O co chodzi z Haskellem? [Zamknięte]

Znam kilku programistów, którzy ciągle rozmawiają o Haskellu, kiedy są między sobą, a tutaj na SO wszyscy wydają się kochać ten język. Bycie dobrym w Haskell wydaje się być znakiem rozpoznawczym genialnego programisty.

Czy ktoś może podać kilka przykładów Haskella, które pokazują, dlaczego jest tak elegancki / lepszy?

Sposób, w jaki mi się to podoba, i to, co myślę, jest prawdą po tym, jak przez miesiąc pracowałem nad nauką Haskell, to fakt, że programowanie funkcjonalne zmienia twój mózg w interesujący sposób: zmusza cię do myślenia o znanych problemach na różne sposoby : zamiast pętli, myśl w mapach, fałdach i filtrach, itp. Ogólnie rzecz biorąc, jeśli masz więcej niż jedną perspektywę na problem, dzięki temu będziesz lepiej rozumieć ten problem i zmieniać punkty widzenia w razie potrzeby.

Inną fajną rzeczą w Haskell jest jego system typów. Jest ściśle wpisany na maszynie, ale silnik wnioskowania o typie sprawia, że ​​czuje się jak program w Pythonie, który w magiczny sposób mówi ci, kiedy popełniłeś głupi błąd związany z typem. Komunikatów o błędach Haskella w tym względzie brakuje nieco, ale gdy lepiej zaznajomisz się z językiem, powiesz sobie: tak powinno być pisanie!

To przykład, który przekonał mnie, aby dowiedzieć się, Haskell (chłopiec i jestem zadowolony, zrobiłem).

-- program to copy a file --
import System.Environment

main = do
         --read command-line arguments
         [file1, file2] <- getArgs

         --copy file contents
         str <- readFile file1
         writeFile file2 str

OK, to krótki, czytelny program. W tym sensie jest lepszy niż program w C. Ale czym to się tak różni od (powiedzmy) programu w Pythonie o bardzo podobnej strukturze?

Odpowiedź to leniwa ocena. W większości języków (nawet niektórych funkcjonalnych) program o strukturze podobnej do powyższego spowodowałby załadowanie całego pliku do pamięci, a następnie ponowne zapisanie pod nową nazwą.

Haskell jest „leniwy”. Nie oblicza rzeczy, dopóki nie musi, a co za tym idzie , nie oblicza rzeczy, których nigdy nie potrzebuje. Na przykład, gdybyś usunął tę writeFilelinię, Haskell nie zawracałby sobie głowy czytaniem czegokolwiek z pliku.

W obecnej sytuacji Haskell zdaje sobie sprawę, że writeFilezależy od readFile, więc jest w stanie zoptymalizować tę ścieżkę danych.

Chociaż wyniki są zależne od kompilatora, to zwykle dzieje się po uruchomieniu powyższego programu: program wczytuje blok (powiedzmy 8KB) pierwszego pliku, następnie zapisuje go w drugim pliku, a następnie odczytuje kolejny blok z pierwszego plik i zapisuje go w drugim pliku i tak dalej. (Spróbuj stracena nim biegać !)

... co wygląda bardzo podobnie do tego, co zrobiłaby wydajna implementacja kopii pliku w C.

Tak więc Haskell umożliwia pisanie zwartych, czytelnych programów - często bez poświęcania dużej wydajności.

Kolejną rzeczą, którą muszę dodać, jest to, że Haskell po prostu utrudnia pisanie błędnych programów. Niesamowity system typów, brak efektów ubocznych i oczywiście zwartość kodu Haskell redukuje błędy z co najmniej trzech powodów:

1. Lepszy projekt programu. Mniejsza złożoność prowadzi do mniejszej liczby błędów logicznych.

2. Kompaktowy kod. Mniej wierszy, w których mogą występować błędy.

3. Błędy kompilacji. Wiele błędów po prostu nie jest poprawnych Haskell .

Haskell nie jest dla każdego. Ale każdy powinien spróbować.

Zadajesz złe pytanie.

Haskell nie jest językiem, w którym patrzysz na kilka fajnych przykładów i mówisz "aha, teraz rozumiem, to jest to , co czyni go dobrym!"

To bardziej tak, że mamy wszystkie te inne języki programowania i wszystkie są mniej więcej podobne, a następnie jest Haskell, który jest zupełnie inny i zwariowany w sposób, który jest całkowicie niesamowity, gdy przyzwyczaisz się do tego zwariowania. Ale problem polega na tym, że przyzwyczajenie się do tego dziwactwa zajmuje trochę czasu. Rzeczy, które odróżniają Haskella od prawie każdego innego, nawet pół-głównego języka:

• Leniwa ocena
• Brak efektów ubocznych (wszystko jest czyste, IO / etc dzieje się przez monady)
• Niesamowicie ekspresyjny system typów statycznych

a także kilka innych aspektów, które różnią się od wielu języków głównego nurtu (ale są wspólne dla niektórych):

• funkcjonalny
• znaczące spacje
• wywnioskowany typ

Jak odpowiedziały niektóre inne plakaty, połączenie wszystkich tych cech oznacza, że ​​myślisz o programowaniu w zupełnie inny sposób. Dlatego trudno jest znaleźć przykład (lub zestaw przykładów), który odpowiednio zakomunikowałby to Joe-mainstreamowi-programista. To rzecz empiryczna. (Aby dokonać analogii, mogę pokazać zdjęcia z mojej podróży do Chin w 1970 roku, ale po obejrzeniu zdjęć nadal nie będziesz wiedział, jak to było mieszkać tam w tym czasie. Podobnie mogę pokazać Ci Haskell „quicksort”, ale nadal nie będziesz wiedział, co to znaczy być Haskellerem).

To, co naprawdę wyróżnia Haskell, to wysiłek włożony w jego projekt, aby wymusić programowanie funkcjonalne. Możesz programować w funkcjonalnym stylu w prawie każdym języku, ale zbyt łatwo jest porzucić przy pierwszej dogodności. Haskell nie pozwala na porzucenie programowania funkcjonalnego, więc musisz doprowadzić to do logicznego wniosku, który jest ostatecznym programem, o którym łatwiej jest myśleć i omija całą klasę najbardziej drażliwych typów błędów.

Jeśli chodzi o pisanie programu do użytku w świecie rzeczywistym, może się okazać, że Haskellowi brakuje pewnych praktycznych aspektów, ale ostateczne rozwiązanie będzie lepsze, jeśli najpierw poznałeś Haskella. Zdecydowanie jeszcze mnie tam nie ma, ale jak dotąd nauka Haskella była dużo bardziej pouczająca niż powiedzenie, że Lisp był na studiach.

Część zamieszania polega na tym, że czystość i statyczne typowanie umożliwiają równoległość w połączeniu z agresywnymi optymalizacjami. Języki równoległe są teraz popularne, a wielordzeniowy jest nieco uciążliwy.

Haskell oferuje więcej opcji równoległości niż prawie jakikolwiek inny język ogólnego przeznaczenia, wraz z szybkim, natywnym kompilatorem kodu. Naprawdę nie ma konkurencji z tego rodzaju obsługą stylów równoległych:

• półjawny równoległość za pośrednictwem iskier wątku
• jawne wątki
• tablice równoległe danych
• aktorzy i przekazywanie wiadomości
• pamięć transakcyjna

Jeśli więc zależy ci na tym, aby praca wielordzeniowa działała, Haskell ma coś do powiedzenia. Świetnym miejscem do rozpoczęcia jest samouczek Simona Peytona Jonesa dotyczący programowania równoległego i współbieżnego w Haskell .

Pamięć transakcyjna oprogramowania to całkiem fajny sposób radzenia sobie z współbieżnością. Jest znacznie bardziej elastyczny niż przekazywanie wiadomości i nie jest podatny na zakleszczenia jak muteksy. Implementacja STM w GHC jest uważana za jedną z najlepszych.

Spędziłem ostatni rok ucząc się Haskella i pisząc w nim dość duży i złożony projekt. (Projekt jest zautomatyzowanym systemem handlu opcjami, a wszystko, od algorytmów handlowych po analizę i obsługę niskopoziomowych, szybkich danych rynkowych, odbywa się w Haskell.) Jest znacznie bardziej zwięzły i łatwiejszy do zrozumienia (dla osób z odpowiednie tło) niż wersja Java, a także wyjątkowo solidne.

Prawdopodobnie największą wygraną dla mnie była możliwość modularyzacji przepływu sterowania przez takie rzeczy, jak monoidy, monady i tak dalej. Bardzo prostym przykładem może być monoid zamawiania; w wyrażeniu takim jak

c1 `mappend` c2 `mappend` c3

gdzie c1i tak po powrocie LT, EQalbo GT, c1wracając EQpowoduje ekspresję kontynuować, oceny c2; jeśli c2zwraca LTlub GTjest to wartość całości, ac3 nie jest obliczana. Tego rodzaju rzeczy stają się znacznie bardziej wyrafinowane i złożone w rzeczach takich jak monadyczne generatory wiadomości i parsery, w których mogę przenosić różne typy stanów, mieć różne warunki przerwania lub mogę chcieć być w stanie zdecydować dla dowolnego konkretnego połączenia, czy przerwanie naprawdę oznacza „brak dalszego przetwarzania” lub oznacza „zwracanie błędu na końcu, ale kontynuowanie przetwarzania w celu zebrania dalszych komunikatów o błędach”.

To wszystko jest rzeczy, których nauczenie się zajmuje trochę czasu i prawdopodobnie sporo wysiłku, dlatego może być trudno przedstawić przekonujący argument na jego rzecz dla tych, którzy jeszcze nie znają tych technik. Myślę, że All About Monads samouczek daje całkiem imponującą demonstrację jednego aspektu tego, ale nie spodziewałbym się, że ktoś, kto nie jest zaznajomiony z materiałem, już go „zrozumie” przy pierwszym, a nawet trzecim, uważnym czytaniu.

W każdym razie w Haskell jest też wiele innych dobrych rzeczy, ale jest to główny, o którym nie wspominam tak często, prawdopodobnie dlatego, że jest dość złożony.

Ciekawy przykład można znaleźć pod adresem : http://en.literateprograms.org/Quicksort_(Haskell)

Co ciekawe, przyjrzyjmy się implementacji w różnych językach.

To, co sprawia, że ​​Haskell jest tak interesujący, podobnie jak inne języki funkcjonalne, to fakt, że musisz inaczej myśleć o programowaniu. Na przykład generalnie nie będziesz używać pętli for ani while, ale użyjesz rekurencji.

Jak wspomniano powyżej, Haskell i inne języki funkcjonalne przodują w przetwarzaniu równoległym i pisaniu aplikacji do pracy na wielu rdzeniach.

Nie mogłem ci podać przykładu, jestem facetem od OCaml, ale kiedy jestem w takiej sytuacji jak ty, ciekawość po prostu się ogarnia i muszę pobrać kompilator / interpreter i spróbować. W ten sposób prawdopodobnie dowiesz się znacznie więcej o mocnych i słabych stronach danego języka funkcjonalnego.

Jedną z rzeczy, które uważam za bardzo fajne, gdy mam do czynienia z algorytmami lub problemami matematycznymi, jest nieodłączna leniwa ocena obliczeń przez Haskella, która jest możliwa tylko dzięki jej ściśle funkcjonalnej naturze.

Na przykład, jeśli chcesz obliczyć wszystkie liczby pierwsze, możesz użyć

primes = sieve [2..]
    where sieve (p:xs) = p : sieve [x | x<-xs, x `mod` p /= 0]

a rezultatem jest nieskończona lista. Ale Haskell oceni to od lewej do prawej, więc dopóki nie spróbujesz zrobić czegoś, co wymaga całej listy, nadal możesz go używać bez utknięcia programu w nieskończoności, na przykład:

foo = sum $ takeWhile (<100) primes

która sumuje wszystkie liczby pierwsze mniejsze niż 100. Jest to dobre z kilku powodów. Przede wszystkim muszę napisać tylko jedną funkcję pierwszą, która generuje wszystkie liczby pierwsze, a potem jestem prawie gotowy do pracy z liczbami pierwszymi. W języku programowania zorientowanego obiektowo potrzebowałbym jakiegoś sposobu, aby powiedzieć funkcji, ile liczb pierwszych powinna obliczyć przed zwróceniem, lub emulować zachowanie nieskończonej listy z obiektem. Inną rzeczą jest to, że generalnie piszesz kod, który wyraża to, co chcesz obliczyć, a nie w jakiej kolejności oceniać rzeczy - zamiast tego kompilator robi to za Ciebie.

Jest to przydatne nie tylko w przypadku nieskończonych list, w rzeczywistości jest używane bez Twojej wiedzy przez cały czas, gdy nie ma potrzeby oceniania więcej niż to konieczne.

Zgadzam się z innymi, że zobaczenie kilku małych przykładów nie jest najlepszym sposobem na pochwalenie się Haskellem. Ale i tak dam trochę. Oto błyskawiczne rozwiązanie problemów 18 i 67 Projektu Euler , które proszą Cię o znalezienie ścieżki o maksymalnej sumie od podstawy do wierzchołka trójkąta:

bottomUp :: (Ord a, Num a) => [[a]] -> a
bottomUp = head . bu
  where bu [bottom]     = bottom
        bu (row : base) = merge row $ bu base
        merge [] [_] = []
        merge (x:xs) (y1:y2:ys) = x + max y1 y2 : merge xs (y2:ys)

Oto pełna implementacja algorytmu BubbleSearch do wielokrotnego użytku autorstwa Lesh i Mitzenmacher. Użyłem go do spakowania dużych plików multimedialnych do archiwizacji na DVD bez odpadów:

data BubbleResult i o = BubbleResult { bestResult :: o
                                     , result :: o
                                     , leftoverRandoms :: [Double]
                                     }
bubbleSearch :: (Ord result) =>
                ([a] -> result) ->       -- greedy search algorithm
                Double ->                -- probability
                [a] ->                   -- list of items to be searched
                [Double] ->              -- list of random numbers
                [BubbleResult a result]  -- monotone list of results
bubbleSearch search p startOrder rs = bubble startOrder rs
    where bubble order rs = BubbleResult answer answer rs : walk tries
            where answer = search order
                  tries  = perturbations p order rs
                  walk ((order, rs) : rest) =
                      if result > answer then bubble order rs
                      else BubbleResult answer result rs : walk rest
                    where result = search order

perturbations :: Double -> [a] -> [Double] -> [([a], [Double])]
perturbations p xs rs = xr' : perturbations p xs (snd xr')
    where xr' = perturb xs rs
          perturb :: [a] -> [Double] -> ([a], [Double])
          perturb xs rs = shift_all p [] xs rs

shift_all p new' [] rs = (reverse new', rs)
shift_all p new' old rs = shift_one new' old rs (shift_all p)
  where shift_one :: [a] -> [a] -> [Double] -> ([a]->[a]->[Double]->b) -> b
        shift_one new' xs rs k = shift new' [] xs rs
          where shift new' prev' [x] rs = k (x:new') (reverse prev') rs
                shift new' prev' (x:xs) (r:rs) 
                    | r <= p    = k (x:new') (prev' `revApp` xs) rs
                    | otherwise = shift new' (x:prev') xs rs
                revApp xs ys = foldl (flip (:)) ys xs

Jestem pewien, że ten kod wygląda jak przypadkowy bełkot. Ale jeśli przeczytasz wpis na blogu Mitzenmachera i zrozumiesz algorytm, , że można spakować algorytm do kodu, nie mówiąc nic o tym, czego szukasz.

Podając kilka przykładów, o które prosiłeś, powiem, że najlepszym sposobem, aby zacząć doceniać Haskella, jest przeczytanie artykułu, w którym dostałem pomysły potrzebne do napisania pakowacza DVD: Why Functional Programming Matters autorstwa Johna Hughesa. Artykuł faktycznie poprzedza Haskell, ale znakomicie wyjaśnia niektóre pomysły, które sprawiają, że ludzie lubią Haskella.

Dla mnie atrakcją Haskella jest obietnica gwarantowanej przez kompilator poprawności. Nawet jeśli dotyczy to czystych części kodu.

Napisałem dużo kodu do symulacji naukowych i wiele razy zastanawiałem się , czy w moich poprzednich kodach był błąd, który mógłby unieważnić wiele bieżących prac.

Uważam, że w przypadku niektórych zadań jestem niesamowicie produktywny z Haskellem.

Powodem jest zwięzła składnia i łatwość testowania.

Oto jak wygląda składnia deklaracji funkcji:

foo a = a + 5

To najprostszy sposób, w jaki mogę wymyślić definicję funkcji.

Jeśli napiszę odwrotność

inverseFoo a = a - 5

Pisząc, mogę sprawdzić, czy jest to odwrotność dowolnego losowego wejścia

prop_IsInverse :: Double -> Bool
prop_IsInverse a = a == (inverseFoo $ foo a)

I dzwoniąc z linii poleceń

jonny @ ubuntu: runhaskell quickCheck + nazwy fooFileName.hs

Który sprawdzi, czy wszystkie właściwości w moim pliku są zachowane, poprzez losowe testowanie danych wejściowych sto razy.

Nie sądzę, aby Haskell był idealnym językiem do wszystkiego, ale jeśli chodzi o pisanie małych funkcji i testowanie, nie widziałem nic lepszego. Jeśli twoje programowanie zawiera element matematyczny, jest to bardzo ważne.

Jeśli potrafisz owinąć głowę wokół systemu czcionek w Haskell, myślę, że sam w sobie jest to spore osiągnięcie.

nie ma konstrukcji pętli. niewiele języków ma tę cechę.

Zgadzam się z tymi, którzy mówili, że programowanie funkcjonalne przekręca twój mózg, aby patrzeć na programowanie z innej perspektywy. Używałem go tylko jako hobbysta, ale myślę, że zasadniczo zmieniło to sposób, w jaki podchodzę do problemu. Nie sądzę, żebym był prawie tak skuteczny z LINQ bez kontaktu z Haskellem (i używania generatorów i list składanych w Pythonie).

Mówiąc inaczej: Steve Yegge pisze, że językom Hindely-Milner brakuje elastyczności wymaganej do pisania dobrych systemów :

HM jest bardzo ładny, w całkowicie bezużytecznym formalnym matematycznym sensie. Bardzo dobrze obsługuje kilka konstrukcji obliczeniowych; funkcja dopasowania do wzorca dostępna w Haskell, SML i OCaml jest szczególnie przydatna. Nic dziwnego, że radzi sobie z niektórymi innymi popularnymi i wysoce pożądanymi konstrukcjami w najlepszym razie niezręcznie, ale wyjaśniają te scenariusze, mówiąc, że się mylisz, że tak naprawdę ich nie chcesz. Wiesz, rzeczy takie jak, och, ustawianie zmiennych.

Haskella warto się nauczyć, ale ma on swoje słabości.