Haskell vs Lisp

Учи Scheme, к нему в придачу есть хорошая книга - SICP. Выучишь не только Scheme а научишься программить вообще. А там уж сам поймешь нужен тебе Haskell или нет.

>> Насколько понимаю сontinuation в lisp и CPS в чисто функциональном языке несколько разные по возможностям конструкции. Или ошибаюсь ?

см. в Haskell функцию callCC. А CPS бывает не тоьлко в чисто функциональном языке, но и в чисто императивном где возможно рекурсивное определение функций (читай везде).

>Что-то я так и не понял, мне Lisp или Haskell учить? %/

Если хочешь глубоко понять ФП - то Haskell. Но можно сначала SICP почитать и выучить попутно Scheme, потом проще будет + там не только про ФП. А потом можно читать "Write Yourself a Scheme in 48 Hours" - мануал по Haskell где описывается как на нем написать Scheme...

>оператор >>=

вы что-то имеете против оператора ф_топку?

Начни с простого, отсюда http://alblue.blogspot.com/2007/10/scala-introduction-to-scala-interpreter.html . Дальше само по чуть-чуть пойдет. И к жизни более приближенные знания, и в реальной работе сможешь быстрее начать применять. А

Человеку надо ФП изучить, какая нафиг разница какой язык? Да хоть ВизуальныйВасик один хрен. Как изучая синтаксис и библиотеки языка можно освоить методы ФП? Лучше бы книг каких порекомедовали, а то каждый кулик свое болото хвалит, скала-хуяла, хаскель-хуяскель.

Карочь читай SICP и не парься, задачи из него можешь хоть на С решать,хоть на схеме, хоть на хаскеле, хоть на брейнфаке, хоть на всех сразу. Пользы будет больше однозначно, чем тупо втыкать в Yet Another Haskell Tutorial или "напиши схему за 48 часов". В SICP невьебенный список дополнительной литературы по всем затроутым в книге аспектам (и ФП и ИП и интерпретаторы и ламбды и DSL и моделирование и еще хуй знает чего) - изучать на всю жизнь хватит.

> Мантра: на лиспе вообще и на схеме в частности можно писать как на любом языке

Нет.

> начинается изврат с монадами.

Да какой изврат? do {n <- readLn; putStrLn (n+1)}. Лепота.

> явно описаны как с побочными

Где описаны?

> Особенно если, учесть что в хаскеле это синтаксический сахар.

Нет. >>= - не синтаксический сахар. В отличие от do-нотации.

IMHO Haskell - инструмент теоретиков CS. LISP, хоть и не православен, но выучить его проще, чем Haskell и реализаций LISP больше, чем реализаций Haskell => проще выбрать более подходящую реализацию для конкретной задачи. Начать можно с drScheme или проприетарной LispWorks personal edition.

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

Хаскель - это лучший в мире императивный язык (c) Simon Peyton-Jones

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

Можно - см. printf

> LISP, хоть и не православен, но выучить его проще

Ты выучил? А экзамен по устройству MOP готов сдать?

>А экзамен по устройству MOP готов сдать?

При чём здесь MOP?

> А экзамен по устройству MOP готов сдать?

Читаю AMOP, пока ничего сложного

>> Ты выучил? А экзамен по устройству MOP готов сдать?

А ты, выучил ФП? Готов сдать экзамен по теории категорий?

>> Хаскель - это лучший в мире императивный язык (c) Simon Peyton-Jones

Simon Peyton-Jones - наймит M$

>> Да какой изврат? do {n <- readLn; putStrLn (n+1)}. Лепота.

Самый настоящий изврат. А что происходит за do-нотаций - вообще аццкий ужос.

>> Где описаны?

В описании.

>> >Мантра: на лиспе вообще и на схеме в частности можно писать как на любом языке

>>Нет.

Да.

> Что-то я так и не понял, мне Lisp или Haskell учить? %/

хз :) Я просто о чем - Чтобы выучить что-то сложное целесообразно начать с простого. Чтобы понять ФП на практике надо выбрать такой язык, в котором было бы не очень много новых для тебя концепций. Мне, например, поскольку я работал в основном с языками вроде Cи и Си# было проще начать с языка со статической типизацией. Я выбрал в качестве исходного Objective Сaml и вообщем-то не пожалел. Если ты имеешь опыт с динамическими языками вроде perl, python и пр., то начать целесообразнее с лиспа. Что касается SICP, то да, книшка интересная и прочитать ее надо, но она слишком заумная чтобы просто понять ФП

> см. в Haskell функцию callCC. А CPS бывает не тоьлко в чисто функциональном языке, но и в чисто императивном где возможно рекурсивное определение функций (читай везде).

Насчет CPS все понятно. Я просто к тому, что continuation на манер lisp-овского гораздо более мощное средство именно за счет использования императивных коснтукций (меняющегося контекста выполнения). Например в python-е и ruby на continuation-ах построены всевозможные генераторы и итераторы.

> А ты, выучил ФП? Готов сдать экзамен по теории категорий?

Да я её преподавать готов.

>>> Где описаны?

> В описании.

Тогда так и говори: не "все функции", а "все функции стандартной библиотеки". А вот в хаскеле - именно ВСЕ.

Начинать что с одного, что с другого - кретинизм. Scheme для обучения проверен временем. К нему есть отточенный годами учебник - SICP. Если будешь до него изучать Common Lisp, то тебе скорее всего покажется, что это - архаичное говно со спецификацией тяжелее задницы мамонта, а с Haskell просто будешь биться головой об стену от непонимания.

> Если будешь до него изучать Common Lisp, то тебе скорее всего покажется, что это - архаичное говно со спецификацией тяжелее задницы мамонта

Да прям. Просто для CL нет такой хорошей книжки, как SICP для Scheme.

> Да прям.

А теперь отключи fanboy mode и подумай, без сколько процентов встроенных функций CL можно было бы легко обойтись. Не спеши отвечать, пока не дойдёшь хотя бы до 60%.

>а с Haskell просто будешь биться головой об стену от непонимания.

Только если у тебя ГСМ.

>> Тогда так и говори: не "все функции", а "все функции стандартной библиотеки". А вот в хаскеле - именно ВСЕ.

Не только в стандарте. В Scheme есть стандарт де-факто обозначать все функции с побочными эффектами восклицательным знаком (set!, например, хотя это и не функция). Это лучше чем городить огород с монадами.

>>а с Haskell просто будешь биться головой об стену от непонимания.

>Только если у тебя ГСМ.

Эх, черт подери... у меня ГСМ, доктор, я не смогу осилить Хаскель?

> Эх, черт подери... у меня ГСМ, доктор, я не смогу осилить Хаскель?

Придется ампутировать :)

> Не только в стандарте. В Scheme есть стандарт де-факто обозначать все функции с побочными эффектами восклицательным знаком (set!, например, хотя это и не функция). Это лучше чем городить огород с монадами.

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

>> Огород с монадами для моделирования примитивных ... [и т.д.]

Кстати да, есть такое. Самое интересное, что почти нигде, где есть "красивые примеры" Хаскеля не упоминается сложность получаемых алгоритмов.

>Отсутствие побочных эффектов иногда бесит :)

Опять же императивное мышление.

Рекомендую нафтизин, недорого и эффективно.

Согласен. Можно почитать великого дядьку Окасаки, и придумать такую структуру данных с которой будет удобно работать в чистом ФП, но зачем мне себя ограничивать, когда и проще и естественее решить задачу императивно.

> Согласен. Можно почитать великого дядьку Окасаки, и придумать такую структуру данных с которой будет удобно работать в чистом ФП, но зачем мне себя ограничивать, когда и проще и естественее решить задачу императивно.

А зачем тогда ФП язык использовать?

> А зачем тогда ФП язык использовать?

Не знаю, сдаюсь.

> А зачем тогда ФП язык использовать?

Потому что в ФП есть некоторые удобные вещи. Вот проникнет достаточно элементов ФП в мэйнстрим (или какой-нибудь гибридный язык станет мэйнстримом) - тогда ФП-языки потеряют статус модных игрушек, и спорить станет не о чем (так было с СП и ООП).

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

> Это лучше чем городить огород с монадами.

Ты хоть понимаешь, что сравниваешь тёплое с мягким? Соглашение - с требованием.

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

Для вас, Козлов, зиппер сделан.

> Кстати да, есть такое. Самое интересное, что почти нигде, где есть "красивые примеры" Хаскеля не упоминается сложность получаемых алгоритмов.

Да, есть такое. Хаскель позволяет писать значительно более сложные алгоритмы.

> Ну так нормальные люди используют ФП там, где оно к месту, а совать его везде - это хуже, чем какой-нибудь XML везде совать, блджад.

Конечно. Но вопрос топикстартера - именно про ФП.

Лол, сам-то понял, что сказал?

капча ownhole

> Лол, сам-то понял, что сказал?

Я-то понял, а вот понял ли предыдущий оратор, что он сказал?

Хочешь сказать, что Хаскель позволяет без особого труда поднять сложность c O(1) до O(n) и далее? Мы не сомневались.

>> Ты хоть понимаешь, что сравниваешь тёплое с мягким? Соглашение - с требованием.

Да мне как-то фиолетово соглашение это или нет. Факт есть, Есть. И спать неспокойно от того, что какой-то мудаг будет писать иначе я не буду :)

> Хочешь сказать, что Хаскель позволяет без особого труда поднять сложность c O(1) до O(n) и далее? Мы не сомневались.

Хинт: сложность алгоритма - это не только время, за которое он работает. Это чуть более многозначное выражение.

>> Для вас, Козлов, зиппер сделан.

А что zip позволит поменять узел без пересоздания дерева? Inplace, да?

>> Хинт: сложность алгоритма - это не только время, за которое он работает. Это чуть более многозначное выражение.

Ага, еще и память :) Многозначнее некуда.

Да не zip, а зиппер. Вот тебе для списков, для деревьев сделаешь сам:

data Zipper a = Zipper [a] a [a]

toLeft :: Zipper a -> Zipper a

toLeft (Zipper (l:ls) x rs) = Zipper ls l (x:rs)

toRight :: Zipper a -> Zipper a

toRight (Zipper ls x (r:rs)) = Zipper (x:ls) r rs

setCurrentValue :: a -> Zipper a -> Zipper a

setCurrentValue x (Zipper ls _ rs) = Zipper ls x rs

Все операции - O(1).

> Ага, еще и память :) Многозначнее некуда.

Вспоминай человеческий язык.