rgoulter

> In effect, instead of building the core while trying to anticipate what might be needed at the other layers, you just simulate the other layers by actually building them.

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 one hand, NixOS can have a steep learning curve. (Although if you're willing to use LLM coding agents, I bet "steep learning curve" turns into "be curious and ask the LLM how it works").

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.

I was curious about the history of these fancy custom split mechanical keyboards.

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.

I know ESP32 is popular, but I wished WCH's CH58x got more attention. (Or WCH's chips in general. e.g. their CH32V006 seems really neat for its price).

Seems to me e.g. John Carmack is a proponent of using LLMs for writing code. https://x.com/ID_AA_Carmack/status/2098443262214230095

Carmack's attitude is less "LLMs stick suck at code" and more "LLMs are getting better at many programming skills".

> People who claim “LLMs can write decent code” don’t understand how code works.

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".

> a thing that previously somewhat prevented lazy and incompetent developers from pushing out horrible code

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"""

> it seems like nearly every tech opinion piece I read now boils down to "things used to be hard but they aren't anymore because LLMs can understand things faster than we can, so can ignore/change fundamentals!"

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.

Pokemon Red has been 'solved'*. (It can be played "blind+deaf" for ~most playthroughs). https://www.youtube.com/watch?v=6gjsAA_5Agk

FWIW, https://duckdblabs.github.io/db-benchmark/ linked to from the readme, every result for "Haskell" shows OOM or undefined error. (Even on the large instance, even with the small input.

With LLMs, I'd expect if something appears more frequently in the training data, then the LLM would be more effecient or smarter at dealing with it somehow.

Surely there's way more content related to programming in Python, JavaScript, Go, etc. than in Haskell.

So you'd expect some things like: an LLM is likely able to come up with an approach that's suited to Python/etc., and an LLM is likely able to work its way through Python/etc.

My experience has been: when using an LLM with a nice language (Nickel-lang, a modular configuration language with types and contracts) that it frequently guesses slightly wrong as to what works (e.g. guessing wrong about how stuff like { x = x + 1 } would work) that it spends more tokens than it otherwise might.

> The issue I have run into is that for running llama.cpp, which is a very actively developed bleeding-edge software, it seems like experimenting with different versions/configs/patches etc. was fighting with the Nix philosophy of immutable software

May be. I'd guess it probably does it in a high-friction way compared to what you expect.

e.g. in a typical linux distro, you can just replace the (globally installed) version of the package and use that.

With Nix, you've got a declaration of how to build a package, including its dependencies; and each of those dependencies is also a declaration of how to build that package, and so on. -- And so, "just change this version" results in rebuilding the full chain of dependencies.

If you want multiple readily-available versions of llama.cpp each with different configs/patches, then using Nix would make this easier I'd think. But for "I just wanna try this, then try that", it's going to add overhead.

I think the main insight from "functional core, imperative shell" is more about structuring the code so as to be easy to test.

Without that structure, code tends to be difficult to test, since the impure stuff like network requests is part of the same sequence of statements as the logic you want to test. (That is: pure code is easier to test (but harder to write real programs with).. so, "arrange the code so you've got a well tested core" is a good strategy).

The nice part about the pure/functional is that you know for the same inputs, you always get the same outputs. -- I think if you want to say, "well, this stateful object is still pure (if you consider the state part of the input" then sure, I guess.

Yes.

I think if you're on a team that cares about quality, LLMs can help you write quality code faster.

If you're on a team that's mindful about technical debt, you can have make practical trade-offs for velocity now at the expense of paying off technical debt later.

And if you're on a team that's unable to care about code quality ("I gotta merge this code now!"), then you can write mountains more code than you can understand.

LLMs are not magical tools which take slop as input, and produce well thought out documentation and tests and code as a result.

Over the last year, LLM coding agents gotten pretty good. It's no longer "if your results suck, you gotta try the latest and greatest model". You can get capable results on a wide variety of tasks, with a wide variety of models, used in a wide variety of ways.

Without LLMs, you can still have bad development processes which lead to increasing technical debt with no plan for paying it off.

LLMs let you move faster.

But it's not as if introducing them is the only reason your codebase isn't high quality.

> Unit tests at >95% coverage

Eh. I wouldn't focus on unit test coverage.

I think it's true that good, well tested code will have higher code coverage than crappy code.

But, above a certain point (which will vary from codebase to codebase), unit tests aren't meaningfully increasing confidence that the code is working.

I'd recommend focusing instead on the code being written in a pure 'functional core, imperative shell' to the extent that's possible. For that pure/functional part, 100% code coverage is attainable (& so not worth remarking on). For the impure parts, unit tests are probably using "mocks" just to get the code to compile anyway.

> Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.

Programming and learning new things can still be fun in the era of agentic coding.

With LLMs, I get to quicky ask: what would this look like? Why do it that way? If you suspect that the LLM isn't doing it the right way, you can still investigate that yourself.

e.g. the other day, https://rhombus-lang.org/ was mentioned on HN. With LLMs, the cost for trying this out is practically much lower.

The punch and profound-sounding phrasing is also Claude; but pre-LLM it might make sense for a marketing page.

"Your laptop stays private. The URL goes everywhere."

A URL ... goes, does it?

I've seen it pointed out (& have noticed) that anthorpomorphising like this is an LLM smell.

In this case, although "URL goes" can be valid, it's just awkward here.

> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.

Pre-LLM, I'd distinguish between e.g. "I know Python" and "I know this codebase". So if I wrote a codebase in Python I'd be familiar with it, if someone else wrote a codebase in Python I'd be familiar with the Python. -- An LLM coding agent can give a codebase in Python very quickly.

With a newbie, they'd be familiar with neither; but an LLM coding agent can give them a full solution written in Python.

I'd say that this power from LLM coding agents blurs the distinction, in some sense. But to an extent it's always been the case that abstractions allow programming without a full understanding of everything down to atoms.

People 'can' learn faster than they used to. But I'd think those who are curious to learn will be able to have better results than those who only have a shallow understanding.

Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?

This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened".

There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy.

From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed".

What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.

> I wonder what use case there would be to checkout the same branch in multiple worktrees.

I've run into it when I've wanted to checkout that branch (to try running code there, or view a file, or rebase it, or whatever) and there's already a worktree checked out.

This is more like treating worktrees as "lightweight clone of the repo checkout out at some dir". (If it were a separate clone, it wouldn't be an issue to have the same branch checked out in two places).

The linked post is not that long. The readme in the linked project happens to be longer, but it's clearly because the author put tables of keymap bindings in the readme.

It's what I'd hope a well-written readme should look like, I think.

I can tell you wrote this comment when you were younger.

For one, there are frequently examples posted to HN where LLM coding agents have been used to help people complete projects which otherwise wouldn't have been done. You're taking a really strict view of 'meaningful' if you think LLM coding agents are incapable of writing code.

For another, the case mentioned in this post is quite specific. It's more useful to ask "ok, so they can't design circuit boards; what can AI do?"

This whole post reads like a frustration with a lack of thought.

I think it's worth distinguishing 'LLM assistance' based on how much thought/effort went into the prompt.

e.g. It's popular to hate on "my colleague just copy-pasted my question into the LLM and copy-pasted the response". Because the colleague added nothing by copy-pasting. But if I'm unfamiliar with some system, I ask a question, and someone gives an LLM response prompted with the right key words, that's more useful than I could have gotten myself.

e.g. OP claims to hate using LLMs, but also said that he thought that by using LLMs he was able to get a tighter comment to post. -- I don't really see the problem with that? If you don't want to use the LLM, post the raw rant. If you care about the quality & think an LLM improved the result, then... well, I guess if he just copy-pasted the result without reading it, that'd be silly.

"Expectations of productivity went up" seems a reasonable response to the excitement of seeing how impressive LLM coding agents are at some tasks. But it'd be nice to pare it back after seeing evidence that the productivity hasn't really improved.

EDIT: my experience has been that LLM coding agents, although better than you'd think, aren't as good as you'd hope. "You don't have to put thought into it any more" doesn't match my experience. But, if you've achieved the ability to productively craft great software without thinking & without being involved in the process, I'd be curious to learn how.

Interesting discussion of a chorded input device alongside modal editing of code.

Modal editing is quite prominent in vim and vim-flavoured tools. So, I don't think model editing's lack of popularity is due to people not knowing about it.. although it's definitely a power-user way to drive a tool.

I wonder if a whole external device is really necessary for the one-handed device for chords. I think with a customisable keyboard, you'd be able to chord.

Seems that the idea is to use the mouse to point at the noun, then use one-handed chord to drive actions? Interesting idea.. some use cases still benefit from one hand on keyboard and one on mouse.

I'd count in LLM coding agents favour: e.g. willingness and capability to do things which I'd have to go read a tutorial for; as well as rapidly being able to iterate and narrow down e.g. when given access to a repl.

Rhombus looks promising in terms of tooling.

On the other hand: LLMs are susceptible to incorrectly guessing "I think it should work this way".. I'd guess the powerful flexibility of metaprogramming could be more annoying than helpful. But, I'm curious.

Each to their own, but I think free weights is the easiest activity where you get to feel tangible progress from doing it.

You move weight around, later you move the same around a bit more (yay!), or move a heavier weigh around (yay!).

You get to really know what your body is capable of.