Programming, Only Better

Recorded at:

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.

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.

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 defaultb) 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'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.