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