• eao197 <eao197 intervale.ru> Mar 28 2008
• Georg Wrede <georg nospam.org> Mar 28 2008
• Walter Bright <newshound1 digitalmars.com> Mar 28 2008

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.

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.

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.