The definition of expressive power they invent is fine as far as it goes, but to me is not very useful. A useful expressiveness is one that makes it possible for one person to write a library that captures semantics in a way that another person can use the semantics by name.
My go-to example is the hash table. Coding in C, one is always cobbling up hash tables, because C hasn't the expressive power to code and publish a generally useful hash table library. Many other languages sidestep the problem by building hash "dictionaries" into the core language.
A few have enough expressive power to capture the hash table pattern (and numerous variations on it) in libraries that may then be used almost as if they had been built into the core language.
Whenever a pattern shows up in many different programs coded in a language, it indicates that the language is not quite expressive enough to usefully capture that pattern in a library. Some languages make a virtue of the weakness, and call it simplicity. Others pull patterns into the core language. A few add expressiveness until it becomes possible to capture the pattern in a library.
Clearly the last is best, for a general-purpose systems language, because it enables capturing an open-ended range of patterns in libraries, and each capability joins the others, multiplying them. But it is also much harder to invent and to get right. Usually, too, the syntax needed to use a library version of a feature cannot be made quite as nice as is possible for a language built-in.
So, in C++ we see core support for exceptions, virtual functions, and coroutines, with pattern matching and reflection coming, but the type system is also continually strengthened to make more kinds of libraries possible.
A more expressive language might not need built-in exceptions or virtual functions, because those patterns could be coded into libraries and used from there. Rust has the Drop trait in its library, so does not need destructors, as such, in the core language.
Downsides to expressiveness of this kind include that interoperability may suffer, as there are too many ways the same thing could be achieved, and therefore little regularity. Performance may suffer if work cannot be moved to compile time; or, if it can, compile time may balloon.
So, some patterns are naturally better to pull into the core: particularly, those with an obviously correct, unique form; or that are needed to help integrate libraries from different sources. A Standard Library is a place to put such features that would not benefit much from adoption into the core.
Whichever course is taken, people will complain that the language is getting too big and complicated, and the standard library too big.
My go-to example is the hash table. Coding in C, one is always cobbling up hash tables, because C hasn't the expressive power to code and publish a generally useful hash table library. Many other languages sidestep the problem by building hash "dictionaries" into the core language.
A few have enough expressive power to capture the hash table pattern (and numerous variations on it) in libraries that may then be used almost as if they had been built into the core language.
Whenever a pattern shows up in many different programs coded in a language, it indicates that the language is not quite expressive enough to usefully capture that pattern in a library. Some languages make a virtue of the weakness, and call it simplicity. Others pull patterns into the core language. A few add expressiveness until it becomes possible to capture the pattern in a library.
Clearly the last is best, for a general-purpose systems language, because it enables capturing an open-ended range of patterns in libraries, and each capability joins the others, multiplying them. But it is also much harder to invent and to get right. Usually, too, the syntax needed to use a library version of a feature cannot be made quite as nice as is possible for a language built-in.
So, in C++ we see core support for exceptions, virtual functions, and coroutines, with pattern matching and reflection coming, but the type system is also continually strengthened to make more kinds of libraries possible.
A more expressive language might not need built-in exceptions or virtual functions, because those patterns could be coded into libraries and used from there. Rust has the Drop trait in its library, so does not need destructors, as such, in the core language.
Downsides to expressiveness of this kind include that interoperability may suffer, as there are too many ways the same thing could be achieved, and therefore little regularity. Performance may suffer if work cannot be moved to compile time; or, if it can, compile time may balloon.
So, some patterns are naturally better to pull into the core: particularly, those with an obviously correct, unique form; or that are needed to help integrate libraries from different sources. A Standard Library is a place to put such features that would not benefit much from adoption into the core.
Whichever course is taken, people will complain that the language is getting too big and complicated, and the standard library too big.