Add next paradigm article

1 files changed, 160 insertions, 0 deletions

diff --git a/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.md b/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.md
new file mode 100644
index 0000000..ff9be5a
--- /dev/null
+++ b/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.md
@@ -0,0 +1,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/