И какой «box office» у этого бестселлера?

В треде закомплексованный нищеброд! Все в танк!

Спасибо. Почитаю.

По-моему, это очень круто. В России, в университете, годный преподаватель написал годный конспект лекций для студентов и выложил в PDF. У нас в университете это была огромная редкость, в основном одни дебилы были вокруг. Надо этого преподавателя поддержать и поощрить.

Очень доходчиво объясняется всё, легко читается. Отличная книжка для начинающих.

Хорошая новость :) Как раз собирался про Haskell почитать.

Только на десктопах у них там линух, а статьи пишут в latex

насчет Reseach я не буду удивлен, если немалый процент сидитна конкурирующих продуктах

Так и знал - Дима ответит первым :)
Дико извиняюсь за своё любопытство, но всё-таки спрошу, т.к. этот вопрос меня мучает уже давно:
- Если, конечно, не секрет, Дима, где ты его применяешь? (:

Microsoft Research != Microsoft

Да, Капитан, мы в курсе. Microsoft Research это часть Microsoft. А часть не идентична целому. Думаешь, ты Америку открыл?

Всегда есть о чём с Вовой Пресняковым поспорить.

В этой книжке нет 4той главы. Поэтому и полезности почти никакой.

О спасибо. Значит новость в игнот.

нет, работа ведется

А rpmки с Hugs под винду, значит, встают без проблем? И что мешает под винду накатить Haskell Platform?

Перегнал в fb2 для читалки, если кому-нибудь понадобится - делюсь ссылкой http://dl.dropbox.com/u/163860/MakeevGA-Haskell.fb2

Microsoft Research это часть Microsoft. А часть не идентична целому. Думаешь, ты Америку открыл?

Нет. Просто у некоторых товарищей только от одного слова «Microsoft» начинается нехилый баттхерт. А между тем она местами вовсе и не такая уж «корпорация зла»(но только местами, да)

от автора

0. Резюме: эта книжка - еще одно объяснение ФП в копилку к уже существующим.

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

2. Но нельзя говорить, что книжка следует стандарту из 3 глав - там все-таки побольше, чем определение факториала.

3. Зачем что-то нужно, если есть LYAH? Зачем вообще универы, есть есть корсера? Затем, что все люди разные, и объяснения им нужны разные. Это говорит мой личный опыт. LYAH - отличная книжка, но как там (и в большинстве других случаев) вводятся ФВП - меня не устраивает, и я предлагаю свое объяснение (как и ко всему остальному). Кого-то зацепит одно объяснение, кого-то другое.

4. Почему doc? Да потому что я работаю в винде и не представляю, что у кого-то могут быть проблемы с чтением doc. Возникают - пожалуйста, рядом pdf. Простите, я не знал о вашем существовании. Вот fb2 не получится легко - поползут отступы и не будут умещаться коды в строке, будут переноситься. Надо перерабатывать.

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

6. Почему hugs? Да потому что скопировать маленькую папку на рабочий стол, поработать и удалить - всяко проще, чем на каждый комп в лабораторной ставить гигабайт haskell platform. Для обучения достаточно и hugs.

P.S. Чтобы не забанили: линукс у меня тоже есть, на asus wl-500gp, я там умею запускать mc и чуть-чуть админить openvpn и svn. Заранее спасибо за ваше чувство юмора и терпимость.

Не мог найти? Неплохая шутка.

Книжки это хорошо, но по Haskell их уже достаточно. Да и сам язык не сложный, что бы там не утверждали его фанатики. Даже если глянуть на расширения, то rocket science там не наблюдается. Так что мне непонятен весь этот ажиотаж.

По-моему единственная (и критичная) проблема Haskell в том, что его разрабатывали люди, которые на «ты» с computer science, но которые совсем не представляют себе что такое software engineering. В результате чисто практические аспекты у экосистемы Haskell слабоваты. Поэтому он прекрасен как учебное пособие и даже как инструмент в кое-каких практических случаях, но в долгосрочной перспективе завязываться на него очень рискованно.

RE: от автора

Простите, я не знал о вашем существовании.

Простите, мы о вашем тоже.

А что именно у него плохо в практической части? В разработке софта?

Вот, меня радует, например, его профайлер, система отладки. Речь, разумеется, про GHC.

Какие задачи на нем вы решаете?

Много с чем плохо.

Вот навскидку:

1. head от пустого списка выкидывает exception (что разумно). Но этот exception валит программу с вообще невразумительным сообщением, по которому нельзя понять где же произошла ошибка.

2. cabal dependency hell. На всех мало-мальски сложных проектах легко напороться на проблему, где разруливание зависимостей надо делать вручную и на это могут уйти дни. По-большому счёту это проблема того, что у haskell packages нет чётко выраженного интерфейса и все зависимости прописываются вручную.

3. нет реальной возможности рефакторить код. Я знаю про HaRe, но он и рядом не стоит даже с элементарными инструментами для той же Java.

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

5. невообразимо сложно писать алгоритмы, что оперируют состоянием. Это нужно не часто, но когда нужно, то начинается Ад с маловменяемыми местечковыми типами, St или как там её монадой, и через-пень-колодными попытками работать с этим состоянием при помощи put и get. Только когда всё состояние это просто одно значение, то все работает красиво. Но это - школьный пример. Когда же состояние это штук десять величин, часть из которых являются коллекциями или records, то желание возиться с haskell очень быстро пропадает.

6. реализация records крайне патологична тем, что замусоривает namespace, склоняет каждый тип record определять в своём личном пакете и всегда использовать его в fully qualified манере. Лаконичность резко превращается в монстрозность.

7. противоречит принципу forward typing. Не критично, но крайне неприятно, т.к. на корню убивает возможность реализовать хорошее автодополнение.

8. быстрый код невозможен без stream fusion. А они в GHC реализованны через rewrite rules. Кое-кому они нравятся. Я же считаю что это феерический минус, т.к. фактически был введён второй язык, что оперирует почти невидимым состоянием, существующим только в момент компиляции. Это почти невозможно отлаживать и совместная работа нескольких библиотек, использующих rewrite rules, превращается в лавкрафтианский кошмар.

.doc

Ну как так можно?

но стоит заметить, что в libreoffice (у меня 4.0.1.2) нормально открывается, даже не тормозит

завязываться на него очень рискованно
но он и рядом не стоит даже с элементарными инструментами для той же Java.

очень авторитетно и аргументировано, просто подкопаться не к чему, особенно про Java.

ФП - будущее, haskell + erlang ФП уже в настоящем. Возможно будут лучше решения чем имеющиеся, но пока чем богаты, тому и рады. Но даже эти решения лучше и интереснее «промышленных» старых.

Если Вы «знаете» о «лучшей альтернативе в перспективе» - поделитесь пожалуйста ею.

Книжки это хорошо, но по Haskell их уже достаточно.

Посмею возразить, много хороших книг не бывает достаточно.

спасибо большое за fb2

1. man import Safe, man implicit parameter,man TH, каждый из перечисленных вариантов решает проблему, плюс щас делают общее решение

2. ложь, говорю на правах мейнтейнера хацкельных пакетов в генте

3. ok

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

5. ложь, плюс незнание IORef/MVar/STM

6. man lens, man common scence

7. ok

8. с чем сравниваем?

очень авторитетно и аргументировано, просто подкопаться не к чему, особенно про Java.

Расскажи про IDE уровня IDEA для Хаскеля. Я бы был очень счастлив увидев такую. Если не можешь - тогда не болтай.

очень авторитетно и аргументировано, просто подкопаться не к чему, особенно про Java.

Особенно авторитетен и агрументирован ваш комментарий. Фееричненько.

ФП - будущее, haskell + erlang ФП уже в настоящем. Возможно будут лучше решения чем имеющиеся, но пока чем богаты, тому и рады. Но даже эти решения лучше и интереснее «промышленных» старых.

Может лучше и интереснее в теоретическом плане. Но отнюдь не в практическом.

Если Вы «знаете» о «лучшей альтернативе в перспективе» - поделитесь пожалуйста ею.

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

Посмею возразить, много хороших книг не бывает достаточно.

Можете и дальше их читать. Мне же надо работу делать.

1. да неужели? И что, для любого выброшенного exception я увижу, где он выброшен? И что, я могу гарантировать, что НЕ будет выброшен ни один exception, который не будет словлен и обработан? Сказочник.

2. да, ты лжёшь. Я (и множество разработчиков на haskell) говорим на правах тех, кто пишет на haskell софт.

4. прикинь, таки значительно более предсказуемо.

5. в отличии от тебя, детка, я их знаю. И они нихрена не решают проблему. Не согласен - пример сюда. Но не игрушечный, а со сложным состоянием.

6. даже не смешно. Ты сам-то этими линзами пользовался?

8. сравниваем с любым языком, где есть вменяемый компилятор. C++, Java, C#.

П.С. У тебя какой опыт программирования?

1. да. -xc позволит увидеть stack trace, остальные методы место в коде, где откуда bottom.

2. аргумент не принимается

4.

5. агрумент не принимается. Не согласен - пример задачи, со сложным состоянием.

6. нет, мне хватает common-scence, все собираюсь добраться. надеюсь мы об одних и тех же, просто помимо Control.Lens есть тройда других дурацких реализаций через State.

8. давай задачу.

П.С. У тебя какой опыт программирования?

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

блин МФТИ видимо зря я ввязался в разговор, надо комментарий добавить.

Проблема со stateful computations есть, но она не там, где вы назвали. Сложное состояние создать легко.

Не согласен - пример сюда.

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

scence пишется без c и через s. sense. ну сколько можно, ты уже третий раз вроде так пишешь?

особенно если там пересекающиеся эффекты, т.е. например 100500 разных вариантов обработки ошибок. Хотя лично у меня проблем со стеками получалось все меньше.

у меня спелчек на русский включен :/

1. ОК, это хорошо.

2. не принимать аргумент - отличный подход. :-) Рекоммендую основать собственную секту. У тебя всё получится.

5. пример задачи:

Есть группа Зверей, у каждого Зверя есть возраст, уровень голода и пол.

Также есть группа объектов типа Еда. Экзепляр еды имеет срок годности и число, которое показывает питательность еды.

Далее система эволюционирует в результате следующий событий:

* появилась новая Еда

* пришёл новый Зверь

* самого сытого зверя попросили уйти

* прошёл квант времени (за который звери едят или размножаются, если хотят).

На выходе события такие:

* Зверь родился

* Зверь умер

* Зверь пришёл

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

Правила поедания: Звери в случайном порядке пытаются есть. Утолённый голод зависит от качества еды.

и т.д.

Как описать такую систему в Haskell?

Проблема со stateful computations есть, но она не там, где вы назвали. Сложное состояние создать легко.

Создать легко, работать с ним - сложно.

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

Да, это - настоящий ад.

И как раньше люди без спеллчека жили? Может, просто грамотными были?

Расскажи про IDE уровня IDEA для Хаскеля. Я бы был очень счастлив увидев такую. Если не можешь - тогда не болтай.

IDE уровня IDEA нужны для языков, где 99.99% кода - бойлерплейт. Для приличных языков IDE не требуются, так как на собственно написание кода уходит исчезающе малый процент времени.

это иррелевантно текущей дискуссии

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

Ну почему же? Это как бы наглядная демонстрация общего уровня развития посетителей ЛОРа.

Как это «ничего стоящего»?!? А факториал? А числа Фибоначчи?!?

2. не принимать аргумент - отличный подход.

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

Похоже мне пора делать большой пост/презентацию по поводу cabal-hell, текущих решений прогресса и проблем, а то действительно надоело, куча народу живет без инфраструктуры и «плачет», что всё плохо, когда у другой кучи всё просто работает :). Пока могу отослать к известной статье «cabal is not package manager», там описаны идеи ведущие к решению проблемы. По поводу cabal-hell и проблем с пакетами я знаком, но обычно все фиксится элементарно, за редкими исключениями.

Проблема с ABI имхо гораздо более сложная.

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

сюда же, я не понял:

1). правила по которым умирают, как-то связано с возрастом, какая-то функция, какая-то вероятность? Оно связано с квантом времени или нет?

2). как квант времени связан с возрастом (годностью продукта), т.е. какие единицы времени где используются, всегда ли время между квантами будет одинаково?

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

4). «размножаются если хотят» как понимать? опять же какие тут правила. Просто в течении кванта выбираем случайное кол-во подходящих пар?

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

Как я понял интерфейс должен быть:

live :: SystemState -> Chan EventsIn -> Chan EventsOut -> IO ()

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

маловероятно.

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

pandoc же!

если лень расписывать на лоре, может стукнуть мне в джаббер/мыло, если не справлюсь, то честно тут признаюсь.

сюда же, нужно ли давать животным уникальные идентификаторы?

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

Полагаю, не мне одному было бы интересно глянуть. А то большинство примеров работы с состоянием - игрушечные.

Особенно интересен вариант, когда фактически всё это выполняется в одном потоке и не использует монаду IO.

1. да. Скажем, аналог на SQL: DELETE FROM animals WHERE age > 2000;

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

3. идея в том, что есть поток событий, который управляет системой. Изменения системы наблюдаются как выходящий поток. Это более-менее популярная система описания самых разных штуковин, причем легко формализуемая. Событие «зверь пришёл» соответствует приходу нового зверя в данную популяцию.

4. Да, можно выбрать пары случайно. Но по-большому счёту для простоты можно ввести какие-то правила вроде «первая пара, если пары отсортировать по какому-то правилу». Главное тут не само правило, а то, как работать с состоянием системы.

5. Давай преположим, что у него есть показатель голода и он находится в диапазоне от 0 до 100. 0 зачит «сытое», может есть но не переест. 100 значит «совсем голодное».

Можно и такой интерфейс, но мне ближе другой:

consumeEvent :: SystemState -> EventIn -> (SystemState, Maybe [EventOut])

Или аналогичный, сделанный через монаду SystemState

consumeEvent :: EventIn -> SystemState (Maybe [EventOut])