> The C++ version is even *worse* than the C one (for wordiness bother):
>
>  for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>  {  T v = *i;
>  ... }
>
> I mean I know the reasons for every bit of the syntax there, and in isolation they make sense, but put it all together and it seems to go backwards.

Hehe, sure. But that's like the worst possible way to do it. :)

* Most people make the std namespace public. Or at least the std::vector part.

* The variable i CAN be declared inside the loop, but it doesn't have to be. I often do this at the beginning of a function. Granted, this doesn't make the overall code smaller, but it does make it neater.

* Inside the loop, you rarely have to make a copy like you do. You can just use i->member() or *i wherever you need them.

So it's actually:

for (i = e.begin(); i != e.end(); ++i) { ... }

Of course, the D foreach loop is still much neater (and I love it). But only if you really want to visit all elements of an array in a row. However, if you want to walk through two AA's at the same time (comparing keys and values, for example), how do you do that in D? Maybe there is a way I haven't found yet (I've only been working with D for a few weeks), but it looks to me like much more bother than with C++ iterators.

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

Overall, I agree with kris. Support for mundane code is just as important, if not more important that support for super features.

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

Flashy super features may catch people's attention, but how good the mundane features are is what *keeps* the people in the language.

Oh, and killer apps are likely much better attractors than flashy super 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.
> 

I disagree. I've seen these arguments over and over, that Java takes a lot of code to write the simplest things, that Java is verbose (consider the Kingdom of Nouns article/rant), etc.. It is true that Java is like that, but I disagree that it is a bad thing. The design of the Java language is optimized for large programs, not for small ones.

Sure, Java's hello world is one the largest compared to other languages, but should we rate languages based on simple code like hello world's? That's not quite correct. It's like bemoaning D or similar languages because a shell scripting language allows writing a hello world with much less code. It does, but shell scripting does scale well for larger projects.

I've been reading and coding a lot of Java recently (as part of a Descent related Eclipse IDE project), and frankly the more I do it, the more I like Java, despite some standing flaws(*). I've been reading and trying to understand a lot of the Eclipse Platform's and JDT's source code, and I'm able to do that fairly well, in good part because the way one writes Java code is both very verbose and very standard. There are no strange or kinky features that obfuscate the code. No MyDSL's for each developer in the team. If Eclipse and JDT were written in C++ (or even in D!) I wonder if my job wouldn't be much more difficult.

I'm not saying an ideal language should be like Java (and indeed I don't think that), what I'm saying is that the verbosity and the "herding of the crowd" mentality of Java are not as bad as most people complain it is. They have a very prominent good side. And Walter, frankly, I think you are very biased in this aspect: Correct if I'm wrong, but you have mostly written code for apps where you are the sole developer, which is very different from being part of a multi-developer team (or even of simply using libraries written by other people), which in turn makes one much more vulnerable to suffer language abuse (or simply different use) from other developers.

(*) I think Java 1.5 made a great difference in Java, making it much more palatable. 'foreach' had to be there, and I find that Java generics cover most of the cases where one would want metaprogramming. What I still consider annoying is checked exceptions, an obtuse function literal syntax (requires using inner classes), and not having free functions, but overall my opinion of Java still remains very positive.

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

I have a feeling there are some more things other than the syntax. But even the syntax alone is a thing very hard to get right: much of LISP's simplicity (specially in its macro system) comes from having a completely orthogonal syntax.

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

Well, no languages do pedestrian code well enough AND allow to code speedy apps at the same time. Java, C#, Python, Ruby, etc. do the first thing, C/C++ does the second, but D is the only one attempting both.

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

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

janderson wrote:
> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.

But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.

> I also think it will be a while before we will realize the full potential of DSL.  Like anything else they should be used with care.

There's one way to find out :o).

Andrei

Bill Baxter wrote:
> Walter Bright wrote:
>> kris wrote:
> 
>>>> 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.
>>
>> I'm pretty sure it's the syntax.
> 
> And the recursion.
> People just don't naturally think recursively.
> 
> And the lack of mutable data structures.
> OCaml tried to fix that, but OCaml's probably always going to be niche as well (see first point).

LISP does have mutation. Besides, many people naturally think recursively, and many problems (e.g. parsing) can be easiest thought of that way.

Andrei

Michiel wrote:
>> The C++ version is even *worse* than the C one (for wordiness bother):
>>
>>  for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>>  {  T v = *i;
>>  ... }
>>
>> I mean I know the reasons for every bit of the syntax there, and in
>> isolation they make sense, but put it all together and it seems to go
>> backwards.
> 
> Hehe, sure. But that's like the worst possible way to do it. :)
> 
> * Most people make the std namespace public. Or at least the std::vector part.
> 
> * The variable i CAN be declared inside the loop, but it doesn't have to be. I
> often do this at the beginning of a function. Granted, this doesn't make the
> overall code smaller, but it does make it neater.
> 
> * Inside the loop, you rarely have to make a copy like you do. You can just use
> i->member() or *i wherever you need them.
> 
> So it's actually:
> 
> for (i = e.begin(); i != e.end(); ++i) { ... }
> 
> Of course, the D foreach loop is still much neater (and I love it). But only if
> you really want to visit all elements of an array in a row. However, if you want
> to walk through two AA's at the same time (comparing keys and values, for
> example), how do you do that in D? Maybe there is a way I haven't found yet (I've
> only been working with D for a few weeks), but it looks to me like much more
> bother than with C++ iterators.

Your right, all that extra work that a simple for-loop causes in C++ its a PITA.

-Joel

Gentlemen,
somebody out there who remembers the Windows OS/2 race ? and why the heck the (without doubt awesome) System is pretty dead ?
Probabely because somebody forget about average Joe Coder, you know him,  the brave guy developing applications for the vertical "billion dollar" market. The meaning is clear, I think, createing an excellent product is not nessesarily a win when you ignore the people this product is made for. And D should be a general purpose language, or do I miss something ?
So please, tell us average coders something like /
THIS SUPER DUPER NEW FEATURE IS USEFULL BECAUSE IT ENABLES YOU TO .... istead of beeing ignorant
Joe




Walter Bright schrieb:
> 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.

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>
>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
> 
> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 

The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.

>Also to write a reflection program that 
> doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.

Not sure I understand. All that will be needed to make Widget available is:

mixin Manifest!(Widget);

I don't see where the syncing problem occurs.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>
> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.

I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information.  Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged D phaser which may become out of sync with the compiler.   I'm undecided on this matter.

>
>> I also think it will be a while before we will realize the full potential of DSL.  Like anything else they should be used with care.
>
> There's one way to find out :o).
>
> Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> janderson wrote:
>>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>>
>>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
>>
>> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 
> 
> The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.
> 
>> Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.
> 
> Not sure I understand. All that will be needed to make Widget available is:
> 
> mixin Manifest!(Widget);
> 
> I don't see where the syncing problem occurs.

This is wrapping each class.  What if the the code was hidden in a library or something.  How would you get a such information?  Also wrapping each class is not as neat as a complete code analysis could be (which is possible in mixin, just very difficult and slow).

Syncing problems could still occur if Walter decides to make some change in the language syntax.

-Joel

> 
> Andrei

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> janderson wrote:
>>>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>>>
>>>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
>>>
>>> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 
>>
>> The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.
>>
>>> Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.
>>
>> Not sure I understand. All that will be needed to make Widget available is:
>>
>> mixin Manifest!(Widget);
>>
>> I don't see where the syncing problem occurs.
> 
> This is wrapping each class.  What if the the code was hidden in a library or something.  How would you get a such information?  Also wrapping each class is not as neat as a complete code analysis could be (which is possible in mixin, just very difficult and slow).
> 
> Syncing problems could still occur if Walter decides to make some change in the language syntax.
> 
> -Joel
> 
>>
>> Andrei

That's my argument against.  My argument for would be that you would be able to build up a much more powerful reflection then Walter would ever have time to create.  For instance you should be able to create a unique ID for ever class so you can version (so if they change, you can still serialize them correctly).

-Joel