I don't think anyone would ever say they want "id, id, id"? They would say they want "customer_id, order_id, item_id" or some such. You would then probably say, "we just use 'id' for the id of every item..." but many places that I've worked actually explicitly didn't do that for essentially this reason. Natural joins on "foo_id" "just work" if you don't give every table the same "id" column.
I truly asking, how much cost is this, have been measured?
I suspect is like the issue with fail to measure the whole thing and is just like "my guys that work in the platform also work making my apps and fixing my printer, so when they work in the platform I can`t print" kind of situation, instead of "I have a platform team (that could be like very small) and a apps team, and I ditch the printer in the bin" that I suspect is just reorg correctly the same amount of people.
Today is easy (finally we have Rust, Zig, Odin, Swift, Go etc that show marked improvements), but the op is correct: A lot of progress was stalled because people defend sub optimal tools.
Every time somebody suggest "but C is wrong" the answer was "You should not do the wrong, be careful every time and things will be fine!"
P.D: Yesterday we have pascal/ADA/effiel/ocalm and others, but the major issues is that C/JS should have be improved to remove the bad things, and add the good things. Is not as if what or why to do it was a mystery, it was just the fear and arrogance against change.
And this cause too much inertia against "reinvent the wheel" and too much hate against anybody that even try
Look, is correct to understand that the BEST way, the BEST refactoring of all, is to change to a language + libraries that fix core issues (similar how you can't outrun a bad diet you can't outrun bad semantics)
BUT, also change it means lose a lot of nice things.
For example I move from python to F# and then Rust, for what I say that is now the best overall decision at all, BUT I miss dearly Django (and instant run and REPL)
IF I could get Django (that means transitively use python) and get better type system and perf from it, I could consider it and surely use it, like "python get as swift or go but with rust algebraic types, whatever it means to get here and yet is Django and python. ok?
Is unreasonable? but sincerely, it will nice if the best ideas get retrofitted in other languages because, well, I wish everyone get as more nice things as possible instead of keep with suboptimal options (that is what I say: breaking languages is not something that must be forbidden forever)
Is unreasonable? (I say again) could be, but I think is a good thing to explore. Maybe is not that much, and if at the end things get better, great!
You need to be catastrophically bad to mess something like htmx.
If you are doing things like eCommerce, form heavy, read heavy, websites (the majority) instead of full apps like a paint/game/code editor (that I say should start with htmx and small components with whatever), htmx IS so simple.
What kind of messy backend this projects have that failed it? Because this is the point: htmx is just html with a bit of more interactivity.
To fail with htmx then you MUST has failed to render html well, and if that is the case, with react will be even worst.
An outcome like this suggest that if the project were made in react or similar it will have failed even harder
I can relate, because I have so much things in years that broke left and right, but at the same time (except if you are talking about pre/alphas) I think is unhealthy to be vary of breaking changes.
A language, in special, should be able to do it. Extreme compatibility is the way to make the mistake that is C.
A breaking change that fix something is a investing that extend infinity to the feature.
Fear to do it, like in C, is how you accumulate errors, mistakes, millions of dollars wasted, because is also compound debt.
P.D: I think langs should be fast to break pre 1.0, and maybe have room to do it each 5/7 years. Despite the debacle of Python (that is in fact more reflective of python than of breaking), there should be possible to make a relatively painless sunsetting with good caring
The problem I have with python2 vs python3 wasn't breaking backward compatibility, but that their "solution" for UNICODE strings is such a weird mess (treating string- and byte-streams as something completely separate instead of treating strings as UTF-8 encoded views on byte streams) The only string encoding that matters today is UTF-8, all others are relics from the early 90s and the sooner we get rid of those the better - e.g. Python caused a whole lot of pain for a solution that would have been useful 30 years ago, but not today.
There's another problem that's affecting more than just Python too: grapheme clusters. It turns out that even a sequence of scalars (code points excluding surrogates) isn't always a safe abstraction anymore.
Others said don't work, but mainly if you aim too high.
THIS is exactly how you survive as small/solo company/consultant.
In fact, all my customers wish I have more time to redo most of the tools that they use. (Tipical scenario: "Hey your app that make invoices is neat, why you don't just add a module for our industrial process and because we want to integrate all and you need to add email capabilities then just add a word processor that is like excel, but good")
The "just add" is not only being naive or greedy, sometimes people dream that the few ones they can actually rely could do all already...
Think: I have 20 tables with the column `id`
"I want 'id,id,id'"
is bad UX, and is what here is being argued, then when the syntax guide you: "I want 'FROM a: id'" is better
reply