www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D growing pains (was Re: The Demise of Dynamic Arrays?!)

reply Kevin Bealer <kevinbealer gmail.com> writes:
retard Wrote:

 Tue, 15 Dec 2009 09:42:26 -0500, Steven Schveighoffer wrote:

 Most likely Walter won't even tell what kind of arrays D2 will have. 
 Anything can happen. The final word is the undocumented executable you 
 can download when the book hits stores. Even then dmd's behavior isn't 
 the final word, it might as well be a bug.

I find following D these days to be interesting but occasionally frustrating. It's a little like talking to a teenager who is growing so fast intellectually that his opinions change every day. You can't really argue with him because you don't know where he stands on anything if it's been more than a few days since the last conversation. But I think this is clearly a "complaint" that actually works out to an amazing compliment, e.g. that the language is still developing and maturing so much, and the changes seem well thought out, too. Congrats, Walter and Andrei! (If a teenager was already stuck in his ways mentally at 15 yrs old, it would be a much worse thing!) I think the new const regime, thread-local data as the default, easy code generation, opDispatch etc etc have enormous power and newness. For this reason I think that the stable set of "best practices" for working in D2 will take a while to settle down unless there is a lot of effort put into designing them somehow (if that's even possible). I find it hard to imagine what the average D programming style might look like a few years out in a 'typical work place'. Maybe this settling-out can't happen until a lot of D code is traded among both D experts and also more "middle" level developers. It seems like the best practices and "expected" usage for C++ and Java are often driven by the friction between people who are at different skill levels. The best (or just most common) practices seem to follow the "don't surprise me" principle, which probably doesn't coalesce until people have built up some common sets of expectations. Mid level developers (the rank and file of any language community) hate to work with code that is "too clever" to easily navigate through. I think best practices and style guidelines often tend (intentionally or not) to become a bulwark against too much invention and cleverness -- a trade-off of brain cycles to read the code versus expressiveness / compactness / performance / perfectionism. D's feature set has the ability to do enormously clever things. The rank and file maintenance programmer will probably prefer these things at least modularized and packed off into controlled sections of the code. This isn't a criticism, it's more like a house keeping thing, e.g. Thomas Edison's friends probably preferred the chemical batteries and various sharp items to be stored in the cabinets when they stopped by for tea. In general, a house is better suited for "company" if the sharp and useful things are put away. Likewise a code-base is probably more suitable for visits by coders unfamiliar with it's peculiarities when the use of advanced features is somehow kept under control or at least marked as special and surrounded by velvet ropes. To smooth this out, it would help to have the best practices for doing common things in D (e.g. serialization, logging) somewhat documented for the consumption of non-experts. I wonder what a good way of doing this is? Kevin
Dec 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kevin Bealer wrote:
 To smooth this out, it would help to have the best practices for
 doing common things in D (e.g. serialization, logging) somewhat
 documented for the consumption of non-experts.  I wonder what a good
 way of doing this is?

It's really impossible to predict what the best practices would be. Only time and usage will tell. The "best practices" for both C and C++ have evolved significantly over time.
Dec 15 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Only time and usage will tell. The "best practices" for both C and C++ have
 evolved significantly over time.

I hope D2 will change itself a little (into D3) to adapt itself to such "best practices", to make them more natural, more easy to use, etc. Bye, bearophile
Dec 16 2009
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
Walter Bright Wrote:

 Kevin Bealer wrote:
 To smooth this out, it would help to have the best practices for
 doing common things in D (e.g. serialization, logging) somewhat
 documented for the consumption of non-experts.  I wonder what a good
 way of doing this is?

It's really impossible to predict what the best practices would be. Only time and usage will tell. The "best practices" for both C and C++ have evolved significantly over time.

I think D2 is so different from D (and in some important ways, from everything out there) that a new usage style would have needed to be created even if D was already the lingua franca. The question that I find myself thinking is -- is chaos better or is it better to try to establish a particular style of programming (however simply or poorly) in the original books and resources that a programmer will find upon discovering D? Chaos has its appeal of course, but others would say that any initial style that will stick is better than no style. In other words, that you cannot evolve until you cohere. It's hard to choose... On the other hand I suppose Phobos is consistent enough with itself that if people follow that they will have a launch point. Kevin
Dec 17 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Kevin Bealer wrote:
 Walter Bright Wrote:
 
 Kevin Bealer wrote:
 To smooth this out, it would help to have the best practices for
 doing common things in D (e.g. serialization, logging) somewhat
 documented for the consumption of non-experts.  I wonder what a good
 way of doing this is?

time and usage will tell. The "best practices" for both C and C++ have evolved significantly over time.

I think D2 is so different from D (and in some important ways, from everything out there) that a new usage style would have needed to be created even if D was already the lingua franca. The question that I find myself thinking is -- is chaos better or is it better to try to establish a particular style of programming (however simply or poorly) in the original books and resources that a programmer will find upon discovering D? Chaos has its appeal of course, but others would say that any initial style that will stick is better than no style. In other words, that you cannot evolve until you cohere. It's hard to choose... On the other hand I suppose Phobos is consistent enough with itself that if people follow that they will have a launch point.

If naming guidelines are a part of the "coding style" you mention, then Phobos isn't very consistent. I think this needs to be fixed before TDPL comes out, even though the renaming will cause major breakage. This is the last chance to get it right. Some examples: - function naming: std.file.isfile() std.math.isFinite() std.thread.thread_suspendAll() - enum naming std.file.SpanMode { shallow, depth, ... } std.getopt.config { caseSensitive, caseInsensitive, ... } std.json.JSON_TYPE { STRING, INTEGER, ... } std.thread.State { HOLD, EXEC, ... } -Lars
Dec 18 2009
next sibling parent Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Kevin Bealer wrote:
 Walter Bright Wrote:

 Kevin Bealer wrote:
 To smooth this out, it would help to have the best practices for
 doing common things in D (e.g. serialization, logging) somewhat
 documented for the consumption of non-experts.  I wonder what a good
 way of doing this is?

Only time and usage will tell. The "best practices" for both C and C++ have evolved significantly over time.

I think D2 is so different from D (and in some important ways, from everything out there) that a new usage style would have needed to be created even if D was already the lingua franca. The question that I find myself thinking is -- is chaos better or is it better to try to establish a particular style of programming (however simply or poorly) in the original books and resources that a programmer will find upon discovering D? Chaos has its appeal of course, but others would say that any initial style that will stick is better than no style. In other words, that you cannot evolve until you cohere. It's hard to choose... On the other hand I suppose Phobos is consistent enough with itself that if people follow that they will have a launch point.

If naming guidelines are a part of the "coding style" you mention, then Phobos isn't very consistent. I think this needs to be fixed before TDPL comes out, even though the renaming will cause major breakage. This is the last chance to get it right.

TDPL hardly mentions Phobos. There is a lot more time for getting Phobos right. Phobos will get a major overhaul early next year.
Dec 18 2009
prev sibling parent Bane <branimir.milosavljevic gmail.com> writes:
Lars T. Kyllingstad Wrote:

 Kevin Bealer wrote:
 Walter Bright Wrote:
 
 Kevin Bealer wrote:
 To smooth this out, it would help to have the best practices for
 doing common things in D (e.g. serialization, logging) somewhat
 documented for the consumption of non-experts.  I wonder what a good
 way of doing this is?

time and usage will tell. The "best practices" for both C and C++ have evolved significantly over time.

I think D2 is so different from D (and in some important ways, from everything out there) that a new usage style would have needed to be created even if D was already the lingua franca. The question that I find myself thinking is -- is chaos better or is it better to try to establish a particular style of programming (however simply or poorly) in the original books and resources that a programmer will find upon discovering D? Chaos has its appeal of course, but others would say that any initial style that will stick is better than no style. In other words, that you cannot evolve until you cohere. It's hard to choose... On the other hand I suppose Phobos is consistent enough with itself that if people follow that they will have a launch point.

If naming guidelines are a part of the "coding style" you mention, then Phobos isn't very consistent. I think this needs to be fixed before TDPL comes out, even though the renaming will cause major breakage. This is the last chance to get it right. Some examples: - function naming: std.file.isfile() std.math.isFinite() std.thread.thread_suspendAll() - enum naming std.file.SpanMode { shallow, depth, ... } std.getopt.config { caseSensitive, caseInsensitive, ... } std.json.JSON_TYPE { STRING, INTEGER, ... } std.thread.State { HOLD, EXEC, ... } -Lars

I find alias std.file.SpanMode std.file.spanMode; alias std.file.SpanMode std.file.span_mode; etc. usefull in some situations.
Dec 18 2009