Hi, again.  Obviously, I can't sleep.

A real danger to a language like D is falling to the Creepy Feature Creature.  This monster eats promising new languages for breakfast.

I've noticed that not only does D have a lot of features, there are a LOT of requests for more (like in my last post about the while loops). If you had to get rid of anything, what would it be?

Here's a short list of things I could probably live without:

- alias: Never felt like I needed it in Pascal.

- function overloading, other than operator overloading: A good long function name never hurt code readability.

- goto statements: Haven't we won this argument yet?  It's been decades now...

- break and continue statements: You can use subroutines and return statements instead.  Generally the code is more readable in this form.

- Assignments in expressions: I accidently type if(a = b) much too often... and when I'm reading code, I often fail to see the assignment.

- Fall through in case statements: Missing break statements can be ugly bugs to find.

And here are the two really big one that will forever be debated:

- pointers

I'm a huge speed freak, but I just don't need pointers.  I'm really sick of debugging pointer spaghetti.  I haven't seen a good use of ** types (pointers to pointers) in years.  Ever debug a function that takes a *** argument?  Lots of fun!

- garbage collection

It's already in D, and that's not going to change, but just to continue the endless debate...

GC is a good solution to a problem that has a better solution.  Speed freaks like me want objects of each class allocated together in memory to make better use of cache (or even more advanced memory layouts).  The compiler should do that automatically.  The compiled code should compact and reclaim memory whenever I ask it to, not whenever it wants.  I just want to write 'new' and 'delete', and get awesomely fast and seg-v free code.  And, I never want to write my own destructors.  Fix the pointers for me.  It requires more from the compiler, and a small addition to the language (to specify which children to recursively delete).  It really does work.  We do this now where I work.

Here's another major one:

- templates

These things confuse the heck out of my new programmers.  It is the single most confusing thing in C++.  That would be OK if they were really powerful, but templates simply don't have much power compared to full code generators.  Why not add support for code generators to the language instead?  Try doing this with a template: stream out all you data structures to a file in binary.  Do it with 1 line of code.  A code generator can do this, but templates can't.

Bill Cox

Bill Cox wrote:
> Hi, again.  Obviously, I can't sleep.
> 
> A real danger to a language like D is falling to the Creepy Feature Creature.  This monster eats promising new languages for breakfast.
> 
> I've noticed that not only does D have a lot of features, there are a LOT of requests for more (like in my last post about the while loops). If you had to get rid of anything, what would it be?
> 
> Here's a short list of things I could probably live without:


Ho ahead and hack Sather. It lacks of most things you hate so much! You simply have to shut off its GC and there you go!!!

Hi Bill, thought you might like a reply.

Bill Cox wrote:
...
> If you had to get rid of anything, what would it be?

I mentioned it earlier in another post, but it would mainly be some of the pointer-usage/declarator syntax still in D.  With arrays being a more first class notion in D I don't think anything more than one level of indirection (via * or whatever) is necessary.

> 
> Here's a short list of things I could probably live without:
> 
> - alias: Never felt like I needed it in Pascal.
> 

I like this one.  I'd bet they could also play a more important role when/if D gets a more worked-out template/generics implementation.

> - function overloading, other than operator overloading: A good long function name never hurt code readability.
> 

Really have to disagree strongly with this one.  Ever looked at the GTK API
versus QT?  They have
lots_of_very_long_function_names_that_do_specialized_things_that_make_it_hard_to_keep_track_of_everything_that_you_are_doing.
:)  Probably something that becomes more of a necessity in libraries/APIs
etc.

> - goto statements: Haven't we won this argument yet?  It's been decades now...
> 

It's certainly not any good substitute for control flow.  Technically the only good argument for it left in C/C++ IMO was breaking out of big nested loops, which is solved in D by "break <identifier>."  I've heard from some performance die-hards that they sometimes use it in critical codepaths where the optimizer didn't do a good job, but these days thats probably of very little importance.

> - break and continue statements: You can use subroutines and return statements instead.  Generally the code is more readable in this form.

I use these sparingly and haven't ever noticed any readability problems. Could be an ingrained thing though.

> 
> - Assignments in expressions: I accidently type if(a = b) much too often... and when I'm reading code, I often fail to see the assignment.
> 

What would you suggest instead? ":="?

> - Fall through in case statements: Missing break statements can be ugly bugs to find.

I agree.  Haven't personally had to chase many bugs of that kind though.

> 
> And here are the two really big one that will forever be debated:
> 
> - pointers
> 
> I'm a huge speed freak, but I just don't need pointers.  I'm really sick of debugging pointer spaghetti.  I haven't seen a good use of ** types (pointers to pointers) in years.  Ever debug a function that takes a *** argument?  Lots of fun!
> 

Agreed++;  See earlier comment on indirection.  Btw, take a look at the D front-end, there are a number of **'s in there.  If it was rewritten in D I bet they could go away.

> - garbage collection
> 
> It's already in D, and that's not going to change, but just to continue the endless debate...
> 
> GC is a good solution to a problem that has a better solution.  Speed freaks like me want objects of each class allocated together in memory to make better use of cache (or even more advanced memory layouts).  The compiler should do that automatically.  The compiled code should compact and reclaim memory whenever I ask it to, not whenever it wants.  I just want to write 'new' and 'delete', and get awesomely fast and seg-v free code.  And, I never want to write my own destructors.  Fix the pointers for me.  It requires more from the compiler, and a small addition to the language (to specify which children to recursively delete).  It really does work.  We do this now where I work.

Would be nice if you could selectively disable GC for small sections that really need it.

> 
> Here's another major one:
> 
> - templates
> 
> These things confuse the heck out of my new programmers.  It is the single most confusing thing in C++.  That would be OK if they were really powerful, but templates simply don't have much power compared to full code generators.  Why not add support for code generators to the language instead?  Try doing this with a template: stream out all you data structures to a file in binary.  Do it with 1 line of code.  A code generator can do this, but templates can't.
> 

That kinda surprises me.  In C++ I use templates a lot and they're the most powerful feature in the language I think.  My biggest complaint would be the lack of a native way to specify constraints -- I hate seeing huge piles of error messages spilled out in front of me.  (A huge problem when you use something like MSVC6, which is well known for being such a POS C++ compiler.  Witness the proliferation of "c++filt" scripts/programs).  I like how the problem is solved in C#; they use a keyword "where" after the template declaration to specify what valid inputs are.

Not sure what to say about your code generator comment...  templates aren't that, so I don't see how they can be compared.

Thanks for the reply.  Reasonable points of view...  To answer your questions:

>>- Assignments in expressions: I accidently type if(a = b) much too often... and when I'm reading code, I often fail to see the assignment.
>>
> 
> 
> What would you suggest instead? ":="
I don't like to write assignments anywhere but in a variable declaration or an assignment statement.  If I could convince everyone to program like me, I'd simply make the following syntax illegal:

    if(x = y)

Of course, these kinds of things are minor issues, and nothing to get worked up about.

>>- templates
>>These things confuse the heck out of my new programmers.  It is the single most confusing thing in C++.  That would be OK if they were really powerful, but templates simply don't have much power compared to full code generators.  Why not add support for code generators to the language instead?  Try doing this with a template: stream out all you data structures to a file in binary.  Do it with 1 line of code.  A code generator can do this, but templates can't.
>>
> 
> 
> That kinda surprises me.  In C++ I use templates a lot and they're the most
> powerful feature in the language I think.  My biggest complaint would be
> the lack of a native way to specify constraints -- I hate seeing huge piles
> of error messages spilled out in front of me.  (A huge problem when you use
> something like MSVC6, which is well known for being such a POS C++
> compiler.  Witness the proliferation of "c++filt" scripts/programs).  I
> like how the problem is solved in C#; they use a keyword "where" after the
> template declaration to specify what valid inputs are.
> 
> Not sure what to say about your code generator comment...  templates aren't
> that, so I don't see how they can be compared.

Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).

Code generators in a program like the Rational Rose class diagram editor or DataDraw have a representation of the program's data structures and are able to generate all kinds of things.  The simple example is a linked list with the next pointer embedded in the child class.  Another is recursive destructor functions.

I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?

Bill Cox

Bill Cox wrote:
> Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).

The most important thing about templates is that they create different types.  Its also a compile-time strategy.  Yes, I create my own classes that has traits, you want a code generator to place traits and policies in your classes and make a different type?  That would look more complex than C++ I think.  Look at the STL quick sort algorithm, using functors it's faster than any configurable C implementation, since the functor call can be inlined.  I can't a tool to generate that code without thinking about something even more-tool based than VB.  That's not what D is intended to be I think.

> Code generators in a program like the Rational Rose class diagram editor or DataDraw have a representation of the program's data structures and are able to generate all kinds of things.  The simple example is a linked list with the next pointer embedded in the child class.  Another is recursive destructor functions.
> 
> I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?

I don't know for Garen, but where I work we use templates a lot. Implementation of the Multicast pattern (a type-safe event system is something I consider important), compile-time policies and traits, template restrictions (D could have that built-in in language), type-safe containers (even Java is adding generics).  Most of our template uses are done in the basic libraries and applications code contains usually no templates.  I suggest you to look at Alexandrescu's Modern C++ Design, while this book might show the most complicated use of templates, it also shows that templates are not only what you seem to think.

Regards,

Nicolas

Bill Cox wrote:
> I don't like to write assignments anywhere but in a variable declaration or an assignment statement.  If I could convince everyone to program like me, I'd simply make the following syntax illegal:
> 
>      if(x = y)
> 
> Of course, these kinds of things are minor issues, and nothing to get worked up about.
> 

Ah, yeah I do the same thing.  As a general rule of thumb, I think its more readable to write out your code in smaller, simpler steps instead of combining them into big heaps of compound expressions.

> 
> Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).
> 

For the really basic templates you could perhaps write macros for them, but for more sophisticated ones that rely on some kind of compile-time decision making, they're out -- assuming you want a single interface.  (C++ went so far to make the preprocessor unnecessary it would have been nice if they officially deprecated much of its use).

> 
> I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?
> 

At first I just made cursory use of them with the library.  Later when I got curious to see how the stuff was implemented I looked through the source and saw how it worked and then started building my own stuff.  Now I notice that in general when I "refactor" code it tends to go into templates.  I don't think there's any kind of specific problems that I tend to solve with them; just whenever I happen to notice some repetitive pattern, I move it into a template.

In another post I see someone recommended Andre's book -- that one is pretty good, but I'd recommend "C++ Templates: The Complete Guide" by Josuttis & Vandevoorde (new book) over it.  I just finished reading it and it covers all the basics and has a tour through some well known techniques in a tutorial/example style. Some of the more "advanced" techniques that aren't so obvious are probably best to be avoided for the sake of clarity.

Hi, Nicolas.

>> Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).
> 
> 
> The most important thing about templates is that they create different types.  Its also a compile-time strategy.  Yes, I create my own classes that has traits, you want a code generator to place traits and policies in your classes and make a different type?  That would look more complex than C++ I think.  Look at the STL quick sort algorithm, using functors it's faster than any configurable C implementation, since the functor call can be inlined.  I can't a tool to generate that code without thinking about something even more-tool based than VB.  That's not what D is intended to be I think.
> 
>> Code generators in a program like the Rational Rose class diagram editor or DataDraw have a representation of the program's data structures and are able to generate all kinds of things.  The simple example is a linked list with the next pointer embedded in the child class.  Another is recursive destructor functions.
>>
>> I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?
> 
> 
> I don't know for Garen, but where I work we use templates a lot. Implementation of the Multicast pattern (a type-safe event system is something I consider important), compile-time policies and traits, template restrictions (D could have that built-in in language), type-safe containers (even Java is adding generics).  Most of our template uses are done in the basic libraries and applications code contains usually no templates.  I suggest you to look at Alexandrescu's Modern C++ Design, while this book might show the most complicated use of templates, it also shows that templates are not only what you seem to think.

As was mentioned in an earlier post, templates and code generators are really different animals.  I've erred in comparing them so directly. However, the use of the code generator I currently use eliminates the most common use of templates I see: type-safe container classes.  More importantly, it generates better code, since both the parent and child classes are modified, not just the parent.

I'm really happy with what I get with the code generators.  I get: virtually no dangling pointers (auto-generated bug-free recursive destructures); really efficient and type safe containers (really more like relationships - the name container implies the enclosed object is not really collaborating); automatic and truely outstanding memory management; extensive debugging support such as checking each memory access (much like running under Purify, but not as complete); auto-generated itterators with foreach syntax; and VERY importantly - highly efficient dynamic class extensions (dynamic inheritance?).  The dynamic class extensions is huge for us, since our code runs off of a common database, and we often need to extend objects in the database that already have been constructed.  Dynamic extensions are probably about 10x more common in our code than static inheritance.

The code generators we use at work are a major impact on every day coding.  There's just less work to do, and fewer ways to shoot yourself in the foot.

Last time I read a linked list template class in full detail (Rogue-Wave in the late 90's), adding an element to a linked list generated a call to malloc (yuk!).  A linked list should have a next pointer embedded in the child.  The majority of one-to-many relationships need data embedded in the child.  How can templates help with that?

Bill Cox

Bill Cox wrote:
> Last time I read a linked list template class in full detail (Rogue-Wave in the late 90's), adding an element to a linked list generated a call to malloc (yuk!).  A linked list should have a next pointer embedded in the child.  The majority of one-to-many relationships need data embedded in the child.  How can templates help with that?

By using something like boost::array (if I understand your question correctly).

Templates are used to make decisions at compile-time.  You talk about code generation and dynamic inheritance; I don't see the relation since code generation is decisions you take at compile-time, right?  If you take the decision at compile-time, you can do it with templates.  The boost::MPL library is a good example.

By code generation, do you also mean data-driven programs?  If so, I totally agree that they provide many useful features.  Using languages like Python in a C++/D program is also an interesting alternative.  But still, I see D as a language under the hood of what you're talking about and at that level templates have a high value.

Regards,

Nicolas

You're right, flexible code generator is a way to go. This is a common solution for template-like things, as well as implementing new syntactic constructs. This is what i am going to adress. It would also allow writing compilers for other languages, using D as a back end.

Bill Cox wrote:
> Hi, Nicolas.
> 
>>> Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).
>>
>>
>>
>> The most important thing about templates is that they create different types.  Its also a compile-time strategy.  Yes, I create my own classes that has traits, you want a code generator to place traits and policies in your classes and make a different type?  That would look more complex than C++ I think.  Look at the STL quick sort algorithm, using functors it's faster than any configurable C implementation, since the functor call can be inlined.  I can't a tool to generate that code without thinking about something even more-tool based than VB.  That's not what D is intended to be I think.
>>
>>> Code generators in a program like the Rational Rose class diagram editor or DataDraw have a representation of the program's data structures and are able to generate all kinds of things.  The simple example is a linked list with the next pointer embedded in the child class.  Another is recursive destructor functions.
>>>
>>> I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?
>>
>>
>>
>> I don't know for Garen, but where I work we use templates a lot. Implementation of the Multicast pattern (a type-safe event system is something I consider important), compile-time policies and traits, template restrictions (D could have that built-in in language), type-safe containers (even Java is adding generics).  Most of our template uses are done in the basic libraries and applications code contains usually no templates.  I suggest you to look at Alexandrescu's Modern C++ Design, while this book might show the most complicated use of templates, it also shows that templates are not only what you seem to think.
> 
> 
> As was mentioned in an earlier post, templates and code generators are really different animals.  I've erred in comparing them so directly. However, the use of the code generator I currently use eliminates the most common use of templates I see: type-safe container classes.  More importantly, it generates better code, since both the parent and child classes are modified, not just the parent.
> 
> I'm really happy with what I get with the code generators.  I get: virtually no dangling pointers (auto-generated bug-free recursive destructures); really efficient and type safe containers (really more like relationships - the name container implies the enclosed object is not really collaborating); automatic and truely outstanding memory management; extensive debugging support such as checking each memory access (much like running under Purify, but not as complete); auto-generated itterators with foreach syntax; and VERY importantly - highly efficient dynamic class extensions (dynamic inheritance?).  The dynamic class extensions is huge for us, since our code runs off of a common database, and we often need to extend objects in the database that already have been constructed.  Dynamic extensions are probably about 10x more common in our code than static inheritance.
> 
> The code generators we use at work are a major impact on every day coding.  There's just less work to do, and fewer ways to shoot yourself in the foot.
> 
> Last time I read a linked list template class in full detail (Rogue-Wave in the late 90's), adding an element to a linked list generated a call to malloc (yuk!).  A linked list should have a next pointer embedded in the child.  The majority of one-to-many relationships need data embedded in the child.  How can templates help with that?
> 
> Bill Cox
> 

IMO,

if (a=b) {}

is a clear bug, i've stumbled over more than a couple of times. And it's not necessarily easy to track down. Likewise:

int j;
for (int i=1; 1<=max; j++) {}

Well, this is the most stupid example, but it illustrates several things which may actually happen when editing a piece of code a number of times. Well, this example "for" is no use at all and should have no forgiving.

Basically, "dirty constructs" like this are to issue warnings. If someone does this on purpose, a keyword should exist, like "violate" or "crude", which would simply shut off a warning. This could considerably bloat a semantic analyzer though.

A keyword is also some typing, and should slowly discourage even the most eager fans of these dirty tricks.

Some systems use something like a pragma, which shuts all warnings or certain classes of warnings off, and then there usually exists an opposite one to turn them on back again. But IMO this would have no teaching efect, since people would be tempted to turn the warnings off and never turn them on again.




Garen Parham wrote:
> Bill Cox wrote:
> 
>>I don't like to write assignments anywhere but in a variable declaration or an assignment statement.  If I could convince everyone to program like me, I'd simply make the following syntax illegal:
>>
>>     if(x = y)
>>
>>Of course, these kinds of things are minor issues, and nothing to get worked up about.
>>
> 
> 
> Ah, yeah I do the same thing.  As a general rule of thumb, I think its more
> readable to write out your code in smaller, simpler steps instead of
> combining them into big heaps of compound expressions.  
> 
> 
>>Templates are a simple form of code generation: they let you generate new class code with some names substituted. You can do that in C++ with the preprocessor (yuk!).
>>
> 
> 
> For the really basic templates you could perhaps write macros for them, but
> for more sophisticated ones that rely on some kind of compile-time decision
> making, they're out -- assuming you want a single interface.  (C++ went so
> far to make the preprocessor unnecessary it would have been nice if they
> officially deprecated much of its use).
> 
> 
>>I'm curios to know how you use templates.  Are you just using the standard template library, or do you often write your own templates.  If you do, what problems are you solving with them?
>>
> 
> 
> At first I just made cursory use of them with the library.  Later when I got
> curious to see how the stuff was implemented I looked through the source
> and saw how it worked and then started building my own stuff.  Now I notice
> that in general when I "refactor" code it tends to go into templates.  I
> don't think there's any kind of specific problems that I tend to solve with
> them; just whenever I happen to notice some repetitive pattern, I move it
> into a template.
> 
> In another post I see someone recommended Andre's book -- that one is pretty
> good, but I'd recommend "C++ Templates: The Complete Guide" by Josuttis &
> Vandevoorde (new book) over it.  I just finished reading it and it covers
> all the basics and has a tour through some well known techniques in a
> tutorial/example style. Some of the more "advanced" techniques that aren't
> so obvious are probably best to be avoided for the sake of clarity. 
> 
> 
>