The document discusses the limitations of tools in functional programming and emphasizes the importance of skilled designers over technology alone for productivity and reliability. It argues against the concept of 'mostly functional programming' due to the inherent complications of side effects and advocates for a shift towards purely functional programming practices as a means to achieve significant benefits. Additionally, it highlights the need to move past reliance on side effects, positioning functional programming as the preferred future direction.

1. No Silver Bullets in
Functional Programming

2. Brian McKenna
Atlassian
Almost always functional programming
Australia

3. There's no such thing as a silver bullet...

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.

6. Fred Brooks' experience as of 1986:
No 10x tools
But 10x programmers

7. 1. No tool will fix all productivity/reliability/simplicity problems
2. No tool strictly better than another

8. Availability vs consistency

9. Space vs time

10. Git vs Mercurial

11. Emacs vs Vim

12. YAML vs JSON

14. Functional programming

15. (10 + 30) * 2
40 * 2
80

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.

17. Reuse

18. println("Hello");
println("World");
println("Hello");
println("World");

19. val x = {
println("Hello");
println("World");
};
x;
x;

20. Refactoring

21. bind(getCredentialsProvider, credentials => {
val regions = Regions.fromName(streamRegion);
val config = makeClientConfiguration(regions);
val client = kinesis(credentials, config, regions);
val proxy = kinesisProxy(credentials, client);
getShardList(proxy);
});

22. val regions = Regions.fromName(streamRegion);
val config = makeClientConfiguration(regions);
bind(getCredentialsProvider, credentials => {
val client = kinesis(credentials, config, regions);
val proxy = kinesisProxy(credentials, client);
getShardList(proxy);
});

23. Equational reasoning

24. def traverse[A](l: List[A], f: A => IO[Unit]) =
l.foldRight(
(a, acc) =>
bind(
f(a),
_ => acc
),
point(unit)
);
traverse(["Hello", "World"], println);

25. ["Hello", "World"].foldRight(
(a, acc) =>
bind(
println(a),
_ => acc
),
point(unit)
);

26. bind(
println("Hello"),
_ =>
["World"].foldRight(
(a, acc) =>
bind(
println(a),
_ => acc
),
point(unit)
)
);

27. bind(
println("Hello"),
_ =>
bind(
println("World"),
_ =>
[].foldRight(
(a, acc) =>
bind(
println(a),
_ => acc
),
point(unit)
)
)
);

28. bind(
println("Hello"),
_ =>
bind(
println("World"),
_ => point(unit)
)
);

29. bind(
println("Hello"),
_ =>
println("World")
);

30. println("Hello");
println("World");

31. Some benefits for humans:
Reuse
Refactoring
Equational reasoning

32. Compare the alternatives

33. Functional programming
Imperative programming
Object-oriented programming

34. Functional programming
Imperative programming
Object-oriented programming

35. In short, Haskell is the world's finest imperative programming
language.
Simon Peyton Jones, 2000

36. Functional programming
Not functional programming

37. Values
Side-effects

38. Benefits of side-effects

40. Argument to moderation

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

42. Middle-ground between a lie and the truth is a lie.

43. Middle-ground between a side-effect and a value is a side-effect.

44. Tooling

45. In theory, functional programming only has benefits.
In practice, tools have trade-offs.

46. type Effect[a]
= WriteLine String a
| ReadLine (String -> a)

47. program = {
writeLine("Hello, what's your name?");
s <- readLine
writeLine("Hello " + s);
};

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.

50. Success

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.