Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Classification of the Principal Programming Paradigms (2009)

info.ucl.ac.be

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Classification of the Principal Programming Paradigms (2009)

#21

Post by dahauns »

chubot wrote: post #14
riffraff wrote: post #3

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.

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…

Well, if you include Excel, one could argue the paradigm is actually immensely successful. :)

Re: Classification of the Principal Programming Paradigms (2009)

#22

Post by dragonwriter »

chubot wrote: post #14
riffraff wrote: post #3

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.

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…

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

Re: Classification of the Principal Programming Paradigms (2009)

#23

Post by irrational »

thebravoman wrote: post #18
sebastianconcpt wrote: post #15

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

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

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

Re: Classification of the Principal Programming Paradigms (2009)

#24

Post by szemet »

chubot wrote: post #14
riffraff wrote: post #3

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.

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…

Haskell has dataflow support too (just to mention a better known language), but not sure how popular this compared to all the other concurrency libraries Haskell provides.

https://www.oreilly.com/library/view/parallel-and-concurrent...

Re: Classification of the Principal Programming Paradigms (2009)

#25

Post by AnimalMuppet »

chroem- wrote: post #17
Jtsummers wrote: post #10

Earlier quoted context omitted.

What about array programming, in your view, would differentiate it from the imperative and related paradigms?

Instead of describing the control flow of a program, you describe a set of operations on data structures.

"A set of operations on data structures" sounds very much like imperative programming to me.

Re: Classification of the Principal Programming Paradigms (2009)

#26

Post by chroem- »

AnimalMuppet wrote: post #25
chroem- wrote: post #17

Earlier quoted context omitted.

Instead of describing the control flow of a program, you describe a set of operations on data structures.

"A set of operations on data structures" sounds very much like imperative programming to me.

It's one of those things you can't really appreciate until you've tried it. Imperative programming languages are to assembly languages, as array programming is to imperative programming: it's a higher level of abstraction. The difference between the array and imperative paradigms may not be quite as pronounced as the difference between C and assembly, but it's still significant nonetheless.

There's no need for control structures like loops or if statements in array programming.

Re: Classification of the Principal Programming Paradigms (2009)

#27

Post by ddragon »

chroem- wrote: post #6

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

It's also missing multiple dispatch (multimethods) from Common Lisp, Dylan and Julia (which did not exist in 2009), which is different enough from OOP to deserve a place (and hopefully enough recognition to appear in more new languages).

Re: Classification of the Principal Programming Paradigms (2009)

#28

Post by chubot »

dahauns wrote: post #21
chubot wrote: post #14

Earlier quoted context omitted.

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…

Well, if you include Excel, one could argue the paradigm is actually immensely successful. :)

I wouldn't include Excel -- it's similar to but not the same as the model presented in the CTM book.

You could call "excel" dataflow but the problem with that term is that are a dozen distinct models that can be called "dataflow". Similar to why "Google Cloud Dataflow" is a bad product name. That's also dataflow but the term is so general that it's not useful.

For example, in Excel, derived cells are recomputed when their sources change. This is true of some dataflow proramming languages but not others, including the one in CTM. This is expensive and has a lot of bearing on the implementation.

In fact I learned a few years ago Excel is occasionally wrong in both directions:

- it fails to recompute cells that are dirty in the name of speed

- it recomputes cells that are clean even though it's not strictly necessary

That's probably a fine tradeoff for Excel but you wouldn't want a programming language with those semantics.

Re: Classification of the Principal Programming Paradigms (2009)

#29

Post by chubot »

dragonwriter wrote: post #22
chubot wrote: post #14

Earlier quoted context omitted.

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…

> 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…

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

Re: Classification of the Principal Programming Paradigms (2009)

#30

Post by riffraff »

mesaframe wrote: post #4
riffraff wrote: post #3

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.

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.

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.

Post reply on HN