InfoQ Homepage Presentations Programming, Only Better
Programming, Only Better
Summary
Bodil Stokke keynotes on the FP languages for writing bug free, fault tolerant code that help building simple, concurrent and reusable software.
Bio
Bodil Stokke (@bodil) is a compulsive conference speaker in the fields of functional programming and internets technologies, and is a co-organizer of multiple developer conferences in Scandinavia and the UK, mostly because she’s still learning how to stop. She is a prolific contributor to the Free Software community. In her spare time, she works as a developer for Future Ad Labs.
About the conference
Now in its 3rd year, FP Days brings together the best speakers on Clojure, Haskell, Erlang, F#, OCaml and Scala for 2 days of intense, practical learning and shared experiences. Whether you're an FP beginner or a seasoned practitioner you're welcome to participate, meet your peers and have fun.
Community comments
Nice Talk - hope it gets good viewership
by Faisal Waris,
I liked the talk, but ...
by Pedro Henrique Antunes de Oliv...,
Not that good as title shows us...
by Wong Richard,
What tool is she using?
by Charles Szilagyi,
Nice Talk - hope it gets good viewership
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
As programmers our greatest enemy is complexity. Even minor increments in requirements can result in state-space explosion. This is something we need to consciously confront.
In my experience, the following two features - found in most current FP languages - help enormously:
a) Immutability by default
b) Pattern matching
Immutability is already well understood.
Pattern matching allows us to express complex decisions in concise and very readable way. You can really only appreciate this after you have worked with it for a while.
I am most familiar with the F# language and I can attest that Pattern Matching has come to rescue many many times. The ML family (which F# is part of) leverages type checking in pattern matching to assist the programmer in making sure all cases are considered.
I liked the talk, but ...
by Pedro Henrique Antunes de Oliv...,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've watched the Rich Hickey speech she mentioned in the beginning. I may be "seeing things", but I get the feeling she somewhat misunderstood it.
Rich Hickey, if I got it right, wasn't saying he doesn't or you shouldn't do TDD. What he said is that it isn't TDD which gives you the flexibility to software changeability and lots of the abilities "promised" in several of the TDD talks out there. And the hammock time wasn't about thinking through your whole software system before starting to code it. He simply said that you should spend some time thinking about what you're doing before you jump into design decisions which could damage you in the future.
Not that good as title shows us...
by Wong Richard,
Your message is awaiting moderation. Thank you for participating in the discussion.
ONLY a few points worth notice.(complexity section)
But too many intro and quotations.
What tool is she using?
by Charles Szilagyi,
Your message is awaiting moderation. Thank you for participating in the discussion.
At 0:23 some live coding is shown, can anyone tell which ide/tool is used so code output is printed below function calls, etc?