dmd codegen improvements

[Ola Fosheim Grostad via Digitalmars-d]

On Friday, 4 September 2015 at 18:27:14 UTC, Laeeth Isharc wrote:

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

Define your target before designing, that is the essence here. 
This is critical to gain wide adoption. D has been defined to be 
a cross platform system level progrmming language. That is what D 
should be evaluated as. "customer" is a nonsensical term that 
essentially means what?

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

Defining who your target is does communicate what you are trying 
to achieve!

This is critical if you want to evaluate and drive the systems 
development process forward. You cannot fix the process if you 
don't know how you measure progress.


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

You compared D to C, not me. I know many appropriate system 
development models...

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

You are taking this too far, all non-chatoic models have a 
design-implement-evaluate pattern in them that, the difference is 
in how the iterations go.

A language specification is a critical work document that expose 
qualities of the language. Bypassing that affects quality.

At this stage D needs a specification.

> This is why you come across as a bit academic and not always 
> constructive.
> You suggested things weren't developing,

I said that adding performance features during refactoring 
communicates a lack of direction. Macro level refactoring is 
needed and challemging snd takes leadership.

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

It does not matter if it runs on embedded or not, unless your 
"customers" are defined as that market. Nobody serious about 
development cares if D runs on embedded if there are cheaper and 
more suitable alternatives. It only matters if you are the best 
alternative.

Engineers don't look for the next-best solution. They look for 
the best. So to gain ground you need to define your key goals 
with your design.

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

There are so few system level programming languages that the 
landscspe is easy to grasp. People are waiting for mature 
solutions that are better than what they have...

Marketing does not affect this. Focus and improved process does.

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

I said "if D is a toy language". That is not calling it anything. 
But it is, like Rust, a toy language by academic use of the 
phrase which is not a pejorative term, but an affectionate term 
in my book. The pejorative term is to call a language a "hack". 
C++ is a hack. String mixins is a hack. Etc.

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

No. There are plenty of visible artifacts from the process. No 
need to manufacture anything.


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

There is only one community driven C++14 compiler, g++. The other 
ones are primarily commercial.

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

You dont have to consolidate anything. You need to look at the 
causes that has led to fragmentation in the past, so you can 
improve the process today. Then you need to see if you are using 
resources effectively or if you accumulate costs you can remove.

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

And it is wrong, you cannot have process improvement without 
either leadership support, consensus or more likely a high level 
of fuzz (end user pressure).