Tillståndslös programmering devlin 2011
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Tillståndslös programmering devlin 2011

on

  • 731 views

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.

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.

Statistics

Views

Total Views
731
Views on SlideShare
731
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • Framtidens språk för flerkärniga processorer\n
  • \n
  • 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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Tillståndslös programmering devlin 2011 Presentation Transcript

  • 1. Tillståndslösprogrammering Erlang skådat från en överlöpare Måns Sandström, Adaptiv
  • 2. My future is so brightI got to wear shades...
  • 3. “Man behöver tänka i timmar utan att kunna skriva enrad, men när man sedan löser problemet vet man attman 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
  • 5. TDD - omöjligt!
  • 6. Före Efter
  • 7. Huh!?
  • 8. Men är det svårare än OO?
  • 9. “Absolut!” -Anonyma kollegor
  • 10. ~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
  • 11. ~10 designmönster (5 från OO-världen) Rekursion och svansrekursion Immuterbart tillstånd Monader FP i ett nöt... AckumulatorerDatastrukturer separerade från beteende Högre ordningens funktioner
  • 12. Onaturligt designtänk!Svårt att representera en verksamhet. Få designval, idiomen styr.
  • 13. Be rational! Get real! i πIf you understand the joke, I have bad news for you... Math Geek
  • 14. X=X+1
  • 15. Vadårå!?X=X+1
  • 16. Vadårå!? Omöjligt!!!X=X+1
  • 17. X2 = X + 1
  • 18. :DX2 = X + 1
  • 19. :D Behövs vanligtvis inte.X2 = X + 1
  • 20. TDD?
  • 21. Dependency injection
  • 22. Testalgoritm för rekursiv lösning1. Avslutningsvillkor2. Ankomma till avslutningsvillkoret3. Startläge
  • 23. Testalgoritm för rekursiv lösningCool! Funkar nog för mig med 1. Avslutningsvillkor 2. Ankomma till avslutningsvillkoret 3. Startläge
  • 24. Testalgoritm för rekursiv lösningCool! Funkar nog för mig med Öhh, ja. 1. Avslutningsvillkor 2. Ankomma till avslutningsvillkoret 3. Startläge
  • 25. Cloudberry
  • 26. Title (one line describing the story) Narrative:As a [role]I want [feature]So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: TitleGiven [context]  And [some more context]...When  [event]Then  [outcome]  And [another outcome]...
  • 27. Title (one line describing the story) Narrative:As a [role]I want [feature]So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: TitleGiven [context]  And [some more context]...When  [event]Then  [outcome]  And [another outcome]...
  • 28. Given
  • 29. Hoho!
  • 30. Given-When-Then är ettsidoeffektsorienterat sätt att utveckla programvara.
  • 31. Det var han som började!
  • 32. Dessutom finns detsidoeffekter i Erlang
  • 33. (
  • 34. Monader...
  • 35. 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
  • 36. 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
  • 37. )
  • 38. Därför finns inga nyckelord i Cloudberry
  • 39. Vilket också gör den oberoende av i18n
  • 40. Then = When(Given)
  • 41. git://github.com/msa/cloudberry.git
  • 42. ?
  • 43. ?
  • 44. √?
  • 45. √?
  • 46. × √ ?
  • 47. × √ ?
  • 48. × √× ?
  • 49. × √ TDD omöjligt!× ?
  • 50. × √ × TDD omöjligt!× ?
  • 51. Tack!Måns Sandström