Вышел (http://www.parrot.org/news/2010/parrot-2.10.0) релиз виртуальной машины для динамических языков программирования Parrot 2.10.0 (http://parrot.org/), в первую очередь используемой в проекте Rakudo Perl 6 (http://rakudo.org/). Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6,
Tcl (http://code.google.com/p/partcl/), Javascript (http://users.fulladsl.be/spb1622/pjs/), Ruby (http://cardinal2.rubyforge.org/), Lua, Scheme, PHP (http://wiki.github.com/bschmalhofer/pipp), Python (http://code.google.com/p/pynie/), APL (http://code.google.com/p/paraplegic/).
Начиная с данного выпуска для разработки Parrot теперь используется система управления исходными текстами Git и сервис GitHub (https://github.com/parrot/parrot). Скрипты конфигурации, сборки и тестирования модифицированы с целью улучшения поддержки Git. Подготовлено небольшое руководство (https://github.com/parrot/parrot/blob/master/docs/project/git...URL: http://www.parrot.org/news/2010/parrot-2.10.0
Новость: https://www.opennet.ru/opennews/art.shtml?num=28682
> Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, APL.У всех этих языков есть собственные виртуальные машины. Интересно, зачем может понадобиться прикручивать Пэррот, например, к Луа?
Наверное чтобы даже при зоопарке языков не было зоопарка виртуальных машин, все равно суть у всех одна.
> Наверное чтобы даже при зоопарке языков не было зоопарка виртуальных машин, все
> равно суть у всех одна.а почему не llvm например ?
Потому что он не рассчитан на динамические языки, AFAIK.
А это чё?
Python LLVM Unladen Swallow
Извратиться вездме можно. Вопрос в сложности и кривости решения
Суть-то одна, но, как говорится, дьявол кроется в деталях. Взять к примеру тот же Луа. Это легковесный язык для встроенных систем, который я могу легко прикрутить к своему приложению, увеличив при этом его размер не более чем на 200К. Одновременно я имею легковесную виртуальную машину, специально разработанную для этого языка. Спрашивается: нафига мне тащить туда Пэррот? Только ради того, чтобы "не было зоопарка виртуальных машин"?Нет, я не хочу таким образом сказать, что Пэррот не нужен. Мне действительно интересно узнать какие _практические_ цели можно преследовать, используя Пэррот с языками, для которых уже есть "родные" виртальные машины?
Ну хотите вы например из Perl заюзать библиотеку на Java. Компилите Java код в код виртуальной машины и все - изайте в перле. Это в идеале конечно.
см. Java VM с кучей языков, интегрирующихся между собой за счёт единой VM
Например:1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных на разных языках. При этом взаимодействие между разными частями из каждого кусочка будет, как с "родным".
2) Если вам надо прикрутить скриптинг к своей системе, то может иметь смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку сразу пачки языков.
> Например:
> 1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных
> на разных языках. При этом взаимодействие между разными частями из каждого
> кусочка будет, как с "родным".Я могу понять зачем использовать Си в связке с ассемблером или даже Делфи в связке с Си, но зачем использовать PHP в связке, например, с Scheme - выше моего понимания. Можно удивить всех, скрестив ежа с ужом, но практическая польза от этого мне не вполне ясна.
> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
> сразу пачки языков.Может быть. Но если я, допустим, пишу игруху, движок которой управляется скриптом на Луа, зачем мне нужна возможность сделать то же самое еще на десяти языках, когда мне достаточно реализовать это на _одном_ языке, но что бы оно работало? :)
Впрочем, не спорю. Тут говорили о возможности сделать общую для них все платформу. Любопытно было бы взглянуть на такую платформу...
Смотрите - Java VM. Но для динамических языков она не особо годится
>> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
>> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
>> сразу пачки языков.
>Может быть. Но если я, допустим, пишу игруху, движок которой управляется скриптом на Луа,
>зачем мне нужна возможность сделать то же самое еще на десяти языках, когда мне достаточно
>реализовать это на _одном_ языке, но что бы оно работало? :)В подобных случаях, конечно, поддержка многих языков мало что дает, а вот, если вы, например, делаете офисный пакет... Макросы там потенциально будет писать куча очень разных людей для совершенно различных задач, может поддержка многих языков там будет и полезна.
> Например:
> 1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных
> на разных языках. При этом взаимодействие между разными частями из каждого
> кусочка будет, как с "родным".На практике это выглядит так, приходишь к заказчику у которого зоопарк из тысячи другой машин (самая типичная ситуация), и вместо автоматической установки приложения начинается квест с ручной установкой нужных версий VM (узнали .net) и ручного разрешения зависимостей, и прыганьем с одной машины на другую, итого вместо минуты, уходит неделя.
> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
> сразу пачки языков.Ну да, а потом сидит "Вася эникейщик", матерится изучает одновремено lua,perl,python,php и пытается понять где у него приложение сбоит.
>[оверквотинг удален]
> На практике это выглядит так, приходишь к заказчику у которого зоопарк из
> тысячи другой машин (самая типичная ситуация), и вместо автоматической установки
> приложения начинается квест с ручной установкой нужных версий VM (узнали .net)
> и ручного разрешения зависимостей, и прыганьем с одной машины на другую,
> итого вместо минуты, уходит неделя.
>> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
>> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
>> сразу пачки языков.
> Ну да, а потом сидит "Вася эникейщик", матерится изучает одновремено lua,perl,python,php
> и пытается понять где у него приложение сбоит.В вашем варианте сидит Петя-эникейщик и думает: какого хрена я должен осваивать очередной луа и искать либы, чтобы написать логику этого поделия это поделие, хотя на питоне у меня всё есть...
Но проблема Васи не возникает, если есть вменяемая policy (в которой указывается: "в рамках нашей конторы расширения пишутся на таком-то языке, и их вход/выход специфицируется так и проверяется этак"), а проблема Пети решается только напрягом Пети.
Очевидно, что бы использовать общие библиотеки и друг-друга.
> Очевидно, что бы использовать общие библиотеки и друг-друга.Ну, может быть. Не совсем, правда, очевидны преимущества использования общих библиотек в данном случае. Все эти языки самодостаточны и используются в разных, слабо пересекающихся областях. Какая нужда может заставить, например, PHP, применяемый для сайтостроения, использовать код, написанный на Луа, применяемый во встроенных приложениях и игрухах? И для того и для другого языка есть масса собственных библиотек, которые покрывают нужды каждого из них с лихвой.
1) чтобы и дальше не плодить идентичные библитеки для разных языков
2) чтобы использовать существуюзщие библиотеки для того языка, для которого они есть
3) чтобы использовать в разных частях проекта языки, которые больше всего подходят к текущей задаче и не маяться с обеспечением взаимодействия.Сейчас самый яркий пример - Java VM, где можно часть кода писать на яве, часть - на Scala, к примеру. Parrot будет выгоден тем же, но в основном заточен под динамику/"скриптовые" языки, и dynamic typing, к примеру, в нём делается вполне прямо.
Хотя как по мне - развесистая VM подразумевает использование в больших проектах, а там скриптовым языкам не место ни разу.
> 1) чтобы и дальше не плодить идентичные библитеки для разных языковЧто это дает? Отбирает самостоятельное эволюционное развитие языков, но что дает?
> 2) чтобы использовать существуюзщие библиотеки для того языка, для которого они есть
Причем тут VM, язык использует свои библиотеки и без VM
> 3) чтобы использовать в разных частях проекта языки, которые больше всего подходят
> к текущей задаче и не маяться с обеспечением взаимодействия.Ох примерчик бы такого проекта, где бы было бы php,perl,python,lua и показан был выигрыш от такого взаимодействия.
> Сейчас самый яркий пример - Java VM, где можно часть кода писать
> на яве, часть - на Scala, к примеру. Parrot будет выгоден
> тем же, но в основном заточен под динамику/"скриптовые" языки, и dynamic
> typing, к примеру, в нём делается вполне прямо.Это не то, Scala без платформы Java не существует, здесь идет речь о самодостаточных языках занимающие давно и успешно свои ниши, и имеющие полный набор библиотек закрывающие любые самые изощренные потребности.
> Хотя как по мне - развесистая VM подразумевает использование в больших проектах,
> а там скриптовым языкам не место ни разу.Если проект действительно большой, то там без скриптования не обойдешься.
Коммерческая рентабельность обратно пропорциональна времени, потраченного на выпуск продукта. Разные языки имееют разные преимущества в разных предметных областях за счет синтаксиса и наличия библиотек. Поэтому, возможность комбинировать несколько языков - выгодна.
Уже и без меня ответили, но дополню - даёт возможность использовать ЧУЖИЕ библиотеки. То есть в lua использовать питоновские, к примеру. Получаем возможность отдельно выбирать язык, подходящий для данного случая, а отдельно - библиотеки, независимо от языка.А все языки сразу использовать никто и не предлагает. Выбирается тот набор, который нужен в данном проекте.
Скриптование в большом проекте - это одно. Оно используется для кастомизации, как правило. А глупости вроде написания графического редактора на Питоне - другое.
Чтобы довести общую платформу до совершенства, например.
>> Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, APL.
> У всех этих языков есть собственные виртуальные машины. Интересно, зачем может понадобиться
> прикручивать Пэррот, например, к Луа?http://www.dict.org/bin/Dict?Form=Dict2&Database=jargon&Quer...
Это немного шутка.
Серьезно. Про общие библиотеки уже сказали.
Именно этим и хорош мелкомягкий .NET.
Под UNIX-ы аналога по сути нет.
> Именно этим и хорош мелкомягкий .NET. Под UNIX-ы аналога по сути нет.http://www.mono-project.com/Main_Page - самая обыкновенная _родная_ UNIX-овая штука
и пожалуйста, не надо говорить что это не аналог
фактически это может быть даже заменой в частных случаях
>> Именно этим и хорош мелкомягкий .NET. Под UNIX-ы аналога по сути нет.
> http://www.mono-project.com/Main_Page - самая обыкновенная _родная_ UNIX-овая штука
> и пожалуйста, не надо говорить что это не аналогНу, во-первых, все-таки не аналог, а во-вторых, двигаясь
в этом направлении, UNIX-комьюнити ВСЕГДА будет позади M$
на несколько шагов, потому что источником идей и направления развития
является как бы Microsoft.
> Серьезно. Про общие библиотеки уже сказали.
> Именно этим и хорош мелкомягкий .NET.А что, взять к пример python, на ironpython уже можно пользоваться джангой, скайпи, твистет, кьютом, алхимией и еще парой тысяч библиотек/фреймворков python?
Или за исключением примерно одинакового синтаксиса с python ничего общего? И все равно все пишут на одном и том же C#, ну иногда ASP и VB, первое спецом для веба, второе для администрирования?
> Под UNIX-ы аналога по сути нет.
Не дай бог.
>> Серьезно. Про общие библиотеки уже сказали.
>> Именно этим и хорош мелкомягкий .NET.
> А что, взять к пример python, на ironpython уже
> можно пользоваться джангой, скайпи, твистет, кьютом, алхимией и еще парой тысяч
> библиотек/фреймворков python?
> Или за исключением примерно одинакового синтаксиса с python ничего общего? И все
> равно все пишут на одном и том же C#, ну
> иногда ASP и VB, первое спецом для веба, второе для администрирования?Даже если либы под платформу придётся писать заново - они всё равно будут доступня для всех языков на платформе.
>> Под UNIX-ы аналога по сути нет.
> Не дай бог.Для юниксов такая общая платформа - native + C API. Понимают все :-)
Мда, скомпилировал perl6 , запустил,
use strict;
use warnings;
он не понимает, нет такого модулядальше споткнулся о первые строки моего perl5 кода.
perl6 -e ' my $h = { default =>[5,34] }; print $h->{"default"} '
в такой строке он не понимает 2 вещи в синтаксисе - (default без кавычек, и ->)
мертворожденный он. Поддержали бы perl5 хоть на слабом уровне, можно было бы пользоватся.
3 года мечтал скомпилировать свой код в пасм/пир, но мечты разрушились, еще 5 лет ждать я не могу.
>[оверквотинг удален]
> он не понимает, нет такого модуля
> дальше споткнулся о первые строки моего perl5 кода.
> perl6 -e ' my $h = { default =>[5,34] }; print $h->{"default"}
> '
> в такой строке он не понимает 2 вещи в синтаксисе - (default
> без кавычек, и ->)
> мертворожденный он. Поддержали бы perl5 хоть на слабом уровне, можно было бы
> пользоватся.
> 3 года мечтал скомпилировать свой код в пасм/пир, но мечты разрушились, еще
> 5 лет ждать я не могу.Если бы кго назвали не Perl, а XYZ - вам было бы легче? Это другой язык, вообще-то.
> Если бы кго назвали не Perl, а XYZ - вам было бы легче? Это другой язык, вообще-то.Мне было бы легче если бы перл 5 развивали в эту сторону, cделали бы байткод для perl5 хоть в каком-то виде, хоть с какими-то ограничениями по конструкциям языка. Вместо этого в перл5 добавляют какие-то фичи, которые меня лично абсолютно не волнуют.
Новые конструкции языка не позволят сделать что-то принципиально новое. А вот байткод и библиотеки для сложных действий - позволят. Вместо этого упор на извращения с языком.
Я надеялся что с perl6 смогу не переписывая все на свете получить доступ к байткоду. А так мне лично perl6 не нужен, а perl5 не достаточен, хоть и очень нравится.
> Мне было бы легче если бы перл 5 развивали в эту сторону,Кто вам мешает, вместо Perl6 поверх Parrot, использовать Perl5 поверх Parrot ? См. https://github.com/jnthn/blizkost/
Спасибо!
скомпилировал, вроде работают скрипты,
только не понял как байткод сгенерить, документации по blizkost нема.
> Поддержали бы perl5 хоть на слабом уровне, можно было бы
> пользоватся.В гугле забанили, да?
> в такой строке он не понимает 2 вещи в синтаксисе - (default
> без кавычек, и ->)Выше не зря сказали, что это другой язык. Где-то читал (гугл тут поможет), что оператор "стрелка", он же "->", остутствует в перл6.
>> в такой строке он не понимает 2 вещи в синтаксисе - (default
>> без кавычек, и ->)
> Выше не зря сказали, что это другой язык. Где-то читал (гугл тут
> поможет), что оператор "стрелка", он же "->", остутствует в перл6.Вот из-за того что базовые конструкции изменили, нет возможности с небольшими переделками плавно перейти на этот новый язык ради вожделенной фичи. Таким образом новый язык мне и многим оказывается не нужен.
выгоды от изменения синтаксиса я не вижу никакой - одни убытки
> Вот из-за того что базовые конструкции изменили, нет возможности с небольшими переделками
> плавно перейти на этот новый язык ради вожделенной фичи. Таким образом
> новый язык мне и многим оказывается не нужен.
> выгоды от изменения синтаксиса я не вижу никакой - одни убыткиТут и не поспоришь.
Вот если бы попугай перл5 осиливал, это было гуд - и стары проекты работают, и CPAN, и perl6 под рукой. Прям сказка! =)