Посоветуйте хорошую книгу по Haskell для начинающих.

В 15 лучше начать с Pascal. Не шучу.

Блин, ну есть языки и получше нынче. Например, питон. Я не могу всерьез относиться к Object Pascal, он был склепан на коленке в угоду помешанным на ООП академикам, причем, реально полезные функции завезли только недавно, как то шаблоны те же.

А почему не для прода по вашему

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

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

Кроме того, очень тяжело отлаживать, оценивать производительность и расход памяти(в основном из-за тотальной ленивости в языке).

Ну и не будем забывать про кадры. Людей искать тяжело, а качество их оставляет желать лучшего. Хорошие программисты могут знать Haskell, но на работе используют «обычные» языки - C++, Java, C#, Kotlin и т.п.

Ну и не будем забывать про кадры. Людей искать тяжело, а качество их оставляет желать лучшего. Хорошие программисты могут знать Haskell, но на работе используют «обычные» языки - C++, Java, C#, Kotlin и т.п.

Мне очень интересно мнение человека, который «делает работу работать». Я так понимаю, что речь идет о каких-то массовых прикладных вещах, вроде «сделать товарооборот и бухгалтерию крупной фирме». Как я понял, причина выбора языков состоит главным образом в том, чтобы найти под них кадры, а не потому что они подходят/не подходят к задаче.
Вот я не люблю C++, хотя под мои склонности и способности именно он больше всего подходит, и по нему много работы. То есть, получается, что менеджмент «сговорился» искать писателей на крестах. Я дурак, что их не изучаю?
С другой стороны, у нас тут сидит товарищ ананас, который пишет на C/GTK, но я боюсь, что в стране подобных умельцев, как и вакансий, можно по пальцам пересчитать.

Есть смысл посмотреть на новые и уже выстрелевшие языки - Kotlin, Swift. А может стоит подумать о C# и Java. А может и C++.

Смотрю я на этот котлин со свифтом, смотрю... А они для чего-то, кроме андроида с гейфоном применяются? Kotlin - это ведь та же самая Scala с маникюром, не? Почему тогда скалу не советуют?

Из функциональных языков Хаскель один нормальный.

Из функциональных языков Хаскель один нормальный.

Лисп - отстой, ракет - дерьмо собачье, Scala - неповоротливый кирпич, Erlang - тормоз, Clojure - никому не нужно, F# - неудобное барахло, OCaml - тухляк. Одним Хаскелем и живы. Я ничего не пропустил? Или может все-таки кто-то не совсем готов отвечать за свои слова? Или он нормальный потому, что никому еще толком не доводилось на нем писать? Типа «хорошо там, где нас нет»?

Из функциональных языков Хаскель один нормальный.

Лисп - отстой, ракет - дерьмо собачье, Scala - неповоротливый кирпич, Erlang - тормоз, Clojure - никому не нужно, F# - неудобное барахло, OCaml - тухляк. Одним Хаскелем и живы. Я ничего не пропустил? Или может все-таки кто-то не совсем готов отвечать за свои слова?

Всё проще: ни один из перечисленных тобой языком не является функциональным. Кроме haskell, конечно.

Функциональный язык — основанный на функциональной парадигме. Как Haskell. А ты перечислил императивные языки, которые имеют те или иные черты функциональности. И этими чертами можно пользоваться ровной в той степени, насколько того хочет/умеет программист. А можно фигачить чистую императивщину. И это будет просто и удобно, потому что язык императивный по своей сути. С опциональными ФП-плюшками.

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

Я с такой начинал - Programming in Haskell, Graham Hutton

Всё проще: ни один из перечисленных тобой языком не является функциональным. Кроме haskell, конечно.
Функциональный язык — основанный на функциональной парадигме. Как Haskell.

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

Функциональность является позитивным признаком, а не негативным. Язык функционален, пока в нем есть возможности функционального программирования

Ок, допустим твоё определение. Так что, Питон тоже функциональный? И C++? Ты же не будешь отрицать, что там эти возможности тоже есть?

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

Раскрой свою мысль, пока не понимаю, что ты имеешь в виду. Стандартная библиотека Хаскеля написана на Хаскеле.

Для обучения основам CS лучше ничего не придумали.

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

Ок, допустим твоё определение. Так что, Питон тоже функциональный? И C++? Ты же не будешь отрицать, что там эти возможности тоже есть?

В крестах есть намеки на функциональщину, но они очень слабые, в основном это процедурщина и ООП: https://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oo...
Критерием наличия той или иной парадигмы я бы ставил выраженную реализованность онной в языке.
Хаскель является чисто функциональным, поскольку иные парадигмы в нем слабо выражены.
Питон является многопарадигменным, то есть, как минимум процедурным, объектно-ориентированным, и функциональным, потому что каждая из этих парадигм хорошо выражена в нем.

Раскрой свою мысль, пока не понимаю, что ты имеешь в виду. Стандартная библиотека Хаскеля написана на Хаскеле.

Да элементарный libraries\base\GHC\Float.hs, libraries\base\GHC\List.hs. В STM страшно заглядывать, на самом деле, потому что там вообще С, С--, особая обработка мусора и исключений. Раньше были одни анбоксы, сейчас с восклицательными знаками чуть полегче стало.

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

Не совсем так. Просто это один из факторов. Код мало написать, его нужно развивать, исправлять и поддерживать.

Вот я не люблю C++, хотя под мои склонности и способности именно он больше всего подходит, и по нему много работы

Тогда у вас только на раст надежда(мои он не оправдал). Или на какой-то будущий язык.

Смотрю я на этот котлин со свифтом, смотрю... А они для чего-то, кроме андроида с гейфоном применяются?

Ну некоторые проекты таки переползают на котлин с java, вне зависимости от предметной области. Свифт вроде как не востребован вне яблочников, но это сама по себе широкая ниша.

Kotlin - это ведь та же самая Scala с маникюром, не?

Scala гораздо сложнее и запутаннее. «C++ 21 века». Котлин - это скорее правильно спроектированная Java

Kotlin - это ведь та же самая Scala

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

Для Spring Kotlin как родной.

Прекрати тупняк, не позорь нас, хаскелистов!

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

Тогда у вас только на раст надежда(мои он не оправдал). Или на какой-то будущий язык.

А почему не оправдал-то? Неудобный?

Обычные кодеры знают что такое быстрая сортировка.

А почему не оправдал-то?

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

Писать на нем не проще и не быстрее, чем на C++. Перевести проект постепенно на rust так же особо не получится. Ценность доказать довольно тяжело, особенно если уже есть CI&CD с интегрированными тестами, статическими анализаторами, санитайзерами и т.п. Синтаксис обычно плюсовикам не нравится, концепции заходят тяжело(в первую очередь как раз из-за отсутствия ощутимой ценности).

Тут можно сравнить с подходом Kotlin. Вы на нем можете сказать практически все, что вы говорили на java, вы можете использовать все, что вы написали на java. Язык не отказался от принятых на данный момент концепций. Язык сделал те изменения в системе типов, которые приносят ощутимую пользу и интуитивно понятны(null safety), а не заставляют бороться с компилятором. С другой стороны, язык не поддается сразу модным тенденциям и не пихает в язык все подряд(xml в Scala - один из классических примеров), равно как и не переусложняет без необходимости (предоставляя другие пути решения проблемы, как например они сделали с pattern matching которого в языке пока нет, но с помощью других средств вы можете решать реальные проблемы столь же удобно). При этом котлин гораздо лаконичнее java, ускоряет разработку и упрощает многие вещи.

Вот как Kotlin пришел в мир java, так же и в мир C++ может быть придет новый язык. Я ждал от rust чего-то такого. Так он неплохой язык и будет скорее всего важной вехой в истории, хотя бы благодаря своим статическим проверкам, но нужно двигаться дальше.

В крестах есть намеки на функциональщину, но они очень слабые, в основном это процедурщина и ООП

С этим полностью согласен

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

Либо ты не знаешь Питона, либо не знаешь функциональной парадигмы. Где ты её там отыскал? map-zip-filter, куцый functools, списковые включения, лямбды (грязные!). В общем-то всё, если ничего не забыл.

Да элементарный libraries\base\GHC\Float.hs, libraries\base\GHC\List.hs. В STM страшно заглядывать, на самом деле, потому что там вообще С, С--, особая обработка мусора и исключений. Раньше были одни анбоксы, сейчас с восклицательными знаками чуть полегче стало.

Естественно, примитивы пишут «грязно». Это явно не тот хаскель, от которого люди тащятся. Ну и что? Ты исходники стандартной библиотеки C++ почитай, тоже волосы дыбом встанут.

Ещё комментарий про питон и ФП

В Python2 в дефолтном пространстве имён вместе с map был и reduce, что косвенно доказывает, что на заре развития питон действительно пытался заигрывать с ФП. Но позднее они посчитали, что понятие свёртки слишком сложно для рядовой python-макаки, и в Python3 задвинули reduce в дальний угол (в модуль functools, которым на практике никто не пользуется). Очень характерное изменение.

Я поясню. Если хотя бы полгода плотно изучать и интересоваться Хаскелем, с огромной вероятностью поциент наткнется на этот баян с qsort. На форуме, в чате, реддите — где угодно. Лично я про это узнал в первую же неделю, просто взахлёб перечитывая весь хабр по тегу haskell

Но позорил он вовсе не по тому, что этого не знал, а потому что продолжал нести бред про красоту кода, когда ему уже сказали, что это два разных алгоритма, и сравнение некорректно

Либо ты не знаешь Питона, либо не знаешь функциональной парадигмы. Где ты её там отыскал? map-zip-filter, куцый functools, списковые включения, лямбды (грязные!). В общем-то всё, если ничего не забыл.

Map-filter-reduce и лямбды могут иметь побочные эффекты, а могут не иметь - тебя никто не ограничивает. Хочешь - добавь проверку на чистоту - язык это позволяет, как ни странно: https://stackoverflow.com/questions/45592490/identifying-pure-functions-in-py...
Замыкания есть, функции передаются как аргументы и возвращаются как результат, для желающих исключить побочные эффекты еще есть неизменяемые типы данных есть. Он не ограничивает, в отличие от чисто функциональных языков, даже, я бы сказал, позволяет слишком много, и нужно делать дополнительные действия, чтобы правильность алгоритмов/типов проверялась при компиляции.

Естественно, примитивы пишут «грязно». Это явно не тот хаскель, от которого люди тащятся.

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

Ну и что? Ты исходники стандартной библиотеки C++ почитай, тоже волосы дыбом встанут.

Кресты - это вообще издевательство, я ни разу не спорю. Скоро, скоро Страуструп наконец сдохнет, и будет крутиться в гробу.

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

Что до Haskell, то я за всё время практически не встречался (может конечно просто не повезло со «злым» high-load-ом?) с ситуацией, где Haskell (GHC) - узкое место в плане производительности. При очень высоких уровнях абстракции он всегда выгодно отличается от действительно «обычных» (с точки зрения бизнеса) языков: php/js/python/ruby/etc. Лишь в личных экспериментах в realtime-critical областях были некоторые нюансы, где нужно код писать с учётом работы GC и всякого боксинга, но даже и там он успешно может применяться до некоторых пределов.

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

Упомянутые C++, Java, C#, Kotlin - с точки зрения сурового бизнеса - не совсем «обычные» языки, и гораздо чаще вы встретите php, js, ruby, python, и другой подобный детсадовский шлак вместо них. Потому что кадры доступнее. При этом всякие боттлнеки, «тормоза» и невероятная жирность при простых задачах встречаются чуть ли не в каждом проекте, сразу, на ранних этапах с последними (при том что с Haskell ничего такого не происходит), это бизнес не останавливает, и не форсирует даже использовать c++/java/c#/kotlin, где и специалистов сложнее искать, и платить им нужно больше. Т.е. можно сказать что всё только к вопросу кадров и их стоимости и сводится.

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

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

С этим никак не могу согласиться, напротив, у меня очень положительные впечатления от изучения и работы с чужим кодом на Haskell. Как часто меня убивало меня иной раз читать какую-нибудь императивную вермишель на «обычных» языках с кучей переменных, меняющих свой стейт в 10 местах на разных уровнях вложенности, да ещё иной раз за пределами функции. Плохо бывает только когда программист плохо знает Haskell, использует много не тотальных функций, выбирает дебильные фреймворки, задизайненные для слабых программистов, пришедших из каких-нибудь ruby и на базе решений оттуда, где могут быть рантайм-фейлы из-за опечатки в имени блока в роуте и т.п.

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

Дело не в этом, а в том, что Haskell сконцентрирован в первую очередь вокруг написания «чистого» кода, а любое «грязное», но по каким-то причинам необходимое решение, - стоит немедленно абстрагировать в библиотеку, отдельный модуль, но никак не поощрять писать «грязно» в конечном продуктовом коде (иначе никакой ценности в изяществе Haskell кода и не было бы, это была бы очередная Scala). Haskell не создан для написания алгоритмов, это понятно уже из того, что он «чисто-функциональный». Все страшные оптимизации должны быть возложены на компилятор, в крайнем случае на библиотеки, конечный код должен быть максимально абстрактным, - в этом и есть вся идея «чистоты» кода на Haskell, странно его упрекать в том, что на нём плохо и неповоротливо пишутся императивные решения (хотя императивные-то они только в рантайме, все IO-монадки на самом деле «чистые»), - он за это ведь и ценится.

чтобы правильность алгоритмов/типов проверялась при интерпретации.

fixed

Лисп - отстой, ракет - дерьмо собачье, Scala - неповоротливый кирпич, Erlang - тормоз, Clojure - никому не нужно, F# - неудобное барахло, OCaml - тухляк.

Всё именно так.

Советую книгу: как приседать со штангой во время поедания борща

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

Не императивные, а те, что нужны в реальной программерской жизни.

Про хаскель уже посоветовали и ещё что-нибудь напишут, но для начала, лучше что-то вроде этого: http://www.stolyarov.info/books

Можно пример, т.к. не совсем понятно о чём речь. Что понимается под «реальным из программерской жизни», что плохо пишется на Haskell? Я уже изложил свою версию о том, что что-то такое нужно, как правило, очень редко, когда обнаруживается bottleneck, в целом зависит от предметной области конечно, хотелось бы из реальной практики.

А почему Racket - «дерьмо собачье»? Не то чтобы я возражал, но интересна Ваша версия. Я конечно обомлел, когда у меня helloworld какой-то в 3 строки (причём не полных, а 30-40 символов) съели сразу 200миб где-то. А его IDE (DrRacket), с виду простенькая, подъела 600-700миб.

Да они все мультипарадигменные. Только Хаскель чисто функциональный. Хаскель быстрый, удобный, есть интерактивный интерпретатор. На Хаскель есть спрос на рынке труда. А значит проще найти помощь, сторонние библиотеки и так далее.

Есть ещё Clean и Miranda, но о них я ничего не могу сказать. Но они тоже тру-функциональные.

чтобы правильность алгоритмов/типов проверялась при интерпретации.

fixed

Не фиксед. Питон можно скомпилировать и сделать статическую типизацию.

Что до Haskell, то я за всё время практически не встречался (может конечно просто не повезло со «злым» high-load-ом?) с ситуацией, где Haskell (GHC) - узкое место в плане производительности.

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

Низкоуровневые, императивные, алгоритмические оптимизации очень редко действительно нужны в конечном продуктовом коде

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

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

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

Знаешь, есть люди, которые говорят, что лучший язык программирования - это SQL, потому что он декларативно определяет условия выполнения операций, а исполнитель уже по ситуации выбирает механизм исполнения. Эти люди немножко забывают, что для код, исполняющий их декларативную команду, намного сложнее и на него угрохано огромное кол-во времени.
Точно так же хаскелисты увлекаются декларативно-функциональным языком, являющимся на самом деле интерфейсом к проклятой императивщине, но в упор не хотят видеть, что большую часть работы на самом деле выполняет именно еретическая императивщина, а никак не их чистый православный код. И как только возможностей императивной реализации становится недостаточно, то приходится слазить со своей розовой пони, и начинать ковырять говно вилкой.
Посмотри на досуге реализацию SMT, MVar, ввод-вывод (readRawBufferPtr, writeRawBufferPtr в base/GHC/IO/FD.hs, которое потом идет в base/GHC/Event/Thread.hs и в base/GHC/Event/Manager.hs просто чтобы прочитать файл асинхронно). Ты же потом пишешь три строчки кода и восхищаешься тому, какой ты клевый программист, но за этими тремя строчками - тысячи строчек готовых решений.
Но вот тебе понадобилось сделать что-то выходящее за рамки стандартных функций - и че делать? Ковырять стандартную библиотеку, ковырять рантайм, и тогда трудоемкость улетает в космос, и тогда к тебе наконец придет осознание того, сколько людей полегло за каждую готовую, отлаженную фичу. Асинхронный ввод-вывод на форточки не спортировали, например, потому для каждой блокировки ввода-вывода там создается свой тред блокировки.

fac n = product [1..n]

func fac(n int) int {
    if n > 0 {
        return n * fac(n-1)
    }
    return 1
}

Очевидно же, что Го для задротов. Столько лишней возни. Столько ненужного кода.

int
fac (n int) {
    if (n > 0) {
        return n * fac(n-1);
    }
    return 1;
}

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

А если кроме шуток, то сменить язык — и сменить парадигму — это разные вещи. Второе как правило вообще не возможно. Все кто пишут на Го там или с Си, или с Питона, или типа того. В с вытекающими. У Го низкий порог вхождения, потому что он мультипарадигменный. В случае с Хаскель это не возможно.

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

Давай я тебе поставлю обратный вопрос: назови мне крупную тулзу на хаскеле, которая бы нашла применение в реальной жизни. Хаскель у нас сколько в индустрии? 30 лет?
Сразу оговорюсь, что xmonad на 4 тыс строк - это не крупный проект. Pandoc - уже лучше, но это 60 тыс строк разрозненных читателей и писателей разных форматов. Darcs на 50 тыс строк, половина которых - это интерфейсы для команд? Извините, но это глюкодром и экспоненциальная зависимость времени слияния от размера репозитория.

SQL действительно лучший язык, с одним уточнением это специализированый язык для реляционных БД. Возможно про Haskell так же нужно говорить что это язык не общего программирования а специализированный язык для мат. логики и теор ката?

После твоего примера «быстрой сортировки» кажется, что эти разговоры бесполезны.

Жирно набрасываешь. Про кадры уже говорили. Go-vno для вчерашних пейсателей на javascript (с тем же уровнем компетенции, с минимальными отличиями, язык для таких и проектировался, ну, хотя бы проектировался, в отличии от последнего). Нужность/никомуненужность определяется отнюдь не качеством технологии, сходи на рынок вакансий, и посмотри чего там больше, по большей части всё крутится вокруг JS-макак, а Go’vno там чисто так, прилепилось рядом, под подошву.

Ну ок, слив засчитан.

Это не так. Лично я применял Haskell для: много веба-хуеба всякого; для утилитарных задач (у меня есть свой хак для кастомизации поведения клавиатуры, который я уже годами использую на постоянной основе, вообще первый долгоживущий проект мой на Haskell, за последние пару лет почти каждая нажатая мною клавиша - стриггерена этой утилитой), всякие мелкие утилиты системные, которые сам использую (ну там не из моего - xmonad например, window manager такой для иксов); для обработки графики, rt-рендеринга; для dsp-процессинга звука; для работы с midi и гуями, etc. Логику и теор. кат можно и лучше обкатывать на Idris, в котором есть завтипы из коробки, но который в реальном мире слабо применим из-за проседающего перформанса и скудной экосистемы. Ну вот Кметт там матановые вещи всякие обкатывает, но это как правило не ограничивается чисто диванным теоретизированием и экспериментированием, а потом появляются библиотеки, которые уже с практическими утилитарными целями используют в конечных продуктах.

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

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

Посмотри на досуге реализацию SMT

Ты хотел сказать STM?

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

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

https://youtu.be/1jZ7j21g028?t=2901 Вот тут человек называет это «most basic stupid quicksort implementation», но по прежнему «quicksort». Проблемы дефиниции. То, что ты считаешь недопустимым называть это «quicksort»-ом, а только соответствующий императивный алгоритм, не означает что все с тобой согласны.

Вот можешь ещё взглянуть насколько часто это встречается: https://duckduckgo.com/?q=haskell+quicksort&t=ffab&iar=images&iax=images&ia=images

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

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

Под капотом не просто грязная работа, под капотом говна залили под крышку, когда при той же реализации MVar и STM дописывали грязные хаки в GC и обработку исключению.
Таким образом, если ты хочешь сделать какой-то крупный проект, то тебе придется дописывать компилятор/рантайм, что становится неотъемлимой частью разработки на хаскеле, поскольку в крупном проекте ты неизбежно упрешься в ограниченность реализации, а есть очень мало кодеров, которые умеют это хорошо делать. Но ты, почему-то, в упор отказываешься видеть эту вторую сторону медали.

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

Поздравляю, юнец, ты понял, что такое «абстракция» в программировании

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