mwcampbell

Yeah, I see what you mean now. Sorry.

DTrace was absolutely a product of pre-Oracle Sun, not Oracle.

I hope we can still get to a point where wasm modules can directly access the web platform APIs and get JS out of the picture entirely. After all, those APIs themselves are implemented in C++ (and maybe some Rust now).

> Boilerplate and scaffolding

Have we really reached the limit of how much we can reliably automate these things via good old metaprogramming and/or generator scripts, without resorting to using unreliable and expensive statistical models via imprecise natural language?

> Refusing to use AI out of principle is as irrational as adopting it out of hype.

I'm not sure about this. For some people, holding consistently to a principle may be as satisfying, or even necessary, as the dopamine hit of creation mentioned in the article.

We had Joel Spolsky saying that users don't read back in 2000, around the same time that Steve Krug published _Don't Make Me Think_: https://www.joelonsoftware.com/2000/04/26/designing-for-peop...

So was the learned helplessness already ingrained by 2000? How far back does it go?

Every little detail matters though. In SQL, do you want your database field to have limited length? If so, pay attention to validation, including cases where the field's content is built up in some other way than just entering text in a free-form text field (e.g. stuffing JSON into a database field). If not, make sure you don't use some generic "string" field type provided by your database abstraction layer that has an implicit limited length. Want to guess why that scenario's on my mind? Yeah, I neglected to pay attention to that detail, and an LLM might too. In CSS, little details affect the accessibility of the UI.

So we need to pay attention to every detail that doesn't have a single obviously correct answer, and keep the volume of code we're producing to a manageable enough level that we actually can pay attention to those details. In cases where one really is just literally moving data from here to there, then we should use reliable, deterministic code generation on top of a robust abstraction, e.g. Rust's serde, to take care of that gruntwork. Where that's not possible, there are details that need our attention. We shouldn't use unreliable statistical text generators to try to push past those details.

I disagree on Kubernetes versus ECS. For me, the reasons to use ECS are not having to pay for a control plane, and not having to keep up with the Kubernetes upgrade treadmill.

This idea is a major theme in this story by Robert Kingett: https://sightlessscribbles.com/the-colonization-of-confidenc...

> the actual object-level question ("is this tool useful for this task")

That's not the only question worth asking though. It could be that the tool is useful, but has high negative externalities. In that case, the question "what kind of person uses/rejects this" is also worth considering. I think that if generative AI does have high negative externalities, then I'd like to be the kind of person that rejects it.

What's the name of this DLL? I assume it's separate from the monster chrome.dll, and that the model is proprietary.

Given that it's a 400B-parameter model, but it's a sparse MoE model with 13B active parameters per token, would it run well on an NVIDIA DGX Spark with 128 GB of unified RAM, or do you practically need to hold the full model in RAM even with sparse MoE?

Impressive work.

I wonder if you've looked into what it would take to implement accessibility while maintaining your no-Rust-dependencies rule. On Windows and macOS, it's straightforward enough to implement UI Automation and the Cocoa NSAccessibility protocols respectively. On Unix/X11, as I see it, your options are:

1. Implement AT-SPI with a new from-scratch D-Bus implementation.

2. Implement AT-SPI with one of the D-Bus C libraries (GLib, libdbus, or sdbus).

3. Use GTK, or maybe Qt.

Yes, exactly.

I actually do believe that AI is dangerous, though for different reasons than the ones he focuses on. But I don't think he really believes it, since if he did, he wouldn't be spending billions to bring it into existence.

This is obviously bullshit. If he were really worried about the things he says he is, he'd put the brakes on his company, or would never have started it in the first place.

I was gratified to learn that the project used my own AccessKit for accessibility (or at least attempted to; I haven't verified if it actually works at all; I doubt it)... then horrified to learn that it used a version that's over 2 years old.

Glad to hear that the coming local version of Sprites will be open-source. I hope there will be some way to financially reward that work, aside from buying Fly services that I likely wouldn't use.

I want something like this, but running on my own box. I now have a Linux box with plenty of RAM and storage under my desk. (It happens to be an NVIDIA DGX Spark, but I'm not really interested in passing the GPU through to these sandboxed VMs; I know that's not practical anyway.) Maybe I'll see if I can hack together a local solution like this using Firecracker.

Simple language isn't just for children. It's also good for non-native speakers. Besides, even for those who can understand complex grammar and obscure words, parsing unnecessarily complex language takes extra effort.

In this specific case, I don't think the rewritten version of the document is infantilizing.

> Did Microsoft seriously deprecate BitBlt and 2D draw calls?

Very unlikely. Far too many applications depend on those things. It's more likely that they accidentally changed something subtle that happened to break colorForth.

If you're allowed to say, are you referring to the Windows 10 ports of the iOS apps that were done via Osmeta in 2016, or the earlier WinRT-native version? If the former, that was a non-starter for me and my blind friends due to deep accessibility issues, probably having to do with the Osmeta port/reimplementation of UIKit. Edit to add: And we wanted something that was easier to use with a Windows screen reader than the desktop website, particularly for Facebook proper.

> I still like it -- for systems programming, that is.

Just curious, what language(s) do you prefer for things that you don't classify as "systems programming"?

> the distinction is whether or not something enables me to perform a task, or whether it's just doing the task for me.

I think school has taught us to believe that if we're assigned a task, and we take a shortcut to avoid doing the task ourselves, that's wrong. And yes, when the purpose is to learn the task or the underlying concepts, that's probably true. But in a job environment, the employer presumably only cares that the task got done in the most efficient way possible.

Edit to add: When configuring or using a particular program is tedious and/or difficult enough that you feel the need to turn to an LLM for help, I think it's an indication that a better program is needed. Having an LLM configure or operate a computer program for you is kind of like having a robot operate a computer UI that was designed for humans, as opposed to having a higher-level program just do the higher-level automation directly. In the specific case of the Apache HTTP Server, depending on what you need to do, you may find that Caddy is easy enough that you can configure it yourself without requiring the LLM. For common web server scenarios, a Caddyfile is very short, much shorter than a typical Apache or nginx configuration.

> there is no capital or material cost to push back against complexity

On a thread about software bloat and inefficiency, @josephg once speculated about an alternate universe where Moore's Law stopped decades ago. I've kept thinking about that. Unfortunately, I kept coming up with counterfactuals where important things like accessibility weren't as advanced or (relatively) widespread as they are in this world.

Shouldn't that make us want to fight to simplify our software stacks to the point where we can do analysis by synthesis, building from simple, well-understood parts, again?

Are you saying that frameworks might become less important because LLMs can just generate boilerplate code instead? Or do I misunderstand? Personally, if the vibe-engineering future that some executives are trying to foist on us means that I'll be reading more code than I write directly, then I want that code to be _doubly_ succinct.

This may not be what you're after, but note that egui and Slint have accessibility support (at differing levels of completeness), e.g. for blind people using screen readers, while Ribir and GPUI do not.

What is Sprite in this context?

The thing that always worries me about these clean-slate designs is the fear that they'll ignore accessibility for disabled people, e.g. blind people, and then either the system will remain inaccessible, or accessibility will have to be retrofitted later.

In the spirit of "every non-trivial program will expand until ...", I think preemptively choosing async for anything much more complex than a throwaway script might be justified. In this case, the relevant thing isn't performance or expected number of concurrent users/connections, but whether the program is likely to become or include a non-trivial state machine. My primary influence on this topic is this post from @sunshowers: https://sunshowers.io/posts/nextest-and-tokio/