We are constantly presented with trade-offs when writing software. What are the trade-offs when applying functional programming? What costs arise? When is it not worth doing? When should pragmatism kick in and when should we start using side-effects?
This talk will give you some tools to be able to answer the above questions for both functional programming and types. The tools have been refined over many professional years of both doing and not doing purely functional programming.
More details: https://confengine.com/functional-conf-2016/proposal/3137/no-silver-bullets-in-functional-programming
4. ... there is no single development, in either technology or
management technique, which by itself promises even one order
of magnitude improvement within a decade in productivity, in
reliability, in simplicity.
...
Hence, although I strongly support the technology transfer and
curriculum development efforts now underway, I think the most
important single effort we can mount is to develop ways to grow
great designers.
Fred Brooks, 1986
5. The differences are not minor - it is rather like Salieri and Mozart.
Study after study shows that the very best designers produce
structures that are faster, smaller, simpler, cleaner and produced
with less effort. The difference between the great and the
average approach is an order of magnitude.
16. Referentially transparent expressions can be replaced with the
value that they evaluate to.
Functions are a way of creating referentially transparent
expressions.
Functional programming is programming with referentially
transparent expressions.
41. "Mostly functional" programming does not work.
...
The idea of "mostly functional programming" is unfeasible. It is
impossible to make imperative programming languages safer by
only partially removing implicit side effects. Leaving one kind of
effect is often enough to simulate the very effect you just tried to
remove. On the other hand, allowing effects to be "forgotten" in a
pure language also causes mayhem in its own way.
Erik Meijer, 2014
48. blink :: Atom ()
blink = do
on <- bool "on" True
period timeout . atom "blinkOn" $ do
call "avr_blink"
on <== not_ (value on)
49. Sunk cost
We have invested a lot of time and effort into using side-effects.
We have received no inherent benefit over functional programming.
We need to beware of putting any more effort into side-effects.
51. Shift the conversation:
We already do functional programming.
If you want to use side-effects, the burden of justification is on you.
52. Don't fall into the "everything is about trade-offs" trap:
Functional programming gives significant benefits over side-effects.
Side-effects give zero benefits over functional programming.
53. We should consider side-effects to be legacy.
Functional programming should be our future.