= The Next Paradigm Shift in Programming - video review

:reviewed-video: https://www.youtube.com/watch?v=6YbK8o9rZfI

This is a review with comments of "{reviewed-video}[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

:forgotten-art-video: https://www.youtube.com/watch?v=SFv8Wm2HdNM

The historical overview at the beginning is very good.  In fact, the very video
I watched previously was about structured programming!

Kevlin Henney on "{forgotten-art-video}[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 `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.

== OOP like a distributed system

:joe-oop: https://www.infoq.com/interviews/johnson-armstrong-oop/
:rich-hickey-oop: https://www.youtube.com/watch?v=ROor6_NGIWU

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
"{joe-oop}[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 "{rich-hickey-oop}[OOP in the
large]"footnote:langsys[
  From 24:05 to 27:45.
]).

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".

== First class immutability

:immer: https://sinusoid.es/immer/
:immutable-js: https://immutable-js.github.io/immutable-js/

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 {immutable-js}[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

:redux: https://redux.js.org/
:re-frame: https://github.com/Day8/re-frame

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.

== What about declarative programming?

:tarpit-article: https://curtclifton.net/papers/MoseleyMarks06a.pdf

In "{tarpit-article}[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

:simple-made-easy: https://www.infoq.com/presentations/Simple-Made-Easy/

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]".

////
I find this conclusion too short, and it doesn't revisits the main points
presented on the body of the article.  I won't rewrite it now, but it would be
an improvement to extend it to do so.
////
