The idea of "programming paradigms" is not a useful way to talk about programming language design.
> The trouble with programming paradigms is that it is rather difficult to say what one is, or how we know we have a new one. Without precise definitions, nothing precise can be said, and no conclusions can be drawn, either retrospectively or prospectively, about language design.
>
> What, if anything, is a programming paradigm? [0]
Luckily, we've studied programming languages and their design rigorously for decades, and we already have a rich, common language for discussion the design space of programming languages: type theory.
It sounds intimidating: "theory" is often general abstract nonsense that's only useful in academic research, etc., etc. But that's not the case at all. "Type theory" is really just a really useful way to understand individual features of a programming language, and how they compose with one another.
Type theory is only useful up to a certain point; there are plenty of languages that appear identical from a type-theoretic viewpoint but that have deeper richer interpretations in category- or set-theoretic settings. Check out the actual diagram in the article; it shows off some distinctions that would have been totally washed out if only types were considered interesting.
If a language has syntax specifically for some paradigm then the paradigm is reflected in the type system. A paradigm is invisible in the type system if it is implemented as library only.
> The idea of "programming paradigms" is not a useful way to talk about programming language design.
The term "paradigm" is too general indeed and therefore can be quite ambiguous in many situations because it covers different aspects like the underlying computing model or language design.
The term is perhaps not very precise, but it is a useful shorthand to describe fundamental conceptual difference between say Basic, Haskell and Prolog.
There many important dimensions of difference in programming languages that matter to the programmer. Which of those are "fundamental"? What does that question even mean??
One fork in the road between academic/theory answers to that question and developer answers concerns the role of the standard libraries and available IDEs. The out-of-the-box work/contribution of those tools is super important to developers in practice, but irrelevant to academic discussions. Some academics focus on real theory and declare that their statements about PL are basically a kind of applied mathematics - use it if it is somehow relevant to you, and ignore it, like other piles of math, if it isn't. Others make claims that the distinctions capture important properties like preventing careless errors. In that case, one can also talk about which tools are helpful/important to prevent careless errors. And similar remarks can be made for other properties such as speed/brevity of coding/expression, availability of pre-existing parts and ease of integrating them, etc. IMO, there is room for theory that tries harder to abstract the dimensions that drive software practice.
Could someone explain to me why everyone is crazy about type theory? ATM i learn category theory by watching and reading the awesome material from Bartosz Milewski. Should i stop and learn type theory instead, if i want to know more about programming languages in an abstract / general sense?
I think there's a form of misplaced attention when it comes to programming. There should be a focus on the UX of the programmer. The programming paradigm is just one component of this. It's missing the forest for the trees.
I think the programming paradigm is the foundation in the UX of a programming language. It is the basic conceptual model the language is presenting for the user. It influences almost all parts of the UX from syntax to debugging experience.
There is a phrase "developer experience" ("DX") that I've seen used occasionally. It would be great if that concept could be developed further, similar to how "UX design" has been maturing as a field over the years.
For all the maturing "UX design" has done over the years, using a computer still feels mostly like swimming in garbage. Sure, now it's pretty brand-name garbage. But I'd hardly call that an improvement.
I don't think it's possible to create a satisfying diagram like this. It's already been said, but compartmentalizing languages into "paradigms" is generally pointless.
Type systems, which the chart doesn’t address at all, are now usually considered at least as important an aspect to language’s ‘paradigm’ as the (increasingly-blurry) functional vs imperative distinction. And a lot of the examples are pretty dated, coming as it did at the tail end of the object-oriented and XML fads. And concurrency and especially parallelism are given short shrift.
Paradigms are quite orthogonal to type systems. Mozart/Oz and AliceML implement more or less the same set of paradigms. One is dynamic the other is statically typed.
Then they don’t implement the same set of paradigms. Type systems (can) fundamentally shape how computations may be expressed in a language. For example, C++’s type system was famously proved Turing-complete.
So is Java's type system [1], and Rust's and Haskell's with some modest extensions, and Scala's. Many type systems have turned out to be Turing complete.
No, that just changes where programmers can put their computations. Scheme and Rust are not more powerful for their macros than C++ is for its templates; both can put unreasonable demands on the compilers.
Typing is hardly a new thing, its lack definitely can't be blamed on the age of the chart.
It has this comment though
> Axes that are orthogonal to this chart are typing, aspects, and domain-specificity. Typing is not completely orthogonal: it has some effect on expressiveness
I don't think so. Perhaps you've changed your mind on that topic, but typed languages were always dominant in industry, modulo a few startups. That's still the case today.
I don't get what you mean here. I think statically typed languages are much less dominant now than in 2008. Python, Ruby, JavaScript have all found huge niches since then.
> Python, Ruby, JavaScript have all found huge niches since then.
And Perl has a much smaller niche, and JavaScript's niche is hard to pin down since it's often just a compilation target for typed languages (Dart, TypeScript, etc.).
Language marketshare ebbs and flows, but I don't think the overall ratio has changed much. Statically typed languages are still largely dominant.
I can't think of any domain that was dominated by a statically typed language that a dynamically typed language took over, and every new domain that cropped up with dynamically typed solutions has equally good statically typed competitors.
Most of the people I know who program in JavaScript are using JavaScript, I'm kind of the odd ball for using Typescript though I hope that's changing. JavaScript still has most of the market share for languages that compile to JavaScript. There is a huge web community out there that still haven't been exposed to very much static typing, by numbers at least.
Machine learning was done in mostly C++ before Python took pretty much the entire domain. Mind you, this is mostly cultural, I don't think it has anything to do with types (more like C++ is a PITA, python is much easier to use).
My only claim, however, is that static languages haven't really made much inroads since 2008, and it feels like there is a lot of regression going on (e.g. with machine learning).
> The trouble with programming paradigms is that it is rather difficult to say what one is, or how we know we have a new one. Without precise definitions, nothing precise can be said, and no conclusions can be drawn, either retrospectively or prospectively, about language design. > > What, if anything, is a programming paradigm? [0]
Luckily, we've studied programming languages and their design rigorously for decades, and we already have a rich, common language for discussion the design space of programming languages: type theory.
It sounds intimidating: "theory" is often general abstract nonsense that's only useful in academic research, etc., etc. But that's not the case at all. "Type theory" is really just a really useful way to understand individual features of a programming language, and how they compose with one another.
[0]: http://www.cambridgeblog.org/2017/05/what-if-anything-is-a-p...