d bare bones

[Ramon]

On Saturday, 7 September 2013 at 00:05:08 UTC, Dicebot wrote:
> On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
>> Frankly, when hacking the kernel you use C, period. There are
>> alternatives, Ada for instance but they have a price tag too. 
>> And
>> D, with all the warm feelings we might have for it, is not one 
>> of
>> those alternatives.
>
> Lot of confusion comes from some earlier times when D was 
> implicitly advertised as systems programming language. It 
> simply gave too much hope - one needs to be get engaged deep 
> into kernel/embedded industry to understand how freaking fed up 
> some programmers are from C in that domain. Thus all the 
> frustration - one sees the possibility of final salvation from 
> 60 year old tool stack only to find out that it in practice 
> competes in C# domain.
>
> Which is pretty bold move because it has completely missed 
> possible niche with zero alternatives and thus competence.
>
> Eventually I got used to it and currently only try to make some 
> buzz so that situation won't get even worse - but consequences 
> of false advertising still roam across the internet.

I tried to stay positive but you are right. This is a good 
example for what I meant and for what I perceive throughout 
different spots with D.

It strikes me as hard to understand when very important factors 
seem to be simply ignored. In the embedded world where 1KB can be 
a lot and where one tries to squeeze out another 50us or another 
200 Bytes other laws and priorities are valid than in userland 
where libraries in the MB range are seen as granted.

My point wasn't that C is perfect for embedded. My point was that 
D is the wrong tool there. If, on the other hand, one wanted to 
develop an improved "C2e" for embedded (and probably kernel) that 
language almost certainly would disappoint in the userland 
application development - those two worlds are just too different.

I don't mean to sound blunt but I see another point that rarely 
gets addressed. WB wanted to scratch an itch. That's OK and he 
was free to do that in any way he saw fit or felt fine. But - 
luckily for us - he went further and opened it and wanted, if I'm 
not very mistaken, D to become (more) widely used.
 From that moment on the target audience was to be heard and 
included.

Similarly I value AA's work very highly but I feel that we should 
have 1 (in words: one) complete and widely acceptable toolchain 
on the major platforms - and - have a reliable and reliably 
working version of whatever first before adding and changing 
things. Probably some wouldn't be happy with, say, Scite (with D 
support) and GDB (with D support) and, for instance, not yet 
supporting 64bit linux. But it would be a base to say "You *can* 
work. No let's go and enhance and grow D, it's standard lib and 
it's eco system".

Unfortunately the path chosen led us to a situation where D and 
phobos are somewhat floating, the advertisements aren't honest, 
unmistakable and to the point, and the tools are quite floating 
and often half-cooked or limited, too.

Let me shed light on what I mean from another perspective: There 
is a reason for a language having lots of alpha, broken, and quit 
projects in its environment. It very often (if not almost always) 
translates to: people discovered the language, were attracted by 
the first impression, even had a need for it, invested time, 
efforts, and know-how - and then left.

If we really want D to grow and spread, we will have to see and 
realize that and to think hard about it and about how to improve.

I'm sorry, honestly sorry, that I myself can not (yet) contribute 
much more than thoughts and constructive(!) criticism. I'm 
working on it and - thanks to Iain (I was just a split second 
away from leaving D) - I stayed. That's not much but it's the 
best I can give as a D newbie and it's much more than just 
leaving like so many before me.

Have a nice weekend, everyone -R