professoretc

In this hypothetical future, why would I (or my business) buy software from any company, when I can just prompt the equivalent into existence myself? We talk a lot about AI killing software engineering as a profession, but if the AI future comes, it will kill software development as a type of business.

But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.

A proof is not like a program. The goal of a program is to "do the thing", thus you can make the argument that it doesn't matter what the code looks like as long as its works right. But the goal of a proof isn't to "do the thing" (where "the thing" is just to print Yes or No), it's to communicate. An unintelligible proof is really just a first draft.

That article (slash advertisement for Speechpad) spends a lot of words not explaining why human captioning is preferable in general to automated captioning. If I, a human, make a mistake in captioning my videos, am I any better off than if I'd used whisper and it messed up?

I think the algorithm recommended Chris to me because of his topology videos, and from there I watched all his "old computing devices" stuff. Something about the Boston accent, the dry humor, and the occasional audio jump-cut make his stuff quite funny.

> And, the US providers seem to all be racing to make that capability inaccessible to anyone who isn't at a Fortune 500 and able to use their "cyber" versions.

Because it's valuable. I'd be surprised if the big providers didn't go even further with this idea. Need your agent to write some C++? Gotta upgrade to the "system developer" package (a $100/mo add-on to your subscription). SQL? You'll need the DBA package. Working with hardware/firmware (or anything that might be construed as reverse engineering or hardware hacking)? You'll need a verified computer engineering account for that.

> Some markdown flavors for example use \(\), which is probably the worst of them to use.

Some markdown flavors say they use `\(\)` but they also use `\` as the escape character, so in practice you have to use `\\(\\)` which is definitely the worst.

The post I was replying to said,

> UB was coined only in the first C standard, in 1989. Prior to that there was no "If you do this, anything can happen".

I.e., the context is, before UB existed as a concept, how would these things be categorized. And I was trying to offer the correction that, before UB existed, it wasn't "all behavior is defined" but rather many behaviors depend on your particular local environment. While that may technically be implementation defined, the current standard requires that implementation defined be documented, and UB-like edge cases were most definitely not documented anywhere consistently in the old days!

More like, "if you do this, what happens depends on your particular combination of hardware, operating system, and compiler. Don't ask us."

"Look around to look around."

Plus, if the LLM goes down (or gets "upgraded" to a model that does the translation differently/wrong), you still have the tool available locally.

They'll qualify their answers in English but as the article mentions, if your prompt asks for a confidence score, that "uncertainty" doesn't translate into low numerical confidence.

If my compiler "went down" I could still think through the problem I was trying to solve, maybe even work out the code on paper. I could reach a point where I would be fairly confident that I had the problem solved, even though I lacked the ability to actually implement the solution.

If my LLM goes down, I have nothing. I guess I could imagine prompts that might get it to do what I want, but there's no guarantee that those would work once it's available again. No amount of thought on my part will get me any closer to the solution, if I'm relying on the LLM as my "compiler".