I'd much rather have application functionality provided by a CLI, over stdin and stdout; and have Emacs provide its TUI-like layer on top.

I don't mind short-lived TUIs, like config wizards; but would still prefer a CLI that prints a few lines to stdout and reads text from stdin; rather than curses-like things that attempt to print whole "screens" at a time, and are driven by a mess of control characters and internal state.

The worst ones are those that (a) want to live for a long time, and (b) hammer the terminal with updates despite no user interaction taking place. These AI agent TUIs tend to be the most obnoxious; e.g. having a bunch of "spinners", which would traditionally be placed at the end and updated using backspace, but for some reason these AI companies have implemented by redrawing the entire screen, based on some HTML/DOM/React layout algorithm; with the result being a whole bunch of CPU & RAM spent, and a headache from staring at the flickering mess it draws.

This is frustrating for two reasons:

Firstly, LLMs are famously bad at counting characters (e.g. the number of "r"s in "strawberry"), so it's no wonder this approach of generating and counting characters doesn't work very well.

Secondly, balancing parentheses is trivial for traditional, non-LLM algorithms; so it feels like an entirely avoidable problem (without resorting to larger, more-expensive models).

Is anyone using LLMs successfully on Lispy projects? If so, what workflows, tooling, etc. have you found to work well? I've tried guiding them to use Emacs `check-parens` rather than counting "manually"; but maybe inferring from indentation might work better? Perhaps tree-based generation/tools would avoid introducing such problems in the first place?

Comments URL: https://news.ycombinator.com/item?id=48657691

Points: 4

# Comments: 2

I've been using computers since the early 90s; we got our first home computer when I was four; I've used many different operating systems.

As a professional Web developer, it took me an embarrassingly long time to figure out what those slider widgets are supposed to mean. It's still very easy to get them wrong/confused (both as a user, and as the designer/dev making the form), e.g. when the affirmative state involves a negative setting, like "Mute" (does "on" mean "muted"; or does "on" refer to the audio, which I can use this to mute?)

This is something I've struggled with as toolkits change and old widget themes stop working. There are still some decent themes out there (e.g. Skulpture for Qt has been my default for many years), and with a little patching they can be dragged into working on the latest toolkit versions. Yet I can't seem to avoid this "you have to hover over to see that it's actually a button" behaviour. Very annoying!

Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).

That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.

Currencies are a little different, since they are required to pay taxes; and payment of taxes is enforced (to varying degrees) by state violence.

Hence if you believe you will be taxed ("death and taxes" being the only certainties in life, etc.) then the currency associated with that tax has value, in that it avoids imprisonment, etc.

According to their videos, they prefer trams within cities; generally take trains between cities; and acknowledge that cars are very useful for places which aren't so well connected (e.g. places that are far apart which aren't on a train line). They think encouraging the use of cars within cities is a bad idea (dangerous, scales poorly, makes those areas less pleasant to be, etc.).

Not what I'd think of as a "biking maximalist".

They do show themselves cycling to places that are nearby. Does that make Youtubers who record videos in their car "driving maximalists"?

There's no C in there? It seems to be Python and shell scripts.

In particular, your examples bring these things to mind, which might be worth considering alongside:

- Any machine can host a server, with no third-party required except an ISP (if we're being pedantic, even that's not needed if use a mesh network, etc.). The main barrier to connectivity IME is NAT, but there are ways around that (e.g. make it a .onion service). I played with all of the above as a teenager, so it's not unrealistic.

- "Hosting a website" covers a lot of things, some of which are already illegal (e.g. CSAM). Just because we can spin up something without jumping through social media sign-up hoops, doesn't mean it can't/shouldn't be subject to legal questions.

- Hosting a website/blog/etc. does not come with the same questionable baggage as social media (algorithmic feeds, PII, tracking, identity verification, communication, etc.). We might opt in to such things, e.g. by accepting comments on posts, but I'd distinguish such two-way, "user generated" activity from merely "hosting a website". Technologically, such things require some dynamic system (usually a self-hosted or third-party backend), rather than "just" a static HTML server.

- There is no technological difference between a blog used like a personal diary, and a blog used to post reviews of Lego. Is there a societal difference? What about if they include photos?

- Posting things on a personal website/blog has an implicit understanding that it's being published and shared with the world (that feels like the whole point of a blog). Social media has muddied those waters, by claiming things like "privacy settings", which can give the impression that posts are not being published and shared with the world.

- When it comes to activities like receiving comments, two-way communication, unsolicited messages from anonymous strangers, etc. the more relevant "basic tech" feels like running a server for email, IRC, Jabber, etc. rather than a web site; since those place such "dangerous" aspects front-and-centre. Email is the most obvious, but I mention the others since getting external systems to trust a self-hosted email server is notoriously tricky!

In fact, Git supports any protocol! If you add a git remote like

    git remote add my-remote my-super-duper-protocol::some-sort-of-address-thingy

I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

jj doesn't "want" anything.

I always end a piece of work with `new`: it puts an empty, description-less commit as the checked-out HEAD, and is my way of saying "I'm finished with those changes (for now); any subsequent changes to this directory should go in this (currently empty) commit"

The last thing I do to a commit, once all of its contents have settled into something reasonable, is describe it.

In fact, I mostly use `commit` (pressing `C` in majutsu), which combines those two things: it gives the current commit a description, and creates a new empty commit on top.

I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another.

With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.

Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.

Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.

As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)

You also mention there being "little value", when your proposed approach costs literal money in form of API/token usage (when using hosted models).

> Now I've moved to coding in Haskell

You might like https://hackage.haskell.org/package/turtle or http://nellardo.com/lang/haskell/hash/