rgoulter
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.
One use case I was interested in: coming up with a (simple) box with cavity in it, and having this CNC'd. (For a simple custom keyboard shell).
Although OpenScad can express the geometry of the geometry without difficulty, it was burdensome to export the .step file that the CNC manufacturer wanted. To my understanding, CSG's model is just fundamentally different than what .step wanted. And re-using the geometry for a technical drawing to communicate e.g. threading wasn't something OpenScad could handle smoothly.
I haven't quite ported this to build123d. But, from a cursory look asking an LLM to do port my code, I was given the impression that it could manage the task. (Certainly build123d was better suited to technical drawings).
I wouldn't take "the standard 104 keyboard layout" as a respectable design.
- If the modifier keys exist twice, then why aren't they placed symmetrically?
- Most users use a mouse with the right hand; yet the numpad is placed on the right side of the keyboard (which means it's even further away). e.g. placing keyboard in front of you in the screen then means the mouse needs to be way off centre.
- That the letters remain asymmetrical shows adherence to tradition/familiarity over improving a good design.
- The spacebar doesn't need to be >6x the size of other keys.
- Caps Lock can be useful but isn't significant enough to be worth putting where it is.
I mean. I can agree with distinguishing "Return" and "Enter". But I wouldn't refer to the typical keyboard layout as if it's a well thought out design.
LLMs took this and smooshed it into "it's not X, it's Y" or "it's X, not Y".
I reckon this "unusual object verb" thing is similar.. kinda an uncanny valley of written communication.
Eh. I think you're just going to end up with slop, or sloppy recommendations?
My experience is that you can make different trade-offs for different reasons. I think even asking for the best answer to "improve the code, make better trade-offs".. even if you got a perfect response, there's no reason to think that it's the same set of trade-offs your actual use cases would benefit from.
On the other, I bet anyone curious about Haskell would love NixOS.
In regards to Haskell not being trouble, though: I'm not too familiar, but I thought stackage & the 'stack' tool would ease over any pain.
If I understand correctly.. the ergodox was the first popular open source keyboard (or maybe the first split one).
But it was the Helix keyboard, and then the Corne which built upon that design, which lead to an explosion in popularity of these split keyboards for makers. Both of these were designed in Japan.
Carmack's attitude is less "LLMs stick suck at code" and more "LLMs are getting better at many programming skills".
It's not clear to me if the claim is:
(1) "If you used an LLM to generate code, and the code works, you're wrong if you think the code is okay"
or
(2) "If you used an LLM to generate code, you reviewed the code and found it to be of decent quality, then you're wrong".
> If you’re toying around, LLMs do a great job. That’s why some of the most aggressive proponents of the “coding is solved” narrative have nothing to show for it.
I also don't get the "LLM proponents have nothing to show for it" statement.
It's really quite common now to see on HN all sorts of LLM-assisted programming projects. The quality varies from slop where little thought was put into it, to high quality results where LLM coding assistance was able to let talented developers produce things they otherwise wouldn't have time to do.
I'd say it's obvious that LLM coding agents can be very useful for a lot of programming related tasks.
EDIT: That is to say, LLMs are obviously useful for use cases above/beyond toying around. It's not a dichotomy between "I'm never touching an AI" and "thoughtlessly accepting everything the LLM outputs".
Brings to mind this classification https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...
"""I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage"""
Sure, LLM coding agents being capable doesn't mean we can ignore fundamentals.
But LLM coding agents surely adjust the cost/benefit considerations for all kinds of programming efforts.
Arranging your code in such a way that it's so complicated you need an LLM to understand it is surely silly.
Using an LLM to write a macro because you weren't going to learn how to write macros and deal with all the subtle cases? I think that's arguable.