Yeah, you're basically treating user experience as an externality, though. The point is that the end user of the program doesn't care how expressive the language is, they care how long it takes to run. And the overhead piles up as the dependency stack gets deeper...

But the end user certainly doesn't care how long the program took to compile,which is something the author lumped together with runtime.

But end users do care about programs not crashing and losing whatever they were working on, they care about features, and they care about how long it takes for them to get the features they want, all of which are impacted in some way by the language and tools used by the programmer.

I thought the article was alluding to the fact that the same code ran 10x slower in JS, vs jvm

Yeah, so we're experiencing this right now. We're writing more and more of our app in Swift (slowly migrating from Objective C), and compile times are growing as a result. It's extremely frustrating. 90 second compile times seem forever when you are used to incremental builds that take only seconds.

That's fair. If it's 90s and it's part of a developer workflow that is triggered more than a few times a day, it matters. I haven't worked with Swift in particular, but in general you might be able to do incremental compilations to avoid that problem rather than "rebuild the entire project" with every change.

My real point is that I care about everything more than speed until I have a specific reason to care about speed. Then I'll care about speed.

In contrast, many programmers fetishize speed and efficiency as a quasi-religious value, even when they have no practical consequences.

I think Swift has support for incremental builds (it's not always 90 seconds).

The blog post was mainly written about GUI toolkits, if your application was freezing for 78 seconds waiting for a screen redraw you might be willing to settle for uglier syntax.

> if your application was freezing for 78 seconds waiting for a screen redraw

78 seconds was the compile time. The runtimes were almost identical: 0.45 seconds to run the entire test suite in the fastest case vs 1.3 in the slowest.

The slowest is three times slower than the fastest! That’s not almost identical at all, and could easily be the difference between a useable interface and an unbearable one...

It could be. And when I have evidence that user experience is affected, I'll care about the difference. But what if it's 1ms vs 3ms? Or 3ms vs 9ms? And the 9ms time is a much more expressive, productive, high-level language?

I'm not going to care about the difference just because "omg one number is 3x another number!?!"

For an soft realtime application like game that’s the difference between 10fps and 30fps. Or 30 and 90. Basically total failure or success.

I was referring to response time in a GUI app -- 9ms is undetectable.

Again, if you have a reason the speed matters, then it matters. The specific numbers here are not relevant to my argument, which boils down to: being "slow", in and of itself, is meaningless.

0.45 vs 1.3 is mentioned as being almost irrelevant in the article - from article: “Another interesting observation is that it makes no difference what hardware you use to run it. If the solution is fast, it’ll be fast on a notebook as well as on a beefed-up workstation-class desktop. Sure, it might be twice or thrice slower, but it’ll be a difference between 10ms and 30ms.”

All up the article starts with reasonable discussion about how different solutions can have more than 6 orders of magnitude time difference, then it segues irrelevantly to a complaint about electron.