Czy są jakieś wady lub problemy z Haskell?

Patrzę na nurkowanie w Haskell dla mojego następnego (stosunkowo trywialnego) osobistego projektu. Powody, dla których walczę z Haskellem są:

1. Przejdź na język funkcjonalny
2. Prędkość. Chociaż jestem pewien, że można to argumentować, profilowanie, które widziałem, gwoździe Haskell blisko C ++ (i wydaje się być nieco szybsze niż Erlang).
3. Prędkość. Serwer internetowy Warp wydaje się być szalony szybki w porównaniu do praktycznie wszystkiego innego .

Biorąc to pod uwagę, szukam wad i problemów związanych z Haskellem. Sieć ma ogromną ilość informacji o tym, dlaczego Haskell jest dobrą rzeczą, ale nie znalazłem wielu tematów na temat jej brzydkiej strony (poza chwytami związanymi z jej składnią, o które w ogóle nie dbam).

Przykładem tego, czego szukam, może być GIL Pythona. Coś, co nie pochyliło się, dopóki naprawdę nie zacząłem używać współbieżności w środowisku CPython.

Kilka wad, o których mogę myśleć:

• Ze względu na naturę języka i jego silne korzenie w świecie akademickim społeczność jest bardzo matematyczna; jeśli jesteś pragmatyczną osobą, może to być czasami przytłaczające, a jeśli nie znasz żargonu, będziesz miał trudniejszy czas niż w przypadku wielu innych języków.
• Chociaż istnieje ogromne bogactwo bibliotek, dokumentacja jest często zwięzła.
• Delikatne samouczki dla początkujących są nieliczne i trudne do znalezienia, więc początkowa krzywa uczenia się jest dość stroma.
• Kilka funkcji językowych jest niepotrzebnie nieporadnych; wyraźnym przykładem jest to, jak składnia rekordu nie wprowadza zakresu nazewnictwa, więc nie ma sposobu, aby mieć tę samą nazwę pola rekordu w dwóch różnych typach w tej samej przestrzeni nazw modułów.
• Haskell domyślnie leniwie ocenia i chociaż jest to często świetna rzecz, czasami może cię ukąsić. Naiwne stosowanie leniwej oceny w nie trywialnych sytuacjach może prowadzić do niepotrzebnych wąskich gardeł wydajności, a zrozumienie tego, co dzieje się pod maską, nie jest proste.
• Leniwa ocena (szczególnie w połączeniu z czystością i agresywnie optymalizującym kompilatorem) oznacza również, że nie możesz łatwo uzasadnić kolejności wykonania; w rzeczywistości nie wiesz nawet, czy dany fragment kodu jest rzeczywiście oceniany w danej sytuacji. W związku z tym debugowanie kodu Haskell wymaga innego sposobu myślenia, choćby dlatego, że przechodzenie przez kod jest mniej przydatne i mniej znaczące.
• Ze względu na czystość Haskella nie można używać efektów ubocznych do robienia rzeczy takich jak I / O; musisz użyć leniwej oceny monady i „nadużycia”, aby osiągnąć interaktywność, i przeciągnij monadyczny kontekst wszędzie tam, gdzie chcesz zrobić operacje wejścia / wyjścia. (Jest to właściwie dobra cecha na wiele sposobów, ale czasami uniemożliwia pragmatyczne kodowanie).

Większość wad Haskell (jak również większość zalet Haskell) wynika z dwóch charakterystycznych cech: jest leniwy i czysto funkcjonalny.

Leniwość sprawia, że ​​trudniej jest uzasadnić wydajność. Zwłaszcza dla osób nieprzyzwyczajonych do lenistwa, ale nawet doświadczonym Haskellerom może być trudno dostrzec, jak lenistwo wpłynie na wydajność w niektórych przypadkach.

Lenistwo oznacza również, że trudniej jest tworzyć dokładne testy porównawcze bez korzystania z bibliotek takich jak Criterion.

Bycie czysto funkcjonalnym oznacza, że ​​za każdym razem, gdy potrzebujesz użyć zmiennych struktur danych (w przypadkach, w których nie można osiągnąć pożądanej wydajności bez nich - chociaż dzięki optymalizatorowi GHC, który nie zdarza się tak często, jak myślisz), będziesz utknął w monadzie IO (lub ST), co czyni kod bardziej kłopotliwym.

Ponieważ wymieniłeś prędkość jako jeden ze swoich celów, powinienem zauważyć, że często istnieją ogromne różnice w wydajności między ręcznie zoptymalizowanym kodem Haskell a kodem Haskell, który został napisany bez większego zastanowienia się nad wydajnością (bardziej niż w innych językach). A ręcznie zoptymalizowany kod Haskell jest często dość brzydki (choć przypuszczam, że dotyczy to również większości innych języków).

Nie jestem ekspertem od Haskell: nauczyłem się podstaw, ale niestety nie miałem okazji zrobić poważnego projektu w Haskell (chciałbym, bo bardzo lubię ten język).

Jednak z tego, co wiem i z dyskusji z kimś, kto pracował w dziedzinie dość bliskiej programowaniu funkcjonalnemu, Haskell może nie być najlepszym rozwiązaniem, jeśli chcesz wdrożyć algorytmy grafów, w których musisz np. Przejść przez wykres i wykonać wiele lokalnych zmian w strukturze wykresu.

Ponieważ wykres nie ma ogólnie struktury rekurencyjnej, uważam, że najlepszym podejściem jest zbudowanie jednej kopii wykresu przy użyciu struktur i wskaźników między nimi (jak można to zrobić np. W C ++) i manipulowanie tą kopią poprzez zmianę wskaźników, tworzenie lub niszczenie węzłów i tak dalej.

Zastanawiam się, jak takie struktury danych i operacje mogą być właściwie obsługiwane w Haskell, ponieważ o ile wiem w Haskell, nie jest możliwe użycie powyższej reprezentacji / podejścia. W tym artykule krótko omówiono niektóre problemy z algorytmami graficznymi w Haskell

EDYTOWAĆ

Niedawno rozmawiałem z ekspertem od programowania funkcjonalnego i potwierdził on, że wydajne wdrażanie niektórych algorytmów graficznych może być dość trudne w Haskell: poruszanie się po wskaźnikach, takich jak w C lub C ++, może być znacznie szybsze.

Wadą Haskell jest to, że jest inaczej. Jest to większy krok od języków, których częściej się uczy lub mówi, więc będzie większa krzywa uczenia się. Jest również mniej popularny w języku, który może ograniczyć dostępność pomocy, jeśli utkniesz. To naprawdę nie są poważne wady.

Jedyną potencjalną wadą jest to, że jest to język funkcjonalny, więc jest mniej przydatny w niektórych domenach problemowych, ale dotyczy to również języków obiektowych. Ogólnie języki nie mają prawdziwych negatywów wykraczających poza krzywe uczenia się, przynajmniej w przypadku stosunkowo popularnych języków. Tak długo, jak język jest kompletny, jest teoretycznie zdolny do wszystkiego.

Biorąc to pod uwagę, szukam wad i problemów związanych z Haskellem

„Problemy z Haskellem” zwykle pojawiają się w niektórych domenach. Haskell to wspaniały język do programowania aplikacji, znacznie przyjemniejszy w pisaniu niż cokolwiek innego. Problemy zwykle pojawiają się, gdy próbujesz zrobić coś, na co nie ma dobrego wsparcia, na przykład:

• Kompilacja krzyżowa. GHC można zbudować jako kompilator krzyżowy, ale proces jest raczej zaangażowany.
• Aplikacje osadzone. Haskell ma zarządzanie pamięcią za pośrednictwem śmietnika, więc ten nie jest zbyt zaskakujący.
• Prędkość. Haskell nie jest tak szybki jak Rdza, choć w większości przypadków będzie konkurował dość dobrze. Zależy to w dużej mierze od dziedziny aplikacji - czyste obliczenia są dobrze zoptymalizowane, ale coś takiego jak „wczytaj plik do bufora i policz liczbę linii” jest trudniejsze do wyrażenia w Haskell.