I feel like I will be using this phone until it crumbles to dust. Apple shows no interest in making decently sized phones. I would support the EU enacting legislation to enforce at least one phone in each lineup to be no bigger than 60 mm x 125 mm. (iPhone Mini is ok, but it's still bigger than what I prefer.)

Smaller and lighter phones are an accessibility concern. Miniaturization has been the goal for computers since they were invented. It is incomprehensible that designers and manufacturers are reversing course. My options right now are basically do nothing or replace my phone with a watch.

If you are implying that programmers who hand code are going the way of carpenters using hand tools, I think I can agree.

These same artisans complain about how bad AI generated code is. The AI is trained on your bad artisan code. It's like they are looking in the mirror for the first time and being disgusted by what they see.

[1]: https://techcrunch.com/2014/03/29/the-internet-is-held-toget...

[2]: https://krebsonsecurity.com/2021/11/the-internet-is-held-tog...

Confusing the *how* and the *what* is very common when discussing specifications, in my experience. Programmers gravitate toward pseudocode when they have trouble articulating a functional requirement.

> Specifications were never meant to be time-saving devices.

Correct. Anyone selling specifications as a way to save time does not understand the purpose of a specification. Unfortunately, neither does the article's author. The article is based on a false premise.

LLMs experience the same problems as humans when provided with underspecified requirements. That's a specification problem.

[1]: https://en.wikipedia.org/wiki/Software_requirements_specific...

[2]: https://en.wikipedia.org/wiki/Formal_specification

To anticipate objections, the conditions keep the software "free for everyone", which is true. But that's still explicitly freedom for the authors. The conditions preemptively eliminate end users who would otherwise find the software valuable. Because it is not freedom for end users.

Having faith that determinism will last forever is foolish. You have to upgrade at some point, and you will run into problems. New bugs, incompatibilities, workflow changes, whatever the case will make the determinism property moot.

But your point stands. There is a period beyond which doing more than learning the fundamentals just becomes toil.

And because formal verification with LLMs is an active area of open research, I have some hope that the old idea of automated formal verification is starting to take shape. There is a lot to talk about here, but I'll leave a link to the 1968 NATO Software Engineering Conference [1] for those who are interested in where these thoughts originated. It goes deeply into the subject of "specification languages" and other related concepts. My understanding is that the historical split between computing science and software engineering has its roots in this 1968 conference.

[1]: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PD...

Bringing a fork in-house and falling behind on maintenance is a very bad idea. The closest I've ever come to that in industry was deploying a patch before the PR was merged.

I also wouldn't agree that proprietary software is in decline. There are niches where the OS, mobile apps, and games are almost entirely proprietary (and that is not changing any time soon). But the most damning problem is that all computer hardware now has multiple layers of subsystems with proprietary software components, even if the boot loader and beyond are ostensibly FOSS.

My take on the cause of proprietary software is "the bottom line". Companies want to sell products and they believe that it's easier to sell things that are not open source. Meanwhile, there are several counterexamples of commercial products that are also open source (not necessarily copyleft), including computer games. The cause of whatever decline you're seeing in proprietary software dominance is unlikely to be the GPL.

No doubt, GPL had some influence. But I would hardly single it out as the force that ensured software stayed open. Software stayed open because "information wants to be free" [2], not because some authors wield copyright law like a weapon to be used against corporations.

[1]: https://opensource.com/article/19/4/history-mit-license

[2]: A popular phase based on a fundamental idea that predates software.

I've hit compiler bugs that behave this way. Here's one from an LLVM upgrade [1]. The test case I discovered apparently took over 20 minutes to compile, up from 26 seconds on stable! Their value tracking algorithm was accidentally quadratic.

[1]: https://github.com/rust-lang/rust/issues/137909

Ah yes, my never-ending crusade to raise awareness that the cost of free (as in effort) dependencies is bloat.

You can make useful tools that are tiny and compile fast [1], but it takes a lot of effort; exactly what developers don't want to spend.

[1]: Like https://github.com/parasyte/hd -- And I wrote about one of the tricks that it uses: https://blog.kodewerx.org/2023/04/improving-build-times-for-...

GTK, Qt, DOM, WinUI 3, Swing, Jetpack Compose, and GWT (to name a few) all provide getters and setters or public properties for GUI state, violating the encapsulation principle [1]. The TextBox/EditBox/Entry control is the perfect example.

The impedance mismatch is that a GUI control is not an object [2]. And yet, all of the object-orient GUI examples listed implement their controls as objects. The objects are not being used for the strengths of OO, it's just an implementation detail for a procedural API. The reason these GUIs don't provide an API like shown in [1] is because it's an impractical design.

"How are you supposed to design an OO TextEdit GUI control if it can't provide a getter/setter for the text that it owns?" Exactly. You're not supposed to. OOP is not the right model for GUIs.

Ironically, SwiftUI doesn't have this problem because it uses the Elm Architecture [3] like React and iced.

[1]: https://www.infoworld.com/article/2163972/building-user-inte...

[2]: From [1], "All the rules in the rule-of-thumb list above essentially say the same thing — that the inner state of an object must be hidden. In fact, the last rule in the list (“All objects must provide their own UI”) really just follows from the others. If access to the inner state of an object is impossible, then the UI, which by necessity must access the state information, must be created by the object whose state is being displayed."

[3]: https://guide.elm-lang.org/architecture/

It is not clear to me why you've quoted "intelligence" or why you separated understanding and answers as having independent intelligences.

But yes, I agree there are limitations. Much like those above that are being researched.

Absolutely! But there is some nuance, here. The failure mode is for an ambiguous question, which is an open research topic. There is no objectively correct answer to "Should I walk or drive?" given the provided constraints.

Because handling ambiguities is a problem that researchers are actively working on, I have confidence that models will improve on these situations. The improvements may asymptotically approach zero, leading to ever increasingly absurd examples of the failure mode. But that's ok, too. It means the models will increase in accuracy without becoming perfect. (I think I agree with Stephen Wolfram's take on computationally irreducibility [1]. That handling ambiguity is a computationally irreducible problem.)

EWD was right, of course, and you are too for pointing out rigorous languages. But the interactivity with an LLM is different. A programming language cannot ask clarifying questions. It can only produce broken code or throw a compiler error. We prefer the compiler errors because broken code does not work, by definition. (Ignoring the "feature not a bug" gag.)

Most of the current models are fine-tuned to "produce broken code" rather than "compiler error" in these situations. They have the capability of asking clarifying questions, they just tend not to, because the RL schedule doesn't reward it.

[1]: https://writings.stephenwolfram.com/2017/05/a-new-kind-of-sc...