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
eu_categories: video review
This is a review with comments of "The Next Paradigm Shift in Programming", 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.
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" 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 gotos is applicable to
other constructs, too.
This is a very mature view, and I like how he goes beyond the
"don't use gotos" 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.
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", 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"[^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".
[^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 for C++, or ImmutableJS for JavaScript.
But functional programming is more easily achievable in languages that have them built-in, like Erlang, Elm and Clojure.
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 for JavaScript or 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.
What about declarative programming?
In "Out of the 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?
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".