Что круче: Лисп или Хаскелль?

> Ты не видишь, что у нас в конторе при многомегабайтных исходниках

не используются сторонние библиотеки

Но допустим есть достаточно изолированные области, для которых ничего стороннего и не надо. Или может дело в многомегабайтных исходниках. Но вот я хочу понять, что же «всё родное»? О чем речь? Какие «батарейки из поставки LW» вы используете? Или библиотеки придумали демоны и реально они никому не нужны?

Зачем тебя просвещать, если ты какую-то чушь про красивость

GUI и сопутствующий нафталин несёшь?

Ну, например, что бы я её не нес больше? А то ведь и непросвещённым и буду дальше ересь всякую нести.

А какие-то объективные недостатки встречались?
Ну или просто какие минусы замечены :)
Интересует практическая сторона - на красивости/проблемы интерфейса в целом пофиг.

Ну вот так деньги и зарабатывают - рраз, и $1500.

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

> А какие еще есть перспективные в смысле зарабатывания денег области

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

веб?

Любая нетривиальная логика? Сервера приложений это не только и не сколько веб, сколько логика.

Но допустим есть достаточно изолированные области, для которых ничего стороннего и не надо. Или может дело в многомегабайтных исходниках. Но вот я хочу понять, что же «всё родное»? О чем речь? Какие «батарейки из поставки LW» вы используете? Или библиотеки придумали демоны и реально они никому не нужны?

Если ты троллишь, то уныло ;)

Вот смотри, для использования в программе гуйни, sql, сети - т.е. типичной такой программы, в LW совсем не надо использовать сторонние библиотеки. А ещё там delivery нормально работает.

Ну, например, что бы я её не нес больше? А то ведь и непросвещённым и буду дальше ересь всякую нести.

А ты и так будешь массам позицию своих тараканов освещать, а не моих.

Все те, которые прибыльные и без CL, за исключением:
тех, код которых захочешь быстро на кого-то спихнуть (без обучения последнего, причем, часто с кардинальным переобучением)
тех, где огромный профит лежит в использовании кучи батареек
тех, где CL просто не эффективен (список последних уже так или иначе утрясли)

кто-то меня поправит?

А какие-то объективные недостатки встречались?

Да особо никаких нет, если от лиспа не требовать перестать быть лиспом. В LW всё просто работает, пока не начнёшь opensource'ными библиотеками пользоваться - в них LW плохо поддерживается. Даже тот же slime из коробки не умеет who calls, who sets, etc, хотя в LW это можно сделать.

ясно, спасибо

ясно, спасибо

У нас в конторе новый товарищ появился, он на прошлой работе с Аллегро работал, и говорит, что там тоже всё очень хорошо. Если закрыть глаза на то, что Лиспворкс просто единовременно денег с тебя хочет, а Франц кровь сосёт.

> Вот смотри, для использования в программе гуйни, sql, сети - т.е.

типичной такой программы, в LW совсем не надо использовать сторонние

библиотеки.

Хм, этакий мини-Qt? Я тут как раз по поводу Qt недавно с одним человеком спорил. Он мне говорил, что там всё есть. И везде работает. Ага.

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

гуйни, sql, сети

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

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

Если тебе подходит питон, используй питон. Мы пишем софт на лиспе, нам подходит лиспворкс, он нам нравится, у нас есть на него деньги. Какие проблемы?

Мы пишем софт на лиспе, нам подходит лиспворкс, он нам нравится, у нас есть на него деньги. Какие проблемы?

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

> Какие проблемы?

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

Вот у меня есть проблема, мне не хватает библиотек (ну да, у меня нет LW, но там нужных мне библиотек тоже нет). И меня в этой связи беспокоит отсутствие роста интереса к CL - никто не приходит писать новые библиотеки.

> с Аллегро работал, и говорит, что там тоже всё очень хорошо

А ты говоришь всё хорошо, т.е. в комплекте есть какие-то либы для GUI, БД и сокетов, супер, больше настоящим джедаям ничего и не надо. Если тебе больше ничего и не надо (мало ли, может правда не надо), то какое тебе дело до какого-то там тренда? Пиши себе спокойно, радуйся. Мне вот есть, потому что мне нужны библиотеки.

Просто позиция «в CL всё хорошо, просто этого никто не знает и надо об этом всем рассказать» - ущербна, нихрена не всё хорошо, но есть светлые моменты, которые могу окупать имеющиеся недостатки. Нельзя же отрицать очевидного (проблемы). Это же все видят и иначе как троллинг рассказы про «всё хорошо» не воспринимают.

1. Для Clojure существуют плагины под самые популярные IDE (Eclipse, NetBeans, IntelliJ), режим для vim, конечно-же режим для emacs вместе со SLIME. Для тех, кто хочет «оп! - и работаю» есть готовый vagrant-образ с настроеным эмаксом для разработки.
2. Clojure стал третьим языком, который поддерживает Heroku (после Ruby и Node.js). Говнокрестами там, ясен хрен, и не пахнет.
3. Твиттер недавно приобрел Backtype (авторов Cascalog и Storm, и соответственно, сервиса Backtweets), у которых главный язык разработки - Clojure.
4. На Clojure написан backend для этой штуки http://www.automatoon.com/ - сервиса для создания HTML5-анимации прямо из браузера.
5. Для Java написано батареек больше, чем под что либо когда либо. Все они автоматически входят в Clojure.

Ну что, будем спорить дальше, что скобки говно, денег на них не заработаешь и вообще они никому не нужны?

Clojure фигня, на LW __все__ работает ;)

Одна беда - Clojure не CL.

Понимаю твой сарказм. Меня самого в свое время очень расстраивали многие вещи в Common Lisp. Но Лисп не единым CL жив.

Но Лисп не единым CL жив.

бесконечно плюсую

> Для тех, кто хочет «оп! - и работаю» есть готовый vagrant-образ с настроеным эмаксом для разработки.

если не затруднит - можно ссылку на скачивание?

Да, это так. Но сейчас Clojure покрывает большую часть use-case'ов Common Lisp'а, таких как написание сложной серверной логики. При этом - предоставляя более обширный и гибкий инструментарий (наличие того-же Hadoop и MapReduce). Единственная оставшаяся сфера его применения (как я вижу) - это написание на CL вещей вроде того-же Hadoop. Да вот только сомневаюсь, что застану в своей жизни.

Пожалуйста: https://github.com/Seajure/emacs-clojure-vagrant
Если вы не знакомы с Vagrant, то вам сюда http://vagrantup.com/ Warning: чтобы установить vagrant, вам придется установить ruby. Это минус, да.

Ну и VirtualBox, что еще хуже:).

> Пожалуйста: https://github.com/Seajure/emacs-clojure-vagrant

спасибо, завтра попробую поразбираться

Да, не только ruby :) но за ссылку спасибо!
root# gem install vagrant
Fetching: archive-tar-minitar-0.5.2.gem (100%)
Fetching: erubis-2.7.0.gem (100%)
Fetching: json-1.5.3.gem (100%)
Building native extensions. This could take a while...
Fetching: mario-0.0.6.gem (100%)
Fetching: net-ssh-2.1.4.gem (100%)
Fetching: net-scp-1.0.4.gem (100%)
Fetching: i18n-0.5.0.gem (100%)
Fetching: thor-0.14.6.gem (100%)
Fetching: ffi-1.0.9.gem (100%)

Зачем каждой задаче жрать 60 Мб? Пусть будет один рантайм на все приложения.

> Зачем каждой задаче жрать 60 Мб? Пусть будет один рантайм

на все приложения.

Что бы если зависло/упало, то сразу всё? Здорово, мне нравится.

спасибо, завтра попробую поразбираться

Видимо, я всё же поспешил советовать эту штуку, сам не попробовав. Там таки немало возни + оно скачивает полноценный виртуальный образ, и ставится долго.
Если хочешь попробовать clojure, начни лучше всё-таки с плагина к Эклипсу Counterclockwise. http://code.google.com/p/counterclockwise/ Вот видео, покрывающее базовую установку: http://vimeo.com/channels/fulldisclojure#9223070 Сорри за дезинформацию изначально, я этот Vagrant заметил краем глаза в гугл-группе, думал что они там всё удобно и легко сделали. Но там еще пока сыровато.

Ты где там лисп нашел?

кложура - не лисп, курица - не птица.

> Что бы если зависло/упало, то сразу всё? Здорово, мне нравится.

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

> Ты где там лисп нашел?

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

>Но сейчас Clojure покрывает большую часть use-case'ов Common Lisp'а

Не далее чем сегодня ковырял программулину на Clojure, написанную мною более года назад. Ессно, я напрочь забыл как она работает. Неблагодарное это дело, скажу я вам. А вот на хаскеле — никаких проблем не возникает.

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

Кстати, к CL все вышеперечисленное не относится.

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

> как это я проглядел такой тред

Так ещё всё в разгаре, присоединяйся ;-)

Не далее чем сегодня ковырял программулину на Clojure, написанную мною более года назад. Ессно, я напрочь забыл как она работает. Неблагодарное это дело, скажу я вам. А вот на хаскеле — никаких проблем не возникает.

Не так давно смотрел программу на Хаскелле, которую написал по учебнику некоторое время назад. Неблагодарное это дело, скажу я вам. А вот на clojure - никаких проблем не возникает. Наверное потому, что я на нём пишу, а на хаскелле нет, но я не уверен.

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

Сударь, я офигеваю от описания вашего опыта использования. Куда вы это у-лю-лю потеряли? macroexpand в три счёта находит все пропавшее у-лю-лю с квазицитированием не там.
Нет, я не спорю, что отладка макросов - это еще то развлечение. Но макросы в clj не отличаются от макросов в CL ничем кроме того, что в clojure безопаснее захват переменных.

> Нет, я не спорю, что отладка макросов - это еще то развлечение.

Рэкетиры со своим макростеппером смотрят на общелисперов/кложурасов и лукаво улыбаются.

>Рэкетиры со своим макростеппером смотрят на общелисперов/кложурасов и лукаво улыбаются.
With great power comes great responsibility. Гигиеничность - это в какой-то мере хорошо, но это не мой подход.

>Наверное потому, что я на нём пишу, а на хаскелле нет, но я не уверен.

А может быть потому что не прошло достаточно времени?

Нет, я не спорю, что отладка макросов - это еще то развлечение

Или поиск «не того» типа в рантайме? Или когда переписываешь часть программы, и вся программа начинает глючить?

> Гигиеничность - это в какой-то мере хорошо, но это не мой подход.

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

> Или поиск «не того» типа в рантайме?

Этот «поиск» существует исключительно в воспаленном мозге упоротых статикодебилов.

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

>Или поиск «не того» типа в рантайме? Или когда переписываешь часть программы, и вся программа начинает глючить?
Пожалуйста, я глубоко уважаю модель разработки, которая применяется в Хаскелле, и твердо уверен, что она:
1) Имеет свою нишу применения
2) Для определенной группы людей более удобна и эффективна, чем любые другие.
Но прошу вас, не припысывайте мне проблем, которых у меня не возникает.

Да, я согласен, в Схеме одна из самых навороченых макросистем из всех существующих языков. Когда я изучал Racket, мне она очень понравилась. Только мне кажется тут разница просто в идеологии применения макросов.
В Схеме макрос - это полноценный вылизанный член сообщества, которого любят, лелеют и почитают. Он аккуратен и ему не позволено слишком много.
В CL макро - это урановый реактивный ускоритель, стреляющий бензопилами. Его достают в отдельном порядке, никто не гарантирует что он не взорвется в руках, но если уж добьет - то добьет вовсю. И в любом случае, после использования его спрячут и до следующего года не достанут.
(В этом месте я не учитываю тех CLщиков, которые городят макры без разбора. Особенно в CL, где в 90% случаев требуемую функциональность можно получить без макросов)
Это напоминает мне два вида метапрограммирования в C++ - темплейты и олдовые препроцессорные дефайны. Темплейтами пользуются все, они красивы и безопасны; но вот где-то возьмет да и проскочит дефайн, как коммандо - тихо выполнит свою работу, не оставив свидетелей.
Clojure в данном случае относится скорее ко второму подходу, хотя определенные сдвиги в лучшую сторону есть - можно хотя-бы резолвить символы, доступные в компайл-тайме.

Не понимаю, почему сразу все должно падать? :)

А чего операционки тогда не падают? И зачем динамические библиотеки существуют? Вдруг все упадет... Ну ты понял, какую глупость сморозил..

> И в любом случае, после использования его спрячут и до следующего года не достанут.

(В этом месте я не учитываю тех CLщиков, которые городят макры без разбора. Особенно в CL, где в 90% случаев требуемую функциональность можно получить без макросов)

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

Макры в CL тупые и примитивные. Писать их корректно не проблема вообще. Отлаживаются они элементарно. Вот почему все эти убогие функциональщики прекрасно справляются с декомпозицией проблемы на мелкие, простые и понятные функции, а когда до макр дело доходит, городят простыню fortran-style, а потом на всех углах орут, что мол «макры это мощно и круто, но очень опасно и отлаживать невозможно». Дебилы, или как?

Макры точно так же должны разбиваться на простые и примитивные преобразования. Чтобы каждый этап преобразований был понятным, читабельным и, соответственно, легко отлаживался. При таком подходе можно хоть 90% кода в макрах писать, не теряя читабельности и только повышая качество. А если не умеешь - не берить, и не рассуждай. Archimag вот, например, ни хера макрами пользоваться не умеет, и зачем-то про них смеет рассуждать. Позор!

Закон Мерфи

>Макры точно так же должны разбиваться на простые и примитивные преобразования.

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

Это я не хаскеле могу невозбранно склеивать программу из кусков, и система типов отловит практически все ошибки взаимодействия. Да и на CL эта задача решается путем использования CLOS. А в остальной «динамщине» приходится себя вести несколько по-другому.

>Нда-с. Как и положено кложурасам, в макросах ты ни хрена не разбираешься.
ок.
>Вот почему все эти убогие функциональщики прекрасно справляются с декомпозицией проблемы на мелкие, простые и понятные функции, а когда до макр дело доходит, городят простыню fortran-style, а потом на всех углах орут, что мол «макры это мощно и круто, но очень опасно и отлаживать невозможно».
Потому что декомпозиция на мелкие, простые и понятные функции использует примитивы самого языка. Функцию можно передать аргументом. На функцию можно навесить хук. Функции можно добавить контракты. В функции можно прохинтить типы. Макрос - это последняя инстанция, последняя остановка. Пока ты пишешь всё на функциях и используешь нормальные структуры данных, у тебя из уникальных сущностей есть только те, что есть в языке. Когда ты написал макру, у тебя есть язык плюс твоя макра.
>При таком подходе можно хоть 90% кода в макрах писать, не теряя читабельности и только повышая качество.
Тоже как мантру читаешь?
>Archimag вот, например, ни хера макрами пользоваться не умеет, и зачем-то про них смеет рассуждать.
Это одна из тех немногих вещей, в чём я с Архимагом согласен.

В общем, таки правду говорили тут отписавшиеся. Сообщество CL-щиков состоит из трололей и макроманов, которые не хотят признавать своих ошибок и делать что-нибудь по поводу этого. Ясен хрен, что популярность common lisp'а в таких условиях расти не будет.

> А чего операционки тогда не падают?

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

Ну ты понял, какую глупость сморозил..

Да, я понял, что вы не в теме.

> При таком подходе можно хоть 90% кода в макрах писать, не теряя

читабельности и только повышая качество.

Качество чего? Попробуйте разбить проект на несколько библиотек и начать менять макросы то здесь, то там. Надоест очень быстро. Вообще на таком уровне может рассуждать только тот, кто ничего серьёзней «Hello world» не писал.

Archimag вот, например, ни хера макрами пользоваться не умеет

Пруфы будут?