Тот же С++ имеет контекстно-зависимую грамматику, это сильно мешает парсить его регулярками. В частности, С++ парсер должен уметь ВЫПОЛНЯТЬ достаточное объемное (и полное по Тьюрингу!) подмножество С++ кода (т.к. constexpr может влиять на контекст ниже написанного кода, а С++ грамматика контекстно-зависима - один и тот же код («текст») может означать совершенно разные вещи в зависимости от, скажем, наличия объявления переменной/поля/класса выше по тексту, которое в свою очередь может вычисляться шаблонной магией и constexpr-ам, например, при инстанцировании шаблона, условный метод getX() может объявляться или не объявляться в зависимости от наличия условного поля X у конкретного типа).
Regex-ы (по крайней мере стандартные) не являются полными по Тьюрингу, поэтому вышеописанные операции они (в общем случае) выполнить не могут даже в теории. Поэтому они и называются РЕГУЛЯРНЫЕ выражения. Для С++ таки нужен полноценный парсер.
Есть и хорошие новости - полноценные парсеры писать самому не надо, они уже написаны для всех популярных языков и большинство поддерживает плагины (т.к. можно добавить свой синтаксис), в С#, к примеру, это кастомный синтаксис для всяких DSL прямо в проект можно встроить штатными средствами. Для С++ есть clang, для JS - Babel, итд
Ну дак от ковида такая же аутоиммунная фигня, только сильно хуже; собственно, поэтому и колят больным при некоторых условиях имуносупрессоры (забыл уже название) - чтоб реакция иммунитета не добила человека. Так что лучше уж вакцина, там шансы откинуться сильно меньше, полностью она не защитит скорей всего, но хотя бы течение ковида потом будет «легкое» (см. выше)
Ну знаете, я вот болел весной. «Легко» - даже не кашлял, в общем-то (пока болел, а вот потом было несколько приступов ещё в течении двух месяцев). Так вот, это «лёгкое» течение - на практике худший «ОРВИ», который у меня был за последние 10 лет; вроде бы и не болит ничего особенно, но температура 38.5-39.5 больше недели и состояние такое, что даже моргать не хочется. Лучше уж я «поболею» три дня аденовирусом из вакцины, который туда подсовывают для репликации достаточного количества антител, чем ещё раз этой штукой.
Если вы собрались писать оптимальный кол на шарпе, то неожиданный боксинг/анбоксинг это одно из первых мест куда надо смотреть. Чтобы упростить эту задачу, сто лет назад изобрели плагин для решарпера/райдера: https://plugins.jetbrains.com/plugin/9223-heap-allocations-viewer. Ну а решарпер/райдер это must have
Ну это как бы классический процесс если компания озабочена безопасностью. А если не озабочена - то это должны быть проблемы компании, а не разработчиков - в том смысле, что подобная интеграция стоит каких-то усилий (и одноразовых, и на поддержку процесса) - инвестировать ли время (деньги) в процессы связанные с безопасностью или в новые фичи, принимая риски, связанные с безопасностью - это решение бизнеса/собственников.
Акселерометр - это беда, если гейм дизайнеры не умеют им пользоваться. Вы пробовали играть держа телефон в положении отличном от «лежит на столе» - например на диване, держа телефон в руке? Самолётик просто падает - оси координат-то перед началом игры никто не нормировал!
Есть и другие баги: игра не работает на ноутбуках (почему нельзя управлять стрелками?), она далеко не всегда включается - чаще сайт начинает сыпать какими-то малопонятными ошибками при отсутствии соединения, а иногда вместо игры появляется статическая заглушка. Детект восстановления тоже глючит.
Начинающие программисты нынче вообще не разбираются в системах счисления, сегодня начинающие программисты должны уметь разбираться в концепциях питона, вебпака и прочего. А байты, биты и все такое - это предмет низкоуровневых оптимизаций.
А можете всё-таки словами объяснить, пожалуйста? В статье какие-то странные вычисления, основанные на том, что «складывать в столбик в троичной системе быстрее чем в двоичной» (меньше переносов). С одной стороны это правда, с другой стороны - а какова практическая польза с учётом того, что компьютеры оперируют в основном с числами фиксированной длины и на таких числах базовая арифметика и логика всегда выполняется за один такт? Получается, что надо ориентироваться не на скорость работы, а на число транзисторов необходимых для реализации логики (меньше транзисторов = дешевле и проще делать многоядерные процессоры). И вот про число транзисторов в статье ни слова.
Надо определится - или тут или здесь - если дженерики можно в библиотеках, как их запретить в сервисном коде? А если не запретить, то их будут использовать… и как выше сказали они сложные.
Ничего не имею против Rust. Если вас после миграции все устраивает - это именно то, о чем я говорю (C# был взят для примера). И да, открытость языка - это очень важно. Я как бывший .NET разработчик до сих пор радуюсь, что MS решилась сделать компилятор (Roslyn) и рантайм (.NET Core/5.0) открытым - это дало дало огромный буст к развитию языка.
Так вот я о том же - может таки мигрировать на что-то другое, что из коробки поддерживает дженерики и плагины? Тот же с# - дженерики работают из коробки, плагины - можете написать, компилятор открытый - в последних версиях есть возможность кодо-генерации (можете изобрести свой DSL и генерировать С# код во время компиляции встроенными средствами, только хорошо подумайте есть ли от этого профит), как частный случай - можете придумать собственные операторы типа await (вам это точно надо?)
Я не эксперт в Go, могу предположить, что оно без этого не взлетает, возможно изначальная идея «простоты» неработоспособна. Дженерики можно туда же отнести; в целом - надо определиться - или очередной .NET/Java, или простота с ограничением возможностей, которая подходит не всем. Простота вроде как декларировалась Гуглом изначально, если простой синтаксис не удовлетворяет реальные требования бизнесов де-факто, то (наверное) стоит отказаться от идеи совсем, и вместо попытки сделать очередную джаву, огласить язык мёртвым (для этого требуется мужество и чёткое понимание бизнес целей). На двух стульях (разрешив сложные штуки в библиотеках и только простые штуки в сервисах) усидеть сложно.
Тот же С++ имеет контекстно-зависимую грамматику, это сильно мешает парсить его регулярками. В частности, С++ парсер должен уметь ВЫПОЛНЯТЬ достаточное объемное (и полное по Тьюрингу!) подмножество С++ кода (т.к. constexpr может влиять на контекст ниже написанного кода, а С++ грамматика контекстно-зависима - один и тот же код («текст») может означать совершенно разные вещи в зависимости от, скажем, наличия объявления переменной/поля/класса выше по тексту, которое в свою очередь может вычисляться шаблонной магией и constexpr-ам, например, при инстанцировании шаблона, условный метод getX() может объявляться или не объявляться в зависимости от наличия условного поля X у конкретного типа).
Regex-ы (по крайней мере стандартные) не являются полными по Тьюрингу, поэтому вышеописанные операции они (в общем случае) выполнить не могут даже в теории. Поэтому они и называются РЕГУЛЯРНЫЕ выражения. Для С++ таки нужен полноценный парсер.
Есть и хорошие новости - полноценные парсеры писать самому не надо, они уже написаны для всех популярных языков и большинство поддерживает плагины (т.к. можно добавить свой синтаксис), в С#, к примеру, это кастомный синтаксис для всяких DSL прямо в проект можно встроить штатными средствами. Для С++ есть clang, для JS - Babel, итд
А почему вы не используете LLVM чтобы не воевать с бинарным кодом самостоятельно?
Ну дак от ковида такая же аутоиммунная фигня, только сильно хуже; собственно, поэтому и колят больным при некоторых условиях имуносупрессоры (забыл уже название) - чтоб реакция иммунитета не добила человека. Так что лучше уж вакцина, там шансы откинуться сильно меньше, полностью она не защитит скорей всего, но хотя бы течение ковида потом будет «легкое» (см. выше)
Ну знаете, я вот болел весной. «Легко» - даже не кашлял, в общем-то (пока болел, а вот потом было несколько приступов ещё в течении двух месяцев). Так вот, это «лёгкое» течение - на практике худший «ОРВИ», который у меня был за последние 10 лет; вроде бы и не болит ничего особенно, но температура 38.5-39.5 больше недели и состояние такое, что даже моргать не хочется. Лучше уж я «поболею» три дня аденовирусом из вакцины, который туда подсовывают для репликации достаточного количества антител, чем ещё раз этой штукой.
Если вы собрались писать оптимальный кол на шарпе, то неожиданный боксинг/анбоксинг это одно из первых мест куда надо смотреть. Чтобы упростить эту задачу, сто лет назад изобрели плагин для решарпера/райдера: https://plugins.jetbrains.com/plugin/9223-heap-allocations-viewer. Ну а решарпер/райдер это must have
Ну это как бы классический процесс если компания озабочена безопасностью. А если не озабочена - то это должны быть проблемы компании, а не разработчиков - в том смысле, что подобная интеграция стоит каких-то усилий (и одноразовых, и на поддержку процесса) - инвестировать ли время (деньги) в процессы связанные с безопасностью или в новые фичи, принимая риски, связанные с безопасностью - это решение бизнеса/собственников.
https://stackoverflow.com/a/1732454/14227156
Акселерометр - это беда, если гейм дизайнеры не умеют им пользоваться. Вы пробовали играть держа телефон в положении отличном от «лежит на столе» - например на диване, держа телефон в руке? Самолётик просто падает - оси координат-то перед началом игры никто не нормировал!
Есть и другие баги: игра не работает на ноутбуках (почему нельзя управлять стрелками?), она далеко не всегда включается - чаще сайт начинает сыпать какими-то малопонятными ошибками при отсутствии соединения, а иногда вместо игры появляется статическая заглушка. Детект восстановления тоже глючит.
А так - идея-то хорошая.
Вот - спасибо! Подозреваю, что этот кусок вырезали, так как стыдно было вставлять ссылку на нормальный перевод в статью переведённую Гуглом.
https://xkcd.ru/605/
вот развёрнутый список (окей, это не только вебпак):
import синтаксис вместо require(), export синтаксис вместо module.exports
типы модулей: amd, umd, commonjs, nextjs и т.д.
loaders, импорт-чего-угодно, а не только js (картинки, статические файлы, и т.п.)
type script вместо js, заголовочные файлы, source maps
lock файлы разных видов, повторябельные сборки
менеджмент транзитивных зависимостей
lerna для управления мульти-пакетными репозиториями
yarn вместо npm, yarn workspaces
В 21 веке пользуются webpack + type script, к чему это легаси?
Это, кстати, очень хорошая мысль. К примеру, двоичный поиск - как его организовать в троичном компьютере, если он не умеет легко делить на 2?
Только не предлагайте троичный поиск, я даже боюсь представить, как бы выглядел его алгоритм :)
Начинающие программисты нынче вообще не разбираются в системах счисления, сегодня начинающие программисты должны уметь разбираться в концепциях питона, вебпака и прочего. А байты, биты и все такое - это предмет низкоуровневых оптимизаций.
А можете всё-таки словами объяснить, пожалуйста? В статье какие-то странные вычисления, основанные на том, что «складывать в столбик в троичной системе быстрее чем в двоичной» (меньше переносов). С одной стороны это правда, с другой стороны - а какова практическая польза с учётом того, что компьютеры оперируют в основном с числами фиксированной длины и на таких числах базовая арифметика и логика всегда выполняется за один такт? Получается, что надо ориентироваться не на скорость работы, а на число транзисторов необходимых для реализации логики (меньше транзисторов = дешевле и проще делать многоядерные процессоры). И вот про число транзисторов в статье ни слова.
Это исторически сложилось так, возможно со временем его научат учитывать атрибуты типа [Inject] - это в целом делабельно (не требует каких-то кардинальных изменений языка). Нечто подобное уже есть: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/nullable-analysis
Надо определится - или тут или здесь - если дженерики можно в библиотеках, как их запретить в сервисном коде? А если не запретить, то их будут использовать… и как выше сказали они сложные.
Ничего не имею против Rust. Если вас после миграции все устраивает - это именно то, о чем я говорю (C# был взят для примера). И да, открытость языка - это очень важно. Я как бывший .NET разработчик до сих пор радуюсь, что MS решилась сделать компилятор (Roslyn) и рантайм (.NET Core/5.0) открытым - это дало дало огромный буст к развитию языка.
Так вот я о том же - может таки мигрировать на что-то другое, что из коробки поддерживает дженерики и плагины? Тот же с# - дженерики работают из коробки, плагины - можете написать, компилятор открытый - в последних версиях есть возможность кодо-генерации (можете изобрести свой DSL и генерировать С# код во время компиляции встроенными средствами, только хорошо подумайте есть ли от этого профит), как частный случай - можете придумать собственные операторы типа await (вам это точно надо?)
Я не эксперт в Go, могу предположить, что оно без этого не взлетает, возможно изначальная идея «простоты» неработоспособна. Дженерики можно туда же отнести; в целом - надо определиться - или очередной .NET/Java, или простота с ограничением возможностей, которая подходит не всем. Простота вроде как декларировалась Гуглом изначально, если простой синтаксис не удовлетворяет реальные требования бизнесов де-факто, то (наверное) стоит отказаться от идеи совсем, и вместо попытки сделать очередную джаву, огласить язык мёртвым (для этого требуется мужество и чёткое понимание бизнес целей). На двух стульях (разрешив сложные штуки в библиотеках и только простые штуки в сервисах) усидеть сложно.
// на правах личного мнения