Под «чувствителен к новым строкам» я подразумеваю, что если полность удалить переносы строк, код перестанет работать. Замены на пробелы потенциально может работать, но насколько я понимаю, это особенность Lua (признаюсь, про которую я не знал).
DOM — это отдельная история, переносы строк на сам рендеринг HTML не влияют (по-крайней мере, наши тестеры и клиенты из Fortune 500 не жаловались, при всем разнообразии поддерживаемых браузеров включая IE6). Естественно, могут быть нюансы, но кросс-браузерная разработка давно заставила всех использовать только безопасное API с правильными селекторами (или просто использовать библиотеки, где это все учитывается).
Ruby чувствителен к переносам строк, так что его реализации были исключены из списка. Но т.к. я включил Lua и собираюсь включить Python, могу и включить mruby в список, если интересно. Но парсер и компилятор будут включены, т.к. необходимо позволять редактировать скрипты в любое время, при этом не требуя дополнительных инструментов.
Не все встраиваемые ЯП поддерживают байткод. Более того, возможно мы немного по-разному понимаем обфускацию. Для меня это возможность минимизировать и запутать код (вплоть до изменения хода выполнения кода путем вставления и реорганизации вызовов). Байткод не обязательно обфусцированный, хотя конечно, он компактнее исходного кода. luac -l -l -p дает достаточно читабельное представление байткода Lua, хотя, конечно, я верю, что есть специальные обфускаторы. Однако все это весьма специфично для конкретных ЯП и если есть возможность обфусцировать на уровне исходного кода, это предпочтительнее для нас (но, естественно, может быть неудобно для других и им лучше использовать байткод и сторонние утилиты).
Согласен, что неплохо было бы показать использование RAM. К сожалению, для "Hello world" примера числа будут весьма "бестолковые" тоже, т.к. только специфические конструкции или библиотеки могут вызывать большой расход памяти. Однако какие-то числа лучше чем вообще никакие, так что я добавлю это в тесты (https://gitlab.com/nuald-grp/embedded-langs-footprint/-/issues/4)
Под обычный Linux — некоторые ЯП достаточно экзотичны и имеют весьма скудную документацию. Собственно, некоторые я смог завести (чтобы подключить их в виде библиотеки) только изучив их исходный код, так что поддержка кросс-компиляции — это отдельная история, на которую у меня, к сожалению, нет времени.
Область применения — массовые потребительские устройства (включая бюджетные типа телефонов на KaiOS), микроконтроллеры и SoC у нас есть в планах, но далеких. Т.к. на некоторых устройствах (типа той же KaiOS) нет возможности исполнять нативный код, то одна из поддерживаемых target — это WASM, и засовывать туда 5 мегабайт пайтона сверху (которые надо будет пользователю скачать в условиях ограниченного хранилища и дорогого интернета) — это роскошь.
Насколько я вижу, Umka чувствителен к новым строкам, их нельзя просто удалить, так что требования к возможности минификации скриптов не удовлетворяются. Насчет предпочтений процедурных vs функциональных — абсолютно нет. Если уж совсем захочется каких-то возможностей, то всегда можно организировать транспиляцию (и тогда возможность ЯП работать с машинно-генерируемым скриптом тоже пригодится, и я это включаю в категорию "дружелюбность к минификации").
Прошу заметить, что я не считаю, что у вашего продукта есть какие-то недостатки. Естественно, у него есть своя ниша и он там занимает достойное положение. Просто немного не подходит под мои требования. Впрочем, т.к. я уже включил Lua и собираюсь включить Python, я могу включить и ваш ЯП, если есть интерес.
Как я понимаю, в Forth-е нельзя просто удалить новые строки (но, возможно, замена пробелами не сломает программу). Насчет компактности я согласен, но с другой стороны еще есть вопрос читабельности. Т.е. код пишется для человека, но потом минифицируется для машины. Компактный код на Forth-е не всегда будет достаточно читабельным.
Переносы строк — это просто один из примеров, конечно использование do/end тоже может сильно влиять. Более того, замена на пробел != полное удаление. В одном из моих проектов мы делали минификацию встроенного HTML, и простое удаление переносов позволило сэкономить 5% от суммарного размера исходных файлов.
Обновлено, 30% — полная минификация, удаление новых строк дало 5% (HTML был автогенерирован, так что там было достаточно много новых строк).
Lua не поддерживает минификацию исходных скриптов, т.к. чувствителен к переносу строк (да и в целом к форматированию, хотя конечно не так сильно как Python). Поэтому он был исключен из рассмотрения.
Что касается других языков, я не говорил, что они мне не понравились. Везде есть свои плюсы и минусы, но если сравнивать по возможностям при минимальном размере, то Chibi-Scheme в лидерах. Lua + LuaRocks — достаточно интересный вариант тоже, но с другой стороны, он уже включен в проект и все желающие могут сами с ним поиграться (хотя я думаю, все заинтересованные лица уже давно знают про Lua).
У меня очень богатый опыт внедрения Python (и написание расширений на Cython), и могу сразу сказать, что он имеет достаточно большой вклад в размер конечного бинарника (мы его встраивали в железку под урезанной версией Linux). Нам пришлось его сильно резать, включая изменения исходников (насколько я помню, он требовал pthread и эта библиотека не была нам доступна, но не уверен что современный Python имеет те же требования). К сожалению, Python не удовлетворяет нашим требованиям, но в принципе я могу его включить в проект, если это интересно.
Chiken требует сам себя, и я не нашел исходники bootstrap-версии, чтобы скомпилировать первичный компилятор. В принципе, я не против многофазовой сборки, но без первичной С-версии это не удовлетворяет требованию максимальной переносимости.
Я бы порекомендовал немного посмотреть в сторону от гигантов (Apple/Google) — есть реальная потребность в нормальных устройствах, которые не под полным контролем этих двух корпораций (по тем или иным причинам).
Второе, это Kai OS (https://www.kaiostech.com/explore/devices/): они набирают популярность в Индии (больше, чем iOS-устройств), Африке и Южной Америке. Большие корпорации потихоньку начинают выпускать приложения под них тоже.
Есть и другие ниши, например, Sailfish OS, но нормальной экосистемой это тяжело назвать.
Япония вообще не дешевая страна, но JR Pass очень полезен тем людям, кто хочет путешествовать между городами. Например, Токио-Осака — 167 USD (в одну сторону — www.govoyagin.com/pages/japan_shinkansen), JR Pass почти полностью покроет расходы, если ехать туда-обратно (и позволит сэкономить, если ехать еще дальше).
В Японию летают регулярные рейсы (S7) и сейчас стало намного проще получить визу (раньше нужен был поручитель из самой Японии или все оформлять через агентство), так что вполне нормально путешествовать самостоятельно. Гостиницы там достаточно дорогие, но к счастью, есть AirBnB (использовал в Токио и Осаке без каких-либо проблем). Лучше передвигаться общественным транспортом (очень хорошая сеть метро), т.к. машина обойдется недешево (может и не сама аренда, но многие трассы платные, плюс левостороннее движение может сыграть плохие шутки). В этом плане JR Pass может позволить сэкономить кучу денег (дает бесплатный проезд на шинкансене — высокоскоростном поезде, и бесплатный проезд по некоторым веткам — в основном, для перемещений за черту города), но замечу, что JR Pass надо оформлять дома, его нельзя получить в самой Японии, т.к. он действует только для иностранных граждан. Для перемещений внутри города есть тоже pass-ы, позволяющие неограниченно ездить (действуют посуточно).
Я бы еще добавил «Xing» — это пишут на знаках дорожного движения:
Пока не узнаешь, что это означает «CROSSing», долго чешешь голову, что за китайская тарабарщина (про показанное сокращение Ped на знаке я вообще молчу, иногда лучше вообще сокращения не использовать, чем сокращать вот так).
Типография — это все-таки немного другое. На Visual Basic наверное тоже можно написать систему управления банковскими транзакциями, но никто (я надеюсь?!) не делает этого. Правда, справедливости ради, отмечу, что HTML содержит все нужные теги (с точки зрения семантики, а не конечного оформления):
a — ссылки (соответственно, по ним формируется библиография, но конечно, нужна постобработка);
dfn — термины (соответственно, глоссарий);
предметный указатель — это использование того же тега a, но только в другом контексте — как якорь.
Ну и плюс к тому же, никто не мешает использовать собственные теги. Вопрос в использовании — когда уже есть готовые инструменты, незачем городить огород. Естественно, с чистого HTML книгу не сверстаешь, для этого есть другие, более подходящие форматы (и соответствующие инструменты).
Это уже зависит от конечного пользователя. Чтобы соответствовала семантика, можно просто применить стиль page-break-before для тега article. Но в целом: стили — CSS, контент — HTML.
Естественно, будет соблазн все понамешать, но это применимо для многих систем разметки: я видел, как и в LaTeX все в box-ы помещают, и в итоге код становится нечитабельным. А в том же Markdown уж слишком много ограничений и упрощений. В этом плане современный HTML с моей точки зрения — разумный компромисс (к тому же, это может быть просто промежуточный формат, как в моем случае).
Позвольте добавить свои пять копеек: в свое время я также долго перебирал, пробовал и использовал разные форматы, включая все вышеупомянутые. Для начала хотел бы напомнить про современный HTML — он имеет всю нужную семантику, например теги <section> и <article>. Явное преимущество — не нужно никаких дополнительных компиляций, простое обновление страницы достаточно. Из недостатков, конечно, отсутствие расширяемости и макроподстановок. Лично для меня главный недостаток — нельзя вставлять код с подсветкой синтаксиса (конечно, можно прикрутить highlight.js, но тогда уже можно забыть про конвертацию в PDF).
На данный момент я остановился на Scalateχ. Это весьма специфическое решение, но для моих нужд вполне подходит:
используются HTML-теги, не нужно изучать новый язык разметки;
полное расширение функциональности, например, вместо того, чтобы использовать встроенный Highlighter (основанный на highlight.js), я написал свой, с генерацией подсветки синтаксиса в процессе компиляции (основано на Highlight.java);
дополнительные фичи использования полноценной компиляции (например, проверка всех ссылок на работоспособность).
Если интересует, как это выглядит, вот ссылка на мою последнюю статью сделанную с помощью Scalateχ: Running arbitrary containers in LinuxKit (ссылка на исходник в конце статьи).
Да, думаю, надо вынести WSL в отдельный пункт. Для серверной разработки это не важно, но интересно в целом, насколько MS оптимизировала эту подсистему. Правда прошу заметить, что готовый Windows target не всегда означает, что была выполнена оптимизация (просто возможно скомпилировали с помощью mingw или cygwin, я сам так много раз делал когда портировал Linux библиотеки на Windows).
Под «чувствителен к новым строкам» я подразумеваю, что если полность удалить переносы строк, код перестанет работать. Замены на пробелы потенциально может работать, но насколько я понимаю, это особенность Lua (признаюсь, про которую я не знал).
DOM — это отдельная история, переносы строк на сам рендеринг HTML не влияют (по-крайней мере, наши тестеры и клиенты из Fortune 500 не жаловались, при всем разнообразии поддерживаемых браузеров включая IE6). Естественно, могут быть нюансы, но кросс-браузерная разработка давно заставила всех использовать только безопасное API с правильными селекторами (или просто использовать библиотеки, где это все учитывается).
Ruby чувствителен к переносам строк, так что его реализации были исключены из списка. Но т.к. я включил Lua и собираюсь включить Python, могу и включить mruby в список, если интересно. Но парсер и компилятор будут включены, т.к. необходимо позволять редактировать скрипты в любое время, при этом не требуя дополнительных инструментов.
Не все встраиваемые ЯП поддерживают байткод. Более того, возможно мы немного по-разному понимаем обфускацию. Для меня это возможность минимизировать и запутать код (вплоть до изменения хода выполнения кода путем вставления и реорганизации вызовов). Байткод не обязательно обфусцированный, хотя конечно, он компактнее исходного кода.
luac -l -l -pдает достаточно читабельное представление байткода Lua, хотя, конечно, я верю, что есть специальные обфускаторы. Однако все это весьма специфично для конкретных ЯП и если есть возможность обфусцировать на уровне исходного кода, это предпочтительнее для нас (но, естественно, может быть неудобно для других и им лучше использовать байткод и сторонние утилиты).Согласен, что неплохо было бы показать использование RAM. К сожалению, для "Hello world" примера числа будут весьма "бестолковые" тоже, т.к. только специфические конструкции или библиотеки могут вызывать большой расход памяти. Однако какие-то числа лучше чем вообще никакие, так что я добавлю это в тесты (https://gitlab.com/nuald-grp/embedded-langs-footprint/-/issues/4)
Под обычный Linux — некоторые ЯП достаточно экзотичны и имеют весьма скудную документацию. Собственно, некоторые я смог завести (чтобы подключить их в виде библиотеки) только изучив их исходный код, так что поддержка кросс-компиляции — это отдельная история, на которую у меня, к сожалению, нет времени.
Область применения — массовые потребительские устройства (включая бюджетные типа телефонов на KaiOS), микроконтроллеры и SoC у нас есть в планах, но далеких. Т.к. на некоторых устройствах (типа той же KaiOS) нет возможности исполнять нативный код, то одна из поддерживаемых target — это WASM, и засовывать туда 5 мегабайт пайтона сверху (которые надо будет пользователю скачать в условиях ограниченного хранилища и дорогого интернета) — это роскошь.
Насколько я вижу, Umka чувствителен к новым строкам, их нельзя просто удалить, так что требования к возможности минификации скриптов не удовлетворяются. Насчет предпочтений процедурных vs функциональных — абсолютно нет. Если уж совсем захочется каких-то возможностей, то всегда можно организировать транспиляцию (и тогда возможность ЯП работать с машинно-генерируемым скриптом тоже пригодится, и я это включаю в категорию "дружелюбность к минификации").
Прошу заметить, что я не считаю, что у вашего продукта есть какие-то недостатки. Естественно, у него есть своя ниша и он там занимает достойное положение. Просто немного не подходит под мои требования. Впрочем, т.к. я уже включил Lua и собираюсь включить Python, я могу включить и ваш ЯП, если есть интерес.
Как я понимаю, в Forth-е нельзя просто удалить новые строки (но, возможно, замена пробелами не сломает программу). Насчет компактности я согласен, но с другой стороны еще есть вопрос читабельности. Т.е. код пишется для человека, но потом минифицируется для машины. Компактный код на Forth-е не всегда будет достаточно читабельным.
Переносы строк — это просто один из примеров, конечно использование do/end тоже может сильно влиять. Более того, замена на пробел != полное удаление. В одном из моих проектов мы делали минификацию встроенного HTML, и простое удаление переносов позволило сэкономить 5% от суммарного размера исходных файлов.
Обновлено, 30% — полная минификация, удаление новых строк дало 5% (HTML был автогенерирован, так что там было достаточно много новых строк).
После обсуждения с коллегой решил включить Python/Cython и MicroPython тесты. Добавлю ответ, когда закончу.
Что касается других языков, я не говорил, что они мне не понравились. Везде есть свои плюсы и минусы, но если сравнивать по возможностям при минимальном размере, то Chibi-Scheme в лидерах. Lua + LuaRocks — достаточно интересный вариант тоже, но с другой стороны, он уже включен в проект и все желающие могут сами с ним поиграться (хотя я думаю, все заинтересованные лица уже давно знают про Lua).
Я бы порекомендовал немного посмотреть в сторону от гигантов (Apple/Google) — есть реальная потребность в нормальных устройствах, которые не под полным контролем этих двух корпораций (по тем или иным причинам).
Первое, это конечно, чистый GNU/Linux — модели этих телефонов могут иметь детские болезни, но в целом, энтузиасты их используют. Из известных я знаю: Librem 5 (https://puri.sm/products/librem-5/) и PinePhone (https://www.pine64.org/pinephone/).
Второе, это Kai OS (https://www.kaiostech.com/explore/devices/): они набирают популярность в Индии (больше, чем iOS-устройств), Африке и Южной Америке. Большие корпорации потихоньку начинают выпускать приложения под них тоже.
Есть и другие ниши, например, Sailfish OS, но нормальной экосистемой это тяжело назвать.
Пока не узнаешь, что это означает «CROSSing», долго чешешь голову, что за китайская тарабарщина (про показанное сокращение Ped на знаке я вообще молчу, иногда лучше вообще сокращения не использовать, чем сокращать вот так).
Типография — это все-таки немного другое. На Visual Basic наверное тоже можно написать систему управления банковскими транзакциями, но никто (я надеюсь?!) не делает этого. Правда, справедливости ради, отмечу, что HTML содержит все нужные теги (с точки зрения семантики, а не конечного оформления):
a— ссылки (соответственно, по ним формируется библиография, но конечно, нужна постобработка);dfn— термины (соответственно, глоссарий);a, но только в другом контексте — как якорь.Ну и плюс к тому же, никто не мешает использовать собственные теги. Вопрос в использовании — когда уже есть готовые инструменты, незачем городить огород. Естественно, с чистого HTML книгу не сверстаешь, для этого есть другие, более подходящие форматы (и соответствующие инструменты).
Это уже зависит от конечного пользователя. Чтобы соответствовала семантика, можно просто применить стиль
page-break-beforeдля тегаarticle. Но в целом: стили — CSS, контент — HTML.Естественно, будет соблазн все понамешать, но это применимо для многих систем разметки: я видел, как и в LaTeX все в box-ы помещают, и в итоге код становится нечитабельным. А в том же Markdown уж слишком много ограничений и упрощений. В этом плане современный HTML с моей точки зрения — разумный компромисс (к тому же, это может быть просто промежуточный формат, как в моем случае).
Позвольте добавить свои пять копеек: в свое время я также долго перебирал, пробовал и использовал разные форматы, включая все вышеупомянутые. Для начала хотел бы напомнить про современный HTML — он имеет всю нужную семантику, например теги
<section>и<article>. Явное преимущество — не нужно никаких дополнительных компиляций, простое обновление страницы достаточно. Из недостатков, конечно, отсутствие расширяемости и макроподстановок. Лично для меня главный недостаток — нельзя вставлять код с подсветкой синтаксиса (конечно, можно прикрутить highlight.js, но тогда уже можно забыть про конвертацию в PDF).На данный момент я остановился на Scalateχ. Это весьма специфическое решение, но для моих нужд вполне подходит:
Если интересует, как это выглядит, вот ссылка на мою последнюю статью сделанную с помощью Scalateχ: Running arbitrary containers in LinuxKit (ссылка на исходник в конце статьи).