simonkagedal

They should be toggles! Every now and then I will press the wrong button and will have to wait for the elevator to stop, open doors, close doors at a floor no one wants off on.

I mean, I haven’t done the usability research, probably there are some good reasons for it’s not a good idea to just make them toggles, but I would find it neat.

Sounds a bit like the idea behind shadcn/ui. You start from the generated components, but the idea is to fork the code.

(Then they seem to also have added their own kind of dependency management thing to update components, which seems to me to kind of defeat the purpose..)

There are lots of good use cases for vibe coding (”never reading the code”), prototypes, various explorations and one-offs. I’ve done various kinds of migrations where I didn’t bother to review the code much, just the output.

Possibly also some user-facing tools with a limited task and runtime environment.

Incidentally, these are all use cases where performance isn’t critical, typically, so you might as well write them in Python or Typescript or whatever makes most sense for the task.

Real production code? Yeah, you still need to be able to read it and understand it.

But people claim that text is AI-written on the most ridiculous grounds, like using proper typography. You might be missing out on interesting stuff!

Same. Meanwhile, I _read_ more code than I ever have.

Furthermore, for the example given, it would have made a lot of sense to me to generate those article summaries on the backend. Once and for all, no need to burden each client device (which are going to need to download the content anyway), no need to tie yourself to a specific provider (Apple in this case), can have the same experience everywhere. Of course, the backend could use a local (to itself) model.

Not saying it’s _wrong_ either – maybe it doesn’t use a backend of its own (the client downloads content directly from some predefined set of sites), maybe there is functionality to adjust how the summaries work that benefit from doing it on device, etc. Just doesn’t convince me that ”local AI should be the norm”.

I would say yes, there’s a difference, in general. I would much rather leave the unsafe code to crates used and tested by many other applications, than have them in the application code itself.

What really does not serve the reader any value is this comment now appearing on nearly every single HN thread. (And neither does my comment, sorry about that.)

If you like the article, upvote. If you don’t, don’t.

In a possible defense of grandparent, whenever I pirate movies these days (seldomly), it would be not because I don’t want to pay, but either because I want the offline reliability or because I just can’t find it elsewhere.

(The latter would however not be the case for Titanic, I imagine.)

I like it when the two paradigms can be combined. Where you (or a non-developer) can set up a dashboard by point-and-click, but in the end there’s a source file that can be downloaded, revision controlled, deployed to different environments.

And in the best of worlds, that file format is simple enough to be understood in code reviews and scenarios where you want to generate them programmatically, not a huge incomprehensible json or xml.

I find this to be only even more important in 2026 where you could then also let a code agent generate the dashboard (any agent, any dashboarding software – no need for bespoke agent embeddings in the dashboard UI).

The mouse clickers can click their mouses and those of us (humans and machines) who prefers working with text files can do that. A good file format should take both into account.

This is being addressed in the article. The service no longer does this, and he apologizes.

Yes, I agree. It's been small enough of an issue for me to care (I have `~/.parallel/will-cite` set by my dotfiles repo, so wouldn't even see it on a new machine), but now I switched to `rust-parallel`.

Picked that one because it was supposedly the fastest, I liked the Github page and I will remember the name :) And I guess I was hoping for it to be a drop-in replacement for `parallel` interface-wise, which it turned out it was not, but my needs are quite minimal. I used to do:

ls | parallel 'echo {} && git -C {} fetch --prune --all'

Now I do:

( for i in $(ls); do echo git -C $i fetch --prune --all; done ) | rust-parallel -p

I think the link (now) points to the wrong line in the source code. I found it, though.

Anyone understands why they do this?

This page describes the behavior, "disables the automatic execution of postinstall scripts in dependencies":

https://pnpm.io/supply-chain-security

While this explicitly calls out "postinstall", I'm pretty sure it affects other such lifecycle scripts like preinstall in dependencies.

The --ignore-scripts option will ignore lifecycle scripts in the project itself, not just dependencies. And it will ignore scripts that you have previously allowed (using the "allowBuilds" feature).

The limit of 16 rules is interesting. Where does that come from?

The end of this article leaves me hanging. Did she manage to find the previously employed insurance lady so that she could thank her, or not? I need closure!

Someone (maybe on this site) suggested to think of the bottom bars of the square brackets around the linked text to kind of frame the underline. Somehow worked really well for me, haven’t forgotten the syntax since.

That is a very nice metaphor indeed!

I applaud this project, “setting all the options”. I think it’s a really good idea to become close friends with the software you use all the time, and getting acquainted through the lens of configuration is one way. Messing around with stuff is good.

I feel it’s worth mentioning that there is a sense in which I think it might be a bad idea. It could be that you’d now be fixating some value that may be optimal right now, rather than benefiting from future improvements to the default settings. But it all depends, of course, on how close friends you plan to be.

He commented on this here: https://simonwillison.net/2025/Nov/13/training-for-pelicans-...

Does “safe” here mean just “non-mutating”?

Took me a while to realize that it is an actual thing, rather than used as a placeholder (“three letter acronym”)

Me too, I still think it's cool. But while indeed easier-to-implement compared to SGML, it could have been yet a bit simpler. :) I once attempted to write a conforming parser, I remember it being a _lot_ of work to even determine well-formedness.

Ah, I was perhaps a bit unclear – I didn't mean to comment on whether certain languages made the list or not, I enjoyed the thorough walkthrough of languages being used for configuration.

I was more commenting on comments such as this one under Pkl:

This is not a markup language. This is a full-blown programming language.

And under Nickel:

Nice programming language. Not a markup language.

It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.

The author seems to be using "markup language" as a concept basically synonymous with a configuration language, or something that is not a programming language. A markup language is a language used to "mark up" text with formatting and structure. This may sound like a terminology nitpick, but I would argue the reason why for example XML is not a great configuration language is that it was designed to be something else – a markup language.

Regarding documentation, I’d love to hear you take on creating the CLAUDE.md/AGENTS.md type of files using the tools themselves, typically via some /init command. I think Claude Code, Codex and Copilot CLI all have a similar thing.

Those often seem to generate a snapshot of the current state of the codebase that to me seem to be just begging to get out of date, often with references to specific files. I sometimes start out with them and remove a bunch of stuff, or I just start empty and add things as they appear to be needed.

What’s your strategy on these?

Yeah. There are many fun experiments one could do. Now I got this idea instead: what if it opened up on 07:39 PM on January 1st, but then the window moved forward 3 minutes and 56.7 seconds each day so that it was back on 07:39 PM a year later. That sounds like it would be extremely useless, but fun.

It was a total brain fart though – I know what EST is and I know that my time zone is CET; just had some neurons misfiring!

I think it's a really cool idea. I signed up because I had a brain fart and thought that "EST" was "European Standard Time" (I was of course thinking of CET).

So yeah, the current window wouldn't work for me, but that's fine. Everything doesn't have to be for everyone. We all live in our bubbles anyway; creating artificial rules could actually be ways of creating new, unexpected interactions.

This being said – if you were to adjust the rules to accommodate more people, I don't think it should be "open from 7:39 to 10:39 in whatever your local time zone is", because that feels like it would just destroy the whole idea – that everyone is there at the _same_ time. Also, it would still exclude people who work evenings.

An alternative solution would be to have multiple windows. For example, if you have one starting at 7:39 PM EST and another one at 7:39 AM EST, there would be more chances that there is some time during the day for people around the globe to check in. Depending, of course, on many things: time zones, sleep habits, work schedule, ability to briefly slack off during work, etc. It would remain true to the idea while opening up for some more people. Just a thought.

I also think each window could be smaller, maybe like just one hour?

I was also wondering what they were trying to say with that.