We see 4 categories of languages in terms of practicality.

  1. There are languages made with a goal of mathematical or conceptual simplicity, which ultimately tend to be excellent at solving problems that are governed by simple rules. Scheme could be an example.
  2. Further in that direction, we find domain specific languages designed only for one particular kind of problem. Regular expression could be an example.
  3. Then there are languages designed to be very pragmatic, to get the job done, without too much fuzzing about. Python could be an example. This is probably the category with most languages. They also tend to be relatively easy to design.
  4. And lastly, we have languages designed to reflect real life problems. C++ could be an example. We see a fair amount of languages in this category, despite being difficult to design, they often have very strong backing from the industry, with Oracle, Apple, Microsoft, and Google, all trying their luck with their own languages.
Cosmos also belong in this category.

What's different in this real life category, compared to the previous three, is that these real life languages often have features that invite the developer to outline the problems that needs solving, and decompose them into manageable units. A relatively large suite a of language constructs helps the programmer with this. These languages tend to be easiest to work with on large and intricate software systems.

The pragmatic languages tend to have a medium set of language constructs, and often have dynamic typing to really allow the developer to focus more on the immediate problem, and its solution, than on all kinds of infrastructure. These languages tend to be the fastest way to solve smaller problems, because they are malleable, and have the least resistance. Software written very pragmatically tends to be difficult to extend.

The conceptually simple languages tend to have very small set of language constructs, which forces developers to build the necessary abstractions on top. Which can lead to developers spending more time on making tools than making solutions. These languages tend to have a rather low market share in practical problem solving. But their simplicity invites people to play around with fundamental mathematical and computer scientific concepts.

Domain specific languages tend to be in a completely different class of programming, and so tends to be used for specific tasks within software written in one of the other three classes of languages. These tasks are often very impractical to do without the domain specific language, And the domain specific languages tend to be virtually useless for anything else.