digitalmars.D - D growing pains (was Re: The Demise of Dynamic Arrays?!)
- Kevin Bealer (9/14) Dec 15 2009 I find following D these days to be interesting but occasionally frustra...
- Walter Bright (4/8) Dec 15 2009 It's really impossible to predict what the best practices would be. Only...
- bearophile (4/6) Dec 16 2009 I hope D2 will change itself a little (into D3) to adapt itself to such ...
- Kevin Bealer (5/14) Dec 17 2009 I think D2 is so different from D (and in some important ways, from ever...
- Lars T. Kyllingstad (16/32) Dec 18 2009 If naming guidelines are a part of the "coding style" you mention, then
- Jesse Phillips (5/15) Dec 16 2009 I think a good thing to look at is the DIP index page[1]. It shows that ...
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
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
bearophile <bearophileHUGS lycos.com> 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
Walter Bright Wrote:Kevin Bealer wrote: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. KevinTo 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 17 2009
Kevin Bealer wrote:Walter Bright Wrote: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, ... } -LarsKevin Bealer wrote: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.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 18 2009
Lars T. Kyllingstad wrote:Kevin Bealer wrote:TDPL hardly mentions Phobos. There is a lot more time for getting Phobos right. Phobos will get a major overhaul early next year.Walter Bright Wrote: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.Kevin Bealer wrote: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.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 18 2009
Lars T. Kyllingstad Wrote:Kevin Bealer wrote:I find alias std.file.SpanMode std.file.spanMode; alias std.file.SpanMode std.file.span_mode; etc. usefull in some situations.Walter Bright Wrote: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, ... } -LarsKevin Bealer wrote: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.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 18 2009
Kevin Bealer Wrote:retard Wrote:I think a good thing to look at is the DIP index page[1]. It shows that ideas are being added; that the community is being listened to. This has always been true in the past, but now there is something that better organizes and documents that the community does have influence on the language. It is very similar to FRL[2], but it is nice to see the DIP referenced[3] when it comes up for discussion. [1] http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs [2] http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList [3] http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=103609Tue, 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.
Dec 16 2009