Classification of the principal programming paradigms
info.ucl.ac.be
info.ucl.ac.be
> 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...
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.
How "state" is classified seems quite ad-hoc.
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.
Btw, those concerns are not language "paradigms"
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
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.
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).