Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

141–150 of 564 posts

Re: We have used too many levels of abstractions

#141

"Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction. And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or…

If what you claim were actually the case, the names we assign these "abstractions" wouldn't matter, they could be any arbitrary sequence of characters, since all you'd be doing is grouping code into procedures for the sake of automation. But the names we assign things obviously do matter, not only to make the reader grasp what the abstraction is about, but to decouple the abstraction from its implementation; two different abstractions may have an identical implementation and still be different abstractions, and an abstraction may remain the same abstraction even if you alter its implementation.

Re: We have used too many levels of abstractions

#142

This is an insightful article, although I don't necessarily agree with the view that "everyone" needs to know everything from first principles to be good at their job. Talking about abstractions, during my past month, I was reading nand2tetris, and it's a compelling experience if you understand the exercise you are doing, which is not about building a computer from first principles; it's much more than that. It makes…

> ...ask a musician if they are really in the weeds of why the instrument is producing music (the physics behind it!). They are probably aware that it's vibrating air, but, in general, they won't know the theory behind it. A big difference is that, unlike computing, their instrument probably won't stop working because of some subtle change to physics introduced by a seemingly-unrelated change made to the universe by…

> Knowing what the foundations are that the edifice you've constructed sits upon allows you to affect repairs when it crumbles unexpectedly.

Finally get to use this bit of knowledge: 'effect' (the verb) was the word you wanted there.

Re: We have used too many levels of abstractions

#143
post #139

> Power steering is yet another level of abstraction that further improves the driving experience. I am a pretty firm believer that antilock brakes are a bad abstraction that might cause fewer accidents, but often more dangerous accidents than they prevent. They avoid a class of accident caused by the brake’s locking limiting your ability to steer. They cause a whole class of accidents where you hit things at a highe…

Do you know that antilock brakes slow down you faster comparing to car with locked wheels?

Re: We have used too many levels of abstractions

#145

I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…

Unless you're two hundred years old, you joined the development of this technology in the middle. There was already decades of progress in electronics and telecommunications theory and engineering that everything you listed was built on top of. Your predecessors likely thought it was all newfangled abstractions that obscured more fundamental knowledge, and your successors will think the same about whatever world they…

Abstractions are only relevant when they are leaky. People alive today were flipping toggle switches to load individual machine codes into memory. Some of them literally knew what every single transistor in the machine was designed to do.

Programmers at the time went from thinking these kit computers are toys to watching all the old ideas like virtual memory, cache, pipelining, networking, and multiple cores get reintroduced as the anemic transistor budget exploded. None of it was particularly novel, but the slow introduction of older ideas was a great way to learn all this stuff from the ground up.

Re: We have used too many levels of abstractions

#146
post #67

Software's re-usability is both a blessing and a curse. Hardware also has modularity, but it is still common to build hardware from scratch. On the other hand, once a library or framework exists, many people no longer feel the need to understand the underlying algorithms. One side effect is that many of the frameworks or libraries still in use and that are important for the dependent software to work are written with…

I’ve seen decades old Fortran codebases that everyone is too scared to touch. So instead all the new ‘features’ marketed to clients are just window dressing around the existing Fortran core.

Side question: what kinds of codebases were those? What products were built on top of decades-old Fortran code? I'm curious.

Re: We have used too many levels of abstractions

#147

Earlier quoted context omitted.

I've heard that advanced math has a similar problem, that some subjects are quite deep that only a handful of people really understand the topic and passing the knowledge down to younger mathematicians is not a given.

Are there good historical examples of this happening, where foundational knowledge is completely lost? I know I have read about it in books as a fiction, but I assume it must have already happened here before. Maybe its an oxymoronic question to ask, seeing as if its lost we might not even know its lost, but more in the vein of "We put the lime in the mortar because this is what we have always done", unaware of the a…

It is all things. Encapsulate all things. Think fractals, hopf and always remember the turbo encabulator.

The original machine had a base-plate of prefabulated aluminite, surmounted by a malleable logarithmic casing in such a way that the two main spurving bearings were in a direct line with the pentametric fan. The latter consisted simply of six hydrocoptic marzlevanes, so fitted to the ambifacient lunar waneshaft that side fumbling was effectively prevented. The main winding was of the normal lotus-o-delta type placed in panendermic semi-bovoid slots in the stator, every seventh conductor being connected by a non-reversible tremie pipe to the differential girdlespring on the "up" end of the grammeters.

— John Hellins Quick, "The turbo-encabulator in industry", Students' Quarterly Journal, Vol. 15, Iss. 58, p. 22 (December 1944)

Re: We have used too many levels of abstractions

#148
post #120

Earlier quoted context omitted.

You can actually see this with new frontend devs. They know only full SPA frameworks, they have never seen a dump of an HTTP message, headers and verbs are abstract things to them. Hell, many of them don't know you can have fully functional websites with zero JS, including payment, video, login, etc. I started to write an HTMX tutorial ( https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 ) because I noticed a l…

>You can actually see this with new frontend devs. They know only full SPA frameworks, ...... Around I guess 2017 or even 2016? I used to think this is some sort internet troll comment about people never seen a dump of an HTTP message, until...... >Because they started with assembly. It wasn't necessary starting with assembly or something low level. ( Although that certainly helped ) We have less entertainment, more…

The "less entertainment" and "more broke things" is probably the critical piece of the environment.

This makes valuable anyone with long attention spans and immunity to boredom.

For me, it has taken some habit forming (and habit prevention), but I have learned so much in the past 10 years since giving up gaming and social media. HN is an occasional vice though...

Re: We have used too many levels of abstractions

#149
post #139

> Power steering is yet another level of abstraction that further improves the driving experience. I am a pretty firm believer that antilock brakes are a bad abstraction that might cause fewer accidents, but often more dangerous accidents than they prevent. They avoid a class of accident caused by the brake’s locking limiting your ability to steer. They cause a whole class of accidents where you hit things at a highe…

[flagged]

Re: We have used too many levels of abstractions

#150

> Question everything. Especially things that don't make any sense to you. Don't just assume that someone else knows better - that's how you quickly turn into a blind follower. That’s what I do by default since I was a kid, and I can tell you the social pressure not to is significant. I recall an interview I did once, and one reason I failed it was "questioning everything". It didn’t even felt like it, I was just ask…

> Questioning everything gets results, not friends.

I'd argue that it depends how it's done. I used to work with a brilliant Data Scientist who had a PhD in AI. She asked so many questions — often about fundamentals — that it was like working with the Riddler. She generated a ton of insight as a result and identified missteps before they happened. Despite questioning everything she was arguably the most liked person at the company because of how she approached it. It didn't feel like being grilled, but rather that she was super interested in people and what they were working on.

My point is that questioning everything can get results and friends if done correctly.

Post reply on HN