LUA и Python замечательно подходят для скриптов, единственный неприятный момент у меня был — создание биндингов. Используя API можно сделать шустрые биндинги, но с большей чреватостью ошибками (для среднестатистичекого прогера), чем скажем luabind/boost.python. тока эти два монстра заставляют компилер падать на колени из-за кучи раскрываемых шаблонов. Я где-то год назад начал писать свой компилер (для прокачки), синтаксис которого содран с C# и внесены некоторые фишки с С+, но код генерится в машинные команды (на данный момент в LLVM-asm) и нет сборщика мусора ( рефкаунт для классов — аналогичен boost::shared_ptr<T> ). И самое главное — биндинги в нем генерируются автоматически (только для С++)!

Кому интересно — смореть сюда http://code.google.com/p/bamelg/
После инсталляции увидите примерно здесь c:\Program Files (x86)\MindStrike Solutions\Bamelg\ проект с примером использования этого компилера.
Для запуска самого компилера нужен .NET 2.0 и выше. А для запуска использующего биндинги приложения — .NET не нужен(!)

Осуждения от ярых фанатов тех или иных языков предлагаю оставить при себе и предлагаю послушать мнения людей, которые хотели бы заюзать у себя какой-либо скриптовый язык, но все что они видели по каким-либо причинам чем-то им не нравится.

На данный момент есть:
* Базовые типы (byte/sbyte, short/ushort etc...), производные (ссылки, указатели, фиксированные массивы, динамические массивы) типы с фиксированным байт-ордером (short_littleendian/short_bigendian .. etc)
* Работа со строками
* Рефлексия, атрибуты
* Итераторы ( как в C# 2.0 )
* Шаблоны, с возможностью полной специализации
* Вычисления на этапе компиляции
* Генерация биндингов для С++

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

Очень интересно.
А нельзя ли примеры в Wiki занести ?

Здравствуйте, gesman,

Исходники компилятора не выкладываете? Компилятор на C# написан? Сколько строк примерно?

В вики обновлять не удобно — а тут закинул, шлёп и готово.

DM>Исходники компилятора не выкладываете? Компилятор на C# написан? Сколько строк примерно?
Примерно 108.000 LoC (в нем просто есть нереализованный пока задел на будущее (ибо сперва планировалось Phoenix SDK заюзать для бэкэнда, ибо с помощью него — можно и асм. но это такое @#$%^ще оказалось, что просто ппц, вспоминаю как кошмарный сон ), например, полный(!) парсер x86 асма с чеками параметров и кодогенерацией. нереализованный — изза некоторых gcc-style 'особеностей' LLVM ). Я просто не вижу смысла писать на чем-то другом, мне же быстрый и качественный результат нужен. тут — за 2.0 сек (на Intel Q9450, после ngen'а) он успевает скомпилировать 500Кб сырцов, вывести в файлы 4.1Мб промежуточного кода ( все стадии оптимизации\трансформации, для дебага ), а затем еще 7.3Мб LLVM-ассемблера и после всего этого сохранить 1.5Мб бинарь (такой большой изза debug-инфы + неоптимизированных метаданных, которых ОЧЕНЬ много).

Сырцы выкладывать не вижу смысла, ибо все задачи которые можно закодить — способен быстро выполнить самостоятельно (да и для тестирования\использования сырцы не нужны)
А всякое зло — такое как отвязать LLVM и сделать на шарпе собственный убер-оптимизационный фреймворк (например Phoenix SDK реверснуть) врятли кто-то из современных избалованных программистов поможет сделать

PS. в инсталлере есть сырцы классовой библиотеки ( которая шибко .NETовскую напоминает ), по ним сразу понятно, как языком пользоваться более продвинуто, чем в юнит-тестах.

~~Новый скриптовый язык для игр с генерируемыми биндингами~~
А есть ли какие бенчмарки в сравнение м lua?

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

M>~~Новый скриптовый язык для игр с генерируемыми биндингами~~
M>А есть ли какие бенчмарки в сравнение м lua?

Разумеется нет, и не будет, оно и так должно быть понятно ибо за низкоуровневую оптимизацию отвечает LLVM, а благодаря статической типизации он может до смерти заоптимизировать полученный код (т.е. получить более быстрый чем проJITенный LUA/Python ).
+ есть дополнительные оптимизационные плюшки, вроде инлайнинга ( помечаешь атрибутом [Inline] метод — а ЛЛВМ его инлайнит ).
язык-то собственно далеко не скриптовый и весьма продвинутый, НО на нем можно писать и скрипты, и регенерирующиеся биндинги позволяют его быстро и эффективно встраивать в С++ код.

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

G>На данный момент есть:
G>* Базовые типы (byte/sbyte, short/ushort etc...), производные (ссылки, указатели, фиксированные массивы, динамические массивы) типы с фиксированным байт-ордером (short_littleendian/short_bigendian .. etc)
G>* Работа со строками
G>* Рефлексия, атрибуты
G>* Итераторы ( как в C# 2.0 )
G>* Шаблоны, с возможностью полной специализации
G>* Вычисления на этапе компиляции
G>* Генерация биндингов для С++

А почему ты называешь свой язык скриптовым? У тебя есть eval() функция?

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

[Skip]

Может вам посмотреть на Squirrel ?

Re[2]: ~~Новый скриптовый язык для игр с генерируемыми бинди
Вы очень пероцениваете LLVM

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

M>Вы очень пероцениваете LLVM

Нет, не переоцениваю. API у них не отточенный, хотя много лет прошло, просто видимо профессионалы руку не прикладывали (да и не приложат =) )... Далее — куча мемликов в статиках, которые они не могут обнаружить, ибо пользуются валгриндом, вместо того чтоб денёк потратить под дебагом, скажем, в Visual Studio 2010. Для пущей уверенности еще и девпартнером разок прогнаться.
НО! Апишкой достаточно приятно пользоваться, в отличие, от скажем, GCC деревьев. Куча ассертов проставлена — тока наглючил\недописал\схалявил где-то, сразу по башке, это тоже жирный +.
Есть правда нюансы.. мне асм не сынтегрировать с LLVM, ибо у них в АПИ — есть только поддержка асмовых строк, оформленных в GCC-style. да кстати, GCCшка на вход гимпл принимать не умеет, а LLVMка свое IR умеет читать из файла, что есть большой плюс при дебаге. далее — не умеет собирать .exe/.dll/.dylib/.so и пр. (в clang'е это делается хаком — LLVMом генерится асм, по нему `gas` проходится, и по полученному — линкером, так что они немного гонят на офсайте )

Кстати, если сравнивать с Phoenix SDK, то последний — кал позорный. Не потому что MS, а потому что MS Research, там программистов адекватных видимо нету Дикий апи, который интуитивно вообще ни разу не понятен ( LLVMовский — тут же с ходу во все въезжаешь, что куда как и зачем ). тоже на офсайте круто все про него написано, а потом начинаешь узнавать приколы:
0. Не компонентно-ориентированная логика, т.е. совершенно не .NET стайле раскидана логика(и логика ли?=)). Среди разрабов этого проекта в MS Researh я видел индусов, что как бе намекаэ
1. *.exe шники не собрать. только интрументировать(!) можно. т.е. компилер должен уже с путой болванкой идти. допустим...
2. *.pdb шники, халявный дебаг... хрен! очень жёстко крошатся, если начать их активно генерить.
3. ОЧЕНЬ МАЛО ассертов. генеришь, генеришь код, и когда даешь команду скомпилить IR, где-то внутри эгзипшен (или несколько вложенных).
4. нет сырцов. учитываю ЛЮТУЮ глючность — они просто жизненно необходимы. Как сырцы для коммерческого игро-движка Torque =) Reflector слабо спасает, ибо у них CLI/C++ там ( а то и Managed вовсе).
5. 2х летняя давность последнего доступного CTP.
6. нет чтения из сырцов как в LLVM, т.е. отлаживать кодеген было жутко тяжело (ибо начинал компилер как раз с феникса). дампить умеет, а читать — фиг.
7. разные опкоды не поддерживаются, например 'Alloca'
8. дичайшее потребление памяти, т.е. пацаны, видимо, не обладают достаточными навыками программирования на .NET платформе.

Еще какие-то приколы были, но уже не помню, но кто хочет — может попробовать отыскать
Итог — LLVM это вовсе не так уж и плохо.

Здравствуйте, Danchik, Вы писали:
D>Может вам посмотреть на Squirrel ?

Я видел. И питон, и луа, и квейк-с и GameMonkey =) но посмотрите внимательно на примеры использования и промежуточные stage-файлы у компилера, и станет совсем понятно чем он от всех них отличается.

Здравствуйте, c-smile, Вы писали:
CS>А почему ты называешь свой язык скриптовым? У тебя есть eval() функция?

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

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

CS>>А почему ты называешь свой язык скриптовым? У тебя есть eval() функция?

G>Кхе-кхе, потому что на нем можно писать в т.ч. скрипты для игр (цитирую 'скриптовый язык для игр' ). Я его не называл динамическим, наоборот, писал что у него статическая типизация (см. выше).

"Скрипты" для игр можно писать и на C/C++ и на том-же D. Да и вообще на всем что шевелится.

Родовым признаком скриптового языка является наличие eval() т.е. runtime содержит полноценный compiler.
У тебя оно есть такое? Собственно я это хотел спросить.

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

CS>Родовым признаком скриптового языка является наличие eval() т.е. runtime содержит полноценный compiler.

Очень неоднозначный критерий ИМХО. В C# 4.0 есть eval(), а "полноценный compiler" входит в рантайм с самой первой версии. В то же время мне кажется, что C# — это не скриптовый язык.

Возможно, скрипт — это язык, который исполняется в особом sandbox-е, у него нет каких-либо средств, входящих ли в рантайм или в сам язык, которые подходили бы для решения универсальных задач, и sandbox нужно расширять специальным образом, чтобы добавить к скрипту функциональность, необходимую в конкретном случае. Как например, BOM/DOM для джава-скрипт. И, с другой стороны, WSH для него же.

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

ВВ>Возможно, скрипт — это язык, который исполняется в особом sandbox-е, у него нет каких-либо средств, входящих ли в рантайм или в сам язык, которые подходили бы для решения универсальных задач, и sandbox нужно расширять специальным образом, чтобы добавить к скрипту функциональность, необходимую в конкретном случае. Как например, BOM/DOM для джава-скрипт. И, с другой стороны, WSH для него же.

Тогда ни питон ни руби ни перл не скрипты.

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

FR>Тогда ни питон ни руби ни перл не скрипты.

С последними двумя знаком очень слабо, а вот по поводу питона у меня действительно большое сомнение, что это скриптовый язык. По-моему это обычный динамический интерпретируемый язык. Достаточно широкого применения, насколько позволяют его особенности.

Вообще если есть лучшее определение того, что из себя представляет скрипт, то буду рад выслушать.

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

ВВ>С последними двумя знаком очень слабо, а вот по поводу питона у меня действительно большое сомнение, что это скриптовый язык. По-моему это обычный динамический интерпретируемый язык. Достаточно широкого применения, насколько позволяют его особенности.

Я тоже так считаю.

ВВ>Вообще если есть лучшее определение того, что из себя представляет скрипт, то буду рад выслушать.

Нет, тема слишком расплывчатая

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

ВВ>Вообще если есть лучшее определение того, что из себя представляет скрипт, то буду рад выслушать.

"Scripts" are distinct from the core code of the application, which is usually written in a different language, and are often created or at least modified by the end-user.
...
Scripting languages are nearly always embedded in the applications they control

http://en.wikipedia.org/wiki/Scripting_language

Т.е. возможность быть modified by the end-user (что включает в себя наличие compiler и eval на борту) есть то что отличает скрипты от всего остального.

C/C++/D можно тоже использовать как скрипт но в этом случае приложение должно включать в себя дистрибуцию означенных компиляторов и runtime библиотек. То же самое и с .NET. Например VB не есть scripting language, а VBS уже есть скрипт т.к. VBS engine самодостаточен — и компилятор и runtime в одном флаконе и ему не требуется ни VB runtime ни .NET.

В принципе для скриптинга есть еще один критерий: поддержка interactive режима когда ввод строки с RETURN в конце вызывает непосредственную компиляцию/исполненние обновляя текущее состояние VM. Но это есть следствие наличие eval().

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

CS>C/C++/D можно тоже использовать как скрипт но в этом случае приложение должно включать в себя дистрибуцию означенных компиляторов и runtime библиотек. То же самое и с .NET. Например VB не есть scripting language, а VBS уже есть скрипт т.к. VBS engine самодостаточен — и компилятор и runtime в одном флаконе и ему не требуется ни VB runtime ни .NET.

CS>В принципе для скриптинга есть еще один критерий: поддержка interactive режима когда ввод строки с RETURN в конце вызывает непосредственную компиляцию/исполненние обновляя текущее состояние VM. Но это есть следствие наличие eval().

Ну у Хаскеля и Окамла, которые вполне классические компиляторы есть вполне нормальный REPL, притом у Окамла его можно спокойно вкомпилировать и в конечное приложение.

Re[4]: ~~Новый скриптовый язык для игр с генерируемыми бинди
Я думаю вы не правы, хотя бы посмотреть на печальный опыт гугла по встраиванию LLVM в питон (получися большой пук ). Там приросты в производительности прото копеечные, а так как в гугле вряд ли работают дураки(что исключает кокое то неправильное привинчивание LLVM), то LLVM вообщем то бе (много шума из ничего)

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

M>Re[4]: ~~Новый скриптовый язык для игр с генерируемыми бинди
M>Я думаю вы не правы, хотя бы посмотреть на печальный опыт гугла по встраиванию LLVM в питон (получися большой пук ). Там приросты в производительности прото копеечные, а так как в гугле вряд ли работают дураки(что исключает кокое то неправильное привинчивание LLVM), то LLVM вообщем то бе (много шума из ничего)

LLVM просто заточен на компиляцию статически типизированных языков. А Питон таковым не является, поэтому его компилировать во что-то более быстрое, чем сам интерпретатор, очень сложно. Даже MS'овский IronPython, который через DLR какбэ компилится в IL и дальше, как-то не блещет...