you a “natural” way to talk about and structure programs, and offers many ways to achieve polymorphism and composition • A big chunk of “software engineering” disciplines being tailored to work with this paradigm (requirements, analysis, UML, design, etc.) • History: being at the right place at the right time with the right people (?)
google “no more free lunch” and read the first article. Seriously. • Since I'm already here, I'll give you a primer: – CPU clock is not getting exponentially faster – Transistor number is still growing rapidly – No performance gain for single threaded apps – Concurrency is the next major revolution in how we write software
write software > Applications will increasingly need to be concurrent if they want to fully exploit continuing exponential CPU throughput gains > Efficiency and performance optimization will get more, not less, important
XP. Vista only in 2007. – No AWS, Twitter, Netflix. – Ruby on Rails launched in December 13th. – Youtube was just founded. – We never have heard of Justin Bieber – I was playing Gunbound & Tibia. No money for WoW.
language created in the last few years has a strong focus in making concurrent programming easier: – Scala, Clojure – Elixir – Go, Rust – The recent popularity boom of Erlang & Haskell – Kotlin, Nim, Pony, Crystal, etc...
First of all, functional programming is not a new thing • Here is a list of “functional languages” and the year they were introduced: – 1960 → Lisp – 1973 → ML – 1980s → Lazy langs: Miranda, KRC, SASL, Orwell... – 1986 → Erlang – 1990 → Haskell 1.0
There is no consensus on what actually means for a language to be “functional”. We prefer talking about “functional style”, which rely heavily on: – Functions as first class citizens – Immutability of data • These are fundamental to avoid types of race conditions
This is one of the cases where immutability makes your life easier. It will also enable the compiler/runtime to perform a lot of optimizations that are just downright impossible in languages like Java, Ruby, Python, C#, etc.
has heard the following: – Good OO design dictates that an object has a single responsibility – Good OO design dictates that an object should have few methods in its public interface – Good OO design dictates that an object limit the number of other objects it interacts with
have heard that functional programming is hard • I strongly disagree. Object systems are hard, and you don't see people whining about them • What is hard is changing your paradigm, and getting out of your comfort zone.
lot in writing concurrent software, it is by no means limited to this. • Many design patterns common to object oriented languages are downright irrelevant with functional languages • Many problems are much better described in functional idioms (google for “the expression problem”)
a great to organize and structure programs that must react to user input. Check out Elm for a conundrum of amazing ideas. • You don't need to abandon OO to use functional programming: Scala, C#, F# and many others let you mix and match according to your tastes.
Actor systems, software transactional memory, persistent data structures, parser combinators, etc where popularized and “discovered” in the functional community • There is a lot of nice things happening out there. • Get out of your box
Take Prof. Dan Grossman's “Programming Languages” course on Coursera • Take Martin Odersky's “Functional programming principles in Scala” course on Coursera • Take Erik Meijer's “Functional programming” course on Edx. • … learn Haskell • … write your own Lisp interpreter