Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
On "hammerprinciple.com" website there are programming languages, statements about them and voting that associates languages with statements.
In particular, there are statements:
Why they are so opposed to each other? Is being incoherent, history-encumbrant, ridden with extra special cases a must for being popular, "mainstream" programming language?
Maybe is it similar reason as why beautiful and coherent artificial natural languages (like Esperanto) are not that popular?
There are three reasons why you learn a natural language:
As it happens, the languages you'd learn under point 3 are ususually not spoken in public or at home, and are not taught in school in place of French or Spanish. Therefore, they are all very niche.
Oh wow, so A and B seem to have some correlation. Does A cause B? Or the other way round? Or are there other factors that I didn't consider?
Your question seems to ask if a programming language can only become mainstream if it is not orthogonal. This is misleading.
Languages change over time. Their standard library gets reworked. New syntax is added. Object orientation is made available. Lambda expressions start looking useful. But closures and objects can be implemented in terms of each other, so why would I need both? Why would I want generics or other type system additions? I clearly do not need them…
A language that does not evolve is probably dead.
For some languages, practicality is of utmost importance. It doesn't matter if there are five or more screwdrivers in my toolbox, because not all screws are equal. An experienced user will pick the right one for the situation.
Other languages strive to be more minimal and/or elegant. This can be useful for didactic purposes, or in research settings. Small languages are easier to port. They are often useful, but not always when you have to ship your application yesterday.
A language that tries to be relevant tomorrow has to keep evolving, and include new concepts. For example, the C++ standard is slowly but constantly being reworked. Each release of Java is a step forward. C# is often ahead of the pack as far as mainstream languages go. A language like SML or Smalltalk has no serious ambitions to go mainstream.
A language that already is widely used has to stay backwards compatible, or it will loose market share. Features that were there yesterday have to stay available even if a better alternative was introduced. In Java, type parameters are erased during compilation for back-compat. In PHP, the main namespace is riddled with dangerous and deprecated functions that can't be removed without breaking a good part of the internet.
I would suggest that successful languages tend to become less orthogonal over time, not only that less orthogonal languages tend to become mainstream more easily. However, there is no clear causation because there are more factors to consider.
If I look through the list of languages you linked to we see as orthogonal languages: Scheme and Lua had minimalism as a design goal, academic languages like Coq, Haskell, SML are less useful for day-to-day programming or difficult to learn, and some languages like Forth and APL are barely used any longer.
The less orthogonal languages are all quite mainstream, or have a long history. Fortran and COBOL are ancient, but still have a strong niche. Languages like PHP and Shell grew beyond what they where intended to do. Some languages are explicitly pluralistic, e.g. Perl and its descendant Ruby. The C# language is in direct competition to Java and tries to score with better features. Some languages have a religious commitment to backcompat, e.g. C++ or Perl.
Because reducing the feature set of a language requires a compromise. Taking a feature out of the language means either:
the language no longer has that feature, so people who need/value that feature will not want to use that language (aside: this is the reason I've never tried golang... while I like some of their ideas I find exceptions too useful to abandon), or
the feature must be implemented as a library within the language. But it is hard to design a language such that a wide variety of useful features can be implemented without compromising on syntax, and syntax is critical in gaining market share (if it wasn't, we'd all be using LISP by now).
LISP is a good case study: it is built on an extremely small set of basic primitives, and those primitives can be combined and recombined in very useful ways, such that just about any language feature you can think of can be (and probably has been) implemented in LISP somewhere. Unfortunately, in order to become flexible enough to achieve this, LISP has compromised on almost all syntactic niceities, leaving a language that (to put it bluntly) only hardcore hackers can stand using.
I'm not suggesting that this is the only way to make a small core language do useful and interesting things, but certainly it is harder to do it without making such compromises. And given that language success is a hit-and-miss kind of thing, ruled by primarily by what developers are trying to do that their existing languages don't do nicely and a new language might do better, the size of the core doesn't really figure much in whether a language becomes popular. And because making a nice language with a small core is more difficult than sacrificing either of those features, fewer such languages are made, which makes it substantially less likely (due to the law of averages) that they will gain traction.
"Small, orthogonal features" is brilliant in a teaching language. It is something I want, in a language I write production code in.
But, I also value "there are good standard libraries" and "I can get stuff done quickly", where there is a strong correlation between a "lack of good standard libraries" and "small orthogonal language". There is a weak correlation between "get stuff done quickly" and "small orthogonal", but a massive anti-correlation between "get stuff done" and "lack of libraries".
Some small, orthogonal languages also take their "purity" (for want of a better word) one or two steps too far, so while purer and cleaner, untainted by practical considerations, they actually end up being harder to write code in.
When I say "production code" and "code", I mean code bases of 100k lines and more.
