Зачем нужны Haskell, Zig, etc... Учу каждый день хаскель, чтобы потом что? Сидеть пердеть на JS ? При этом о хаскеле говорят везде, где говорят о фп, когда в фп есть языки более прикладные и более интересные(Rust, F#). Для чего учить языки которые нигде не используются и за которые не платят?
Научный интерес или хобби. Какая разница, в свободное от работы время играть в доту, дрочить хаскель или фапать на ножки блогерш?
на нём охуенно приятно писать. в его внутренностях чертовски интересно ковыряться. магическая система тайпклассов приносит тебе море (почти) халявных функций к любому классу. автовыведение типов тоже неплохо помогает. на применимость/популярность языка в общем-то пох)
Учу из любопытства, отвлекаясь иногда от джавы, ну и чтобы потом вкатиться в раст однажды.
эти вообще не позиционируют себя как адекватные
хаскель после богопротивных плюсов - любовь с первого взгляда не пробовал эти ваши Rust, F#, что в них есть такого, чего нет в хаскеле?
>не пробовал эти ваши Rust, F#, что в них есть такого, чего нет в хаскеле
работа
больше ничего?
Т.к. модель не зависит от реализации, там есть автоматическое выведение типов.
К примеру, оператор сложения берет все типы из категории чисел, инты флоаты и тп и таким образом раскручивает клубок типов в программе.
Поэтому итерация от одной версии функции к другой в F# очень быстрая, плюс можно работать с библиотеками, с типами которой ты не знаком.
Плюс тебе не нужно предугадывать будущее, записывая выходной тип наперед.
но в хаскеле тоже есть автоматическое выведение типов. или я пропустил какое-то большое отличие?
например к функциям
f2 a b = a / b
f a b = a + b
будет автосгенерированны такие сигнатуры:
f2 :: Fractional a => a -> a -> a
f :: Num a => a -> a -> a
Я на хаскель смотрю со стахом, поэтому мог упустить что-то. Насколько далеко хаскель раскручивает типы?
Он раскрутит все функции одну за другой без использования оператора композиции? (>>>)
К примеру:
Вот такую сигнатуру сможет выдать сам без указания типов вовсе?
((unit -> int) -> (unit -> int -> int -> int))
>Он раскрутит все функции одну за другой без использования оператора композиции?
применение композиции или простой вызов функций из функций - для хаскеля нет разницы а других опций нет - в хаскеле нет понятия оператора
>Насколько далеко хаскель раскручивает типы?
довольно далеко. он может не справиться в следующих cитуациях:
1) принципиально невозможно определить тип/слишком много вариантов и нет подсказок
main = readLn >>= print
=>
main = (readLn::IO Int) >>= print
2) когда нужного типа не существует
f5 a b c = a / b `mod` c
как здесь - число должно быть одновременно целым и дробным, нужно явное приведение типов
>Вот такую сигнатуру сможет выдать сам без указания типов вовсе?
f3 a b c d = d + sum ( mfilter (>c) $ fmap a b)
у такой функции будет сигнатура
f3 :: (Num a1, Foldable t, MonadPlus t, Ord a1) =>
(a2 -> a1) -> t a2 -> a1 -> a1 -> a1
в зависимости от дальнейшего использования она может рассматриваться как
(a2 -> a1) -> (t a2 -> a1 -> a1 -> a1)
или как
(a2 -> a1) -> t a2 -> (a1 -> a1 -> a1)
и т.д. благодаря частичному применению функций
конкретные типы будут выбраны непосредственно при вызове для t подойдёт, например, список, для a1 - Int, для а2 - любой тип
лол, скрин случайно добавил
Haskell vs Rust, F#, etc. thread
Научились а и б складывать, на этом интерес к хаскелю пропадает
Научились а и б складывать, на этом интерес к хаскелю пропадает
ну, у меня нет, лол.
хаскель конечно дофига упрощает сложные задачи генерация всех возможных перестановок массива и всех возможных комбинаций элементов списка - алгоритмы на полстрочки в хаскеле, но зато усложняет некоторые простые. ты наверняка сможешь создать проблемы некоторым хаскелистам таким вопросом: как вывести массив в консоль без скобок и запятых, просто числа в столбик - если хаскелист не знает нужную функцию, то код будет не 10/10, да и напишет он его не сразу)
>Зачем нужны Haskell, Zig, etc...
Для получения удовольствия от программирования. Зачем люди играют в компьютерные игры? Просто для удовольствия. Вот что происходит, когда человек запускает хорошую компьютерную игру, если абстрагироваться от конкретики? Прежде всего - это wow-эффект. Разумеется, wow у всех случается от разного. Кто-то говорит: "Wow, какой графоне!", кто-то: "Wow, какие механики!", кто-то: "Wow, какая атмосфера!" Но суть в одном - щенячий восторг и выброс дофамина, и человек начинает получать удовольствие от самого процесса игры, а не от того, что за прохождение игры ему чего-то будет.
Дело в том, что программисты любят подрачивать на некую эстетику инструмента. Ты, наверняка, слышал такие слова, как "костыли", "бойлерплейт", "копипаст", "легаси" - все они употребляются в негативном контексте. Но нет объективного обоснования (по крайней мере, очевидного), почему это плохо. Да, можно притянуть за уши какие-то утверждения, что мол "костыли" сложно сопровождать, но кто и когда объективно измерял сложность их сопровождения? Кроме того, я с тем же успехом могу сказать, что это не "костыль", а "общепринятый паттерн", а если мой "костыль" - не паттерн, а какое-то моё личное изъёбство, я могу сказать, что это моё "ноу-хау".
Но это не сработает. Другие программисты скажут: "фу, говно, не красиво". Причем, даже студент, хуёв не нюхавший, может сказать: "фу, говно", хотя, казалось бы, откуда ему знать, какие затраты на сопровождение могут породить в будущем те или иные решения? Потому что тут дело вовсе не в эффективности или коммерческой целесообразности, хотя их и пытаются приплести чтобы обосновать использование "красивых" решений, первична тут не рациональность, а чувство эстетики.
И это чувство у людей существует. Более того, оно даже достаточно универсально. Т.е. большинство людей сойдутся во мнении, что A может быть более эстетичным, чем B, даже если они вообще не шарят в назначении этих объектов.
Я даже могу провести ментальный эксперимент. Вот тебе две картинки с рубанками. Я думаю, ты не настолько искушен в деревообработке, чтобы сказать, какой рубанок лучше. Но я уверен, к какому именно из них твои ручонки потянутся, как и ручонки большинства других анонов, если я просто предложу обстругать деревяшку. Ведь сразу видно, что один - это просто рубанок, а другой - это wow, его подержать в руках охота, даже если ты не знаешь, как правильно его держать.
Так вот, Haskell - это и есть дрочь на эстетику и wow-генератор от мира программирования. Вся история его дизайна - это как сделать "правильно", с минимумом "костылей" (при том, что никто на самом деле не знает, что такое эти богомерзкие "костыли" и чем они плохи, но есть некий консенсус сообщества программистов в области "красивого"). Поэтому любой вкатывальщик в Haskell ловит мощный wow-эффект и one love, вот как этот и все выше отписавшиеся, я, кстати, такие же ощущения словил, когда вкатился. Масла в огонь подливает тот факт, что язык довольно динамично развивается, и даже если ты в него вкатился и заценил все его решения, через год будет что-то новенькое и ты скажешь: "wow, а теперь и так можно?!"
> Учу каждый день хаскель
Ну и да, прочитал предыдущие ответы, почти во всём согласен.
- Хаскель не изучают, в нём ковыряются. Это примерно как разобрать рубанок с пика, чтобы посмотреть из чего он сделан, потому что он прикольный.
- На Хаскелле не программируют, с ним играют. Хаскель конкурирует не с Java и C++, а с Дотой и ножками блогерш.
Хаскель не упрощает решение "сложных задач", он их даже чаще усложняет. Но делает процесс решения кайфовым.
Вердикт.
Хаскель - идеальный язык для пет-проектов. Проблема пет-проектов в том, что они никому не нужны и никогда нет стимула довести их до конца. А Хаскель всегда драйвит на на то, чтобы изучить что-нибудь новое и что-нибудь закодить, он - как игра. Возможно, ты никогда не докодишь свой пет на Хаскелле, ты так и будешь дрочить на охуенные экспериментальные подходы, но в процессе этого ты узнаешь много нового и применишь это уже в реальных проектах на работе.
Промышленный язык не прикрепился.
И снова не прикрепился, третья попытка вот в этом и проблема всех этих плюсов и джав, что они нихуя не работают из коробки и большую часть времени тратишь не на программирование, а на решение инфраструктурных проблем
Что-то неубедительный пример. Кто знает про forM_ напишет с использованием forM_, а кто не знает - напишет рекурсивную функцию.
> Потому что тут дело вовсе не в эффективности или коммерческой целесообразности, хотя их и пытаются приплести чтобы обосновать использование "красивых" решений, первична тут не рациональность, а чувство эстетики.
Может оказаться, что есть неявная связь между чувством эстетики и рациональностью. Тем более, если это чувство у разных людей срабатывает одинаково. Может быть это на фундаментальном уровне связано со способностью различать простое и сложное. Возьмём задачу составления из элементарных вещей каких-то конструкций. Когда ты совмещаешь простые вещи и в итоге получаешь сложную составную вещь - тут ничего удивительного. Но когда ты совмещаешь простые вещи и в итоге получаешь простую составную вещь, то в мозгу что-то щёлкает "Смотри-ка как хорошо получается: и там просто, и там просто." Как-то так работает это чувство эстетики, о котором ты пишешь, и, как мы видим, в нём есть что-то рациональное, какое-то распознавание паттернов. Но распознавание паттернов зависит от опыта тоже.
ну, это всё таки тривиальная задача с точки зрения большинства языков, а тут надо рекурсию хуярить, да не простую, а с монадами/аппликативными функторами.
А на джаве раньше нужно было писать "public static void main(String[] args)". Кто-то рассказывал, что в универе заставляли этот набор слов заучивать наизусть, или что-то в этом роде. Я к тому, что эта строка была нужна для любой программы, даже самой тривиальной.
по крайней мере эта строчка была нужна везде - а for_ в других задачах упоминается не настолько часто - или (если он уже применялся для списков) будет неочевидно, что он может быть полезен и здесь.
хороший пост. в основном двачую, но не тут
>Хаскель не упрощает решение "сложных задач", он их даже чаще усложняет
например мы хотим написать такую программу: дано 7 покерных карт. найти лучшую комбинацию, использующую 5 из них.
1) создадим типы данных для всего, например
data Card_Suit = C | H | S | D deriving (Eq,Ord,Show)
вывод на экран идёт в комплекте, как и сравнения (а не как в плюсах)
а тут у нас трушный полиморфизм и материал для гетерогенного массива - одним простым типом!
data Comb = Empty | Simple_pairs Int Card_Value (Comb) | Straight (Comb) | Flush (Comb) и т.д.
2) теперь нужно выбрать все комбинации по 5 карт
c_5_7 xs=filter ((5==).length) $ filterM (const [True, False]) xs
3) обрабатываем комбинацию
reverse.sort.map (length &&& head ).group.sort.map b
справа налево: извлекаем масть или номинал, сортируем и группируем, создаём пару из головы и длины, сортируем по убыванию [A,K,Q,A]->[(A,2),(K,1),(Q,1)]
4) разбираем все возможные случаи
check_combs(((3,x):(2,y):xs),z,str)
заголовок одной из 8 проверяющих функций. она чекает следующее: в руке минимум 2 разных номинала карт, количество карт:3 карты одного номинала, 2 другого ((3,x):(2,y):xs), стриты и флеши роли не играют. её результатом будет простенький конструктор, вызывающий прочие проверки
High_pairs 3 x (check_combs ((2,y):xs,z,str))
5)а чтобы отсортировать комбинации в конце работы просто вызывается ещё один sort, и готово
таки никто ничего не сказал про zig, clojure и прочее дрочево хотя даже у них есть фанатики
потому что у хаскеля фанатиков куда больше?
> вот в этом и проблема всех этих плюсов и джав, что они нихуя не работают из коробки и большую часть времени тратишь не на программирование, а на решение инфраструктурных проблем
Это как раз проблема хаскеля, лол.
Поставить шарпы это установить сдк, готовую иде и все - готов шлепать любое говно.
Тогда как у хаскеля под виндой половина модулей не соберется, вместо иде кривой плагин с утечкой памяти, а библиотек мало и приходится писать свои велосипеды.
>Тогда как у хаскеля под виндой половина модулей не соберется
не замечал особых проблем
>вместо иде кривой плагин с утечкой памяти
VScode вполне норм
>библиотек мало и приходится писать свои велосипеды
https://hackage.haskell.org/packages/
меньше, чем на c# - но вполне прилично. + хаскель дофига шаблонный, так что свои велосипеды можно будет переиспользовать хоть до посинения
> не замечал особых проблем
Я пытался поставить servant - не вышло. В ошибке сборки прямым текстом говорилось что винда не поддерживается.
> VScode вполне норм
Я так и не научился работать с различными модулями - он тупо их не видит пока ты не откроешь все файлы в проекте.
Ну и были утечки памяти, когда лаба в унтвере на 50 строчек кода сжирала гигов 5 оперативки.
> меньше, чем на c# - но вполне прилично.
95% из них написаны как пет проекты и последний коммит в них был лет 5 назад. Реально, как только не поищу какую-то либу, то она заброшена и часто даже не билдится под современный хаскель.
В общем хаскель это такой язык, где на нужную тебе вещь ти либо ничего не найдешь, либо закинутую и недописанную 5 лет назад библиотеку, которую писал один васян в свободное время. Зато в нем несколько вариантов стандартной библиотеки и куча фреймворков каждый из которых пропихивает свою уникальную парадигму стрелки, мтл, системы эффектов и тд
Я бы хотел что-то написать на хаскеле, но не знаю что. Думал хоть круд напишу, но аналога entity framework тут нет, а я ебал писать свои деплоймент скл скрипты.
Получается, велкам ту F#?
F# это просто c# с немного другим синтаксисом и почти таким же хуевым тулингом как у хаскеля.
В нем нет тайплкасов или хотябы функторов как в окамле, для полиморфизма приходится юзать "шарповские" классы и интерфейсы. Ну и либы в 99% случаях придется юзать шарповские, из-за чего тебя не будет покидать очущение, что ты пишешь на сшарпе со странным синтаксисом.
Иде райдер его хоть и поддерживают, но куда хуже чем сшарп.
Да, в нем есть прикольные фичи, типа тайппровайдеров генерируют типы за тебя в компайлтайме, может быть удобно при работе с джсонами/хмл и даже скл или computation expressions по факту монады, но захардкоженые монады, а не как в хаскеле где монада это всего лишь тайпкласс. Но стоят ли эти фичи того, чтобы избавиться от сшарповского туллинга и начать писать на очень странном синтаксисе?
В хаскеле есть и монады, и нормальная система типов, а template haskell позволяет генерировать в компайлтайме не только типы, но и функции и вообще что угодно. И пишут на нем в чистом ФП стиле, а не в фп/ооп франкенштейне. И кроме тайпклассов там дохулиард расширений для системы типов, скоро даже зависимые типы должны завести.
В общем, я не вижу смысла в фшарпе в 2021. Если хочешь поиграться со всем крутым что есть в фп, в качестве хобби, твой выбор хаскель. Если босс сказал тебе написать круд, но тебе не нравится ооп, то просто пиши в сшарпе в фп стиле! В нем и тулинг нормальный, и язык колегам привычный и все фишки фшарпа в нем есть ок, нет тайппровайдеров, но так ли сильно они нужны? А монады можно накостылить либо через linq, либо через await. С каждой новой версией добавляется все больше фп фич, типа рекордов, паттерн матчинга, свитч экспрешнов, наллабл типов и тд.
>скоро даже зависимые типы должны завести
вот это богоугодня хуйня!
bump
Я наступил в PWSH, C# и F# и я рад, что F# не наступил в тайпклассы и параметризуемые функторы.
Если первые это избыточная абстракция, то второй - антипаттерн для нагромождения нечитаемого кода, где разделение ответственности не имеет понятной грани.
Я еще я рад, что в F# нет ад хок оверлоадов. Любой ад хок чего угодно - смерть.
Хорошо что дон сайм берет в расчет конгитивную сложность и держит энтузиастов ФП под контролем.
Большую часть своего времени я провел за PWSH, но из всех трёх, наиболее читаемым я считаю F#
> F# это просто c# с немного другим синтаксисом
Нет.
>pwsh
Апофеоз говноедства.
тайпклассы охуенны. с чего бы им быть избыточной абстракцией?
Дисклеймер, с хаскелем знаком из документации и видеоуроков сомнительного качества, поэтому могу быть неправ.
К примеру, в хаскеле есть Read, Write, IO монады и проч.
Console.Log в F# это 'a -> unit, в хаскеле это IO монада
Чтение и запись в хаскеле это тоже свои собственные монады, в F# это unit -> 'a
Тут отдает духом ООП, с синглтонами, транзиентами и прочими избыточными абстракциями. Никто не будет спорить, что указанные выше абстракции действительно избыточны?
>Чтение и запись в хаскеле это тоже свои собственные монады
монада для ввода-вывода в хаскеле только одна - IO, read/write - просто функции тайпклассов, аналоги .from_string(), .to_string()
соответственно, функции ввода-вывода в хаскеле имеют сигнатуры
String->IO() вывод
IO String ввод
а вообще вся возня с монадами связана с исключительной чистотой хаскеля - ввод вывод не могут производиться в функции, а должны пробрасываться до main ф-ции как часть возвращаемого значения, возвращаться из неё, и только потом происходить за пределами основной программы - чтобы ничто в программе не имело побочных эффектов
+ монады - маленькая часть всей огромной системы тайпклассов хаскеля см. пикчи но это далеко не все, только самые известные
такие механики как вывод типов активно используют деревья тайпклассов для выбора требуемого типа данных, а при разработке своих типов данных - деревья работают как инструкция по сборке, унификации, и как источник халявных функций
бамп
>параметризуемые функторы
а это что за зверь?
>Может оказаться, что есть неявная связь между чувством эстетики и рациональностью.
А может и нет. Поэтому не стоит пиздеть всем подряд, что Хаскель эффективен и навязывать что-то людям. Если бы он был дохуя эффективным, то стал бы самым востребованным языком. А был бы говном, то и сдох бы давно. Но он уже 35 лет и не в мейстиме и дохнуть не собирается и самый мейстримовый из ФП-языков, в который вкладывались очень хорошие программисты. Значит, что-то есть очень хорошее, и есть что-то не очень хорошее тоже есть.
Например, мы хотим написать не синтетическую программу, а что-то вроде реальной графовой базы данных. И тут выясняется, что хаскеллевские хеш-таблицы не очень производительны, что хаскелевский Protobuf написан каким-то чуваком по-фану, и хаскелевский json тоже сосёт, как и csv.
Сложные задачи - это не покер. Сложные задачи - это реальные задачи. Хаскель красив и потенциально упрощает решение задач. Но вот в реальности у тебя есть неудобная библиотека, но она есть. А в Хаскелле её нет, есть только идея, как её красиво можно было бы сделать.
> Поставить шарпы
Ты просто человек, избалованный коммерческой продукцией мелкософта. У них реально всё охуенно, не зря индусы старались. Но вот инфраструктура Джавы реально перегружена и неудобна по сравнению с Хаскелем. Ты просто попытайся простой проект на Джаве собрать, там же maven, Ад и Израиль. У Хаскелля куда более легковесный стек. И куда более легковесный, чем у MS, просто MS его пока затыкают трудом их программистов.
> F# это просто c#
Согласен. В https://en.wikipedia.org/wiki/F%E2%99%AF_(musical_note) просто синтаксиса добавили. Но с какого хуя ты считаешь, что в Хаскелле тулинг хуёвый? Да он там просто охуенный. До сих пор в Scala жалкие подобия да и в других языках убогие порты. Вот если у Хаскеля и есть проблемы, так это точно не тулинг.
У джавы охуенно удобные иде на любой вкус, а собрать мавеном проект проще, чем сходить посрать. Хаскель же у меня завелся только в редакторе атом, кал индусов под названием vscode потребовал двухчасовых плясок с бубном над плагинами из десятков пунктов, и в результате ни один из плагинов не завелся.
Лучший пример функторов это pwsh, прошу отнестись к pws с сожалением, это был воннаби функциональный язык.
К примеру, функция:
Remove-Item "C:\Windows\system32\svchost.exe"
Просто удалит конкретный файл.
Remove-Item "C:\Windows\system32" -Recurse
Удалит все файлы и подпапки в директории.
С течением времени обрастают новыми параметрами и т.п, которые входят в диапазон обязанностей и однажды он становится нечитаем.
Кстати по поводу нечистоты F# и IO, в F# принято держать весь OI на границах.
Я когда делаю приложухи на ASP.NET, я весь IO и все побочки держу в одном месте, на эндопинтах.
Все остальные функции чистые как слеза и могут быть ленивыми, поинт с чистотой хаскеля мне не понятен.
> в F# принято держать весь OI на границах.
> Все остальные функции чистые как слеза и могут быть ленивыми
Т.е. речь о каком-то негласном соглашении, так? Наверное неплохо было бы сделать так, чтобы какой-то инструмент автоматически проверял код на предмет нарушения этого соглашения? Или вообще встроить эту проверку в компилятор. Так это работает с хаскелем: вместо того, чтобы создавать соглашение о том, что io-функции будем держать отдельно от чистых функций, мы явно отмечаем это, а компилятор проверяет. Это работает со всеми монадами и тайпклассами, не только с IO.
Я думал над этим, это спорный момент, нужно ли увеличивать когнитивную сложность для уменьшения вероятности ошибки?
Если увеличивать, то до какого предела?
Вот тебя от каких конкретно ошибок хаскель останавливал?
Ну это один из многих трейд-оффов. Как это перевести? Измерения выбора, компромисса, балансирования между несовместимыми качествами.
Есть когнитивная сложность и вероятность ошибки, или скорость создания прототипа, скорость исполнения и когнитивная сложность ручного управления памятью, меньшая нагрузка на сборщик мусора или сложность результирующего многопоточного кода и т.д.
> Вот тебя от каких конкретно ошибок хаскель останавливал?
Если хаскель успешно предотвратил ошибку, то наверное я могу только гадать о том, какая могла быть ошибка.
Например, я написал небольшую программку, которая с помощью STM демонстрирует проблему "трапезничающих философов". Может быть без STM я написал бы что-то сложное, запутанное и потом пришлось бы долго искать ошибку.
>поинт с чистотой хаскеля мне не понятен
с хаскелем "грязную" функцию можно создать где угодно - хоть в глубинах программы. это потребует несколько другого синтаксиса на пути от IO до main, но в остальном никаких ограничений. а можешь создать на эндпоинте и использовать няшную do-нотацию
main = do
a <- readln
b <- readln
print a+b
> это потребует несколько другого синтаксиса на пути от IO до main
Это ты о чём? Обычный синтаксис, функции, вызывающие другие функции.
если в функциях только вызовы - да, никаких отличий. но
f = readln
f2 = f+1
работать не будет, понадобится написать например
f2 = (+1)<$>f
А, теперь понял. Хотя это ведь тоже функции, вызывающие другие функции, только синтаксис вызовов немного другой, да.
>Хотя это ведь тоже функции, вызывающие другие функции
ага. IO выступает как обёртка над значением, и перед использованием её нужно развернуть тем или иным способом
bump
на самом деле ты хуйню написал. все проще - кодерки хорошо понимают когда они спускают силы в унитаз, а когда делают то что можно реюзать. консенсус простой - решение должно менее всего ебать мозги, меньше дрочить внимание.
выбор - сделать чистую функцию которая принимает обьект и отдает обьект известной структуры, с пруфами ее работы и тд, и забыть вообще о том какой у нее код внутри, и пытаться чтото подкостылись вечно в связке говнобд и говнопыха
в любом языке так же ковыряются. в хаскеле так же много говна - ублюдочный прелюд, ублюдочные рекорды.
про рубанки хз какие ты там аналогии собрался. ручки там идентичные. черный просто меньше, боковина не полированая, и у него нет стружколома и регулировочного винта. и мы конечно знаем что кто угодно выберет рубанок со стружколомом и регулировкой и почему. и у тебя не стоит выбор обычно аля ой, на дядю можно и поебаться кривым рубанком, как в кодочмырении
ну а зиг конечно ублюдочная скриптопараша
>ублюдочный прелюд, ублюдочные рекорды
так и что со всем этим не так?
bump
Хаскель и теория категорий расширяют понимание типов и программирования в целом. Они полезны для любого разраба просто как бекграунд, как часть Computer Science.
Кроме того, никто тебе не запрещает вкатиться в Скалу/F#/Хаскель профессионально. Вакансий не очень много, но они есть, языки используются в своих нишах. Помни, что тебе не нужно 1000 вакансий, тебе нужна 1-2 компании, которые занимаются твоей нишей. Это касается всех нишевых языков.
Если говорить в целом, то за функциональщиной будущее, джавы и шарпы всякие это детский сад и лопатки в песочнице.
>Они полезны для любого разраба просто как бекграунд, как часть Computer Science.
двощую этого. в чём фича всяких форычей и иже с ними разобрался только после хаскеля
> У джавы охуенно удобные иде на любой вкус
У джавы их ровно 1. Idea. Причем такой себе IDE. Удобный, если придрочиться, но это надо еще уметь придрочиться.
>собрать мавеном проект проще, чем сходить посрать
Для этого надо очень неплохо разбираться в мавене. Причем, чем лучше ты в нём разбираешься, тем более понимаешь, что он нихуя не простой.
> сделать чистую функцию которая принимает обьект и отдает обьект известной структуры, с пруфами
Да нет, дело вообще не в пруфах. Ну какие там пруфы, мол, если нет монады IO, значит нет IO? Она там везде есть. Дело в общей культуре кодинга. Хаскельёбы задают в этой культуре абсолют, поэтому кодеркам этот язык и нравится. Чисто язык ради того, чтобы подрочить на конечные решения.
> за функциональщиной будущее
Под большим вопросом, на самом деле.
bump
> за функциональщиной будущее
хехе, да помню весь этот кураж конца десятых начала нулевых, тогда еще верили в светлое функциональное будущее, но что-то не пошло
даже согласен с этим набросом
https://thedeemon.livejournal.com/101181.html
Все основные языки впитали в себя (или взросли на) ФП, по крайней мере полезные его части (первоклассные функции, ФВП, лямбды, замыкания, иммутабельность, произведение типов, копроизведение типов, экспонента, применение этого всего в первую очередь в виде map/filter/reduce), а бесполезные части оказались выкинуты на задворки, в уголке музея эзотерики на них всегда можно будет полюбоваться, но в основном только там. Думаете, другая часть ФП еще себя покажет, и расширение линз Кана вправо-вверх вдоль контравариантного функтора еще выстрелит? Не будет этого, dead end.
как-то все так и получилось
хотя, если честно, даже в далеком 2009 было понятно, что если ФП и станет популярным, то все высокое ФП останется за бортом, так как оно интересно лишь задротам, а обычным работягам и их манагерам оно будет НИПАНЯТНА И НИНУЖНА
к тому же, все эти крутые абстракции полезны онли в больших проектах и сложных предметных областях, таких проектов в принципе мало и представляют они из себя, как правило, ебический бардак, который, наоборот, хотят свести к чему-то понятному среднему индусу, а попытка запихнуть туда тру-ФП только повысит уровень пиздеца и непонимания, и поэтому никем не приветствуется
применять же х-ль в стартапах и мвп это явный овкркил, плюс любой хипстер на питоне/рельсе обставит по скорости разработки очкарика, по пол дня ковыряющего в носу и выдумывающего очередной гомозигаморфизм для своей крудо-хомпаги,
вот и оказалось что этот и подобные ему ЯП так и остались языком для души для задротов как и все высокое ФП
в теории, его было бы идеально использовать для крупных, заранее хорошо спланированных проектов, но из моего опыта количество оных стремиться к нулю
хехе, да помню весь этот кураж конца десятых начала нулевых, тогда еще верили в светлое функциональное будущее, но что-то не пошло
даже согласен с этим набросом
https://thedeemon.livejournal.com/101181.html
Все основные языки впитали в себя (или взросли на) ФП, по крайней мере полезные его части (первоклассные функции, ФВП, лямбды, замыкания, иммутабельность, произведение типов, копроизведение типов, экспонента, применение этого всего в первую очередь в виде map/filter/reduce), а бесполезные части оказались выкинуты на задворки, в уголке музея эзотерики на них всегда можно будет полюбоваться, но в основном только там. Думаете, другая часть ФП еще себя покажет, и расширение линз Кана вправо-вверх вдоль контравариантного функтора еще выстрелит? Не будет этого, dead end.
как-то все так и получилось
хотя, если честно, даже в далеком 2009 было понятно, что если ФП и станет популярным, то все высокое ФП останется за бортом, так как оно интересно лишь задротам, а обычным работягам и их манагерам оно будет НИПАНЯТНА И НИНУЖНА
к тому же, все эти крутые абстракции полезны онли в больших проектах и сложных предметных областях, таких проектов в принципе мало и представляют они из себя, как правило, ебический бардак, который, наоборот, хотят свести к чему-то понятному среднему индусу, а попытка запихнуть туда тру-ФП только повысит уровень пиздеца и непонимания, и поэтому никем не приветствуется
применять же х-ль в стартапах и мвп это явный овкркил, плюс любой хипстер на питоне/рельсе обставит по скорости разработки очкарика, по пол дня ковыряющего в носу и выдумывающего очередной гомозигаморфизм для своей крудо-хомпаги,
вот и оказалось что этот и подобные ему ЯП так и остались языком для души для задротов как и все высокое ФП
в теории, его было бы идеально использовать для крупных, заранее хорошо спланированных проектов, но из моего опыта количество оных стремиться к нулю
хрюкнул с диванного знатока programming language theory
> При этом о хаскеле говорят везде, где говорят о фп
В Scala-коммьюнити есть подкоммьюнити программистов, которые любят pure FP. Многие из них знают Хаскель и вдохновляются им когда создают скальные либы. На Скале работа есть. Какие практические профиты от pure FP и почему это удобнее чем императивный подход могу объяснить. Не апеллируя к эстетике, а чисто прагматично.
объясняй
Очевидно, в этом треде мы не говорим об интернет-магазинах и стартапах, для которых достаточно на рельсе круд запилить. Да, это большинство рынка - но мы говорим именно о нишевых, сложных, ключевых системах - безопасность, медицина, банкинг, а так же сложная обработка данных на больших масштабах и распараллеливание.
Я поэтому и говорю про детские лопатки - просто мы только в начале увеличения сложности систем, поэтому кажется что ФП ни нужно и достаточно на Джаве наклепать фабрик абстрактных. Вспомнишь мои слова через 30+ лет, когда все будет обпутано мгновенными сетями и нужно будет синхронизировать все IoT системы, умные города и т.д. Теоркат сейчас самый тренд в матане, к тому времени как раз это станет стандартом больших систем.
Уменьшается когнитивная нагрузка на программистов, соответственно, уменьшается количество багов в разы.
1. Программисту намного легче работать с чистыми функциями, потому что их намного легче понять. Код написанный на чистых функциях легче тестировать и безопасней рефакторить. В целом можно вот это почитать https://zio.dev/overview/overview_background
2. В промышленном программировании очень много разных абстракций используется, часто нужно изобретать свои абстракции, свои DSLи и д. Скала для этого очень удобна.
3. ФП хорошо для написания асинхронных приложений (декларативно описываем что в каком порядке вычисляется с помощью монад). По сути альтернатив ФП в этой области нет. Ну разве что на колбэках все писать. Но ты охуеешь код с колбэками поддерживать.
4. В concurrent applications у тебя нет race conditions т к все данные иммутабельны. на самом деле есть, потому что в бд-то че-то надо писать и все равно придется использовать какие-то локи, например, состояние в бд локать, но это другая история
5. Stream processing: пишем или читаем кафку, допустим. Да и вообще много чего можно смоделировать как стрим. Например запросы к АПИ. В итоге можно пользоваться готовыми полезностями стриминговых библиотек типа backpressure, использовать готовые методы для throttling ит д
6. Скала и ХАскель типизированные языки, соответственно компилятор очень много багов отлавливает. Самый банальный пример: В скале никогда NullPointerException не словишь в отличие от джавы.
Это то что в голову пришло. В целом pure FP это про удобство. Конечно, можно все и на джаве нахуярить. Но разработка будет дольше и багов больше будет, ибо неудобно.
фпшизик спок, полторы вакансии на которые нужен PhD в теоркате не делают фп привлекательным
https://www.youtube.com/watch?v=T5oB8PZQNvY
Маняфантазии борщехлебов. На практике это не работает.
Классический пример с квиксортом на хаскеле: двухстрочная красивая реализация адово медленная, быстрая реализация выглядит страшнее чем на С.
Оптимизаторы как обычно про скорость пука и наносекунды разницы, когда это не имеет никакого значения в современных системах, где 80% от времени занимает запрос в БД и нетворкинг
Современные системы бывают разные. Но доля правды есть, если ты занимаешься облачными крудами, то тебе и функциональщина сойдет.
>Ррряя полторы вакансии рррряяяя фпшизики кококо борщи
Мне в неделю-то больше предложений в линкедине присылают, лол. Старайся лучше, антифпшизик.
>верит спаму в линкедине
Эти борщехлебы такие забавные
>Врети вакансии не вакансии рряя
Ничего другого от шизика и не ожидалось.
>да тащемта ничего сложного просто берешь и вкатываешься в фп
Бэкграунд свой опиши, а то выяснится, что ты яндексоид-олимпиадник с 12 лет программируешь во сне советуешь птушникам куда вкатываться.
Ну все так и есть, берешь и вкатываешься. Учишь сам основы, проходишь собеседование, доучиваешься на месте. У нас многие перешли с жавы, некоторые с котлина или шарпа.
>Бекграунд
3 класса церковно-приходской
>работа
Справедливости ради на F# я не знаю ни одной программы, а на Haskell одну Hasura всё-таки знаю
В линкедине как раз работа легко и ищется, если у тебя профиль нормальный
Работаю сейчас на Расте, было 2 вакансии открыты еще, уже нашли людей очевидно европа, не раисся, твои оправдания?
На нишевых языках куча работы - просто почему-то ищущие ее считают что им обязательно нужно 100 вакансий и 10000 конкуренции, иначе это не считается. Тебе не нужно 100 вакансий, тебе нужна 1-2 компании, который ипользуют этот язык. Если ты нормальный инженер, тебя возьмут спокойно.
>1-2 компании
Которые зная, что кроме них борщам идти некуда, начнут хуеть и ставить зп ниже рынка, ебать требованиями и заниматься прочими непотребствами.
Снгшная логика. В Европе на практике наоборот, зная что нишевых программистов мало, компании платят нормальные зп. Сам получаю 3300 евро за Раст, хотя вообще не расчитывал, благо не протупил и сказал большую сумму. Для компаний же тупо выгодней платить лишнюю тысячу больше, зато прогер будет комфортно работать пару лет.
Ну и кроме того, обычно те, кто знают нишевые языки, спокойно могут хуярить круды на языках попроще, борщи это те кто вообще нигде работать не могут.
>Европа
>Нормальная зп
>3300 евро
Ты про Украину чтоли?
Это для сеньера даже в Москве нижняя планка.
В видосе, который ты приложил, приводятся примеры обычного асинхронного кода на фьючах, который может быть в самом обычном энтерпрайзе. Я такой писал на самой первой работе на скале, мои самые первые задачи на ней были по поддержанию вебсервера на Play. Не космической ракеты, а обычного, блять, вебсервера.
> Маняфантазии борщехлебов. На практике это не работает.
> Классический пример с квиксортом на хаскеле: двухстрочная красивая реализация адово медленная, быстрая реализация выглядит страшнее чем на С.
Шиз, спок, на практике 99% программистов не пишут квиксорт после окончания универа и не оптимизируют низкоуровневую ебалу всякую. Если тебе надо написать свой nginx или драйвера какие-нибудь, ты же не будешь писать на JS писать, правильно? Но из этого не следует, что JS не нужен на рынке труда. Очевидно есть задачи, для которых ФП подходит и не подходит. ФП подходит везде кроме низкоуровневой ебалы, где каждую наносекунду надо оптимизировать.
Как правильно написал
> в современных системах 80% от времени занимает запрос в БД и нетворкинг
Но между прочим thread usage тоже нихуево оптимизируется если писать в асинхронном стиле и на практике получается, что сервисы на скале выдают больше rps чем сервисы на джаве. Такие дела. А на джаве ты охуеешь в асинхронном стиле писать, у тебя глаза вытекут.
Изучать различные парадигмы и подходы - это отличный способ повысить свой хардскилл
А потом обмякаешь на собесе, когда спросят как раскладывается в JVM-байткод этот листинг или как устроены коллекции в STL, ведь ты пробовал различные хеллоуворлды.
> Если говорить в целом, то за функциональщиной будущее, джавы и шарпы всякие это детский сад и лопатки в песочнице.
Да уже вполне настоящее.
У фронтеров везде реакт обмазанный тайпскриптом.
Даже у джаверов стримы появились.
>Эти проекции
А какой у хаскелла тулинг вообще? Кабал не советуют, hstack?
Тут дело в том, малыш, что на х-ле можно написать как быстрый квиксорт причем несколькими способами, так и короткий и понятный, но не оптимальный, и программист может сам решить какой ему использовать в зависимости от текущих требований. А на императивном говнище можно писать только процедурные портянки и никак иначе.
В общем случае правило такое: понятный код лучше, чем быстрый, если нет каких-то ощутимых просадок. И вот когда они появляются, то берется профайлер и переписывается 5% критического кода, при этом остальная кодовая база остается чистой и понятной.
>программист может сам решить какой ему использовать
Байтоебы сэр.
На крестах обычно в стл записано несколько алгоритмов в сорт, и библиотека сама решает какой более выгодный в данном случае.
Нихуясе подмена понятий, квиксорт на хаскелле сосал пушо раскладывался в O(N^2), а не потому что на сишке микрооптимизации, так что воевать с байтоебами тебе лучше продолжать в своих влажных фантазиях.
>понятный лучше, чем быстрый
Хохотнул с неосилятора, может для тебя ещё и написать красно-черное дерево у доски трудно?
Работаешь ты тоже один, долбоеб?
Речь о том, что ничего не мешает на х-ле написать императивный квиксорт если нужно. Вопрос только зачем.
Это у тебя laba3.cpp могут не принять, если НИАПТИМАЛЬНА, а в реальном мире за ненужную оптимизацию в ущерб читаемости на пулл реквест повесят changes required или вообще закроют и правильно сделают.
Быстрый код не значит байтоебские оптимизации.
Любой код подразумевает, что ты примерно понимаешь что происходит под капотом, начиная с какая сложность у метода в этой коллекции до в какой SQL развернет твою портянку ORM, чтобы не написать такого, что лишний раз грузит систему, кроме каких-то одноразовых вещей, которые редко используются.
Соответственно мне не ясно о какой "читаемости" идет речь. При необходимости ты по идее должен понимать что там до тебя писали, если технологии с твоим стеком совпадают или хотя бы пнуть техлида, чтобы он устроил ревью, если там совсем портянка.
Это идеальная ситуация конечно в ИП у Ашота может как-то и по-другому.
Как сказать дохуя но нихуя по теме:
Очевидно, что даже без квантовых компьютеров, будущее за функциональщиной. Подожди еще лет 10-20.
> ФП хорошо для написания асинхронных приложений (декларативно описываем что в каком порядке вычисляется с помощью монад). По сути альтернатив ФП в этой области нет. Ну разве что на колбэках все писать. Но ты охуеешь код с колбэками поддерживать.
Во всех нормальных языках уже давно есть async/await
> В concurrent applications у тебя нет race conditions т к все данные иммутабельны.
Не поверишь, иммутабельные коллекции можно написать на любом языке. В шарпе они вроде как даже в стандартной либе есть.
> Stream processing: пишем или читаем кафку, допустим. Да и вообще много чего можно смоделировать как стрим.
Согласен, прикольная штука, ебался с ней в акке на шарпах.
Жаль что в стандартной либе уродливые императивные стримы как в джаве. Но хоть ленивые и даже асинхронные списки через енумерабл есть, уже не так плохо.
> Скала и ХАскель типизированные языки, соответственно компилятор очень много багов отлавливает. Самый банальный пример: В скале никогда NullPointerException не словишь в отличие от джавы.
В котлине и шарпе уже давно есть наллабл типы, с которыми будет ошибка компиляции если не проверишь на налл. Та даже в джаве есть Optional<T> .
Но да, хз как в скале, но в хаскеле точно никогда не словишь налл ошибку, так как наллов в хаскеле как концепта нет.
Кароче хаскель так и остается языком для борщехлебов, просто полезные фп фичи тырят другие языки.
> Во всех нормальных языках уже давно есть async/await
Хуй знает, по-моему максимально неудобная хуйня по сравнению с монадами и for comprehensions. Прикол монад в том, что это общая концепция, под которую подходят другие концепции. Кроме фьюч монадами являются List и Option например, и с ними можно через for comprehensions работать.
> Та даже в джаве есть Optional<T>
Да по сути теоретически можно в pure FP стиле на джаве писать. И монады можно писать на джаве. Проблема в том, что так как синтаксис джавы изначально под ФП не заточен, у тебя будет дохуя бойлерплейта и код написанный в pure FP стиле на джаве будет выглядеть вырвиглазно.
> Кароче хаскель так и остается языком для борщехлебов
К сожалению не знаю Хаскель, но на Скале работа есть и достаточно, сам работаю и пишу в pure FP стиле, брат жив, зависимость есть.
Не вижу смысла что-то доказывать местным шизикам, у них все на чем работы меньше, чем на жаваскрипте, объявляется борщами.
А жаваскрипт в pure FP можно писать?
> Если первые это избыточная абстракция
В каком смысле избыточная? Конечно, если у тебя в языке есть что-то, что позволяет имитировать тайплассы (например, скалоёбы их эмулируют имплицитами) то в некотором смысле избыточная, ведь можно сделоть. Но тайпклассы на имплицитах - это же вообще пиздец. Я бы скорее имплициты выпилилил, но тайпклассы оставил (кстати, в Хаскелле были имплициты, вроде до сих пор есть, но ими один хуй никто не пользуется, я вот даже не знаю, есть они там до сих пор или нет, лол).
Тайпклассы - как раз очень удачная абстракция. Они покрывают почти все задачи (вообще, не могу придумать, когда надо было бы въебать вместо тайпласса имплицит), плюс, хоть и формально тайпкласс можно эмулировать передачей словаря функций, но поддержка его на уровне языка открывает возможности для оптимизации. Т.е словари функций - это непрямые вызовы в рантайме, а тайпклассы резолвятся на этапе компиляции, т.е. можно инлайнить код.
Вот пример: микробенчмарк либы, которая эмулирует сишные структуры. В одном случае я просчитал все смещения в памяти вручную (вбил цифры из какого места в памяти читать). Во втором - использовал семейства типов для рассчета смещений. Т.е. в случае 1 у меня что-то вроде `i6 <- readOffPtr ptr 6`, где 6 - это смещение в машинных словах (я для бенча упростил задачу), во втором: `i6 <- readOffStruct @"i6" ptr` где "i6" берётся из описания структуры, которое я задаю примерно как: `type MyStruct = '[ "i0" := .., .., "i6" := Word64, ...]` (т.е. перечисляю список полей в структуре, каждое может быть своего размера, смещение вычисляется автоматически, а если поля нет, то будет ошибка компиляции).
Это не тайплассы, я там немного более продвинутые технологии заюзал. Но и на тайпклассах это сделать можно. В итоге, я сделал внутри языка подобие сишных структур. Теперь посмотри на бенч. Т.к. всё вычисляется на этапе конпеляции, оверхеда нет вообще, работает так, как если бы я вручную все смещения указывал. Вот на каком еще языке подобное сделать возможно? Это же и есть zero cost abstraction (когда ты себе для удобства делаешь абстракцию, но она ничего не стоит в рантайме). Такое возможно, только если у тебя изначально нужный механизм в языке есть, либо можно добиться каким-то кодогенератором, что не удобно, либо продвинутой системой типов, как в Хаскелле.
>Console.Log в F# это 'a -> unit, в хаскеле это IO монада
>Чтение и запись в хаскеле это тоже свои собственные монады, в F# это unit -> 'a
А, теперь я понял. Ты просто начинающий программист, который еще не был выебан в рот и в жопу байтоёством и императивным программированием. И который пока не понимает, что никакого "функционального" программирования на самом деле не существует. Есть только императивное программирование. Вся суть программирования в том, что мы хотим от компьютера, чтобы он последовательно выполнял какие-то вычисления, больше он ни за чем не нужен.
Так вот, Хаскель - это и есть максимально императивный язык. И вся его "чистота" - это, по сути, возможность максимально точно описывать его императивные действия. Если во всяких полуфункциональных говнах у тебя g :: a -> unit (т.е. вызов g = неизвестно что), то в Хаскелле g :: a -> f unit, где f описывает сайдэффеты.
Короче, научись писать императивные программы чтоле.
> Но тайпклассы на имплицитах - это же вообще пиздец. Я бы скорее имплициты выпилилил, но тайпклассы оставил
В скале 3 так и будет. Сейчас уже сделали отдельную синтаксическую конструкцию для тайпклассов. Имплиситы удаляют постепенно, Одерский обещает полный отказ от имплиситов к версии 3.2 или 3.3. Сразу отказаться нельзя, потому что слишком много либ в экосистеме используют имплиситы.
> ублюдочный прелюд
Нормальный для вкатывальщиков. Надо держать баланс между сложностью языка и полиморфзмом. И, главное, он не мешает. По крайней мере, `NoImplicitPrelude` мне применять почти не доводилось. Значит, не так уж и плохо сделан.
> ублюдочные рекорды
Нормальные. Для простых задач их достаточно, для более сложных - включаешь всякие record puns, для еще более сложных - field selector polymorphism. Для совсем конченных ублюдков есть линзы и haskell vinyl.
Но, что характерно, этого почти никогда не нужно делать. В большинстве случаев родные рекорды канают с включением puns/wildcards. В самом крайнем случае - microlens. Когда полноценные линзы подключать? Такой необходимости вообще почти не бывает.
Lens и vinyl реально очень сложные. Но и в других языках аналоги не проще, в Скале оптика тоже дохуя сложная. Но 99% программ на Хаскелле как-то пишутся и без продвинутой оптики.
По IDE.
1. VS-code c плагинонм. Он, конечно, хуёвее, чем Visual Studio в плане user experience для начинающих, но это ещё большой вопрос, что легче настроить из коробки, VS-code + плагин для Хаскеля, или Idea, или, не дай Б-г вообще Eclipse.
Теперь именно по тулингу.
2. Haskell Stack. Аналогов нет вообще. В любой Джаве/Шарпе/С++ ты ебёшся с непонятно откуда скаченными и непонятно как с собой взаимодействующими библиотеками. В Стеке ты просто используешь билд-план, который гарантированно работает для всех библиотек. Плюс плюшки для начинающих, в виде создания шаблонного проекта.
Теперь по мелочам.
3. Сам ghc позволяет компилировать с -with-rtsopts, дампить код в ассемблер, собирать метрики. ghci - полноценный интерпретарор, плюс, возможность ставить брейкпоинты из командной строки, загружать любые модули, дергать любые функции для быстрой проверки не компилируя весь проект.
4. Criterion. Это вообще няшечка для микробенчмарков. И им очень легко пользоваться.
5. Weigh. Классная штука для отслеживания аллокаций. Ну и enableAllocationLimit прямо в самом языке, где еще такое есть?
6. Hspec - всё для юнит-тестов.
7. Там же QuickCheck для рандомных тестов и генерации рандомных данных. Гораздо лучше его портов на F# и Scala.
8. smallcheck/tasty - нишевый инструмент для тестирования на полном объёме данных. Сам им не пользовался, но в Хаскелле он есть.
9. Всякие инструменты для установки cost centre сборки и визуализации продвинутой статистики. Опять же, встроено в сам конпелятор https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/profiling.html
>В скале 3 так и будет.
Ну так оно и понятно, что правильная Scala - это Haskell. Я как-бы сам скалист, мне есть с чем сравнивать. Просто у скалкоёбов яиц не хватает сразу на топовую технологию перекатиться, вот и страдают.
Кстати, у GHC релизные циклы стабильно раз в полгода, как течки у самок. А Scala 3, я вообще какое-то время думал, что её не будет. Потому что проще всё нахуй переписать, чем пофиксить этого инвалида.
Вот в этом и разница между языками. Один стабильно и гладко прогрессирует, потому что там изначально подумали о дизайне, другой пытаются натянуть как сову на глобус, потому что думали, что и так сойдёт для начала.
> правильная Scala - это Haskell
Почему тогда Frege (хаскель на жвм) не взлетел? Почему люди пишут в pure fp стиле на zio и котах, а не на Frege?
> Просто у скалкоёбов яиц не хватает сразу на топовую технологию перекатиться, вот и страдают
Ну продай мне хаскель. Почему я должен с zio и котов переходить на хаскель? Я и так получаю все профиты pure fp подхода. Бойлерплейта наверное меньше будет на хаскеле, синтаксис красивее, но бля, я уже не первый год программирую и смотрю на код прагматично а не с точки зрения красивости синтаксиса.
> правильная Scala - это Haskell
С этим тезисом я даже не спорю, если Хаскель на jvm взлетит и работа появится, оно может и правлиьно будет. Я просто пытаюсь понять в текущих реалиях что даст переход на хаскель.
>В любой Джаве/Шарпе/С++ ты ебёшся с непонятно откуда скаченными и непонятно как с собой взаимодействующими библиотеками
В жабе есть mvn/gradle, в решетках NuGet
бумп
А что бумп, уже пояснили все. Идите дальше играйтесь в ООП в песочнице лопатками
>Вся история его дизайна - это как сделать "правильно", с минимумом "костылей"
Напиши на нем квиксорт без костылей.
Знаешь730, что главное в квиксорте кстать? O(n log n)
>злобные звуки борщехлебания
Чтобы выёбываться потом.
Но вообще, если у тебя возникают такие вопросы, ты ещё недостаточно их учил, просто по вершкам посмотрел, прошёл туториал и ничего не понял.
То что ИП Иванов не хочет тебе платить за хаскель, ещё не значит что сам по себе хаскель бесполезное говно. Это скорее в твоих жизненных условиях хаскель для тебя бесполезное говно. Возможно в этом даже есть здравый смысл и к нему стоит прислушаться.
Назови мне что-нибудь годное на хаскеле.
Я вот в основном С и С++ вижу в по-настоящему серьезных вещах.
Чел, ну ты пообщайся с ребятами из Металамп, они тебе горы приложух в пример приведут.
>Металамп
Литературно кто?
>какие-то мои друганчики-ребятки местечковые
>web-приложения и сайты на заказ
Серьезный базар! Веб-приложения-то и сайты на заказ.
А я поисковые движки, распознавание речи, операционки и машин лернинги всякие имел в виду, так, хуйня, признаю свою ничтожность.
Pandoc, PostgREST, XMonad
>Pandoc
Параша нишевая
>PostgREST
Враппер ебаный. На чем написан сам postgres?
>XMonad
Хуйня для красноглазых уебков.
Ты бы еще вьеб-фреймворк для блогов какой-нибудь притащил, лол.
Старайся лучше.
Дебич, все "годное" по твоему мнению и низкоуровневое не будут писать на Хаскеле. Хаскель используют когда нужна либо надежность и матан проверяемость кода (медицина, крипта), либо для преобразования сложных данных. Язык не для байтоебли и не для системного программирование, на нем нет смысла писать базы данных или игровые движки. В этом плане Хаскель ближе к Руби/Питону, на нем (при знании языка и матчасти) можно быстро моделировать функциональные данные, при этом имея типизированный скалируемый язык, а не динамикодрисню.
>Дебич
Какой визглявый борщехлебок, лол.
>Хаскель ближе к Руби/Питону
Вот ты и проговорился, соевый говнарик.
Ну давай, приведи тогда примеры использования хуйскиля в медицине.
>А я поисковые движки, распознавание речи, операционки и машин лернинги всякие имел в виду, так, хуйня, признаю свою ничтожность.
Ну в плане зарплат ты всё правильно сказал, хотя и пытался в иронию. Из всего C/C++ по зарплатам только алготрейдинг нормально оплачивается.
так и почему мы опять тратим время на такие бесполезные вещи, как работа? кого это вообще волнует? если язык охуенный, то количество вакансий - третьестепенный критерий
так и почему мы опять тратим время на такие бесполезные вещи, как еда? кого это вообще волнует? если бургер с мусорки у мака такой охуенный, то количество еды- третьестепенный критерий
работаешь четверть ставки на скучном языке, остальное время кайфуешь на приятном - профит
Берешь MVector + ST и погнали. В чём проблема-то?
работаешь на императивке -> хочешь расширить кругозор -> выбираешь максимально другой язык -> велком ту хаскель
в хаскеле масса кошерных фич в стандартной библиотеке
1) выведение типов
2) частичное применение функций - (+1) - обычная функция от 1 параметра
3) в тайпклассах (интерфейсах) достаточно реализовать только часть функций, для остальных будут реализации по умолчанию - море функций нахаляву
4) чрезвычайно простой и удобный полиморфизм без наследования
5) удобное сравнение с шаблоном. работает для тьюплов, списков, полиморфных и составных типов
6) при создании типа данных конструктор с параметрами создаётся автоматически, по запросу создаются функции toString, fromString, >, < , ==, minBoundary и несколько других
7) полная чистота - параллелить программы очень легко
8) огромные инты в стандартной библиотеке позволяют не переживать о переполнении
9) бесконечные списки и деревья - ведь зачем вообще задавать заранее количество элементов
10) ленивость - позволяет разносить построение дерева/списка/контейнера и передвижение по нему произвольно далеко в программе без потерь производительности
11) eta reduction - вместо f a b = map (+a) b можно написать f a = map.(+a)
12) эффективная композиция функций позволяет сократить код ещё сильнее
f a = map (+a) == f a = map.(+) a == f = map.(+)
13) скобки сведены к минимуму и используются только по необходимости
14) монады. монада списка позволяет удобно перебирать комбинации элементов, монада maybe - комбинировать несколько действий, которые могут провалиться и т.д.
15) sequenceA - меняющая местами 2 монады функция с морем применений. есть контейнер функций - получаем функцию, возвращающую контейнер. контейнер maybe -> maybe контейнер и т.д.(где контейнер это список, дерево, тьюпл, maybe и прочие)
16) подход с использование arrow позволяет на ходу менять тип возвращаемого из глубокого стека вызовов значения, и вся работа с возвращаемым значением адаптируется под новый тип автоматически вплоть до указанного пользователем момента
11,12 - точно валидный код?
в 11 очепятка
fd a= map (+a)
вместо
f a = map.(+a)
в 12 я поленился написать скобки в
f a = map.(+) a
надо
f a = (map.(+)) a
остальное вроде норм
> полная чистота - параллелить программы очень легко
очередной постит мантры с хеллоуворлдами
в чём я не прав?
Сколько по-настоящему серьёзных вещей ты написал за жизнь? Почему ты решил что это про тебя? Не то чтобы это невозможно стать сишником, но в ОП-посте ты говоришь что ты жс макака. Да и пишут серьёзные вещи не в одиночку, тысячами человек, на зарплате в какой-нибудь корпорации. Очевидно что это корпорация выбрала язык по каким-то своим соображениям экономии или вынужденности, о которых и ты и я имеем мало представления. Конечно в 99% языков не будет никакого киллер аппа, банально некому за это заплатить чтобы во всех языках всё было. Если ты к этому клонишь, то тут я полностью согласен, по параметру бабло от корпораций хаскель посасывает, пусть даже его разработку спонсирует сам майкрософт.
>хаскель
>понятный код
/0
ФП код намного легче читать и воспринимать когда ты перешел через кривую обучения.
То есть вы просто хипстеры, которые намеренно усложняют себе жизнь.
Так ведь это компромис же. Определенные ограничения в коде и специфический подход к его написанию дают свои "недостатки" если смотреть со стороны обычного ООП работяги, но и дают свои преимущества для толковых ребят. ФП нужно не везде, но спрашивать "зачем нужны эти ЯП" может только совсем уже макака.
Более того, я лично считаю что ФП и языки вроде Хаскеля полезны сами по себе, как часть CS и инженерного мышления в целом. Тут в треде уже писали, я абсолютно согласен - изучая ФП и вещи вроде теории категорий, ты расширяешь свой кругозор как программист. Ты становишься сильнее в моделировании данных, алгоритмов работы программ, в том числе понимаешь подноготную многих ООП паттернов, которые зачастую являются лишь попыткой организовать с говна и палок то, что в ФП подкреплено матаном.
Например, я вкатился в Раст профессионально, и бекграунд в ФП внезапно очень пригодился, ведь Раст будучи низкоуровневым и быстрым языком на уровне плюсов, работает с функциональным абстракциями. Там есть трейты, Option/Result которые являются на самом деле монадами и любой ФП господин в момент с улыбой узнает map и and_then функции на этих типах, итераторы в конце концов.
мимо Rust господин на зарплате
Чтот последний абзац про JavaScript и PHP не убеждает. Были бы эти языки так популярны еслиб их умники превратили в свой Хаскелл с самого начала?
Может они были ближе к народу, от народа, и для народа?
