Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

101–110 of 564 posts

Re: We have used too many levels of abstractions

#101
post #65
post #22

I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'. Programmers too often add indirections which don't provide abstraction: * The programmer wants to POST an object to a web server. * The programmer also wants to think about it at the level of POSTing an object to a web server. * And yet the programmer creates an HttpClient.java and an AbstractClient…

Yes. Anything that is destroyed during the process of compilation is not architecture. It is just a method of code organisation, and we've turned the subject into a holy war, pulling in mindshare that should be spent on more important problems (e.g. we have fibre lines and Ghz multi-core processors, but why are user interactions slower than they were in 1995?). 80% of code organisation problems require doing a couple…

This an amazing way to concisely explain the difference between indirection and abstraction. Works for me at least.

Anything undone by the compiler (perhaps even inlined) is just indirection. Everything beyond is actual abstraction (which cannot be broken down further by the compiler as it’s far too limited in its understanding).

Re: We have used too many levels of abstractions

#103
post #66

Reading this, I had an epiphany about why open-source software is essential. How do you peak under opaque abstractions? It's just not possible. Imagine if Kubernetes was closed source & binary distribution only. Understanding abstractions is, I think, why being open source has become table stakes for infrastructure software.

To add: the two most popular languages by most popular metrics, JavaScript and Python, are interpreted. There, you don’t have a choice.

Go is different of course. Your insight is very good. Not being able to dig into source code when needed is unimaginable.

Re: We have used too many levels of abstractions

#104
post #43
post #22

I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'. Programmers too often add indirections which don't provide abstraction: * The programmer wants to POST an object to a web server. * The programmer also wants to think about it at the level of POSTing an object to a web server. * And yet the programmer creates an HttpClient.java and an AbstractClient…

I think the reason people do that stuff is because they do provide abstraction, but they only do it in UML diagrams, not in the code. I've found the shittest programmers to work with are the ones that think visually, because in their head they just deleted two boxes and four lines, but in reality all they did was add 40 lines of code that do nothing.

I think visually, but in terms of memory and datastructures, not in UML diagrams. I don't think the "visual" part is the problem.

Re: We have used too many levels of abstractions

#105

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…

There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields. I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention". I'd love to hear from somebody with experience in scientific or other disciplines and IT who could contrast their fields with ours. I only know that I have had…

Analogue electronics design has been almost entirely replaced by digital micro-controllers to the point that finding old-school electrical engineers that can design non-digital circuits is becoming a challenge.

Re: We have used too many levels of abstractions

#106

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…

There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields. I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention". I'd love to hear from somebody with experience in scientific or other disciplines and IT who could contrast their fields with ours. I only know that I have had…

> There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields.

Much as I'd like that, I disagree.

The momentum has always been against that. We're members of a cult of the new, which does not value or even acknowledge the old. Which is why we keep reinventing the same solutions but with different tech stacks.

This drives developer value down which drives developer salaries down, so I don't see it changing.

FWIW, my history of math class as an undergrad was a math elective that almost nobody else took. Other math students didn't want to learn history and other history students didn't want math. And the curriculum stopped at the 18th century, before things got really interesting.

Re: We have used too many levels of abstractions

#107
"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 interpreted? Not really. Should you realize that every automation takes resources, creates accidental knowledge, and introduces its own probability of failure? Yes.

Re: We have used too many levels of abstractions

#108

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…

>We, people who really understand the technology that the world runs on, are a slowly dying breed.

And web development has the worst tech abstraction of all.

There used to be a time where any Software Engineers ( i think the term wasn't even invented then ) or simply programmers would know at least a thing or two about Hardware. We now have so much abstractions we have people working in tech who have zero knowledge on either software or hardware, or any low level stuff.

That is why not only do we need some open source or open standards ( I am not a zealot for everything open sources ), we also need to simplify everything we have today. To basically refractor everything we have learned from Hardware to Software.

Re: We have used too many levels of abstractions

#109

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…

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 lot of young coders don't understand what to do with it. They read the tweets saying it's nice, but when they look at it, it makes no sense to them.

It's really fun because I now remember how some senior coders looked at me, knowing nothing about compilation. I was struggling with Python packaging because before wheels, it required compiling a lot on linux, and it failed often. For them it was obvious: just install the headers, look you need the dev packages, wait, you don't have gcc?

Nowadays I happily patch nginx source code and compile it manually, but it took a lot of work to learn a minuscule chunk of what all those guys knew by heart.

Because they started with assembly.

Re: We have used too many levels of abstractions

#110

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…

There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields. I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention". I'd love to hear from somebody with experience in scientific or other disciplines and IT who could contrast their fields with ours. I only know that I have had…

>I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention".

Some of this just seems to be due to the maddening popularity contest of technologies and frameworks within companies. There is a frantic rush to make sure you're doing everything that your competitors are doing, but not much introspection regarding whether things will actually help your company. You're just keeping ahead for the sake of keeping ahead.

Post reply on HN