Super-dee-duper D features

[kris]

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.

It's already /stacked/ with attention grabbing features :)


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

A lot of people feel that way. D can potentially tap that vast market.


> 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];
>      ... }
> 

Yep, that's great! One of the reasons I like D so much, along with array 
slicing.


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

True.


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

Yet, Lisp will always remain a niche language. You have to wonder why.


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

Boost seems more like a language within a language <g> The very thing 
that increases long-term costs.

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

Agreed. But the issue is not about how badly they're flawed. Instead, 
it's the non-standard "language" problem. The MyDSL problem :)

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

Same here.

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

Templates are certainly a useful tool in D. Tango has some very simple 
usage for handling char[]/wchar[]/dchar[] implementation.

I also look at some D templates for ages, and still can't figure out 
just how they work. Don Clugston is known around here as the Template 
Ninja -- the very name itself shouts out "Here Dwell Demons!" :-D

That kind of thing is a point of diminishing return, anywhere where cost 
is king. Relates to #7


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

The danger is, of course, the language-within-a-language that leads to 
#7. In structured and OOP, if you learned the language you could 
maintain the code (we disregard the fact that anyone can write truly 
unmaintainable code if they try to).

Yet, this could be described as 'contained' within the language. Quite 
different than what causes #7 :)


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

Certainly :)

What Kirk has been doing (much awesometude there) is one of those things 
that fit into the "narrow focus" or "speciality" field that /can/ 
benefit in some manner. But it's a black-box. When it works, nobody will 
fuss with the insides unless they /really/ have to. That's not how most 
commerical software is done today, regardless of all the efforts to make 
it more like circuit-design.


- Kris