Чи є якісь недоліки або проблеми з Haskell?

Я дивлюся на занурення в Хаскелл для мого наступного (відносно тривіального) особистого проекту. Причини, з якими я борюся з Haskell,:

1. Введіть мою голову в чисто функціональну мову
2. Швидкість. Хоча я впевнений, що це можна стверджувати, профілюючи, що я бачив нігті Haskell близькі до C ++ (і, здається, зовсім трохи швидше, ніж Ерланг).
3. Швидкість. Веб-сервер Warp, здається, з розуму швидкий порівняно з практично всім іншим .

Отже, з огляду на це, я шукаю недоліки або проблеми, які виникають разом з Haskell. В Інтернеті є величезна кількість інформації про те, чому Haskell - хороша річ, але я не знайшов багатьох тем про її потворну сторону (окрім схоплень про її синтаксис, про які я зовсім не переймаюся).

Прикладом того, що я шукаю, може бути, як GIL Python. Щось, що не замахнулося на голову, поки я насправді не почав дивитися на використання одночасності в середовищі CPython.

Я можу придумати кілька недоліків:

• Через природу мови та її міцні корені в академічному світі громада дуже налаштована на математику; якщо ви прагматична людина, це часом може бути непосильним, і якщо ви не говорите на жаргоні, вам буде складніше, ніж з багатьма іншими мовами.
• Хоча бібліотеки мають неймовірне багатство, документація часто є короткою.
• Ніжні підручники початкового рівня мало, і їх важко знайти, тому початкова крива навчання досить крута.
• Кілька мовних особливостей непотрібно незграбні; помітний приклад - те, як синтаксис запису не вводить область іменування, тому немає можливості мати одне і те ж ім’я поля запису у двох різних типах в одному просторі імен модуля.
• Хаскелл за замовчуванням лінивий, і хоча це часто чудова річ, він може іноді вкусити вас неприємними способами. Наївне використання лінивої оцінки в нетривіальних ситуаціях може призвести до зайвих вузьких місць, і розуміння того, що відбувається під кришкою, не зовсім однозначне.
• Ледача оцінка (особливо в поєднанні з чистотою та агресивно оптимізуючим компілятором) також означає, що ви не можете легко міркувати про замовлення на виконання; насправді ви навіть не знаєте, чи певна частина коду насправді оцінюється в даній ситуації. Отже, налагодження коду Haskell вимагає іншого мислення, хоча б тому, що переходити до вашого коду є менш корисним і менш значущим.
• Через чистоту Haskell, ви не можете використовувати побічні ефекти, щоб виконувати такі дії, як I / O; для досягнення інтерактивності вам доведеться використовувати монашество та ледачу оцінку "зловживань", і вам доведеться перетягувати монадійний контекст куди завгодно, де ви можете зробити введення / виведення. (Це насправді багато в чому хороша особливість, але вона робить прагматичне кодування часом неможливим.)

Більшість недоліків Хаскелла (як і більшість позицій Хаскелла) походять з його двох визначальних характеристик: Це лінивий і чисто функціональний.

Якщо ледачий, важче міркувати про продуктивність. Особливо для людей, які не звикли до лінощів, але навіть досвідченим хаскеллерам важко зрозуміти, як лінь вплине на працездатність у певних випадках.

Лінь також означає, що важче створити точні орієнтири без використання таких бібліотек, як Критерій.

Бути суто функціональним - означає, що коли вам потрібно буде використовувати структури даних, що змінюються (у випадках, коли без них неможливо досягти бажаної продуктивності - хоча завдяки оптимізатору GHC, який відбувається не так часто, як ви думаєте), ви будете мати застряг у монаді IO (або ST), що робить код більш громіздким.

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

Я не фахівець з Haskell: я засвоїв ази, але, на жаль, у мене не було можливості зробити якийсь серйозний проект у Haskell (хотілося б, хоча мені дуже подобається ця мова).

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

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

Мені цікаво, як з такими структурами даних та операціями можна правильно керувати в Haskell, оскільки, наскільки мені відомо в Haskell, неможливо використовувати вищезазначене представлення / підхід. Деякі проблеми з графічними алгоритмами в Haskell коротко обговорені в цій статті

EDIT

Нещодавно я розмовляв з експертом з функціонального програмування, і він підтвердив, що ефективно використовувати певний алгоритм графіків може бути досить складним в Haskell: переміщення по вказівниках, як ви робите в C або C ++, може бути набагато швидшим.

Нижня сторона до Haskell полягає в тому, що вона відрізняється. Це більший крок від мов, про які частіше навчають чи говорять, тому буде більша крива навчання. Також менш популярна мова, яка може обмежити доступність допомоги, якщо ви застрягли. Це, правда, не є основними недоліками.

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

Отже, з огляду на це, я шукаю недоліки або проблеми, які виникають разом з Haskell

"Проблеми з Haskell", як правило, з'являються в певних областях. Haskell - чудова мова для програмування додатків, набагато приємніше писати, ніж просто все інше. Проблеми, як правило, виникають, коли ви намагаєтесь зробити щось, для чого не дуже хороша підтримка, наприклад:

• Перехресне складання. GHC може бути побудований як перехресний компілятор, але процес є досить задіяним.
• Вбудовані програми. Haskell має управління пам’яттю за допомогою сміттєзбірника, тому це не надто дивно.
• Швидкість. Haskell не такий швидкий, як Rust, хоча в більшості випадків він буде конкурувати досить добре. Це дуже залежить від домену програми - чисті обчислення добре оптимізуються, але щось подібне "прочитати файл у буфер і підрахувати кількість рядків" важче виразити в Haskell.