As someone who most often works in a language that is literally orders of magnitude slower than this —- and has done so since CPU speeds were measured in double-digit megahertz —- I am crying at the notion that anything here is measured in nanoseconds

What language is “just as productive but isn't going to lock us into abysmal performance down the line”?

What makes that language not strictly superior to Python?

Sure, my language of choice is more flexible than that: I can type

   put "test abc999 this" into x
   add 1 to char 4 to 6 of word 2 of x
   put x -- puts "test abc1000 this"

But I'm still curious -- what's the better language?

> The biggest commercial success is not the best technical design: Nokia N95 versus the first generation iPhone

That’s not a good example. Neither is Beta vs VHS. The most they illustrate is a different law I am coining right here:

Canyon’s Law of Design Optimization: you will inevitably choose to optimize for different metrics than your customers would wish. Don’t try to convince them they are wrong.

That's not a good example, but for a different reason: the N95 outsold the original iPhone.

The original iPhone was a promising proof of concept. It got the form factor and the interface right, but the actual device was underwhelming. It had no 3G, no GPS, no third-party apps, and a weak camera. iPhone 3G added all the features competitors already had (apart from a good camera) and became a much bigger commercial success.

The N95 outsold the IPhone because it had a good camera and was cheaper, and got even cheaper with the phone companies subsidy.

But I'd be surprised if Apple didn't have a beefier profit with the IPhone compared to Nokia with the N95.

They definitely didn't. Apple was starting from scratch in the market, and the original iPhone did a whole bunch of things it shouldn't have, making it needlessly expensive to build for the hardware it included. This is partly why Nokia initially dismissed it, as soon as it was on the market, teardowns showed that it was basically an amateurish prototype that was pushed to production, internally much worse than you'd expect from a mature company that was used to building consumer electronics. The N95 could be sold for less because it was legitimately a lot cheaper phone to build.

Then only a year later the iPhone 3G came out, and it was a rough wake-up for Nokia. Because that one was actually a well-built sane design.

I had to look up the N95. Yeah, Wikipedia goes to pains to rattle off things that made it better than the iPhone, but then I looked at a photo of the device and it was clear why the iPhone "won".

I has a Nokia N95. The phone itself was great. The problem was the dearth of apps. Nobody developed anything for windows mobile OS. Maybe Ballmer was not so crazy when he was running around on stage screaming “Developers, developers, developers”.

N95 didn't use Windows mobile. It used Symbian, and the reason there were so few apps was that the development experience was downright horrible.

This was the (juvenile) nerd take back then https://maddox.xmission.com/c.cgi?u=iphone/

(Nokia E70 not N95, but still)

That's funny. I guess the iPhone was the poseur phone, the Nokia was punk.

> That’s not a good example

It’s a great example. One can list a litany of technical specifications on which the N95 is superior. That, however, doesn’t make it a superior product.

"technical design" vs. "technical specs"

I think we're in violent agreement.

So it seems like with the right code (and maybe a ton of future infrastructure for training?) Eliza could have been much more capable back in the day.

The original ELIZA ran on an IBM 7094 mainframe, in the 1960s. That machine had 32K x 36-bit words, and no support for byte operations. It did support 6-bit BCD characters, packed 6 per word, but those were for string operations, and didn't support arithmetic or logical operations.

This means that a directly translated 40 KB Z80 executable might be a tight squeeze on that mainframe, because 40K > 32K, counting words, not bytes. Of course if most of that size is just 2-bit weight data then it might not be so bad.

ELIZA running on later hardware would have been a different story, with the Z80 - released in 1976 - being an example.

I maintain Navigator, a development tool I started over twenty years ago; I am the only contributor to the open source repository [1]. I have rewritten drag and drop in that thing four times (because drag and drop in Livecode [2] is a bit of a hack). It's a pain every time. I'm not rewriting it again.

1. https://github.com/gcanyon/navigator

2. https://livecode.com

Interesting: for me, the image quadrants display correctly in Safari, but there is a horizontal white line between the top and bottom left quadrants. You're not seeing that?

I see the white line on mobile, but not on desktop, though my OS versions are wildly different too, so hard to narrow down exactly what it might be there.

The white line is just because the four quadrants are four separate images, and the four images are HTML-aligned together to make one.

I see the white line on Safari, and also on Mac Firefox. No idea what the line means—it's not present in any of the reference images.

While not disputing in any way the truth of what you're saying: I'm a product manager who leans toward Safari, while the devs I work with use Chrome almost exclusively, and we have an unwritten agreement that when it comes to display/layout issues, I'll double check in Chrome before filing the bug. It's only been Safari-exclusive a handful of times, but that's enough that it's annoying for everyone when it's just me.

I guess the question here has to be: is this actually a bug in Safari? Or is it a bug in Chrome, that people (whether that's your people or third parties) have just been working around in a way that doesn't work in Safari?

And this is a big part of the problem with having Chrome become such a dominant force on the web: people assume that it's correct when Safari displays something differently. And people give instructions and documentation for how to do various things "in HTML/CSS/JS" when they've never tested them in anything other than Chrome, so if Chrome's behavior deviates from the spec there, someone implementing those instructions on Safari will see them fail, and assume incorrectly that it's Safari that's wrong.

Note that I am not saying this is what is happening in any specific case—but because Chrome is so dominant, enough people treat it as the de-facto standard that over time, it becomes a near-inevitability that this will happen in some cases.

I've run into Safari exclusive issues before as well around color transparency, but tbh I'm surprised it comes up that often. Modern IDEs support linters that warn you whenever you are using a CSS feature that isn't supported by all modern browsers. You can even set the year you wanna support (e.g. all major browser versions since 2023). Between that awesome tooling and rapidly improving browser support for web standards, these kinds of issues feel extremely rare.

Except for printing. Printing has and seemingly always will f'n suck. Unfortunately WPT doesn't have a good way of testing for print-related features

I can only speak to my experience, but I spent a long time being puzzled by video editor user interfaces, until I ran into ScreenFlow about ten years ago. For whatever reason, the UI clicked, and I've used it ever since. It's a single purchase, not monthly, and relatively affordable. https://www.telestream.net/screenflow/overview.htm

How to build and deploy web apps. I worked as a developer for many years (before becoming a product manager), but always in desktop apps. I still code for fun, but I never made the jump to web apps. Now with AI that's easier than ever, so I'm going to do it.

Python. I played around with it three years ago, and did about 30 Project Euler problems with it, but I've let that lapse. I'll work to pick that up.

I bought my wife a learn-to-draw kit for Christmas, but it's really a gift for both of us.

When our kids were little we got them a wire bead rollercoaster, something like: https://www.ebay.com/itm/304637213979

It's one piece. Cleanup is picking it up and putting it where you want it. For playability, that thing kept each of our kids occupied for an unreasonable portion of their toddler-hood. We then passed it on to friends, and it did the same for their kids. They kept it, and gave it back to our kids when they had kids, and it's still delivering joy.