H. S. Teoh 
Posted in reply to forkit
| On Tue, May 31, 2022 at 02:07:53AM +0000, forkit via Digitalmars-d wrote:
> On Monday, 30 May 2022 at 18:58:38 UTC, H. S. Teoh wrote:
> > ...
> > And D is the only language where having multiple compilers is said
> > to be a bad thing. C, for example, probably has hundreds of
> > different compilers, yet we never hear anyone complain about why C
> > is bad because it has so many compilers. Or C++, for that matter.
> > Yet for D this is somehow one of the biggest nails in its supposed
> > coffin. Tellingly enough, back in the days when dmd was the only
> > compiler, people were singing lamentations on why having only one
> > compiler was bad. And now this. Let the reader draw his own
> > conclusions. ;-)
> > ...
>
> The problem with 'multiple compilers' is the concept of 'implementation defined' behaviours.
Portable coding practices dictate that code should not rely on implementation-defined behaviours. If you write code that does, be prepared for it to be non-portable.
> With a single compiler, implementation defined behaviours, which would of course exist, are contained to the 'one' compiler, which has obvious benefits for developers, and their customers (and C# is a prime example), as well as the compiler developers and the language designers.
The disadvantage is that the code will rely on said implementation-defined behaviours, resulting in vendor lock-in.
> Of course people like Stroustrup strongly support and argue for the idea of multiple compilers, but his views/arguments really reflect the legacy of C and C++. I don't know that they are relevant to the future ;-)
>
> I don't argue against multiple compilers per se. I argue against compilers having 'different' definitions of behaviours of the same language.
The language spec (ideally) dictates mandatory behaviours, and indicates which construct(s) may have implementation-defined behaviours. If you're writing code intended to target multiple runtime environments, you avoid using these constructs.
> I would like to understand whether this is also a problem with the D programming language (I don't know that it is, but I'd like to know). If it is a problem, then (to keep in context with the subject of this thread), perhaps it is a reason why D is unpopular, given the problems it has created in the C/C++ world of programming.
Your second sentence doesn't from the first, logically. What has implementation-defined behaviours got to do with popularity? When one talks about popularity, the first thing that comes to mind is the question "is language X used by my best friend and my friend's best friend? If not, it sux. If yes, it must be cool, I'll use it." It has little, if anything, to do with technical issues like implementation-defined behaviours. Nobody is gonna go "OMG Java has no implementation-defined behaviours, it must be the best language in the world!!!!111ROTFLMAOBBQ". It's not even a consideration as far as popularity is concerned.
But that aside, D has a lot of facilities built in to help you make your code maximally portable.
- Fixed sizes for integral types, for example, are a prime example of
where D shines over C/C++. In C, `int` can mean anything from a 16-bit
value to a 64-bit value (according to the spec anyway), and char is
("at least 8 bits wide", but could be wider). This leads to all sorts
of silliness like stdint.h that has to spell out
implementation-defined typedefs just so people can write int16_t to be
100% sure they are the expected size. In D, `short` is ALWAYS 16 bits,
so you write `short` once, and you get a 16-bit value, and never have
to worry about "what if on some weird platform `short` is actually 8
bits?". And don't get me started on printf %d specs, which may have
to be written %ld or %lld depending on whether your implementation
makes `long` 32-bit or 64-bit long. In D, `long` is ALWAYS 64-bits.
End of story. No need for stdint.h, no need for insanity like
`printf("%"PRIu64"\n", var);` just to get the right print format.
Heck, std.format.format lets you write "%d" for ALL integral types.
Nonsense like %ld and %lld don't even need to exist in D.
- Then you have std.bitmanip.nativeToBigEndian, et al, to help you deal
with byte order issues. It deliberately returns char[n] instead of
native int types, so that you never accidentally swap byte order more
than once in your conversions.
- Then there are modules like std.process that abstract away much of the
OS-dependent details of spawning a subprocess, etc.. Details that
you'd have to grapple with manually in C/C++.
These are just random items in no particular order that came to mind. D is quite far ahead of C/C++ in terms of reducing implementation-defined behaviour. I think it's unfair to just lump it with C/C++ in terms of "problems caused by implementation-defined behaviour". To be frank, NO language is 100% free of implementation-defined behaviours. (Yes, even Java.) The only ones that are, are academic toys that have no real world applications. As long as you're interacting with the real world in some way, there WILL be implementation-defined behaviours.
But all that is besides the point. I've had my projects compiled with all 3 D compilers without any problems or weirdnesses caused by differences in implementation-defined behaviours. In fact, I freely switch between DMD and LDC when writing D code in the same project -- DMD for the compilation speed, LDC for the runtime speed. I've never run into a case where testing something with DMD exhibited different behaviour from the final executable produced by LDC. I'm pretty sure there *are* some cases where you might run into some differences -- but so far, I haven't encountered any yet. And I do write a fair amount of D code. So this whole hangup about implementation-defined behaviours is IMO unduly exaggerated.
And more to the original point: back in the day when D had only one compiler, the naysayers said that it was the sign that the D ecosystem is small and immature, that's why it only has 1 compiler. Now that we have 3+ compilers (soon to be 4 once SDC gets more release-ready), the naysayers say that it's the reason D is small and unpopular.
I have just one word to describe this: strawman.
T
--
Creativity is not an excuse for sloppiness.
|
Permalink
Reply
