Это неверно. Тут перепутан субъект и объект глагола. Смысл грифинга (griefing) не в том, что игрок «скорбит», а в том, что он «вызывает скорбь» у других игроков. То есть вызывает негативные эмоции у других игроков и тем самым портит впечатление от игры.
Собака выгоду получает, у неё среди обезьян пробаффана способность ловить грызунов. Для обезьяны ситуация неоднозначная, т.к. указано, что собаки иногда заигрываются и ловят их детёнышей, но, возможно, есть и какие-то нераскрытые плюсы, которые меняют общую оценку выгоды на слабо-положительную.
А что будет, если отрефакторить его с использованием map? Массив остался неизменным.
Да, есть такое. filter-map-reduce семейство функций на разрежённых массивах не работает с пропусками. Некоторые библиотеки в угоду производительности даже исключают разрежённые массивы из области своего применения.
В очередной раз все изменения очень хорошие. Версия 5 хорошо стартанула.
requirements порадовало. Что-то типа чеклиста и --dry-run в одном.
cordova prepare --browserify — сначала подумал что они просто за пользователей решили чем им собирать, но всё оказалось лучше. Вообще, работа над зависимостями очень радует.
особенности API, … не слишком удачного, но устоявшегося
Об этом я и веду речь.
1. Если сделать dir(fs), то получим солянку из двух API, в которых зрительно придётся выделять sync/async функции.
2. В любой подсистеме, как правило, используется одно из двух API. Для скриптов синхронное, для серверов асинхронное. Нет необходимости валить их в один модуль. Они могли бы быть в разных пространствах имён или даже в разных модулях.
3. Префиксы-постфиксы это очень грязная практика, так как в определённый момент возникает ситуация, когда для получения нужной функциональности приходится конструировать её имя. В итоге, приходится доблестно решать проблему доступа к объекту, которую мы сами создали какое-то время назад. Всегда, когда есть возможность, лучше пользоваться языковыми средствами, например пространствами имён.
Теперь Вы можете предварительно загрузить модули во время выполнения скриптов или использования REPL. Сделать это можно с помощью -r или флага --require.
Очень здравая фишка, но это не всё, что можно с этим сделать. Ещё более интересный кейс: загрузить модули и/или скрипты, выполнить их и перейти в REPL с результатами работы в global. Когда-то приходил в трекер ноды с таким запросом, но был непонят. В ноде есть флаг --interactive но он имеет контр-интуитивный смысл.
Необходимость не пропадала и я запилил для этих задач модуль repl.js и сейчас его широко использую в различных экспериментах с кодом, проверке идей и т.п.
Что мне не нравится в модуле fs, так что это, что синхронные и асинхронные операции свалены в одном нейсмспейсе. А чтобы избежать коллизий, синхронные функции получили уродливый постфикс Sync. Я бы просто выделил в модуле суб-пространство имён sync и в нём все функции имели бы такие же имена, как и асинхронные. Также в дальнейшем так можно было бы добавить суб-пространство имён promise и положить туда аналогичный набор функций, возвращающий промисы. Многие библиотекостроители догадались до этого манёвра, в результате мы имеем опрятное API в библиотеках glob, cp, mkdirp, touch и других.
Если примешивалка будет немного сложней чем Object.assign, то можно сделать предупреждения, и даже более сложные вещи, типа проверки вхождения в миксин.
Регион? Ну так-то да, регион, но ошибка из одного места региона не равна ошибке из другого места региона. Тут сказывается не столько формальная сила типизации языка, сколько реальная типизация ошибок, обусловленная предметной областью задачи. Если ошибки произошли в разных местах этого региона, то и источники у них разные, и корректная их обработка тоже будет различаться. Какой смысл остаётся от региона, если все захваченные им ошибки всё равно потом нужно распределять по обработчикам?
Если я не прав, то в качестве контрпримера приведите ситуацию, когда мы можем создать регион, в двух разных точках которого потенциально возможно получение ошибок одинакового типа (с формальной точки зрения) и главное — одинаковую обработку этих ошибок (фактическая типизация предметной области).
То есть PhoneGap был раньше и был проприетарным. Потом код был передан в Апач. Но ведь и сейчас PhoneGap предоставляет облачные сервисы на базе Кордовы? То есть получается, что оба проекта находятся в активном состоянии, имеют общий код, но PhoneGap имеет проприетарные добавки. Всё верно?
Насколько я знаю, это некорректно. PhoneGap является коммерческим форком Кордовы с дополнительными плюшками, навроде сборочной инфраструктуры в облаке. PhoneGap это форк Cordova (а не наоборот).
Использование того же самого языка для программ и метапрограмм не обязательно
Я с вами по большей части согласен, но и мысль иметь схожий синтаксис для языка и мета-языка тоже заманчива. В основе мета-генерации будут лежать всё равно все те же основы, что и при работе с «обычными» данными: определения, ветвления, циклы. А пройтись по мапе целых чисел или по мапе операторов языка разницы особой не имеет: суть цикл (за вычетом требования constexpr ко всем участникам последнего). Главное, чтобы вызов обычной функции и макроса в коде различались.
Я думаю, разница между языком и его мета-языком тем больше, чем более строг и статичен язык. По мере добавления динамики грань между языком и мета-языком стирается, до тех пор, пока совсем не пропадёт на уровне символических выражений Лиспа.
requirementsпорадовало. Что-то типа чеклиста и--dry-runв одном.cordova prepare --browserify— сначала подумал что они просто за пользователей решили чем им собирать, но всё оказалось лучше. Вообще, работа над зависимостями очень радует.1. Если сделать
dir(fs), то получим солянку из двух API, в которых зрительно придётся выделятьsync/asyncфункции.2. В любой подсистеме, как правило, используется одно из двух API. Для скриптов синхронное, для серверов асинхронное. Нет необходимости валить их в один модуль. Они могли бы быть в разных пространствах имён или даже в разных модулях.
3. Префиксы-постфиксы это очень грязная практика, так как в определённый момент возникает ситуация, когда для получения нужной функциональности приходится конструировать её имя. В итоге, приходится доблестно решать проблему доступа к объекту, которую мы сами создали какое-то время назад. Всегда, когда есть возможность, лучше пользоваться языковыми средствами, например пространствами имён.
global. Когда-то приходил в трекер ноды с таким запросом, но был непонят. В ноде есть флаг--interactiveно он имеет контр-интуитивный смысл.Необходимость не пропадала и я запилил для этих задач модуль repl.js и сейчас его широко использую в различных экспериментах с кодом, проверке идей и т.п.
fs, так что это, что синхронные и асинхронные операции свалены в одном нейсмспейсе. А чтобы избежать коллизий, синхронные функции получили уродливый постфиксSync. Я бы просто выделил в модуле суб-пространство имёнsyncи в нём все функции имели бы такие же имена, как и асинхронные. Также в дальнейшем так можно было бы добавить суб-пространство имёнpromiseи положить туда аналогичный набор функций, возвращающий промисы. Многие библиотекостроители догадались до этого манёвра, в результате мы имеем опрятное API в библиотеках glob, cp, mkdirp, touch и других.Object.assign, то можно сделать предупреждения, и даже более сложные вещи, типа проверки вхождения в миксин.Если я не прав, то в качестве контрпримера приведите ситуацию, когда мы можем создать регион, в двух разных точках которого потенциально возможно получение ошибок одинакового типа (с формальной точки зрения) и главное — одинаковую обработку этих ошибок (фактическая типизация предметной области).
Я думаю, разница между языком и его мета-языком тем больше, чем более строг и статичен язык. По мере добавления динамики грань между языком и мета-языком стирается, до тех пор, пока совсем не пропадёт на уровне символических выражений Лиспа.
Похоже, что в планах есть: