Classification of the Principal Programming Paradigms (2009) • Hacker News Board

Re: Classification of the Principal Programming Paradigms (2009)

#31

Post by dkersten » Sat, Feb 15, 2020, 9:51 PM UTC

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.

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.

Re: Classification of the Principal Programming Paradigms (2009)

#32

Post by dkersten » Sat, Feb 15, 2020, 9:53 PM UTC

snovv_crash wrote: post #19

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

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

Re: Classification of the Principal Programming Paradigms (2009)

#33

Post by tom_mellior » Sat, Feb 15, 2020, 10:54 PM UTC

lebuffon wrote: post #8

chroem- wrote: post #6

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

And I can't see concatenative programming languages. https://en.wikipedia.org/wiki/Concatenative_programming_lang...

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.

Re: Classification of the Principal Programming Paradigms (2009)

#34

Post by discreteevent » Sat, Feb 15, 2020, 11:01 PM UTC

chubot wrote: post #29

dragonwriter wrote: post #22

Earlier quoted context omitted.

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

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.