What Makes A Programming Language Good

[retard]

Wed, 16 Feb 2011 17:23:04 +0000, Bruno Medeiros wrote:

> On 04/02/2011 20:55, bearophile wrote:
>> Bruno Medeiros:
>>
>>> That language ecosystems are what matter, not just the language
>>> itself.
>>
>> This is true, but only once your language is already very good :-)
>>
>> Bye,
>> bearophile
> 
> I disagree. I think an average language with an average toolchain (I'm
> not even considering the whole ecosystem here, just the toolchain -
> compilers, debuggers, IDEs, profilers, and some other tools) will be
> better than a good language with a mediocre toolchain. By better I mean
> that people will be more willing to use it, and better programs will be
> created. Obviously it is very hard to quantify in a non-subjective way
> what exactly good/average/mediocre is in terms of a language and
> toolchain. But roughly speaking, I think the above to be true.
> 
> The only advantage that a good language with bad toolchain has over
> another ecosystem, is in terms of *potential*: it might be easier to
> improve the toolchain than to improve the language. This might be
> relevant if one is still an early-adopter or hobbyist, but if you want
> to do a real, important non-trivial project, what you care is what is
> the state of the toolchain and ecosystem *now*.

Surprisingly this is exactly what I've been saying several times.

I'd also like to point out that part of the potential for new languages 
comes from the fact that you can design much cleaner standard & de facto 
libs before it takes off. Some of the issues with "old" languages come 
from the standard utilities and libraries. It sometimes takes an enormous 
effort to replace those. So, 100% of the potential doesn't come from 
redesign of the language, it's also the redesign of tools and the 
ecosystem. I'm also quite sure it's a redesign every time now. There are 
simply too many languages already to choose from.

Some examples of failed designs which are still in use: PHP's stdlib with 
weird parameter conventions and intensive use of globals, (GNU) C/C++ 
build tools, Java's wasteful (in terms of heap allocation) stdlib, C++'s 
thread/multicore unaware runtime, C++'s metaprogramming libraries using 
the terrible template model, Javascript's "bad" parts from the era when 
it still was a joke.

However there has been a constant flux of new languages since the 1950s. 
I'm sure many new languages can beat Java and C++ in several ways. But in 
general a new language isn't some kind of a silver bullet. Advancements 
in language design follow the law of diminishing returns -- even though 
we see complex breakthroughs in type system design, better syntax and 
cleaner APIs, something around 5-50% better usability/productivity/safety 
many times isn't worth the effort. I've seen numbers that moving from 
procedural programming to OOP only improved the productivity about 
20-40%. Moving from OOP language 1 to OOP language 2 quite likely 
improves the numbers a lot less.

As an example, Java's toolchain and its set of available libraries are so 
huge that you need millions of $$$ and thousands of man years to beat it 
in many domains. There simply isn't any valid technical reason not to use 
that tool (assuming it's the tool people typically use to get the work 
done). If you need a low cost web site and only php hosting is available 
at that price, you can't do a shit with D. Some hardcore fanboy would 
perhaps build a PHP backend for D, but it doesn't make any sense. It's 
1000 lines of PHP vs 100000 lines of D. And reclaiming the potential 
takes forever. It's not worth it.