Комментарии 38
+ 2 * 2 2 == 8
* 2 + 2 2 == 6
очевидно, опечатка?
Скорее закономерный результат неудобной записи
+ 2 * 2 2 == (2 + 2) * 2 == 8
* 2 + 2 2 == (2 * 2) + 2 == 6
Т. е. приоритетов операций вообще нет, они выполняются в порядке записи.
+2*22 => + (2, ( * (2, 2))) => 2*2 + 2 = 6
*2 +22 => (2+2)*2 = 8
Сначала идет операция, потом два операнда, выполняется через стек (встретили вместо операнда операцию — начинаем выполнять ее).
Вы неверно скобки расставили, а должно быть так
- 2 2 2 == +(2,(2,2)) == +(2,4) == 8
- 2 + 2 2 == (2,+(2,2)) == (2,4) == 6
Что неверно, поэтому в статье действительно должно быть опечатка
Да, вы правы, это опечатка. Большое спасибо! Исправил в статье.
По поводу «неудачи» — вы взялись «вручную» тягаться с зарекомендовавшим себя профессиональным инструментом. Не удивительно, что с первого раза не удалось завалить мамонта. Уверен, в этом языке ещё есть места для оптимизаций.
Про байт-код благородный дон, очевидно, не читал?
А что касается ваших проблем, которые привели к необходимости введения типизации — вспомните про каррирование (currying). Или вообще почитайте про такой язык, как forth (тут всё наоборот, используется не прямая польская запись, как у вас, а обратная) — тоже для разбора аргументов функций не требуется знать количество аргументов.
И Perl тоже скриптовый язык, и весьма продуманный. Его изучение может быть полезным для создания таких минималистичных языков.
А результат оказался даже больше.
И вы даже не стали разбраться почему?
2 — у вас изначальный код на вашем ассемблере больше места занимает чем жаваскрипт. Напрашивается вывод, что сказывается бедность «стандартной библиотеки», что есть вещи которые в жс занимают мало, а у вас надо расписывать. Без внятного анализа того почему этот ассемблер проиграл языку высокого уровня бенчмарк выглядит неполным.
Очевидно, что любая оптимизация по набору тестовых примеров будет приводить к overfitness, на что можно ответить контрольной группой.
Причём видны пути как для лингвистической оптимизации (более выразительные языковые конструкции), так и для семантической (новые языковые конструкции, позволяющие описывать что-то «неизведанное»), так и для микрооптимизации (например, очевидно, что встроенная поддержка base64 для чисел и значений позволит нам экономить на строках), явно нужно больше локальных неявных переменных, например, с результатами предыдущего вычисления. Больше неявного поведения, которое можно использовать.
А что, если разработать язык, специально рассчитанный на минификацию?
*шепотом* байт-кооооод.
Тут ближе Форт по идеологии. Читаемый и сжимаемый, простой.
Это нормально что тут велосипед с треугольными колесами. Ненормально что обрывается на середине. Результат бенчмарка вообще не разобран.
Вы немножко не первый.
И это замечательно.
Тут ближе Форт по идеологии. Читаемый и сжимаемый, простой.
Согласен, стековая машина здесь к месту. Под байт-кодом я скорее имел в виду любую вирутальную машину, хоть стековую, нежели джава-подобие.
Несколько лет назад по работе пришлось писать транслятор нашего скриптового языка в язык стековой виртуальной машины (на основе польской записи, я не знал про Форт — обошел он меня стороной как-то), чтобы ускорить исполнение и уменьшить объем хранимого кода. Реализовал и выражения с разными типами данных, и вызов процедур/функций, и модульную компоновку с поздним связыванием.
Написать статью руки не дошли, да и не уверен, что это интересно.
Вся имевшаяся кривость системы заключалась в том, что проект изначально не предполагал файлового хранения, это должна была быть on the fly компиляция для ускорения проблемных участков. А вот когда потребовалось сохранять в файл, поскольку это был proof of concept для проверки возможного ускорения скриптов, а не система для реального использования, получилось достичь только ускорения, но не размера. Но лишь потому, что сохранение было достатчоно примитивным, а дальше проект не пошел.
'a' * 100
, что в байткоде окажется константа длинною в сотню букв 'a'.текст сжимается намного лучше бинарного кода
И это легко объяснить: текст даже в однобайтовых кодировках состоит из достаточно маленькой части доступных символов (навскидку, русскоязычный текст состоит из 90-100 различных символов из 256 доступных). Поэтому текстовая запись может быть сжата с сравнительно большим коэффициентом сжатия. А байт-коды, по идее, создаются так, чтобы иметь минимальную избыточность, и потому сжимаются плохо.
А по сути вопроса: писать на скриптовом языке и пытаться на уровне языка это сжать — то ещё извращение. Нечитаемое. Как по мне, лучше всё же разнести: синтаксический сахар для удобства программиста оставить на уровне языка, а сжатие возложить на компилятор, преобразующий нормальный язык в байт-код. Таким образом, и писать удобно, и сжимается всё хорошо.
Теперь по техническим мелочам. Ваши попытки преобразовать человеческую запись арифметики в короткую занимательны, но не проще ли использовать готовое решение (обратную польскую запись)? И программисты более-менее быстро поймут, так как запись широко известна, и минимизация так же достижима.
Вы как-то совсем по верхам текст затронули.
У символов есть своя частотность, что позволяет еще снизить разрядность, особенно частотность комбинаций (начиная от комбинаций читаемых символов, и заканчивая большими буквами которые редко бывают в середине слова).
Если мы говорим о программе а не Война и мир, то у нас есть относительно короткий набор слов (включая символьные, не текстовые) самого языка, который является константой, плюс тоже не очень большой словарик идентификаторов и прочих литералов специфичных самой программе. Словарик этот можно уже кодировать алгоритмом Хаффмана, чем еще чуть сократить размер.
У символов есть своя частотность, что позволяет еще снизить разрядность, особенно частотность комбинаций (начиная от комбинаций читаемых символов, и заканчивая большими буквами которые редко бывают в середине слова).
Всё равно есть нижний предел сжатого размера (посмотрите вики избыточность информации), который ни байт-код, ни сжатый текст преодолеть не могут, иначе будет потеря полезной для задачи информации. И сжатый идеальный байт-код к нему близок.
Кстати, этого нельзя сказать про сжатый текст. Все эти большие буквы и идентификаторы — лишние элементы, не несущие полезной для задачи информации. Следовательно, собственная информация в идеальном байт-коде меньше или равна собственной информации в некомпилированном тексте. Следовательно, и предельный сжатый идеальный байткод будет меньше, чем предельный сжатый текст. Осталось только выяснить, насколько избыточен байт-код. Если этот байт-код делается более-менее под подобные задачи, то, полагаю, почти наверное мы не сможем сжать текст и получить размер меньший, чем у сжатого байт-кода. В связи с чем идея сжимать исходник ценой читаемости ЯП вместо сжатия байт-кода мне представляется бесперспективной.
Я что-т не понял зачем битовые операции если из чисел — только с плавающей точкой
Язык программирования, рассчитанный на минификацию