diff options
6 files changed, 905 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/ diff --git a/locale/eo/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po b/locale/eo/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po new file mode 100644 index 0000000..70ea4e6 --- /dev/null +++ b/locale/eo/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po @@ -0,0 +1,245 @@ +# +msgid "" +msgstr "" + +msgid "title: The Next Paradigm Shift in Programming - video review" +msgstr "" + +msgid "date: 2020-11-08" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: the-next-paradigm-shift-in-programming-video-review" +msgstr "" + +msgid "category: video review" +msgstr "" + +msgid "" +"This is a review with comments of \"[The Next Paradigm Shift in " +"Programming](https://www.youtube.com/watch?v=6YbK8o9rZfI)\", by Richard " +"Feldman." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "Structured programming" +msgstr "" + +msgid "" +"The historical overview at the beginning is very good. In fact, the very " +"video I watched previously was about structured programming!" +msgstr "" + +msgid "" +"Kevlin Henney on \"[The Forgotten Art of Structured " +"Programming](https://www.youtube.com/watch?v=SFv8Wm2HdNM)\" 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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In a few minutes, Richard is able to condense most of the significant bits " +"of Kevlin's talk in a didactical way. Good job." +msgstr "" + +msgid "OOP like a distributed system" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.infoq.com/interviews/johnson-armstrong-oop/)\", since " +"it actually adopted this paradigm." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.youtube.com/watch?v=ROor6_NGIWU)\"[^the-language-of-the-" +"system])." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "[^the-language-of-the-system]: From 24:05 to 27:45." +msgstr "" + +msgid "First class immutability" +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"There are some languages with third-party libraries that provide functional " +"data structures, like [immer](https://sinusoid.es/immer/) for C++, or " +"[ImmutableJS](https://immutable-js.github.io/immutable-js/) for JavaScript." +msgstr "" + +msgid "" +"But functional programming is more easily achievable in languages that have " +"them built-in, like Erlang, Elm and Clojure." +msgstr "" + +msgid "Managed side-effects" +msgstr "" + +msgid "" +"His proposal of adopting managed side-effects as a first-class language " +"concept is really intriguing." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "What about declarative programming?" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"Rich Hickey makes a great case for single-process FP on his famous talk " +"\"[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-" +"Easy/)\"." +msgstr "" + +msgid "" +"This is something you can achieve with a library, like " +"[Redux](https://redux.js.org/) for JavaScript or [re-" +"frame](https://github.com/Day8/re-frame) for Clojure." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In \"[Out of the Tar " +"Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\", 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." +msgstr "" + +msgid "" +"If the next paradigm shift is towards functional programming, will the " +"following shift be towards declarative programming?" +msgstr "" + +#~ msgid "" +#~ "This is something you can achieve with a library, like " +#~ "[Redux](https://redux.js.org/) for JavaScript or re-frame for Clojure." +#~ msgstr "" + +#~ msgid "" +#~ "Also all languages with managed side-effects I know are statically-typed, " +#~ "and all dynamically-typed languages I know don't have managed side-effects " +#~ "baked in." +#~ msgstr "" + +#~ msgid "" +#~ "\"[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\" " +#~ "by B. Moseley and P. Marks goes beyond his view of functional programming, " +#~ "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." +#~ msgstr "" + +#~ msgid "" +#~ "If functional programming is the next paradigm shift, is declarative " +#~ "programming the next next paradigm shift?" +#~ msgstr "" diff --git a/locale/fr/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po b/locale/fr/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po new file mode 100644 index 0000000..70ea4e6 --- /dev/null +++ b/locale/fr/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po @@ -0,0 +1,245 @@ +# +msgid "" +msgstr "" + +msgid "title: The Next Paradigm Shift in Programming - video review" +msgstr "" + +msgid "date: 2020-11-08" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: the-next-paradigm-shift-in-programming-video-review" +msgstr "" + +msgid "category: video review" +msgstr "" + +msgid "" +"This is a review with comments of \"[The Next Paradigm Shift in " +"Programming](https://www.youtube.com/watch?v=6YbK8o9rZfI)\", by Richard " +"Feldman." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "Structured programming" +msgstr "" + +msgid "" +"The historical overview at the beginning is very good. In fact, the very " +"video I watched previously was about structured programming!" +msgstr "" + +msgid "" +"Kevlin Henney on \"[The Forgotten Art of Structured " +"Programming](https://www.youtube.com/watch?v=SFv8Wm2HdNM)\" 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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In a few minutes, Richard is able to condense most of the significant bits " +"of Kevlin's talk in a didactical way. Good job." +msgstr "" + +msgid "OOP like a distributed system" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.infoq.com/interviews/johnson-armstrong-oop/)\", since " +"it actually adopted this paradigm." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.youtube.com/watch?v=ROor6_NGIWU)\"[^the-language-of-the-" +"system])." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "[^the-language-of-the-system]: From 24:05 to 27:45." +msgstr "" + +msgid "First class immutability" +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"There are some languages with third-party libraries that provide functional " +"data structures, like [immer](https://sinusoid.es/immer/) for C++, or " +"[ImmutableJS](https://immutable-js.github.io/immutable-js/) for JavaScript." +msgstr "" + +msgid "" +"But functional programming is more easily achievable in languages that have " +"them built-in, like Erlang, Elm and Clojure." +msgstr "" + +msgid "Managed side-effects" +msgstr "" + +msgid "" +"His proposal of adopting managed side-effects as a first-class language " +"concept is really intriguing." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "What about declarative programming?" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"Rich Hickey makes a great case for single-process FP on his famous talk " +"\"[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-" +"Easy/)\"." +msgstr "" + +msgid "" +"This is something you can achieve with a library, like " +"[Redux](https://redux.js.org/) for JavaScript or [re-" +"frame](https://github.com/Day8/re-frame) for Clojure." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In \"[Out of the Tar " +"Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\", 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." +msgstr "" + +msgid "" +"If the next paradigm shift is towards functional programming, will the " +"following shift be towards declarative programming?" +msgstr "" + +#~ msgid "" +#~ "This is something you can achieve with a library, like " +#~ "[Redux](https://redux.js.org/) for JavaScript or re-frame for Clojure." +#~ msgstr "" + +#~ msgid "" +#~ "Also all languages with managed side-effects I know are statically-typed, " +#~ "and all dynamically-typed languages I know don't have managed side-effects " +#~ "baked in." +#~ msgstr "" + +#~ msgid "" +#~ "\"[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\" " +#~ "by B. Moseley and P. Marks goes beyond his view of functional programming, " +#~ "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." +#~ msgstr "" + +#~ msgid "" +#~ "If functional programming is the next paradigm shift, is declarative " +#~ "programming the next next paradigm shift?" +#~ msgstr "" diff --git a/locale/pt/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po b/locale/pt/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po new file mode 100644 index 0000000..70ea4e6 --- /dev/null +++ b/locale/pt/LC_MESSAGES/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.po @@ -0,0 +1,245 @@ +# +msgid "" +msgstr "" + +msgid "title: The Next Paradigm Shift in Programming - video review" +msgstr "" + +msgid "date: 2020-11-08" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: the-next-paradigm-shift-in-programming-video-review" +msgstr "" + +msgid "category: video review" +msgstr "" + +msgid "" +"This is a review with comments of \"[The Next Paradigm Shift in " +"Programming](https://www.youtube.com/watch?v=6YbK8o9rZfI)\", by Richard " +"Feldman." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "Structured programming" +msgstr "" + +msgid "" +"The historical overview at the beginning is very good. In fact, the very " +"video I watched previously was about structured programming!" +msgstr "" + +msgid "" +"Kevlin Henney on \"[The Forgotten Art of Structured " +"Programming](https://www.youtube.com/watch?v=SFv8Wm2HdNM)\" 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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In a few minutes, Richard is able to condense most of the significant bits " +"of Kevlin's talk in a didactical way. Good job." +msgstr "" + +msgid "OOP like a distributed system" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.infoq.com/interviews/johnson-armstrong-oop/)\", since " +"it actually adopted this paradigm." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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](https://www.youtube.com/watch?v=ROor6_NGIWU)\"[^the-language-of-the-" +"system])." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "[^the-language-of-the-system]: From 24:05 to 27:45." +msgstr "" + +msgid "First class immutability" +msgstr "" + +msgid "" +"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\"." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"There are some languages with third-party libraries that provide functional " +"data structures, like [immer](https://sinusoid.es/immer/) for C++, or " +"[ImmutableJS](https://immutable-js.github.io/immutable-js/) for JavaScript." +msgstr "" + +msgid "" +"But functional programming is more easily achievable in languages that have " +"them built-in, like Erlang, Elm and Clojure." +msgstr "" + +msgid "Managed side-effects" +msgstr "" + +msgid "" +"His proposal of adopting managed side-effects as a first-class language " +"concept is really intriguing." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "What about declarative programming?" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"Rich Hickey makes a great case for single-process FP on his famous talk " +"\"[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-" +"Easy/)\"." +msgstr "" + +msgid "" +"This is something you can achieve with a library, like " +"[Redux](https://redux.js.org/) for JavaScript or [re-" +"frame](https://github.com/Day8/re-frame) for Clojure." +msgstr "" + +msgid "" +"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." +msgstr "" + +msgid "" +"In \"[Out of the Tar " +"Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\", 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." +msgstr "" + +msgid "" +"If the next paradigm shift is towards functional programming, will the " +"following shift be towards declarative programming?" +msgstr "" + +#~ msgid "" +#~ "This is something you can achieve with a library, like " +#~ "[Redux](https://redux.js.org/) for JavaScript or re-frame for Clojure." +#~ msgstr "" + +#~ msgid "" +#~ "Also all languages with managed side-effects I know are statically-typed, " +#~ "and all dynamically-typed languages I know don't have managed side-effects " +#~ "baked in." +#~ msgstr "" + +#~ msgid "" +#~ "\"[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf)\" " +#~ "by B. Moseley and P. Marks goes beyond his view of functional programming, " +#~ "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." +#~ msgstr "" + +#~ msgid "" +#~ "If functional programming is the next paradigm shift, is declarative " +#~ "programming the next next paradigm shift?" +#~ msgstr "" diff --git a/scripts/spelling/en.txt b/scripts/spelling/en.txt index 2d9584f..f05298c 100644 --- a/scripts/spelling/en.txt +++ b/scripts/spelling/en.txt @@ -18,6 +18,7 @@ declaratively decrypting definitionally demoer +didactical didn differentiator doesn diff --git a/scripts/spelling/international.txt b/scripts/spelling/international.txt index 4b5bc4d..7af1b73 100644 --- a/scripts/spelling/international.txt +++ b/scripts/spelling/international.txt @@ -31,8 +31,10 @@ Datomic EuAndreh F FFI +FP FTS Fastmail +Feldman Forsgren GADTs GTK @@ -45,13 +47,16 @@ HTML HTTPS Halloway Haskell +Henney Hodgson I IPs +ImmutableJS IndexedDB JS JSON Joyent +Kevlin L1 LTS LaTeX @@ -65,6 +70,8 @@ Merkle NPM Nextcloud NixOS +OOP +OTP POSIX Pastebin Pittet @@ -74,6 +81,7 @@ RPN RSS Raku Reddit +Redux SA SSD Slava @@ -131,6 +139,7 @@ https i5 i7 ify +immer intbytes ios ish |