>Что плохого в Python

Плохого в нём ничего нет. Хорошего тоже. Ещё один язычок с фиксированной семантикой. Зачем его нужно было делать непонятно. Но раз уж он существует --- пусть живёт.

>на сколько он тормозной ( в сравнении допустим с Perl)

0. Некорректно говорить о скорости языков. Нужно говорить о скорости интерпретаторов.

1. Относится к тому же классу.

> Ещё один язычок с фиксированной семантикой. Зачем его нужно было делать непонятно. Но раз уж он существует --- пусть живёт.

Странно. Всегда казалось что для решения конкретных задач полезны именно языки "с фиксированной семантикой"

По сравнению с перлом у питона единственный существенный плюс - более или менее продуманная концепция. По поводу скорости ни разу не заморачивался ...

> Плохого в нём ничего нет. Хорошего тоже. Ещё один язычок с фиксированной семантикой. Зачем его нужно было делать непонятно. Но раз уж он существует --- пусть живёт.

А ты с синтаксисом не путаешь?

Для решения конкретных задач полезны dsl, так как они позволяют решать задачу в терминах задачи. А для написания dsl нужны языки с изменяемой семантикой. Покури лисп, затем выкури c + bison. Почувствуй разницу.

> более или менее продуманная концепция.

Какая?

Нет.

Вот уж чего-чего, а продумманности в питоне ни-ка-кой!
Наоборот такое чуство что его php-кодеры писали....
join сделали методом стринга, а вместо существующего у всех .toString() сделали отдельную функцию....
и так далее....

Насчёт скорости - скорость одинаковая...
Гибкость - хуже чем у перла...

> Для решения конкретных задач полезны dsl, так как они позволяют решать задачу в терминах задачи.

Люой dsl - яэык с "фиксированной семантикой". Легко можно показать, что Python вполне себе dsl. Вопрос тольков в его domain-е.

> А для написания dsl нужны языки с изменяемой семантикой.

Строго говоря любой более или менее серьезный язык - это язык с изменяемой семантикой. Например, на Си написано дофига наиболее популярных на сегодняшний день dsl-ей. Другое дело что разработка и интеграция dsl-ей на C может быть достаточно трудоемким процессом.

> c + bison.

А это что за хрень ? Генератор синтаксических анализаторов? Кстати тоже dsl и тоже написан на C.

>Гибкость - хуже чем у перла...

Что в питоне макр нету, что в перле их не наблюдается. => С гибкостью у них одинаково плохо.

>Люой dsl - яэык с "фиксированной семантикой".

Ты не понял. Нужен один метаязык, язык с изменяемой семантикой. Тогда ты можешь лёгко и изящно, с помощью нескольких макросов, реализовать dsl. Естественно у dsl будет фиксированная семантика, но у ,,создателя'' dsl она должна быть изменяемая. Иначе будет геморой.

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

Если ты пишешь дисер, то это (может быть) другое дело. А когда у тебя есть ограничение по срокам на сдачу проекта, то вопрос в лёгкости реализации/модификации/поддержки приобретает первостепенное значение.

> Кстати тоже dsl и тоже написан на C.

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

>> более или менее продуманная концепция.

> Какая?

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

В отличие от перла питон выглядит на порядок более стройным языком с логичным синтаксисом, нормальной поддержкой ООП и более простыми средствами интегрирования с С/C++. Для мелкого скриптования в силу указанных причин мне проще использовать именно python

На всякий случай.

Я _не_ утверждаю, что на цэ в принципе невозможно реализовать dsl. Точно так же я не утверждаю, что нельзя построить самолёт, работающий на дровах.

> Ты не понял. Нужен один метаязык, язык с изменяемой семантикой.

Окей. Кому нужен? Очевидно, что конечному кодеру нужен dsl с фиксированной семантикой. Ему плевать каким образом этот dsl реализован. Питон вполне себе dsl для задач склеивания компонентов, реализованных на C/C++. Что проще взять питон или взять лисп написать на нем питон и радоваться от того что ты используешь язык с не "фиксированной семантикой" ?

> Если ты пишешь дисер, то это (может быть) другое дело. А когда у тебя есть ограничение по срокам на сдачу проекта, то вопрос в лёгкости реализации/модификации/поддержки приобретает первостепенное значение.

У тебя есть опыт реализации/модификации/поддержки серьезных программ на языке с не "фиксированной семантикой" ?

> Вот и попробуй реализовать с помощью бизона что--нибудь серьёзнее языка--калькулятора.

Эти средства имеют не пересекающиеся области применения. Bison - dsl для написания синтаксических анализаторов. Lisp - многоцелевой язык программирования. Написать синтаксический анализатор на bison-е проще чем на чистом lisp-е.

> Кому нужен?

Очевидно тому, кто будет реализовывать транслятор с dsl'я.

>Питон вполне себе dsl для задач склеивания компонентов

Да? Раскажите, что в питоне есть такого, что эта задача решается в нём лучше, чем в других яп. Я с питоном знаком весьма поверхностно и возможно просто не разглядел в нём этих продвинутых возможностей.

>Что проще взять питон или взять лисп написать на нем питон

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

>У тебя есть опыт реализации/модификации/поддержки серьезных программ на языке с не "фиксированной семантикой" ?

Нету.

> Написать синтаксический анализатор на bison-е проще чем на чистом lisp-е.

Ой ли. bison хорош для разбора очень примитивных язычков. Грубо говоря сложность работы с бизоном экспоненциально зависит от сложности разбираемого языка. Тогда как с лиспом зависимость имеет логарифмический вид.

>Lisp - многоцелевой язык программирования.

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

> Да? Раскажите, что в питоне есть такого, что эта задача решается в нём лучше, чем в других яп. Я с питоном знаком весьма поверхностно и возможно просто не разглядел в нём этих продвинутых возможностей. > Проще взять лисп и работать с ним. Зачем вообще нужен питон? Что в нём есть такого, чего не было реализовано лет за 30 до него?

С точки зрения языковых конструкций питон - очередной скриптовый ООП язык с динамической семантикой и простым в изучении синтаксисом, вроде того же Ruby. Ничего особенного. Питон выруливает в своей области за счет простоты и наличия огромного количества готовых компонентов. Берешь и пользуешься, это быстро, просто и это реально работает. Ничего придумывать не надо.

> Ой ли. bison хорош для разбора очень примитивных язычков. Грубо говоря сложность работы с бизоном экспоненциально зависит от сложности разбираемого языка. Тогда как с лиспом зависимость имеет логарифмический вид.

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

> Могу спорить что напишу синтакисческий анализатор дсотаточно сложного языка на bison-е быстрее чем ты на чистом lisp-е

О поддержке и модификации я вообще молчу.

Готовый DSL, а не синтаксический анализатор, проще дешевле и быстрее создать именно на Лиспе.

>очередной

Вот именно. Питон --- флагман велосипедостроения.

>за счет простоты

Чем питон проще лиспа? Меньший функционал вижу.

> наличия огромного количества готовых компонентов

Не такого уж и огромного. Особенно если со CPAN'ом сравнить. И потом, представь себе, что тебя завут GvR. Нужно реализовать огромное количество компонент. Два варианта: реализовать их для имеющегося языка (тикуля или перла) или написать свой язык и уже для него писать компоненты. Имхо, первый вариант предпочтительнее.

>Берешь и пользуешься, это быстро, просто и это реально работает.

Всё это было задолго до питона.

> Bison и ему подобные предназначены для реализации cинтаксических анализаторов. Все.

Верно, но кому нужен _только_ синтаксический анализ? Никому. Результат работы bison'а придётся обрабатывать в цэшной проге. А цэшный код для этого плохо подходит, и чем дальше семаника dsl от семантики цэ, тем хуже будет программисту.

>Могу спорить что напишу синтакисческий анализатор дсотаточно сложного языка на bison-е быстрее чем ты на чистом lisp-е

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

>О поддержке и модификации я вообще молчу.

Вот и молчи. ;)

Вижу что базар переходит в плоскость бессмысленной holy war. Окей. Давай представим ситуацию. У тебя есть команда разработчиков пишуших различные, относительно независимые компоненты на Си и Си++. Твоя задача

1) состыковать эти компоненты между собой 2) дополнить полученную систему некоторым типовым функционалом, вроде скачивания с инета обновлений или рассылки писем на заданный адрес и т.д.

Твои действия ?

Особенно интересует место не "фиксировнной семантики" при решении этой задачи

>1) состыковать эти компоненты между собой 2) дополнить полученную >систему некоторым типовым функционалом, вроде скачивания с инета >обновлений или рассылки писем на заданный адрес и т.д.

perl ? :)

Тут вот как-раз нужнен язык-клей, скорее всего конечно perl-python-ruby-tcl да и схема подойдёт. CL тут ИМХО overkill. CL это для создание чего-то нового со сложными абстракциями (правда со схемой тоже это всё можно делать, но имхо геморойнее)... Такая мысль часто высказываеться: "Если ты ещё точно не знаешь что у тебя должно получиться - пиши на Лиспе."

>Твои действия ?

0. apt-get install cl-uffi

1. Делаем интерфейс между цэшнмыми модулями и лиспом

2. Наслаждаемся жизнью.

>Тут вот как-раз нужнен язык-клей,

До питона, конечно же, язык--клеев ни одного не было?

>CL тут ИМХО overkill.

Почему?

>CL это для создание чего-то нового со сложными абстракциями

И для этого тоже. Но примитивную, кодерскую задачу также можно решать на лиспе.

> Могу спорить что напишу синтакисческий анализатор дсотаточно сложного языка на bison-е быстрее чем ты на чистом lisp-е

А я на миг31 пролечу быстрее чем ты на велосипеде. Бум спорить?

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

Потомучто ну не предназначен изначально CL для скриптования, точней не сам CL а его реализации (по крайней мере то что я видел). Чтобы сделать так чтобы все те вещи которые можно легко сделать в python/ruby/perl нужно достаточно большой набор функций и макр, да ещё и желательно переносимимый между реализациями. Я думая для этих целей как раз сделали NewLisp ну и наверное какую-нибудь реализацию схемы.

Я сейчас как делаю. Те программы для которых сам выбираю язык пишу так, если маленький скриптик <= 200-300 строк то ruby (раньше python). Что посложнее - lisp. А ну веба, простого веба, всё-таки Ruby On Rails - под CL такого фрэймворка нет:( А было-бы весьма неплохо. Да и не будет наверное, ибо в этом деле главное - куча полезных компонентов, кто на лиспе писать то будет?

Да и ещё советую посмотреть на ruby, он как питон но намного ближе к лиспу. Метапрограммированием например хоть какое-то есть.

>Потомучто ну не предназначен изначально CL

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

Нужно было сделать распознование фурье--спектров нейронными сетями. Есть либа для фурье --- fftw и либа для неёронных сетей --- fann. Логику делал на окамле. Писать полноценные биндинги было лениво. Решение: сделать маленькую либу на цэ, которая дёргала нужные функции из fftw и fann, и писать биндинг к ней.

Так что мне бы хотелось примеров типа: задача --- питоновое решение --- лисповое решение --- вывод о чрезмерной сложности лиспа.

>Чтобы сделать так чтобы все те вещи которые можно легко сделать в python/ruby/perl нужно достаточно большой набор функций и макр

Конкретику в студию.

>под CL такого фрэймворка нет:(

Слышал, что unCommon Web очень неплохая штука.

>Да и ещё советую посмотреть на ruby,

Всё никак руки не доходят. ;(

И вообще, для меня сейчас самый актуальный язык --- R. Который, кстати, наглядно иллюстрирует пользу от dsl'ей.

Я что хотел сказать. У питона(в меньшей степени руби) есть хорошая стандартная библиотека раз. Для лиспа дольше искать, чем в питоне. У лиспа посложнее система пакаджей, у лиспа всётаки синтаксис изначально понагруженнее, конечно можно своих синонимов наделать и прочее, но всё-таки для маааленьких задач не всегда нужно. У лиспа многие простые вещи типа "вызвать внешнюю прогу получить вывод" зависимы от реализации , хотя есть кончено бибилотеки для платформонезависимости. Короче не для маленьких скриптов лисп (Common Lisp) хуже подходит. К тому же на маленьких задачах достоинства метапрограммирования редко раскрываетються. А вообще я про лисп и не говорю, я говорю про конкретные реализации CL. Если в тот же CL написхать кучу макр для скриптописания то он будет кончено всех делать, только помоему никто этого не сдлал. Зато вроде сделали на схеме, но я не смотрел.

s/ не для маленьких скриптов/ для маленьких скриптов/

> Слышал, что unCommon Web очень неплохая штука.

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

>У питона(в меньшей степени руби) есть хорошая стандартная библиотека раз.

Ну этим сейчас никого не удивишь.

> Для лиспа дольше искать, чем в питоне.

0. А чего тебе конкретно не хватает в лиспе.

1. Если пакета нет ни под лисп, ни под питон, то под лиспом его написать быстрее.

> У лиспа посложнее система пакаджей, у лиспа всётаки синтаксис изначально понагруженнее

Тебя похитили чеченские терористы и заставляют использовать все возможности ansi common lisp'а в каждом приложении? Если что--нибудь (например макры) тебе в данном приложении не нужно, то ты его просто не используешь и всё. В чём проблема то?

(офтопик (сильно подазреваю, что многие перл программисты таки похищены вышеупомянутыми терористами))

> зависимы от реализации

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

>для маленьких скриптов

Для маленьких скриптов идеален scsh (scheme shell). Прикольная штука. Код получается яснее, чем для posix shell. Опять же скобки вместо кавычек многого стоят.

>на маленьких задачах достоинства метапрограммирования редко раскрываетються

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

>Если в тот же CL написхать кучу макр для скриптописания то он будет кончено всех делать

Однозначно, тебе нужно обратить внимание на scsh. Это схема с макрами для скриптования.

>Нету кучи нужных компонетов, чтобы по-быстрому сайт с БД-бэкэндом наваять.


~% apt-cache search lisp|grep sql
cl-pg - Common Lisp library that provides a socket level postgresql interface
cl-sql - SQL Interface for Common Lisp
cl-sql-aodbc - CLSQL database backend, AODBC
cl-sql-mysql - CLSQL database backend, MySQL
cl-sql-odbc - CLSQL database backend, ODBC
cl-sql-postgresql - CLSQL database backend, PostgreSQL
cl-sql-postgresql-socket - CLSQL database backend, PostgreSQL
cl-sql-sqlite - CLSQL database backend, SQLite
cl-sql-uffi - Common UFFI functions for CLSQL database backends
cl-sql-oracle - CLSQL database backend, Oracle

~% apt-cache search lisp|grep html
cl-html-template - Common Lisp HTML Template processor
cl-htmlgen - HTML generation library for Common Lisp programs

~% apt-cache search lisp|grep apache
libapache-mod-lisp - An Apache module that interfaces with Lisp environments

Ага scsh я же писал что на схеме что-то такое наваяли, нужно посмотреть.

Я это всё видел, и даже кое-что приминял в реальном проекте. Но теперь только осталось сделать фрэймворк аналогичный RoR который все эти элементы между собой интегрирует. А также заставить кучу кодеров написать кучу web-компонентов для этого фрэймворка. Если первое ещё возможно, что я думаю скоро сделают (я бы даже с удовольствием принял участие) то со вторым будет сложнее. Скорее всего CL-фрэймворк будет отствавить от RoR по количеству компонентов постоянно... К тому же есть уже такой фрэймворк на схеме, Виталий одно время всё в него тыкал, но боюсь пока не осилю его в продакшене использовать... Буду пока web писать всё-таки на RoR... К тому же руби довольно неплохой язык и метапрограмминг там более-менее развит, во многом благодоря этому RoR и получился такой конфеткой.

> А чего тебе конкретно не хватает в лиспе.

Да всё хватает (кроме нормально бесплатной кросплатфоменной гуйни). 
только иногда нужно бысторо и не заморачиваясь. Понадобились мне 
разные фичи для генерации случайных файлов. ВОт беру random и смотрю 
все его функции - там всё есть. На лиспе есть тока функция random и 
приходиться искать или писать недастоющие функции (например случайный 
элемент списка). 

ИЛи for i in file

Чтобы так просто работать со строками в файле приходиться писать 
что-то вроде этого:

(defmacro loop-stream-lines ((stream line &optional line-number)
			     &body body)
  "Process ``stream'' line by line. In ``body'' - ``line'' is a current
   line and ``line-number'' is a nubmer of current line in stream"
  (with-gensyms (eof)
    `(loop ,@(when line-number
		   `(for ,line-number = 1 then (+ ,line-number 1)))
           for ,line = (read-line ,stream nil ',eof)
	   until (eq ,line ',eof)
      ,@body)))

(defmacro loop-file-lines ((file-name line &optional line-number)
			   &body body)
  "Process ``file'' line by line in ``body'' line is a current
   line and ``line-number'' is a nubmer of current line in stream"  
  (with-gensyms (file-stream)
    `(with-open-file (,file-stream ,file-name :direction :input)
      (loop-stream-lines  (,file-stream ,line ,line-number)
       ,@body))))

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

Удачи в написании питона на лиспе

> А для написания dsl нужны языки с изменяемой семантикой

Покажи мне в Haskell _изменяется_ семантика - а ведь DSL'и прекрасно с ним интегрируются. В языке должна быть возможность встраивания DSL'ей (ес-но у каждого своя семантика) - но не изменения самого языка (который есть основа. Если ты поверх лиспа соорудишь ленивый функциональный язык с системой типов HM - то семантики _самого лиспа_ ты не изменишь - ты создашь _новый_ язык.

> Покажи мне в Haskell _изменяется_ семантика - а ведь DSL'и прекрасно с ним интегрируются. В языке должна быть возможность встраивания DSL'ей (ес-но у каждого своя семантика) - но не изменения самого языка (который есть основа. Если ты поверх лиспа соорудишь ленивый функциональный язык с системой типов HM - то семантики _самого лиспа_ ты не изменишь - ты создашь _новый_ язык.

Оопс, а можно с этого места по-подробнее?

ИМХО, написать DSL можно на любом языке. Ну, встроить в DSL в некоторой степени элементы (их вызов) этого самого языка - да. Но встроить DSL со своей семантикой в другой язык (пусть тот, на котором он пишется) - это подвласно только языкам с изменяемой семантикой. Разве не так?

Т.е. написать на паскале/си обработку SQL-запросов с возможностью использования паскалевских/сишных функций - можно (но не нужно:)). Но как встроить в паскаль/си семантику SQL-запросов силами самого паскаля? Только разве что написанием препроцессора. А в противном случае Вы просто напишете очередную библиотеку.

Или мимо тазика?

> это подвласно только языкам с изменяемой семантикой. Разве не так?

В каком месте defmacro изменяет семантику лиспа? И еще см. http://www.haskell.org/yale/papers/icsr98/index.html

> А в противном случае Вы просто напишете очередную библиотеку.

Библиотеки могут быть разные. См. например Parsec (Text.ParserCombinators.Parsec из иерархических библиотек Haskell). Библиотеки комбинаторов позволяют встроить DSL в несущий язык.

>Только разве что написанием препроцессора

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

> Что в питоне макр нету, что в перле их не наблюдается. => С гибкостью у них одинаково плохо.

В перле есть механизм фильтров. Пример: Switch.pm.

> В каком месте defmacro изменяет семантику лиспа?

В том, что от самого лиспа остаются (могут остаться) только скобочки :) А есть еще readtable...

> И еще см. http://www.haskell.org/yale/papers/icsr98/index.html

Посмотрел одним глазом. Последний абзац параграфа 3.1 в pdf-е.

В лиспе нельзя уйти только от одной вещи - от списка. Все остальное - в Ваших руках.

Тогда уж и от функции и (или) от макры

> Тогда уж и от функции и (или) от макры

от представления "единицы кода" в виде списка - да. Это много? :)

на два.