December 25, 2017
On Monday, 25 December 2017 at 10:40:09 UTC, Mike Parker wrote:
> On Monday, 25 December 2017 at 10:06:31 UTC, Mike Franklin wrote:
>> On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:
>>
>>>>> D as betterC really is a game changer, for anyone who cares to give it a try.
>>>>
>>>> Yes, it really is.
>>
>> The fact that -betterC exists is a glaring admission that D "got it wrong".
>
> I strongly disagree. D got it right, but when there's a heavy investment in an existing code base, there has to be a strong incentive to port to a different language. The less work required to do so, the lower that barrier becomes.
>
> Support for inner classes was motivated by a desire to make porting Java code easier. Support for COFF was motivated by requests to better integrate with existing Windows toolchains. extern(C), extern(C++), -betterC, and a future "Better C++" are all in that vein.
>
> None of this is evidence of anything D got wrong, but rather that the range of excuses for not adopting D is shrinking.

To clarify Mike's point, the dmd backend was taken from the existing dmc C/C++ compiler, which started in the '80s.  It wasn't written in D because D didn't exist back then!  The backend could be turned into normal GC'ed D, but Walter still supports dmc and I guess it's easier to just port it all to betterC D.

IOW, it's not a matter of what D got wrong that it needs betterC but what those old languages got wrong that D must adapt to, because of all the old C/C++ code out there.
December 25, 2017
On Monday, December 25, 2017 11:18:58 Joakim via Digitalmars-d wrote:
> To clarify Mike's point, the dmd backend was taken from the existing dmc C/C++ compiler, which started in the '80s.  It wasn't written in D because D didn't exist back then!  The backend could be turned into normal GC'ed D, but Walter still supports dmc and I guess it's easier to just port it all to betterC D.

Using betterC, it's fairly easy to port a program over in a piecemeal manner, whereas that's a royal pain if you're using the full language and druntime. Once the port to D is completed, then normal D can be used without problems.

Honestly, I don't think that there's really any reason to use betterC for most programs, but it does make calling D from C much easier, so folks who are in an environment where they need to call D from C/C++ may want to use betterC to make that more reasonable (though at the cost of a number of useful language features). I expect that there will be some indivuals who will latch onto betterC for one reason or another, but I also expect that the vast majority of D programmers aren't going to want to put up with its restrictions. Personally, I don't see much point in using D if I'm going to be restricted to betterC. At that point, I'd much rather just use C++. I might port something using betterC, but that's the most that I'd ever consider. I actually want a fully featured language, and D without a runtime is doomed to be severely crippled even if it doesn't have to be quite as crippled as it is now.

- Jonathan M Davis

December 25, 2017
On Monday, 25 December 2017 at 09:25:46 UTC, Dan Partelly wrote:
> On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:
>
>>>Most of Phobos is actually workable with betterC, it's just that nobody had gone through >>and figured out what is.
>
> Could you "fix" Phobos so it works out of the box regardless with no GC runtime ? Or at least properly label the each thing whatever it works in "betterC' or not ?

WIP: https://github.com/dlang/phobos/pull/5952
December 25, 2017
On 12/25/2017 1:25 AM, Dan Partelly wrote:
> 1. Exceptions can be done "you do not use it, you do not pay for them". Also, compiler switches to diable exceptions totally exist in most compilers.

Those switches exist because it is not free.


> 3. In several extensive C programs I seen, expception handling was used. A poor man's version implemented with setjmp/longjmp, but neverthless was there. And it was very well used, it was not code done by somone who learned a gimmick and abused it everywhere. It was the sanest way to handle errors in that portion of the code. The use was confined where needed.

You can use setjmp/longjmp in betterC. After all, they are just library functions.
December 26, 2017
On Monday, 25 December 2017 at 20:36:56 UTC, Walter Bright wrote:
>
> You can use setjmp/longjmp in betterC. After all, they are just library functions.

This is self evident. However, this was not the point of my post. My point was to refute your statement that no C programmer would care about exceptions. If what you say is true, how comes SEH was used so intensively on Windows by C programmers , and how come many programmers homebreaw their own using setjmp/longjmp to use it?
December 26, 2017
On Monday, 25 December 2017 at 11:18:58 UTC, Joakim wrote:

> IOW, it's not a matter of what D got wrong that it needs betterC but what those old languages got wrong that D must adapt to, because of all the old C/C++ code out there.

Rust is an example of a language that got it right.  It is inherently memory-safe, can interface with legacy code requiring essentially no runtime, and still has optional reference counting, and plans for an optional garbage collector [1].

The key innovation in Rust is that it didn't bake such things into the language.  That's where D got it wrong, requiring D to now back out such things with features like -betterC and @nogc.

There is hope for D, however.  It may be possible to obsolete -betterC, by levereging design-by-introspection directly in the compiler (i.e. the compiler introspects the runtime, or the lack thereof).  I'm researching this and the first of such PRs was recently merged [2].  Following this pattern, it may be possible to use D without the runtime by simply avoiding those D features that require it (assuming I can figure out how to get the implementation right).  Users will be able to implement the full runtime, no runtime, and everything in between.  In other words, pay for only what you choose to use.

Mike

[1] - https://www.rust-lang.org/en-US/faq.html#is-rust-garbage-collected
[2] - https://github.com/dlang/dmd/pull/7395
December 26, 2017
On 12/26/2017 12:40 AM, Dan Partelly wrote:
> This is self evident. However, this was not the point of my post. My point was to refute your statement that no C programmer would care about exceptions. If what you say is true, how comes SEH was used so intensively on Windows by C programmers , and how come many programmers homebreaw their own using setjmp/longjmp to use it?

Standard C has always had setjmp/longjmp, so "exceptions" are part of the language.

SEH is used on Windows because Microsoft designed the Windows API to pretty much force people to use it. Its absence on every other OS suggests it is hardly that desirable.
December 27, 2017
On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:

> Rust is an example of a language that got it right.

Rust got it right for a single, very specialized use case. The cost is that the language is of interest to the tiny fraction of programmers for whom that use case is relevant. Most don't want to read a dissertation on memory management to write Hello World, and having a weirder syntax than Haskell doesn't help either. D is a programming language appropriate for many use cases.
December 27, 2017
rammers homebreaw their
On Tuesday, 26 December 2017 at 23:02:18 UTC, Walter Bright wrote:
>> own using setjmp/longjmp to use it?
>
> Standard C has always had setjmp/longjmp, so "exceptions" are part of the language.

So then why not have first class support for them in language instead of having the programmer go through hoops to use them ?



> SEH is used on Windows because Microsoft designed the Windows API to pretty much force people to use it. Its absence on every other OS suggests it is hardly that desirable.

There where no successful operating system written after NT(1993). It's presence on NT might suggest that it got it right, not that it got it wrong. You and I might **feel** differently on the area. Surely SEH its much better than the state on POSIX in this area.

Besides, the point is the C programmers used this feature. It was not "forced" on you. It was also used in kernel, where it was not "forced" on programmers by any API, since they designed the APIs. Cutler's pose considered OK to pay the price in many situation.

Truth is, It was convenient to use it. This is why people used it. Not that the terrific API design of Windows forced them. I seen programs for NT written in C which barely used any Win API but used SEH. Made code much simpler and easier to maintain imo. __finally alone was a stroke of genius for that time.
December 27, 2017
On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:

> Rust is an example of a language that got it right.  It is inherently memory-safe, can interface with legacy code requiring essentially no runtime, and still has optional reference counting, and plans for an optional garbage collector [1].

I could not agree more with this. It is unfortunate D has dependencies on a garbage collector in language proper and in std.

Of course, only if it wants to go against C/C++, and the fact a -betterC exists suggests that it does. If it wants a place with Java/C# well, then all they have to do is to plug-in an industrial strength GC implementation and live happily ever after.

The situation is a bit weird today for an outsider like me. Make no mistake, outsider first impressions count , even if they contain errors. This is because the adoption of a language will rather be a function of social factors then technical excellence, as I mentioned before on this board

The D personality is mixed:

1. A language and a std depending on GC, but with an imprecise GC (do they really want that marginal speed ??) suggesting they want to go against Java like

2. Promoted as language which can be used with no GC (but practically you cannot, at least not easily because a lot of the core language depends on GC, and what is worst std depends on it too, and made the mistake to put hashes vectors and strings in language proper rather than lib ) . This marketing suggest they care about 0 cost abstractions , but they where an afterthought added when they realized they are useful. Which is weird since they also have second to none compatibility linking against C, which suggest they where aware of how important this whole business is.

3. Now seeing a -betterC mode, which is really 0 cost abstraction and delivers , but
removes from language what it should have been a library in the first place, without providing a library alternative from it and a crippled std.

All could have been prevented by going the C++ route of 0 cost abstraction, and have a stellar std which also offered a GC for those who want it. *ALL* language features could have been implemented in this mode.