git mv src/content/* src/content/en/

1 files changed, 154 insertions, 0 deletions

diff --git a/src/content/en/blog/2020/11/08/paradigm-shift-review.adoc b/src/content/en/blog/2020/11/08/paradigm-shift-review.adoc
new file mode 100644
index 0000000..1110085
--- /dev/null
+++ b/src/content/en/blog/2020/11/08/paradigm-shift-review.adoc
@@ -0,0 +1,154 @@
+= The Next Paradigm Shift in Programming - video review
+:categories: 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.
+////