TheFlyingFish

Theme switchers! My favorite example of why "document-only" sites might need JS. Sure, you can use @media prefers-color-scheme for defaults, and you can do checkbox/radio shenanigans to make it switchable, but there's no way to persist that preference on a static site without JS.

If you don't care about your site being static then you can track it server side, but that has big implications for his you can just your site. Sticking a little flag in localStorage really is the best solution, if you can get past ideological purity.

Not the person to whom you responded, but several times I have been dealing with debugging. Issue, tried. Opus/Sol/whatever and come up dry, then thrown it at Fable and gotten the solution in one shot.

The corn-syrup comment made sense to me FWIW. I associated corn syrup with mass-produced food that's optimized to make all your taste receptors go "bling" when it first hits your tongue, but lacks any real substance. Which also describes the text that comes out of an LLM.

I'm aware of the Bun Rust rewrite, but what has Astro done with experimental agent-based work?

DuckDB is heavily focused on analytical workflows, so it stores data in a compressed columnar format. So "rewrite one row" is more efficient in SQLite, but "sum all the values in this column" is vastly more efficient in DuckDB.

That's the core of the difference, to me. But the projects also have a pretty different ethos. SQLite has always prioritized simplicity, often at the expense of features, whereas DuckDB's approach to features seems to be "the more the merrier." E.g. the star feature of this new release, client/server mode. Plenty of people would love to see something similar in SQLite, but it doesn't seem likely.

Feed aggregators (inoreader, feedly) make this difficult, though. One request may end up serving any number of end users, so you can't personalize ads the same way.

Good, you might say, and I wouldn't disagree, but Google et al sure would.

Are you suggesting that AI-written code tends to be more secure than human-written code? Because there are many examples to the contrary, starting with MoltBook.

Tangent: Much like PHP, "modern" CF isn't actually that bad to work with these days. In particular the superset-of-html syntax has been superseded for pure logic by "CFScript" which is just an ECMAScript dialect.

There's even a package manager, test harness, etc. And of course it's JVM hosted so it's fairly easy to use Java stuff (stdlib of otherwise) if what you need doesn't exist in CF.

He's living the hacker dream. Made a billion bucks, then went right back to writing code. People upvote because they wish they were him.

The HN zeitgeist has something of a love/hate relationship with the web, I've noticed. HN in general seems to skew a little older than a lot of online communities, so a lot of HN users were adults back in the early days of the web/Usenet/etc. There's a tendency to view those days with nostalgia, leading a lot of people to feel like the "good old days" of the web were "ruined" by the modern shift into more interactivity, fancier/prettier design, etc. And "web developers" are the ones proximately responsible for the shift, so they get the hate too.

I laugh every time I see someone on HN asserting that the web "shouldn't" be used for anything beyond "documents and lightly interactive content", which is not uncomment. There's some real old-man-yelling-at-clouds energy there.

If you're crazy then I am too. 50% odds it was written by a human, 50% bot.

I imagine offloading a lot of the heavy lifting to Vite helps cut down on the code size.

I once managed to trigger what I think was a race condition in a microwave's beep routine. It was one of the type that does a single long beep rather than individual beeps, and like most it would cut the beep short when you opened the door. But one time, one single time, I managed to open the door PRECISELY as the timer finished, and the beep just didn't stop. I finally closed and opened the door after maybe 30 seconds, and that stopped it.

I was never able to trigger it again, so I have no idea whether it was a race condition or some other random one-in-a-million happenstance, but it makes a fun theory at least.

I've never used a Lisp either, but I get the impression that "forcing you to write the AST" is sort of the secret sauce. That is, if your source code is basically an AST to begin with, then transforming that AST programmatically (i.e. macros) is much more ergonomic. So you do, which means that Lisp ends up operating at a higher level of abstraction than most languages because you can basically create DSL on the fly for whatever you're doing.

That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.