LINUX.ORG.RU

Ответ на: комментарий от metar

Откуда вообще интерес к этим языкам?

К навороченным языкам вообще рост интереса стабильный. Просто Лисп однажды зафейлился в глазах сурьозного бизнеса (не оправдал бредовые идеи о возможности лёгко AI и т.п.), поэтому в него перестали вваливать деньги, профессура переключилась на более денежные направления, etc, etc, свято место пусто не бывает.

mv ★★★★★
() автор топика
Ответ на: комментарий от shty

меня тут «копетан» подёгивает за рукав и нетерпеливым шёпотом настаивает, дабы я Вас известил, о том, что попытка выполнить «сложение испуганных ворон с письменными столами» и есть логическая ошибка, что с ним делать не пойму

Если испуганная ворона превращается в письменный стол банальной перепутанной при наборе парой символов, то «копетан» может хоть рукав оторвать.

mv ★★★★★
() автор топика
Ответ на: комментарий от iVS

mv попробуй и Haskell, у тебя к нему интерес, похоже, уже давно. Хотя думаю, применять тебе его пока негде. Ну хз, может новый стартап, но теперь со ставкой на суровую статическую типизацию?

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

К тому же, лисповоды - милые общительные люди, а хаскеллисты - зануды :-P

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

Просто Лисп однажды зафейлился в глазах сурьозного бизнеса (не оправдал бредовые идеи о возможности лёгко AI и т.п.), поэтому в него перестали вваливать деньги, профессура переключилась на более денежные направления, etc, etc, свято место пусто не бывает.

хм, как-то общался с товарищем из европы, который приехал посмотреть ДС, спросил - как ему столица понравилась, он ответил - да так себе, а на вопрос а почему ответил - high expectations

думаете с лиспом та же самая проблема, слишком большие ожидания?

shty ★★★★★
()
Ответ на: комментарий от shty

думаете с лиспом та же самая проблема, слишком большие ожидания?

Как причина его исторического фейла - вероятно.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

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

А что за «интересные идеи», кроме REPL кончено.

Macil ★★★★★
()

В первую очередь - потому что слово Лисп используют ровно в три раза меньше, чем положено. Схемеры не любят называть свой язык лиспом. В Clojure-комьюнити это тоже не распространено. Остаются коммонеры, и те чаще сокращают название языка до CL.
Хаскелистам назвать свой язык по другому просто нечем.
Рекоммендую вам всё таки пристальнее взглянуть на Clojure. Языку три года от роду, он написан одним ленивым мужиком, а в трендах обгоняет CL уже в два раза. А причина одна - сакральные батарейки. Каким бы удобным. гибким и надежным не был бы язык, если у тебя есть возможность использовать тонны библиотек здесь и сейчас, без всяких FFI - это располагает к себе. То же самое можно наблюдать со Scala и Haskell - переняв часть ML-ной идеологии и JVM-ные батарейки, Скала рискует стать новым языком для людей под лампами дневного света.
Чтобы поддержать холивор - предпочитаю динамическую типизацию статической. Мне удобнее быстро наваять что-то на коленке, пока мысль не ушла, прогнать через REPL, а потом покрыть парой тестов\предикатов и прохинтить где нужно типы. В случае строгой типизации я посредине процесса описания типов просто засыпаю.

unlog1c ★★★
()
Ответ на: комментарий от shty

>милые такие, один лавсанчик чего стоил

Ага, и vsl...

Macil ★★★★★
()
Ответ на: комментарий от shty

милые такие, один лавсанчик чего стоил :)

Это просто молодость. У многих молодых хаскеллистов тоже манера общения далека от социально приемлемой.

mv ★★★★★
() автор топика
Ответ на: комментарий от Macil

А что за «интересные идеи», кроме REPL кончено.

Символы. Возможности восстановления после ошибок. Встроенная в язык виртуальная машина (лисповый образ), который может полноценно эволюционировать.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

Да, этого действительно не будет никогда...

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

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

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

Ну и идиоматика у хаскеля достаточно специфическая. Причем с самого начала ты вынужден использовать «единственную и правильную», в отличие от того же мультипарадигменного C++.

Macil ★★★★★
()
Ответ на: комментарий от anonymous

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

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

mv ★★★★★
() автор топика

Народу поднадоела (почти) чистая императивность и хочется чего-нибудь покруче.

Miguel ★★★★★
()
Ответ на: комментарий от provaton

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

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

Хаскель своим bondage and discipline автоматически делает какое-то покрытие. В Лиспе можно исследовать живой образ, отслеживать эволюцию данных, менять код - не менее ценное свойство. Я тему, собственно, с расчётом на обсуждение таких фич и завёл, а она, как всегда, скатилась в банальный срач о типах.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

Тут как бы палка о двух концах. С одной стороны возможности крутые, с другой - для них нужна ВМ. А ВМ - сложная штука. Маш код прост как говно - он или есть, или его нет. А ВМ большая, жирная, што-то делает внутре. Вещь в себе, так сказать. И с этим можно смириться, если точно знать, что вот есть ВМ, она вся такая жирная и непрозрачная конечно, но если делает, то делает все зае^Wоч. хорошо. А что в мире лиспа? Куча ВМ, плохо совместимых между собой, у всех свои профиты и недостатки. И работают на 2х с половиной платформах. И вот смотришь на это, и думаешь - ну его нафиг

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

Лисповый образ - это не совсем VM. Может быть и VM, но может быть и не VM.

Вещь в себе, так сказать. И с этим можно смириться, если точно знать, что вот есть ВМ, она вся такая жирная и непрозрачная конечно, но если делает, то делает все зае^Wоч. хорошо.

Ну вот LispWorks - крайне качественная штука :)

А что в мире лиспа? Куча ВМ, плохо совместимых между собой, у всех свои профиты и недостатки. И работают на 2х с половиной платформах. И вот смотришь на это, и думаешь - ну его нафиг

Разве это не проблема любого языка с неединственной реализацией? Скомпилируйте линуксовое ядро каким-нибудь Borland C? Ну или даже современным микрософтовским компилятором.

mv ★★★★★
() автор топика
Ответ на: комментарий от unlog1c

Yes! Я всегда говорил что любой срач статическая типизация vs динамическая кончается аргументом «А у вас REPL не работает».

KblCb ★★★★★
()
Ответ на: комментарий от vasily_pupkin

>>И с этим можно смириться, если точно знать, что вот есть ВМ, она вся такая жирная и непрозрачная конечно, но если делает, то делает все зае^Wоч. хорошо. Тем и хорош Clojure. За 15 лет существования JVM научилась делать все достаточно зае^Wхорошо.

unlog1c ★★★
()
Ответ на: комментарий от mv

> Разве это не проблема любого языка с неединственной реализацией?

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

А за LispWorks деньги хотят. И работает он только на ТруЪ интерпрайзе.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от KblCb

Yes! Я всегда говорил что любой срач статическая типизация vs динамическая кончается аргументом «А у вас REPL не работает».

Вовсе нет, это не аргумент «А у вас REPL не работает». Это аргумент «У меня работает REPL и я привык использовать этот подход в разработке». Один вопрос в начале топика звучал как «в чём выгода от динамической типизации», это был ответ на него.

unlog1c ★★★
()
Ответ на: комментарий от unlog1c

У clojure, на тот момент когда я его смотрел, были проблемы с инструментарием. Отсутствовал вменяемый отладчик и IDE, к примеру. Про сам язык говорить ничего не буду, хотя протоколы в 1.2 больше были похожи на игрушку для непонятно каких проектов, а вот с ВМ - вопрос. Нужны бенчи, что бы понять, на сколько jvm может адекватно пережёвывать такое использование

vasily_pupkin ★★★★★
()
Ответ на: комментарий от mv

> У многих молодых хаскеллистов тоже манера общения далека от социально приемлемой.

А немолодые всем штангой угрожают. На фиг на фиг.

anonymous
()
Ответ на: комментарий от unlog1c

Это аргумент «У меня работает REPL и я привык использовать этот подход в разработке». Один вопрос в начале топика звучал как «в чём выгода от динамической типизации», это был ответ на него.

Как REPL относится к срачу «LISP vs. Haskell» или «Static vs. Dynamic typing»? И там, и там REPL наличествует.

Miguel ★★★★★
()
Ответ на: комментарий от mv

Поэтому внешние по отношению к программе тесты всё равно надо делать

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

В Лиспе можно исследовать живой образ, отслеживать эволюцию данных, менять код - не менее ценное свойство.

Баззворды. Причем тут рефакторинг IRL?

provaton ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

Для x86 из оупенсорсных CL есть Clozure, который одинаково хорошо работает под всеми тремя самыми распространёнными операционками, и за которым стоит фирма, зарабатывающая на написании лисповых программ деньги.

mv ★★★★★
() автор топика
Ответ на: комментарий от vasily_pupkin

У clojure, на тот момент когда я его смотрел, были проблемы с инструментарием. Отсутствовал вменяемый отладчик и IDE, к примеру.

Как-то вы однобоко посмотрели. Emacs+Swank+SLIME остается для меня лучшей IDE и для Clojure, и для CL. Отладчика пристойного нету, хотя он не столь важен для функциональных языков. Тулзы для сборки на базе Maven (leiningen, cake) для меня в разы удобнее, чем asdf.
Протоколы мне тоже не нравятся, но это был шаг в сторону производительности. Мультиметоды всем хороши, но слишком медленные. Никто не мешает продолжать их использовать.

unlog1c ★★★
()
Ответ на: комментарий от provaton

Баззворды. Причем тут рефакторинг IRL?

Откуда рефакторинг вообще взялся? И если он уж появился в дискуссии, как положительная черта Хаскелля, то почему отметаются положительные черты CL?

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

Откуда рефакторинг вообще взялся?

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

И если он уж появился в дискуссии, как положительная черта Хаскелля, то почему отметаются положительные черты CL?

А какие у него положительные черты?

provaton ★★★★★
()
Ответ на: комментарий от Miguel

Как REPL относится к срачу «LISP vs. Haskell» или «Static vs. Dynamic typing»? И там, и там REPL наличествует.

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

unlog1c ★★★
()
Ответ на: комментарий от provaton

тебе для стопроцентного покрытия надо писать тесты типа [..]

100% покрытие - идиотия

shty ★★★★★
()
Ответ на: комментарий от provaton

Защитаем слив или все-таки расскажешь подробнее?

Мне лень цитировать себя же из этого же самого треда.

P.s.: множественное число? Шизофрения? Мания величия?

mv ★★★★★
() автор топика
Ответ на: комментарий от provaton

При всём моём уважении, интерфейсы намного мощнее и безопаснее утиной типизации, так что непонятно кто чем с натяжкой заменяется.

KblCb ★★★★★
()
Ответ на: комментарий от Miguel

Это как Google+ такой весь из себя нефейсбук?

Нуу... Процесс разработки софта в CL во многом ортогонален хаскелевому. И т.к. говном от этого CL не стал (кроме как внутри черепной коробки отдельных индивидов), то что-то в нём такое есть.

Вообще, потопить Лисп (CL) с позиций Хаскеля невозможно.

mv ★★★★★
() автор топика
Ответ на: комментарий от mv

Процесс разработки софта в CL во многом ортогонален хаскелевому.

Ставишь клаву вертикально - и пошёл.

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Только вот в хаскеле нельзя `с-x c-e`, `c-c c-c` на закрывающей скобочке, и даже нельзя `c-c c-r`. Только перезагрузка модуля в repl целиком. Некоторые считают, что одних только этих фич достаточно, чтобы предпочесть хаскелю Лисп, и их можно понять. Rapid'нее slime ничего за историю человечества придумано не было, даже смоллток сливает, хотя на втором месте.

ander-skirnir
()
Ответ на: комментарий от mv

Я тред читал весь, но кроме маркетологоподобного бреда типа «эволюции кода» и «виртуальной машины» от тебя не было. Давай конкретные примеры, понятные юз-кейсы. Кого волнуют высокие материи?

provaton ★★★★★
()
Ответ на: комментарий от KblCb

В целом спорить тяжело, разве что можно сказать, что в статическом варианте кода гораздо больше обычно. Но хасскелловские типы решают ИМХО.

provaton ★★★★★
()
Ответ на: комментарий от Miguel

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

Ну вот в случае с CL нередки коммиты вроде: «№ля, забыл сохранить буфер в Емаксе!». При всём при том, что предыдущий коммит был сделан для полностью рабочего кода. Только код эволюционировал в лисповом образе, а на диск его из редактора сохранить забыли.

mv ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

В слаботипизированном C++ с dynamic_cast'ом не стоит проблемы гетерогенных списков. Но вообще можно попробовать что-нибудь изобразить…

KblCb ★★★★★
()
Ответ на: комментарий от Macil

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

KblCb ★★★★★
()
Ответ на: комментарий от provaton

Я тред читал весь, но кроме маркетологоподобного бреда типа «эволюции кода» и «виртуальной машины» от тебя не было. Давай конкретные примеры, понятные юз-кейсы. Кого волнуют высокие материи?

Это устоявшиеся лиспофичи в местных лиспосрачах. Ты, наверное, не местный :)

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

mv ★★★★★
() автор топика
Ответ на: комментарий от unlog1c

Да. Это был мой вопрос. Объясните пожалуйста зачем нужен REPL. Я не умею им пользоваться (иногда использую ghci для проверки некоторых функций, связываний и вывода типов, но он «неполноценный» REPL) и плохо понимаю зачем он нужен.

KblCb ★★★★★
()
Ответ на: комментарий от geekless

>Руби — это лисп для бедных. Осталось изобрести хаскелль для бедных.

эф-шарп\окамл?

kyz
()
Ответ на: комментарий от geekless

Хаскель и так для бедных: все хаскелисты, которых я видел ведут себя так будто они притесняемые массы.

buddhist ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.