Haskell-programmerare som inte kan förklara vad en Monad är

Folk som jobbar med och pratar sig varma om Hashkell, som samtidigt inte kan förklara vad en Monad är under 4 timmar, är det typiska haskell programmerare?

De säger att det är lite som "matte" för att förstå vad en Monad är måste du först förstå vad en Functor och en Applicative är osv.

Är detta hipsters som helt har förlorat greppet om vad de fakiskt skall producera med sin kod, och i stället grottar ned sig i abstrakta begrepp som de själva, trots otaliga timmar knappt verkar lyckas förstå?

Varför inte bara använda PHP och få det gjort?

För att de är unika snöflingor. Hipsters helt enkelt som ska vara speciella. Skulle inte förvåna mig om de klär sig i scarf, skägg, glasögon och khakibyxor.

De vet oftast inte vad de pratar om men vill ses av andra som unika. De är posers helt enkelt.

De har helt enkelt börjat inse det fina med funktionell programmering

Att de inte kan allting direkt beror nog på att det är relativt nytt för dem. Du har nog också varit där någon gång.

Haskell är ett jävligt häftigt språk som vänder upp-och-ner på ens programmerarvärld om man kommer från ett OOP-språk. Så det tar ju ett tag innan man lär sig, det är väl nice att de brinner för det under tiden

Vet du vad en monad är TS? Jag hör gärna en beskrivning

Jag har absolut ingen aning, och jag ville få det förklarat. När jag lärde mig funktionell programmering i Erlang så fanns det inga monader.

Det fans funktioner, guards, tuples, listor som bestod av tuples, maps, processes och lite annat.

Viktiga saker man behövde bemästra var pattern matching och att bygga svansrekursiva funktioner mha. ackumulatorer.

Men allt det här måste finnas i haskell också.

Att förklara vad t.ex. en process är i erlang är inte speciellt svårt. Erlang använder sig av lättviktstrådar som sceduleras på ett antal os-trådar. Antalet os trådar är med fördel lika många som antalet processor kärnor. Erlang motron har altså ett eget litet "operativsystem" inbyggt för att hantera processer. Processer i erlang kommunicerar via message passing, villket gör att man undviker alla konstiga problem som är associerade med delat minne och locks.

Lättvitktstrådarna kan iof dela datastrukturer när det är säkert. T.ex. om jag skickar en tuple till en annan process så behöver den inte kopieras. Om den andra tråden börjar göra något med den så resulerar det i en cons operation, och då blir det en ny tuple. Det beror på hur datastrukturer hanteras i erlang. Du kan i princip aldrig ändra på befintliga datastrukturer, utan du skapar hela tiden nya strukturer som retuneras ur dina funktioner.

Ja, Erlang ska ju vara väldigt funktionellt också av vad jag förstått, så det låter ganska likt Haskell ur det perspektivet. Haskell är nog lite mer strikt (gissar jag på)

Jag är ingen jätteexpert själv, men jag försöker lära mig lite då och då eftersom det är intressant. Någon får rätta mig om jag har fel.

Monader är väl ett matematiskt begrepp som kommer ifrån "category theory", så det är väl inte riktigt att likna med någon särskild funktion i språket. Monader kan man nog skapa i de flesta språk (men Haskell är som klippt och skuret för det i och med sitt avancerade typsystem).

Kort och gott så kan man väl säga att det är en funktion som man skapar (men det finns många färdiga monader också).

Denna funktion har ett gäng egenskaper (och krav) som gör den väldigt kraftfull. Den gör att du kan föra samman komplexa datastrukturer på ett häftigt sätt. Den kan t.ex. beskriva hur du för samman musikstycken, människor, ordrar, tåg eller whatever.

Ska man dra det mer extremt och förenklat så skulle det väl vara möjligt att göra beräkningar i stil med:
x = Tåg * Musikstycke + Människa / Order

En sådan beräkning ser ganska bisarr ut. Vad fan betyder ens "Tåg multiplicerat med musikstycke"? Hur kan ett tåg multipliceras med musik? Men det är min uppfattning att kategoriteorin behandlar sådant, och det blir monadens uppgift att reda ut det. Detta var ett bisarrt exempel med mening, men det 'är bara för att framhäva poängen med vad jag menar med att "föra samman komplexa datastrukturer"

Men det enda en nybörjare behöver veta är väl typ att en monad är vad man använder för att kapsla in sidoeffekter. Det gör att dina program förmodligen aldrig någonsin kommer att råka ut för ett runtime exception.

Men monader har många fler egenskaper, men det är ganska svårt att förklara allt i en mening. Denna videon tycker jag är bäst, och det förklaras väldigt tydlig, och är riktad till folk utan bakgrund i Haskell. Ta dig en titt på den så förstår du nog varför det är svårt (särskilt för nybörjare) att förklara över en öl:
https://youtu.be/ZhuHCtR3xq8

Och detta är inte allt. Vill man verkligen förstå det så behöver man plugga "category theory", då kan den här serien nog vara användbar https://www.youtube.com/playlist?lis...t6gyZJZZAPoQ6v

Men det är overkill, precis som det nämns i det första klippet jag länkade tidigare.


Men som sagt, det brukar vara räcka att säga typ "Monader är bra delvis för att de kapslar in sidoeffekter, och det är ett krav i Haskell eftersom sidoeffekter inte tillåts. Det gör ditt program säkert, deterministiskt och korrekt". Det är nog förklaringen man bör satsa på när man ska förklara över en öl

Om man på allvar använder Haskell till något vad som helst förutom att lära ut funktionell programmering, så är man någon sorts hipster ja. Icke-hipsters använder Erlang eller liknande om de nu absolut måste använda något funktionellt språk.

Erlang är fett najs. Lite mycket boilerplate, men jag skulle gärna syssla med Elixir till vardags.