Comment by TheOtherHobbes | Hacker News Reader

Comment by TheOtherHobbes | Hacker News Reader

Parent Full thread

There's no such thing as "don't have to care about the details."

This is the biggest difference between then and now. In the 70s and 80s computing was all about details, all the way down to the hardware, which most developers understood at the register level.

8-bit amateurs grew up with simple toy machines. They learned enough detail to allow a natural transition to professional development on mainframes and minis - far more detail and more complexity, more of an OS to deal with, but with a recognisably similar outline.

Now most development is more like LEGO - clip moving parts to other moving parts in a slightly precarious way and hope nothing breaks.

It's a completely different way of thinking about computing - kit and cookbook based, with less space for original creation and problem solving. This is partly because the details are hidden and can't be changed, but also because the ethic of experimentation and creativity based on deep domain knowledge driven by curiosity isn't the same.

> There's no such thing as "don't have to care about the details."

The whole point of the many abstractions between the user and the hardware is so they don’t have to care about the details.

Not caring about the details leaves us with people who can't fix simple issues and with applications that use way too much cpu, memory or energy than they really should. Sure, a lot of people don't care and just want to do the thing, but if you at all care that your computer that is 1000x as powerful as the one you had years ago, but doesn't really do a lot more, then you have to care. If you care about the users of your application and don't simply pass your lower development effort on to them in terms of performance cost, then you have to care. If you want to be able to fix your own issues, then you have to care.

Yes, the abstractions mean people can do more without caring, which in turn means more people can use them, but it comes at a cost too.

Every user application doesn't have to be written in C.

Of course not, but from reading HN, I’m not the only one frustrated with the performance state of many applications. They don’t have to be written in C to perform well. For example, I quite like using Qutebrowser, a minimalistic keyboard-centric browser that’s more lightweight than Chrome or Firefox, yet its written in Python (well, I guess the actual browser engine is C++/Qt)

I'm reading this (late) in qutebrowser! Mine has so many tabs open but doesn't hang (until it does), which is a fresh change from luakit (and Chrome but not Firefox, alas mine has many many more tabs open so that I don't open it anymore.) And I'm using because it's written in Python (and so easily scriptable from my own Python program.)

Performance is a business decision.

It doesn’t come for free and ultimately other things might be more important.

If any performance gains from Moore's Law get canceled out by inefficient software due to Wirth's Law, then what's the point of all the work that we technologists are doing?

You can call it a business decision, but that basically means the tech people are doing the work and making our execs rich without actually creating anything that's more beneficial to humanity compared to the computer systems of 10 or 20 years ago.

Abstractions are, almost by definition, always imperfect. A perfect abstraction sort of ceases to be an abstraction and is simply "the way things are".

Reply on news.ycombinator.com