Lisp

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

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

нормальной orm

Потребность в orm, скажем так, спорна. Например, у меня обычно все данные тащатся из базы с помощью хранимок, поэтому профита от orm нет. А если работать с монго или т.п. то тоже не понятно зачем он нужен. В общем, на любителя.

hu.dwim.perec

Че-то не гуглится документация и examples...

Ну и модульных фреймворков с батарейками

hu.dwim или quicklisp

Батарейки для вебни, а не вообще

активным сообществом.

С этим хуже.

Ну, то есть придется велосипедить, спотыкаться о грабли и не надяться на хоть сколько-нибудь оперативные багфиксы. А ради чего, собственно?

hu.dwim.perec

Че-то не гуглится документация и examples...

http://pinterface.livejournal.com/34706.html

Остальные примеры в тестах в самой библиотеке.

Батарейкопроблемы, рас. Два - для фреймворка на лиспе уже не покатит просто быть клоном рельс (нафига? рельсы уже есть и работают - им самим рук не хватает), в фреймворке должна быть киллер-фича и желательно не одна. Сейчас ничего подобного нет. И, на сколько я знаю, кроме restas'a нет вообще ничего.

Потребность в orm, скажем так, спорна.

Меня бы даже устроил уровень postmodern'a +-, но чтобы этот orm был полным и актуальным, чтоб не приходилось как в джангах всяких запросы чуть сложнее простых фигачить через raw-sql. Ну и одного постгреса, естественно, мало.

Например, у меня обычно все данные тащатся из базы с помощью хранимок

Согласись, тоже весьма:

на любителя.

активным сообществом.

С этим хуже.

У ruby до rails вообще считай никакого сообщества не было. Стоило появиться слегка посеребренной пуле - сразу набежали.

hu.dwim или quicklisp

Батарейки для вебни

так hu.dwim для неё и есть

http://dwim.hu/live/hu.dwim.presentation/ http://dwim.hu/live/hu.dwim.web-server/ http://dwim.hu/live/hu.dwim.model/ http://dwim.hu/live/hu.dwim.wiki/

Меня бы даже устроил уровень postmodern'a +-, но чтобы этот orm был полным и актуальным, чтоб не приходилось как в джангах всяких запросы чуть сложнее простых фигачить через raw-sql. Ну и одного постгреса, естественно, мало.

Посмотри http://dwim.hu/live/hu.dwim.perec/test/query/ Там вроде покрыты все частые случаи. А с БД он работает через http://dwim.hu/live/hu.dwim.rdbms/ . Поддерживается Oracle, PostgreSQL, SQLite. При необходимости и наличии клиентской библиотеки можно прикрутить другие СУБД.

даже сейчас я могу выделять на разработку идей 250-300 000 р ежемесячно

Миллионеры ITT! Продал книгу или дом у озера? :)

Ни одной вакансии

Где?

Есть идея проекта игровой тематики. Хочу использовать Lisp. Разумно?

Да, удобный язык для этого.

какие минусы и с какими сложностями и трудностями прийдется столкнуться?

Привязки к либам будете писать сами.

Ok спасибо, ознакомлюсь. Поддержка oracle - звучит неплохо, надо поковырять.

Привязки к либам будете писать сами.

Ну нифига. lispbuilder-sdl есть и шо ещё надо?

а я-то думал, чё не работает лиспер.ру? Оказывается, лор-эффект :)

archimag, а ты что скажешь о hu.dwim? Смотрел?

Пиши на плюсах. Там ООПом и не пахнет.

lispbuilder-sdl

Оно живо и работоспособно?

Хватает,дом как раз планирую приобретать. Программирование и математика помогают в моей работе.

Почему не какая-то более веб-готовая функциональщина? Erlang, например. Что значит «игровой тематики» - очередной бложик с прохождениями игр или сама игра?

1)Ни одной вакансии.Почему?

В рашке вообще плохо с функциональными языками. Будь то лисп, будь то хаскел. Рашепроблемы

2)Преимущества и недостатки для web?

Особо в тему не посвящен, но что то подсказывает мне что преимуществ нет/очень мало

3)Инфраструктура?

Специфичная

4)Есть идея проекта игровой тематики. Хочу использовать Lisp. Разумно?

Если использовать модульность — очень даже. Например, движок на С++/Java а тот же ИИ на Lisp. Игру на голом лиспе плохо представляю, но мне мне уже жалко разработчика и других людей, которые будут поддерживать код.
Учил Lisp что бы освоить матчасть ИИ. Но был не готов и бросил. В принципе не жалею ни что бросил (не думаю что пригодиться), ни что потратил на него время(интересное узнал, понял лямбды возлюбил многоскобочность))))),etc)

Сама. Самая настоящая.С клиентским десктопом. Да нравится мне всего лишь Лисп.

для racket

А я вам про схему говорил, а не про рэкет.

что скажешь о hu.dwim?

Вещества...

Сколько говорить уже, что лисп к ФП мало относится

ЛОЛШТО?

А ты зря проигнорировал мое упоминание о PAIP. Там есть неожиданный ответ для тебя.

Вещества...

А конкретнее, хотя бы тезисно, можешь?

Вещества...

А конкретнее, хотя бы тезисно, можешь?

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

Динамическая типизация очень быстро намекает тебе на полезность статической типизации

fixed

Может и не живо, но работает)

упоминание о PAIP

Не, не читал. Там что, утверждается, что CL в частности - это ФП?

упоминание о PAIP

Не, не читал. Там что, утверждается, что CL в частности
- это ФП?

Это просто очень старая книга, плюс написанная скорей математиком, чем программистом.

ЛОЛШТО?

Два чая вам. До сих пор не могу понять, откуда взялся этот идиотский миф, что «лисп к ФП мало относится».

Не фапать на ФП двумя руками сразу и вприсядку != не любить ФП

До сих пор не могу понять, откуда взялся этот идиотский миф,
что «лисп к ФП мало относится».

Не лисп, а Common Lisp. Что бы понять откуда взялся этот «миф» достаточно посмотреть на исходный код библиотек, доступных через тот же quicklisp.

Не лисп, а Common Lisp. Что бы понять откуда взялся этот «миф» достаточно посмотреть на исходный код библиотек, доступных через тот же quicklisp.

Цикл разработки может быть таким. Начинаем с функционального кода. Такой код проще тестировать. Затем вводим деструктивные оптимизации. Поэтому ты, скорее всего, не увидишь чистого функционального кода даже там, где начинали с него.

Это просто очень старая книга, плюс написанная скорей математиком, чем программистом.

Кстати, не такая старая. Более того, она была снова перепечатана в 2011 году. Выглядит совершенно как новая :)

Использованные в PAIP термины практически не изменились вплоть до сегодняшнего времени. На протяжении всей книги, меня постоянно удивляло, что Piter Norgiv предельно корректен и точен в отношении всего, что касается формулировок, терминов и выводов (да, наверное, математик). Он не позволяет себе вольностей и всякого рода измышлизмов, которые присутствуют у других авторов, например, в On Lisp by Paul Graham и Let over Lambda by Doug Hoyte.

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

Не фапать на ФП двумя руками сразу и вприсядку != не любить ФП

Дело в том, что CL позволяет писать в стиле ФП, но также позволяет и не писать. Точно также как и другие развитые ЯП общего назначения. Так ведь можно говорить что, неапример, perl имеет отношение к ФП или C++.

До сих пор не могу понять, откуда взялся этот идиотский миф, что «лисп к ФП мало относится».

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

Плюс масла в огонь добавляют хаскелисты своим очевидным радикализмом. Доходит до того, что для некоторых из них, если язык не ленивый, то уже никак не может быть функциональным. Ведь тогда появляется зависимость от порядка действий, а значит императивность. Очевидно, что те же scheme и clojure гораздо императивнее, чем haskell. Но для хаскелистов императивность почему-то противопоставляется функциональному стилю, хотя по идее должна противопоставляться лишь декларативному. В общем, единой терминологии нет, в разных языках она разная, но по какой-то необъяснимой причине терминология хаскелистов стала доминирующей в наше время.

Во-первых, вам ничто не мешает использовать ФП в питоне. Во-вторых, CL имеет отношение к ФП не намного больше, чем питон.

ИМХО бред. ФП это костыль в пайтоне. Не настолько костыльный, как в C++11, но тоже костыль.

ФП это костыль в пайтоне

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

А вот скажите лучше, что такое есть в CL, для поддержки ФП, чего нет в питоне или перле?

что такое есть в CL, для поддержки ФП, чего нет в питоне или перле?

1. оптимизация хвостовых вызовов (не в стандарте, но почти во всех реализациях)

(defun iter (n) (when (> n 0) (...) (iter (- n 1))))

будет выполняться также эффективно, как цикл

2. Нормальные лямбды.

3. Нормальные замыкания.

что такое есть в CL, для поддержки ФП, чего нет в питоне или перле?

Выражения. Для стиля ФП должно быть важно, чтобы все или почти все было выражением, чтобы не было statement. Statement вынуждает использовать деструктивное присваивание.

И честно говоря, не понимаю этого ажиотажа вокруг ФП. Для стиля ФП не так уж и много надо: писать код, используя чистые функции. Раньше этим так не заморачивались. В том же PAIP слово «функциональный» встречается очень редко, хотя стиль ФП явно подразумевается. Обычно сначала пишется код в этом стиле, а потом код оптимизируется деструктивными операциями.

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

1. оптимизация хвостовых вызовов (не в стандарте, но почти во всех реализациях)

в перле есть

2. Нормальные лямбды.

тоже в перле есть

3. Нормальные замыкания.

и это в перле есть.

Перл - ФП язык?

Выражения. Для стиля ФП должно быть важно, чтобы все или почти все было выражением, чтобы не было statement. Statement вынуждает использовать деструктивное присваивание.

С этим я вынужден согласится

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

Вот об этом я и говорю. Если посмотреть, как тут уже предлагали, исходники библиотек для CL - такой уровень ФП легко достижим в любом современном языке. А кода на CL, с ФП как в хаскеле, например, я вообще не видел. Вот вы монады используете в CL?

2. Нормальные лямбды.
3. Нормальные замыкания.
и это в перле есть.
Перл - ФП язык?

Да. Пруф: http://perldesignpatterns.com/?LambdaClosure

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

можно. С этим я и не спорил.

А вот скажите лучше, что такое есть в CL, для поддержки ФП, чего нет в питоне или перле?

в отличие от CL, пайтон изначально не является языком с ФП. Там такое-же костыльное ФП, как ООП в C++. Только хуже, ибо синтаксис C достаточно гибкий и тупой, что позволяет легче костылить к нему костыли.

Выражения. Для стиля ФП должно быть важно, чтобы все или почти все было выражением, чтобы не было statement. Statement вынуждает использовать деструктивное присваивание.

++

с ФП как в хаскеле, например

Посмотри xmonad. Там ФП как в CL.

Вот вы монады используете в CL

Да. В виде блока (progn ...)

Statement вынуждает использовать деструктивное присваивание.

А монада ST не вынуждает?

Да.

Вот именно. А теперь вопрос: если ТС хотел ФП в вебе, зачем брать CL в котором полтора живых фреймворка, если с тем же успехом можно качать скилл ФП на перле, руби или (о боже) похапе?

пайтон изначально не является языком с ФП.

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

пайтон изначально не является языком с ФП.

Ну и кому до этого есть дело, если его все-таки можно использовать для ФП. Раз уж в язык запилили замыкания и функции-данные, то наверное это не с проста.

если ТС хотел ФП в вебе

Вообще-то в топике «Решил прокачать скиллы на CL.... Хочу использовать Lisp...». А ФП уже вторично как противопоставление основного подхода лиспа против мейнстримового ООП.

Всё-таки в CL основной инструмент цикла в стандартной библиотеке mapcar, а в Perl for(...). Также как регекспы удобней учить на Perl, несмотря на то, что соответствующие библиотеки уже даже в Си есть. А если именно «ФП в вебе», то брать надо Haskell (плюс какой-нибудь Happstack).