On Thursday, 3 September 2015 at 02:30:41 UTC, Laeeth Isharc
wrote:
In my experience grumbling without action doesn't tend to lead
to the change you want in the world. In theory maybe it
should, and someone will listen. But human beings are funny
creatures.
End user back pressure helps. If it does not help, then the
development process is FUBAR. However it does help, Walter is an
intelligent man, that enjoys defending his position, but that
does not mean that he does not listen to arguments and
internalize them over time.
Well how would a dictator of D accomplish that? Probably
porting the compiler to D would be a pretty good start, for a
variety of reasons. That will help with stability,
refactoring, and documentation I should have thought. Not
everyone knows C++, and of those who do, not everyone wants to
write in it.
Dedicating one cycle to porting, another to refactoring and
documentation is a very good start. IFF you focus on that and
stick with it and avoid adding more features as code at the same
time. (Add them to the plan/spec instead.)
By the way, the dmd source code doesn't seem horribly obscure
to read at first glance.
Reading is one thing, making it do what you want another. For
that you need either documentation or "reverse-engineering the
underlying model".
alors ? as you point out, an asm.js backend would be rather
nice to have, and you are by all accounts a low-level guy, so
it shouldn't be hard to do, no ?
I don't have enough time to figure out all the ins-and-outs of
the current compiler. To do that, in reasonable time, I would
need a refactored and documented compiler. (I am also not
primarily a low level person, my background is broad, but my
major was in systems development).
Given that C compilers are still developing, I doubt D will
ever be finished in my useful career. So what ? The facts
speak against your claim, since D is clearly becoming more
polished with every release - just look at the improvements to
the GC within the past year. (Runtime/compiler, whatever).
Oh, I would love for D to follow the trajectory of C. C
development can follow a near-waterfall development model:
1. specification-ratification-cycle
2. specification based gamma-beta-alpha production implementation
3. release
4. non-semantic improvements
D is nowhere near C's conservative fully spec'ed
ISO-standard-based process.
Semantically C does not have many advantages over D, except VLAs
(which I find rather useful and think D should adopt).
Andrei talked about documentation and presentation a little
while back, and we're now in a much better state. Allocators
soon here.
People have got D to run on embedded systems with low resources.
What people can do isn't really all that interesting. What is
interesting is what you can do with little effort and better than
the alternatives. BASIC ran on machines with just a few K's of
RAM, that does not make it a reasonable choice.
enough for my modest needs. I'd honestly bet that a little
more effort to communicate the practical commercial benefits of
D would make much more of a difference than this abstract
stuff. But who am I to say.
I think you underestimate the expections people with a major in
compsci or a significant amount of development experience have.
They care about the actual qualities, not the presentation. Those
are the CTOs you need to convince, not the CEOs.
As it stands today both Rust and D falls into the category
toy-languages. "toy language" is the term academics use to
describe their languages that explore interesting ideas, but does
not have the polish, tooling or commercial backing to take a
significant market share.
