From 570ec471d1605318aeefb030cd78682ae442235b Mon Sep 17 00:00:00 2001
From: EuAndreh <eu@euandre.org>
Date: Mon, 31 Mar 2025 21:51:40 -0300
Subject: src/content/: Update all files left to asciidoc

---
 .../blog/2020/11/08/paradigm-shift-review.adoc     | 163 ++++++++++-----------
 1 file changed, 76 insertions(+), 87 deletions(-)

(limited to 'src/content/blog/2020/11/08/paradigm-shift-review.adoc')

diff --git a/src/content/blog/2020/11/08/paradigm-shift-review.adoc b/src/content/blog/2020/11/08/paradigm-shift-review.adoc
index c98c131..dd31f87 100644
--- a/src/content/blog/2020/11/08/paradigm-shift-review.adoc
+++ b/src/content/blog/2020/11/08/paradigm-shift-review.adoc
@@ -1,164 +1,153 @@
----
+= The Next Paradigm Shift in Programming - video review
 
-title: The Next Paradigm Shift in Programming - video review
+:reviewed-video: https://www.youtube.com/watch?v=6YbK8o9rZfI
 
-date: 2020-11-08
+This is a review with comments of "{reviewed-video}[The Next Paradigm Shift in
+Programming]", by Richard Feldman.
 
-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][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
+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
+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
+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
 
-## 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!
+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.
+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.
+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.
+Kevlin's talk in a didactical way.  Good job.
 
-[structured-programming]: https://www.youtube.com/watch?v=SFv8Wm2HdNM
+== OOP like a distributed system
 
-## 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.
+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.
+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
+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]).
+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
+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*
+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
 
-## 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 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
+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
+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
+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.
 
-[immer]: https://sinusoid.es/immer/
-[immutablejs]: https://immutable-js.github.io/immutable-js/
+== Managed side-effects
 
-## 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.
+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.
+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.
+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?
 
-## What about declarative programming?
+:tarpit-article: https://curtclifton.net/papers/MoseleyMarks06a.pdf
 
-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
+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?
 
-[tar-pit]: http://curtclifton.net/papers/MoseleyMarks06a.pdf
+== Conclusion
 
-## 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]".
-
-[simple-made-easy]: https://www.infoq.com/presentations/Simple-Made-Easy/
+"{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. -->
+////
+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.
+////
-- 
cgit v1.2.3

