
Classification of the Principal Programming Paradigms (2009) - deepaksurti
https://www.info.ucl.ac.be/~pvr/paradigms.html
======
riffraff
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.

~~~
chubot
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.

~~~
dragonwriter
> I think there is some overlap with async/await which seems to be the
> dominant concurrency paradigm now

Dataflow variables are exactly promises where every use that calls for the
result is awaited; in a language where it's the core paradigm, you just don't
write async and await everywhere (and often the runtime will be free to
abandon calculations that won't be used), so, no, it doesn't just have “some
overlap” with async/await; async/await is syntax to for using the paradigm in
a language that is otherwise eager and synchronous.

So, it's also wrong to say that it hasn't caught on, the paradigm is pervasive
and frequently used in industrial programming, which usually uses
multiparadigm languages, not languages purely devoted to a single paradigm.

> (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.)

Dataflow variable don't require any parallelism, though they can leverage it.

~~~
chubot
Citation needed for both your first and second paragraphs :)

As mentioned in my sibling comment [1] there are lots of definitions of
dataflow. It's plausible that the model in CTM can be expressed entirely with
async/await, but I'd like to see it.

As for the second claim, if it's caught on, then it should be easy to point to
code that uses it. Or name some industrial systems that use it. There are some
programming models that live only in specific industries but they also tend to
leak out into open source over time.

And what programming language do those systems use? Are they using Mozart/Oz
or something else? I wasn't aware of any production usage of that language but
I could be wrong.

[1]
[https://news.ycombinator.com/item?id=22337801](https://news.ycombinator.com/item?id=22337801)

~~~
discreteevent
For data flow in industrial programming look at IEC 1131 which is a major
standard. It's a different world and, no, it doesn't seem to leak out to the
mainstream despite there being some very interesting solutions to i/o heavy
concurrent problems.

------
chalst
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)

------
dang
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.)

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

~~~
lebuffon
And I can't see concatenative programming languages.
[https://en.wikipedia.org/wiki/Concatenative_programming_lang...](https://en.wikipedia.org/wiki/Concatenative_programming_language)

~~~
tom_mellior
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.

------
WoodenChair
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.

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

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

~~~
thebravoman
The chart is not by language. There are just some languages for example
because there are many languages for a single paradigm

~~~
irrational
If JS was added to the chart as an example, where would it land?

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

