www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: const

reply eao197 <eao197 intervale.ru> writes:
Walter Bright Wrote:

 4. Here's the biggie. Points 1..3 are insignificant in comparison. The 
 future of programming will be multicore, multithreaded. Languages that 
 make it easy to program them will supplant languages that don't. 
 Transitive const is key to bringing D into this paradigm. The surge in 
 use of Haskell and Erlang is evidence of this coming trend (the killer 
 feature of those languages is they make it easy to do multiprogramming). 
 C++ cannot be retrofitted to supporting multiprogramming in a manner 
 that makes it accessible. D isn't there yet, but it will be, and 
 transitive const will be absolutely fundamental to making it work.

Ironically, the transitive const makes multithreading programming harder for me. Just imagine multithreaded messages passing framework which implements publisher-subscriber model. Subscribers work on different threads, so it is necessary to guarantee that message object will not been changed by anyone. A small illustration: // Without const/invariant. class LogChangedNotify { public Log newLog; } class GoodSubscriber : Subscriber { void onLogChange( LogChangedNotify msg ) { log = msg.newLog; } private Log log; } class BadSubscriber : Subscriber { void onLogChange( LogChangedNotify msg ) { msg.newLog = null; } } BadSubscriber easily can change contents of message even if BadSubscriber author doesnít intend to do that. So in D 1.0 the best solution is duplicating each message for every subscriber (but it may be too expensive in the cases of big count of subscribers) or relying on convention that nobody changes messageís contents. D 2.0 could improve the situation a lot: subscribers would receive messages via const (or even better via invariant) references: class BadSubscriber : Subscriber { void onLogChange( invariant(LogChangedNotify) msg ) { msg.newLog = null; // Doesnít compile! } } But transitive const doesnít allow transfer of non-const information via const/invariant message objects: class GoodSubscriber : Subscriber { void onLogChange( invariant(LogChangedNotify) msg ) { // Doesnít compile because this.log is not invariant, but msg.newLog is. log = msg.newLog; } private Log log; } So in my multithreading experience there were a lot of situations where I needed a const object with references to non-const data inside. Because of that I think that sometimes transitivity of const is a barrier for a developer. PS. Iím not a D programmer yet not because D has something or miss something as a language, but because I think that priority #1 should be support of stable release of language (e.g. D 1.0), not the development of D 2.0.
Mar 28 2008
parent reply Georg Wrede <georg nospam.org> writes:
eao197 wrote:
 PS. Iím not a D programmer yet not because D has something or miss
 something as a language, but because I think that priority #1 should
 be support of stable release of language (e.g. D 1.0), not the
 development of D 2.0.

I think that's what we all want. But, (1) in today's /grow or die standing/ world, if D were to stop evolving, we'd miss a heck of an oppornity (to IMHO take over the world ;-) ). If Walter really did move from mainly D2 to solidifying D1, I bet we'd se a mass extinction of (even) D1 folks, overnight, because "there's no future". And (2), since we only have one Walter, what can I say? We've been at it all of this decade here, and a couple of years more is a short time in comparison. Within the next couple of years, there'll simply come a day when we have made all Grand Things into D2, and it'll be some time before the next Really Must Haves are thought of. That's the natural time when D2 (or whatever the version) is frozen and then we have much time on our hands to really polish it and prune the last bugs and minor warts. It won't be as cool or challenging work, but it needs to be done, and that time lends itself naturally to such activities. Manuals, a proper web site, not to mention proper and detailed scrutinizing of Phobos and all "too small to see when busy" things will then get our attention. Historically, we've already seen a few such "plateaus" in D development, but at those times there's always been something grossly missing or wrong with the language, so that we haven't been able to call it a Version Release. (And, of course, the last time we tried it the wrong way: we set a date for the release, and "the week before deadline" Templates flooded the room. Well, we know better now than to slate a release 4 months from now. It's ready when it's ready.) These waves between frenzied development and calmer days will continue indefinitely. It may be that the waves grow bigger (both in caledar time and in lines written), but the pattern will stay the same. Since we don't need to fix arbitrary deadlines for D releases (as a commercial project would have to), we are in a position to go with these waves and make the most of it, instead of paddling upstream at both tides. PS, I think D1 is pretty darn good right now. Sure there are bugs, but if one reads this NG, one inevitably gets the impression there are more and severer bugs than really is the case. Programmers have historically (before www) been satisfied with their compilers, but in the old days that was mainly because any bugs you encountered were hushed and pooh-poohed by the vendor's consultants (and always in a tone of voice like you're the only person on earth to encounter the particular bug -- funnily they still had the workaround already figured out! Or even worse, a patch to fix just this particular bug. I was there, for example SunOS cc.) The total number of known unfixed bugs was a trade secret, and people lived happily /believing/ they use a reasonable compiler. Quality wise, D1 beats the lot hands down already. I bet Walter would have a couple of juicy anecdotes on this.
Mar 28 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
  The total number of known unfixed bugs was a trade secret,
 and people lived happily /believing/ they use a reasonable compiler. 
 Quality wise, D1 beats the lot hands down already.
 
 I bet Walter would have a couple of juicy anecdotes on this.

Yeah, I do <g>. Back in the 80's, I once made the mistake of including with the compiler a text file with a list of known bugs in the compiler. It wasn't long before a lazy journalist did a review of the compiler in a magazine, a review which mainly consisted of copy/pasting the bug list in its entirety. He declared that the existence of that bug list proved the compiler was unstable and unusable. Keeping the bug list secret was a matter of survival. Fortunately, the open source movement has changed the culture. Open source code cannot keep trade secrets, and so the bug list must also be open. Bug lists now are seen as an essential part of good service.
Mar 28 2008