You are deleting the document from your computer.

In some instances this could be a file on disk. But it does not have to be.

It's not deleted. I already have a.txt. I edit it then quit without saving. a.txt is still there.

Since 10.7 it autosaves.

The Delete button is shown, and correct, for new files that have not been saved at all yet.

Oh you're right. And if I enable "ask to keep changes when closing documents," it asks me if I want to "revert changes" when I quit, not "delete." That even survives a force-quit, so on-disk the file was autosaved, but it still remembers that the changes are in an uncommitted state.

Weird thing is with the setting disabled, quitting TextEdit with multiple new docs open asks if I want to "delete and quit," but Numbers only lets me "save and quit." Even if I press that, Numbers reopens those in a still-uncommitted state. So from all the CSVs I've opened in Numbers and messed with, I have literally 100 pending docs and can only get rid of them by clicking through every single one.

Producing more tokens means charging more money to solve a given task.

Do you believe this is a significant part of the increased GutHub traffic, people’s personal software?

Are non-coders these days aware that they should use version control (and push their code to GitHub)? Or does their agent helpfully suggest setting up a GitHub repo?

Thanks for sharing. It was a fun read, and relatable.

I don’t think launching Go today would have been better than 15 years ago.

Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.

I mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.

There is no disconnect and your comment does not attempt to explain why this is some sort of contradiction.

Read it twice then

Snake oil salesmen of all kinds make money all the time.

What does that have to do with providing value?

It’s find for actions and workflows as long as you do no interpolation and logic.

Better move as much of that as possible into your own scripts. And your scripts can be portable between forges, and even run locally!

The YAML spec/parse _itself_ does interpolation and logic - incorrectly in some cases. YAML is pretty much never the right solution.

Assigning an env var to an empty variable (env: { myvar: ${{unsetfoo}} }) should trigger an error, not silently pass an empty string.

What does that have to do with YAML?

It has to do with the gha bastardization of yaml, which clearly learned nothing from ansible's deficiencies.

> It’s find for actions and workflows as long as you do no interpolation and logic.

How do you specify actions and workflows without interpolation and logic kind sir?

Run the same script for all of the workflow triggers and pass relevant vars into the script as environment variables.

They should replace the unicorn image with a horse or at least a zebra during ongoing incidents.

Donkey, surely.

There is not simply one government in the US.

It seems the federal executive admin is censoring government websites of all levels and branches of government.

> by decomposing problems and identifying optional solutions and weighing the solutions based on various risks, trade-offs and tolerances.

This is how all people solve problems. Now everyone are not great at all parts, but this really is what anyone does.

Surely the title ”engineer” means something else?

Even if engineers were uniquely capable in this regard it still wouldn't equip them to solve problems in fields where they lack domain expertise.

Again: identifying possible solutions to a problem is not "solving" the problem.

You're right. I'll rephrase: Even if engineers were uniquely capable in this regard it still wouldn't equip them to identify solutions, let alone solve problems, in fields where they lack domain expertise.

I have a bachelor's and masters in engineering and was never taught to "hack it" without regard for how a solution is reached.

Documenting and analyzing your solution is an extremely important part of managing risk, which is what engineers actually do.

Not everyone is going to school for engineering.