Фраза о Лиспе...

Конкретных деталей не подскажу (давно было - во времена 1.5), но это возможно. Более того, это одно из штатных применений Питона. Python embedding называется. Если вкратце - делашь либу, у которой снаружи - нужный тебе Сишный интерфейс, а внутри - обращение к Python C API, через который вызывается Питон-код. Может быть, такое можно сделать через SWIG (не уверен).

Э-э-э. Мы часом "большие" и "сложные" не путаем?

> + смартпойнтеры

В стандарте С++ есть? В свое время (лет пять назад) пришлось писать свои собственные, ибо сторонние обладали странными интересными эффектами. А чем Вы пользуетесь? И насколько оно синтаксически прозрачно?

> как в C++, позволяет автоматизировать учет не только памяти, но и других ресурсов (мутексы, файлы, сокеты, соединения с БД),

Для таких целей в Эйфеле тоже есть специальный mixin (кажется, DISPOSABLE). Подмешиваешь к любому классу, и используешь метод dispose (опять кажется, ибо ни разу не понадобилось). Ну и, понятно, что при потере ссылок будет уничтожаться без спросу, хотя объекту дается "последний шанс". Кажется, точно так же это все работает и в Питоне, недавно видел статью, где для перегрузки методов как раз используют трюк с "неуничтожимыми объектами".

ИМХО, искусственно отключать сборку приходится намного реже, чем не забывать втыкать ее там, где она нужна. Как по мне, соотношение где-то 90/10 в пользу автоматической сборки.

> причем exception-safe образом

В Эйфеле все exception являются safe. Правда, ценой потери производительности.

А на Pyrex ты смотрел?

А зачем тут SWIG ? Для вызова Лиспа из другой программы можно просто FFI использовать, закатав Лисп в DLL. По крайней мере в Corman Lisp, Lispworks и ACL с этим проблем нет. Не уверен насчет SBCL.

>А зачем тут SWIG ? Для вызова Лиспа

Потому что вопрос был про Питон

М.б. ECL (Embeddable Common-Lisp) подойдет? Он как раз сделан для встраивания в программы на C. Вроде умеет транслирвоать в C-код.

ECL is a free Common Lisp implementation aimed at producing a small-footprint Lisp system that can be embedded into existing C-based applications. It is able to create stand-alone ELF executables from Common Lisp code and runs on most platforms that sport a C compiler.

http://ecls.sourceforge.net/

Типа в других языках выходящее за стандарт является совместимым.

>, (относительно) тормозное

Ну это касается только самых отъявленных числодробильных задач с массивами, и то там отрыв не такой же фатальный. Питон, Перл, Haskell уж точно не смогут тягаться с SBCL, да и с некоторыми другими Лиспами (например Lush). Что касается ML и С++, то с метапрограммированием как то у них тяжко, на Лиспе все таки оно намного легковеснее получается.

>, (довольно таки, по сравнению с Python/Perl/ML/Haskell) >многословное,

Краткость наверстается на нормальных по объему задачах. Для написания заоптимизированных Hello World Лисп и правда хреново подходит. Хотя без оптимизации не видно особой многословности.

> со странным синтаксисом

А у какого из упомянутых языков синтаксис не странный ? ;-)

>, не умеющее порождать unix-way программы

Почему это ? Это про тяжеловатое ядро, неудобное для мелких задачек ? Скорость запуска ядра может быть не очень. Но в принципе, тогда и Java этим грешит. Скриптовать так на GNU CLisp вроде лучше. Если полноценное приложение, где важна производительность, то можно и ядро 25 метровое запустить. В принципе можно все приложение в fasl хранить, одно и то же ядро на все приложения запускать, fasl грузятся быстро.

>, с кривыми отстающими от mainline биндингами...

А где эта mainline сейчас проходит ? Кто мешает нагенерить баиндинги для чего надо ? Почему кривыми ?

> Ну да, есть там приятные возможности - но граблей таки больше.

Дык если на другие языки с такой же точки зрения посмотреть, то граблей не меньше кажется.

И кстати, где аналог CL библиотеки CELLS хотя бы под один упомянутый язык ?

Смотрел. Только, как я понял, он работает в другую сторону. Я использовал его для оптимизации числодробилок, но хостом был таки Питон, который использовал C-модули. Тут же задача прямо противоположная.

>Смотрел. Только, как я понял, он работает в другую сторону.

Я им не пользовался, но по описанию решил, что он транслирует Питон в Си. Может, ошибся :/

Плохой для sbcl. Питону - выше крыши :) Но мы же хотим с "ссями" тягаться ;) А так как там половину надо писать самому, вот и решили "поупражняться" в целях повышения быстродействия.

> Если бы мне показали идеальный язык программирования, на порядок превосходящий остальные (ну, хотя бы бьющий C++ _и_ Perl на их поле), с хорошей - открытой и кроссплатформенной - реализацией, богатой стандартной библиотекой и активным community - я бы пересел (для собственных разработок), и ходил бы с плакатом по офису агитируя коллег.

Месье желает "серебрянную пулю"? И прямо сейчас? Новую, но открытую и с "богатой стандартной библиотекой и активным community"? Фантазёр!.. ;)

> GC не отрывается, а это плохо

Всё! Достаточно! Хотите "эдакого" - возьмите форт.

> А мне предлагают (в лице CL-я) нечто странное пока - куча полусовместимых реализаций

Все реализации си совершенно совместимы? (только не говорите - в пределах стандарта - у лиспа есть CL)

> (относительно) тормозное

Относительно чего? Питона? :)

> (довольно таки, по сравнению с Python/Perl/ML/Haskell) многословное

Согласен. По мне - не недостаток. Или действительно берите Перл.

> со странным синтаксисом

В сад! (неа, не яблоневый - в детский!)

> не умеющее порождать unix-way программы

Зависит от реализации.

> с кривыми отстающими от mainline биндингами...

Вы о коммерческих версиях? :) С открытыми - да, есть проблемы. Но это следствие. Причина - относительно небольшое community.

> Ну да, есть там приятные возможности - но граблей таки больше.

Ок, вернётесь, когда поймёте, что без этих возможностей что с граблями, что без них... "Пилите гири, Шура, они золотые"

На такую роль сейчас ничего не подходит. И не знаю, когда подойдёт.

ECL? Но там много ещё чего "пилить" надо. Хотя может то, что надо "пилить", вам и не нужно. Смотрели?

> Но вот можно ли быстро и элегантно генерить кроссплатформенный С-код из лисповских программ?

GCC?

> А было бы вкусно.

Не было бы вкусно. Ибо потеряли бы как раз много лисповых вкусностей. (К примеру, у того-же ECL не _любой_ код, который нормально компилируется, может выполниться в REPL :( А так может когда-нибудь и будет такая возможность. Или берите коммерческие версии.

Т.е. вместо того, чтобы поискать "ипостась" поприличнее, или самому принять участие в данном процессе, будем оттачивать владение ручной КПП?

> Это не очень легко (особенно с т.з. автора библиотеки), но отнюдь не невозможно.

Ага, т.е. сами "на лыжах в гамаке", зато все нити управления в руках? Ну, иногда и это надо (картинг), но чаще всё что можно посчитать на машине - пусть считает сама (Ф1). Всё, с аналогиями завязал :)

> На такую роль сейчас ничего не подходит

ИМХО (подчеркиваю красным: ИМХО) на эту роль подходит Питон. Открытая единая кроссплатформенная реализация, большое и активное сообщество (единое, а не как у Лиспов), куча библиотек, биндинги ко всему подряд. Если бы там было что-то вроде type inference, я бы даже не смотрел в сторону других языков.

> Э-э-э. Мы часом "большие" и "сложные" не путаем?

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

> + смартпойнтеры

> В стандарте С++ есть? В свое время (лет пять назад) пришлось писать свои собственные, ибо сторонние обладали странными интересными эффектами. А чем Вы пользуетесь?

В STL есть auto_ptr, который убогий, но быстрый. В Boost есть shared_ptr, который надежный, но с мутексом-на-каждую-операцию. И есть свой (не мой лично, а в смысле в конторской библиотеке), который не threadsafe, но быстрый (для thread-local-storage и однопоточных программ).

> И насколько оно синтаксически прозрачно?

shared_ptr<Foo> autofoo(new Foo());

autofoo->field = 1;

autofoo->call_method();

По-моему, нормально.

> как в C++, позволяет автоматизировать учет не только памяти, но и других ресурсов (мутексы, файлы, сокеты, соединения с БД),

> Для таких целей в Эйфеле тоже есть специальный mixin (кажется, DISPOSABLE). Подмешиваешь к любому классу, и используешь метод dispose (опять кажется, ибо ни разу не понадобилось). Ну и, понятно, что при потере ссылок будет уничтожаться без спросу, хотя объекту дается "последний шанс". Кажется, точно так же это все работает и в Питоне, недавно видел статью, где для перегрузки методов как раз используют трюк с "неуничтожимыми объектами".

Мы, по-моему, чуть-чуть о разном. Я о том, что можно, скажем, завернуть мутекс в класс (lock в конструкторе, unlock в деструкторе), и потом код типа

{

Lock a(MUTEX_ID_A);

Lock b(MUTEX_ID_b);

do_smth_locked();

}

оказывается автоматически избавленным от проблем с исключениями (и большей части проблем с дедлоками, хотя и не всех). А в языках с "настоящими" GC разрушение a и b произойдет неизвестно когда, и в непонятном порядке.

Соотвественно, заявление что > " В Эйфеле все exception являются safe."

с этой точки зрения, вероятно, ложно - невозможно, по-моему, сделать систему исключений, гарантирующую синхронное (и в правильном порядке!) освобождение ресурсов, о которых компилятор ничего не знает (потому что они объекты предметной области).

Т.е. я хочу не столько отключаемого GC, сколько предсказуемого времени финализации (которое, как мне кажется, возможно только при явном управлении памятью со стековой дисциплиной, или при reference counting-е, как в перле. Правда, в перле порядок не соблюдается, потому что lexical pad там - это, iirc, хэш внутри).

1) Тормоз! (когда хоть какая-нибудь "ускорялка" сможет работать с _любым_ питоньим кодом?)

2) Макропрограммирование - хрен целых фиг десятых. И не предвидется (в стандарте, не надо мне про сторонние костыли напоминать)

3) Хоть какой-то "конструктор" синтаксиса - фиг. ГВР лучше знает, на чём мы должны писать!... :\

Да, Питон замечательный язык. Замечательный тем, что у него _так мало_ недостатков :)

Ладно. "Каждому - своё". Плохие были место, время и события. Слова - хорошие.

1) Питон тормозит. 2) Что с метапрограммированием делать ? 3) В Питоне лямбды убирать собирались. И вообще минусы получаются из плюсов - один "милосердный диктатор" говорит, что там будет и чего не будет. В Лиспе такие решения принимаются по необходимости после существенной практической обкатки (как и в С++). Но в отличии от Питона добавить новые языковые конструкции в Лисп можно в любой момент, не дожидаясь решения "сверху".

Инфиксные выражения и type inference в Лисп добавить можно (например уже есть библиотека TypeL для вывода типов по Хиндли-Милнеру как в ML). Только не уверен, что это такое уж преимущество, на 80% кода биться из-за производительности со статической типизацией, когда там тормозить можно как угодно.

ИМХО, в REPL - нафиг не нужно. А в для компилятора - задавайте типы явно. Хотя да - с выводом типов - заманчивее ;)

Haskell по производительности - на уровне SBCL. Он статически типизированный и прекомпилируемый в native. Был бы быстрее, если бы у него был нормальный оптимайзер.

> Что касается ML и С++, то с метапрограммированием как то у них тяжко, на Лиспе все таки оно намного легковеснее получается.

Да, но "метапрограммирование ненужно". В том смысле, что эти проблемы решает малое количество людей один раз, и, в любом случае, проектирование DSL - сильно более сложная задача, чем его реализация (даже на С/yacc).

> А где эта mainline сейчас проходит ? Кто мешает нагенерить баиндинги для чего надо ? Почему кривыми ?

Ну, вон, гтк к sbcl у кого-то тут подцепить не получилось. А, скажем, к какому-нибудь cairo их вообще нету, небось.

> Дык если на другие языки с такой же точки зрения посмотреть, то граблей не меньше кажется.

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

Я не утверждаю, что CL _хуже_, чем связка Perl/C++. Только то, что он не настолько лучше, чтобы переход на него оправдал затраты (имхо - так вообще не лучше).

Ну приведи пример, строк на 100, где действительно необходимо макропрограммирование.

Пока что во всех примерах рассмотренных в этом топике не было ни обдного примера где дествительно были необходимы макры.

Или этого нельзя понять на хелло-ворлдах, а только на больших серьёзных лисповых проектах на тысячу строк?

По сравнению с компилируеммы в машинный код - да. Но есть psyco. А критическое числодробление делается во всяких Numeric Python, которые юзают жостко оптимизированный Си-код.

> 2) Что с метапрограммированием делать ?

Использовать. Начать с гугления по "Python Metaprogramming". Впрочем - по-моему, "метапрограммирование" - это еще хуже, чем "обёектно-ориентированное программирование" 15 лет назад, там хоть были общепринятые определния и эталонные реализации. А "метапрограммирование" - модный термин и повод для фаллометрии.

> 3) В Питоне лямбды убирать собирались.

Но не убрали же.

> минусы получаются из плюсов - один "милосердный диктатор" говорит, что там будет и чего не будет.

Какая чушь. Гвидо - это финальная инстанция при разрешении конфликтов. Он может сказать, чего не будет, но что будет - решает практика.

> Только не уверен, что это такое уж преимущество, на 80% кода биться из-за производительности со статической типизацией

Это не ради производительности ни разу.

_Необходимо_ - не то слово. Можно и без них обойтись. Только... гемору слишком много.

А чтобы понять - посмотрие потроха sbcl. Да, на 3 строчках все вкусности макр не увидеть. Да и желания нет.

1. Кому как.

2. Тебе _лично_ не надо? А чё ты тогда в этом топике делаешь? Хочешь лисперам глазики промыть? Иди в свю "ссятницу" и даже define-ом не пользуйся.

> Только то, что он не настолько лучше, чтобы переход на него оправдал затраты (имхо - так вообще не лучше).

Не хочешь - не переходи. Тебя кто-то силой тащит?

Давай заменим "необходимо" на "нельзя обойтись без макр без большого гемору"

> А чтобы понять - посмотрие потроха sbcl.

Это сильно большой пример

> Да, на 3 строчках все вкусности макр не увидеть.

Согласен на 100. Приведи пример. Я его перепишу на питоне, и мы посмотрим действительно ли макры дают большие плюсы.

> Да и желания нет.

Или примеров? :-)

Прошу прощения за безграмотность, но psyco "съест" _любой_ питоний код?

> А критическое числодробление делается во всяких Numeric Python, которые юзают жостко оптимизированный Си-код.

Аналогично. Подключите через ffi любую оптимизированную числодробильну. Всего-то.

> Впрочем - по-моему, "метапрограммирование" - это еще хуже, чем "обёектно-ориентированное программирование"...

Это в Питоне "метапрограммирование" еще хуже, чем "обёектно-ориентированное программирование", ибо через него и делается. Ага, вы ещё форт "пошлите по азимуту", потому что там одно сплошное метапрограмирование ;) Хотя да, мы же уже пришли к консенсусу - Вам метапрограммирование не нужно. Так зачем опять повторяться? :)

Давай :)

> Это сильно большой пример

> Согласен на 100. Приведи пример. Я его перепишу на питоне, и мы посмотрим действительно ли макры дают большие плюсы.

100 тоже мало. Возьми не весь sbcl - возьми из него только loop :))

Нет. Операции с плавающей точкой оптимизируются не в машинный код, а вызов функций; вложенные функции и yield - не оптимизируется. Работает правильно, но не ускоряется.

>> А критическое числодробление делается во всяких Numeric Python, которые юзают жостко оптимизированный Си-код.

>Аналогично. Подключите через ffi любую оптимизированную числодробильну.

Не аналогично. При использовании Numeric Python мне не надо возиться с FFI. Вы вообще видели Numeric?

> Ага, вы ещё форт "пошлите по азимуту", потому что там одно сплошное метапрограмирование

Если Форт - это метапрограммирование, то спасибо, не нужно. Его уже все давно послали.

> мы же уже пришли к консенсусу - Вам метапрограммирование не нужно.

Вы пришли к такому консенсусу с кем-то другим. Я до сих пор толком не понял, что это такое :/. Но все говорят, что это неимоверно круто.

> 100 тоже мало. Возьми не весь sbcl - возьми из него только loop :))

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

Ну давай 200. Приведи пример что я не смогу эффективно заменить макры чем либо другим и всё, я буду доволен. Вопрос для меня будет закрыт.

> Нет. Операции с плавающей точкой оптимизируются не в машинный код, а вызов функций; вложенные функции и yield - не оптимизируется. Работает правильно, но не ускоряется.

tailgunner, ты yyk-а запутываешь. Имхо правильный ответ будет такой:

Да, psyco cъест _любой_ питоний код, не любой ускорит, но _съест_ _любой_.

Для включения pysco достаточно в одной точке программы напсать:

import psyco

psyco.full()

Я это обычно делаю либо в main() либо до его вызова

>Да, psyco cъест _любой_ питоний код, не любой ускорит, но _съест_ _любой_.

:/ По-моему, я сказал то же самое. "Работает правильно, но не ускоряется."

> :/ По-моему, я сказал то же самое. "Работает правильно, но не ускоряется."

Согласен, ты сказал то же самое. Но акценты расставлены по другому.

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

Я просто представил что мог бы вынести из твоего поста bugmaker... :-)

а как же "плакали, кололись, но _ели_"?

> Немного выше по топику ты считал достоинством лиспа то что там есть готовый контейнер для решения задачи с файлами и что тебе не надо дотачивать контейнер как в С++ или питоне.

справедливости ради следует отметить, что и в лиспе и в притоне и в сях++ и в жабе и ещё много где есь контейнер с более-менее одинаковыми свойствами, в составе стандартной либы. Только вот в лиспе ево _не_надо_ дотачивать, именно из-за свойств езыка, а не либы.

> А как питон попал в аналогичную ситуацию так это уже не достоинство, а просто "из стандартной библиотеки специально для этово случяя написатую на сях функцию". Занятная манера спора.

я не утверждал чё в лиспе нету аналогичных. Меня только позабавило искреннее восхищение питоноедов тем фактом, что в стандартной либе есь функция специально для этого случяя и непригодная ни для чего более, в отличие от контейнеров, доволльно универсальных.

Хотиш сделать это на петоне, не прибегая к стандартным?

> Только тормозит со страшной силой?

С нормальной силой.

> Т.е. программы на лиспе у нас или короткие, но тормозные, или быстрые, но спагетти-кодинг-оптимизированные?

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

А в питоне проги одновременно и тормозные и преогромные и нечитаемые, и выбора, оптимизировать или не, нету.

> Спасибо, я уж лучше на плюсах. Или Eiffel/*ML какой освою.

да наздоровье, хто заставляет?

> Эти функции необходимы едва ли не в любой юниксовой программе...

лисповые и без них отлично обходяцо.

Мож тебе сразу всё тебе потребное и накодить на ём заодно?

> А мне предлагают

дык неихто тебе не предлагает, успокойся.

> нечто странное пока - куча полусовместимых реализаций,

в питоне одна всево, зато ужасная.

> (относительно) тормозное,

относительно сей, вдвое примерно. ИМХО вполне приемлемо. Если согласен для немного большей производительности намного больше коду крапать - флаг вруки и барабан и все дела, чё разнылся то? Вон народ даже питон устраивает, куда как тормозной.

> (довольно таки, по сравнению с Python/Perl/ML/Haskell) многословное,

пока что приведённые здесь проги на питоне намного длиньше. По отзывам, которых лехко можеш найти гуглем, лиспопроги для достаточно больших проектов на порядок короче с++вых. На малых задачах выйгрыш конечно намного менше, но и тут действие из 3х строк на лиспе превратилось в многотомную сагу о файлах в питоньей реализации.

> со странным синтаксисом,

у питона ещё страньше, не говоря уж о с++. И ничё, пользуют ведь.

> не умеющее порождать unix-way программы,

не умеющее, вернее это довольно сложно. Жаба тоже не умеет. Потомушто внутри своей собственной идеологии работает. Иногда это недостаток, а иногда наоборот.

> с кривыми отстающими от mainline биндингами...

напишы прямые если которые есть ненравяцо.

> я лучше что-нибудь модное изучу - Haskell

и будеш бинарь по писятмех получять

> 30-тилетние консервы, из которых уже поуносили все интересное...

только вот ни по одному параметру к ним пока даже близко не подошли.

> А что, в LISP не так? Для реализации, например, двусвязного списка ты видоизменяешь CONS? Или таки строишь новый тип из примитивных?

Именно так, я это и пытаюсь обяснить челу, который хотит секвенс, такой точно как стандартный, но с перламутровыми пуговицами...

> +1. На такую роль CL, увы, не подходит.

остальные подходят ещё меньше, и намного

>> На такую роль сейчас ничего не подходит

> ИМХО (подчеркиваю красным: ИМХО) на эту роль подходит Питон. Открытая единая кроссплатформенная реализация, большое и активное сообщество (единое, а не как у Лиспов), куча библиотек, биндинги ко всему подряд. Если бы там было что-то вроде type inference, я бы даже не смотрел в сторону других языков.

ну, питон ещё когда доделают... ИМХО лет десять пройдёт, не меньше. Если не забросят.

у меня в своё время хеловорд на бейсике не сразу завёлся, хотя казалось бы...

> А, скажем, к какому-нибудь cairo их вообще нету, небось.

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

> не настолько лучше, чтобы переход на него оправдал затраты (имхо - так вообще не лучше).

чясть обезян думала, что жыть в пещерах не настолько луче, чем на деревьях. Тебе решать, тя нихто не заставит и неуговаривает. Только вот приписывать лиспу/питону/чемутоещё свойства, которых у их нету, ИМХО неследует.

ИМХО нельзя, или затруднительно. Придумай _небольшую_ задачу, для которой дсл было бы оправдано...

Тебе ведь уже привели пример обычного кодинга, где лисповые три строки на питоне были расписаны в семи томах. Ты ведь не был доволен и не закрыл для себя вопрос? Почему ты думаеш чё макры тя убедят?

аха, я коварный...

Врешь. Уж не хуже лиспов, которые даже не все дистростроители собрать асиливают.

> пока что приведённые здесь проги на питоне намного длиньше.

Врешь. Они функциональнее, аналогичное по "наколенности" на питоне будет короче. Прога про перестановки не перле была на 20% короче.

> не умеющее, вернее это довольно сложно. Жаба тоже не умеет. Потомушто внутри своей собственной идеологии работает. Иногда это недостаток, а иногда наоборот.

Врешь. Есть gcj. Да и с сановской явой *.jar подключаются как misc_binaries очень легко. С лисповой так не получится.

> только вот ни по одному параметру к ним пока даже близко не подошли.

Врешь. *ML уж точно во многих областях (type inference, pattern matching) лиспа опередил уже десять лет назад.

> Именно так, я это и пытаюсь обяснить челу, который хотит секвенс, такой точно как стандартный, но с перламутровыми пуговицами...

"Именно так" - это крутой ответ на "альтернативный вопрос".

Если ты "видоизменяешь CONS" - делись травой. Если "строишь новый тип из примитивных" - где тут радикальное преимущество над С?

Haskell лично мне нравится. Никаких предубеждений против него нет, но он "ленивый", а "энергичные" языки все таки эффективнее ленивых. Так что не верю. В Haskell как ни пытался не нашел способ как сделать быструю работу с массивами. Вот Clean - это реально эффективная вещь (есть даже array comprehension), но писать GUI приложения как пишут на нем, заталкивая все в один вытянутый блок (хоть он малость и побит логически), нет никакого желания. Даже удивительно, что с таким убойным языком как Clean нет ни одной приличной GUI библиотеки. Наверное у него все еще впереди, как и Haskell.

>Да, но "метапрограммирование ненужно". В том смысле, что эти >проблемы решает малое количество людей один раз, и, в любом случае, >проектирование DSL - сильно более сложная задача, чем его >реализация (даже на С/yacc).

Это миф. Если DSL никако не интегрируется с host language, то это трудоемко и любые ошибки проектирования стоят очень дорого (путь C/yacc) Проектирование "малых" встраиваемых DSL в Lisp, Haskell, C++ (из того что я рельно видел) действительно оправдано и значительно упрощает решаемую задачу. Пример тому loop macro в Common Lisp, синтаксис в принципе не лисповый, но интегрируется с языком настолько хорошо, что считается хорошим стилем использовать именно loop, а не do,do* и т.п.

Потом без метапрограммирования невозможно сделать нечто подобное CELLS (и чтобы этим еще можно было также легко пользоваться), или приличный (но не обязательно тяжелый) фрэймворк для веб. программирования.

>Ну, вон, гтк к sbcl у кого-то тут подцепить не получилось. А, >скажем, к какому-нибудь cairo их вообще нету, небось.

Всякое бывает. Я например активно юзаю собтвенноручно сгенеренные баиндинги к OpenCV и нарадоваться не могу, очень удобная интеграция. Еще финализацию прикрутил, чтобы объекты c foreign кучи убивались сами, когда в них больше нет необходимости. Это в Lispworks, но SBCL в этом плане вроде ничем не отличается. Какие могут быть проблемы с баиндингами ? Надо конечно, чтобы в Лисп это удобно интегрировалось, кое что и завернуть в Лисп объекты неплохо, а мелочью и так рулить замечательно можно (например IplImage из OpenCV).

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

Не получится то же самое. Например лямбда в boost совершенно не то же самое, что в Лиспе. Тексты фильтров в Перле тоже не равны Лисповым макрам. Ну нигде такого сочетания функционала как в Лиспе не найти, хотя каких-то вещей конечно не хватает, например полный type inference чтоб алгебраическими типами крутить удобнее было, но в принципе это от незнания типичных лисповых способов делать то же самое. Ну иногда хочется, чтоб код со статической типизацией и объявлением типов, выглядел также красиво как с динамической, но не терять быстродействие, за счет макр это часто удается сделать.

>Я не утверждаю, что CL _хуже_, чем связка Perl/C++. Только то, что >он не настолько лучше, чтобы переход на него оправдал затраты >(имхо - так вообще не лучше).

Что тут сказать. Думайте сами, решайте сами... Не исключено, что попробовав и как следует прочувствовав все плюсы, Вам уже не захочется покидать Лисп из-за синергетики сочетания всех его функций (как мне) как бы притягательно не выглядели отдельные аргументы сторонников других языков. На comp.lang.lisp неоднократно предупреждали, что можно легко втянуться в Лисп окончательно, что ваша карьера Java или С++ программиста накроется медным тазом ;-)

Haskell лично мне нравится. Никаких предубеждений против него нет, но он "ленивый", а "энергичные" языки все таки эффективнее ленивых. Так что не верю. В Haskell как ни пытался не нашел способ как сделать быструю работу с массивами. Вот Clean - это реально эффективная вещь (есть даже array comprehension), но писать GUI приложения как пишут на нем, заталкивая все в один вытянутый блок (хоть он малость и побит логически), нет никакого желания. Даже удивительно, что с таким убойным языком как Clean нет ни одной приличной GUI библиотеки. Наверное у него все еще впереди, как и Haskell.

>Да, но "метапрограммирование ненужно". В том смысле, что эти >проблемы решает малое количество людей один раз, и, в любом случае, >проектирование DSL - сильно более сложная задача, чем его >реализация (даже на С/yacc).

Это миф. Если DSL никако не интегрируется с host language, то это трудоемко и любые ошибки проектирования стоят очень дорого (путь C/yacc) Проектирование "малых" встраиваемых DSL в Lisp, Haskell, C++ (из того что я рельно видел) действительно оправдано и значительно упрощает решаемую задачу. Пример тому loop macro в Common Lisp, синтаксис в принципе не лисповый, но интегрируется с языком настолько хорошо, что считается хорошим стилем использовать именно loop, а не do,do* и т.п.

Потом без метапрограммирования невозможно сделать нечто подобное CELLS (и чтобы этим еще можно было также легко пользоваться), или приличный (но не обязательно тяжелый) фрэймворк для веб. программирования.

>Ну, вон, гтк к sbcl у кого-то тут подцепить не получилось. А, >скажем, к какому-нибудь cairo их вообще нету, небось.

Всякое бывает. Я например активно юзаю собтвенноручно сгенеренные баиндинги к OpenCV и нарадоваться не могу, очень удобная интеграция. Еще финализацию прикрутил, чтобы объекты c foreign кучи убивались сами, когда в них больше нет необходимости. Это в Lispworks, но SBCL в этом плане вроде ничем не отличается. Какие могут быть проблемы с баиндингами ? Надо конечно, чтобы в Лисп это удобно интегрировалось, кое что и завернуть в Лисп объекты неплохо, а мелочью и так рулить замечательно можно (например IplImage из OpenCV).

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

Не получится то же самое. Например лямбда в boost совершенно не то же самое, что в Лиспе. Тексты фильтров в Перле тоже не равны Лисповым макрам. Ну нигде такого сочетания функционала как в Лиспе не найти, хотя каких-то вещей конечно не хватает, например полный type inference чтоб алгебраическими типами крутить удобнее было, но в принципе это от незнания типичных лисповых способов делать то же самое. Ну иногда хочется, чтоб код со статической типизацией и объявлением типов, выглядел также красиво как с динамической, но не терять быстродействие, за счет макр это часто удается сделать.

>Я не утверждаю, что CL _хуже_, чем связка Perl/C++. Только то, что >он не настолько лучше, чтобы переход на него оправдал затраты >(имхо - так вообще не лучше).

Что тут сказать. Думайте сами, решайте сами... Не исключено, что попробовав и как следует прочувствовав все плюсы, Вам уже не захочется покидать Лисп из-за синергетики сочетания всех его функций (как мне) как бы притягательно не выглядели отдельные аргументы сторонников других языков. На comp.lang.lisp неоднократно предупреждали, что можно легко втянуться в Лисп окончательно, что ваша карьера Java или С++ программиста накроется медным тазом ;-)

Ну вот, например, простейшая задача:

Есть связный лабиринт из квадратных полей, с одним входом. В лабиринте разбросаны вещи.

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

Ы?

> Врешь. Уж не хуже лиспов, которые даже не все дистростроители собрать асиливают.

дык он оперативу освобождает ужо?

>> пока что приведённые здесь проги на питоне намного длиньше.

> Врешь. Они функциональнее, аналогичное по "наколенности" на питоне будет короче. Прога про перестановки не перле была на 20% короче.

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

>> не умеющее, вернее это довольно сложно. Жаба тоже не умеет. Потомушто внутри своей собственной идеологии работает. Иногда это недостаток, а иногда наоборот.

> Врешь. Есть gcj. Да и с сановской явой *.jar подключаются как misc_binaries очень легко. С лисповой так не получится.

Это ты врёш, и сильно. Есь gcl. Да и с лиспом лиспопроги подключаются как misc_binaries ещё легче. Ты просто рассуждаеш о вещах о которых не имееш ни малейшево представления.

Там же где для сей примитивные это указатели и байты, а для лиспа - списки и хеши. Если для большинства лисппрог новых типов строить безсмысленно, то на с/с++/питоне для более-менее сложной задачи с этого и приходицо начинать, изобретая лисапет сново и сново.

А чего там возиться? И Numeric - это top в числодроблении?

> Я до сих пор толком не понял, что это такое :/.

А, ну тогда у Вас ещё всё впереди ;)