Whatever specific class I am, my play style is definitely “glass cannon”.

Patching a library is fine if you’re building a final executable — something where you know what the final dependency graph looks like ahead of time.

It’s not fine if you’re building a library. You don’t know if a consumer will also want to use an unpatched version of that library, and depending on the scenario that could result in duplicated instances (each with their own internal state), failure to build or load, or mismatches in data layout or function definitions.

I would avoid using a library like that if I could.

Of course, sometimes the person who can make that decision is the creator of npm itself, and says “No I don’t believe I will”: https://github.com/isaacs/jackspeak/issues/20

Just to be clear: My reply was a (sarcastic but not inaccurate) summary of the attitude of the blog post.

“Harm”? What is “harm”? There are only well-made products or not-so-well-made products!

This whole ordeal is going to be quite a wake-up call for some orgs. They spent this whole time thinking they only paid devs to produce code, not to understand it, because the understanding part was invisible to them.

Now they’re like astronauts blasting off to space and not knowing they need to bring oxygen with them, because they’re never seen any.

So in 5 years we’ll all be running v260.182.1?

JS for sure.

It has a reputation among programmers as being a bit of a mess, but I think the reasons behind that reputation are largely irrelevant to your use case.

Basically:

1. It has some bad decisions about basic stuff, like truthiness, equality, coercion. But those aren’t major stumbling blocks, really. When they run into those situations, they’ll probably already be aware that they’re trying something weird and won’t have the same already-developed intuition about “how it should work” that many of us are bringing to the table.
2. Production deployment can easily turn into a Rube Goldberg machine. I think this is mostly what the kneejerk “really? JS?” response is about. Different ES versions, module systems, WASM, dependency hell, transpilers on top of transpilers, and a billion different runtimes. And the fact that everyone and their grandma apparently wants to build a custom DSL on top of JS that requires additional transpiler plugins or codegen steps. But your students won’t have to worry about that shit. Just pick one environment and do that. Maybe warn them that stackoverflow might use different syntax (require vs import) or try to import stuff that doesn’t exist in their environment though.

Yeah, the unfortunate reality is that nobody ever remembers your name on the good posts.

“Oneshotted” apparently originated from hallucinogens — the rare but sad occurrence where people try them once and then completely lose their minds.

But I’ve mostly seen it in the context of LLMs, where it means basically the same thing.

(Also: why did someone downvote your reply?)

I’m not gonna assume a motivation, but yes I have noticed that whenever I wonder “Wow, this reads like the author got oneshotted. Who posted this?” it is codeinabox.

I always enjoy your writing.

I agree with the emerging schism between those two different kinds of developers, and about the Marxist analysis of the different forms of alienation. I’m thankful that you put in the time to identify this and put it into context.

About the premise of “don’t blame the LLMs; the real enemy is capital” though…

There’s a folk wisdom phrase (and maybe thought-terminating cliche) “just a tool” that has always bothered me.

Because as a species, our behavior has changed drastically over the past few thousand years. And it’s not because of genes. It’s because of tools. They shape who we are, and who we can be.

And increasingly, in the digital age, tool-makers are able to embed their philosophies deeply into the tools themselves. Sometimes it’s a top-down deliberate effort, but sometimes it’s a bottom-up battle of random mutations.

Like the gesture priority on the iPhone. They were all-in on touchscreen. So what’s it gonna be: user taps and flicks just a tiny amount… is that a selection event or a scroll event? They chose scrolling.

And thus the inflection point for getting people to keep a mini PC in their pocket at all times carried with it a tiny UX nudge, away from text editing and towards scrolling content.

You can still compose on a phone! But is it fair to say it’s “just a tool”, and you could easily choose to write instead of scroll, when the device itself is running an event handler every time you touch it, just waiting to steer you towards scrolling?

If I can’t convince you (couldn’t blame you), there is a large body of philosophical work on this topic: Heidegger, and Do Artifacts Have Politics? are two good threads.

“The essence of technology is by no means anything technological”

I expect so, yes, that’s the model for handling SoC GPUs on Windows and Linux: treat it like a PCI peripheral. (Use PCI protocol, even though it’s not a PCI connection.)

This make it spend a lot of time managing PCI book-keeping, which doesn’t scale and becomes a performance bottleneck — but, more importantly, a thermal hotspot.

Console OSes don’t coordinate integrated GPUs over PCI, so they don’t have the same thermal issue.

Edit: I should specify: this is x86. ARM SoC GPUs on Linux at least (Idk about Windows) are not treated as PCI peripherals.

Massive waste of the GPU, having it spend so much time handling PCI. I bet that part of the chip heats up like an MF while the CUs are barely getting tickled.

“Open source is dead either way. Do you want to make that bag on the way out or not?” -Sam Altman

You could save the output to bash vars instead of temp files and pass those in using diff <( echo $str1 ) <( echo $str2 )

The point is to create an unambiguous defendant for a court case to challenge the constitutionality of the law.

The messed-up thing about judicial review is that you can’t just go “hey I think this law is invalid”, you need someone to charge you under the law first.

From the title, I expected “AI is killing SaaS, and that’s a good thing”, but it’s mostly about SaaS billing potentially switching from purely seat-based to a mix of seats + a kickback for each instance of valuable <macguffin here> they provide to the customer.

So… kinda misleading, but also I’m not convinced that we are headed that direction, and I’m also not convinced we want to head in that direction.

Their example was software that provides qualified leads. Well, if the vendors get $4k/lead, you can guarantee their criteria for “qualified” is gonna be as loose as they can possibly get away with. (Or, what if their customers are okay with low-quality leads, but they don’t want to pay the same tor both?)

It’s that old chestnut: if a metric is important for the success of your business, then for the love of god do not tie a financial incentive to it.

1Password handles this gracefully

As always: it depends

My first concern with exposing a DB to an authenticated client is incomplete state transitions. Often, a user interaction requires updating multiple DB entities in order to complete properly. Clients can die at any point, but servers should (hopefully) stay alive through one entire request and ensure that the DB goes from one complete valid state to the next.

My second would be: just because you verify that the user is allowed to modify a given record doesn’t mean that all possible DB-level modifications are valid at an application level. That’s where resource-level security is insufficient. Security gaps often consist of having legitimate access to a resource but performing unexpected actions against it.

I don’t know anything about supabase specifically, so I can’t guide you there. But those are the big two security (and data integrity) concerns I’d never stop worrying about in a direct-to-DB scenario.

Well, maybe soon…?