11 ms·

Classification of the Principal Programming Paradigms (2009)

116 points by deepaksurti 7y ago

chalst 7y ago
This should be marked as dating from 2009. There was a discussion of an earlier iteration of the poster on Lambda the Ultimate, where Van Roy defended some of the choices he made. http://lambda-the-ultimate.org/node/2410 http://lambda-the-ultimate.org/node/2410
riffraff 7y ago
FWIW, the linked book, "Concepts, Techniques, and Models of Computer Programming"(CTM), is imo a fantastic book, and there are free classes on edX ("Paradigms of Computer Programming", I think it's now split in two now) that go over the material. Highly recommended if you have an interest in this stuff.
- mesaframe 7y ago
  I gave it a skim and from that what I could conclude was that it focuses a lot on concurrent operations. Which I don't think comes to everyone's use.
  - naasking 7y ago
    Integrating concurrency with mutability is a tough problem, and concurrency is becoming increasingly important.
    - mesaframe 7y ago
      It has always been important but again not for everyone. I would like a similar treatise but for synchronous single threaded operations.
  - spinningslate 7y ago
    > it focuses a lot on concurrent operations It does but not to the exclusion of other computation models. I'd agree with GP - I found it a wonderful book. It builds different models of computation successively by incrementally adding features. It's a bit like SICP[0] in that it starts with declarative/functional fundamentals and brings in mutable state really late. The coverage of dataflow was the first one that gave me an "aha!" moment. It's easily 10 years since I bought it and I still dip into it every few months or so. Every time I do, I get something new: insights, deeper understanding, etc. Really wonderful book. [0] https://sicpebook.wordpress.com/ https://sicpebook.wordpress.com/
  - riffraff 7y ago
    Yes, I think concurrency is about 1/3 of the book, but it's approached the same way as the other paradigms; you have a basic language, add a single feature and see what happens: what new things can you do? How does the expressivity change? What problems arise? Is this equivalent to another paradigm? I found the insights interesting, but I would agree they are not of immediate utility to many people's day job.
- chubot 7y ago
  As far as I remember one of the main ideas was "dataflow variables", which are lazily evaluated in parallel (?) I've read about this paradigm in the literature, e.g. with the Lucid language and others. And the book goes into some depth about it. But somehow this paradigm hasn't caught on, despite the constant production of new experimental languages. And I've never seen a real program in it -- e.g. one over 5K lines that people use. Anyone have a conjecture on what happened? Is it flawed, or did nobody pay enough attention? I think there is some overlap with async/await which seems to be the dominant concurrency paradigm now (C#, JS, Python, Rust, etc.) I think one issue is that real systems are composed of multiple languages, and it's hard to bridge programs with wildly different evaluation semantics with C or JavaScript code. And I guess the paradigm is not "reactive". It wants to control the main loop, but in GUIs and networking code where async/await is appropriate, the app doesn't "own" the thread of control. A new paradigm for batch programs is perhaps of limited use. I guess I sort of answered my own question -- the model doesn't solve enough problems to justify its cost. (Also, another issue is that it's a model of very fine-grained parallelism, where as coarse-grained parallelism with limited communication is faster. That's how people optimize in practice.) I'm interested in any contrary opinions though.
  - snovv_crash 7y ago
    I worked with LabView enough to have an opinion, I think. The issue is that it isn't actually any easier or faster. The machine still needs to do the same synchronizations and cache invalidations. The engineer becomes very limited in what they can effectively do (recursive structures? They become like {} in Go, performance nightmares). Labview is very effective in its niche, factory monitoring and automation, but I found beyond that it was a pain and a half.
    - dkersten 7y ago
      > Labview is very effective in its niche, factory monitoring and automation, but I found beyond that it was a pain and a half. I’ve never used Labview but it’s worth pointing out that it’s only one possible implementation, just like we have many different takes on other paradigms. I’ve heard people say that labviews specific design is somewhat flawed, but I can’t comment on that since I’ve not used it myself.
- dkersten 7y ago
  What I found quite interesting, when I read CTM a few years back, was that they only introduced mutable state about half way through. That you could talk about all of these different aspects of programming before introducing mutable state was pretty enlightening.
chroem- 7y ago
Correct me if I'm wrong, but this seems to be missing array programming (APL, Matlab, Julia, etc).
- lebuffon 7y ago
  And I can't see concatenative programming languages. https://en.wikipedia.org/wiki/Concatenative_programming_language https://en.wikipedia.org/wiki/Concatenative_programming_lang...
  - tom_mellior 7y ago
    In this poster's classification, "basic" Forth (the data manipulation part without parsing words) to me seems to be "procedure" + "cell (state)", i.e., "Imperative programming". This classification is along general semantic lines, not "what syntax do you use to access values". In concatenative languages you use a stack implicitly while in C you use variable names and nested expressions, but this more of a "syntactic" issue than what the poster is concerned with, namely things like "does the language have native closures" which Forth, like C, does not. Parsing words add a huge amount of metaprogramming power, but this classification doesn't deal with any kind of metaprogramming. That's not a dimension that is included here, and even if it were, it would be debatable if it's that different in Forth from Lisp macros, once you look past syntactic concerns as above. But I could very well be wrong here, I'm not an expert on this part.
- Jtsummers 7y ago
  What about array programming, in your view, would differentiate it from the imperative and related paradigms?
  - chroem- 7y ago
    Instead of describing the control flow of a program, you describe a set of operations on data structures.
    - AnimalMuppet 7y ago
platz 7y ago
Ah yes, the chart that lists Oz and Alice ? under every box
WoodenChair 7y ago
I find this diagram less easy to navigate than the simpler categorization of declarative vs imperative with four subcategories: I.e. Imperative: Procedural, Object-oriented Declarative: Functional, Logic (or better term for Prolog-esque languages - constraint-based perhaps) Four simple categories with two meta categories.
dang 7y ago
A thread from 2017: https://news.ycombinator.com/item?id=15417338 https://news.ycombinator.com/item?id=15417338 Two small discussions at the time: https://news.ycombinator.com/item?id=733041 https://news.ycombinator.com/item?id=733041 https://news.ycombinator.com/item?id=578632 https://news.ycombinator.com/item?id=578632 (These links are just for the curious; reposts are fine after a year or so.)
sebastianconcpt 7y ago
Beautiful. But where is JavaScript? Is multi-paradigmatic, tho
- thebravoman 7y ago
  The chart is not by language. There are just some languages for example because there are many languages for a single paradigm
  - irrational 7y ago
    If JS was added to the chart as an example, where would it land?
thebravoman 7y ago
The article is named for “dummies” but it should be noted that it is much more difficult to read than other for dummies materials.

116 points by deepaksurti 7y ago

This should be marked as dating from 2009. There was a discussion of an earlier iteration of the poster on Lambda the Ultimate, where Van Roy defended some of the choices he made. http://lambda-the-ultimate.org/node/2410 http://lambda-the-ultimate.org/node/2410

riffraff 7y ago

FWIW, the linked book, "Concepts, Techniques, and Models of Computer Programming"(CTM), is imo a fantastic book, and there are free classes on edX ("Paradigms of Computer Programming", I think it's now split in two now) that go over the material. Highly recommended if you have an interest in this stuff.

mesaframe 7y ago
I gave it a skim and from that what I could conclude was that it focuses a lot on concurrent operations. Which I don't think comes to everyone's use.
- naasking 7y ago
  Integrating concurrency with mutability is a tough problem, and concurrency is becoming increasingly important.
  - mesaframe 7y ago
    It has always been important but again not for everyone. I would like a similar treatise but for synchronous single threaded operations.
- spinningslate 7y ago
  > it focuses a lot on concurrent operations It does but not to the exclusion of other computation models. I'd agree with GP - I found it a wonderful book. It builds different models of computation successively by incrementally adding features. It's a bit like SICP[0] in that it starts with declarative/functional fundamentals and brings in mutable state really late. The coverage of dataflow was the first one that gave me an "aha!" moment. It's easily 10 years since I bought it and I still dip into it every few months or so. Every time I do, I get something new: insights, deeper understanding, etc. Really wonderful book. [0] https://sicpebook.wordpress.com/ https://sicpebook.wordpress.com/
- riffraff 7y ago
  Yes, I think concurrency is about 1/3 of the book, but it's approached the same way as the other paradigms; you have a basic language, add a single feature and see what happens: what new things can you do? How does the expressivity change? What problems arise? Is this equivalent to another paradigm? I found the insights interesting, but I would agree they are not of immediate utility to many people's day job.
chubot 7y ago
As far as I remember one of the main ideas was "dataflow variables", which are lazily evaluated in parallel (?) I've read about this paradigm in the literature, e.g. with the Lucid language and others. And the book goes into some depth about it. But somehow this paradigm hasn't caught on, despite the constant production of new experimental languages. And I've never seen a real program in it -- e.g. one over 5K lines that people use. Anyone have a conjecture on what happened? Is it flawed, or did nobody pay enough attention? I think there is some overlap with async/await which seems to be the dominant concurrency paradigm now (C#, JS, Python, Rust, etc.) I think one issue is that real systems are composed of multiple languages, and it's hard to bridge programs with wildly different evaluation semantics with C or JavaScript code. And I guess the paradigm is not "reactive". It wants to control the main loop, but in GUIs and networking code where async/await is appropriate, the app doesn't "own" the thread of control. A new paradigm for batch programs is perhaps of limited use. I guess I sort of answered my own question -- the model doesn't solve enough problems to justify its cost. (Also, another issue is that it's a model of very fine-grained parallelism, where as coarse-grained parallelism with limited communication is faster. That's how people optimize in practice.) I'm interested in any contrary opinions though.
- snovv_crash 7y ago
  I worked with LabView enough to have an opinion, I think. The issue is that it isn't actually any easier or faster. The machine still needs to do the same synchronizations and cache invalidations. The engineer becomes very limited in what they can effectively do (recursive structures? They become like {} in Go, performance nightmares). Labview is very effective in its niche, factory monitoring and automation, but I found beyond that it was a pain and a half.
  - dkersten 7y ago
    > Labview is very effective in its niche, factory monitoring and automation, but I found beyond that it was a pain and a half. I’ve never used Labview but it’s worth pointing out that it’s only one possible implementation, just like we have many different takes on other paradigms. I’ve heard people say that labviews specific design is somewhat flawed, but I can’t comment on that since I’ve not used it myself.
dkersten 7y ago
What I found quite interesting, when I read CTM a few years back, was that they only introduced mutable state about half way through. That you could talk about all of these different aspects of programming before introducing mutable state was pretty enlightening.

chroem- 7y ago

Correct me if I'm wrong, but this seems to be missing array programming (APL, Matlab, Julia, etc).

lebuffon 7y ago
And I can't see concatenative programming languages. https://en.wikipedia.org/wiki/Concatenative_programming_language https://en.wikipedia.org/wiki/Concatenative_programming_lang...
- tom_mellior 7y ago
  In this poster's classification, "basic" Forth (the data manipulation part without parsing words) to me seems to be "procedure" + "cell (state)", i.e., "Imperative programming". This classification is along general semantic lines, not "what syntax do you use to access values". In concatenative languages you use a stack implicitly while in C you use variable names and nested expressions, but this more of a "syntactic" issue than what the poster is concerned with, namely things like "does the language have native closures" which Forth, like C, does not. Parsing words add a huge amount of metaprogramming power, but this classification doesn't deal with any kind of metaprogramming. That's not a dimension that is included here, and even if it were, it would be debatable if it's that different in Forth from Lisp macros, once you look past syntactic concerns as above. But I could very well be wrong here, I'm not an expert on this part.
Jtsummers 7y ago
What about array programming, in your view, would differentiate it from the imperative and related paradigms?
- chroem- 7y ago
  Instead of describing the control flow of a program, you describe a set of operations on data structures.
  - AnimalMuppet 7y ago

platz 7y ago

Ah yes, the chart that lists Oz and Alice ? under every box

WoodenChair 7y ago

I find this diagram less easy to navigate than the simpler categorization of declarative vs imperative with four subcategories: I.e. Imperative: Procedural, Object-oriented Declarative: Functional, Logic (or better term for Prolog-esque languages - constraint-based perhaps) Four simple categories with two meta categories.

dang 7y ago

A thread from 2017: https://news.ycombinator.com/item?id=15417338 https://news.ycombinator.com/item?id=15417338 Two small discussions at the time: https://news.ycombinator.com/item?id=733041 https://news.ycombinator.com/item?id=733041 https://news.ycombinator.com/item?id=578632 https://news.ycombinator.com/item?id=578632 (These links are just for the curious; reposts are fine after a year or so.)

sebastianconcpt 7y ago

Beautiful. But where is JavaScript? Is multi-paradigmatic, tho

thebravoman 7y ago
The chart is not by language. There are just some languages for example because there are many languages for a single paradigm
- irrational 7y ago
  If JS was added to the chart as an example, where would it land?

thebravoman 7y ago

The article is named for “dummies” but it should be noted that it is much more difficult to read than other for dummies materials.