common lisp

Python

императивный

Да

лаконичный

Да

кроссплатформенный

Да

с динамической типизацией

Да

с развитой инфраструктурой

Да

продукты которого жрут минимум памяти

Более-менее

адекватные по скорости

Скорость адекватна для решаемых задач

можно с вкраплениями функционального программирования

Да

совсем хорошо, если компилируемый

Да

под такие противоречивые требования только python подходит

Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа (по типу Eclipse RAP/RCP)

groovy

>Python

совсем хорошо, если компилируемый

Да

вы в этом уверены?

Абсолютно уверен, на все 100%.

Python

Питон - для девочек. Ну и tailgunner'а.

Groovy, Grails. Сейчас фапаю.

> Ну и tailgunner'а.

Ты так говоришь, словно у него короткие волосы.

> Питон - для девочек. Ну и tailgunner'а.

Ч0рт, куда ж попрятались все эти девочки?

А под список требований Python вполне подходит.

А под список требований Python вполне подходит.

Pythin уныл ;)

Rebol

.

> Ч0рт, куда ж попрятались все эти девочки?

В поисках жены-питонистки?

В поисках жены-питонистки?

знаешь как питон заглатывает кролика? ммм...

Быстрый ты слишком %)

Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа

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

JavaScript интересен как язык своей гибкостью, прототипами, this зависящим от контекста и функциональщиной. Под твои условия не попадает. :)

> Pythin уныл ;)

Да ладно! Иной раз смотришь на код — обхохатываешься!

Лорчую.

tcl/tk

>Под твои условия не попадает. :)

единственное под что он не попадает - это под твои фантазии:

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

а

создание серверных, десктопных и веб-приложений

JS умеет и хорошо.

>под такие противоречивые требования только python подходит

ммм, а в чем противоречия, не укажете?

да, Python подходит.
Собственно сейчас у меня на рассмотрении Python, Groovy и JS.

да, записал.
Groovy мне наверное ближе своей Java-инфраструктурой (платформой), в сравнении с Python.

clojure

пошел читать

> императивный, лаконичный, кроссплатформенный ЯП, с динамической типизацией, с развитой инфраструктурой, продукты которого жрут минимум памяти, адекватные по скорости, можно с вкраплениями функционального программирования

Под описание подходят несколько жизнеспособных современных языков. Давайте разберем три из них: Python, JavaScript и один JVM-based, например, Groovy. Как языки они все весьма неплохи и должны удовлетворить вашим требованиям, поэтому останавливаться на чисто языковых «фичах» мы не будем.

Python: Самая большая проблема - с производительностью. Приличного JIT-компилятора нет до сих пор, перспективы PyPy неясны, проект Unladen Swallow почил в бозе. Потребление памяти среднее. Инфраструктура на четверочку с плюсом: стандартный рантайм довольно богат, есть довольно большое количество сторонних библиотек, но не все они хорошо поддерживаются. Особенно в контексте миграции на Python 3 и вообще постоянно меняющихся спецификаций языка.

JavaScript: сразу будем рассматривать две реализации: Seed (базирующийся на вебкитовом JavaScriptCore) и GJS (SpiderMonkey). Оба обладают хорошими, зрелыми JIT-компиляторами, над которыми постоянно работают команды WebKit и Mozilla, соответственно (и, надо сказать, от этой гонки браузеров сам язык только выигрывает). Стандартный runtime минималистичен, но благодаря GObjectIntrospection открывается вся мощь платформ GLib/GTK+/GNOME и кучи библиотек, использующих парадигму GObject. Поддержка в Anjuta IDE. Итог: инфраструктура на пятерку с минусом.

Наконец, Groovy. Все плюсы и минусы Groovy - это плюсы и минусы JVM. О них, полагаю, подробно рассказывать не надо, так как вы производите впечатление человека, знакомого с Java. Плюсы: мощный JIT и «батарейки», минус - время запуска и потребление памяти. Отличная поддержка в IDE. Итог по инфраструктуре: 5+.

> совсем хорошо, если компилируемый

Вы хотите статической компиляции в ELF? Этому требованию из динамических языков удовлетворяют только некоторые коммон-лиспы и схемы. Но при этом они имеют кучу родовых травм, нивелирующих этот «бонус». (О них, разумеется, невдомек вбрасывающим про Common Lisp в первом же комментарии Reset'ам - потому что они либо не писали на Common Lisp ничего сложнее «Hello, World!», либо явно троллят. Следовательно, «disregard them, they suck cocks». (C))

Собственно, и сама «бонусность» тут сомнительна. Для обеспечения динамизма в статически компилированном коде приходится прибегать к ухищрениям в виде 60-мегабайтного рантайма со встроенным ad hoc, informally-specified, bug-ridden, slow implementation of half of GCC. Более адекватный путь, выбранный цивилизованным IT-миром - JIT-компиляция. Из выше рассмотренных языков стабильным и зрелым JIT-компилятором располагают, напоминаю, JavaScript и JVM-based языки.

> Цель - создание серверных, десктопных и веб-приложений. Будет Ъ, если можно использовать один код для веб и десктопа (по типу Eclipse RAP/RCP)

Требование довольно экзотическое. Полагаю, проще будет доточить тот же RAP/RCP до возможности скриптинга его на Groovy. Но сперва поинтересуйтесь, вдруг такое уже возможно - тогда тема должна быть сразу же закрыта.

Можно подробнее про «родовые травмы» ? Про 60 мегабайт рантайма это не аргумент.

> Python: Самая большая проблема - с производительностью.

Ты или теоретик, или пытаешься использовать Питон не по назначению.

Теоретик без практики он.

> Можно подробнее про «родовые травмы» ?

Охотно. К самому языку это слабо относится: язык как язык, хотя и со своими тараканами. Отметим проблемы с переносимостью между реализациями и платформами. Но в основном претензии относятся к последнему пункту - инфраструктуре. Хорошо, что ТС уделяет ему особенное внимание: это свидетельствует о зрелости специалиста. Адепты же лиспа, наоборот, этот пункт устойчиво игнорируют. Посему ТСу будет предложены Emacs+SLIME вместо IDE, а вместо библиотек - кучки неподдерживаемого и непортируемого кода с CLiki. Ну или другой вариант: везде использовать FFI. Но в чем тогда профит от использования лиспа? В том же Питоне гораздо более приличное FFI, да и нет в нем особенной надобности. В макросах, метапрограммировании и мифической «выразительности»? Другие фичи, типа лямбда-выражений (которые лисперы привыкли незаслуженно присваивать себе), уже давно есть в во всех нормальных языках.

Про 60 мегабайт рантайма это не аргумент.

С этим надо идти к ТСу. Если его устроит оверхед в 60 метров непонятно на что - то почему бы и нет. Тут лисперами на ура используется риторика о дешевизне памяти, обычно используемая апологетами Java. Не забудем мы и про относительно легковесный ECL, но он, по утверждению самих лисперов же, сильно кастрирован и вообще проблемен.

Итак, если ТС готов пожертвовать ради сомнительной выгоды использования макросов а) нормальными IDE, 2) богатым рантаймом и качественными библиотеками, 3) переносимостью, 4) отчасти собственной психикой - то добро пожаловать в розовый мир Коммон Лиспа!

спасибо большое за трактат. учту.

Вообще, лучше меня о «родовых травмах» расскажут сами лисперы. Курите многочисленные посты того же den73, в которых он описывает массу фатальных проблем, из-за которых он вынужден был отказаться от лиспа (кстати, в пользу Python). Пробегал тут также юноша бледный, который пытался применять Common Lisp в махровом enterprise - очень неплохо все расписал после прозрения. Попытки запихнуть лисп в числодробильню наталкивались на непреодолимые архитектурные ограничения, связанные с tagged values, и так далее.

>С этим надо идти к ТСу.

все ничего, но

2) богатым рантаймом и качественными библиотеками, 3) переносимостью

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

Учи яваскрипт. До петухона всегда успеешь добраться, а вот как доберешься скажешь что js не нужен.

> Ты или теоретик, или пытаешься использовать Питон не по назначению.

Лично я питон не пытаюсь использовать :) Хотя вру. Использовал три раза в жизни. Для stored-процедуры под PostgreSQL, в качестве «клея» для NumPy, и для небольшого системного демона. Для _моих_ задач производительности Python вполне хватало, в чем я и отдавал себе отчет.

Но ТС требует «адекватной производительности». Изучив задачи и бэкграунд ТСа, делаем справедливый вывод, что требуется производительность, сравнимая с Java. А питон там и рядом не валялся. Посему проблемность питона в этом плане следует воспринимать по отношению к JVM.

Чистая логика, никакого мошенства.

> Теоретик без практики он.

...только почему-то этот «теоретик» знает о лиспе и его проблемах больше, чем многие здешние «лисперы» ;) Если что, я не о тебе конкретно.

>Учи яваскрипт. До петухона всегда успеешь добраться, а вот как доберешься скажешь что js не нужен.

JS нужен, ровно до той поры, пока он монополист в www-скриптинге. как только все мажорные браузеры запилят «петухон», тогда можно говорить о ненужности JS. мне не нравится костыльность некоторых решений в JS, связанных с ООП (другое дело - нахера там ООП с костылями? этот вопрос прежде всего авторам многочисленных библиотек, которые подстраиваются под пхппистов и жабистов)

> спасибо большое за трактат. учту.

Рад помочь, обращайтесь.

реальные ответы на них можно получить только из практики

Заметьте, не только из своей. Рекомендую внимательно прислушиваться к постам тех немногих здешних обитателей, кто реально пытается использовать лисп на практике. Среди них есть вполне адекватные люди, которые не стесняются вскрывать проблемы и обращаться за помощью.

Да и сам язык мне как-то не очень по духу, тяжело читать (хотя, это дело привычки)

Тут, в общем, дело не в привычке и не «по духу». Гомоиконность лиспа - палка о двух концах. С одной стороны, она открывает довольно богатые возможности метапрограммирования, с этим никто не спорит (правда, непосредственный профит от этого - вещь сомнительная и вообще подлежит отдельному обсуждению). С другой стороны - вам придется постоянно тратить кванты своего мозгового времени на парсинг кода, потому что семантически различные элементы никак не выделены синтаксически. В «более нормальных» языках это не так. Поэтому синтаксис языка крайне важен, что бы там ни трындела «илита» о том, что-де «синтаксису языка уделяют внимание только быдлокодеры, труЪ-джедаям важна только семантика».

>> Ты или теоретик, или пытаешься использовать Питон не по назначению.

Лично я питон не пытаюсь использовать :)

В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Но ТС требует «адекватной производительности». Изучив задачи и бэкграунд ТСа, делаем справедливый вывод, что требуется производительность, сравнимая с Java.

Гладко излагаешь. Но ты знаешь не бэкграунд ТС, а только используемую им платформу. А веб, о котором ТС упомянул, по определению I/O-bound.

Smalltalk

Прочёл все посты. Удивился. Неужели нужно такое обильное словоизлияние, чтобы сказать: «ТС, для твоих требований подходят Groovy, JS, в меньшей степени Python, но никак не Lisp и его клоны».

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

> В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Как известно, не надо быть поваром, чтобы понять, что мясцо слегка подтухло ;) К тому же, «не пытаюсь» относится к настоящему времени, а упоминание о прошлом опыте ты ловко проигнорировал.

А веб, о котором ТС упомянул, по определению I/O-bound.

Но это не значит, что он _только лишь_ I/O-bound. Видимо, мой опыт с веб-программированием несколько богаче твоего (nothing personal), поэтому я и воспринимаю этот термин немножко шире. Hint: transaction processing, business rules, expression language, business intelligence.

> Неужели нужно такое обильное словоизлияние, чтобы сказать: «ТС, для твоих требований подходят Groovy, JS, в меньшей степени Python, но никак не Lisp и его клоны».

Я привык аргументировать свою точку зрения. Прошу прощения, если «словоизлияние» было слишком «обильным», знаете ли, преподавательское прошлое дает о себе знать. И да, вас никто не заставлял читать мой трактат.

И сладострастно обсасывать недостатки лиспов тоже не было необходимости.

Вы склонны видеть эмоции там, где есть только голые факты.

Те, кому лисп действительно нужен, и без того про них знают, а тем, кому лисп не нужен, это не интересно.

Вы забываете про третью категорию: молодежь и новички, способные поддаться пустопорожней лисп- и ФП-пропаганде. Собственно, все это «обсасывание», как вы изволите выражаться, предназначалось исключительно для них.

> Курите многочисленные посты того же den73,

он вынужден был отказаться от лиспа (кстати, в пользу Python)

Дык вроде бы наоборот констатировал что Pythin для инкрементной разработки не подходит и остался на синтакически расширеном CL.

>> В этом случае разумный человек (ты выбрал именно такой имидж) воздержался бы от высказывания своего мнения.

Как известно, не надо быть поваром, чтобы понять, что мясцо слегка подтухло ;)

На лурк.

А веб, о котором ТС упомянул, по определению I/O-bound.

Но это не значит, что он _только лишь_ I/O-bound

В своих предположениях ты заходишь всё дальше.

Видимо, мой опыт с веб-программированием несколько богаче твоего (nothing personal)

Мой, как ты говоришь, «бэкграунд» - системный программист.

Hint: transaction processing,

I/O-bound.

business rules

Jess, Drools и прочее? Там интерпретатор на Яве - качественно от Jython не отличается.

expression language

Не знаю, что это, но предполагаю еще один интерпретатор.

business intelligence.

Матобработка большого количества данных? Делается на numpy.

(попытка предыдущего наезда деликатно проигнорирована)

Дык вроде бы наоборот констатировал что Pythin для инкрементной разработки не подходит и остался на синтакически расширеном CL.

Это, на самом деле, не главное. Главное - то, что он открыто, компетентно и много говорил о проблемах Common Lisp, которые он массово огребал во время своей практики. Инкрементальная разработка - достоинство лиспа (хоть и не безусловное), и, полагаю, это достоинство в случае Дена73 перевесило все недостатки.

ТС же на такие жертвы не готов.

> И да, вас никто не заставлял читать мой трактат.

Ты понимаешь, какая штука (извини, уже привык на лоре тыкать) - в отличие от многих «персонажей» я сначала внимательно читаю то, что меня заинтересовало, и после этого имею право высказать своё мнение. Ходить на форум и читать только «по верхам» - это круто, да-а. Желаешь, чтобы тебя читали как можно меньше людей?

Вы склонны видеть эмоции там, где есть только голые факты.

Я склонен видеть то, что вижу. Кто-то знает об этом лучше, чем я?

Вы забываете про третью категорию: молодежь и новички, способные поддаться пустопорожней лисп- и ФП-пропаганде. Собственно, все это «обсасывание», как вы изволите выражаться, предназначалось исключительно для них.

Да брось ты это лицемерие. Я не понимаю смысла агиток как «за лисп», так и «против лиспа». Если человек выбирает инструмент для работы и серьёзно подходит к этому, то он сам найдёт инфо про инструмент и разберётся: нужен он ему или нет. А прочие пусть сами «шишки набивают».

> Мой, как ты говоришь, «бэкграунд» - системный программист.

Ну, вот с этого и надо было начинать. Ты же не будешь утвеждать, что web- и enterprise-задачи имеют свою, сильно отличающуюся специфику?

Hint: transaction processing,

I/O-bound.

Да что ви гойворите. Системный погромист детектед. :)

Там интерпретатор на Яве - качественно от Jython не отличается.

Ага, значит, уже всплыл Jython ;)

Не знаю, что это, но предполагаю

Не читал, но осуждаю :) А предположение верное.

Матобработка большого количества данных? Делается на numpy.

А как работает связка Jython+NumPy? Если там все в порядке, то я признаю, что Jython - очень хорошая кандидатура для всего вышеописанного.

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

Заинтересовался, прочитал, оказалось неинтересно. Ну, и кто тут виноват?

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

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

> Ты же не будешь отрицать, что web- и enterprise-задачи имеют свою, сильно отличающуюся специфику?

fixed

> он открыто, компетентно и много говорил о проблемах Common Lisp, которые он массово огребал во время своей практики.

Опять же надуваешь муху размером с слона. Он давно говорил об отсутсвии webdev библиотеки. И имел несколько претензий к синтаксису в районе let-а и доступа к слотам.

А вот компилируемую динамиу найти довольно сложно. Ну это так к слову.