Как быстро интерпретируемый язык должен быть сегодня?

Скорость важна, да, но обычно языки сценариев используются в тех случаях, когда скорость выполнения перевешивается затратами на ввод-вывод, так что это еще не конец. все, все. Гораздо важнее структура и особенности языка. Сначала поработайте над ними, а затем разберитесь со скоростью выполнения.

Тем не менее, я думаю, что в конечном итоге, если вы хотите создать новый язык общего назначения, вы пойдете по пути, по которому идет большинство из них, а именно предварительной компиляции в байт-код и JIT-компиляции во время выполнения. .

Так быстро, насколько это необходимо разработчику.

Нет никаких правил, просто нужно кормить.

Я не понимаю, зачем кому-то писать интерпретатор в наши дни. Есть две отличные виртуальные машины: CLR (+ DLR) и JVM. Нетривиально написать компилятор для любой среды выполнения, и тогда вы получите преимущество взаимодействия с огромным количеством существующего кода, плюс фантастические стандартные библиотеки, плюс JIT-компиляторы, которые сделают скорость вашего языка не проблемой для многих case (конечно, быстрее, чем любой интерпретатор).

Если вы хотите создать язык, который будет больше, чем просто любопытство для разработчиков, это определенно правильный путь в наши дни.

Лично я выбрал бы язык с отличным API. Если вы посмотрите на Lua, 90% кода Lua C, который пишут люди, является просто шаблонным. Если бы появился более медленный язык с гораздо лучшим C ++ API, я бы мгновенно переключился на него.

В конечном счете, «преждевременная оптимизация - корень всех зол», то есть вашему языку нужны отличные функции, И он должен быть быстрым. Нет ничего хорошего в быстроте, если он так же удобен, как ассемблер, когда пользователю нужно реализовать операционную систему.

1. Да
2. Это зависит от того, как предполагается использовать ваш язык.
3. Нет. Нет причин, по которым нельзя разработать быстрый читаемый язык, который вряд ли мог бы служить оправданием для игнорирования производительности.

Вы действительно должны ответить на эти вопросы для себя, исходя из целей ваших экспериментов.

Нет только ответа на такой вопрос. Ни один ответ не может относиться ко всем возможным целям и аудиториям.

Вероятно, самым большим фактором, который следует учитывать, является то, собираетесь ли вы, чтобы язык был в основном автономным или использовался в сочетании с чем-то другим. Если вы напишете что-то вроде Lua, предназначенное в первую очередь (или исключительно) для использования вместе с чем-то другим (C в случае Lua), то скорость становится гораздо менее актуальной и интересной. Если вы пишете что-то, что используется в основном само по себе, скорость начинает иметь гораздо большее значение.

Скорость всегда важна, если только ваш язык не бесполезен. Если он полезен, люди будут пытаться использовать его для выполнения тяжелых задач, и если он не падает при попытке, это всегда лучше. Это не значит, что стоит оптимизировать для скорости (это зависит от ваших целей), и это не говорит вам как (например, быстрая компиляция в байткод против изменения способа доступа к высокоуровневой библиотеке, написанной на C, чтобы интерпретатору приходилось делать еще меньше работы перед ее вызовом).

Оптимальный баланс между скоростью и абстракцией зависит от типов решаемых задач. Компьютерное время обычно менее ценно, чем время людей, но и то, и другое чего-то стоит. Если полностью пренебречь компьютерным временем, то все равно полезно рассмотреть, сколько времени будет занято всего людьми, которые работают и ждут результатов; пользователи языка должны быть максимально довольны, когда общее время кодирования + выполнения минимизировано. (Взвесьте зарплаты кодеров и пользователей, если вы хотите сделать максимально сильное деловое обоснование.)

Из-за двух предыдущих пунктов я думаю, что для интерпретируемых языков плохой идеей является полное игнорирование производительности. Конечно, если язык сам является экспериментальным, вы должны спросить себя, сколько времени вы хотите потратить на работу над производительностью вместо добавления функций. Вполне возможно, что первоначальная реализация будет ужасно медленной, если она будет постепенно оптимизироваться по мере того, как язык будет использоваться чаще и для более сложных задач. JavaScript является отличным примером этого.