On Sunday, 28 December 2014 at 12:10:15 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 24/12/14 15:27, eles via Digitalmars-d wrote:
D2 is still looking for the best design. D1 has one, is not as
good, but is a
safer default.
Honestly, developing in D1, I personally feel that this is not
so much a stable version as a frozen snapshot of a
still-evolving language.
Yes, because D1 is just that. It was already a D2 in the making
at that time and D1 was stopped not because it has reached a
significant milestone, but simply because Andrei bet everything
on D2 and wanted all resources concentrated on it.
But D1 might be dead, the question of stability s experiment
remains.
As Ola wisely observed, the debate is not about D1 per sé, but
about the moving target that one chases when (trying to) use(ing)
D.
Instead of D1 and D2, think D2 and D3 or, if you like, stableD
and experimentD. Place the border between them wherever you want,
but before changing the paradigm of memory management.
In the original comment to which I replied with the proposal of
D1 back again, the trigger was "different build". Just re-read
that post and replace D1 with "different (aka stable) build" and
re-shape the ideas accordingly.
Why that? Well, as Walter stated several times, using a new
memory management technique is not only about having a new
compiler and memory management mechanism. It is also (and mainly)
about *coding style*. When developing for a GC-based language,
one makes some assumptions and writes some code accordingly. When
developing for a RC-based language, one writes *different* code.
And when writing for MM-based language, one structures and writes
another kind of code.
Thing is, by now, most of D2 code that is written is GC-centric.
Supporting that to at least the same level of performance, while
making sure the impact of the new changes that should allow RC
and MM techniques, along with the work on a
precise/concurrent/performant GC, while letting room for the new
memory paradigm to provide optimized code (and not asking changes
in the coding style)... is too much.
Even much too much given the other untied knots that D has: from
properties, multiple aliasing this, re-definition of "scope" and
C++ compatibility. I am sure there are others too.
And you charge this already unstable state with a new mechanism
of memory management that is yet to be designed, not to say about
being written? Now oua re introducing -dip= flags, which could
work as long as they are orthogonal with existing code but... for
how long and how? Will every project come with a .ini file that
will list the dips that are necessary for that project to work?
"This project is not written in D1, but in
D2+dip63,+dip45+dip119v3,+dip23 and incompatible with dip22 and
dip99. For best performance we recommend disabling dip67 and use
the dmd source version 2a2b3c4ddf2a"?
What about tying up the current issues that keep running in
circles, a lot of eternally to be deprecated features and so on?
They will be let for 2025? Will drag properties issues and the
others (*complex types, anyone*?) until then?
Don clearly stated in one of hist posts: "keeping deprecated
features has a cost!". It works for one of the most successful
stories in the D world. Guess its name? Sociomantic!
Now, that said, in practice D1 does feel for the most part very
much like a subset of D2 features; you could code a new project
in D2, using the same design principles, and have pretty much
identical results. So it's entirely fair to see a D success
story here.
Except that porting this subset to its own takes quite some time
for Sociomantics...
With more historical resources, it might have been sane or
possible to backport some of the relevant breaking changes --
that is, to have a D1.5 with the same reduced feature set but
with the inconsistencies and bad design decisions ironed out --
but now that D2 has reached its current state, it doesn't seem
worth it to me.
I agree with that. But the point is, D2 has been also reached a
state where is too much on its plate in terms of contradiction
between "be-production-ready!" and "be-innovative!". Not even to
say "clean up all the dark corners!".
Everybody keeps replying with "that was then and a decision was
made back then!". I am saying "hey! this happens again!".
I suppose that we could, today, divide D2 into a guaranteed
stable subset and a wider range of features whose final design
is still up for discussion, but even that seems non-trivial:
cf. the kerfuffle over whether class methods should be virtual
or final by default. (And no, please don't take this as a
reason to re-open that discussion.)
No, I do not start that discussion. Thing is, you cannot add
zillions of flags that basically make you jumping from a language
to another every time that you compile code. This way, what about
adding some new flags like "-java", "-csharp" and
"-c++1zwithconceptsliteandmodules"?
The only thing that those flags will have in common with D and
with each other will be the fact that they are all braces-family
languages. That, and nothing more than that. (yes, yes, it's an
exaggeration).
