Super-dee-duper D features

[Sean Kelly]

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.

Agreed with all of the above.

> 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's lambda functions are another good example of a useful idea with 
a horrific implementation.

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

I have no problem with C++ templates, but the syntax is such that I 
don't consider them appropriate for a lot of the uses to which they're 
being put.  Also, in many ways, C++ templates feel like a hack.  The 
need to sprinkle such code with "template" and "typename" qualifiers 
just so the compiler knows what it's parsing sends up a huge red flag 
that something is wrong.

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

Yup.  It may be that the D community is more technically adept than the 
C++ community on average simply because of the type of people new 
languages tend to attract, but I've seen a lot of interesting template 
code around here.

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

True enough.  And it may end up being only hindsight that shows where 
the approach tends to break down, much like happened with OO.

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

I'll admit it's nice to see examples that truly require compile-time 
facilities to be at all feasible.


Sean