3 ms·
>> But they shouldn’t use that in production. > Why? Generally speaking, because that’s very likely to end up being “pushing for rewrites of things that work”,
by dahart 2y ago
>> But they shouldn’t use that in production.
> Why?
Generally speaking, because that’s very likely to end up being “pushing for rewrites of things that work”, and also a case of not “taking complexity into account when adding features”, and perhaps in some cases “jumping on a new language”, too.
This is an imagined scenario, but the likelihood of someone easily replacing a working compiler in production with something better is pretty low, especially if they’re not a compiler engineer. I’ve watched compiler engineers replace compilers in production and it takes years to get the new one to parity. One person tinkering and learning how to write a compiler almost for sure does not belong in production.
- vdupras 2y ago"parity" is the keyword here. Most of the time, the problem doesn't come from sloppy execution, but ever widening scope of the software. For example, my own "Almost C" compiler[1] is 1137 lines of code. 1137! Can it ever reach "parity" with gcc or even tcc? No! That's specifically not the goal. Do I benefit strongly for having a otherworldly simpler toolchain? hell yeah. The key is scope, as always. Established projects have, by virtue of being community projects, too wide a scope. [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/comp/c.txt https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...
- dahart 2y agoAgreed, parity is a strong constraint. Since the premise under discussion was “production” environments where some kind of parity is presumably required, I think it’s a reasonable assumption. If there is no baseline and it’s not a production situation where parity is needed, then yeah scope can and should be constrained as much as possible. I like the phrase “otherworldly simple”, I might borrow that!
- vdupras 2y agoI don't think that people deciding what goes in "production" are immune to scope inflation. Thinking that we need parity with another software without realizing the cost in terms of complexity of that parity requirement is, I think, a big driver of complexity.