1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
---
title: The Next Paradigm Shift in Programming - video review
date: 2020-11-08
layout: post
lang: en
ref: the-next-paradigm-shift-in-programming-video-review
category: video review
---
This is a review with comments of
"[The Next Paradigm Shift in Programming][video-link]", by Richard Feldman.
This video was *strongly* suggested to me by a colleague. I wanted to discuss it
with her, and when drafting my response I figured I could publish it publicly
instead.
Before anything else, let me just be clear: I really like the talk, and I think
Richard is a great public speaker. I've watched several of his talks over the
years, and I feel I've followed his career at a distance, with much respect.
This isn't a piece criticizing him personally, and I agree with almost
everything he said. These are just some comments but also nitpicks on a few
topics I think he missed, or that I view differently.
[video-link]: https://www.youtube.com/watch?v=6YbK8o9rZfI
## Structured programming
The historical overview at the beginning is very good. In fact, the very video I
watched previously was about structured programming!
Kevlin Henney on
"[The Forgotten Art of Structured Programming][structured-programming]" does a
deep-dive on the topic of structured programming, and how on his view it is
still hidden in our code, when we do a `continue` or a `break` in some ways.
Even though it is less common to see an explicit `goto` in code these days, many
of the original arguments of Dijkstra against explicit `goto`s is applicable to
other constructs, too.
This is a very mature view, and I like how he goes beyond the
"don't use `goto`s" heuristic and proposes and a much more nuanced understanding
of what "structured programming" means.
In a few minutes, Richard is able to condense most of the significant bits of
Kevlin's talk in a didactical way. Good job.
[structured-programming]: https://www.youtube.com/watch?v=SFv8Wm2HdNM
## OOP like a distributed system
Richard extrapolates Alan Kay's original vision of OOP, and he concludes that
it is more like a distributed system that how people think about OOP these days.
But he then states that this is a rather bad idea, and we shouldn't pursue it,
given that distributed systems are known to be hard.
However, his extrapolation isn't really impossible, bad or an absurd. In fact,
it has been followed through by Erlang. Joe Armstrong used to say that
"[Erlang might the only OOP language][erlang-oop]", since it actually adopted
this paradigm.
But Erlang is a functional language. So this "OOP as a distributed system" view
is more about designing systems in the large than programs in the small.
There is a switch of levels in this comparison I'm making, as can be done with
any language or paradigm: you can have a functional-like system that is built
with an OOP language (like a compiler, that given the same input will produce
the same output), or an OOP-like system that is built with a functional language
(Rich Hickey calls it
"[OOP in the large][langsys]"[^the-language-of-the-system]).
So this jump from in-process paradigm to distributed paradigm is rather a big
one, and I don't think you he can argue that OOP has anything to say about
software distribution across nodes. You can still have Erlang actors that run
independently and send messages to each other without a network between them.
Any OTP application deployed on a single node effectively works like that.
I think he went a bit too far with this extrapolation. Even though I agree it is
a logical a fair one, it isn't evidently bad as he painted. I would be fine
working with a single-node OTP application and seeing someone call it "a *real*
OOP program".
[erlang-oop]: https://www.infoq.com/interviews/johnson-armstrong-oop/
[langsys]: https://www.youtube.com/watch?v=ROor6_NGIWU
[^the-language-of-the-system]: From 24:05 to 27:45.
## First class immutability
I agree with his view of languages moving towards the functional paradigm.
But I think you can narrow down the "first-class immutability" feature he points
out as present on modern functional programming languages to "first-class
immutable data structures".
I wouldn't categorize a language as "supporting functional programming style"
without a library for functional data structures it. By discipline you can avoid
side-effects, write pure functions as much as possible, and pass functions as
arguments around is almost every language these days, but if when changing an
element of a vector mutates things in-place, that is still not functional
programming.
To avoid that, you end-up needing to make clones of objects to pass to a
function, using freezes or other workarounds. All those cases are when the
underlying mix of OOP and functional programming fail.
There are some languages with third-party libraries that provide functional data
structures, like [immer][immer] for C++, or [ImmutableJS][immutablejs] for
JavaScript.
But functional programming is more easily achievable in languages that have them
built-in, like Erlang, Elm and Clojure.
[immer]: https://sinusoid.es/immer/
[immutablejs]: https://immutable-js.github.io/immutable-js/
## Managed side-effects
His proposal of adopting managed side-effects as a first-class language concept
is really intriguing.
This is something you can achieve with a library, like [Redux][redux] for JavaScript or
[re-frame][re-frame] for Clojure.
I haven't worked with a language with managed side-effects at scale, and I don't
feel this is a problem with Clojure or Erlang. But is this me finding a flaw in
his argument or not acknowledging a benefit unknown to me? This is a provocative
question I ask myself.
Also all FP languages with managed side-effects I know are statically-typed, and
all dynamically-typed FP languages I know don't have managed side-effects baked in.
[redux]: https://redux.js.org/
[re-frame]: https://github.com/Day8/re-frame
## What about declarative programming?
In "[Out of the Tar Pit][tar-pit]", B. Moseley and P. Marks go beyond his view
of functional programming as the basis, and name a possible "functional
relational programming" as an even better solution. They explicitly call out
some flaws in most of the modern functional programming languages, and instead
pick declarative programming as an even better starting paradigm.
If the next paradigm shift is towards functional programming, will the following
shift be towards declarative programming?
[tar-pit]: http://curtclifton.net/papers/MoseleyMarks06a.pdf
## Conclusion
Beyond all Richard said, I also hear often bring up functional programming when
talking about utilizing all cores of a computer, and how FP can help with that.
Rich Hickey makes a great case for single-process FP on his famous talk
"[Simple Made Easy][simple-made-easy]".
[simple-made-easy]: https://www.infoq.com/presentations/Simple-Made-Easy/
|
