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
