Какая разница между Duby и Juby и зачем мне это нужно?

Ответ 1

Mirah (ранее Duby) существует, потому что статическая типизация может привести к значительному повышению производительности с помощью Java/Hotspot. Суринкс (ранее Juby) - это одно и то же, за исключением того, что он также использует новую функцию производительности, которая приходит в JDK7, чтобы еще больше повысить производительность.

Функция производительности обычно называется "invokedynamic", и хорошее описание доступно на блоке Nutter.

Ответ 2

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

2. Может ли кто-нибудь более подробно рассказать о том, что такое различие?

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

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

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

Это незаконно в Ruby.

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

Прежде всего: кроме синтаксического сходства, эти языки никоим образом не являются формами или формой, относящимися к Ruby.

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

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

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

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

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

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

Итак, Duby.

Чтобы объяснить Surinx, я сначала отвечу на ваш первый вопрос:

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

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

Конкретная цель JSR-292 (это то, что Charlie ссылается на его сообщение в блоге), заключается в том, чтобы ускорить динамический метод - действительно, почти так же быстро, как статическая отправка в 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, С++, Objective-C (iPhone, кто-нибудь?), D, CLI и ActionScript и порты Surinx в DLR, Smalltalk, Parrot, ECMAScript, Python, Perl, PHP и Objectice-C. На самом деле уже есть начало C-порта Duby.

Ответ 3

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

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

Ответ 4

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

Там много неясных языков; они с удовольствием играют, но, вероятно, не то, что вы хотели бы сделать в реальном проекте.

Ответ 5

Я подозреваю, что в какой-то момент я смогу прототипировать фрагмент кода в Plain Ol 'Dynamic Ruby и, когда он работает, но должен быть значительно быстрее, поместите его с относительно небольшими уровнями боли, чтобы закрыть которое будет скомпилировано для оптимизации JITted Java байт-кода. Или, вполне возможно, IronRuby #.NET, Sapphire или что-то еще.

Графические манипуляции, тяжелая математика, ИИ, такие вещи. Я подозреваю, что мне будет интересно это сделать...