Запускаю Telegram на Android 6, получаю запрос на ввод пароля/отпечаток. Прикладываю отпечаток пальца, и telegram разблокировался, доступна вся переписка СЧ и облако.
Перезапускаю Telegram, ввожу 31-значный local code, и Telegram также разблокирован.
У вас в двух идущих подряд пунктах Телеграм разблокирован. Путаница какая-то, поправьте и укажите более подробно что происходит в первом и втором случае.
Согласен, что от патентных троллей лучше защищаться заранее. Но, во-первых, какова цель упоминания патента в статье? А, во-вторых, делаешь защитный патент – переводи в общественное достояние (public property), незачем ограничивать других разработчиков своим патентом, если настоящая цель – защита.
В такой трактовке – да. Осталось запантентовать разбиение задачи на подзадачи, ограничение предметной области и другие методы оптимизации.
В США пытаются бороться с патентами вида "делать что-то с помощью компьютера". И даже успешно. Хотя процесс идет достаточно медленно, говорят, что из-за нового главы ведомства. Интересно, что будет в данном случае.
Интересно, что именно стало объектом патентования: анализ хангыля приемами для алфавитного письма? Если да, то патент ничтожен. Потому что хангыль – это фонематическое письмо, а не иероглифическое.
Могу сказать, что Go по сравнению со многими языками, которые мне довелось попробовать, более простой и быстрее осваивается (за счет меньшего количества языковых конструкций). Поэтому, вполне вероятно, что в этом плане он выиграет у Перла. Например про Перл я часто слышал, что его легко писать, но тяжело читать.
Но я могу и обобщить: пространство решаемых тьюринг-полными языками задач одинаково, поэтому, если при этом пространства их логических примитивов соразмерны, то остается только синтаксис. И тут выиграет тот, у кого он проще.
2) С тем, что в последнее время получил развитие отказ от ручного управления памятью, выглядит очень опасно. Нужно как-то ограничить. Например разрешать вызов free только из контекста функции main, чтобы управление всегда происходило явно. Возможно, через контроллер, определяемый программистом на уровне приложения, а не библиотеки.
4) Тут я с вами категорически не соглашусь, сначала нужно дать что-то читателю, чтобы вызвать у него интерес. Тогда он и неинтересные части прочтет.
Я не могу обсуждать Перл, так как не знаком с ним. Я говорил о том, что JS постепенно превращается в два языка в одном. Процесс еще не завершился, но вектор задан и меняться не будет, если судить по TC39/proposals.
Например Solidity для Ethereum переваривает поломки обратной совместимости за счет явного указания версии языка в исходном коде программы. Единственное его ограничение в том, что разные версии нельзя использовать в одном проекте. И то, во многом из-за наличия апдейтов безопасности. Но при этом контракты, написанные на первых версиях языка, могут быть собраны и взаимодействуют с контрактами на всех версиях.
Вообще советую провести мысленный эксперимент: создать программу, которая работает бесконечное время, например где-нибудь в далекой-далекой галактике, и периодически получает апдейты на языке, который меняется.
ИМХО. Я бы поменял местами $ и @. Например в Ruby и Crystal используются именно @ как замена конструкции this., а '$' чаще встречается именно в именах переменных.
Вызвав Free, я удаляю значения из памяти даже если они используются в другом месте?
Почему gc() пишется со строчной буквой, а Free() с прописной?
Соглашусь с автором выше, ничего принципиально нового в языке не вижу. Как учебный язык ок, но, на мой взгляд, стоит добавить какую-нибудь изюминку.
Когда к var добавляются let и const, это задирает кривую обучения, потому, что вы не можете пройти мимо этого, а разница в поведении достаточно существенная: var всплывает, let и const – нет, let и const имеют блочную область видимости, var – нет. Различия продолжаются в таких базовых концепциях как объявление функции, создание класса, применение встроенных типов. Нет здесь плавности, о которой вы говорите.
Смысл в том, что в языке появляется много исключений, которые нарушают изначальную логику. И для каждого такого исключения нельзя построить какое-то одно правило, все исключения придется заучивать. Т.е. предсказание поведения на основе полученного опыта становится невозможно. Пример с 1 + 1n уже привел выше.
Самый простой пример из недавнего – исключение в приведении типов. Так можно:
1 + []
А так нельзя:
1 + 1n
Есть и другие примеры, но во всех них просто принято юзать самый последний синтаксис
Это никак не отменяет того, что разработчику придется изучить все три let, const и var, оба варианта объявления классов, разные случаи использования Function и => и т.п. При этом изучая каждую новую конструкцию он будет держать в голове, что из нее могут быть исключения, даже, если их нет. Это катастрофически снижает скорость освоения материала.
Не буду сейчас приводить конкретных примеров, чтобы не уйти в полемику. Смысл в том, что в языке появляются новые возможности, которые не сильно отличаются от предыдущих, но при этом вместо замещения они просто соседствуют. Самый наглядный пример – греческий язык, который за 3 тысячи лет натащил в себя со всего Средиземноморья и теперь в нем 3 буквы "и" и при этом никаких правил когда какую использовать нет, нужно просто заучивать.
JS предстоит научиться чистить исторический мусор, но судя по тому что сейчас происходит в TC39, мы просто однажды столкнемся с последствиями.
У вас в двух идущих подряд пунктах Телеграм разблокирован. Путаница какая-то, поправьте и укажите более подробно что происходит в первом и втором случае.
Согласен, что от патентных троллей лучше защищаться заранее. Но, во-первых, какова цель упоминания патента в статье? А, во-вторых, делаешь защитный патент – переводи в общественное достояние (public property), незачем ограничивать других разработчиков своим патентом, если настоящая цель – защита.
В такой трактовке – да. Осталось запантентовать разбиение задачи на подзадачи, ограничение предметной области и другие методы оптимизации.
В США пытаются бороться с патентами вида "делать что-то с помощью компьютера". И даже успешно. Хотя процесс идет достаточно медленно, говорят, что из-за нового главы ведомства. Интересно, что будет в данном случае.
В патенте у вас явная неточность:
Базовым символом в корейском является не иероглиф, а слог. Патент явно прошел некачественную проверку специалистами.
Интересно, что именно стало объектом патентования: анализ хангыля приемами для алфавитного письма? Если да, то патент ничтожен. Потому что хангыль – это фонематическое письмо, а не иероглифическое.
Могу сказать, что Go по сравнению со многими языками, которые мне довелось попробовать, более простой и быстрее осваивается (за счет меньшего количества языковых конструкций). Поэтому, вполне вероятно, что в этом плане он выиграет у Перла. Например про Перл я часто слышал, что его легко писать, но тяжело читать.
Но я могу и обобщить: пространство решаемых тьюринг-полными языками задач одинаково, поэтому, если при этом пространства их логических примитивов соразмерны, то остается только синтаксис. И тут выиграет тот, у кого он проще.
2) С тем, что в последнее время получил развитие отказ от ручного управления памятью, выглядит очень опасно. Нужно как-то ограничить. Например разрешать вызов
freeтолько из контекста функции main, чтобы управление всегда происходило явно. Возможно, через контроллер, определяемый программистом на уровне приложения, а не библиотеки.4) Тут я с вами категорически не соглашусь, сначала нужно дать что-то читателю, чтобы вызвать у него интерес. Тогда он и неинтересные части прочтет.
Лучше закинуть на JSFiddle.net, jsbin.com или gist.github.com.
Я не могу обсуждать Перл, так как не знаком с ним. Я говорил о том, что JS постепенно превращается в два языка в одном. Процесс еще не завершился, но вектор задан и меняться не будет, если судить по TC39/proposals.
Например Solidity для Ethereum переваривает поломки обратной совместимости за счет явного указания версии языка в исходном коде программы. Единственное его ограничение в том, что разные версии нельзя использовать в одном проекте. И то, во многом из-за наличия апдейтов безопасности. Но при этом контракты, написанные на первых версиях языка, могут быть собраны и взаимодействуют с контрактами на всех версиях.
Вообще советую провести мысленный эксперимент: создать программу, которая работает бесконечное время, например где-нибудь в далекой-далекой галактике, и периодически получает апдейты на языке, который меняется.
this., а '$' чаще встречается именно в именах переменных.Free, я удаляю значения из памяти даже если они используются в другом месте?gc()пишется со строчной буквой, аFree()с прописной?Это никак не отменяет того, что разработчику придется изучить все три let, const и var
Вы цепляетесь за конкретные примеры и игнорируете общую картину, которую они вместе составляют. Просто вернитесь к этому комментраю.
Когда к var добавляются let и const, это задирает кривую обучения, потому, что вы не можете пройти мимо этого, а разница в поведении достаточно существенная: var всплывает, let и const – нет, let и const имеют блочную область видимости, var – нет. Различия продолжаются в таких базовых концепциях как объявление функции, создание класса, применение встроенных типов. Нет здесь плавности, о которой вы говорите.
Смысл в том, что в языке появляется много исключений, которые нарушают изначальную логику. И для каждого такого исключения нельзя построить какое-то одно правило, все исключения придется заучивать. Т.е. предсказание поведения на основе полученного опыта становится невозможно. Пример с
1 + 1nуже привел выше.Один неудачный пример, не является подтверждением ошибочности всей идеи. Это лишь опыт, для поиска оптимального решения.
Самый простой пример из недавнего – исключение в приведении типов. Так можно:
А так нельзя:
Это никак не отменяет того, что разработчику придется изучить все три let, const и var, оба варианта объявления классов, разные случаи использования Function и => и т.п. При этом изучая каждую новую конструкцию он будет держать в голове, что из нее могут быть исключения, даже, если их нет. Это катастрофически снижает скорость освоения материала.
Что-то вы путаете. Чем больше разных решений, тем выше сложность освоения. Для примера возьмите Go и сравните его кривую обучения.
Не буду сейчас приводить конкретных примеров, чтобы не уйти в полемику. Смысл в том, что в языке появляются новые возможности, которые не сильно отличаются от предыдущих, но при этом вместо замещения они просто соседствуют. Самый наглядный пример – греческий язык, который за 3 тысячи лет натащил в себя со всего Средиземноморья и теперь в нем 3 буквы "и" и при этом никаких правил когда какую использовать нет, нужно просто заучивать.
JS предстоит научиться чистить исторический мусор, но судя по тому что сейчас происходит в TC39, мы просто однажды столкнемся с последствиями.
С таким названием идея, что программы должны умирать, не получит поддержки, слишком оно отталкивающее. И плохо отражает суть явления.