На Хабре есть такая статья «Что же там такого тяжелого в обработке исключений C++?». В статье рассказывается про две стратегии обработки исключений, из коей можно сделать выводы, что вне зависимости от выбранного механизма, есть некоторый (малый или умеренный) оверхед.
Не знаю, как обстоят дела с оверхедом механизма ошибок в Rust, но есть подозрение, что их затруднения как раз связаны с желанием имплементировать механизм ошибок, за который не придётся платить в рантайме. Что весьма похвально для системного языка. Вообще, одна из самых лучших вещей в Rust это то, что они по сути на полную катушку используют принцип C++ «вы не платите за то, что не используете», и при этом приправляют его статическими гарантиями.
Короче, поживём увидим. Не взяли в релиз: не хотят уже затягивать с 1.0, потому как давали гарантии по датам. С другой стороны можно получить разброд в коде библиотек, написанных после релиза. В общем, хейтеры найдут к чему прицепиться, а прогрессивному человечеству остаётся просто осознать принятое решение.
Будущее — за архитектурой, собираемой из отдельных компонуемых npm-пакетов. Управляющий код оформлен в виде потоков данных (Bacon, Highland). HTTP-данные, данные из сокетов и моделей абстрагированы в источники таких потоков, а представления на них единообразно подписываются. Пользователь также является источником потоков команд, подписчиком на которые выступает сервер.
Сейчас главное число версии означает наличие костылей для старых обозревателей или их осутствие. При этом оба пакета (более-менее) содержат одну и ту же версию API, просто засчёт костылей compat-версия более тяжёлая. Суть данного изменения в том, что они хотят поменять семантику версии с обозначения «совместимость-не совместимость» на обозначение версии API, как это должно быть в семвере. Теперь будет два пакета версии 3 (которые, по факту, имеют один API) и они будут обновляться параллельно.
3.х только для специфических задач
Разработка под мобильные обозреватели (при известных целевых платформах) может вестись с модерновым вариантом библиотеки. Если ведётся разработка какого-то модного сервиса для специалистов, или внутренний сервис, когда известно, что ретроградов нет, то тоже можно пользоваться модерновой версией. По-моему сейчас, наоборот, скорее проще сказать когда нужна compat-версия, а в остальных случаях пользоваться модерновой.
Все примеры конечно не имеет. Но это ж не какой-то рядовой случай. Это как раз тот самый случай, когда Близзард внезапно проиграл в суде. И суд поделил права на персонажей (модели) WarCraft и права на персонажей (геймплей) доты, использовавших эти модели в оригинале.
И этот случай повлиял на возникновение Dota 2, которая стремительно ворвалась в топы, благодаря политике Valve, а Близзард вынуждены были делать своих Heroes of the Storm. Если бы дело получило иной результат, сейчас бы всё было иначе. Никаких фритуплеев, стим доты, никаких International с компендиумами и пр.
Я во всё это не играю, но даже мне видно какой громадный эффект на отрасль оказал вердикт этого дела.
Если вы о завязанности на реестр npm, то это не так — можно ставить зависимости с GitHub или любого git-эндпоинта. Также с версии 2 можно использовать свои реестры приватных пакетов. То есть npm прекрасно работает с кастомным реестром или без оного, как, например, это делает bower.
А если вы о завязанности на сам API npm, то это есть. Но разве тут есть что-то плохое? npm весьма хорош.
Не воспринимайте эту фразу, как C++ — плохой, а X — хороший.
Скорее, это значит, что C++, за свою долгую жизнь оброс различными здоровыми практиками и идиомами, но даже при всём желании комитета разработчиков он не сможет ввести некоторые фичи, в силу громадного груза обратной совместимости.
С другой стороны, язык X (Rust, например), не имеет такого груза; он может свободно заимствовать лучшие идеи из C++ и других языков, и, возможно, когда-нибудь станет следующим словом в системном программировании.
Не нужно всем сразу бросать C++ и кидаться писать на Rust. C++ это основа, которая всем нужна, на нём написано громадное количество жизненно важного для индустрии кода, но это не значит, что он никогда не будет заменён чем-то новым.
Насколько подсказывает мой опыт, тип Символ это аналог перечислимого значения, уникального в пределах всей программы. Т.е., он выполняет роль некоторого уникального (но при этом читаемого в коде) идентификатора. Символ ближе к enum, чем к строке (просто мы его видим как строку), все символы лежат как бы внутри глобального enum на всю программу. Если сравнить это со статьёй, то автор тоже вводит FizzBuzzItem с перечислимыми значениями, которые суть символы, уникальные в рамках этого типа.
Главная проблема, как указывают выше, это то, что символы во многих языках с gc не утилизируются (например, если мне не изменяет память, в erlang). Если в рубине утилизируются, то это очень хорошо, это очень здорово.
Скорее всего, вы бы применили методы parseFloat и parseInt.
В очередной раз незаслуженно не упоминается функция и конструктор Number. Функции parseInt и parseFloat делают несколько больше, чем конвертация в число. Наиболее близкий аналог это «выковыривание» числа из числоподобной строки. Для конвертации лучше прямолинено использовать конструктор Number.
Вот хороший пример:
Под иерархическим я понимаю имя, которое составлятся из категорий от более общих, к более частным.
Возьмём для примера два имени: right-of-viewport, partly-above-the-viewport. Самая общая категория здесь это viewport, соответственно, имя должно начинаться с него. Т.е, если переделать, то это будет viewport-right, viewport-above-partly, или что-то в таком роде (с артиклями или без, по вкусу). При этом все имена заключены в «пространство имён» viewport и далее в субпространства, относящиеся к более мелким категориям (субкатегориям). Такое имя проще генерить, проще получить список всех имён, проще запомнить.
Его сложней читать, это обратная сторона. Если взглянуть на псевдоселекторы CSS, то многие из них написаны в «литературном» порядке, но т.к. их длина меньше, это не так критично. У вас же селекторов много, они однотипные, imo, тут уже лучше иерархический подход.
Замечательная статья, всё по делу и достаточно просто. Если применить фразу из статьи, то сама статья следует принципу быть «наиболее простым текстом из всего возможного множества описаний» :)
Тема DSL очень интересная, и, вообще, DSL во многих случаях можно рассматривать как один из способов своевременного поднятия абстракции.
Лично я к такому подходу отношусь положительно, но термин «кодогенерация» мне не нравится, потому что он навевает генераторы всяких копипаст-болванок и «шаблонного» кода. Если языку нужно генерировать какой-то шаблонный код, то либо ему не хватает возможностей к абстракции, либо программисту не хватает знаний об этом языке.
А вот декларативность и доменный подход это, конечно, пушка. Не всегда даже нужно делать парсер или использовать спецефический язык, достаточно просто пересмотреть используемые концепции в ЯП общего назначения и он уже открывает свои новые грани, возможности тут безграничны.
Не знаю, как обстоят дела с оверхедом механизма ошибок в Rust, но есть подозрение, что их затруднения как раз связаны с желанием имплементировать механизм ошибок, за который не придётся платить в рантайме. Что весьма похвально для системного языка. Вообще, одна из самых лучших вещей в Rust это то, что они по сути на полную катушку используют принцип C++ «вы не платите за то, что не используете», и при этом приправляют его статическими гарантиями.
Короче, поживём увидим. Не взяли в релиз: не хотят уже затягивать с 1.0, потому как давали гарантии по датам. С другой стороны можно получить разброд в коде библиотек, написанных после релиза. В общем, хейтеры найдут к чему прицепиться, а прогрессивному человечеству остаётся просто осознать принятое решение.
Разработка под мобильные обозреватели (при известных целевых платформах) может вестись с модерновым вариантом библиотеки. Если ведётся разработка какого-то модного сервиса для специалистов, или внутренний сервис, когда известно, что ретроградов нет, то тоже можно пользоваться модерновой версией. По-моему сейчас, наоборот, скорее проще сказать когда нужна compat-версия, а в остальных случаях пользоваться модерновой.
И этот случай повлиял на возникновение Dota 2, которая стремительно ворвалась в топы, благодаря политике Valve, а Близзард вынуждены были делать своих Heroes of the Storm. Если бы дело получило иной результат, сейчас бы всё было иначе. Никаких фритуплеев, стим доты, никаких International с компендиумами и пр.
Я во всё это не играю, но даже мне видно какой громадный эффект на отрасль оказал вердикт этого дела.
А если вы о завязанности на сам API npm, то это есть. Но разве тут есть что-то плохое? npm весьма хорош.
Скорее, это значит, что C++, за свою долгую жизнь оброс различными здоровыми практиками и идиомами, но даже при всём желании комитета разработчиков он не сможет ввести некоторые фичи, в силу громадного груза обратной совместимости.
С другой стороны, язык X (Rust, например), не имеет такого груза; он может свободно заимствовать лучшие идеи из C++ и других языков, и, возможно, когда-нибудь станет следующим словом в системном программировании.
Не нужно всем сразу бросать C++ и кидаться писать на Rust. C++ это основа, которая всем нужна, на нём написано громадное количество жизненно важного для индустрии кода, но это не значит, что он никогда не будет заменён чем-то новым.
enum, чем к строке (просто мы его видим как строку), все символы лежат как бы внутри глобального enum на всю программу. Если сравнить это со статьёй, то автор тоже вводитFizzBuzzItemс перечислимыми значениями, которые суть символы, уникальные в рамках этого типа.Главная проблема, как указывают выше, это то, что символы во многих языках с gc не утилизируются (например, если мне не изменяет память, в erlang). Если в рубине утилизируются, то это очень хорошо, это очень здорово.
В общем случае унарный плюс форсит вызов valueOf.
В очередной раз незаслуженно не упоминается функция и конструктор
Number. ФункцииparseIntиparseFloatделают несколько больше, чем конвертация в число. Наиболее близкий аналог это «выковыривание» числа из числоподобной строки. Для конвертации лучше прямолинено использовать конструкторNumber.Вот хороший пример:
Просто превосходно.
Возьмём для примера два имени:
right-of-viewport,partly-above-the-viewport. Самая общая категория здесь это viewport, соответственно, имя должно начинаться с него. Т.е, если переделать, то это будетviewport-right,viewport-above-partly, или что-то в таком роде (с артиклями или без, по вкусу). При этом все имена заключены в «пространство имён» viewport и далее в субпространства, относящиеся к более мелким категориям (субкатегориям). Такое имя проще генерить, проще получить список всех имён, проще запомнить.Его сложней читать, это обратная сторона. Если взглянуть на псевдоселекторы CSS, то многие из них написаны в «литературном» порядке, но т.к. их длина меньше, это не так критично. У вас же селекторов много, они однотипные, imo, тут уже лучше иерархический подход.
Непохоже, что он съехал, скорее всего просто не понял вопрос.
Тема DSL очень интересная, и, вообще, DSL во многих случаях можно рассматривать как один из способов своевременного поднятия абстракции.
Лично я к такому подходу отношусь положительно, но термин «кодогенерация» мне не нравится, потому что он навевает генераторы всяких копипаст-болванок и «шаблонного» кода. Если языку нужно генерировать какой-то шаблонный код, то либо ему не хватает возможностей к абстракции, либо программисту не хватает знаний об этом языке.
А вот декларативность и доменный подход это, конечно, пушка. Не всегда даже нужно делать парсер или использовать спецефический язык, достаточно просто пересмотреть используемые концепции в ЯП общего назначения и он уже открывает свои новые грани, возможности тут безграничны.