If you expect that you can complete some task just from the keyboard, then the idea of having to use the mouse interrupts what you're doing.

The original post gives "stage and commit in git" as an example. Magit is much nicer than CLI, since you can quickly invoke the actions you want; it's less effort than typing out the full command on the CLI. -- With LLM coding agents, getting an LLM agent to make a commit is slower than doing it yourself in magit (if all you're going to do is stage and commit), but it's much less effort.

I think these things are going to be true:

- For a specific well-defined coding task, an LLM coding agent will be able to execute it quicker than humans, regardless of how it does it.

- Codebases which are well organised will be easier for an LLM to manipulate than codebases which are obscure and surprising.

I mean.. I think it's plausible that something like "lisp makes DSLs easy, DSLs are a great way to arrange code" is especially true with LLMs; but I'd also think you'd need to know when to use (& when to not use) DSLs to get effective results from this.

Whereas, say, you could have the LLM come up with a DSL in a way which is high friction for the LLM to do it ... but, you'd get the result a bit slower, & maybe worse.

This is a useful criticism.

Left to themselves, LLMs prefer writing that's really atrocious. e.g. The writing will try and make everything sound profound.

The other problem I've noticed is e.g. LLMs will write in stuff that's inappropriate for the content of the text. e.g. Writing out stuff that looks like a chat reply, in commentary or descriptions or whatever.

I'd distinguish, though, between "sloppy writing" & "LLM generated writing". I'd agree if you didn't put in the effort to check the writing is of high quality, then perhaps the other parts are also not high quality.

I don't think just because "AI" wrote it it's bad. I wouldn't prefer e.g. sloppy human writing over well-crafted LLM-written text.

This readme the main thing which sticks out is the "what you get" bullet points are rather dense/verbose for bullet points. But aside from that it seems fine.

You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.

With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.

For a personal workstation, it's not necessarily a practical trade-off.

This is somewhat inaccurate, and loosely written.

It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.

Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.

In systems where I've taken complex inputs and transformed it into complex outputs, I'd make it as easy to bring each particular pass under test, have snapshots that the same transformations resulted in the same outputs (insofar as I did want that consistency).

I'd think with a compiler, though, it can still be practical to describe the input you depend on as a value.

In distributed systems, your service might rely on another service which might be broken, might return different values than you expect, might return slower than you expect, etc. and so testing the parts of your system which depend on other services can be tricky.

Point is, you can arrange a lot of your code into "it's easy for me to ensure this part works", and you can see wins from that, even if as a whole the full system can be difficult to bring under test.

Using an LLM doesn't mean "I must write this code in a way that I cannot understand it". I'd encourage using the LLM to write code in a way that you can understand.

> When corporations own it exclusively, they can do whatever they want with it.

This is an argument in favour of open-weight models.

Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?

> Moreover, it's downright offensive for a purported expert to defer their expertise to a SAAS black box.

With programming, it's just the opposite, though.

Programmers work with abstractions. Understanding the full system down to how atoms work is too much to think of when e.g. writing an API handler. So instead you work with modules and their interfaces.

Pre-LLM, if you need some task done, you wouldn't write it all out yourself if there was some external package which did the work for you.

Of course, when using an LLM, you don't need to surrender your ability to think about the problem and solution.

The name of the test should indicate what it's doing.

For unit tests, these should check only one thing, and the test can be structured into "assemble, act, assert" style tests.

On the implementation side: code which touches state is tricky. -- So, minimize the amount of code which touches state (or rather, shift as much code as you can to stateless code, which is easier to bring under test).

I think any of the "JSON + functions" configuration languages mentioned in this thread (there are many) would be just as good.

Writing configurations in a modular way is really neat to be able to do. Rather than having to manage a single YAML file with the resource manifest, you can construct the resource by combining different parts of it.

e.g. rather than { image = "backend", tags = ["backend"] }, { image = "cache", tags = ["backend"] }, you could factor out the `tags`. -- Doing this from a "JSON + functions" language makes more sense than Helm's approach, from my experience.

The module system that NixOS uses builds an abstraction over this: each module declares like { options, config, output }. So the module author defines the option & output, and the module users declare the config, then the system knows how to render the configuration.

If you habitually drink 3 cans of coke a day, and want to lose weight, then switching to coke zero is practically the same benefit, but consumes 430kcal less. Since coke zero is like a zero sugar replacement for typical coke, it makes sense to use "compared to coke" as the baseline.

That's what I meant by "clearly .. nutritionally beneficial". If you'd prefer a different term, then sure.

(I think the proposed alternative of "just eat whole foods and water" is surely going to be even more beneficial, but also requires a change in habits. If "change habits" was easy, I don't think there'd be any discussion around "Ultra Processed Food")

Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.

- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.

- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.

- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.

- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).

- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.

- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..

- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.

- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.

- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.

- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.

So ... some aspects could be easier. But I think there's a fundamental friction to it.

That ... doesn't seem like a concern unique to passkeys, though?

It seems more like a policy rather than a technical aspect.

e.g. A website might decide they will only provide services if you upload a photo of government ID, or pass a verification where you show your face.

If it's software running on someone else's computer, you don't get full control regardless.

If your concern is about your own health as an individual? I want to lose weight now? I think it's useful to say "I have agency, I can lose weight". If you have the agency to lose weight, it makes sense you can take on the responsibility for having gained weight.

"Why did society in general get fatter?" is a different question. And if your main concern is "how can I lose fat?" it's not directly interesting.

That people use resources to help them use tools they don't understand too well is hardly new. e.g. Classically you might copy-paste from StackOverflow after finding an error, or some people watch YouTube videos about it.

I'd say LLMs make it easier to get to the point where you can understand it, though. So it's an accessibility increase.

> It remains so, only now you want people to blindly trust LLM output for this system.

This isn't related to Nix, though. You could ask an LLM to create the most mainstream Python code ever and blindly trusting it would make as much sense.

For system management, Nix has the advantage of being declarative. e.g. For NixOS you get to read the code and review what it's doing.

Pre-LLM: Nix is "high effort, moderate reward". The cost is: you have to learn a tool which does things apparently completely different to how other tools do things.. you have to put up with a lot of friction, pay all the pain upfront, and the benefit is that may be later it's easier to get the package again.

It's just not a practical trade-off for most developers.

With LLMs, the cost-benefit trade-off changes.

You can use this cloud provider's LLM to get you a good result. You get the benefits, and the cost is 'just' "ask the LLM to do it".

Similarly: it's easier to assess whether produced code does the right thing, than to come up with that code from scratch.

Without LLMs? The inaccessibility also comes from being a niche tool. Not many use it, so not many software projects accommodate it or consider it, and you might have to come up with workarounds yourself.

e.g. obviously not practical for everyone but Taub's "Twinkie Study" showed fat 27 lbs of fat loss even from a diet of decidedly calorie-dense food like twinkies and doritos. https://www.psychologytoday.com/us/blog/comfort-cravings/201...

I think that UPF mostly aligns with that in that the food that's "UPF" is generally calorie dense, highly palatable, low satiation.

But...

> He would probably also say that there's nothing inherently bad about diet coke, but there is something bad about getting all your food from people trying to make money instead of from people who love you.

At this point, it seems more a discussion of morals and social values rather than a scientific "how to lose fat".

Last time I looked into this, the strongest research showed "we looked and couldn't find any evidence it's not associated with cancer".

That is, to hear "artificial sweeteners = cancer, I'm better off with the sugary drinks" was the wrong conclusion to take.

A couple of years ago I lost 20kg (~40lb) of body weight.

I find this phrasing odd. -- Should I say "something made me lose 20kg of body weight", or should I say "I was able to improve the food I ate, and I lost 20kg of weight".

I tend to think that even without scientific literature, people know that e.g. lettuce is "healthier" than chocolate cake and fried chicken.

The term "UPF" seems like a weird term that puts the moral responsibility on the food manufacturers, rather than on "us" who are fat and want to lose weight.

For one, for achieving fat loss, it's surely simpler to focus on factors like calories & how full the food makes you. -- With that perspective, yeah it's obvious that fried chicken and sugary chocolate aren't great for your health when eaten frequently.

For another, e.g. it seems that nutritionally, something like "diet coke" is strictly better than the sugar drinks it replaces: you get the same taste, but zero calories. -- I mean, zero-calorie drink is clearly UPF but also nutritionally beneficial. I don't see "UPF" as a practical way to look at it.