Konieczność nauki rozszerzenia języka haskell do produkcji

Podstawowy język Haskell jest naprawdę prosty. Pochodząc z tła OO, główną trudnością jest dostosowanie się do czysto funkcjonalnego paradygmatu.

Ucząc się „podstawowego” języka Haskell, zawsze brałem pod uwagę rozszerzenia językowe jako zabawki dla osób CS lub eksperymenty dla przyszłych wersji języka (jak from future import ???w Pythonie).

Jednak kiedy zacząłem patrzeć na frameworki takie jak Yesod, okazało się, że wiele plików źródłowych wymaga rozszerzeń 3 i 4. Niektóre wyglądają dość prosto (StringOverload). Inne są naprawdę przerażające (GADT, Type Famillies, Template Haskell). Ich dokumentacja prowadzi do artykułów naukowych, co jest przerażające dla kogoś, kto spodziewa się „nowej” biblioteki.

Czy trzeba uczyć się rozszerzeń języka GHC, aby być produktywnym w Haskell? Gdybyś zatrudnił programistę Haskell do aplikacji produkcyjnej, czy poprosiłbyś o taką wiedzę?

haskell

— Simon Bergot
źródło

Zobacz także: stackoverflow.com/a/10849782/894284

Czy trzeba uczyć się rozszerzeń języka GHC, aby być produktywnym w Haskell?

Tak. Dotyczy to każdego języka / narzędzia. Z podstawową / podstawową wiedzą możesz rozwiązać problemy związane z konkursem online, może to być niewielki projekt uniwersytecki, ale zdecydowanie nie aplikacja w świecie rzeczywistym.

Gdybyś zatrudnił programistę Haskell do aplikacji produkcyjnej, czy poprosiłbyś o taką wiedzę?

To zależy teraz od tego, czy masz przy sobie jakąś osobę, która może dzielić się tą wiedzą. Jeśli tak, to osoba ta może zwiększyć nowego pracownika. Jeśli nie, najpierw musisz zdobyć taką wiedzę. I znowu dotyczy to nowych technologii.

Oczywiście można również próbować zatrudniać ludzi posiadających tak głęboką wiedzę w Haskell. Ale Haskell jest stosunkowo nowy w branży i biorąc pod uwagę, że wokół niego wykonano niewiele projektów komercyjnych, znalezienie takiej osoby będzie trudne. Skutecznym sposobem na zbudowanie zespołu specjalistów w Haskell będzie zatrudnienie ludzi, którzy znali się na podstawach i chcą pracować w Haskell, a następnie ich kształcenie.

— Manoj R.
źródło

Chciałem zaprotestować, ale potem zobaczyłem, że Real World Haskell uczy wielu języków. Dziękuję za Twoją odpowiedź.

— Simon Bergot

„I dotyczy to każdego języka / narzędzia” - to całkowicie nieprawda. Powiedzmy, weź takie języki jak Java, C #, C ++ - żaden z nich nie ma rozszerzeń języka, które są powszechnie spotykane w kodzie aplikacji w świecie rzeczywistym. Jeśli musisz używać rozszerzeń językowych za każdym razem, gdy musisz napisać coś mniej trywialnego niż „rozwiązania problemów z konkursem online”, moim zdaniem jest coś bardzo złego w specyfikacji językowej.

— Malcolm,

@ Malcolm Dlaczego znajdujesz „Jeśli musisz używać rozszerzeń językowych za każdym razem, gdy musisz napisać coś mniej trywialnego niż„ rozwiązania problemów w konkursie online ”, moim zdaniem jest coś bardzo złego w specyfikacji językowej.” szczerze mówiąc? Jaka jest cecha rozszerzenia, które powoduje, że jest ono ujemne? Używam ghc i dostarczonych rozszerzeń. Dodanie rozszerzenia do istniejącego projektu wydaje się równie uciążliwe jak dodanie innej biblioteki.

— Davorak

@Davorak Ponieważ zamiast jednego języka mamy zillion różnych kombinacji rozszerzeń i nie wiesz nic o tym, czy kod będzie się kompilował na pewnym kompilatorze. Rozszerzenia sprawiają, że kod jest nieprzenośny. A także sprawia, że nauka języka jest trudna do nauczenia, ponieważ zamiast jednego zestawu funkcji, z których wszyscy korzystają, jest ogromna liczba dodatkowych funkcji, a ty nie masz pojęcia, które z nich musisz znać i które z nich istnieją, a które istnieją. ponieważ naukowcy dobrze się bawią.

— Malcolm

@Davorak Właśnie o tym mówię: wszyscy używają GHC, ponieważ jest to jedyny nadal aktywnie utrzymywany kompilator. Inne kompilatory nie nadążają, więc nikt nie może ich używać i nie ma powodu, by w nie inwestować. Jeśli chodzi o biblioteki: wybierasz biblioteki dla problemu i pracujesz tylko z nimi. Powiedz, że jeśli chcesz czytać XML, potrzebujesz tylko jednej biblioteki do odczytu XML. Jednak w przypadku rozszerzeń nie jest oczywiste, kiedy tego potrzebujesz. Chociaż istnieje również problem z bibliotekami. Powiedzmy, że w Javie są tylko tablice i kolekcje, aw Haskell jest mnóstwo bibliotek tablic.

— Malcolm