Bartosz Milewski Missing post

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu May 28 08:55:58 PDT 2009


Leandro Lucarella wrote:
> Jason House, el 28 de mayo a las 08:45 me escribiste:
>> I'm really surprised by the lack of design discussion in this thread.
>> It's amazing how there can be huge bursts of discussion on which keyword
>> to use (e.g. manifest constants), but then complete silence about major
>> design decisions like thread safety that defines new transitive states
>> and a bunch of new keywords. The description even made parallels to the
>> (previously?) unpopular const architecture. 
> 
> I just find the new "thread-aware" design of D2 so complex, so twisted
> that I don't even know where to start. I think the solution is way worse
> than the problem here. That's why I don't comment at all.
> 
> I think D duplicate functionality. For "safe" concurrency I use processes
> and IPC (I have even more guarantees that D could ever give me). That's
> all I need. I don't need a huge complexity in the language for that. And
> I think D2 concurrency model is still way too low level.
> 
> I would like D2 better if it was focussed on macros for example.
> 
>> Maybe people are waiting for Walter to go through all the hard work of
>> implementing this stuff before complaining that it's crap and
>> proclaiming Walter should have done in the first place?
> 
> No, I don't see any point in saying what I said above, because I don't
> think anything will change. If I didn't like some little detail, that
> could worth discussing because it has any chance to change Walter/Bartoz
> mind, but saying "I think all the model is way too complex" don't help
> much IMHO =)

On the contrary, we all (Bartosz, Walter, myself and probably other 
participants) think this would be valuable feedback. We'll always have 
some insecurity that we cut the pie the wrong way, and therefore we're 
continuously on lookout for well-argued positives or negatives. Those 
could lead to very useful quantitative discussions a la "X, Y, and Z 
together are way too complex, but X' and Z seems palatable and get 90% 
of the territory covered".

I like Bartosz's design, it's sound (as far as I can tell) and puts the 
defaults in the right place so there's a nice pay-as-you-need quality to 
it. There are two details that are wanting. One is that I'm not sure we 
want high-level race-free so badly, we're prepared to pay that kind of 
price for it. Message passing is more likely to work well (better than 
lock-based concurrency) on contemporary and future processors. Then 
there's a design for solving low-level races that is much simpler and 
solves the nastiest part of the problem, so I wonder whether that would 
be more suitable. We also have immutable sharing that should help. Given 
this landscape, do we want to focus on high-level race elimination that 
badly? I'm not sure.

Second, there is no regard to language integration. Bartosz says syntax 
doesn't matter and that he's flexible, but what that really means is 
that no attention has been paid to language integration. There is more 
to language integration than just syntax (and then even syntax is an 
important part of it).


Andrei



More information about the Digitalmars-d mailing list