Hacker News Reader

Comment by glial | Hacker News Reader

Given the speed of modern computers, I'm fascinated by the fact that so many processes complete in human-scale time (seconds-minutes), rather than milliseconds or years+, depending on problem complexity. If times for compute tasks have some power law distribution (a big if...), I'd expect a very small part of that distribution to overlap with the 'seconds' range.

Then again, computers do so many things in the millisecond range and faster that maybe what we observe IS only a small fraction of the total.

View on HN

It's a relief to do a bit of Go from time to time, render a complete html template in 40 ms (with almost 2 MB of JSON data) instead of spending forever figuring out the JS framework du jour to do the same thing, only with it feeling a lot more involved, heavyweight, and slow - even if said framework claims to be faster than all the other JS frameworks.

I think I want to do back-end or terminal-based interfaces again. Native interfaces. Mmmmm

I've had a similar experience on a current project.

Even after disabling any and all caching and minification (read: basically parsing all templates per request, a bit like PHP), the entire render process take less than 20ms of time to the point that I've simply left out caching during some production runs.

I also keep the interface free of any expensive rendering precisely because I don't really need all of the niceties of JS frameworks.

Surely, the page could be more fancy but vanilla HTML5/CSS3/JS can do the job too. (And document.querySelector has replaced jQuery for me)

> Native interfaces. Mmmmm

If you decide to work on native GUIs, please don't create your own toolkit on the assumption that you can do better than the OS. You'll almost certainly break at least one thing: accessibility for blind people.

This has nothing to do with Go and a lot to do with choosing the right tool for the job. Maybe Go is the best tool for you in this job, but a given js framework can serve someone else just as well if it is in their expertise area. Don't confuse your expertise with language/ecosystem pros and cons.

This has nothing to do with choosing the right tool for the job, but with performance, which this discussion is about. Practically all JS frameworks, having multiple levels of (near-inscrutable) abstractions naturally degrade the performance and certainly contribute to the trend the submitted twitter thread is talking about.

The right tool for the job != whatever tool is in your expertise area.

I'd love to see more terminal interfaces. I've been looking for a modern TUI library for a while.

It's pretty much an availability heuristic / complexity (or cost) constraint.

If the operation cannot be done quickly -- in a few seconds at most for reasonably interactive work, in a few minutes to, perhaps, a few days for batch -- then it's very, very very rarely done.

It it occurs in less than about 1/10 second, there's not much incentive to try to speed it up, and inefficiencies that bump process time up to even a few seconds tend to creep in. That despite the fact that there are psychologically and outcomes-measurable differences between interfaces with even 1/10s vs. 1/1000s delays or responses.

The Jevons Paradox plays into this, balancing against Gresham's. Stuff that's cheap (clock time) happens, stuff that's non-discernable (under perceptible / outcomes limits) tends not to get constrained.

You have it on the head. The tasks we pick for computing are the ones that can be completed in seconds.

There is plenty of interesting computation we could and would do if what now requires a year would only require a second.

I think the opposite direction is actually more telling. Developers tolerate bloat and BS up to the level of seconds.

So there is plenty of computation being done that only requires milli or microseconds, but due to development practices now stretches just out into the annoying time frame.

(Prime example: the growth of web pages to match increases in processing, RAM, and internet speeds, means that the web is actually slower to use these days.)

When the web was young and most people were on dialup, having access to a T1 meant that everything happened nearly instantaneously. All the sites were optimized for dialup levels of complexity. Now that everyone has broadband there is no equivalent. The slowness is either because the page is so heavyweight in terms of memory or processing power (note that more money does not buy much single-threaded performance), or because it's making so many network requests that everyone faces at a similar latency.

Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.

All programs grow to outstrip available computing resources?

> Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.

Until you install an adblocker and disable javascript. An enormous amount of modern-web overhead is adtech and user tracking cancer.

If you don't believe me, install privacy badger/ghostery and ublock origin, visit any popular news/entertainment website, and look at the number of blocked elements/requests as you load a few articles. All of those take time and suck up resources.

I've experienced this. My first computer managed about 100 flop/s, or 3 Gflop/year. A modern PC can do that year's work in a millisecond! Yet when my current computer struggles to display a web page there isn't much interesting computation going on.

We're usually not computationally bound. Often its disk or network I/O and that basically means tasks are content bound. We tune for maximum content in the acceptable human scale time. The moment we take less than a second to load something it means we can find more things to load.

I think it's mostly a cognitive bias, we don't even notice processes that take milliseconds, and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical.

> and we either optimise or simplify (approximate) problems that would have taken years to make solutions more practical.

Or we just don't do them.

Software engineers optimize for human scale time.

I kinda feel that UI developers should work with crappy, old PCs. Then they could optimize to the point where things are barely usable to them, but then they'd be snappy for everyone else.

Luckily Google Chrome has added device emulation recently for slower devices and network conditions. Hopefully tooling like that will make it in many developers Workflows.

Reply on news.ycombinator.com