Jeden z linków, wspomnianych w audycji, odnośnie Haskella: 
https://github.com/Gabriel439/post-rfc/blob/master/sotu.md 
 
A tu coś dla tych, których interesuje gamedev + języki funkcyjne:  
https://michaelshaw.github.io/game_talk/game.html

A to praca naukowa (całkiem przystępnie napisana), o której wspomniałem, gdy nmk był na antenie, nie podając tytułu ani linku, jednak to właśnie opisane w niej podejście ze znanych mi obecnie uważam za najbardziej obiecujące w zakresie podniesienia Haskella, i ogólnie programowania funkcyjnego, z Immature do co najmniej Mature w kategorii „Standalone GUI applications”: oai.cwi.nl

Na plus audycji można zaliczyć to, że wiesz, o czym mówisz. (Może nie ze wszystkim się zgadzam, ale fachowcem jesteś.) Słuchałem kiedyś audycji na Kontestacji, jakiegoś wywiadu z kimś, kto pisał w Javie. Po dwóch czy trzech wypowiedziach stwierdziłem, że koleś w życiu nie powinien być programistą, bo nie ma o tym pojęcia. W Twoim przypadku widać, że znasz się na temacie. 
 
ByteEater, polecasz tego Haskella, chwalisz go... A próbowałeś używać? Mógłbyś się pochwalić jakimiś aplikacjami? 
 
Pytam, bo ja próbowałem. A spróbowałem dlatego, że poczytałem o Haskellu. Wyczytałem mniej-więcej dokładnie to, co powiedziałeś w audycji (same cuda). A z praktyki mam wręcz przeciwne wrażenia niż te, o których opowiadasz. 
 
Zrobić w tydzień to, co konkurencja robi w dwa lata? Ja mam z Haskellem dokładnie na odwrót: to, co w Haskellu zajmuje mi dwa dni, w Eliksirze/Erlangu/JavaScript potrafię zrobić w dwie godziny. Haskell to język piękny, ciekawy i interesujący, ale produktywność w nim żadna. Dlatego Haskellowi zdecydowanie podziękuję. (I żeby była jasność: programuję głównie funkcyjnie; jestem przeciwnikiem programowania obiektowego.) 
 
Kompilator w Haskellu? Ogólnie wypowiadał się nie będę, natomiast wtrącę moje trzy grosze w dziedzinie transpilerów JavaScript. Pełno jest teraz tego (Babel, TypeScript, Elm, CoffeeScript, ...). W większości są one pisane albo w JavaScript, albo w samym transpilowanym języku. Jest też jeden transpiler pisany w Haskellu: PureScript. Efekt? Narzędzia w PureScript za cholerę nie integrują się z resztą ekosytemu Node.js tak, jak pozostałe transpilery. Co z tego, że PureScript (wzorowany na Haskellu) jest znacznie piękniejszy od Elm-a (też funkcyjnego), skoro to właśnie Elm-a znacznie prościej się używa? 
 
Aplikacje webowe? Dokładnie ta sama uwaga. Używając Eliksira, Pythona czy JavaScript jestem znacznie bardziej wydajny, niż w Haskellu. Właśnie dlatego, że Eliksir, Python i JavaScript są językami typowanymi dynamicznie, gorliwymi (przeciwieństwo lazy evaluation) i można w nich pisać funkcje z efektami ubocznymi bez znajomości monad. (A piszę to jako zwolennik typowania statycznego!) 
 
A swoją drogą, to przestań opowiadać farmazony, że w innych językach można przez przypadek odpalić głowice atomowe, a w Haskellu nie. Używałem Haskella przez rok i wiem, że w Haskellu też można popełniać błędy. Jak zresztą w każdym języku. (Tak przy okazji, ByteEater - kiedy to ostatnio Twój program napisany nie-w-Haskellu przez przypadek odpalił głowice atomowe? Bo mnie nigdy się to nie przydarzyło. Podobnie nigdy mi się nie przydarzyło przez przypadek skasować wszystkie dane. Więc argument też, jak dla mnie, chybiony.) 
 
Bliższy prawdy jesteś mówiąc, że w Haskellu można opracować bezpieczny system typów. To prawda. Tylko że zanim to zrobisz w Haskellu, to ja już trzy razy zdążę napisać gotową i działającą aplikację w innym języku. (Takie są moje doświadczenia z Haskellem - choć przyznaję, że ubogie w porównaniu do Pythona czy JavaScript.) 
Poza tym, każdy programista wie (POWINIEN wiedzieć), że specyfikacja oprogramowania często się zmienia. A to znaczy, że projekt typów sprzed, powiedzmy, roku, nie musi być odpowiedni do specyfikacji potrzebnej dzisiaj. Czyli cały misternie przemyślany system typów w Haskellu może powędrować do kosza. 
 
Na koniec napiszę tak: uwielbiam Haskella. To piękny język. Widać, że jest dobrze przemyślany. Gorąco polecałbym naukę Haskella każdemu, kto chciałby się czegoś nowego nauczyć o programowaniu. (A już obowiązkowo dla chcących poznać programowanie CZYSTO funkcyjne.) Jeśli audycja ByteEatera zachęci kogoś do nauki - to super. Spróbujcie. Napiszcie proste programy. Wyróbcie sobie własne zdanie. ByteEater przez 1.5h słodził nt. Haskella, to ja postanowiłem trochę ponarzekać. Tyle w temacie.

@ByteEater 
 
Będąc całkiem zielony i nie rozumiejąc połowy z tego co mówiłeś zacząłem się zastanawiać jakimi zdolnościami matematycznymi powinien wykazywać programista? Czy te zdolności muszą byś rzeczywiście większe w przypadku programowania w Haskellu?

O, fajnie, że są pytania, i jest polemika! Tomek, Faraday, szerzej Wam w takim razie odpowiem w następnym odcinku, w którym planuję dopowiedzieć też o Elixirze i Scali. 
 
Ale teraz tak na szybko dla Was, i dla wszystkich chętnych, przede wszystkim czytających, którzy z jakiegoś powodu nie posłuchają, bądź zrobią to później: 
 
• Nie mówiłem, że Haskella należy się nauczyć jako jedynego języka i stosować w każdej niszy, wręcz przeciwnie. Miałem zamiar zareklamować 3 języki bardziej jako reprezentację pewnego trendu, który ma decydujący – tak przewiduję – wpływ na kierunek obecnego skrętu mainstreamu. Źródło inspiracji, poszerzenie horyzontów, przygotowanie na to, jak będą wyglądać wiodące języki i metody programowania (nawet jeżeli sam Haskell nie będzie wśród nich) za ileś lat. Także te obecnie mainstreamowe się do nich zbliżą jeszcze bardziej, bo już to robią. 
 
• Oczywiście Haskell nie jest tak popularną platformą, w sensie narzędzi, bibliotek integrujących go z czymkolwiek itd., żeby dorównywał JavaScriptowi z jego Node'em i silnikami w przeglądarkach, Pythonowi instalowanemu domyślnie w wielu dystrybucjach Linuksa, a tym bardziej Javie i .NET-owi. Ale nie jest też już akademicką zabawką, ma wiele bibliotek, wiodący kompilator (GHC) obrośnięty pakietem typu batteries included, są przyzwoite IDE i inne narzędzia. Więc gdy chodzi o stosowanie w praktyce, to oczywiście nie bierzcie Haskella w ciemno, tylko sprawdźcie, czy będzie się dało wygodnie w danym zastosowaniu z nim pracować, i to nie tyle z samym językiem, co właśnie pod kątem reszty ekosystemu. Ale to nie żaden minus języka, prawie każdy tak miał (no, Java, C#, Visual Basic i Objective-C (fuj!) nie, bo wprowadzały je gigantyczne korporacje w istniejących i już popularnych produktach). 
 
• Co do szybkiego prześcigania długotrwałego wysiłku konkurencji, to akurat było z wykorzystaniem LISP-a, innego języka funkcyjnego, omawiałem kiedyś już ten przykład dokładniej w audycji. Pisze o tym znany matematyk i informatyk Paul Graham: www.paulgraham.com 
 
• O głowicach to nie farmazon, tylko oczywisty chwyt retoryczny, dobitny przykład, mający działać na wyobraźnię, żeby łatwiej dotrzeć z przekazem, że to jest ważne. Sam np. dla Nokii pisałem przykładowy kod do dołączenia do SDK platformy Ovi, który się pytał (miał demonstrować wywołanie zapytujące się użytkownika o potwierdzenie, i standardowy styl takiego okienka), czy na pewno chcesz launch missiles. To jest wręcz topos w tej branży, jak exegi monumentum w poezji. A programistę, który jakiś czas temu niechcący usunął wszystkie dane, choć nie jestem nim ja, to znam, i to w Kontestacji; na szczęście zrobił to gdzie indziej (z oczywistych względów pominę identyfikację i inne szczegóły). 
 
• Czy i w jakim stopniu silny i statyczny system typów jest krępujący przy zmieniającej się specyfikacji? Czy dynamiczne i słabsze typowanie ma zalety, a jeśli tak, to przy stosowaniu w jakich niszach, które nie byłyby, przynajmniej w długim terminie, przerośnięte przez wady? (Ja uważam, że owszem, ma, w pewnych niszach.) Czy istotną zaletą systemów typów nawet w obliczu zmiennej specyfikacji jest trzymanie pewnej dyscypliny myślowej i w ryzach procesu arbitralnych zmian, co powstrzymuje nas (i klienta, jeśli jest zewnętrzny i bezpośrednio decyzyjny) od tworzenia ameb z featuritis i niespójnego bloatware'u (czego mogą nawet wszyscy żałować już w trakcie implementacji, ale być nieskłonni zmienić podejście, skoro już się wydało pieniądze i pracę na pójście daną drogą)? Czy może najlepszą (tak ja uważam) kombinacją jest programowanie w wielu językach, i pozostawienie słabo typowanego interfejsu skryptowego, podczas gdy zrąb aplikacji, a przynajmniej logika, są napisane w sposób zdatny do statycznej analizy i tym sposobem weryfikacji pożądanych własności (np. bezpieczeństwa), czyli prawdopodobnie w Haskellu lub języku inspirowanym Haskellem? To są głębokie pytania, i myślę, że nieco je sformułowaniami takimi, jak że plotę farmazony, zbyt lekko zbywasz. Warto byłoby porozmawiać i wspólnie te zagadnienia rozważyć. 
 
• Zauważ, że leniwe obliczanie jest coraz częściej obecne, czy to w formie bibliotek, czy nowych cech samego języka, także w JavaScripcie, Pythonie. Javie, .NET, C++, a nawet PHP. Owszem, to też głęboki temat, i naukowcy się zastanawiają i wiele prac piszą (a także eksperymentalnych języków tworzą, głównie zresztą jako rozszerzenia Haskella, który już zajął w tej roli dominującą pozycję) jak zgrabnie dać programiście możliwość łączenia najlepszych do zastosowania w danym problemie kawałków jednego i drugiego. 
 
• Żeby mieć produktywność zespołu programistów w Haskellu, musisz najpierw taki zespół mieć. Szacuję, że ich liczba jest dwucyfrowa na świecie (to i tak zdecydowanie więcej niż dla języków akademickich, takich tylko dla teoretyków), a w Polsce na razie 0. Dlatego jeżeli chcesz coś robić w Haskellu, to zdecydowanie radzę zacząć od jakiejś niezbyt wielkiej rzeczy, do ogarnięcia przez 1 człowieka. 
 
• Kto i w którym odcinku był gościem jako niekompetentny programista w Javie? Było to może u Kamila C.? Ja zwykle w takich sytuacjach wrzucam ten link: www.joelonsoftware.com 
 
• Faraday, myślę, że z tą połową to przesadzasz, tak retorycznie. ;-P Tylko w paru momentach była wyższa matematyka, i starałem się też od razu dopowiedzieć coś dającego intuicję (np. o tych monadach). Czy da się programować w Haskellu bez uprzedniej głębszej znajomości matematyki niż w przypadku innych języków? Da się. Nawet czytałem fajny tutorial, który zaczyna nie od prostych wartości, typów, funkcji, curryfikacji, rekurencji i funkcji wyższego rzędu, jak większość, tylko od monady IO, bez stojącej za nią teorii, i od prostych programików z konsolowym wejściem i wyjściem, np. "Hello, World!". Ale to jest tak, że im dalej w las, tym więcej matematyki, której rozumienie pozwala dobrze wykorzystywać elementy Haskella. Przy czym można się tego uczyć równolegle, co zresztą polecam (i nauczam, za pieniądze), m.in. dlatego, że przełożenie na programowanie daje tej nauce matematyki motywację. No i jest to w znacznej mierze matematyka dość odmienna od tej w szkole, czy nawet na większości studiów inżynierskich, według mnie ciekawsza.

Ogólnie nie padły chyba stwierdzenia takie jak immutability oraz rekurencja ogonowa. A to są, moim zdaniem, dosyć mocne punkty języków funkcyjnych. 
 
Temat trudności programowania w językach funkcyjnych jest według mnie taki sam jak z innej beczki - sorry, znowu trochę gamedev: 
 
w szkołach, książkach i internetach najczęśćiej uczy się robić obiektowo. Niestety jest to często mniej wydajne - tam gdzie naprawdę potrzeba - głównie z powodu `vtable`. Dlatego z czasem powrócono do pisania gier albo chociażby raytracerów w sposób zorientowany na dane. Tzn. atrybuty zaczęto wkładać do osobnych tablic, np. zamiast robić klasę `Entity { Vector2 position, Vector2 size, Vector3 speed }`, to powstają trzy tablice `float[] positions`, `float[] sizes`. Bo tak jest szybciej. No ale wiadomo - architektura to, no, wątpliwa, chociaż pojawiło się potem coś takiego jak Data-Driven Design czy podobne terminy. Potem wykluło się coś znacznie piękniejszego, czyli Entity Component Systems - tu klasyczny link: t 
 
Teraz będę dążył do analogi nauki Haskella przez Tomka Primke. Podejście ECS w stosunku do OOP jest zgoła inne. W zasadzie to bardzo inne. Nie skupiamy się już na obiektach, a aspektach, czyli zestawach komponentów, pod które piszemy obsługujące je Systemy. Mniejsza o architekturę, tematem interesuję się już od ponad dwóch lat, właściwie bawiąc się tym, kodząc różne rzeczy po godzinach właśnie w ten sposób. Początek wyglądał świetnie! Robię MovementSystem, który operuje na tych encjach (Entity), które mają komponenty Position i Velocity. Ale po paru klasach tego typu człowiek miał pełno wątpliwości - co z hierarchią encji, coś z warstwami renderowania, co z dwukierunkowymi relacjami między encjami, np. przy kolizjach, co z inputem, co z eventami itd. No to sobie rozwiązywałem te problemy jeden po drugim. Przyznam się, że przez rok takiej zabawy po godzinach mindset ciągle przestawiałem. Tzn. trudno było z tą architekturą pracować, ale zdaję sobie sprawę, że z powodu OOP. I jak człowiekowi po miesiącu wydawało się, że już obiektowość go nie trapi, to i tak przez następne 11 miesięcy nie jest jak ryba w wodzie. 
 
Odnośnie funkcjyjnych to ja programowałem w OCamlu na studiach przez cały semestr i tak mi się spodobało, że zacząłem zgłębiać inne możliwości - Erlang, który był na serwerach w jednej pracy, no i Scala, z której zrobiłem certyfikat zorganizowany na Coursera.org przez twórcę Scali - Martina Odersky'iego. Szczerze, to ten certyfikat ledwie liznął niektóre tematy, a niektóre pozostawił samym sobie. Monady niestety też. W każdym razie Scalę mogę polecić szczególnie niezdecydowanym - jest funkcyjność, obiektowość i mutacyjność danych (mutability) nie jest jakoś szczególnie utrudniona jak np. w OCaml. 
 
Natomiast na studiach poznałem jeszcze inny język - mozart.github.io Wielu się nie podobało, bo "niepraktyczne" itd. ale deklaratywność dla komunikacji międzyprocesowej tutaj zaprezentowana była miodna (o ile pamiętam). W zasadzie kojarzy mi się z tematem modnym swego czasu - czyli FRP (Functional Reactive Programming) właśnie. Przy czym, to FRP to dużo bardziej coś w rodzaju "approach" niż "language syntax", "algorithm" albo "design pattern". A u podstaw FRP, wydaje mi się, leży deklaratywność, czyli możliwość opisania tego co się chce uzyskać - zamiast tego jak to uzyskać. Deklaratywność to jest moc i moim zdaniem powinniśmy do niej dążyć w wielu ogólnie pojętych systemach (chociażby przez data binding), zwłaszcza w których użytkownik ma bezpośredni wpływ na stan aplikacji, gdzie wtedy deklaratywność upraszcza auto-wnioskowanie stanu na podstawie inputu. Niestety w praktyce wydaje się to trudne, bo za bardzo wysokopoziomowe. Komputery jednak działają sekwencyjnie :( 
 
Odnośnie wspomnianego wielokrotnie leniwego obliczania, to skojarzył mi się też CQRS (bardziej approach niż design pattern - devtalk.pl gdzie taka deklaratywność, pod której sukienką kryje się leniwe obliczanie, data binding i takie tam, to właśnie najczytelniejszy sposób zaprogramowania takich optymalizacji jak w CQRS. A pragnę zauważyć, że optymalizacje to jedna z gorszych rzeczy psujących utrzymywalność kodu, czyli mówiąc wprost - jego czytelność. 
 
I jeszcze ostatni temat - matematyka w językach funkcyjnych. Ja bym nie "reklamował" tego w ten sposób, bo większość ludzi nie myśli tutaj o rachunku lambda / składaniu funkcji czy regułach Liskova, tylko raczej o wykresach i wzorze na deltę przy funkcji kwadratowej albo o pochodnych i całkach :D - jeżeli mieli z tym ostatnim do czynienia. A to trochę nie tak.