3 ms·
It'd be wonderful if we could measure the utility of software engineering choices by counting keystrokes or measuring file sizes or putting them in a turbo enca
by feoren 3y ago
It'd be wonderful if we could measure the utility of software engineering choices by counting keystrokes or measuring file sizes or putting them in a turbo encabulator and seeing which one has more modial interaction with its magneto-reluctance. Unfortunately, reality is just too complicated, with far too many tradeoffs to be balanced. I'd recommend deep thought and discussion about the domain over looking at a graph of your codebase's sinusoidal repleneration.
> All that complexity would be better handled via version control fork/branch relationships
Probably not.
- MilStdJunkie 3y agoHoly smokes, my turbo-sarcasmo detector just broke! But yeah, that's more or less the TLDR of my point. The phrase "wrong abstraction" does some heavy lifting, but it's not a bad concept, even if largely a qualitative one. No one should use a single metric to toss ginormous architecture decisions - they're tools to inform educated judgement, not replace it. Re: fork/branch shenanigans, no, you're right, that's not an optimal way to handle variance . . in a normal programming language. In the context of natural language, it's not the same kettle of fish, because, well, lots of reasons, probably the most prominent being the "messy unidirectionality" of NL that's all mish mished with its extremely complex grammar vs constructed languages. Chopping up giant documents into tiny pieces a la CCS[1] systems has made this a stew of problems, but for some reason Leadership is fond of the idea. It's not unlikely that specialized on-prem LLMs are going to nuke the CCS concept from orbit in the next five years, except for those cases where the CCS is a contractual requirement for doing the work. [1] component content systems