3 ms·
I call the first three paragraphs the “molecule problem.” In construction, most components are standardized, bolts, nuts, screws, roof shingles, etc. Even when
by bearjaws 2y ago
I call the first three paragraphs the “molecule problem.”
In construction, most components are standardized, bolts, nuts, screws, roof shingles, etc. Even when dimensions vary, there’s usually a standard way to interact with materials. For example, rebar has a defined role and behavior when used with concrete.
Programming hasn’t developed that kind of standardization. Instead, we build software at the molecule level: if statements, loops, data structures, or the atomic level (machine code). Each company or project effectively invents its own “materials and standards” for how things are built.
Imagine if every house being built didn't have standard length screws or standardized threading on bolts, it would collapse in years or take 5x longer to build.
Even when we do adopt standard tools like ORMs or frameworks, it still feels like working with molecules instead of nuts and bolts. Best practices exist, but because ORMs and frameworks are so diverse, even knowing one doesn't make switching jobs fast.
Again and equivalent would be that someone putting shingles on a roof in Florida can likely pick up the nail gun and put shingles on a roof in Georgia.
I don’t know what a future where we have our "nuts and bolts" standarized looks like, but I know LLMs are making it infinitely worse because the amount of code being written is beyond exponential at this point.
- hdkdicnsnjes 2y agoThe nuts and bolts will be embeddable DSL’s, they are the only code which does not rot. Put them in a hierarchy with one compiling down into another or several and you have your building.
- layer8 2y agoHow would that not rot and be full of leaky abstractions?
- hdkdicnsnjes 2y agoDoes SQL or regex as a language rot? I’d say the abstraction above using SQL or regex to implement it rots, because it’s not formalised as a language. Does the implementation leak through things like JSON or a EBNF grammar? Performance can be a concern but the implementation doesn’t leak through the language unlike a library api. If you have access to the compiler you can adjust the implementation to get whatever performance you’d like without affecting the abstraction. Edit: JSON is a perfect example of resistance to rot and a good abstraction. You will always be able to read it in any given language because it is a language and not some library. Non DSL code should be considered as compiler output and that is what 99.9% of software devs spend their time writing. They mock people who would write assembly then go and create some fucked type hierarchy in Haskell for some business problem and call it a good abstraction. The complexity just multiplies until we end up with the current state of the industry.
- atmavatar 2y ago"If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization." - Gerald Weinberg