semioticbreakdown

I disagree, I think it's very important. formal verification methods and type systems are powerful but not perfect by any means, and it is still up to the intuitions and domain and technical knowledge of programmers to find mistakes and detect issues. We do test-driven development and it helps some things too, but failed in many other ways, and writing test suites is itself still dependent upon programmers. https://raywang.tech/2017/12/20/Formal-Verification:-The-Gap-between-Perfect-Code-and-Reality/

And every programming abstraction came with tradeoffs, demonstrably so. Assembly to compiled languages, direct memory management to GC, bare HTML and ajax to transpiled javascript frameworks. Bloated electron apps eating up all your memory because no one cared about optimization when you can just load up a framework. There are always situations where the abstractions break down and issues crop up with their underlying implementations or regarding their performance. We've already had issues like this, which is why zero-cost abstractions etc are in vogue, and why formal verification methods even exist in the first place. I do not think the tradeoff of "never having to write function implementations again" and just writing contracts while a machine that can't learn from its mistakes fills in the blanks is worth it. Not knowing what the code is doing because you never wrote assembly by hand is true on some level, so are the issues with GC, and so on.

This isn't what I suggested at all. What I said that the programmer would focus on the specification and understanding what the code is doing semantically. The LLM handles the implementation details of the code with the human focusing on what the code is doing while the LLM focuses on how it does it.

but the how is relevant to the what, and intimately tied to the learning process of good programming as a praxis. Our domain knowledge has always been reproduced through the practice of programming itself. Not having to write any of that does mean you wont understand how it works, and when things go wrong (which they will), the people who wrote it won't be able to do anything about it because they can't. From personal experience, the short time I spent LLM programming made me worse as a programmer because I wasn't actively using my skills, ending up relying on the LLM, and they degraded. Declarative programming, Prolog-style inference, these have always been good tools, but they have also always had flaws that required good programming knowledge to work around, and set up correctly. COBOL forms the backing of our banking system and no one wants to touch it because everyone who actually worked with it retired and/or died. Fortran is still in use everywhere. Assembly and C are relegated to arcane arts instead of the foundations that modern software is built on. Fields change and evolve - we were stuck in the paradigm of writing domain ontologies into class hierarchies for 40 years and now that's getting baked into these models, too. I look at trends in software and find LLMs as their extension to be nothing but horrifying. An endless reproduction of the now, with all of its worst flaws. I do not like thinking about how much LLM cheating in college is a thing. I do not trust this stuff at all.