Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

Post reply on HN
Print view View original

321–330 of 504 posts

Re: Software Disenchantment (2018)

#321

Post by modeless »

pcurve wrote: post #190
peter_d_sherman wrote: post #170

Excerpt: "An Android system with no apps takes up almost 6 GB. Just think for a second about how obscenely HUGE that number is. What’s in there, HD movies? I guess it’s basically code: kernel, drivers. Some string and resources too, sure, but those can’t be big. So, how many drivers do you need for a phone? Windows 95 was 30MB. Today we have web pages heavier than that! Windows 10 is 4GB, which is 133 times as big. B…

My favorite was "Google’s keyboard app routinely eats 150 MB. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? "

This in particular is a terrible example. Gboard is full of good features that Windows 95 did not have. Features that require a way deeper understanding of natural language than existed on computers in 1995. Autocorrect, voice typing, swipe typing, handwriting input, translation. It's so far from "30 keys on a screen" that it's not even funny.

Re: Software Disenchantment (2018)

#322

Post by zbentley »

qqii wrote: post #265
TeMPOraL wrote: post #189

Earlier quoted context omitted.

Browsers are fine. It's the websites that are slow. It's not the fault of Firefox that Reddit's new UI is pathetically slow. It's the Reddit's implementation of their UI itself which is total garbage. And given that people do write fast, complex, real-time games in JavaScript for the browser, gamedev absolutely becomes a valid reference point for the possible performance of any individual page.

Hmm, that leads be to an interesting counter idea. Why should Firefox or any other dynamic software have the ability to be slow for what it archives? If compilers should be fast, Web engines should be equally as fast. The Web should have never been designed such that a slow website (relative to the task) could be achieved. In the same way that you can only express memory safe code in rust and type safe code in haskel…

> The Web should have never been designed such that a slow website (relative to the task) could be achieved

That's already the case, your orders of magnitude are just off. Long-running AJAX or page loads are timed out at a pretty consistent point across browsers. Half-open/closed TCP connections are timed out at a pretty consistent point across operating systems. Busy-looping JS gets you a "page is not responding" block in a similar amount of time; same for nonresponsive native applications on many operating systems.

Their definition of "slow" or "stuck" just tends to be "tens of seconds or minutes", not the threshold of perceived responsiveness you want in a website.

Also, your parenthetical is a pretty tall-née-impossible order:

> a slow website (relative to the task)

How could the "task" be classified? Do you mean "task" as in "clicking a button and having a DOM update"? Or as in "this is a TODO application so it should have responsiveness threshold X"?

Re: Software Disenchantment (2018)

#323

Post by ateng »

> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms.

Modern text editors have to deal with proportional font, right to left writing, anti-aliasing, and a big bag of Unicode related issues (Arabic is going to break all assumptions you have on language and text editing)

Fantastic read on this subject from few months ago:

https://news.ycombinator.com/item?id=21384158

Re: Software Disenchantment (2018)

#324

Post by Aeolun »

jeffmcmahan wrote: post #222
jiofih wrote: post #88

Earlier quoted context omitted.

He hints at Electron in the end, but I think the real blame lies on React which has become standard in the past five years. Nobody has any fucking idea what’s going on in their react projects . I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happe…

I completely agree, here. React has replaced the DOM, and it's pretty fast, pretty efficient when you understand its limitations... but when you start rendering to the canvas or creating SVG animation from within react code, everything is utterly destroyed. Performance is 1/1000 of what the platform provides. I have completely stopped using frameworks in my day-to-day, and moved my company to a simple pattern for upd…

It seems to me that using your react components to render SVG animations, or to canvas, is just inviting disaster.

Re: Software Disenchantment (2018)

#325

Post by jodrellblank »

johnwatson11218 wrote: post #179
jodrellblank wrote: post #168

Earlier quoted context omitted.

The main idea being that for a given input the output really is 100% predictable [..] I think it would be super fast once you got it working. I imagine it would be fast, then you realise you've made a static content caching layer out of a neural network and replace it with Varnish cache and it would be hyper fast.

I don't think a caching layer would work. One example would be an online mortgage estimator. You input the loan amount, interest rate, length of loan etc. all as http input parameters. I'm suggesting that the LSTM can eventually figure out that those variables are being used by the application code to go in to a formula. That application code and its formula would all be replaced by the LSTM. I just don't know how yo…

Seems that either the NN memoizes all the inputs and outputs until the function is totally mapped - then functions as a memoized lookup table, or the NN has discerned what the mortgage calculation is, and is doing exactly the calculation your {Python} backend does, but migrated into an NN middleware layer instead, which sounds like it would be slower.

And then you're hoping that the NN would act like a JIT compiler/optimiser and run the same code faster. But if it was possible to process (compile? transpile? JIT compile?) the Python code to run faster, then writing a tool to do that sounds easier than writing an AI which contains such a tool within it.

So there's a handwave step where the AI develops its own innate Python-subset optimiser, without anyone having to know how to write such a thing, which would be awesome indeed .. is that possible?

Re: Software Disenchantment (2018)

#326

Post by clouddrover »

thanhhaimai wrote: post #45
rogerdb wrote: post #20

> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…

> "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. I'll prioritize the 0.005L per 100km car for sure. That means the car can be driven for all its expected lifetime (500k km) in a single tank of gas, fill…

> I'll prioritize the 0.005L per 100km car for sure. That means the car can be driven for all its expected lifetime (500k km) in a single tank of gas, filled up at the time of purchase!

It's a nice idea but it wouldn't work. The gasoline would go bad before you could use it all.

Plug-in hybrids already have this problem. Their fuel management systems try to keep the average age of the fuel in the tank under 1 year. The Chevy Volt has a fuel maintenance mode that runs every 6 weeks:

https://www.nytimes.com/2014/05/11/automobiles/owners-who-ar...

https://www.autoblog.com/2011/03/18/chevy-volts-sealed-gas-t...

Instead of having a "lifetime tank", a car that uses 0.005L per 100km would be better off with a tiny tank. And then instead of buying fuel at a fuel station you'd buy it in a bottle at the supermarket along with your orange juice.

Re: Software Disenchantment (2018)

#327

Post by Aeolun »

ratww wrote: post #247
TeMPOraL wrote: post #192

Earlier quoted context omitted.

To the extent it's in your power as a developer and a team member, don't tolerate low-performance code from yourself or your co-workers. In my experience, a lot of performance problems boil down to really stupid problems, like simple code using the wrong data structure out of convenience (e.g. linked lists instead of arrays for lots of randomly-accessed data), or structured in a bad way (e.g. allocating a lot of smal…

I agree with your point of developers being responsible for the performance. But I have a different experience (probably because we work in different areas): Most the performance problems of the products I ever worked were purely systemic. They boiled down to technologies and architectures having been chosen for "organizational" rather than technological reasons. And "organizational" is in quotes because sometimes it…

Ah, I can tell you such stories of a stack that evolved solely out of incompetence...

Re: Software Disenchantment (2018)

#328

Post by hnuser123456 »

qqii wrote: post #279
mtm7 wrote: post #176

Earlier quoted context omitted.

I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardwa…

Unfortunately this isn't the perfect solution as there is no universal device or average user. Especially with music, mixing songs for earbud/headphones will produce a worse quality song for another pair. In the same way we've seen software written by users primarily using x86 work less effectively when compiled to arm. Plenty of open source projects are developed on by people with less than adequate hardware yet the…

No one said you have to test on everything. Just adjust your target and testing hardware to something midrange, maybe even budget optioned. As above, test on some mid-range or even budget-level 2015 hardware, laptop or phone, and if it's smooth on that, it'll be smooth for people running 2020 hardware. You can never be sure about the reverse.

That being said, there's a lot of crap software out there that's slow even on 2020 hardware.

Re: Software Disenchantment (2018)

#329

Post by kmlx »

d23 wrote: post #276

Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time. As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same…

this usually happens with ad blockers. they somehow mess up a page, and then you get angry customers saying the page doesn't work for them.

we need a solution to this mess. so far i've seen popups (of all things) letting users know they should disable the ad blocking. but that's not a solution. ideally websites should not break when ad blockers are enabled, but i've seen sites where their core product depends on ad blocking being disabled. strange/chaotic times we live in.

Re: Software Disenchantment (2018)

#330

Post by mrcsharp »

I agree with the author on every point except:

>That is not engineering. That’s just lazy programming

I don't believe that developers/programmers are all lazy. There are a lot that want to do a good job optimizing their code and making sure it performs well and is future proof as much as possible. I believe that budget limits and pressure from deadlines set by non-technical people forces even the good programmers to cut corners in order to deliver.

Post reply on HN