dmd codegen improvements

[Laeeth Isharc via Digitalmars-d]

On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim 
Grostad wrote:
"I don't have enough time to figure out all the ins-and-outs of 
the current compiler."

"Unless you sell DMD, how about providing a definition of 
"customer"?
If you don't pay attention to evaluations, then surely the 
competition
will steal your thunder and you'll end up as Cobol; on a long tail
in maintenance mode."

Sometimes it's really worth putting energy into ensuring crisp
definitions.  This isn't one of those cases.  Your own language is
exploiting polysemy in an unstraightforward manner - mixing up
different meanings to achieve a rhetorical effect.  Quite clearly
Walter+Andrei listen to what people say, but it doesn't thereby
follow that they should listen to people who think D should go
in a completely different direction based on a very theoretical
view of things and who have no evident experience in writing
a compiler used on a large scale, or in developing a language
community.

It's Business 101 that you shouldn't listen to what most people
tell you, because whilst often well-meaning it's based on an
understanding of things different from the practical situation one
faces and that doesn't always understand what one is trying to
achieve.  It's hard to do that whilst not falling into the other
extreme of not attending to the smallest signs from the right
people when you should, but difficulty is in the nature of such
endeavours.

"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."

Thank the Lord!  I really don't see how anyone can seriously 
believe
that this is an appropriate model for D for the foreseeable 
future.
The essential reason for why it is an attractive language is that 
it
was based on the genius (I mean this in the etymologically-rooted 
sense)
of one, or a few minds and thereby is greatly superior to anything
designed by a committee.  Maybe at some stage this will be an 
appropriate
process to establish, but I do note that even some of those 
involved
in such processes would readily admit that waterfalls are evil, if
necessary at that stage.

>> 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."

This is why you come across as a bit academic and not always 
constructive.
You suggested things weren't developing, and I pointed out that 
they are,
and gave a few concrete examples of how.  You then said that the 
first
attempt wasn't perfect.  But you know, as well as I, that it's in 
the
nature of things that beginnings never are.  It's really tough to 
be
the first to do something (another reason I think you could be a 
little
more respectful towards Walter), but every person that follows 
makes it
some how easier.  There's a slightly mysterious aspect to this, 
but
nonetheless it's true.  D is running on embedded systems, and it
sounds like it was a pain because of the runtime but not because 
of
any horrible flaw in the language that means it cannot be 
considered
a systems language if you want it to be.  I'd be really surprised 
if
it doesn't become easier from here with time.  I like the 
old-fashioned
English virtue of being willing in a discussion to give credit 
where
credit is due.


>>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."

I shared a flat for some time with a pretty smart friend who 
studied
computer science at Trinity, Cambridge (I didn't study computing).
He wrote this - it wasn't a success businesswise, but that's not
  for technical reasons and timing had a lot to do with it:
https://github.com/pythonanywhere/dirigible-spreadsheet

And I have other friends with similar backgrounds, and I have 
hired
and worked with developers, and I am not sure that in the 
enterprise
world a computer science credential has any more incantatory 
standing
than any other degree - and that's probably as it should be.

My point wasn't that D needs to fool gullible people into adopting
it, but rather the opposite.  I always thought smart people should
just be able to see what's obvious, but one sometimes has to learn
the hard way that ideas and products don't sell themselves of 
their
own accord.  You have to make it as easy as you can for your
potential customers to appreciate what the value is for them in
adopting what it is you would like them to explore.  Part of that
is that people naturally think differently, and also that what's
obvious from the inside simply isn't from the outside.  CTOs are
not gifted with some magic ability to see through appearances to
the Platonic essences of things.  They are human and have a tough
job.  So one needs to make an effort if they are to easily 
appreciate
the value.

This is a point John Colvin made with regards to scientists in
his dconf talk.  And, on balance, I rather think that scientists
are a little less concerned about appearances than enterprise 
people.
And if it's true for them - which it is - it's all the more true 
for
the enterprise.

"I am not calling D a toy language"
"As it stands today both Rust and D falls into the category 
toy-languages."

Make up your mind.

Or better, think for a bit about whether a different approach 
would be
more effective.

Of course you know that you're using a pejorative term 
(depersonalizing
it as if it is something objective doesn't change that), and 
asserting
it to apply without any kind of argument for it.  A toy is 
something
that is suitable for entertaining children, but not something to 
be
used be a serious craftsman or businessman.  Since serious people
have built their businesses around it (Sociomantic alone being 
$200mm
EV), you must be fully aware that it can hardly be a toy.  I 
gather you
think market share is critical - it's reasonable for you to think 
that,
but not to suggest that it's the only reasonable way of looking 
at the
world.  Myself, I side with Thiel,who at least must be considered 
a
serious thinker, and to have some insight regarding the diffusion 
of technologies and the creation of new enterprises.


> When you get fracturing related to code base quality, licensing
> or language semantics, you have development strategy issues that
> cause fracturing (you also have private fors like ketmar's).

You're really reaching now.  In a community that draws creative 
and
curious people something would be wrong if people didn't fork the
compiler and experiment.  Now if there's mass adoption of 
different
forks and warring tribes, perhaps that's different.  (War is
generative, too, but the costs are too high for this to be 
sustained
for long).

But this simply isn't the case, and it strikes me that you're
manufacturing words to suit how you feel, rather than basing how
you feel on things as they are.

> If you scaled up C++ to D based on resources and usage then C++
> should have 100s of free compilers. You have 2 free C++14 
> compilers.

If you scaled up the institutions and mores of Norway to the size 
of
and conditions applying to the US you would have a very odd 
country
indeed.  That gedankenexperiment may indeed help stimulate the
imagination to understand what one has before one.  But the 
conditions
of D are different from those of C++, since the two non-dmd 
compilers
were written, as you know, to benefit from the code generation
capabilities of other projects.  One may legitimately have the 
view
that the projects should be consolidated, but one would have to
actually make an argument for it in the Russian style of
  close-reasoning.  As someone said, a statement isn't an argument,
and neither is an analogy to something different.  Also, one's
arguments would need to cohere in this domain, rather than arguing
like a lawyer "1. my client didn't take, let alone steal the vase;
2. it was broken already when he took it; 3. he returned it in
good shape'


"End user back pressure helps. If it does not help, then the
  development process is FUBAR."
My sincere view is that if you adopted a different approach you
would be more effective in your influence.  And there might be
broader beneficial effects too.

" However it does help, Walter is an intelligent man, that enjoys
defending his position"
Patient as he is, I have the impression that the enjoyment is not
saliently on his side of things!