System programming in D (Was: The God Language)

[Manu]

>
> D is not a compiler, it is a language. Furthermore it is not true that
> DMDs backend is rubbish and there are already more backends than just the
> DMC backend.
>

Sorry, I was generalising a little general in that claim. And where I say
'rubbish', I was drawing comparison to the maturity of C compilers for x86,
which STILL have trouble and make lots of mistakes with centuries of man
hours of work.
DMD has inferior code gen (there was a post last night comparing some
disassemblies of trivial programs with GDC), will probably never rival GCC,
that's fine, it's a reference, I get that.
But to say that using GDC will magically fix code gen is also false. I'm
not familiar with the GCC code, so I may be wrong, but my understanding is
that there is frontend work, and frontend-GCC glue work that will allow for
back end optimisation (which GCC can do quite well) to work properly. This
is still a lot of work for a small OSS team.
I also wonder if the D language provides some opportunities for
optimisation that aren't expressible in other languages, and therefore may
not already have an expression in the GCC back end... so I can imagine some
of future optimisations frequently discussed in this forum won't just
magically appear with GCC/LLVM maturity. I can't imagine Iain and co
extending the GCC back end to support some obscure D optimisations
happening any time soon.

The point I was making (which you seem to have missed thanks to my
inflamatory comment ;), was that I don't have faith that compiler maturity
will solve all these problems in prompt time, and even if they do for x86,
what about for less common architectures that receive a lot less love (as
is also the case in C)?

I make this argument in support of the language expressing optimal
constructs with ease and by default, rather than expressing some concept
that feels nice to programmers, but puts a burden on the
whole-program-optimiser to fix.
For example, virtual-by-default RELIES on whole-program-optimisation to
fix, whereas final by default has no performance implications, and will
produce the best code automatically.

I think it would be nice if you stopped spreading FUD. You seem to have
> reasonable requests.
>

Perhaps a fair request, but I only do this because after a couple of months
now, I have a good measure of FUD, and I receive very little response to
anything I've raised that would make me feel otherwise.
The most distressing thing to me is the pattern I see where most of my more
trivial (but still significant) points are outright dismissed, and the hard
ones are ignored, rather than reasonably argued and putting my FUD to rest.
:)

I also accept that I produce very little evidence to support any of my
claims, so I'm easy to ignore, but this is because all my work and
experience is commercial, private, and I can't easily extract anything
without wasting a lot of work time to present it... not to mention breaking
NDA's. Most problem cases aren't trivial, require a large context to prove
with benchmarks. I can't easily write a few lines and say "here you go".
At some level I'd like to think people would accept the word of a seasoned
game engine dev who's genuinely interested in adopting the language for
that sort of work, but I completely understand those who are skeptical. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120105/c60f2b24/attachment.html>