Введение в возможности Haskell

Почитаем.

Слышал, язык хороший, но что в нем такого, чего нельзя со сравнимыми трудозатратами реализовать на языках таких как питон, джава и С++?

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

> Слышал, язык хороший, но что в нем такого, чего нельзя со сравнимыми трудозатратами реализовать на языках таких как питон, джава и С++?

Функциональщина.

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

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

Жду мануал по Brainfuck.

цепепе здесь вообще не в теме - эдакое кривоватое расширение C с недоООП и невменяемым синтаксисом.

>но что в нем такого, чего нельзя со сравнимыми трудозатратами реализовать на языках таких как питон, джава и С++?

Многие вещи в нём делаются на порядок-два быстрее, нагляднее, прозрачнее. Поройся в примерах, их много приводится.

Я, правда, функциональщину до сих пор не осилил. Мозги по иному перестраивать надо.

>цепепе здесь вообще не в теме - эдакое кривоватое расширение C с недоООП и невменяемым синтаксисом.

зато популярен и используетс везде. коде реюзинг легче. много написано. много специалитов. но STL... и это еще хорошо написанная стандартная библитека. если сравнивать C++ с Common Lisp по элегантности в этом плане - Common Lisp рулит =)

сам сейчас проектик на лиспе поддерживаю (на удивление нашел такую работу, правда удаленно) - изумительно.

>Я, правда, функциональщину до сих пор не осилил. Мозги по иному перестраивать надо.

черт, я что-то делаю не так? вроде вхождение в тот же Лисп не сложно. правда у меня и не совсем функциональный стиль... мож в этом дело...

>Жду мануал по Brainfuck.

лучше по Машине Тьюринга. С решением P =/<> NP =)

>лучше по Машине Тьюринга

Или алгорифмам ;)

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

А про хаскел скажу, что прекрасный язык для тренировки мозга и написания всевозможных этюдов, разработки for fun. К сожалению, мало где можно встретить промышленное программирование на нем (да и на другом функциональном языке, или близким к ним), особенно у нас :( Ну да ладно, все впереди. Сами творим историю, глядишь и появится какая-нибудь вакансия ;) И не надо говорить, что на нем не напишешь коммерческую систему. Целиком может и не напишешь, а вот ядро вполне себе можно. Да и прототипы всякие. На Прологе, например, очень часто пишутся прототипы, и встраивается прологовское ядро.

>Или алгорифмам ;)

Марков молодец. если бы все как он осиливали бы доказательства корректности свох поделий, мир был бы другим =)

Одноричная система это как?

И как в ней можно складывать, вычитать, умножать...

>Одноричная система это как?

| | | | | | | | | | | | == 12 =например так ,)

>И как в ней можно складывать, вычитать, умножать...

Как и во всех других. %)

| | + | | | = | | | | |

Умножение соответствующе ;)

Для десятичной системы конвертировали сначала аргументы в 1-уй, затем результат в десятичную опять. Так, с учетом специфики алгорифмов, показалось легче и правильней сделать +)))

Несколько недель как занимаюсь хаскелем в свободное от работы время... приобрел книжку русского автора, взял 2 статьи на rsdn, и еще один недопереведенный кусок (все это находится через гугл).. для того чтобы понять все концепции приходится почитывать документацию по окамлу, но к примеру что такое монады и как с ними работать до сих пор не осилил.

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

Книжка эта у меня пробегала. Написана просто копипастом с лекций. Суховато и трудно разобраться че-же автор имел в виду.

>Я, правда, функциональщину до сих пор не осилил. Мозги по иному перестраивать надо.

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

Изучи Хаскел за 10 минут:
http://www.haskell.org/haskellwiki/Learn_Haskell_in_10_minutes

Чего интересного. Вот появилась первая книжка на русском языке. Думал - сразу расхватают студенты в качестве учебного пособия. И тут то и дело раздаются вопли, что что Haskell в 100 раз лучше, чем нормальные языки. А вот и не покупают - несмотря на тираж 1500 экземпляров, давно лежит в магазине (я себе купил просто так, чтоб лежала).

Хотя в статье интересное начало: Let me start by being perfectly clear: if you are a professional programmer, then Haskell is in your future. In 1987, this statement would have been equally true about Smalltalk. "Если ты профессиональный программист, то у тебя в будущем - Haskell. В 1987 г. это в равной степени было справедливо для Smalltalk".

Где живёт автор - на Луне или в подобном месте? Smalltalk имел ограниченное применение и уже давно отпал, не выдержав конкуренции с нормальным языком (конкретно, с Java).

>Чего интересного. Вот появилась первая книжка на русском языке. Думал - сразу расхватают студенты в качестве учебного пособия. И тут то и дело раздаются вопли, что что Haskell в 100 раз лучше, чем нормальные языки. А вот и не покупают - несмотря на тираж 1500 экземпляров, давно лежит в магазине (я себе купил просто так, чтоб лежала).

ну и зачем купил? студентам бы оставил =)

а в чем суть проекта, если не секрет?

>а в чем суть проекта, если не секрет?

вообще поддерживаю и отлаживаю готовый web-движок.

>цепепе здесь вообще не в теме - эдакое кривоватое расширение C с недоООП >и невменяемым синтаксисом.

Ну ведь неосилил ?

Ты даже абзац до конца дочитать не осилил?

...even though Smalltalk never saw widespread adoption.

> Ну ведь неосилил ?

Осилил, поэтому и говорю, что ооп в нём кривой и недоделанный. Где полиморфизм? Где синтаксический сахар в виде пропертей?

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

> во-во всё в этих лиспах и хаскелях нравится, но писать не могу - думать надо учиться по другому :(. Сложно переучиваться, когда всякие оопобразные языки уже в подкорке сидят.

прошлую неделю учил XSLT -- одновременно и мейнстрим, и непохож на остальные.

в хаскеле прикольные классы (типов) и полиморфные функции. думается, этот те вещи, которые должны быть полезны ООП языкам.

в остальном, с точки зрения практического применения, это мертвый язык. как и все функциональные.

язык программирования должен быть императивным, но для математики, поддерживать элементы ФП. а не наоборот. реальность-то императивна. )

Ленивые вычисления, истинный (параметрический) полиморфизм, монады.

>Осилил, поэтому и говорю, что ооп в нём кривой и недоделанный. Где полиморфизм? Где синтаксический сахар в виде пропертей?

То есть полиморфизма у плюсов нет ?
Что именно нехватает в реализации ООП ?

Плюсы конечно не конфетка , но не надо гнать без знания предмета :-)

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

> То есть полиморфизма у плюсов нет ?
> Что именно нехватает в реализации ООП ?

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

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

Насчёт этого ты уже где-то жаловался , описывай дальнейшие минусы

>вообще поддерживаю и отлаживаю готовый web-движок.

хотелось бы пообщаться по вопросам применения лиспа для целей www.

> Насчёт этого ты уже где-то жаловался , описывай дальнейшие минусы

этого не хватило? ну, ещё, нет лямбды, нет foreach, нет понятия кортежей, нет удобных строк, чтобы сразу "aaa" + "bbb". Всё это делается, но через жуткие костыли.

> Что именно нехватает в реализации ООП ?

вопрос в другом: нафик такой ООП?

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

а в плюсах объекты _создаются классами_, т.е. классы целиком и полностью определяют их тип и поведение. отсюда возникает куча логических заморочек, которые в реальном коде выливаются в проблемы. почему в плюсах объекты не могут жить без классов?

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

второй момент -- наследование. вообще, этим словом называют две совершенно разные по сути штуки: отношение "родитель"-"дети" и отношение "общее"-"частное".

чисто логически, наследование в с++-подобных это отношение вида IsA. а посему должно трактоваться исключительно как "общее"-"частное", т.е. чисто формально так, как принято в теории абстракных типов данных. когда наследники целиком и полностью принадлежат базовому типу, и соответственно могут использоваться везде где используются объекты базового типа.

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

>этого не хватило? ну, ещё, нет лямбды, нет foreach, нет понятия кортежей, нет >удобных строк, чтобы сразу "aaa" + "bbb". Всё это делается, но через жуткие >костыли.

Хватит тролить , плюсы ты не знаешь дальше синтаксиса

> Хватит тролить , плюсы ты не знаешь дальше синтаксиса

Телепат? Слушай, чуве. Я видел реализацию лямбды в плюсах. Я видел реализацию foreach в плюсах. И ничем этим я пользоваться не собираюсь, ибо неудобно, а такие вещи нужны именно для удобства. Плюсы - для костылей. Для программирования - другие языки, не плюсы.

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

а-афигеть!

[фцытатнег, бить пагалаве маниакальных построителей "иерархических структур" где надо и ненадо]

На самом деле, методы обобщенного проектирования (generic programming) в С++ настолько сложны и запутаны, что люди которые это реально понимают и могут использовать в проектах похожи на древних алхимиков, обладающих тайными знаниями. Спросите у рядового программиста на С++, про мультиметоды или паттерны проектирования типа Command или Abstract Factory, знает ли он вообще такие слова.

>Спросите у рядового программиста на С++, про мультиметоды или паттерны проектирования типа Command или Abstract Factory, знает ли он вообще такие слова.

Вот не надо про паттерны, и Команду с Абстракт фактори в частности. Это такая примитивщина, что должна вливаться в человека с молоком матери. А если чел не понимает, что это такое, зачем нужно, даже после целенаправленного объяснения - может следует ему сменить профессию? И вообще причем тут С++? Паттерны - они в голове, а не в языке.

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

это с++-сное ООП заставляет строить маниакальные иерархические структуры потому, что мешает в кучу типы и классы, объекты и экземпляры классов.

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

т.е. в реальности, иерархии классов строить не обязательно. один и тот же объект может принадлежать (рассматриваться как принадлежащий) сразу нескольким классам. и не потому, что между классами выстроена иерархия, а потому что у объекта такие свойства.

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

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

Уже лет 20 как известны иерархии по реализации и по интерфейсам. Еще в 1995 были реализованы signaure для Си++ - но ни то, ни другое в народ не пошло. Видимо, оказалось не нужно на практике. То же будет и с Хаскелем - некоторые идеи проникнут в мэйнстрим, язык отправится на помойку^W^Wв музей.

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

>и не нужно наследовать палки от млекопитающих, чтобы иметь возможность поскакать. )

вот об том и речь )

просто есть отдельные индивиды, строящие "четкую иерархию в виде дерева", а потом пущають сопли и слюни и кричат "это неправильно, так нечестно!", когда стройное деревце превращается в хитрожопый граф. (что, вобщем-то, вполне ожидаемо и соответствует задаче).

> Уже лет 20 как известны иерархии по реализации и по интерфейсам. Еще в 1995 были реализованы signaure для Си++ - но ни то, ни другое в народ не пошло. Видимо, оказалось не нужно на практике. То же будет и с Хаскелем - некоторые идеи проникнут в мэйнстрим, язык отправится на помойку^W^Wв музей.

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

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

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

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

концептуально, классы типов рулят. )

.. впрочем, согласен, что хаскель тоже не подарок. в основном из-за своей излишне "математизированной" натуры. да и классы с типами там не first-class objects. наверняка, мейнстримом никогда не станет.

> Такие области как: AI, "нечеткая математика", распознавание речи и т.д., рано или поздно станут основным направлением компьютерных технологий, и тогда функциональные языки совершат переворот в индустрии программирования.

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

простой процесс. берем из реального мира бумажку и сжигаем. смотрим что стало:

x <- бумажка;; сжигаем (x)

вопрос что _теперь_ такое x?

с точки зрения математики, Х как был бумажкой, так и остался ей даже _после_ сожжения (и вообще, вечно будет бумажкой, сколько не жги). ведь классическая математика вообще не заморачивается проблемами существования и времени.

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

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

По собственному опыту -- на практике всё же удобнее OCAML использовать (caml.inria.fr), хотя для изучения основ функционального программирования и Haskell сойдёт. Жаль только, что в российских ВУЗах мало уделяют внимания функциональному программированию.

>простой процесс. берем из реального мира бумажку и сжигаем. смотрим что стало:

> x <- бумажка;; сжигаем (x)

> вопрос что _теперь_ такое x?

эээ... "сожженая бумажка"? угадал? что у нас "сжигаем (x)" возвращает?

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

это как?

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

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

В реальности, когда ты решаешь задачу на ЭВМ, ты оперируешь не с реальностью а с мат.моделью, которую ты строишь исходя из условий задачи , имеющихся данных и других факторов(напр. аппаратных ограничений или сорта травы).
Модель ес-но всегда проще чем реальность, она должна быть "как можно проще, но не слишком". Усложнение структур данных и/или их отношений (кроме случаев, когда они слишком упрощены - не учитывают какие-то важные для твоей задачи моменты) приводит к ухудшению понимания программы и, как правило, добавляет факторы, влияющие на результат, которые становится сложно контролировать.
Язык программирования это просто инструмент реализации этой модели.
Если ты знаком с некоторым языком и понимаешь задачу, ты сможешь реализовать её решение на этом языке.
Решения на разных языках/использовании разных подходов могут сильно отличаться визуально, но по сути одна фигня(до тех пор пока ты не изменил структуры данных и логику). А ограничения налагаемые языком обычно имеют и положительные стороны.

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

>В реальности, когда ты решаешь задачу на ЭВМ

форматирование - говно, бред ниасилил.

>а для большинства задач вполне хватает концепции классов C++, и для многих прочих случаев есть устоявшиеся решения

дадад, устоявшиеся решения. Как правило - в виде отмазок типа: "этот способ решения в данном случае не годится, он методологически не верен, так как не укладывается в модель". Угу. Кому другому расскажи.

Так вот. Концепции - _не хватет_ ! Иначе, зачем понадобились какие-то левые "интерфейсы"??? Правильно, за тем, что один какой-то опездол придумал придумал, что "древовидной иерархией" можно описать все, что угодно. а все повелись на эту шнягу.