Каково различие между Duby и Juby и почему мне был бы нужен любой из них?

I suspect that at some point I may be able to prototype a piece of code in Plain Ol' Dynamic Ruby and, when it works but needs to be significantly faster, port it, with relatively minor levels of pain, to a close relation that will compile to optimised JITted Java bytecode. Or quite possibly IronRuby#.NET, Sapphire or something else.

Graphic manipulation, heavy mathematics, AI, stuff like that. I suspect I'd have some fun doing that...

Как и в случае с языками, мы не создаем их, потому что они нам «нужны». Люди создают их по любой причине, и если они нам не понадобятся, они останутся непонятными.

Есть много малоизвестных языков; с ними весело играть, но, вероятно, это не то, на чем вы бы хотели заниматься настоящим проектом.

Я отвечу на вопросы в произвольном порядке, начиная с самого простого:

2. Не мог бы кто-нибудь пояснить, что это за различие?

Duby статически типизирован, Surinx (это последнее название того, что на короткое время называлось ] Juby ) динамически типизирован. Это уже все.

На самом деле, есть одна маленькая деталь, как следствие этого: синтаксис Surinx - это строгое подмножество синтаксиса Ruby , то есть каждый синтаксически допустимый Программа Surinx также является синтаксически допустимой программой Ruby . Duby OTOH является почти синтаксическим подмножеством, за исключением его обязательных аннотаций типа параметра метода:

def foo(bar => Integer, baz => String) => Array
  # ...
end

That ' запрещены в Ruby .

3. Зачем нам нужен (нужен!) Другой язык, связанный с Ruby ?

Во-первых: кроме синтаксического сходства, эти языки никоим образом не связаны с Ruby .

Итак, почему Чарльз Оливер Наттер создал Дуби ? Он является ведущим разработчиком реализации JRuby Ruby , которая является реализацией языка программирования Ruby для JVM. Как и большинство реализаций Ruby , он написан на доминирующем языке программирования базовой платформы: MRI , YARV и tinyrb реализованы 100 % на C, MacRuby в основном на C с небольшим количеством Objective-C, Ruby. NET и IronRuby 100% в C #, HotRuby в ECMAScript , Red Sun в ActionScript, Cardinal ] в PIR и NQP и так далее. (Единственными реализациями Ruby , которые содержат значительное количество кода Ruby , являются Rubinius (около 70% Ruby , 30% C ++) и MagLev (неизвестное количество Ruby и Smalltalk ).) И, естественно, реализованы XRuby и JRuby 100 % в Java.

А вот что забавно, Чарли пришел к Ruby , потому что ему не нравилась его повседневная работа - разработка Java. И теперь он по-прежнему целый день пишет код Java! Конечно, ему это не нравится, и поэтому он искал другой язык программирования, на котором можно было бы реализовать ядро ​​ JRuby . Одним из вариантов, конечно же, было бы просто написать все это на Ruby , но с метациркульными реализациями обычно наступает момент убывающей отдачи, когда реализации вырождаются в академическую мастурбацию. Безусловно, имеет смысл переписать библиотеки, опережающий компилятор (фактически , который уже делается ) и некоторые основные классы в Ruby , но некоторые части ядро движка лучше написано на чем-то более близком к модели исполнения самой JVM.

Чарли рассматривал доступные варианты: Scala , Groovy , ] Fan , Clojure , Хорошие , но у всех них был существенный недостаток: довольно большая среда выполнения языка. Размер среды выполнения JRuby уже представляет собой большую проблему с точки зрения потребления памяти и задержки запуска (особенно по сравнению с MRI или YARV ) и тем более, если вы фактически включите в свои измерения саму JVM), и переписать ее на языке, который добавляет к этому весу собственную среду выполнения , - это просто запрет. К сожалению, не существовало языка программирования, который удовлетворял бы двум основным критериям , которые искал Чарли : отсутствие среды выполнения и компиляция в байт-код JVM, который по крайней мере так же эффективен, как эквивалентный Java.

Поэтому он решил создать свой собственный. Причина, по которой он решил использовать синтаксис, подобный Ruby , на самом деле довольно проста: ему не нужно было писать для этого парсер, Duby просто использует уже существующий парсер JRuby с одной незначительной модификацией для поддержки аннотаций типов параметров методов. (На самом деле ему также нравится синтаксис Ruby , который, конечно, также был важным фактором.)

Как вы знаете, синтаксис на самом деле является наименее важной частью языка программирования. (Его нерелевантность не всегда очевидна из количества споров по этому поводу , но это только потому, что синтаксис - единственное, о чем вы можете спорить, не имея на самом деле понимания того, о чем вы говорите о.) Гораздо важнее синтаксиса система типов и семантика оценки. А вот и хитрость: Duby тоже не имеет! Он только имеет синтаксис! Это' как паразит: он просто «заимствует» систему типов и семантику у своей базовой платформы. Это означает, что в JVM система типов Duby является системой типов Java, а семантика Duby - семантикой Java. . Другими словами: Duby вообще не является языком программирования , скорее это «просто» альтернативный синтаксис для Java.

Это означает, что нет никакого отображения , нет накладных расходов на преобразование и нет разницы в скорости между Duby и Java. А это означает, что внутреннее устройство JRuby может быть записано на Duby без потери каких-либо функций.

Итак, это Duby .

По порядку. чтобы объяснить Суринкс , я ' Сначала я отвечу на ваш первый вопрос:

1. Что такое invokedynamic и почему Duby «нужен товарищ по игре»?

invokedynamic - это, в частности, новый байт-код, который будет добавлен в 3-е издание спецификации JVM и это будет выпущено в JDK7. Однако в более общем смысле invokedynamic обычно используется в качестве замены для обозначения целого набора функций, из которых фактический invokedynamic байт-код является только одним, которые в настоящее время разрабатываются под эгидой JSR-292 «Поддержка динамически типизированных языков на платформе Java» . И даже в более общем плане имя invokedynamic используется как прозвище для общего изменения стратегии как в Sun, так и в JCP в целом, чтобы превратить платформу Java в языковую платформу общего назначения для всех видов языков.

Конкретная цель JSR-292 (именно на это Чарли намекает в своем сообщении в блоге) - ускорить отправку динамических методов - в действительности, почти так же быстро, как static отправка на Java, по крайней мере, в лучшем случае.

Surinx - это язык программирования с динамической типизацией, который в основном делает то же самое, что и Duby : например, Duby , он также имеет только синтаксис, как Duby , он также использует систему типов Java. Но в отличие от Duby , он не использует семантику вызова методов Java , вместо этого он использует семантику вызова методов invokedynamic s . IOW: он динамически типизирован и использует динамическую отправку.

Итак, это Surinx .

Теперь я могу ответить на вторую половину вашего третьего вопроса:

3. Зачем нам (нужны!) […] Еще два языка, связанных с Ruby?

Я уже отвечал для Duby , вот ответ для Surinx : это то, что Groovy должен был быть - легким (фактически нулевым ) динамическим выразительным языком сценариев для JVM. Кроме того, в настоящее время это самый простой способ поиграть с внутренней работой invokedynamic . (Текущие снимки JRuby 1. 4 также поддерживают его, но это намного более сложный проект.)

Две вещи, которые я упустил: Duby фактически использует вывод типа локальной переменной, поэтому, в отличие от Java, вам нужно только объявить типы параметров метода, но все внутри метода будет определяться типом.

И, во-вторых, и Duby , и Surinx фактически не привязаны к JVM. Поскольку они просто крадут свою семантику и системы типов у базовой платформы, их можно перенести практически куда угодно, где есть приблизительное отображение синтаксиса Ruby на концепции платформы. В голове я мог представить портирование Duby на C, C ++, Objective-C (iPhone, кто угодно?), D , CLI и ActionScript, а также порты Surinx на DLR , Smalltalk , Parrot , ECMAScript , Python , Perl , PHP и Objectice-C. Фактически, уже есть начало C порта Duby .

Только что наткнулся на это, прямо от самого Чарльза , который частично отвечает на вопрос (о различии между ними):

Что подводит меня к будущему Суринкс. Это даже проще, чем будущее Дуби: двое сольются. Как Я работал и над Суринксом, и над Дуби, мне стало очевидно, что по сути, они на одном языке с различными механизмами отправки и требования к объявлению типа. А также поскольку Дуби мог легко лечить нетипизированные или выражения с динамической типизацией как требуя динамического вызова, есть нет причин, по которым Суринкс не должен быть ассимилирована как особенность Duby.