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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
#
msgid ""
msgstr ""
msgid "title: The Next Paradigm Shift in Programming - video review"
msgstr ""
msgid "date: 2020-11-08"
msgstr ""
msgid "layout: post"
msgstr ""
msgid "lang: en"
msgstr ""
msgid "ref: the-next-paradigm-shift-in-programming-video-review"
msgstr ""
msgid "category: video review"
msgstr ""
msgid ""
"This is a review with comments of \"[The Next Paradigm Shift in "
"Programming](https://www.youtube.com/watch?v=6YbK8o9rZfI)\", by Richard "
"Feldman."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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."
msgstr ""
msgid "Structured programming"
msgstr ""
msgid ""
"The historical overview at the beginning is very good. In fact, the very "
"video I watched previously was about structured programming!"
msgstr ""
msgid ""
"Kevlin Henney on \"[The Forgotten Art of Structured "
"Programming](https://www.youtube.com/watch?v=SFv8Wm2HdNM)\" 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."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"In a few minutes, Richard is able to condense most of the significant bits "
"of Kevlin's talk in a didactical way. Good job."
msgstr ""
msgid "OOP like a distributed system"
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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](https://www.infoq.com/interviews/johnson-armstrong-oop/)\", since "
"it actually adopted this paradigm."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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](https://www.youtube.com/watch?v=ROor6_NGIWU)\"[^the-language-of-the-"
"system])."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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\"."
msgstr ""
msgid "[^the-language-of-the-system]: From 24:05 to 27:45."
msgstr ""
msgid "First class immutability"
msgstr ""
msgid ""
"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\"."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"There are some languages with third-party libraries that provide functional "
"data structures, like [immer](https://sinusoid.es/immer/) for C++, or "
"[ImmutableJS](https://immutable-js.github.io/immutable-js/) for JavaScript."
msgstr ""
msgid ""
"But functional programming is more easily achievable in languages that have "
"them built-in, like Erlang, Elm and Clojure."
msgstr ""
msgid "Managed side-effects"
msgstr ""
msgid ""
"His proposal of adopting managed side-effects as a first-class language "
"concept is really intriguing."
msgstr ""
msgid ""
"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."
msgstr ""
msgid "What about declarative programming?"
msgstr ""
msgid "Conclusion"
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"Rich Hickey makes a great case for single-process FP on his famous talk "
"\"[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-"
"Easy/)\"."
msgstr ""
msgid ""
"This is something you can achieve with a library, like "
"[Redux](https://redux.js.org/) for JavaScript or [re-"
"frame](https://github.com/Day8/re-frame) for Clojure."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"In \"[Out of the Tar "
"Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\", 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."
msgstr ""
msgid ""
"If the next paradigm shift is towards functional programming, will the "
"following shift be towards declarative programming?"
msgstr ""
#~ msgid ""
#~ "This is something you can achieve with a library, like "
#~ "[Redux](https://redux.js.org/) for JavaScript or re-frame for Clojure."
#~ msgstr ""
#~ msgid ""
#~ "Also all languages with managed side-effects I know are statically-typed, "
#~ "and all dynamically-typed languages I know don't have managed side-effects "
#~ "baked in."
#~ msgstr ""
#~ msgid ""
#~ "\"[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\" "
#~ "by B. Moseley and P. Marks goes beyond his view of functional programming, "
#~ "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."
#~ msgstr ""
#~ msgid ""
#~ "If functional programming is the next paradigm shift, is declarative "
#~ "programming the next next paradigm shift?"
#~ msgstr ""
|
