For me, the huge one is that LLMs are currently bad at learning from experience. I don’t trust any kind of automatic MEMORY.md or whatnot; in fact I greatly prefer starting from a clean slate each time because the LLM’s baseline general knowledge is so good.

In terms of accuracy and “lying”, I don’t really see a huge difference. Most LLMs are unfortunately a bit sycophantic and over-confident, but you sometimes see that in people as well.

Sure, the model can go wrong, but sometimes it's able to realise that and correct its course. Stronger models are better at doing this.

People do exactly the same thing! Haven't you ever wasted a lot of time chasing down a blind alley?

To say the LLM has immutable limits because it only predicts the next token and can't backtrack is like saying we have immutable limits because we can't travel backwards in time. It's a true statement but not particularly relevant or helpful.

And the Daring Fireball article does complain that watermarking will reduce quality. If that's what you're trying to check, "which is better?" is the right question.

I’d be very willing to try it out as an API, but it’s far too complicated to set up payment, and I don’t want to risk taking a wrong step and being locked out of other Google services. So Anthropic and Mistral get my money instead.

Built-in line and column tracking. Any movement across a newline updates the line number, including a backwards seek. getLine and getColumn are always available and both are one-based, which makes decent error messages nearly free.

That doesn't sound like much, but having hand-written plenty of recursive descent parsers, it's most of what you need for good error messages. Just being able to pinpoint where the error occurred is usually 80% of the battle; but keeping track of lines and columns in a hand-written parser is a pain.

Sure, for something like Rust, you need vastly more than that, but parsing is a tiny fraction of what the Rust compiler is doing -- type-checking and borrow checking is much more complicated and much more important.

A tiny library like this is a great fit for something like an INI file parser.

For example, you have an idea for a cool and useful app and you want to put it on a website. You need to figure out hosting, you need to write some copy, you need to do some visual design.

Maybe 3a) Yak shaving?

There are various ways to take shortcuts. For hosting, you can use something super easy like GitHub Pages or Netlify or Cloudflare, or maybe piggyback off an existing site that's already deployed. For both copy and visual design, you can just ask Claude or Codex to do it -- but only if you don't mind having that standard vibe-coded look and feel, all glowing gradients and punchy, mic-dropping text.

Maybe you're including that under 5), ship/deploy/publish, but I read that as being more about scaling, marketing, and making things robust. Even before you reach that stage there's always a bunch of bullshit to work through before you can even reach 4), seeing the solution work for yourself.

But I don't think you can cover all requirements with a set of fixed layouts, they do need to be somewhat flexible. Even if all screens were the same size, you'd want to be able to boost the font size for accessibility, and that essentially means scaling the whole UI.

And the slightly different sizes of iPhones are not really that problematic with something like autolayout.

I think something like flexbox is a better fit. There are tradeoffs in each approach, but I usually find a local, modular, bottom-up approach easier to work with than global constraint solving, even though it seems in principle like it should be nice to be able to say "keep this button here in relation to this other button". As you add more constraints like that your layout slowly turns to mush and doesn't actually resize nicely. (Edit to add: I'm probably conflating a few different generations of iOS toolkits here, I realise autolayout is somewhat separate from constraint-based layouts.)

I don't think it's a coincidence that most other UI toolkits have added something like flexbox (including iOS) -- it's not perfect but it fits how people generally think about UIs. Was HTML/CSS the first major UI framework to use flexboxes? That's how I remember it, but maybe it was copied from somewhere else.

Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it.

As Apple gradually added more and more slightly different sizes of iPhone and iPad, making good UI layouts got harder. Even handling screen rotations is a huge hassle! If iOS had proper support for resizing from the start, screen rotation would be trivial, just another window resize.

Xcode had Interface Builder and autolayout, but I found those to be disastrously fiddly and unusable. Maybe some people like them?

HTML has many problems of its own, but it does have good support for responsive layouts. CSS isn't perfect, but it's vastly better than anything you can find in macOS, iOS, Android or Windows.

It seems to me that SwiftUI was trying to tackle two problems at once: React-style declarative UI, and responsive layout. Those are both good ideas, but trying to tackle both in a single uber-framework and deprecating the lower layers was too ambitious. As somebody said elsewhere in this thread, SwiftUI could have been decent as just an optional helper on top of the existing UIKit / AppKit.

Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.

That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...

The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.

Looks like NI voted ~55% remain and Gibraltar ~95% remain, but too bad, England voted ~53% leave, so screw all you little overseas territories with actual land borders who are most directly impacted.

The thing is, "load-bearing" is a useful phrase when discussing architecture. What would you rather have it say, that has all the same nuances in as few words?

It's kind of like those sports metaphors that often get used in management-speak, like sending some important email "at close of play". Sure, they can sound a bit weird, but they're often useful -- they capture common concepts in a clear and pithy way.

Jargon isn't always just for obfuscation, good jargon exists because we needed a short word for the complicated thing that frequently comes up.

Usefulness aside, I quite like that Claude Code and other LLMs have their own weird way of speaking. Back in the day we always imagined robots and computers would talk like HAL or Spock; turns out that they talk more like Troi instead. Is that so bad? It reminds you that you're talking to an LLM, and as long as you're not lazy, it spurs you to rephrase things in your own words.

It’s a shame because it’s making an excellent point! It just takes so long to get to the point that the reader loses the will to live.

Yes, I could probably ask an LLM to summarise it for me. No, I’m not going to. I would prefer the author just take care of that for me.

It's been a very long time since I played Thrust, and I've played plenty of WASD games in the meantime, but it still felt really strange to control it that way rather than the classic BBC Z/X/*/? for left/right/up/down.

Pretty sure it was return to fire, space for shield/tractor; and maybe * for thrust? Edit to add: ah, no, shift to thrust. Works very well on modern keyboards too.