layer8

“Keep going” is exactly how many mathematicians achieved success in the past. :)

anything more than you are doing already. I call it "Ghost Cut", and it works like this: pressing ctrl+x fades the selected text and makes it inert—you can't click on the cut text and the cursor just kind of leaps over it, but it is still present in the document. Nothing is placed in the clipboard at this point and there is nothing to undo. If you decide you don't want to paste then hitting escape will restore the text to its active editable state.

What if you press Ctrl+X twice on separate regions and then press Escape (once)? Does it restore the state after the first Ctrl+X? So Ctrl+X pushes on a to-be-cut stack and Escape pops? Probably not.

Anyway, this looks like it means that the inability to undo the change in clipboard state is replaced by the inability to return to an earlier to-be-cut state. Or maybe the editor includes a Vim-like time-travel history that includes the to-be-cut state?

Regarding the clipboard state, given that the clipboard is an OS-level object, for me it makes sense that an application-level or document-level undo doesn’t undo changes in the OS object. Similarly, undo after Save doesn’t undo the change in the file system state. Of course, it’s fine to provide alternative editing operations in addition.

If the outcome is equivalent regardless which choices the LLM made, then these LLM decisions weren’t material for the outcome, and it would be fine for me. If the decisions don’t materially change the result, then it means that I can still reason about the output that will be produced. If, on the other hand, the decisions materially change the output, then this also breaks the ability for the prompter to predict what will be produced.

This is analogous to the compiler example: It generally doesn’t matter which exact variation of machine instructions the compiler chooses to generate from the source code. It doesn’t significantly impact the ability to predict the resulting program’s behavior in detail based on the source code.

This predictability relation is what allows the creator to reason about the creation, to reason about which exact change to apply to the input to effect a precise modification in the output.

In that sense, the robot lawnmower is like a compiler, if it yields the state of lawn that I specified. I largely don’t care if it first moved left or right, the same as I largely don’t care if a compiler translates a multiplication by a power of two with a shift instruction or a multiplication instruction.

However, we use LLMs precisely for their heuristics, for their property to actually make material choices. Therefore LLMs inherently conflict with the ability to reason about which exact input will yield which desired output.

What's the real difference in that gray area? I'm not sure. I think it hinges on something that has to do with making versus asking to be made, even if that line isn't particularly clear.

For me the difference is in the extent that I can reason about how changes in the input affect the observable behavior of the output. When the executable the compiler outputs doesn’t behave in the way I intended, then in 99.99% of cases this is completely on me, and, importantly, I could have predicted it from the source code. Conversely, I can analyze any such misbehavior by reasoning on the source code. This doesn’t hold to any remotely comparable extent for the relation between vibecoded programs and the prompts used to create them.

Influencers have been successfully sued in Europe due to covert advertising.

“Web” implies a structure. And the internet traffic travels physically from country to country. Not being bound to geographical regions is an illusion.

You know that it won’t be doing that, the tech for that either just isn’t there yet, or is more costly than your average purchase.

Most of OpenAI‘s users are using the free tier, and have little incentive to change that.

ads in disguise

These are illegal in most jurisdictions. We need to apply the existing laws.

It will disclose your Apple account address even when you received the email on a different account in the Mail app.

In general it's bad practice for a user to expose someone else's email address to an application provider without consent (email providers being the one necessary exeception, of course), therefore I would abandon that approach in any case.

You could implement read-only access to a workspace via a generated link (containing a UUID or similar), like e.g. a Dropbox link. You would store the link IDs with the workspace, and you can implement (user-configurable) link expiration and such. Since links are shareable, these wouldn't be personalized to the recipient. A recipient who wants more than read-only access would still have to create an account with you and ask the workspace owner for write access.

I disagree in the sense that source code (compiler input) leaves little space as to the behavior of the resulting program. With LLMs, either there is much more implied leeway, in which case I’d argue that it’s different in nature. Or the specs will restrict the LLM output to a similar extent as a conventional programming language restricts a compiler’s freedoms, in which case it’s not clear that LLMs are the most expedient technology for generating that output.

Levels of abstraction actually matter with regard to how much observable behavior they leave unspecified, and with regard to how much control is needed over each respective behavioral aspect.

One problem with that is that it’s difficult to prove motives. So you’re on shaky and disputable ground. It’s much better to point out how the proposed mechanisms are prone to be misused, which is independent of current motives. Get rid of the shaky ground. Saying “these are disingenuous people proposing this” is exactly an attempt at emotional manipulation, in the sense of an ad hominem fallacy.

That’s technically correct, but it still means that someone has to write the formal specs that Claude’s output is verified against, and someone has to design the formal languages the specs are written in. And once you have formal specs that truly covers all aspects that you ever will care about, it’s unclear if you couldn’t instead build a non-LLM mechanism that efficiently and deterministically spits out an implementation of such a spec.

The source code always was the result of that distillation, or at least a crucial part of the result. I’m unconvinced that natural-language specs can replace that role. Even long before LLMs, when writing specs I often resort to some form of formal language to precisely nail down certain parts of the specification. And some parts are always left open, where I know I’ll get to them when writing the code, because they are more effectively solved “in the code” than waterfall-like up front.

You misread what I wrote. My comment is against the argument used, not against what is being argued for. Using the wrong argument diminishes one’s position. I’d prefer the stance against surveillance to not be diminished by such arguments.

While I’m decidedly pro-encryption, I don’t like this argument. If something is the right thing, it would still be the right thing when promoted for the wrong reasons, and if it’s the wrong thing, it’s still the wrong thing even when at present nobody has ulterior motives.

When arguing against surveillance, the arguments should be on its merits, not on whether the current proponents happen to have ulterior motives.

I wonder, if Doom didn’t exist, what would have taken its place for the “can it run X” usage.

The executables built by LLMs should only given access to a restricted test environment by default.

the only time you should ever need the "login" button is on a new computer, or after logging out to switch accounts

That’s still more frequent per customer than signing up.

It only makes sense when prioritizing growth over your long-term customers.

The article discusses how Python uses it for numbers above ~2100 bits for that reason. That’s way beyond your regular floating-point type in terms of precision.

Not everyone is seeing a paywall. Not sure if it’s the adblocker or other factors.

The problem is that you also need multiplication to implement OCR.

You defer to the advice of experts you trust. Which somehow have become harder to come by in terms of signal to noise than 20-30 years ago.

It seems that the writer has standards other than “getting richer”.

Based on comments elsethread, I think what was meant is: You can install it now with “bun upgrade --canary”, or something along those lines.

However, people also report that the canary version doesn’t identify itself as version 1.4.

who cares what language a JS toolset is written in?

Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.

That wasn’t the question. The question is how LLM code review is a huge disruptor. What is it disrupting? At best, with regard to code review LLMs just solve the problems that LLMs create.

It's just to replicate the ritual of ordering food and give you the dopamine that the real process gives you.

I’m confused. How does the food-ordering process give you dopamine? It generally just gives me anxiety due to the uncertainties involved, until the food arrives in good condition, which here it won’t.

The question is whether the balance of white-hat and black-hat LLM bug findings gives us a different enough result from the previous balance of white-hat and black-hat human bug findings to constitute a major disruption.