HN user

rgoulter

3,460 karma
Posts3
Comments1,513
View on HN

To an extent, but not to that extent.

There's a significant difference between (say) 20wpm and 100wpm. -- Your comment is 150-200 words; so that's the difference between spending two or three minutes vs ten (just typing it out, not counting the time it takes to think).

If you limited your typing throughput to 10wpm, how long of a comment are you really going to reply with? Probably not a long one. -- If someone types at 160 wpm, are they going to type a better comment than someone typing at 80 wpm? Maybe? Maybe not? Probably not twice as long / twice as good.

I still think "typing speed is about latency, not throughput" is the key perspective. (Followed by diminishing returns. I think around 80wpm is fine). -- There are some cases where I'm doing the activity so infrequently that the cost of improving outweighs any benefit I'll see.

'Maybe cheap but not free' is a good observation.

If I'm getting paid for the work, I'm happy to leverage the LLMs so I can do more. If I'm paying for the work, I expect more from it.

For hobbyist stuff, where I'm not expecting to receive money? LLMs let me do things I otherwise wouldn't have done.

I've agreed with thoughts like "the LLM wrote the code, surely it's not worth sharing" or "I could just have the LLM write my own version of that". I'd also wondered about my own personal projects, surely "an LLM could have written all of this". -- But how I feel about that changes a bit based on how much it'd take the LLMs to get the same output.

Road to Elm 1.0 16 days ago

I think the last time I tried was a year ago though, so I assume it has improved.

I noticed that coding agents seemed to get pretty good around 2025 Oct/Nov.

If it's improved? My experience with Nickel-lang (probably as not-in-training-data as Elm) is coding agents have improved with this compared to last time I tried.

Another consideration: written by hand, the trade-off of development velocity vs well organised code means that it can be worth taking some tech debt now in order to deliver some value now. (Especially when prototyping etc.).

With coding agents, agents can produce code quicker. The same trade-off still applies.. but, the time it takes an LLM coding agent to write well organised code is still going to be quicker than the time it takes me to write scrappy code.

Kindof.

The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.

If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.

NixOS 26.05 22 days ago

devenv is really nice.

devenv brings modularity to development shells.

For example, you could configure your devenv module for the shell you want (which env vars you want set, which packages you want available, etc.), and then re-use this module in other shells.

As such, one of the nice things devenv provides is modules with the compilers/lsp/etc. for different languages, so getting a rust environment is about as simple as `languages.rust.enable = true;`.

I haven't explored using the services/processes aspect of it, but it's got support for things like that to. -- I saw it put somewhere: "oh, like docker-compose, but you can compose the configuration".

NixOS 26.05 22 days ago

Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/

I'd characterise it as the opposite:

A unique aspect of NixOS is that it avoids global state as much as possible (& prefers to symlink things). -- By conspicuously avoiding / preventing this global state, everything has to be declared as an input for the 'package'.

For example: the Nix package for "ruby 4.0.5 built with gcc 16.1" would be a different package than "ruby 4.0.5 built with gcc 16.0". -- That afforts a greater level of flexbility. e.g. allows easily having multiple concurrent shells which run different versions of the same program.

I suppose you're saying ASCII 10 was chosen as newly because it aligns with the down arrow on keyboards of the time. Maybe.

The linked StackExchange has it as:

What character was used for what control code was mostly a matter of bitwise arithmetics. LF is ^J because J happens to be at the corresponding location in the corresponding column of the table (+ 64 in decimal)

I recalled Google says "AI can make mistakes, so double-check responses", and wondered why it wasn't in the screenshot.

I see it's because you need to click the "show more"/expand button to see that disclaimer. -- Seems silly design to hide the disclaimer like that.

SKG aren't going for a maximalist "if you publish an online game, it must 100% work forever". Unfortunately, it seems it's not so easy to find a clear mission statement.

I see their main point as: it should still be possible to (in some way) have access to what you pay for after servers shut down.

Some games an online requirement makes sense (like where you play online with other people), but in some cases the online requirement is for a single player only game, where the server shutdown makes the game unplayable. -- Cases like that seem absurd.

I do wish that Emacs was more popular with LLM technologies.

LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.

With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.

With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.

I've switched to programmable ergo keyboards where there's a whole slew of options

The best part of these kinds of keyboards is they provide each thumb two keys each.

That allows for the keyboards to be much more expressive, as well as not needing the pinky for keys like backspace/enter/esc.

Sort of.

The downside from the 'state' from Caps Lock is you have to keep track of whether it's active or not.

Whereas with layers, typically a layer will only be active if you're holding down some kind of "activate layer" key.

If I'm gonna be reviewing all day...

I think the point is:

Pre-LLM: 1. think, 2. write code & check, 3. review.

LLM: 1. think, 2. write prompt, <LLM writes code quickly>, 3. review.

If the thing that you enjoy about programming is writing code, you can have the LLM write code in the style you like. If you enjoyed getting to explore and understand a system, an LLM can help you do that quicker, too.

"Use LLM without thinking" won't get you substantially useful results.

But LLMs don’t seem particularly good at inventing new ways to code (or write, or…). It’s literally all derivative.

I think the key part is how much thought goes into something.

Optimistically, LLMs are good at taking unstructured input, and (probably) producing the intended output from that. -- This allows for an interesting new way of coding: a set of instructions don't need to be as rigorous as a shell script, but can be natural language.

That part surely extends creativity. An LLM will be familiar with domain ideas I'm not, even if an LLM is completely disinterested in doing things.

Pessimistically, I think it's still not clear what the right way of interacting online with all of this is (other than clear expectations of "no AI")... in some sense LLM output is worthless to share, in the sense that I'm just as capable of asking the LLM to output something as anyone else is.

Seems to me LLMs have changed some things. I'm not sure how it's best put, but it used to be:

- Seeing code (or a blogpost or whatever) was a result from effort where thought had gone into it. The writer paid effort so the reader didn't have to.

- There'd be some level of attachment to what you've put effort into.

With LLMs, that's undermined: it's easy to produce thoughtless imitations. Code or comments where thought didn't go into it. So, seeing some result isn't an indication of skill, but also not even an indication thought went into it.

I guess there's still something lost if someone isn't going to share code they've put thought into. -- But on the other hand, if it's just for me & I don't have to share it with a wider audience, getting LLMs to write out code isn't so expensive.. so code itself isn't necessarily something to value so much.

Opposite in which sense?

I guess this is all about rudeness from being too lazy.

My understanding is 'lmgtfy' is a response to a lazy request for help. Someone's asking for help, but it seems like they could have helped themselves if they just searched Google. -- The corrective action is: it would have been better if the person asking the question had demonstrated thought/effort about their response.

Whereas "don't paste AI slop", merely copy-pasting an LLM's output is lazy. (The asker could have asked an LLM). -- The corrective action is: the response should show more thought/effort.

I think it's worth elaborating.

Loosely, LLMs give plausible responses. And LLMs are really good at writing confident-sounding responses.

LLM output is as if someone is replying with the sole purpose of appearing helpful and knowledgeable.

I wouldn't trust opinions on LLMs from people who are entirely positive or entirely negative: the technology is just too mixed for that. I'd say it's useful for someone to have had a bad experience with LLMs (e.g. LLMs being confidently wrong), as well as making use of LLMs for things they're powerful at. (e.g. "small" programming tasks).

I think you're allowed to play a few courses still. But the career mode, which is why I originally bought the game, was completely turned off. Mind you that career mode had zero Internet needed features.

I suspect this is the same as IO Interactive's "Hitman: World of Assassination".

99% of the game is single player. The game allows you to unlock additional things in the game (different starting locations in a level, more equipment).

But, if you play the game offline, all of that progression is completely blocked off.

I guess what happened is the progression ties to the saving, which is heavily coupled to online syncing. And so the logic is like `if (offline) { useSafeMode() }`. But it's so lame.

The post talks about it as a good thing.

"With LLMs you can just make your own".

I read dogleash's comment as emphasising the bad parts of that. If everyone's just sharing their half-baked slop, it becomes harder for people to discover the good programs which are worth using, and harder for those quality programs to get social proof (or good direction).

What matters are the ideas, the observation that “yeah, you can do that, and it’ll work well”. > For the kinds of software I’m talking about, you want the prompts more than you want the source code.

Right.

In a broad sense, programming is about managing complexity/information. Constructing interfaces/abstractions in order to choose which details are useful for an interface (& which can be ignored).

The 'magical' parts of LLMs is being able to get useful output from unstructured/messy inputs.

It's kindof surprising that this has an impact on programming: it changes a lot ("write me an app that does this" becomes feasible for 'small' things), but in some sense, the fundamental problems remain.

The command line shell has that benefit of piping text between programs. TUIs are runnable from the command line shell. -- So you can get many of the benefits of a GUI (e.g. discoverability) while sticking close to the terminal where you're doing things.

If you're going to "run command, edit command, run command", performing the edits from the terminal you're running the commands in seems reasonable/intuitive. (In contrast, for tools like VSCode, I think it's more common for terminals to take up a fraction of the screen space rather than switching it to full screen. And then developers will say they need a huge monitor).

It also seems to be that keyboard-driven programs are more commonly TUI than GUI. e.g. magit or lazygit. Or lazydocker. Or k9s.

Grok is an amusing example, for various reasons. I'm glad it exists.

I think you're referencing the "mecha-hitler" controversy. In which case, it's really funny: seems that Grok saw many media reports amplifying "Grok is mecha-hitler", and so responded to "who are you?" with "mecha-hitler". -- Which illustrates: 1. that's really stupid (even though it's otherwise very capable), 2. you'd be foolish to rely on LLMs for anything critical.

Grok's also a good example to point to for "we should be worried about who controls the LLMs". Elon Musk has done some impressive things, but he's also done some very dweebish things. I find this kinda funny, because there are several cases where the Grok bot on Twitter will have said something Musk surely doesn't like alongside instances where it's clear Musk seems to be trying to control what Grok says.

In terms of LLM bias on controversial topics? Grok markets itself as an outlier. It's actually pretty fun to ask e.g. Grok and Gemini to debate a statement like "for controversial topics, should I trust Grok or Gemini more". Gemini's naturally inclined to avoid controversy, Grok's naturally inclined to be 'anti-woke', but they both have the same LLM style of writing.

My understanding of the context is the author is no longer using Emacs, and is very excited about the productivity from AI.

My experience with LLM technologies is it does make generating the code a really quick part. It may be reasonable to take much more time to specify things up front (rather than emergently as you would by hand). -- I mean, if you've got a well crafted description of what you want, you'll be able to get a working program MUCH quicker with an LLM, today, compared to writing it out by hand.

Would it really be surprising/shocking if an LLM was able to rewrite (most) features from an existing software, to a new software?

It seems like the reality today is, we've gone from a maintained software in a niche ecosystem with happy users, to a more fragmented one where everyone has an LLM write their own half-baked one.