Наверное вы имели в виду "обожрались"? Если гусеницы действительно перерабатывают пластик, как заявлено в статье, а не просто глотают и измельчают, то в теории может и сработать. Хотя, конечно, без серьезных исследований исключать какие-то странные побочные эффекты дальше по цепочке нельзя
Имхо вы поторопились с созданием собственного решения, не разобравшись как следует в теории и существующих инструментах. Поэтому предложенный DSL воспринимается как велосипед, а статья вызывает гораздо больше вопросов, чем ответов. Например:
Как разобрать конструкцию вида if(...) { ... } else { ... }, где else и блок после него опциональны?
Как разобрать конструкцию вида 1 + (2 - (3 * 4 / 5) + 6 + 7)), где есть вложенность и цикл?
Зачем такое количество синтаксического шума в DSL, например всякие M+=, O+=, split, go_auto и т.д., если всё это можно вывести автоматически из списка полей выше и не заставлять разработчика писать еще раз вручную?
Используете ли вы ваш парсер, чтобы разобрать его собственную грамматику, и возможно ли это сделать вообще?
Заодно ради интереса сравните, как выглядит реализация пунктов 1 и 2 на вашем DSL и на, например, PEG или комбинаторах парсеров.
Кажется, что предлагаемый синтаксис подходит только для одной очень узкой задачи. Шаг в сторону - и, по всей видимости, нужно всё переписывать на обычные циклы. Например, если я хочу шаг, отличный от 1? А если я хочу на каждом шаге цикла еще залогировать что-то? Ну и так далее
Простите, мне очень сложно следовать за мыслью в вашем комментарии, но попытаюсь ответить.
Метафорически говоря, если я хочу поесть салат и начну его приготовление с посадки семечек на грядку, то я умру с голоду быстрее, чем что-то вырастет. Вместо этого я пойду в магазин, сколько бы ни твердили, что выращенные своими руками овощи полезнее и вкуснее.
И в программировании точно так же. Я хочу получить готовую игру в обозримое время. Когда ресурсы ограничены, их лучше потратить на высокоуровневые вещи типа оттачивания геймплея и баланса, сюжет и т.д., а не ковыряние низкоуровневых проблем и поиска костылей для них. С нормальным движком можно рассчитывать на то, что эти скучные вещи уже решены.
Пробовал такой подход. Делать игру на собственном движке первое время весело, а потом оказывается, что многие удобные вещи на коленке за пару вечером не делаются - сборка под разные платформы (особенно мобильные), поддержка разных разрешений экрана, создание атласов текстур, оптимизации отрисовки, системы частиц, столкновение различных форм, UI, внутриигровые покупки, профилировщик и т.д. - в других движках кто-то другой уже потратил сотни человекочасов, чтобы сделать всё как следует, а тебе только предстоит.
Сборка ссылается на огромное множество стандартных библиотек .NET, и анализировать их бессмысленно - в них не может быть вредоносного кода.
А это точно так? В них может быть код, который позволит вредоносному плагину выполнять произвольные действия. Например, как вы отловите ситуацию, если загружаемая сборка создаст экземпляр "запрещенного" типа с помощью десериализатора? А если в ней используется dynamic, как это проанализировать? И т.д. - составить исчерпывающий список запрещенных API не представляется возможным, и сам по себе подход будет бесконечным затыканием дырок, каждая из которых может быть фатальна для проекта.
На практике я встречал много кода на проектах, где разработчики просто игнорировали возможные ошибки. Например, они использовали операторы await или throw в вызываемых функциях и не применяли конструкции try-catch.
Если обработка ошибки не происходит непосредственно в месте ее возникновения, это не значит, что разработчик ее игнорирует. Место, где ошибку можно обработать осмысленно, как правило находится гораздо выше по колл-стеку, чем место ее возникновения, и таких мест мало - а мест, где нужно понимать конкретный тип ошибки, и того меньше. Обмазывать ради этого весь код таким густым бойлерплейтом - переусложненное решение. Если это знание вам важно, возможно, стоило взять какой-то другой язык, нежели Typescript?
Не, ну если складывать метры с килограммами, то и не такое можно наворотить. Обычно получить количество байт гораздо проще, чем число видимых символов - из известных мне языков только Python делает наоборот. Другое дело, что с такой логикой всё сломается гораздо раньше - с первым символом, кодируемым более чем одним байтом. Скрытые символы ситуацию не ухудшат.
Ну а с точки зрения DoS или увеличения времени обработки они, кажется, не более опасны, чем если добавить в текст много пробелов.
Было бы неплохо дать не только ссылку на репозиторий, а написать немного про язык для тех, кто о нем ничего не знает. В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Оно не стирает указания типов, а забивает их пробелами. Поэтому, наоборот: размер исходника не меняется (следовательно экономии нет), все значимые вещи остаются в точности на своих местах (следовательно source maps не нужны), и все это нужно сугубо для удобства быстрого запуска локально. Для сборки на прод по-прежнему нужен полноценный TS с проверками, минификатор и т.д.
Наверное вы имели в виду "обожрались"? Если гусеницы действительно перерабатывают пластик, как заявлено в статье, а не просто глотают и измельчают, то в теории может и сработать. Хотя, конечно, без серьезных исследований исключать какие-то странные побочные эффекты дальше по цепочке нельзя
Фишка гусениц в том что они могут его именно переработать, а не просто проглотить как человек или кто-либо еще
Но ведь гусениц можно абсолютно экологичным способом перерабатывать в курятину или свинину?
Очень удобный движок для инди-разработчика, и активно развивается
Имхо вы поторопились с созданием собственного решения, не разобравшись как следует в теории и существующих инструментах. Поэтому предложенный DSL воспринимается как велосипед, а статья вызывает гораздо больше вопросов, чем ответов. Например:
Как разобрать конструкцию вида
if(...) { ... } else { ... }, гдеelseи блок после него опциональны?Как разобрать конструкцию вида
1 + (2 - (3 * 4 / 5) + 6 + 7)), где есть вложенность и цикл?Зачем такое количество синтаксического шума в DSL, например всякие
M+=,O+=,split,go_autoи т.д., если всё это можно вывести автоматически из списка полей выше и не заставлять разработчика писать еще раз вручную?Используете ли вы ваш парсер, чтобы разобрать его собственную грамматику, и возможно ли это сделать вообще?
Заодно ради интереса сравните, как выглядит реализация пунктов 1 и 2 на вашем DSL и на, например, PEG или комбинаторах парсеров.
Кажется, что предлагаемый синтаксис подходит только для одной очень узкой задачи. Шаг в сторону - и, по всей видимости, нужно всё переписывать на обычные циклы. Например, если я хочу шаг, отличный от 1? А если я хочу на каждом шаге цикла еще залогировать что-то? Ну и так далее
Какая уже по счету итерация механического турка?
Простите, мне очень сложно следовать за мыслью в вашем комментарии, но попытаюсь ответить.
Метафорически говоря, если я хочу поесть салат и начну его приготовление с посадки семечек на грядку, то я умру с голоду быстрее, чем что-то вырастет. Вместо этого я пойду в магазин, сколько бы ни твердили, что выращенные своими руками овощи полезнее и вкуснее.
И в программировании точно так же. Я хочу получить готовую игру в обозримое время. Когда ресурсы ограничены, их лучше потратить на высокоуровневые вещи типа оттачивания геймплея и баланса, сюжет и т.д., а не ковыряние низкоуровневых проблем и поиска костылей для них. С нормальным движком можно рассчитывать на то, что эти скучные вещи уже решены.
Я не говорю, что это невозможно - но крайне утомительно и трудозатратно, особенно для хобби-проекта, который делает один или пара человек по вечерам
Пробовал такой подход. Делать игру на собственном движке первое время весело, а потом оказывается, что многие удобные вещи на коленке за пару вечером не делаются - сборка под разные платформы (особенно мобильные), поддержка разных разрешений экрана, создание атласов текстур, оптимизации отрисовки, системы частиц, столкновение различных форм, UI, внутриигровые покупки, профилировщик и т.д. - в других движках кто-то другой уже потратил сотни человекочасов, чтобы сделать всё как следует, а тебе только предстоит.
А это точно так? В них может быть код, который позволит вредоносному плагину выполнять произвольные действия. Например, как вы отловите ситуацию, если загружаемая сборка создаст экземпляр "запрещенного" типа с помощью десериализатора? А если в ней используется dynamic, как это проанализировать? И т.д. - составить исчерпывающий список запрещенных API не представляется возможным, и сам по себе подход будет бесконечным затыканием дырок, каждая из которых может быть фатальна для проекта.
Но зачем? Шутка-то одноразовая - слепить тему, записать с ней видео для ютуба, и всё. Едва ли кто-то будет действительно на ней сидеть
Если обработка ошибки не происходит непосредственно в месте ее возникновения, это не значит, что разработчик ее игнорирует. Место, где ошибку можно обработать осмысленно, как правило находится гораздо выше по колл-стеку, чем место ее возникновения, и таких мест мало - а мест, где нужно понимать конкретный тип ошибки, и того меньше. Обмазывать ради этого весь код таким густым бойлерплейтом - переусложненное решение. Если это знание вам важно, возможно, стоило взять какой-то другой язык, нежели Typescript?
Три абсолютно бесполезных скриншота, и ни слова о сути нововведений, серьезно?
Да и туды его в качель. Более тормозной мессенджер чем еще поискать надо, для него загружать историю сообщений со вчера полминуты - в порядке вещей
Не, ну если складывать метры с килограммами, то и не такое можно наворотить. Обычно получить количество байт гораздо проще, чем число видимых символов - из известных мне языков только Python делает наоборот. Другое дело, что с такой логикой всё сломается гораздо раньше - с первым символом, кодируемым более чем одним байтом. Скрытые символы ситуацию не ухудшат.
Ну а с точки зрения DoS или увеличения времени обработки они, кажется, не более опасны, чем если добавить в текст много пробелов.
Это как должна быть реализована проверка длины строки, чтобы ее можно было таким образом обойти?
Практическое применение сомнительно - слишком просто обнаруживается и вырезается, plausible deniability как в случае со стеганографией отсутствует.
Было бы неплохо дать не только ссылку на репозиторий, а написать немного про язык для тех, кто о нем ничего не знает. В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Оно не стирает указания типов, а забивает их пробелами. Поэтому, наоборот: размер исходника не меняется (следовательно экономии нет), все значимые вещи остаются в точности на своих местах (следовательно source maps не нужны), и все это нужно сугубо для удобства быстрого запуска локально. Для сборки на прод по-прежнему нужен полноценный TS с проверками, минификатор и т.д.