Presentation jag höll på DevLin 2011 om hur det är att gå över från att utveckla objekt- (klass)orienterat till att utveckla i funktionella språk exemplifierat med erlang.
3. “Man behöver tänka i timmar utan att kunna skriva en
rad, men när man sedan löser problemet vet man att
man gjort det på rätt sätt.”
- Anonym kollega
4. Be rational! Get real!
i π
If you understand the joke, I have bad news for you...
Math Geek
14. ~50 designmönster Null
Trådsäkerhet
SOLID-principerna
DDD
OO i ett nöt...
Datastrukturer och beteende i ett
Arv - använd bara för klasser utan tillstånd
BDD
15. ~10 designmönster (5 från OO-världen)
Rekursion och svansrekursion
Immuterbart tillstånd Monader
FP i ett nöt...
Ackumulatorer
Datastrukturer separerade från beteende
Högre ordningens funktioner
38. Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
39. Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
50. me: Ok, jag tänker förklara monader på
DevLin.:)
Alla IT-konferenser med självaktining har
någon som förklarar monader.
Jag tar gärna på mig den dumstruten.
Niklas: :D nice
"de är typ shell pipes". klart. ;)
-Saxat ur chat med Niklas Lindström
51. me: om jag skulle säga att en monad är en
process som kan ackumulera state för att
sedan exekvera en funktion när lämpligt
state uppnåtts. Skulle du fortfarande
säga att du känner mig då?
-Saxat ur chat med Niklas Lindström
Funktionella språk sägs vara anpassat för matematiknördar - något akademiskt som man inte kan skriva riktiga applikationer i. - Jag är inte beredd att helt avvisa det här påståendet.\n
Bara en liten elit av hjärnor är skapta för att programmera i erlang.\nSvårt - “vissa är helt enkelt inte intelligenta nog för att klara av det...”\nBara för eliten? Provocerande tanke.\n
Alla dessa utsagorna triggade mig.\nJag vill vara med i framtiden\nJag gillar eleganta lösningar\nProvocerad av tanken på att IQ skulle ha med saken att göra\nProvocerad av tanken på att behöva ge upp TDD i framtiden\n
Jag utser mig själv till försökskanin - kan jag lära mig så kan alla.\n
Så jag antar givetvis utmaningen - den här objektorienterade hjärnan ska maseras med lite funktionell programmering.\n
Så jag satte igång...\n
Och visst var det en lite stökig väg till en god förståelse.\nJag var inte helt förtjust i dekonstruktion med hjälp av bitsyntaxen som återfinns på sid 95 i boken.\n
\n
De jag pratat med verkar rörande överens om att FP är svårare än OO.\nÄndå envisas Erlangutvecklare med att säga att det är ett utmärkt språk att göra prototyper i...\nHur hänger det här ihop. \n
Min bild av vad det är som gör OO svårhanterat.\nMånga designpatterns bygger på att man gör avsteg från OO-idiom. \n
De som säger att det är ca. 10 mönster räknar bort de mönster som är så inflätade i språkets allmänna syntax att det blir meningslöst att prata om ett designmönster.\n
\n
Hur var det med den där matematikgrejen då?\n
\n
\n
Eftersom all iteration görs med rekursion så får man hela tiden nya variabelscope.\n
Eftersom all iteration görs med rekursion så får man hela tiden nya variabelscope.\n
\n
Men jag hittade eunit för enhetstester. Lite old-school men fungerade riktigt bra.\n\n
Fann att de dynamiska egenskaperna hos erlang tillåter isolerade tester.\nNotera också att dependency injection är en grundförutsättning för att man ska kunna arbeta utifrån och in med isolerade designtester.\n
\n
\n
\n
\n
\n
Lite utav ett annorlunda test-idiom.\n
Lite utav ett annorlunda test-idiom.\n
Däremot verkade det inte finnas något cucumberliknande verktyg för story driven development. Det fanns en lite ogenomtänkt plugin till FitNesse, men den verkade inte förvaltas aktivt.\n
Så jag bestämde mig för att göra något liknande cucumber för erlang.\n
Givetvis råkade jag genast på svårigheter.\n\n
\n
\n
I vårt kära Given-When-Then mönster så fungerar Given som skedet då systemet prepareras med data lite så som man pryder en julgran.\nSedan hänger tillståndet snällt kvar där för att kunna betraktas av vem som helst när som helst.\n
Erlang använder inte sådana julgranar, istället har de skorstenar. Den data man skickar till en erlang process försvinner bara ner i ett svart hål för en betraktares synvinkel. Sedan kan det komma något tillbaka men det är inte så att man kan betrakta någon varaktig förändring. Det är liksom hela tanken med att programmera utan sidoeffekter. Vilket fick mig att tänka.\n
Själva vanan av att dela upp systembeskrivningen i Given-When-Then skvallrar om att vi definierar våra system efter vilka sidoeffekter det har.\nVi har lutat oss så tungt mot rådande paradigmer att vi har bestämt att våra kunder ska uttrycka sig om vår programvara som att det är åtråvärt att den är full av sidoeffekter. Oops. \n
Så frågan är väl om man ska lära kunderna att se system som rena funktioner eller som objekt med sidoeffekter? Eller är den frågan ställd på fel nivå?\n
Min utgångspunkt är att kunderna inte har drivit fram Given-When-Then-konceptet. Det är vi nördar som gjort det och kunder blir inte upprörda över lite frihetsgrader på den punkten.\n
Filer, databaser, och processer. Så jag vill ju inte skapa ett verktyg som helt naivt bortser från att utvecklare vill använda sig av den möjligheten.\n
här kommer en parentes...\n
Alla IT-konferenser med självaktning idag har en talare som försöker förklara monader.\nJag har själv varit på timmslånga föreläsningar om monader som inte lyckades förklara, för mig i alla fall vad det är för någonting - ofta hamnar man i långa matematiska utläggningar som inte säger någonting om vad de gör och varför de finns.\n
Så först får ni min vän Niklas Lindströms förklaring...\n...för er som inte använder shell pipes eller kanske inte reflekterat över hur de fungerar kommer här min förklaring... \n
en process som kan ackumulera tillstånd för att senare kunna exekvera en funktion när lämpligt tillstånd uppnåtts.\nMen för att riktigt förstå dem kan det vara bra att lägga upp en på obduktionsbordet...\n
Så motivationen bakom monader är att man vill tillåta kontrollerade sidoeffekter i språk som annars inte stöder sidoeffekter. De verkar ha fått sin mystiska status genom Haskell. Allt gjort i Haskell är mystiskt.\n
För er som vill ha ett körbart exempel...\n
slutparentes...\n
Jag vet alltför väl att mina ordval inte kommer att vara de bästa därför låter jag det vara helt öppet i Cloudberry.\nDen enda konventionen just nu är att varje rad i ett scenario ger upphov till ett anrop mot en steps-modul.\n
\n
One-liners i BDD a’la FP. \n
Om man vill ta en titt genom staketet in till byggröran och kanske, rentav, hjälpa mig komma till rätta med den.\n