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

On Sat, Sep 07, 2013 at 05:35:48AM +0200, Ramon wrote: [...]
> 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.
[...]

Don't be sorry; D is really not *that* hard to learn (it's certainly simpler than C++, speaking from my experience!). Once you get a good grip on it, start making pull requests. Make the changes you'd like to see happen. That's what I'm doing. I see a lot of flaws and problems in various areas, but I don't see much value in complaining -- it often only makes people angry and the problem still remains. Instead, I tell myself, OK, I may not know everything about D, but I do know *something* about programming, so I'm going to make the code changes and submit them. If they don't like it, then it's a good opportunity for me to learn how to make my code changes better; if they accept it, even better, I made a difference.

I find that it's much more convincing for me to say "feature X is broken, here's the code change to make it better", than to say "feature X is broken, D sucks, you lazy bums better start working to fix X or else I'm leaving".  It feels good to rant and get it off my chest, but it feels even better to have my changes merged and feature X to get fixed because of me.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy

On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
> I find that it's much more convincing for me to say "feature X is
> broken, here's the code change to make it better", than to say "feature
> X is broken, D sucks, you lazy bums better start working to fix X or
> else I'm leaving".  It feels good to rant and get it off my chest, but
> it feels even better to have my changes merged and feature X to get
> fixed because of me.

My intention was and is not ranting, nor saying D sucks, nor
asking other to do work nor threatening. And this can found
proven in what I wrote.

Your personal attitude, which many others have, too, is one to be
respected and a necessary and productive one. Bot not the only
valid or constructive one.

Neither is there a need to decide; the options are not mutually
exclusive. As a seasoned programmer that I take you to be you
certainly can agree that leaning back and looking, incl. looking
critically at was has been done so far not only is not harmful
but it actually is positive and often even necessary. And you
will quite certainly also degree that a non trivial project will
need some planning and management.

Unlike what you seem to think, my point isn't hitting on D
(actually that's obviously nonsensical as I wrote just yesterday
or today that meanwhile I'm happily humming along with D).
But neither can it be a healthy attitude to ignore less pleasant
things or events. We should ask what's behind it and what we can
make better.

Simply fixing issues one at a time is not a solution per se but
rather one step in solving a problem albeit an important one.
Identifying reasons and patterns is also a step and often one
that considerably enhances the situation.

If today I'm a better devoloper than 20 years ago than not merely
by experience alone but by learning from mistakes and (in my case
an important lesson) by thinking extensively *before* I hack, by
learning the importance of good design and well proven principles
and, last but not least, by learning to recognize patterns in my
errors.

I try to be polite and respectful because I highly value the work
of WB, AA and others but I feel a suspicion that "shut up and
write code!" is not a solution but part of the problem in certain
regards.

But I respect your right to rant *g

A+ -R

On 6 September 2013 19:40, eles <eles@eles.com> wrote:
> On Friday, 6 September 2013 at 17:09:03 UTC, Leandro Lucarella wrote:
>>
>> eles, el  6 de September a las 16:20 me escribiste:
>>>
>>> On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
>>> >On 6 September 2013 14:13, Dicebot <public@dicebot.lv> wrote:
>>> >>On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
>>> >>>
>>> >>>On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
>>> >>>>
>>> >>>>On 6 September 2013 10:35, eles <eles@eles.com> wrote:
>>
>> LDC used to have a --no-runtime switch or something like that, that aborted compilation if a call to the runtime was emitted. I
>
>
> That's good, but is rather a workaround for a limitation of the language. Is D the first language with a compiler unable to compile its own standard library?

And you rephrase that question? I think you asked it wrong. :)


> There is no guarantee in the language that one day even the most
> innocent operation in the language won't require the standard library and
> what compiles with "--no-runtime" today might as well not compile tomorrow.
>

I don't think that's true.  Any compiler operations being moved into the library will be separate from the language keyword. eg: creal -> Complex!real.


> In C or C++, while the standard library is part of the language standard, is not part of the language per sé. It is not part of the compiler, after all. It is provided with.
>

C++ required a minimal runtime as it does emit library calls through code generation (see libcxxrt link earlier in this thread) - there are however compiler switches which mean that the c++ compiler will error if you try to use any of these features.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 7 September 2013 00:17, Ramon <spam@thanks.no> wrote:
> - It's not as consistent as I'd like it to be. phobos seems, uhm, worthy a discussion e.g. concerning at least its design (e.g. layers, OS interface), safety has been a concern but might have profitted by learning more from other languages, etc. Similarly there are bits all over the place but very little consistently implemented. That's another example why I value Iains work so emminently; he has brought us a complete and (at least principally) portable toolchain incl. debugging which is a conditio sine qua non.

You can thank GNU for that portable toolchain too... :o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Sat, Sep 07, 2013 at 08:37:02AM +0200, Ramon wrote:
> On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
> >I find that it's much more convincing for me to say "feature X is broken, here's the code change to make it better", than to say "feature X is broken, D sucks, you lazy bums better start working to fix X or else I'm leaving".  It feels good to rant and get it off my chest, but it feels even better to have my changes merged and feature X to get fixed because of me.
> 
> My intention was and is not ranting, nor saying D sucks, nor asking other to do work nor threatening. And this can found proven in what I wrote.

I did not intend to imply that you were ranting. I was only speaking generally.


[...]
> Neither is there a need to decide; the options are not mutually exclusive. As a seasoned programmer that I take you to be you certainly can agree that leaning back and looking, incl. looking critically at was has been done so far not only is not harmful but it actually is positive and often even necessary. And you will quite certainly also degree that a non trivial project will need some planning and management.

What I said doesn't preclude that. All I'm saying is, *after* you stand back and look at what's there and find it unsatisfactory, you can write some code and then show it to others and say, "The current way we do X is unsatisfactory; here is my code to prove this (or better yet, here's my code to do it a better way)."


> Unlike what you seem to think, my point isn't hitting on D (actually that's obviously nonsensical as I wrote just yesterday or today that meanwhile I'm happily humming along with D).

I never implied that you were hitting on D. As you said yourself, that's nonsensical.


> But neither can it be a healthy attitude to ignore less pleasant things or events. We should ask what's behind it and what we can make better.
[...]

Well yes, what I was saying was just to take it one step further: once you identify the problem, write the code to improve it and show that to others. I don't think that kind of proposal will be easily turned down.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

On 06/09/13 15:11, Iain Buclaw wrote:
> It has always been the case that if you want to enter kernel-space
> with D, you have to drop phobos and implement a more low level
> druntime.  For instance, the GC that comes with D is wholly infeasible
> for use inside a kernel .

To what extent can that situation be improved with respect to Phobos?  The ideal would be to make it non-GC-reliant and agnostic with respect to how the runtime manages memory.

More generally, this makes a case for something like a well defined "dmicroruntime" which can be used as a general solution for embedded and low-level programming.

On 07/09/13 07:33, H. S. Teoh wrote:
> I find that it's much more convincing for me to say "feature X is
> broken, here's the code change to make it better", than to say "feature
> X is broken, D sucks, you lazy bums better start working to fix X or
> else I'm leaving".  It feels good to rant and get it off my chest, but
> it feels even better to have my changes merged and feature X to get
> fixed because of me.

Of course, but many potential users don't have the free time to be able to do this, and even if they do, sometimes the techniques required to make the fix are outside their understanding (and the time required for learning may be prohibitive).

I don't think there's any excuse for ranting, but it's understandable that there can be frustration in circumstances where a user says: "Hey, this feature is broken, having it work is really important for me," and that concern is not reciprocated by the principal developers.

I don't think D is particularly an offender here -- where it is, it's usually down to manpower rather than unwillingness to recognize problems.  But when anything like this happens, it's very demotivating to users.

On 8 September 2013 13:00, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 06/09/13 15:11, Iain Buclaw wrote:
>>
>> It has always been the case that if you want to enter kernel-space with D, you have to drop phobos and implement a more low level druntime.  For instance, the GC that comes with D is wholly infeasible for use inside a kernel .
>
>
> To what extent can that situation be improved with respect to Phobos?  The ideal would be to make it non-GC-reliant and agnostic with respect to how the runtime manages memory.
>

Wouldn't want to change Phobos in any way really, it serves it's purpose.


> More generally, this makes a case for something like a well defined "dmicroruntime" which can be used as a general solution for embedded and low-level programming.

This could be done - don't like the name though. ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 08/09/13 15:04, Iain Buclaw wrote:
> This could be done - don't like the name though. ;)

smalld... ? :-)