Walter Bright wrote:
> 
> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.

I suppose it depends on the person.  Personally, I was mostly searching for a language that addressed my issues with existing languages, and D had that in spades.


Sean

kris wrote:
> Walter Bright wrote:
>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
> 
> Bling is very much in the eye of the beholder, and often has the inverse effect?

If it is perceived as being *just* bling, it will have the reverse effect. If you can show, however, that it solves otherwise intractable or time-wasting problems, you get interest.

Walter Bright wrote:
> kris wrote:
>> Walter Bright wrote:
>>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
>>
>> Bling is very much in the eye of the beholder, and often has the inverse effect?
> 
> If it is perceived as being *just* bling, it will have the reverse effect. If you can show, however, that it solves otherwise intractable or time-wasting problems, you get interest.

I agree, though I think most people have a psychological bias toward problems they can already solve but are tedious, as opposed to problems that are too hard to be done now.  (I.e. it's easier to sell dishwashers than personal robots, and the first home computers were marketed as useful for organizing recipes.)

So while DSLs are really cool, if you want to advertise in "java developer magazine", you want to use them in an elegant way to do the top five routine tasks better, rather than solving P = NP, even if the latter is far more interesting.  From the little that I understand RoR, it seems to be exactly this - for building web sites of the type that already exist but require a lot of grunt work to get off the ground.

Kevin

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
>>
>>
>> Bling is very much in the eye of the beholder, and often has the inverse effect?
> 
> 
> If it is perceived as being *just* bling, it will have the reverse effect. If you can show, however, that it solves otherwise intractable or time-wasting problems, you get interest.

Absolutely.

If you can successfully do that for, say, dev managers, then so much the better. On the other hand, giving such ppl a reason to fear adoption would be a terrible mistake. As you probably know, commercial shops tend to be more than a bit conservative when it comes to code.

Even companies perceived as progressive care deeply about ensuring the code is 'pedestrian' in nature. Google, for example, outlawed C++ templates. They did this because their experience showed such code was unmaintainable, more often than not. In the hands of the masses, such tools are often used for creating a language within a language, and everyone's version has a personal stamp: MyDSL

It's the old story about great power requiring great responsibility. Should the language be penalized for that? No. Might it be viewed that way? Sure. Just being "right" is never enough in such an environment.

In no way am I saying "oh, all that meta-stuff is poppycock", as someone had suggested to me. I personally /like/ a touch of DSL here and there (have been shot-down in the past for exactly that). Instead, my personal concerns (when it comes to D) are based purely around three things:

1) is it of notable or daily value to 50%+ or more of users?
2) does it further delay fixing existing features that match #1?
3) does it have /real/ potential to hinder adoption due to ignorance, religion, sexual preferences, or the weather?

Those are all arguable, of course. Programmers are notoriously fickle when it comes to #3. But my concern over that one is the commercial dev shops; the likes of Google, Oracle, SAP, Yahoo, along with every single company that currently uses Java instead of C++

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.

All IMO

- Kris

Reply in new thread "Super-dee-duper D features".

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> The flashy stuff, though, is the stuff that piques peoples' interests enough to give D a try.
>>>
>>>
>>> Bling is very much in the eye of the beholder, and often has the inverse effect?
>>
>>
>> If it is perceived as being *just* bling, it will have the reverse effect. If you can show, however, that it solves otherwise intractable or time-wasting problems, you get interest.
> 
> Absolutely.
> 
> If you can successfully do that for, say, dev managers, then so much the better. On the other hand, giving such ppl a reason to fear adoption would be a terrible mistake. As you probably know, commercial shops tend to be more than a bit conservative when it comes to code.
> 
> Even companies perceived as progressive care deeply about ensuring the code is 'pedestrian' in nature. Google, for example, outlawed C++ templates. They did this because their experience showed such code was unmaintainable, more often than not. In the hands of the masses, such tools are often used for creating a language within a language, and everyone's version has a personal stamp: MyDSL

Well, I'd like some real references before I'll believe Google has "outlawed" templates.  I found two links saying they aren't wild about 'em:
This one basically says they don't have a lot of them mostly because they like to wrap their C++ with SWIG, and SWIG can't handle 'em well.
http://www.sauria.com/~twl/conferences/pycon2005/20050325/Python%20at%20Google.notes

This one says templates are hard to use and make for bad propeller-head APIs:
http://www.manageability.org/blog/stuff/google-coding-cultures

But neither of those says it's "outlawed".

On the other hand Adobe is doing more and more with templates these days.  http://opensource.adobe.com/index.html


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

Good points.  I've pretty much given up trying to do anything interesting with C++ templates for much the same reason.  With the exception of Boost smart pointers, pretty much every mega-template library I've tried to use has made me regret in the end, as I waste hours staring at meaningless page long compiler error messages.  Looking at the source code is absolutely no help.  And the template things I've worked on myself have always turned into brick-wall affairs where there just isn't a good way to get from point A to point B without a lot of shenanigans.

But I don't think that's a condemnation of metaprogramming.  That's a condemnation of metaprogramming /in C++/, which was never designed for such a thing.  I'm hopeful that a design created with the task of metaprogramming in mind will actually lead to code that's easier to read and maintain than pages of repetitive boiler-plate.

I'm hopeful anyway.  But to me it seems like what D's souped-up templates have proved so far is that while features like static-if take you a long way -- maybe so far as "making the simple stuff simple" -- anything beyond that still turns into spaghetti.

It's a step in the right direction, though.  In C++ even the simple stuff gives you spaghetti.

--bb

Andrei Alexandrescu (See Website For Email) wrote:
> Don Clugston wrote:
>> To do a perfect solution, you'd need to be able to identify when a variable is used twice, for example,
>>
>> a = 3.0 * b + (c - a * 1.5);
>> The compiler knows that 'a' occurs twice, but that information is not transferred into expression templates.
> 
> I think what you really need is aliasing information (e.g. two names referring to the same vector), and that is typically not easily computable.

Ideally, yes. But there's value in knowing names which are *definitely* aliased, even if the majority of names have indeterminate aliasing. I think that most of the value comes from the simple cases, the ultimate example being the += operator.

Example: for x87, the most severe limitation on expression complexity is not the number of temporaries, but the number of distinct vectors (you run out of pointer registers before you run out of floating-point stack).

>> The compiler may also know the length of some of the arrays, and that is also lost.
> 
> Ah, indeed. So that would mean better error checking and probably less runtime bounds checking.

Exactly. And there's implications for loop unrolling, too. (eg, loop unrolling is very attractive if you know the length is a multiple of 4).

>> Of course another approach would be to add
>> opAssignExpression(char [] expr)()
>> {
>> }
>> where "expr" is the verbatim expression.
>> a = b*5 + c*d;
>>
>> would become
>> mixin a.opAssignExpression!("a=b*5+c*d");
>>
>> since it seems that with expression templates, you're fighting the compiler, attempting to undo everything it has done.
> 
> Not everything - e.g., precedence of operators remains unchanged. In the string-based approach you'd have to write a little parser to reimplement operator precedences. But point taken.

I've thought about this a bit more. The compiler has done some useful constant folding for you, and parsed all the literals. So ideally you want it in a partially digested form.
My implementation converts the expression into a tuple of values (basically a stack), and a char [] of postfix operations to be performed on that stack. Something like this is probably close to ideal, especially if the compiler could remove known duplicate (aliased) values from the tuple.

There would need to be a canonical form for the operations, though -- postfix is great for Forth, but looks thoroughly out of place in D.
eg
a = 3.0 * b + (c - a * 1.5);
becomes
"v2 v3 * v4 v5 v1 * - v1 ="
with the tuple being v[1] = a, v[2] = 3.0, v[3] = b, v[4] = c, v[5] = 1.5
But perhaps a
char [] ConvertToPostfix(char [] expr) library metafunction is all that's required.

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> To do a perfect solution, you'd need to be able to identify when a variable is used twice, for example,
>>>
>>> a = 3.0 * b + (c - a * 1.5);
>>> The compiler knows that 'a' occurs twice, but that information is not transferred into expression templates.
>>
>> I think what you really need is aliasing information (e.g. two names referring to the same vector), and that is typically not easily computable.
> 
> Ideally, yes. But there's value in knowing names which are *definitely* aliased, even if the majority of names have indeterminate aliasing. I think that most of the value comes from the simple cases, the ultimate example being the += operator.
> 
> Example: for x87, the most severe limitation on expression complexity is not the number of temporaries, but the number of distinct vectors (you run out of pointer registers before you run out of floating-point stack).
> 
>>> The compiler may also know the length of some of the arrays, and that is also lost.
>>
>> Ah, indeed. So that would mean better error checking and probably less runtime bounds checking.
> 
> Exactly. And there's implications for loop unrolling, too. (eg, loop unrolling is very attractive if you know the length is a multiple of 4).
> 
>>> Of course another approach would be to add
>>> opAssignExpression(char [] expr)()
>>> {
>>> }
>>> where "expr" is the verbatim expression.
>>> a = b*5 + c*d;
>>>
>>> would become
>>> mixin a.opAssignExpression!("a=b*5+c*d");
>>>
>>> since it seems that with expression templates, you're fighting the compiler, attempting to undo everything it has done.
>>
>> Not everything - e.g., precedence of operators remains unchanged. In the string-based approach you'd have to write a little parser to reimplement operator precedences. But point taken.
> 
> I've thought about this a bit more. The compiler has done some useful constant folding for you, and parsed all the literals. So ideally you want it in a partially digested form.
> My implementation converts the expression into a tuple of values (basically a stack), and a char [] of postfix operations to be performed on that stack. Something like this is probably close to ideal, especially if the compiler could remove known duplicate (aliased) values from the tuple.
> 
> There would need to be a canonical form for the operations, though -- postfix is great for Forth, but looks thoroughly out of place in D.
> eg
> a = 3.0 * b + (c - a * 1.5);
> becomes
> "v2 v3 * v4 v5 v1 * - v1 ="
> with the tuple being v[1] = a, v[2] = 3.0, v[3] = b, v[4] = c, v[5] = 1.5
> But perhaps a
> char [] ConvertToPostfix(char [] expr) library metafunction is all that's required.

Or go with prefix notation, and use some sort of nesting indicator, like idunno, uh, parentheses.  ;-)

  char [] ConvertToLisp(char [] dexpr)

Seriously though, it may be that that's pretty much what we're going to need in the end.  Greenspun's tenth law and all.  If you want to manipulate a textual form of parse trees in the most convenient way possible you're pretty much going to end up with Lisp Sexprs.   You'll just want to get out of Lisp in the end to spit out the D code:

   char [] ConvertLispToD(char [] sexpr)

I could imagine worse things happening.  D becomes a better C++ with embedded compile-time Lisp for extensions.

--bb

Bill Baxter wrote:
[snip]
> I'm hopeful anyway.  But to me it seems like what D's souped-up templates have proved so far is that while features like static-if take you a long way -- maybe so far as "making the simple stuff simple" -- anything beyond that still turns into spaghetti.
> 
> It's a step in the right direction, though.  In C++ even the simple stuff gives you spaghetti.

Very true.

-Joel

Bill Baxter wrote:
> 
> Well, I'd like some real references before I'll believe Google has "outlawed" templates.

I heard something roughly to this effect from a friend of mine who used to work there, but things may have since changed.


Sean