Комментарии 26
Писать на хаскелле без монад безусловно можно. Можно даже в какой-то мере успешно.
Однако, мне это напоминает вождение автомобиля с закрытым лобовым стеклом. Конечно, можно вести, высунувшись из окна, но это немного не то.
Однако, мне это напоминает вождение автомобиля с закрытым лобовым стеклом. Конечно, можно вести, высунувшись из окна, но это немного не то.
Haskell без монад
прочитал название топика.
прокрутил листинги кода.
везде монада IO, с do-нотацией и без.
о каком «хаскеле без монад» вообще идёт речь?
просто пипец.
прокрутил листинги кода.
везде монада IO, с do-нотацией и без.
о каком «хаскеле без монад» вообще идёт речь?
просто пипец.
Странный подход. «Я не понимаю как работает мотор, давайте вырвем его с корнем, а машину будем толкать». Быть может лучше объяснить что такое монады и как они применяются?
1. А что, в общем-то, такого в объяснении монад через эндофункторы и естественные преобразования? :) В сумме выходит максимум 20 простых определений, начиная с категорий. Это же гораздо проще понять чем, скажем, объектно-ориентированное программирование.
2. rsdn.ru/forum/decl/4049523.1.aspx — вполне понятное описание без «страшных слов».
3. Конструкции, которые по сути являются монадами или моноидами широко используются и в других языках программирования. И пока их не называют монадами, проблем с пониманием обычно не возникает.
2. rsdn.ru/forum/decl/4049523.1.aspx — вполне понятное описание без «страшных слов».
3. Конструкции, которые по сути являются монадами или моноидами широко используются и в других языках программирования. И пока их не называют монадами, проблем с пониманием обычно не возникает.
Объяснять непонятное непонятным — само по себе порочно, ибо сепулькарий выходит. 20 новых определений в рамках одного объяснения — тоже ужасно, ибо среди них выход из сепулькария найти трудно, да и удерживается в голове 5-7 элементов одновременно, а среди них должны быть не только новые понятия, но и уже известные, и связи этих новых с ними.
Ваше «вполне понятное описание» оперирует кучей непонятных слов и ещё большей кучей непонятных символов типа рыбки >=>. Лично я, не знакомый с хаскелем, понял лишь что-то в части про рефакторинг — что в хаскеле можно преобразовывать его выражения по формальным правилам.
А вот про то, что можно было бы назвать монадами в других языках — было бы полезно услышать. Так может и монады понятны станут… Когда станут опираться на известные понятия.
Ваше «вполне понятное описание» оперирует кучей непонятных слов и ещё большей кучей непонятных символов типа рыбки >=>. Лично я, не знакомый с хаскелем, понял лишь что-то в части про рефакторинг — что в хаскеле можно преобразовывать его выражения по формальным правилам.
А вот про то, что можно было бы назвать монадами в других языках — было бы полезно услышать. Так может и монады понятны станут… Когда станут опираться на известные понятия.
ответы добавлены в конец топика
Эта статья замечательный способ запутать разработчика. Давайте лучше писать вообще на haskell без haskell, например:
import BASIC
main = runBASIC $ do
10 LET X =: 1
20 PRINT "Hello BASIC world!"
30 LET X =: X + 1
40 IF X <> 11 THEN 20
50 END
Эта статья замечательный способ запутать разработчика.
Что вы хотели бы там прояснить? Может быть, лямбда функции?
Давайте лучше писать вообще на haskell без haskel например:
Многие так и делают. Хотя назвать это «haskell без haskell» не получится, но встроенные проблемно-ориентированные языки очень распространены, примеры:
hackage.haskell.org/package/atom/ — edsl для генерации embedded кода на си
jaspervdj.be/blaze/ — edsl для построения html
legacy.cs.uu.nl/daan/parsec.html — edsl для парсинга контекстно-свободных(и некоторых КЗ — грамматик)
www.lexifi.com/downloads/frankau.pdf — edsl для трэйдинговой системы
Что вы хотели бы там прояснить? Может быть, лямбда функции?
Давайте лучше писать вообще на haskell без haskel например:
Многие так и делают. Хотя назвать это «haskell без haskell» не получится, но встроенные проблемно-ориентированные языки очень распространены, примеры:
hackage.haskell.org/package/atom/ — edsl для генерации embedded кода на си
jaspervdj.be/blaze/ — edsl для построения html
legacy.cs.uu.nl/daan/parsec.html — edsl для парсинга контекстно-свободных(и некоторых КЗ — грамматик)
www.lexifi.com/downloads/frankau.pdf — edsl для трэйдинговой системы
Насколько я понял, здесь результат не поменяется, НО поменяется порядок поулчения этого результата. Если бы приоритетPrelude> (putStrLn "Строка 1") >>= (\a -> putStrLn "Строка 2") >>= (\b -> putStrLn "Строка 3")
Строка 1
Строка 2
Строка 3
Забегая вперёд, скажу что оператор »= имеет очень низкий приоритет и при желании в этом примере можно обойтись без скобок.
>>= был ниже, чем у ->, то вот этот код, который вы привели позже:Prelude> getLine >>= \a -> putStrLn "Вы ввели:" >>= \_ -> putStrLn a
asdf
Вы ввели:
asdfPrelude> getLine >>= (\a -> putStrLn "Вы ввели:") >>= (\_ -> putStrLn a)
:1:62: Not in scope: `a'Отлично подмечено!
В данном случае \a -> это парметр лямбда-функции, тело которой — весь остаток строки. А первый bind связывает getLine и (\a -> putStrLn «Вы ввели:» >>= \_ -> putStrLn a).
Поэтому скобки более правильно было бы расставлять так:
Prelude> getLine >>= \a -> putStrLn "Вы ввели:" >>= \_ -> putStrLn a
В данном случае \a -> это парметр лямбда-функции, тело которой — весь остаток строки. А первый bind связывает getLine и (\a -> putStrLn «Вы ввели:» >>= \_ -> putStrLn a).
Поэтому скобки более правильно было бы расставлять так:
Prelude> getLine >>= (\a -> putStrLn "Вы ввели:" >>= (\_ -> putStrLn a))
Превосходная статья.
Лично у меня после этого www.muitovar.com/monad/moncow.xhtml наступило просветление.
Лично у меня после этого www.muitovar.com/monad/moncow.xhtml наступило просветление.
Ну и от себя 5 копеек.
1. Есть прекрасная презентация, объясняющая преимущества Хаскеля mmcs.sfedu.ru/~ulysses/IT/Haskell/papers/why-haskell-censored.pdf
2. На русском языке есть две годные книжки за авторством Душкина.
1. Есть прекрасная презентация, объясняющая преимущества Хаскеля mmcs.sfedu.ru/~ulysses/IT/Haskell/papers/why-haskell-censored.pdf
2. На русском языке есть две годные книжки за авторством Душкина.
Действительно, годная презентация!
Но. Опытному программисту на haskell это всё и не нужно объяснять. А вот опытному программисту на с++ никакими аргументами не доказать что map лучше for. Хоть об стену разбейся. Почему? Вопрос открыт.
Диалог слепого с глухим обычно примерно следующий:
— В map нет побочных эффектов, код более надёжен!
— Чо? Каких эффектов? Какой надёжен, он же непонятен! А вот for понятен каждому!
Но. Опытному программисту на haskell это всё и не нужно объяснять. А вот опытному программисту на с++ никакими аргументами не доказать что map лучше for. Хоть об стену разбейся. Почему? Вопрос открыт.
Диалог слепого с глухим обычно примерно следующий:
— В map нет побочных эффектов, код более надёжен!
— Чо? Каких эффектов? Какой надёжен, он же непонятен! А вот for понятен каждому!
Почему-то мне, как опытному (более-менее) программисту на C++ аргументы показались убедительными. Сами идея хорошая. Особенно понравилась возможность параллельного выполнения программ на функциональных языков (без мьютексов, нитей и тд). Я бы на всякий случай включил ссылку в статью.
Кстати, в институте, когда нам объясняли ФП (кажется, это был Lisp, а возможно как раз и Haskell) на вопрос «а кому это все нужно» лектор (аспирант) ответил что-то в стиле «ну, математикам такой язык понятнее». Вопиющая безграмотность!
Всё таки кто автор презентации, на каких условиях распространяется?
Не знаю, мне ссылка через твиттер пришла.
Изначально презентация была размещена в ЖЖ-сообществах ру-лямбда и ру-декларатив, сходу могу дать ссылку на второе, видимо, спрашивать надо там:
ru_declarative.livejournal.com/97251.html
Я менее аккуратный в вопросах лицензий человек, так что я выбросил оттуда слайд с матом (заодно потерялись все гиперссылки, что ужасно), перевыложил в сеть университета (домен sfedu.ru) и дал ссылку студентам.
ru_declarative.livejournal.com/97251.html
Я менее аккуратный в вопросах лицензий человек, так что я выбросил оттуда слайд с матом (заодно потерялись все гиперссылки, что ужасно), перевыложил в сеть университета (домен sfedu.ru) и дал ссылку студентам.
Хакель без монад называется LISP :)
Для тех, кто все-таки хочет разобраться с тем, что такое монады я перевел очень толковую статью о них, которая на примерах на Javascript и Haskell отвечает на вопрос, что же это такое и зачем их придумали. joydevel.blogspot.ru/2013/01/haskell-javascript.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Haskell без монад