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
