iainmerrick

However, if you think through the scenarios, the US is in a very strong military position and there's not much Denmark or the EU as a whole would be able to do about it. They could threaten a direct military response, on the basis of making the annexation more trouble than it's worth, but then you're just playing chicken with a significantly crazier enemy.

Most likely the EU would try to calm the waters, and offer a compromise peace / surrender plan along the lines of the one the US has offered Russia in Ukraine.

The biggest obstacle ought to be political opposition and public protests within the US itself, but right now the US government is in a position to just move fast and make things happen, what with the weak Congress and compliant Supreme Court.

I hope and believe it'll become much less likely after the midterms, with a Democrat-led Congress motivated to push back against the executive's excesses.

HCI work in 1992 was very heavily based on user research, famously so at Apple. They definitely had the data.

I find myself questioning that today (like, have these horrible Tahoe icons really been tested properly?) although maybe unfairly, as I'm not an HCI expert. It does feel like there are more bad UIs around today, but that doesn't necessarily mean techniques have regressed. Computers just do a hell of a lot more stuff these days, so maybe it's just impossible to avoid additional complexity.

One thing that has definitely changed is the use of automated A/B testing -- is that the "empirical data" you're thinking of? I do wonder if that mostly provides short-term gains while gradually messing up the overall coherency of the UI.

Also, micro-optimizing via A/B testing can lead to frequent UI churn, which is something that I and many others find very annoying and confusing.

I don't think that's fully accurate, unless you have a link that confirms it? That Dye designed it, I mean, not that it was horrible...

Jony Ive was the head of design at that point (both hardware and UI). Wikipedia says Dye "contributed greatly to the design language of iOS 7" but Ive would have had final say. Certainly at the time as I recall it, iOS 7 was seen as Ive's baby.

Also, I'm not defending iOS 7, but I reckon its visual design was a lot more influential than it gets credit for. Think of those ubiquitous Prime bottles, with their bright saturated color gradients; the first place I remember seeing that style was iOS 7. I bet they picked that style for Prime because kids liked it, and kids liked it because kids like iPhones.

Edit to add: "bright saturated colors" goes back a long way to Fisher Price toys and the like, of course, but it's the gradients specifically that I think iOS 7 popularized.

The accusation usually levelled at cutting-edge jazz (fairly or unfairly) is that it’s so niche that it is difficult to get; that it’s left behind any pretence at being popular music. Many listeners would even go further and sneer “they’re just playing notes at random!” or “you’re just pretending to like it!”

I do wonder whether good-sounding, easy-to-get music is purely a matter of fashion (being just different enough to be interesting, but conventional enough to be accessible), or if to some degree there’s another axis of skill/difficulty in great pop music, of making it catchy and universal.

I think Guaraldi is almost like a jazz version of Erik Satie, who’s been discussed here a few times. His music seems very simple, almost simplistic, but his taste and feel are superb. It’s just really good and easy to listen to, which unfortunately means it gets dismissed as “easy listening”.

You don’t think that’s pretty bad?

I don’t think this is specific to any one language or environment, it just gets more difficult the larger your project is and the longer you go without updating dependencies.

I’ve experienced this with NPM projects, with Android projects, and with C++ (neglecting to merge upstream changes from a private fork).

It does seem likely that dynamic languages make this problem worse, but I don’t think very strict statically typed languages completely avoid it.

Either the design is fundamentally incompatible with European regulations, or they just don't think there's market demand. But note that other US truck do sell in Europe and the UK, e.g. the F-150.

There's something special about the Cybertruck. The special thing seems to be that it's a lemon.

This is some of the best writing on AI since Ted Chiang's "ChatGPT Is a Blurry JPEG of the Web". And that was in the New Yorker too! Might need to get myself a subscription...

Yes it is more complex, but it's nowhere near the complexity of the human or bird brain that does not use clocks, does not have "turing machines inside", or any of the other complete junk other people posted in this thread.

The information in Jira is just less complex, but it's in the same vein of the data in an LLM, just 10^100 times more complex. Just because something is complex does not mean it thinks.

So, what is the missing element that would satisfy you? It's "nowhere near the complexity of the human or bird brain", so I guess it needs to be more complex, but at the same time "just because something is complex does not mean it thinks".

Does it need to be struck by lightning or something so it gets infused with the living essence?

The counter-argument is, even if it’s not perfectly secure, that extra bit of friction before you can see the passwords is useful, and may just save your bacon if a casual thief has access to your computer for a few seconds.

The Chrome team eventually saw sense and added some client-side password protection.

As long as you don’t only have client-side protections, of course (and maybe your clueless auditors were making that mistake).

Acorn won the bid to make the original BBC home computer, with a 6502-based design.

Acorn later designed their own 32-bit chip, the ARM, to try to leapfrog their competitors who were moving to the 68000 or 386, and later spun off ARM as a separate company.

If so, you have the extra cost, effort and bureaucracy of building and deploying to all the different app stores. Apple's App Store and Google Play each have various annoyances and limitations, and depending on your market there are plenty of other stores you might need to be in.

Sometimes you do need a native or native-feeling app, in which case a native wrapper for JS probably is a good idea, other times you want something lightweight that works everywhere with no deployment headaches.

Vite gives you that behaviour out of the box.

I particularly like that (JSX aside) it's just JavaScript, not a separate language with its own compiler like Svelte (and by the sounds of it Marko, which I hadn't heard of before). You can split your app into JS modules, and those can all use Solid signals, even the internal bits that don't have their own UI.

You need to manipulate a large sheet, and you probably need to move around, bend down and lean over to reach all the corners. Bonus points for neat hospital corners on a flat sheet.

Putting pillows in pillowcases is another fun one. Usually pretty easy, probably a bronze medal.

Gold medal: put a UK super king size duvet inside a duvet cover. It's huge and awkward, there are buttons, and it's almost but not quite square (why??) so there's a good chance you'll get it round the wrong way and have to rotate it 90 degrees.

The nice thing about JS workers is that they can start really fast from cold. If you have low or irregular load, but latency is important, Cloudflare Workers or equivalent is a great solution (as the article says towards the end).

If you really need a full-featured container with AOT compiled code, won't that almost certainly have a longer cold startup time? In that scenario, surely you're better off with a dedicated server to minimise latency (assuming you care about latency). But then you lose the ability to scale down to zero, which is the key advantage of serverless.

So I think it's reasonable to say that, to paraphrase the earlier comment, putting an X in a box on a piece of paper is how it's done in most of the world.

It's true that the ballots aren't always counted by hand.

When you’re connecting those two knots, it seems like you have the option of flipping one before you join them. It does seem very plausible that that extra choice would give you the freedom to potentially reduce the knotting number by 1 in the combined knot.

(Intuitively plausible even if the math is very, very complex and intractable, of course.)

I didn't use any LLMs for those comments, but that comment style feeds into the training data, so it's not surprising if LLMs like to copy it!

The choices of JS and Python were pretty solid for the prompts I gave. Maybe the LLM is, well, making a reasonable decision in context, rather than just defaulting to Python!

"LLMs prefer Python" is an over-simplification. Python was already very popular, so I agree that LLMs are likely to entrench that popularity, but that doesn't mean Python will grow into other areas where it wasn't being used much before.

I would have assumed it might be JS and more specifically React -- isn't that what you often get if you ask an LLM to "make an app that does such-and-such"?

(Experimental anecdata: I just asked Gemini to write an app and it gave me a single HTML file with embedded JS, no TS or React, Tailwind for CSS.)

(Edit to add: then I asked it to "write some code" instead of "write an app", and this time it went with Python.)