Super-dee-duper D features

[Pablo Ripolles]

Walter Bright Wrote:

> kris wrote:
>  > Thus; shouting from the rooftops that D is all about meta-code, and DSL
>  > up-the-wazzoo, may well provoke a backlash from the very people who
>  > should be embracing the language. I'd imagine Andrei would vehemently
>  > disagree, but so what? The people who will ultimately be responsible for
>  > "allowing" D through the door don't care about fads or technical
>  > superiority; they care about costs. And the overwhelming cost in
>  > software development today, for the type of companies noted above, is
>  > maintenance. For them, software dev is already complex enough. In all
>  > the places I've worked or consulted, in mutiple countries, and since the
>  > time before Zortech C, pedestrian-code := maintainable-code := less
>  > overall cost.
> 
> Some comments:
> 
> 1) D has no marketing budget. It isn't backed by a major corporation. 
> Therefore, it needs something else to catch peoples' attention. Mundane 
> features aren't going to do it.
> 
> 2) I know Java is wildly successful. But Java ain't the language for me 
> - because it takes too much code to do the simplest things. It isn't 
> straightforward clarifying code, either, it looks like a lot of 
> irrelevant bother. I'm getting older and I just don't want to spend the 
> *time* to write all that stuff. My fingertips get sore <g>. I wouldn't 
> use Java if it was twice as fast as any other language for that reason. 
> I wouldn't use Java if it was twice as popular as it is now for that reason.
> 
> 3) Less code == more productivity, less bugs. I don't mean gratuitously 
> less code, I mean less code in the sense that one can write directly 
> what one means, rather than a lot of tedious bother. For example, if I 
> want to visit each element in an array:
> 
> 	foreach(v; e)
> 	{...}
> 
> is more direct than:
> 
> 	for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
> 	{ T v = e[i];
> 	 ... }
> 
> 
> 4) The more experience I have, the more it seems that the language that 
> got a lot right is ... Lisp. But Lisp did one thing terribly, terribly 
> wrong - the syntax. The Lisp experts who can get past that seem to be 
> amazingly productive with Lisp. The rest of us will remain envious of 
> what Lisp can do, but will never use it.
> 
> 5) Lisp gets things right, according to what I've read from heavy Lisp 
> users, by being a language that can be modified on the fly to suit the 
> task at hand, in other words, by having a customizable language one can 
> achieve dramatic productivity gains.
> 
> 6) If I think about it a certain way, it looks like what C++ Boost is 
> doing is a desperate attempt to add Lisp-like features. By desperate I 
> mean that C++'s core feature set is just inadequate to the task. For 
> example, look at all the effort Boost has gone through to do a barely 
> functioning implementation of tuples. Put tuples into the language 
> properly, and all that nasty stuff just falls away like a roofer peeling 
> off the old shingles.
> 
> 7) A lot of companies have outlawed C++ templates, and for good reason. 
> I believe that is not because templates are inherently bad. I think that 
> C++ templates are a deeply flawed because they were ***never designed 
> for the purpose to which they were put***.
> 
> 8) I've never been able to create usable C++ templates. Notice that the 
> DMD front end (in C++) doesn't use a single template. I know how they 
> work (in intimate detail) but I still can't use them.
> 
> 9) But I see what C++ templates can do. So to me, the problem is to 
> design templates in such a way that they are as simple to write as 
> ordinary functions. *Then*, what templates can do can be accessible and 
> maintainable. It's like cars - they used to be very difficult to drive, 
> but now anyone can hop in, turn the key, and go.
> 
> 10) Your points about pedestrian code are well taken. D needs to do 
> pedestrian code very, very well. But that isn't enough because lots of 
> languages do pedestrian code well enough.
> 
> 11) Today's way-out feature is tomorrow's pedestrian code. I'm old 
> enough to remember when "structured code", i.e. while, for, switch 
> instead of goto, was the way-out feature (70's). Then, OOP was all the 
> rage (80's), now that's a major yawner. STL was then the way-out fad 
> (90's), now that's pedestrian too. Now it's metaprogramming (00's), and 
> I bet by 2015 that'll be ho-hum too, and it's D that's going to do it.
> 
> 12) Take a look at what Kirk McDonald is doing with Pyd. He needs all 
> this stuff to make it slicker than oil on ground steel. He's on the 
> bleeding edge of stuff D needs to *make* pedestrian.


for me reading this post it's amazingly encouraging and future-exciting, 

thanx!