Abstractions are a way to manage complexity - hiding things is only one way to do that. Deciding how to organize it, when and how to expose it, and when to get out of the way, are all important aspects of designing abstractions.
Good question - and there's been lots of work on this area. See for example property testing and fuzz testing, which can do something similar to what your second paragraph suggests.
You should be able to find a property testing library in your favourite language such as Hypothesis (python), Quickcheck (Haskell), Fastcheck (JS/typescript), etc.
Paint didn't replace charcoal.
Photography didn't replace drawings.
Digital art didn't replace physical media.
Random game level generation didn't replace architecture.
AI generated works will find a place beside human generated works.
It may even improve the market for 'artsy' films and great acting by highlighting the difference a little human talent can make.
It's not the art that's at risk, it's the grunt work. What will shift is the volume of human-created drek that employed millions to AI-created drek that employs tens.
Elm's strengths are its constraints, which allow for simple, readable code that's easy to test and reason about - partly because libraries are also guaranteed to work within those constraints.
I've tried and failed several times to write Haskell in an Elm style, even though the syntax is so similar. It's probably me (it's definitely me!), but I've found that as soon as you depend on a library or two outside of prelude their complexities bleed into your project and eventually force you into peppering that readable, simple code with lifts, lenses, transformations and hidden magic.
Not to mention the error messages and compile times make developing in Haskell a chore in comparison.
p.s. Elm has not been abandoned, it's very active and getting better every day. You just can't measure by updates to the (stable, but with a few old bugs) core.
For a small, unpopular language there is so much work going into high quality libraries and development tools. Check out
Elm is so nice to work in. Great error messages, and near instant compile times, and a great ecosystem of static analysis, scaffolding, scripting, and hot reloading tools make the live development cycle super nice - it actually feels like what the lispers always promised would happen if we embraced repl-driven development.
Agreed. I've run the house using google minis and assistant for years now, and asking assistant to do / about stuff has not improved one iota in that time and has introduced several more quirks and bugs.
Makes me wish I had bet on Alexa or Apple instead.
I work with the regulated drug development industry, and believe there is a useful and important distinction between Quality Control (QC) and Quality Assurance (QA). I wonder if perhaps this distinction would be useful to software quality too.
QC are the processes that ensure a quality product: things like tests, monitoring, metrology, audit trails, etc. No one person or team is responsible for these, rather they are processes that exist throughout.
QA is a role that ensures these and other quality-related processes are in place and operating correctly. An independent, top level view if possible. They may do this through testing, record reviews, regular inspections and audits, document and procedure reviews, analyzing metrics.
Yes, they will probably test here and there to make sure everything is in order, but this should be higher level - testing against specifications, acceptability and regulatory, perhaps some exploratory testing, etc.
Critically they should not be the QC process itself: rather they should be making sure the QC process is doing its job. QA's value is not in catching that one rare bug (though they might), but in long term quality, stability, and consistency.