• bearophile <bearophileHUGS lycos.com> Feb 04 2011
• spir <denis.spir gmail.com> Feb 04 2011
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Feb 16 2011
• Jonathan M Davis <jmdavisProg gmx.com> Feb 16 2011
• retard <re tard.com.invalid> Feb 16 2011

bearophile <bearophileHUGS lycos.com> writes:

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

spir <denis.spir gmail.com> writes:

On 02/04/2011 09:55 PM, 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 :-)


A key point is, imo, whether the eco-system grows, and how harmoniously, is 
completely unrelated to whether your language is "very good", or how good it is 
--compared to others of similar vein. I would say these are close to orthogonal 
dimensions, with probability close to 1 ;-) (sorry for unclear formulation, I 
guess you get the point anyway).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

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*.

-- 
Bruno Medeiros - Software Engineer

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Wednesday, February 16, 2011 09:23:04 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*.


There are people who will want a better language and will be willing to go to 
some effort to findand use one, bet there are plenty of programmers who just
don't 
care. They might like to have a better language, but they're not willing to go 
togreat lengths to find and use one. So, even if they're presented with a 
fnantastic language that they might like to use, if it's a pain to use due to 
toolchain issues or whatnot, they won't use it.

Every barrier of entry reduces the number of peoplle willing to use a
particular 
programing language. For someone to be willing to put up/work passed a 
particular barrier of entry, the effort has to appear to be worthwhile to them. 
And often, it won't take much for a particular barrier of entry to be enough
for 
someone to not try a language which they think _might_ be much better but don't 
know is much better, because they've never really used it.

So, until the toolchain is reasonable to your average programmer, your average 
programmer isn't going to use the language.

Now, by no means does that mean that the toolchain is the most important aspect 
of getting people to use a new language, but it _does_ mean that if you want to 
increase your user base, you need a solid toolchain.

To get your language ironed out, you need a fair-sized user base, but there's 
also no point in growing the user base to large sizes long before the language 
is even properly usable. So, I don't know what point in the development process 
is the best time to really be worrying about the toolchain.

As it stands, D has generally worried more about getting the language right.
Now 
that the spec is mostly frozen, the focus is shifting towards ironing out the 
major bugs and fixing the major wholes in the toolchain (such as the lack of 
support for 64-bit and shared libraries). So, D has definitely taken the
approach 
of trying to iron out the language before ironing out the toolchain.

Regardless, it's definitely true that problems with the toolchain are
preventing 
people from using D at this point. How good the language is if you can put up 
with some of its problems or how good it will be once those problems are solved 
is irrelevant to many programmers. They want a good toolchain _now_. And when 
most programmers are used to dealing with toolchains with virtually no bugs (or 
at least not bugs that they typically run into), they're not going to put up 
with one with as many bugs as D's has. We're really going to need a solid 
toolchain for D to truly grow its user base. And we're getting there, but it 
takes time. Until then though, there are a lot of programmers who won't touch D.

- Jonathan M Davis

retard <re tard.com.invalid> writes:

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.