[rb-general] Perfectionism gets in the way?

[Ximin Luo]

carlo von lynX:
> Hi there. From the other discussion I gather that I wasn't
> the only one observing a pattern of confusing perfectionism.
> [..]
> 
> Of course, since it is enough that a bunch of people that are
> unlikely to conspire, agree on that. It doesn't matter if others
> are honestly or dishonestly unable to recreate the binary.
> 

I think in certain cases "less is more" is true, but this applies differently to different situations. I myself have seen this principle abused more often, as an excuse not to bother doing something, than it being used for *constructive* purposes. In fact, I would guess that 90% of the computer security problems today, exist because somewhere along the development chain somebody thought "less is more" and didn't take measures to avoid security mistakes.

I would add "less *might* be more, but it's really hard to tell in advance, and generally working-towards-more is better than working-towards-less".

--

For SOURCE_DATE_EPOCH we actually originally settled on a human readable format (one of the RFC / ISO formats, I forget which one it was), until I went and did some research and found that in most programming languages it was far easier to use the UNIX timestamp and there were less timezone issues with using this. (Also random tiny details that leap seconds are omitted from the epoch definition.)

So for BUILD_PATH_PREFIX_MAP, I am taking roughly the same approach by researching and optimising for ease-of-coding on the consumer side first. I think the effort is worth it, though it is boring and can get frustrating at times.

--

I generally never take the position that a harder job ought "not to be done" for "less is more" reasons. In an earlier message I was making the point that nobody is doing true functional compilation today, but in fact I would love it if somebody did it [*] and would never dream of telling somebody who is trying to do that, "don't do that, less is more"; I would shower them with money and praise if I could.

[*] not me, I don't want to it, at least today anyway

One concrete benefit of "true" functional compilation like I defined, is that we wouldn't have to be continually running these reproducibility tests on all packages all the time. If your whole language is pure, you can statically analyse the source code, then you are *very sure* that the resulting compiler + buildsystem always reproduces (is deterministic) for all inputs. (By contrast, with R-B we are only "somewhat sure" it reproduces for certain particular inputs, and we have to continually run tests to be "more sure" as newer versions of these inputs get developed.)

And yes, this is also assuming that your static analyser (or original compiler) isn't buggy, which of course we need to write many tests for. However this is just testing 1 package rather than 25k packages.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git