Я разрабатывал вариант Smalltalk для удовольствия, и мне интересно, какой будет выборщик stackoverflowers, когда речь заходит о таргетинге на внешний сервер. Это были мои текущие соображения:
.NET, JVM: эти две виртуальные машины в основном предназначены для статически типизированных языков, и я предполагаю, что было бы довольно сложно настроить такой динамический язык, как smalltalk.
Python (как исходный код): Кажется, это самый простой способ. Также было бы лучше, если бы я мог испускать байт-код Python, но он не был хорошо документирован как другой VM AFAIK (вам нужно копать исходный код Python для подробностей!).
Самостоятельный интерпретатор: вопрос невозможен: -)
LLVM, NekoVM, Parrot - это другие варианты, которые я проверяю. Что бы вы взяли на себя?
Не снижайте .NET или JVM так быстро. Динамические языки разрабатываются для обоих (например, Groovy, JRuby, Jython на JVM, IronRuby, IronPython на .NET) и .NET набирает "DLR" - динамическое время выполнения. (Подробнее см. блог Джима Хьюгунина)
Я бы выбрал JVM, но в основном потому, что знаком с ним.
Объективные причины JVM: поддерживаются основные платформы, много библиотек и хорошая производительность (в рамках выбранных вами вариантов может быть лучшая производительность).
.Net работает лучше всего в Windows. Если вы выберете его, вы должны проверить на Mono, чтобы он был более нейтральным по отношению к платформе.
Python кажется хорошим выбором. Но я думаю, что для JVM доступно больше библиотек.
Parrot, по моему мнению, слишком свежо, ему нужно время, чтобы созреть. Но интересная альтернатива для будущего.
Другие варианты для меня новы, я посмотрю на них.
Parrot действительно классный, даже если они еще не отправили "настоящий" код. Но поскольку проект просто для удовольствия, это не должно вас остановить: D.
Поскольку вы пытаетесь реализовать Smalltalk, почему бы не рассмотреть одну из виртуальных виртуальных машин с небольшим количеством символов для Ruby, например YARV или даже rubinius. Оба они малоподвижны и нацелены на высокую производительность. YARV станет новой стандартной Ruby VM.
Одним из преимуществ использования Parrot является то, что он поставляется с множеством примеров языков, включая вариант Smalltalk под названием ChitChat. Таким образом, вы можете использовать это как ссылку, чтобы увидеть, как кто-то другой реализовал аналогичный язык в Parrot.
Возможно, вам стоит взглянуть на PyPy - в то время как этот проект существует для реализации языка Python в (подмножество ) Python, подход, который они используют, позволяет использовать несколько фронтов и несколько back-end (включая CLR, JVM, LLVM, C и даже Smalltalk и JavaScript, я думаю). Например, работа над JIT была выполнена с использованием Prolog в качестве внешнего интерфейса и CLR в качестве внутреннего. Таким образом, вы можете присоединиться к партии, чтобы реализовать Smalltalk, а позже обнаружите, что вы также помогли кому-то реализовать Prolog, не зная об этом...: -)
Фактор (http://factorcode.org/) может предложить некоторые полезные функции для этого.
Если это для удовольствия, почему бы не начать с кода для Squeak, который является открытым исходным кодом, и изменить его. У Smalltalk должно быть небольшое время выполнения, и ваш небольшой забавный вариант может начинаться с среды бутстрапа от скрипа, который почти микроскопичен и построен оттуда.
Моя большая вещь против .NET и JVM - огромные размеры. Посмотрите, насколько маленькая среда исполнения "операционная система для малого уровня" соответствует Squeak.
Не должны ли забавные проекты быть, ну...... FUN? Squeak - это много вещей, деловое не является одним из них, но FUN... определенно.
JVM как первый выбор. Это обеспечит широкую библиотечную поддержку с первого дня. Посмотрите, как это принесло пользу Clojure.
Кроме того, LLVM может быть интересным выбором, но я не уверен, как это "доказано", так как я не могу иметь зрелую языковую реализацию с бэкэндом LLVM.
Я бы избежал .NET. Это затруднит сбор и поддержку вокруг вашего нового языка, и вам это понадобится в ближайшее время. Кроме того, он не является межплатформенным.
Что бы вы ни выбрали, вы многое узнаете, сделав это.
JVM более стабилен, хорошо документирован и, как правило, менее вероятно, является движущей целью, чем .Net Кроме того, вы с большей вероятностью найдете людей, которые могут помочь вам, если вы отправитесь с открытым исходным кодом. С .Net талантом действительно мало, и большинство из них работают в Microsoft, поэтому у них вряд ли найдется время, чтобы помочь.
.NET как DLR, которая теперь находится поверх CLR для динамического языка.
Сделайте это на .Net, ведь вы хотите сделать это для удовольствия. Поэтому сделайте это немного сложнее. И любые выводы могут быть сообщены Microsoft, для улучшения DLR и поддерживаемых им языков.
Если вы посмотрите на использование .Net, взгляните в "Красивый код" - там будет очерк о том, как делать динамический код gen на .Net CLR.
Определенно .Net, использующая время выполнения динамического языка. Ваши объекты будут использоваться непосредственно пользователями С# и V.Net к моменту завершения (вы собираетесь отправить что-то?: -)
В частности, цель работает под уменьшенной .Net в SilverLight, поэтому вы получаете самую последнюю версию веб-браузера.