Input from a newbie

[bearophile]

Jonas:

> Could you please elaborate on this a bit more? What's the 
> problem with helpful compiler messages?

Walter likes helpful error messages, but I think he doesn't want 
to:
1) Use too much time to improve them. There are usually more 
important problems to fix.
2) Slow down the compiler (or make it use more RAM) to generate 
better errors (this seems to happen if you want the column number 
too of the error).
3) Produce too much long error messages because he thinks most 
people are annoyed by a command line interface that gets too much 
scrolling caused by many long error messages (I think most people 
think this is a bit ridiculous justification).

But if you want to add/improve specific error messages, then ask 
for the specific improvements in D Bugzilla as enhancement 
request.


> That looks great, thanks, although it's a bit cluttered with 
> all those languages ;-)

That 'clutter' is the real purpose of that site.

If you know language X, you don't know language Y but you want to 
learn language Y, often in that site you are able to find the 
same algorithm/code implemented in both X and Y. Comparing them 
you are able to learn some Y and  the best idioms of Y too. Just 
like the true Rosetta Stone did for Egyptian language :-)

That site has other secondary purposes:
- There you often find good computer science ideas or good 
programming ideas/tricks to learn from.
- Comparing the same algorithms in many very different languages 
you are sometimes able to catch better the essence of an 
algorithm, that is what's invariant of those implementations. A 
good book that introduces to algorithms is supposed to show this 
"essence" but often it doesn't, because a book on algorithms like 
the one by Robert Sedgewick is mostly procedural, even if he has 
written books for Java, C, C++. On that site you find wildly 
different implementations based on different programming 
paradigms, like templates, pure lazy functional, dynamic 
homoiconic functional, parallel, OOP, logic programming, 
concatenative programming, stack-based, even flow programming. 
All those programming paradigms are usually absent on books like 
Robert Sedgewick ones. And often the comparison teaches you 
something. Because sometimes an algorithm or data structure must 
be changed to fit (otherwise you get things like QuickSort or the 
Sieve of Eratosthenes implemented naively in Haskell, with so bad 
performance that they essentially have become a different 
algorithm).
- If you are interested not just in algorithms (or little 
programs) and their implementations, but also in programming 
languages themselves and their design, then that site helps you 
slowly gain a broader vision of what different languages offer to 
solve specific problems, what the "taste" of a language is, what 
languages are elegant or not, what languages seem an 
agglomeration of features, what languages are practical 
"engineering products" like D or not, what type systems seem 
intrusive and what are too much rigid, and so on and on. So if 
you want you are able to use that site to learn how to design 
languages too, a bit.
- That site has several other smaller purposes.

Bye,
bearophile