> 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.
When I perform a task myself, it will be reproducible, so it is done once and for all for this employer. That probably won't be the case for the LLM, which will change or might be down next week.
> 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?
You can certainly do that if you restrict software to be a mathematical artifact instead of an executable running on one of 3 kernels with different APIs and behaviors, let alone the mountain of dependencies your code will build and link against.
The reality is that the machines we write software for are complex, and trying to abstract it away and simplify it will introduce more abstractions that someone has to understand and deal with when they inevitably leak. It's not all bad, all this shit we're writing makes a lot of money.
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.
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.
I'm actually ok with that if it truly serving the purpose for what a computer should be.
I think those principles would embody the notion that the same thing cannot serve all people equally. Simultaneously, for people to interact, interoperability is required. For example, I don't think everyone should use the same word processor. It is likely that blind people would be served best by a word processor designed by blind people. Interoperable systems would aim to neither penalise or favour users for using a different program for the same task.
I also think for the purpose of piloting a new system I don't mind people chasing whatever aspect of that mission most inspires them. Anything aspiring to be a universal paradigm needs to account for accessibility to have legitimacy in being "for everyone" but that doesn't necessarily have to be the scope when you're starting.
I'd like to think that prioritizing early phase momentum of computing projects leads to more flowers blooming, and ultimately more accessibility-enabled projects in the long run.
Yeah, this is concerning. Although, if the system is architected well, accessibility features ought to be something that can be added as an extension.
What is a screen reader but something that can read the screen? It needs metadata from the GUI, which ought to be available if the system is correctly architected. It needs navigation order, which ought to be something that can be added later with a separate metadata channel (since navigation order should be completely decoupled from the implementation of the GUI).
The other topic of accessibility a la Steve Yegge: the entire system should be approachable to non-experts. That's already in their mission statement.
I think that the systems of the past have trained us to expect a lack of dynamism and configurability. There is some value to supporting existing screen-readers, like ORCA, since power users have scripts and whatnot. But my take is that if you provide a good mechanism that supports the primitive functionality and support generalized extensibility, then new and better systems can emerge organically. I don't use accessibility software, but I can't imagine it's perfect. It's probably ripe for its own reformation as well.
> What is a screen reader but something that can read the screen?
Good screen readers track GUI state which makes it hard to tack on accessibility after the fact. They depend on the identity of the elements on the screen so they can detect relevant changes.
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/
> They’re trained to be far too user led. They don’t challenge you enough.
An anecdote here: I recently had a conversation with Claude that could be considered therapy or at least therapy-adjacent. To Anthropic's credit, Claude challenged me to take action (in the right direction), not just wallow in my regrets. Still, it may be true that general-purpose LLMs don't do this consistently enough.
Just curious, what language(s) do you prefer for things that you don't classify as "systems programming"?
reply