diff options
Diffstat (limited to 'src/content/blog/2020/11/08')
| -rw-r--r-- | src/content/blog/2020/11/08/paradigm-shift-review.adoc | 154 |
1 files changed, 0 insertions, 154 deletions
diff --git a/src/content/blog/2020/11/08/paradigm-shift-review.adoc b/src/content/blog/2020/11/08/paradigm-shift-review.adoc deleted file mode 100644 index 1110085..0000000 --- a/src/content/blog/2020/11/08/paradigm-shift-review.adoc +++ /dev/null @@ -1,154 +0,0 @@ -= 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. -//// |