On Tuesday, 30 January 2024 at 00:41:02 UTC, Walter Bright wrote:
> D has the advantage of simple persistence. With enough persistence, you can chop down an oak tree with a cauliflower.

I would prefer not to cut down an oak tree with anything.

So while I don't like your metaphor, I do think you have a point. I have had the impression that the Zig guys are a bit making it up as they go along. I wonder how many, Andrew included, have written compilers before this one. I don't know the answer. But if this is their first, it's likely part of the explanation for the problems.

I'm quite sure that your long experience in compiler writing has had a very positive effect on DMD's internals.

It would certainly slow me down if the edit-compile-debug loop of the compiler was longer than a few seconds.

On Tue, Jan 30, 2024 at 12:25:24PM +0000, deadalnix via Digitalmars-d wrote: [...]
> The question can better be asked in the following form: if we want to reduce errors, do we slow down development speed, in such a way that we can be more careful to not introduce problems at every steps along the way, or do we speed things up, such as it is faster to fix bugs, and therefore more can be fixed.
> 
> The usual answer most would give in the software industry is that one needs to slow down and be more careful. But this is not what the data ended up showing. Quite the opposite in fact!
[...]

My experience confirms this.  When your code-compile-test cycle is slow, you tend to spend more time to write more code / make more changes before compiling and running it.  It's simple practicality: making only few changes means more compile cycles, which means more time spent waiting.  Making more changes means less time spent waiting for the compile cycle.

But since more changes are made, there's more room for bugs.  And the more changes you make means the more combinations you need to test before you discover failing cases.  Due to combinatorial explosion, the chances of catching these cases decrease exponentially the longer the compile cycle is.

When the compile cycle is fast, the incentives shift the other way: you make less changes before compile + test, so you get faster feedback on any obvious bugs in your changes. So problems get caught early and get fixed before they accumulate.  Your mind is also fresher when it's only a small amount of changes -- you still remember the details of what's happening, so you can fix it faster and more accurately.  And since there are less combinations to test with each small change, you're more likely to find failing cases early.

tl;dr: DMD's fast compile times is a killer feature.  It's why I still use it in spite of its suboptimal codegen.


T

-- 
Let X be the set not defined by this sentence...

On Tuesday, 30 January 2024 at 18:33:45 UTC, H. S. Teoh wrote:
> [snip]
>
> tl;dr: DMD's fast compile times is a killer feature.  It's why I still use it in spite of its suboptimal codegen.
>
>
> T

That's also why version-ing unittests is good. It lets you just run the UTs that you need to run. Got a new feature? Put a unique version just for that and run tests on those.

It gets trickier when you're dealing with features that go across multiple modules and such, but nothing that's not do-able. You can also combine them hierarchically if needed.

On Tuesday, 30 January 2024 at 00:41:02 UTC, Walter Bright wrote:
> D has the advantage of simple persistence. With enough persistence, you can chop down an oak tree with a cauliflower.

Will you be livestreaming the next time you need to cut down a tree?