There are two different ways to go about this question:
- asking about the scope of a programming language is asking about the intended programming situations one wants to cover.
- what is a good balance between convenience (sytactic sugar, "features" and abstractions) and asking the programmers to write out things explicitly.
- more subtly: who is using the language, what concepts can be expected to be known to the programmers.
These are of course connected: a particular type of recurring programming situation may lead one to think of patterns and a need to abstract them, whereas to someone who intentionally constrains the scope to a specific area, it can be easier to keep the number and kind of source or "programmer intent" abstractions low.
Often these discussions happen in the context of a general purpose language but there is little consideration that some programming situations are better served by DSLs.
Also a decision on "MIT vs "New Jersey" (worse-is-better) style affects the whole thing, as the notion of correctness is at some level always one of programming situations (a higher level discussion on using the API right way, checking error conditions etc)
Thus is a long-winded way to say: in the end the starting point matters. C++ can be considered a failure language design if you consider it from the readability/cognitive load angle but design choices seem to consistently be about permitting all possible choices. This is why Stroustrup can claim things like "you can write memory safe C++" and not even be wrong. Java can be considered a failure in concision but tool support means that programmers do not pay the cost of writing everything out explicitly.
Haskell and anything in the academic tradition will emphasize abstractions and demand more and more knowledge from users whereas industry tradition will be biased towards low (or lower) cognitive overhead, but if one is willing to specialize, there is an infinite number of nuances of possible points in the design space. We will see more programming languages and come to accept that there will be many that we use at the same time.
So rather than asking how big, maybe we should wonder how to understand the involved trade-offs.
- asking about the scope of a programming language is asking about the intended programming situations one wants to cover.
- what is a good balance between convenience (sytactic sugar, "features" and abstractions) and asking the programmers to write out things explicitly.
- more subtly: who is using the language, what concepts can be expected to be known to the programmers.
These are of course connected: a particular type of recurring programming situation may lead one to think of patterns and a need to abstract them, whereas to someone who intentionally constrains the scope to a specific area, it can be easier to keep the number and kind of source or "programmer intent" abstractions low.
Often these discussions happen in the context of a general purpose language but there is little consideration that some programming situations are better served by DSLs.
Also a decision on "MIT vs "New Jersey" (worse-is-better) style affects the whole thing, as the notion of correctness is at some level always one of programming situations (a higher level discussion on using the API right way, checking error conditions etc)
Thus is a long-winded way to say: in the end the starting point matters. C++ can be considered a failure language design if you consider it from the readability/cognitive load angle but design choices seem to consistently be about permitting all possible choices. This is why Stroustrup can claim things like "you can write memory safe C++" and not even be wrong. Java can be considered a failure in concision but tool support means that programmers do not pay the cost of writing everything out explicitly.
Haskell and anything in the academic tradition will emphasize abstractions and demand more and more knowledge from users whereas industry tradition will be biased towards low (or lower) cognitive overhead, but if one is willing to specialize, there is an infinite number of nuances of possible points in the design space. We will see more programming languages and come to accept that there will be many that we use at the same time.
So rather than asking how big, maybe we should wonder how to understand the involved trade-offs.