On Fri, Jun 10, 2022 at 07:22:51PM +0000, mw via Digitalmars-d wrote: [...]
> How come the DMD frontend is in such terrible state?

Because:

	https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Selected quotes:

	[...] you can ask almost any programmer today about the code
	they are working on. “It’s a big hairy mess,” they will tell
	you.  “I’d like nothing better than to throw it out and start
	over.”

	Why is it a mess?

	“Well,” they say, “look at this function. It is two pages long!
	None of this stuff belongs in there! I don’t know what half of
	these API calls are for.”

	[...]

	Yes, I know, it’s just a simple function to display a window,
	but it has grown little hairs and stuff on it and nobody knows
	why. Well, I’ll tell you why: those are bug fixes. One of them
	fixes that bug that Nancy had when she tried to install the
	thing on a computer that didn’t have Internet Explorer. Another
	one fixes that bug that occurs in low memory conditions. Another
	one fixes that bug that occurred when the file is on a floppy
	disk and the user yanks out the disk in the middle. That
	LoadLibrary call is ugly but it makes the code work on old
	versions of Windows 95.

	Each of these bugs took weeks of real-world usage before they
	were found. The programmer might have spent a couple of days
	reproducing the bug in the lab and fixing it. If it’s like a lot
	of bugs, the fix might be one line of code, or it might even be
	a couple of characters, but a lot of work and time went into
	those two characters.

	When you throw away code and start from scratch, you are
	throwing away all that knowledge. All those collected bug fixes.
	Years of programming work.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Friday, 10 June 2022 at 19:37:37 UTC, H. S. Teoh wrote:
> On Fri, Jun 10, 2022 at 07:22:51PM +0000, mw via Digitalmars-d wrote: [...]
>> How come the DMD frontend is in such terrible state?
>
> Because:
>
> 	https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
>
> Selected quotes:
>
> 	[...] you can ask almost any programmer today about the code
> 	they are working on. “It’s a big hairy mess,” they will tell
> 	you.  “I’d like nothing better than to throw it out and start
> 	over.”
>
> 	Why is it a mess?
>
> 	“Well,” they say, “look at this function. It is two pages long!
> 	None of this stuff belongs in there! I don’t know what half of
> 	these API calls are for.”
>
> 	[...]
>
> 	Yes, I know, it’s just a simple function to display a window,
> 	but it has grown little hairs and stuff on it and nobody knows
> 	why. Well, I’ll tell you why: those are bug fixes. One of them
> 	fixes that bug that Nancy had when she tried to install the
> 	thing on a computer that didn’t have Internet Explorer. Another
> 	one fixes that bug that occurs in low memory conditions. Another
> 	one fixes that bug that occurred when the file is on a floppy
> 	disk and the user yanks out the disk in the middle. That
> 	LoadLibrary call is ugly but it makes the code work on old
> 	versions of Windows 95.
>
> 	Each of these bugs took weeks of real-world usage before they
> 	were found. The programmer might have spent a couple of days
> 	reproducing the bug in the lab and fixing it. If it’s like a lot
> 	of bugs, the fix might be one line of code, or it might even be
> 	a couple of characters, but a lot of work and time went into
> 	those two characters.
>
> 	When you throw away code and start from scratch, you are
> 	throwing away all that knowledge. All those collected bug fixes.
> 	Years of programming work.
>
>
> T

No it really is bad. Some newer areas are ok but the quality of the code is overall just bad, relies on enormous amounts of mutability, doesn't have a proper opinion about how to resolve symbols (it only has 3 passes), tries to make decision before properly analyzing the problem etc.

The compiler is mostly reasonable semantically because D is a conventional language, but several key parts of the logic are either extremely old messy bits of code that basically cannot be easily changed or types with a very sloppy heritage that lead to an explosion of edge cases all over the place: Array, Struct, and Int32 are all considered to be the same type of thing according to the enum at the heart of the class that represents types, it's ad-hoc "eh just ship it code" that almost no one can be bothered to fix because they've either been scared off from working on the compiler because of aforementioned warts or because they've tried to divide and conquer the cleanup efforts and been told no.

Probably 40% of the bug fixes of the kind you posit are *because* of the frontend being unreliable.

On Friday, 29 April 2022 at 16:03:16 UTC, Paul Backus wrote:
>
> I would hardly call ImportC's implementation "correct" and "complete" at this point, given the large number of outstanding bugs and the fact that it does not even support the preprocessor yet.

For this particular preprocessor issue, I think we should cut the scope where this ImportC's goal is: it should only take the input from cpp's output, .i files, instead of .h files.

1) why should D reinvent the wheels, and waste efforts which all those cpp have put in for the past several decades?

2) otherwise, there are so many C compilers (flavored) headers, does dmd want to handle them all?

After all, this is a D compiler, not a C compiler.


> This is exactly what people mean when they call features of D "incomplete" or "unfinished" or "half-assed": the happy path works, but important features are missing and the edge cases are riddled with bugs.
>
> I'm sure ImportC will improve, given enough time--maybe 3-5 years? But outside of a tiny number of core developers such as yourself who work on D full-time, it is unrealistic to expect an open-source contributor to see a project of that scale through to completion. That's what I really mean by "basically impossible". Not that it literally cannot be done, but that the amount of time and effort required is prohibitive for the vast majority of contributors.

I agree with all the rest, we should really cut the scopes of each D features, and make them stable & mature; instead of 100 ∼95% complete features, users are more happy with 10 100% complete features. Those ∼5% incomplete corner cases will drive users away, esp for production software.

On Friday, 10 June 2022 at 20:00:26 UTC, mw wrote:
> On Friday, 29 April 2022 at 16:03:16 UTC, Paul Backus wrote:
>> [...]
>
> For this particular preprocessor issue, I think we should cut the scope where this ImportC's goal is: it should only take the input from cpp's output, .i files, instead of .h files.
>
> [...]

This is what it does already. It uses the system compiler's preprocessor.

On Friday, 10 June 2022 at 19:37:37 UTC, H. S. Teoh wrote:
> On Fri, Jun 10, 2022 at 07:22:51PM +0000, mw via Digitalmars-d wrote: [...]
>> How come the DMD frontend is in such terrible state?
>
> Because:
>
> 	https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
>
> Selected quotes:
>
> 	[...] you can ask almost any programmer today about the code
> 	they are working on. “It’s a big hairy mess,” they will tell
> 	you.  “I’d like nothing better than to throw it out and start
> 	over.”
>

Joel is assuming that the typical refactoring and maintenance is happening to keep the complexity under control. This hasn't happened in DMD at all.

Joel is right that dev are usually too prompt to pull that card. However, this case is slightly different.

On Friday, 10 June 2022 at 19:52:15 UTC, max haughton wrote:

> No it really is bad. Some newer areas are ok but the quality of the code is overall just bad, relies on enormous amounts of mutability,

"relies on enormous amounts of mutability" of global state / variables?


> ... but several key parts of the logic are either extremely old messy bits of code that basically cannot be easily changed or types with a very sloppy heritage that lead to an explosion of edge cases all over the place

...
> Probably 40% of the bug fixes of the kind you posit are *because* of the frontend being unreliable.

Just curious: how DMD is becoming self hosted in D? it started from scratch, or being translated from the old C++ implementation? where this old mess baggage coming from?

I still feel puzzled:

D is supposed to be a better OO language (read: encapsulation, separation of concerns), and DMD is developed by a number of highly capable very experienced D developers (read: not ordinary programmers), how come DMD is in such a terrible state as if it's done by some average Joel (above)?

No offense, I am just puzzled by this software engineering myth.

On Fri, Jun 10, 2022 at 08:59:38PM +0000, mw via Digitalmars-d wrote: [...]
> Just curious: how DMD is becoming self hosted in D? it started from scratch, or being translated from the old C++ implementation? where this old mess baggage coming from?

DMD was originally written in C++.  There was a period of transition when the code was being auto-transliterated to D with increasing coverage until the result could be compiled. Then when it started passing the test suite, the official repo switched to the D version and dropped the C++ code.

The auto translation, of course, was the absolute minimum needed to get C++-style code to compile as D code.  Since that time, there has been a good amount of refactorings to take advantage of D's features, but a good chunk still remains more-or-less the same as in the C++ days (except with C++ syntax translated to D).  From time to time Walter would refactor bits of this code, taking advantage of D features to make it better, but there's a LONG way to go before it could be considered anywhere close to idiomatic D.


[...]
> D is supposed to be a better OO language (read: encapsulation,
> separation of concerns), and DMD is developed by a number of highly
> capable very experienced D developers (read: not ordinary
> programmers), how come DMD is in such a terrible state as if it's done
> by some average Joel (above)?
> 
> No offense, I am just puzzled by this software engineering myth.

The answer is very simple: historical baggage. It happens to every project that's been around for more than just a few years.


T

-- 
PNP = Plug 'N' Pray

On Friday, 10 June 2022 at 20:59:38 UTC, mw wrote:
>
> ..
> D is supposed to be a better OO language (read: encapsulation, separation of concerns), and DMD is developed by a number of highly capable very experienced D developers (read: not ordinary programmers), how come DMD is in such a terrible state as if it's done by some average Joel (above)?
>
> No offense, I am just puzzled by this software engineering myth.

Nonsense. D .. a better OO langauge??

Do you even know how hard it is, to reason about a D module?

The D module is, apparently, THE single most important abstraction for encapsulation - someone decided to design it this way.

This conflicts with OO principle of being able to encapsulate an objects invariants in its specification. So D, a -betterOOP .. hah!

The D module is designed to encourage shared mutability. There are no means to specifiy, let alone verify and enforce, encapasulated object invariants. They have no 'boundary' inside a D module - by that I mean, any other code in the same module can transgress any boundary that has been specified.

The D 'supremecy' of the D module, encourages exactly what it going on the dmd and phobos source.

Co-operative mutability, is a major source of bugs - always has been, always will be (cause it makes it so difficult to reason about code).

Mutable state subverts encapsulation, makes it more difficult to reason about code, and makes it difficult to scale 'correct' code.

Mutabilty is certainly 'convenient', and oftne necessary, especially in low-level code, but it needs to be approached with greater caution than is what demonstrated in D's source code.

D's module is the result of imperative, co-operative mutability, thinking, not OO thinking.

Please drop this idea, that D is a better OO langauge. It is not.