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

401–410 of 504 posts

Re: Software Disenchantment (2018)

#401

Post by mikro2nd »

crazygringo wrote: post #244
pcurve wrote: post #190

Earlier quoted context omitted.

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? "

I mean... considering the fact that in contains the probabilities of typing every single word in the English language versus every other, at every stage of typing, including potentially the probabilities of all the ways you might mistype each word while swiping without precise accuracy... ...maybe? I don't know if that's 150 MB' worth of data... but it's certainly a lot.

So why is it persistently, perniciously and stubbornly insistent in refusing to spell 'naughty' words like 'duck'?

Re: Software Disenchantment (2018)

#402

Post by danenania »

TeMPOraL wrote: post #154
ljm wrote: post #30

Earlier quoted context omitted.

I have to be careful about what I describe, but I don't think people care about speed or performance at all when it comes to tech, and it makes me sad. In fact, there are so many occasions where the optimisation is so good that the end user doesn't believe that anything happened. So you have to deliberately introduce delay because a computer has to feel like it thinks the same way you do. At my current place of emplo…

> In fact, there are so many occasions where the optimisation is so good that the end user doesn't believe that anything happened. So you have to deliberately introduce delay because a computer has to feel like it thinks the same way you do. I never liked this view. I can't think of a single legitimate use case that couldn't be solved better than by hiding your true capabilities, and thus wasting people's time. > the…

"I can't think of a single legitimate use case that couldn't be solved better than by hiding your true capabilities, and thus wasting people's time."

Consider a loading spinner with a line of copy that explains what's happening. Say it's for an action that can take anywhere from 20 milliseconds to several seconds, based on a combination of factors that are hard to predict beforehand. At the low end, showing the spinner will result in it flashing on the screen jarringly for just a frame. To the user it will appear as some kind of visual glitch since they won't have time to even make out what it is, much less read the copy.

In situations like this, it's often a good idea to introduce an artificial delay up to a floor that gives the user time to register what's happening and read the copy.

Re: Software Disenchantment (2018)

#403

Post by machiaweliczny »

jiofih wrote: post #88
buboard wrote: post #68

He has a nice follow up which gets to the reasons why https://tonsky.me/blog/good-times-weak-men/ Another take: rewrites and rehashes tend to be bad because they are not exciting for programmers. Everything you re about to write is predictable, nothing looks Clearly better and it just feels forced. First versions of anything are exciting, the possibilities are endless, and even if the choices along the path are subop…

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…

React is super simple - I could implement same API from memory so I don't think it's the root of the problem.

> Nobody

Speak for yourself

Re: Software Disenchantment (2018)

#404

Post by pedagand »

ncmncm wrote: post #264
johnwatson11218 wrote: post #93

When I was in school and first leaning about programming I assumed that code written in C or Java would eventually be ported to hand tuned assembler once enough people were using it. Then I got in to the industry and realized that we just keep adding layer after layer until we end up at the point this article talks about. I remember once reading that IBM was going to implement an XML parser in assembler and people we…

XML actually is parsed with assembly code, now, using vector instructions that split up bytes, bits 0 of 128 or more bytes in XMM0, bits 1 of the same bytes in XMM1, et al., and doing bitwise operations on the registers to recognize features. Imagine how bad it would be if not!

That's interesting: would you happen to have any reference implementing/describing such a parser, by any chance?

In the crypto world, this is called "bitslicing":

https://www.bearssl.org/constanttime.html#bitslicing

Re: Software Disenchantment (2018)

#405

Post by mikro2nd »

vojta_letal wrote: post #391

Most of the issues outlined are problems of the web. The HTML+CSS+JS combo is just painfully slow and wasteful by design - it's just way too many levels of flexible abstractions. Which is suboptimal for app development. Moreover it's expensive to maintain two apps - web and native - which share have the exact same UI/UX. Hence the rise of Electron, React Native , ... The only way out of this is to rethink the web. Wh…

I think it's a desktop problem, too. TBH I don't know how things are over in the Mac/Win world, but over here in Linux land it's... not so good.

Boot used to be a small number of seconds. Now (on the rare occasions I'm forced to actually boot/reboot) I start the machine and bugger off to make coffee while it does its thing. I don't know what takes so fucking long, but it's in the range of 'several minutes'.

Starting apps likewise. I just started up an infrequently used picture-editing app a little while ago,... up towards a full minute of 'loading this crap', 'loading this other crap', etc.

And let's not mention Atom (an Electron app unless I've misunderstood something) -- so laggy for some things that should be near-instant that I'm developing an active hate.

Alright: get the hell off my lawn now!

Re: Software Disenchantment (2018)

#406

Post by Sharlin »

mynegation wrote: post #136
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…

What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.

To an extent, UI was solved in 1991 by Visual Basic. Yes, complex state management is not the best in a purely event-based programming model. Yes, you didn’t get a powerful document layout engine seamlessly integrated to the UI. Yes, theming your components was more difficult. And so on. But… if the alternative is what we have now? I’m not sure.

Re: Software Disenchantment (2018)

#407

Post by adrianN »

username90 wrote: post #385
thanhhaimai wrote: post #45

Earlier quoted context omitted.

> "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…

You are thinking too small, with a car generating power that cheaply you could use it to power a turbine and provide cheap electricity to the entire world. It would fix our energy needs for a very long time and it would usher a new age!

Or the car could just be very efficient. Gasoline has a lot of energy. Transporting a person 100km on 34MJ/l * 0.05l =1.71MJ doesn't sound as impossible as you make it seem.

Re: Software Disenchantment (2018)

#408

Post by neop1x »

vojta_letal wrote: post #391

Most of the issues outlined are problems of the web. The HTML+CSS+JS combo is just painfully slow and wasteful by design - it's just way too many levels of flexible abstractions. Which is suboptimal for app development. Moreover it's expensive to maintain two apps - web and native - which share have the exact same UI/UX. Hence the rise of Electron, React Native , ... The only way out of this is to rethink the web. Wh…

...but it works everywhere (Win/Linux/Mac/Phones/Tablets/Consoles/Cars), no need to fight with incompatible shared dynamic libraries or ask users to install 20 native library dependencies. And the webapp is developed waaaay faster with waaay less work and money.

I also see the problem. I hate bloated websites. I hate all those little unnecessary fancy CSS animations, I use uMatrix and regularly have to figure out which of those blahblahcdn.com domains (subdomains are whitelisted) needs to be enabled to make it work.

But even those webapps can be made to be "fast enough". Developers just have to be very careful on the design from the beginning and try to use as little deppndencies as possible. Prefer simplicity and speed over fancy effects and unnecessary features no one asked for.

Re: Software Disenchantment (2018)

#409

Post by jordanbeiber »

I’m in a bad mood today, and IM bad mood O, much of this is a symptom of modern economics and business management.

Also - resources that are essentially free to use (customer/users CPU cycles, storage and bandwidth) will be consumed.

We as consumers are paying the bills for it all in different ways(electricity, new gadgets, cloud costs etc).

Re: Software Disenchantment (2018)

#410

Post by modo_mario »

buboard wrote: post #95
coldtea wrote: post #67

Earlier quoted context omitted.

Combining these two is only a non-issue with unlimited resources. Otherwise it's a tradeoff if you add constraints like cost, effort, time to market, and so on...

Windows does it. And despite that, versions like win 7 were pretty fast

Fuck no. A bit faster does not mean fast. It's slow as fuck basically across the board.
Post reply on HN