Один из разработчиков JRuby, Charles Nutter, делится своими впечатлениями об участии в конференции Lang.NET 2008. О том, как он воспринимает идею DLR в .NET с позиции разработчика JRuby, о том, что из DLR можно было бы взять в Java, о том, нужна и будет ли многоязычная JVM...

Lang.NET 2008: Day 1 Thoughts

PS. Сразу предупреждаю: много английский букв

Здравствуйте, eao197, Вы писали:

E>Один из разработчиков JRuby, Charles Nutter, делится своими впечатлениями об участии в конференции Lang.NET 2008. О том, как он воспринимает идею DLR в .NET с позиции разработчика JRuby, о том, что из DLR можно было бы взять в Java, о том, нужна и будет ли многоязычная JVM...

E>Lang.NET 2008: Day 1 Thoughts

E>PS. Сразу предупреждаю: много английский букв

Английский не учил (никогда и нигде). Можно вкратце по пунктам что и как?

Здравствуйте, iZEN, Вы писали:

E>>Один из разработчиков JRuby, Charles Nutter, делится своими впечатлениями об участии в конференции Lang.NET 2008. О том, как он воспринимает идею DLR в .NET с позиции разработчика JRuby, о том, что из DLR можно было бы взять в Java, о том, нужна и будет ли многоязычная JVM...

E>>Lang.NET 2008: Day 1 Thoughts

E>>PS. Сразу предупреждаю: много английский букв

ZEN>Английский не учил (никогда и нигде). Можно вкратце по пунктам что и как?

Пересказывать чужое мнение -- задача неблагодарная, может получиться как в анекдоте о том, что Карузо не такой уж и великий певец. Но я бы суммировал впечатления Наттера так:

Oн был поражен тем, что LINQ-инструкции преобразуются в обычные инструкции CLR. Как если бы спрятанный за LINQ запросом код был написан программистом вручную (вроде как это Хальсенберг продемонстрировал в своем выступлении). И Наттер понял, что в JVM возможен такой же фокус -- можно расширить язык Java не переделывая набора команд JVM. Для него это было откровением.

Ему было интересно послушать о DLR и он понял, что это и зачем это в .NET. Что-то из DLR ему показалось уместным иметь и в JVM. Но, в отличии от .NET, в JVM изначально был сделан сильный упор на динамическую оптимизацию и даже деоптимизацию и в этом JVM (по мнению Наттера) впереди .NET. А недостающие для поддержки динамических языков фичи для JVM сейчас проталкиваются в JVM через JSR-292.

Ну и он пришел к следующим трем выводам:
1. Что создание мульти-языковой JVM должно быть самым большим приоритетом. Не только для Sun-а, но и для всего Java сообщества. Что Sun уже делает определенные шаги к этому в виде открытия Java, инициирования проектов JVM Language Runtime и Multi-Language VM.
2. Но это дело не только Sun-а но и других игроков на рынке Java. И не только крупный игроков, но и каждого использующего Java/JVM (что-то типа лозунка "А ты записался добровольцем?!").
3. Ну и нужно решится на "JVM reborn". Хотя Java уже достаточно старая и будет много сопротивления от разных людей, в том числе и тех, кто думает, что Титаник никогда не утонет. Но если не прилагать усилий к изменению и оновлению JVM, то можно оказаться в ситуации, когда все будут говорить, что она уже просто умерла. И что сам Наттер будет прилагать усилия, чтобы такого печального итога не было.

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

Здравствуйте, eao197, Вы писали:

E>В общем, для меня это еще одно подтверждение того, что изначально Sun заняла выигрышную позицию, выдавая Java за единственную правильную платформу. Но затем времена изменились и MS находится в лучшей ситуации -- .NET изначально расчитан на интеграцию разных языков. И чтобы не проиграть Java нужно меняться.

Большое спасибо за тезисы.

Моё мнение.

1. Яву как язык (не платформу) "испортили" в Java 5.0 с появлением обобщённых типов (да, они экономят время написания кода) и аннотаций вместо того, чтобы, например, из String'а сделать мутабельный класс.

2. Включать в ядро поддержку других языков вряд ли стоит, так как усложняется JVM, инфраструктура и средства тестирования/отладки. Кроме того, нужно заботиться об обратной совместимости с унаследованным кодом.

3. Переработка языка должна вестись в сторону упрощения, а не усложнения семантики. Дополнительные фичи должны обеспечиваться библиотечным кодом. Иначе получится ещё один монстр типа PL/M.

Здравствуйте, iZEN, Вы писали:

ZEN>Моё мнение.

ZEN>1. Яву как язык (не платформу) "испортили" в Java 5.0 с появлением обобщённых типов (да, они экономят время написания кода) и аннотаций вместо того, чтобы, например, из String'а сделать мутабельный класс.

Ну следуюя такой логике, я мог бы сказать, что Ява -- она была изначально испорченным C++. Да, она экономит время написания кода (временами ), но все это вместо того, чтобы сделать JDK и SWing библиотеками для C++ -- вот тогда бы не пришлось никакие Boost-ы выдумывать

ZEN>2. Включать в ядро поддержку других языков вряд ли стоит, так как усложняется JVM, инфраструктура и средства тестирования/отладки. Кроме того, нужно заботиться об обратной совместимости с унаследованным кодом.

Как раз если не переделывать набор инструкций JVM, то JVM окажется не конкурентоспособной, т.к. для динамических языков будут лишние тормоза при вызове динамически определяемых методов, а для функциональных языков еще какая-нибудь бяка найдется (вроде отсутствия средств поддержки хвостовой рекурсии и пр.).

Тем более, что потеря совместимости на уровне байт кода между старой и новой JVM не так уж страшна. Компиляторы Java могут иметь переключатели, которые будут определять в какой байт-код выполнять трансляцию. А унаследованные и сторонние разработки для которых нет исходников, можно пускать на старой JVM. Или же делать трансляцию одного байт-кода в другой.

ZEN>3. Переработка языка должна вестись в сторону упрощения, а не усложнения семантики. Дополнительные фичи должны обеспечиваться библиотечным кодом. Иначе получится ещё один монстр типа PL/M.

Еще только получится? Может пора уже говорить в прошедшем времени?
Как раз нарушение совместимости на уровне исходников при изменении языка гораздо более серьезный шаг, чем нарушение совместимости на уровне байт-кода. Так что основные промахи языка так в Java и остануться. Надежда есть только на новые языки на платформе JVM, вроде Scala или Nice.

Здравствуйте, eao197, Вы писали:

E>Ну и он пришел к следующим трем выводам:
E>1. Что создание мульти-языковой JVM должно быть самым большим приоритетом. Не только для Sun-а, но и для всего Java сообщества. Что Sun уже делает определенные шаги к этому в виде открытия Java, инициирования проектов JVM Language Runtime и Multi-Language VM.
E>2. Но это дело не только Sun-а но и других игроков на рынке Java. И не только крупный игроков, но и каждого использующего Java/JVM (что-то типа лозунка "А ты записался добровольцем?!").
E>3. Ну и нужно решится на "JVM reborn". Хотя Java уже достаточно старая и будет много сопротивления от разных людей, в том числе и тех, кто думает, что Титаник никогда не утонет. Но если не прилагать усилий к изменению и оновлению JVM, то можно оказаться в ситуации, когда все будут говорить, что она уже просто умерла. И что сам Наттер будет прилагать усилия, чтобы такого печального итога не было.

Интересно, что в LINQ в частности и в .NET 3.5 в целом нет ни грамма изменений в самой VM. Так что этот орел просто наслушался лозунгов и не смог понять что за ними стоит. Впрочем, возможно и не хотел понимать. Ему то, как разработчику ДжиРуби нужно как раз рантайм хакать под динамику. Вот он о своем, наболевшем и поет.

Здравствуйте, VladD2, Вы писали:

E>>Ну и он пришел к следующим трем выводам:
E>>1. Что создание мульти-языковой JVM должно быть самым большим приоритетом. Не только для Sun-а, но и для всего Java сообщества. Что Sun уже делает определенные шаги к этому в виде открытия Java, инициирования проектов JVM Language Runtime и Multi-Language VM.
E>>2. Но это дело не только Sun-а но и других игроков на рынке Java. И не только крупный игроков, но и каждого использующего Java/JVM (что-то типа лозунка "А ты записался добровольцем?!").
E>>3. Ну и нужно решится на "JVM reborn". Хотя Java уже достаточно старая и будет много сопротивления от разных людей, в том числе и тех, кто думает, что Титаник никогда не утонет. Но если не прилагать усилий к изменению и оновлению JVM, то можно оказаться в ситуации, когда все будут говорить, что она уже просто умерла. И что сам Наттер будет прилагать усилия, чтобы такого печального итога не было.

VD>Интересно, что в LINQ в частности и в .NET 3.5 в целом нет ни грамма изменений в самой VM. Так что этот орел просто наслушался лозунгов и не смог понять что за ними стоит. Впрочем, возможно и не хотел понимать. Ему то, как разработчику ДжиРуби нужно как раз рантайм хакать под динамику. Вот он о своем, наболевшем и поет.

Он заботится о поддержке динамических языков, а не о LINQ для Java. Может быть LINQ в Java так же удалось бы встроить без изменения JVM. А вот для поддержки динамических языков в .NET MS приходится развивать DLR. Так что, боюсь, те, кто делают поддержку Ruby или Python для .NET поют о похожих вещах.

Здравствуйте, eao197, Вы писали:

E>Тем более, что потеря совместимости на уровне байт кода между старой и новой JVM не так уж страшна. Компиляторы Java могут иметь переключатели, которые будут определять в какой байт-код выполнять трансляцию. А унаследованные и сторонние разработки для которых нет исходников, можно пускать на старой JVM. Или же делать трансляцию одного байт-кода в другой.

Более того — у java 1.5 обратной совместимости по байткоду нет.

Здравствуйте, eao197, Вы писали:

E>Он заботится о поддержке динамических языков, а не о LINQ для Java. Может быть LINQ в Java так же удалось бы встроить без изменения JVM. А вот для поддержки динамических языков в .NET MS приходится развивать DLR. Так что, боюсь, те, кто делают поддержку Ruby или Python для .NET поют о похожих вещах.

Видишь ли, DLR вообще то тоже работает на стандартной CLR. Будет ли для нужд динамических языков меняться CLR — неизвестно, и, в любом случае, это будет нескоро.

Здравствуйте, AndrewVK, Вы писали:
AVK>Видишь ли, DLR вообще то тоже работает на стандартной CLR. Будет ли для нужд динамических языков меняться CLR — неизвестно, и, в любом случае, это будет нескоро.

Ну так и автор блога о том же говорит: к JVM надо "сбоку прилепить" аналог DLR (в основном речь идет об expression trees), причем этот явовякий аналог можно сделать проще дотнетовского DLR, т.к. дотнетовский DLR решает в т.ч. вопросы динамической оптимизации. А с динамической оптимизацией JVM (в отличие от JIT) справляется неплохо — надо только суметь этой возможностью JVM воспользоваться.

And that's particularly heartening to me, since it means the vast majority of these (хотя тут речь скорее о linq и type inference) features could be added to Java or supported by JVM languages without modifying the JVM itself. Whether they're features we want to add is a separate discussion.
<...skip...>
So again, we're working at a level well above the VM itself. That means the power of expression trees could definitely be put into the hands of JVM language developers without any modifications to existing JVMs.
<...skip...>
The answer is that certain parts of the DLR are definitely attractive, and they may be worth implementing to ease the pain of JVM language implementation or at least reduce the barrier to entry. But there's a large set of DLR features we simply don't need to create if we can find a way to open up the JVM's existing ability to optimize dynamically...

И тут встает важная по мнению автора проблема: нужно "стандартизировать" AST:

While a language-generic expression tree is certainly a very appealing goal, one that lowers the entry cost of language implementation considerably, it always seemed like a too-lofty ideal. Of course it's impossible to predict what features future languages might decide to add, so can we reasonably expect to provide a set of expression nodes that can represent those languages? Won't we be endlessly forced to extend that set of node types for each new language that comes along? And if to alleviate such pain we are given hooks to call back to custom language-specific code for cases where the DLR falls down, doesn't that eliminate the advantage we hoped to gain in the first place?
<...skip...>
If it were reasonable for us to expose JRuby's AST as a "one true AST" to represent all languages, we'd be able to support a similar set of features, adding syntax to Java to generate Ruby ASTs at runtime and capabilities for manipulating, executing, and compiling those ASTs. Naturally, we'd never try to make an argument that the JRuby AST can even come close to approximating a set of low-level features "all languages" might need to support, but hopefully you see the parallel.

собственно, автору не очень нравится подход MS с его "one true AST", но деваться-то некуда.

I'll make no secret about my skepticism here, but I've seen a couple things today that make me far more optimistic about the utility of language-agnostic expression trees.

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну так и автор блога о том же говорит: к JVM надо "сбоку прилепить" аналог DLR (в основном речь идет об expression trees)

Expression trees это часть LINQ, а не DLR (да оно, к тому же, еще и строго типизировано). В DLR входит стандартизованная система типов для динамических языков (чтобы динамические языки были между собой совместимы) и набор хелперов для решения типовых задач динамических языков при помощи динамической кодогенерации.

MC>, причем этот явовякий аналог можно сделать проще дотнетовского DLR, т.к. дотнетовский DLR решает в т.ч. вопросы динамической оптимизации. А с динамической оптимизацией JVM (в отличие от JIT) справляется неплохо — надо только суметь этой возможностью JVM воспользоваться.

Это разные вещи. JVM все равно требует строго типизированный байткод, а именно в этом проблема при реализации динамических языков. И джавовская динамическая оптимизация (hotspot видимо имелся ввиду) этому горю ничем не поможет, потому что работает уже по типизированному коду.
MC>[q]
MC>And that's particularly heartening to me, since it means the vast majority of these (хотя тут речь скорее о linq и type inference) features could be added to Java or supported by JVM languages without modifying the JVM itself. Whether they're features we want to add is a separate discussion.

LINQ и DLR ничего общего не имеют. LINQ, безусловно, прекрасно реализуем в рамках JVM и Java. Единственное, что могло бы пригодится LINQ от рантайма — поддержка анаонимных типов, но динамическим языкам эта фича все равно без надобности.

MC>И тут встает важная по мнению автора проблема: нужно "стандартизировать" AST:

Это, увы, невозможно.

MC>собственно, автору не очень нравится подход MS с его "one true AST", но деваться-то некуда.

Хейлсберг, между прочим, в ответ на прямой вопрос о доступе к AST шарпа ответил, что это крайне сложно сделать как раз потому что для разных задач нужно разное AST (и это в рамках одного языка!). Видимо, автор что то не так понял.

Ага... Спасибо за разъяснение. Я тут кстати откопал заброшенный блог о DLR и IronPython. Вдруг кому интересно будет:
http://blogs.msdn.com/hugunin/

Здравствуйте, AndrewVK, Вы писали:

AVK>LINQ и DLR ничего общего не имеют. LINQ, безусловно, прекрасно реализуем в рамках JVM и Java. Единственное, что могло бы пригодится LINQ от рантайма — поддержка анаонимных типов, но динамическим языкам эта фича все равно без надобности.
Я так понял, что это неимение не есть генеральная линия партии.
Судя по http://blogs.msdn.com/hugunin/, парни изначально полагали, что "DLR AST" будут совсем другими, чем "Linq AST" aka Expression trees:

Because our trees were untyped, we didn't believe that they shared much in common with the always strongly typed expression trees in C# 3 and we went about designing these trees as something completely independent.

Но, c течением времени, они обнаружили совпадения, не менее удивительные, чем внешнее сходство дельфина с акулой:

Pretty soon we realized that the nodes that we were adding mapped directly onto the statically typed and bound expression tree nodes from C# 3.

В связи с этим, генеральная линия партии дала резкий крен:

If you look at the code you'll notice that in fact we only support a subset of the C# 3 nodes and that our APIs don't exactly match the existing expression trees. This is simply an artifact of our late realization that these trees were so closely related and we're now in the process of reconciling our trees with the existing expression trees.

(выделение моё)
MC>>"стандартизировать" AST:
AVK>Это, увы, невозможно.
Теоретически — да, но есть намек на практическую реализуемость концепции.

Здравствуйте, eao197, Вы писали:

E>Тем более, что потеря совместимости на уровне байт кода между старой и новой JVM не так уж страшна. Компиляторы Java могут иметь переключатели, которые будут определять в какой байт-код выполнять трансляцию. А унаследованные и сторонние разработки для которых нет исходников, можно пускать на старой JVM. Или же делать трансляцию одного байт-кода в другой.

Компиляторы Java имеют переключатели командной строки "-source" и "-target":
http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html

-source release
    Specifies the version of source code accepted. The following values for release are allowed:

    1.3
        The compiler does not support assertions, generics, or other language features introduced after JDK 1.3. 
    1.4
        The compiler accepts code containing assertions, which were introduced in JDK 1.4. 
    1.5
        The compiler accepts code containing generics and other language features introduced in JDK 5. 
    5
        Synonym for 1.5. 
    1.6
        This is the default value. No language changes were introduced in Java SE 6. However, encoding errors in source files are now reported as errors, instead of warnings, as previously. 
    6
        Synonym for 1.6.

-target version
    Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1 1.2 1.3 1.4 1.5 (also 5) and 1.6 (also 6).

    The default for -target depends on the value of -source:
        * If -source is not specified, the value of -target is 1.6
        * If -source is 1.2, the value of -target is 1.4
        * If -source is 1.3, the value of -target is 1.4
        * For all other values of -source, the value of -target is the value of -source.

А при исполнении байткода какой-либо версии на последней JVM правила меняются на лету.

Здравствуйте, eao197, Вы писали:

E>Он заботится о поддержке динамических языков, а не о LINQ для Java. Может быть LINQ в Java так же удалось бы встроить без изменения JVM.

Ага. И что же он смог на этой конфе найти?

E>А вот для поддержки динамических языков в .NET MS приходится развивать DLR.

Это ты из пальца высосал.

Здравствуйте, AndrewVK, Вы писали:

Со всем вышесказанным согласен кроме:

AVK>Хейлсберг, между прочим, в ответ на прямой вопрос о доступе к AST шарпа ответил, что это крайне сложно сделать как раз потому что для разных задач нужно разное AST (и это в рамках одного языка!). Видимо, автор что то не так понял.

Это мягко говоря его сугубо частное мнение. Иметь одно АСТ на все случаи жизни можно. В Немерле так и есть.

Здравствуйте, VladD2, Вы писали:

E>>А вот для поддержки динамических языков в .NET MS приходится развивать DLR.

VD>Это ты из пальца высосал.

А зачем тогда это самое DLR?

Здравствуйте, VladD2, Вы писали:

VD>Это мягко говоря его сугубо частное мнение.

Это мнение человека, определяющего политику корпорации Microsoft в вопросах развития основных языков платформы .NET.

VD> Иметь одно АСТ на все случаи жизни можно. В Немерле так и есть.

Помнится, в одном немерловом компиляторе несколько разновидностей деревьев при обработке используется. Если уж стандартизировать что то подобное, то лучше описать событийную или последовательную модель, навроде SAX или XmlReader + некие достаточно абстрактные алгоритмы ресолвинга типов и т.п. А уж деревья каждый сам себе построит, это несложно.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А зачем тогда это самое DLR?

Чтобы
а) упростить работу разработчикам "динамических" языков
б) обеспечить способность взаимодействия между реализациями

Здравствуйте, Andrei F., Вы писали:

AF>а) упростить работу разработчикам "динамических" языков
AF>б) обеспечить способность взаимодействия между реализациями

Я не пойму ты с Владом

Автор: VladD2
Дата: 31.01.08

согласен или нет? Как по мне эти твои высказывания вполне опровергает его мнение.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я не пойму ты с Владом

Автор: VladD2
Дата: 31.01.08

согласен или нет? Как по мне эти твои высказывания вполне опровергает его мнение.

Почему это опровергает? Насколько можно понять из этих данных, DLR — это просто надстройка над CLR, которая нужна, чтобы исключить разброд и шатания в среде разработчиков динамических языков.

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну так и автор блога о том же говорит: к JVM надо "сбоку прилепить" аналог DLR (в основном речь идет об expression trees)...

kawa/gnu/expr ?

Хочешь — с типами. Не хочешь — не надо.

Здравствуйте, Andrei F., Вы писали:
AF>Почему это опровергает? Насколько можно понять из этих данных, DLR — это просто надстройка над CLR, которая нужна, чтобы исключить разброд и шатания в среде разработчиков динамических языков.
Ну вот лично мне интересно, удастся ли добиться нужного эффекта без вмешательства в CLR. DLR должно на что-то опираться. Уж явно не на голый Emit — он будет приводить к утечке памяти. Как вариант, можно опереться на LCG, но я лично не уверен, что этого хватит на все случаи. В частности, мне не вполне понятно, как будет проверяться CAS у динамических методов.

Здравствуйте, AndrewVK, Вы писали:

E>>Тем более, что потеря совместимости на уровне байт кода между старой и новой JVM не так уж страшна. Компиляторы Java могут иметь переключатели, которые будут определять в какой байт-код выполнять трансляцию. А унаследованные и сторонние разработки для которых нет исходников, можно пускать на старой JVM. Или же делать трансляцию одного байт-кода в другой.
AVK>Более того — у java 1.5 обратной совместимости по байткоду нет.
Самое смешное, что особо непонятно зачем они так сделали. В большинстве случаев все различие только в заголовке класса — если его поменять, то все работает и на прежних версиях JVM.

Здравствуйте, AndrewVK, Вы писали:

VD>>Это мягко говоря его сугубо частное мнение.

AVK>Это мнение человека, определяющего политику корпорации Microsoft в вопросах развития основных языков платформы .NET.

Это уже твое частное мнение. А я вот вижу что этот направляющий не может изменение в рантайм проблить, даже если очнь надо.
В прочем, будь он хоть богом в МС мнение его от этого более правильным не становится. Ибо уже давно опровергнуто практикой.

VD>> Иметь одно АСТ на все случаи жизни можно. В Немерле так и есть.

AVK>Помнится, в одном немерловом компиляторе несколько разновидностей деревьев при обработке используется.

Два. Типизированное и не типизированное.

AVK> Если уж стандартизировать что то подобное, то лучше описать событийную или последовательную модель, навроде SAX или XmlReader + некие достаточно абстрактные алгоритмы ресолвинга типов и т.п. А уж деревья каждый сам себе построит, это несложно.

Вот это как раз неверное решение. Это как раз парсеры у языков разные. А вот АСТ можно и общее залудить. Проблема будет только в том, что оно должно быть рассчитано на самый мощьный язык в семействе. Так АСТ Шарпа или Васика будет принципиально недостаточно для хранения данных Немерла или С++.

Здравствуйте, VladD2, Вы писали:

AVK>>Это мнение человека, определяющего политику корпорации Microsoft в вопросах развития основных языков платформы .NET.

VD>Это уже твое частное мнение.

Моя фамилия Хейлсберг?

VD> А я вот вижу что этот направляющий не может изменение в рантайм проблить, даже если очнь надо.

Рантайм это не язык. Это во-первых. А во-вторых это тебе очень надо. А мне лично не особо. Ему, возможно, тоже.

VD>В прочем, будь он хоть богом в МС мнение его от этого более правильным не становится.

А его никто богом и не называет. Просто мнение. Как и твое.

AVK>>Помнится, в одном немерловом компиляторе несколько разновидностей деревьев при обработке используется.

VD>Два. Типизированное и не типизированное.

Ну вот видишь.

AVK>> Если уж стандартизировать что то подобное, то лучше описать событийную или последовательную модель, навроде SAX или XmlReader + некие достаточно абстрактные алгоритмы ресолвинга типов и т.п. А уж деревья каждый сам себе построит, это несложно.

VD>Вот это как раз неверное решение.

А по мне, так оченьв верное.

VD> Это как раз парсеры у языков разные.

А парсеры никто одинаковыми делать не предлагает. Или ты предлагаешь делать много парсеров для одного языка?

VD> А вот АСТ можно и общее залудить.

Можно, но ненужно. У меня в текущем проекте есть несколько языковых инструментов, и AST у каждого из них довольно специфично (а в некоторых случаях, как и в Немерле, их несколько для одного языка, заточенных под разные задачи).

Здравствуйте, eao197, Вы писали:

E>Один из разработчиков JRuby, Charles Nutter, делится своими впечатлениями об участии в конференции Lang.NET 2008. О том, как он воспринимает идею DLR в .NET с позиции разработчика JRuby, о том, что из DLR можно было бы взять в Java, о том, нужна и будет ли многоязычная JVM...

E>Lang.NET 2008: Day 1 Thoughts

Думаю, эта ссылка будет в тему: Da Vinci Machine Project

the Da Vinci Machine
a multi-language renaissance
for the Java™ Virtual Machine architecture

Mission

We are extending the JVM with first-class architectural support for languages other than Java, especially dynamic languages. This project will prototype a number of extensions to the JVM, so that it can run non-Java languages efficiently, with a performance level comparable to that of Java itself.

Our emphasis is on completing the existing bytecode and execution architecture with general purpose extensions, as opposed to a new feature for just one language, or adjoining an unrelated new execution model.

We want the new languages to co-exist gracefully with Java in the JVM, and to benefit (like Java) from its powerful and mature technologies.

We are looking to remove “pain points” already observed by implementors of successful or influential languages, as opposed to attempting more speculative work on unproven features or niche languages.

Major sub-projects include dynamic invocation and extensions to class loading. There is a large number of more speculative, lower-priority sub-projects. These are included in hopes that someone in the community will become excited with us at the prospects of a more dynamic JVM, to the point of sharing in its creation.

Здравствуйте, eao197, Вы писали:

E>Один из разработчиков JRuby, Charles Nutter, делится своими впечатлениями об участии в конференции Lang.NET 2008. О том, как он воспринимает идею DLR в .NET с позиции разработчика JRuby, о том, что из DLR можно было бы взять в Java, о том, нужна и будет ли многоязычная JVM...

E>Lang.NET 2008: Day 1 Thoughts

И еще одна новость, связанная с этими событиями. Побывав на конференции Lang.NET 2008 разработчик Ruby.NET решил прекратить участие в развитии своего проекта. Он считает, что DLR и IronRuby приведут к появлению гораздо лучшей реализации Ruby для .NET-а, чем в можно было бы надеятся в рамках Ruby.NET.

Подробнее: The future of Ruby.NET.

Еще один интересный блог-пост одного из разработчиков JRuby о некоторых проблемах реализации динамического языка Ruby на JVM:

JRuby and the Permanent Generation

В конце поста есть несколько ссылок, которые могут заинтересовать JRuby пользователей.

Здравствуйте, AndrewVK, Вы писали:

AVK>Будет ли для нужд динамических языков меняться CLR — неизвестно,

Таки да, кое что прояснилось — CLR будет в этом направлении меняться (в рантайме появится возможность динамического биндинга методов во время выполнения). Причем поддержка этого биндинга, скорее всего, будет и в шарпе.

Здравствуйте, iZEN, Вы писали:

ZEN>... вместо того, чтобы, например, из String'а сделать мутабельный класс.

Зачем?

Здравствуйте, AndrewVK, Вы писали:

AVK>Таки да, кое что прояснилось — CLR будет в этом направлении меняться (в рантайме появится возможность динамического биндинга методов во время выполнения). Причем поддержка этого биндинга, скорее всего, будет и в шарпе.
Речь о ключевом слове dynamic?
Чем это будет отличаться от reflection с точки зрения рантайма?

Здравствуйте, EvilChild, Вы писали:

EC>Речь о ключевом слове dynamic?

ХЗ что там в итоге будет.

EC>Чем это будет отличаться от reflection с точки зрения рантайма?

Скоростью.