Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

531–540 of 564 posts

Re: We have used too many levels of abstractions

#531

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…

> The issue, as with any automation, is that new players on the scene (younger devs, devops, etc.) simply have no chance to learn the same things and go trough the same path. The worst problem, which TFA alludes to, is that those "layers" are not really needed, they are leaky kludges upon kludges to make some lower layer unsuitable for later needs more palatable or able to handle some unforeseen use case that's again…

Yes. And we know this process from legacy code. Rather than fix the problem, it is usually easier to just write some new code to manage the old problem. We tack on new layers, modules, abstractions, workarounds all because at the time it seemed to be easier than refactoring the cause of the problem.

But it only works so far and at some point the application becomes unmaintainable mess and the effort to rewrite it from scratch starts.

Only we can't rewrite the world after it has become so unmaintainable that nobody can figure out how to change a detail of some layer inbetween the program and the transistor.

Heck, we are already stuck trying to fix the bad design of IPv4.

Re: We have used too many levels of abstractions

#532

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…

> spending a decade working with a low level programming language before you jump into high level programming language is simply not an option. Nobody said that. But spending a week is definitely an option to all programmers, and many would benefit from it.

There is a lot of beginner level resources. But there is very few or any resources to teach you the things you learn doing the job for a decade.

Re: We have used too many levels of abstractions

#533

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…

> perseverance to really understand all those things by diving into obscure, historical manuals. You say you were lucky to be there in the beginning and that young people don't have this advantage. Then you conflate your own luck with perseverance.

I am not conflating anything. For me it was my day to day work for decades. Some new technology happened and I had to learn it to be on top of my game.

Trying to learn all this in 1/10th of the time to start your career is what requires perseverance.

Re: We have used too many levels of abstractions

#535

Earlier quoted context omitted.

At least in JavaScript land all production ready frameworks only solve two problems: architecture in a box and put text on screen. These are trivial to achieve at substantially lower effort without the frameworks, but it requires a more experienced or better trained developer. What you describe is a training failure, but your thoughts on the matter are an economic failure. The goal of software is eventual cost reduct…

> These are trivial to achieve at substantially lower effort without the frameworks, but it requires a more experienced or better trained developer. Say more? What do you see as the trivial non-framework path (choose any example problem you like)?

Some developers believe everything is always a framework or any attempt to avoid frameworks creates a new framework. I cannot help these people. Any non-religion is a cult type nonsense of affirming the consequent fallacy.

Otherwise a valid example is this one file that creates a complete OS-like GUI in the browser awaiting content typically populated from WebSocket messaging: https://github.com/prettydiff/share-file-systems/blob/master...

Re: We have used too many levels of abstractions

#536
post #214

Earlier quoted context omitted.

Why do you need money to learn things? The internet exists. The library exists. Meetups exist. Go out and learn things you are interested in.

Not dying of hunger is a good motivator.

If you are dying of hunger I doubt you have the time to be posting about it on hacker news.

Re: We have used too many levels of abstractions

#537
I've been writing software since the early 1980's and I remember being pushed to get it working and thinking "they'll rewrite this and fix it in the future, this is just to get it working now". It's been terrifying to realize over the years since then that no one ever revisited the code and it still has not been fixed in many cases. Some of that code was used to control trains, nuclear power plants, chemical factories, medical systems, and satellites. I suspect some of it has been replaced, and ultimately it was the responsibility of the people building those systems to make sure they worked correctly, but poorer countries often stole software and a lot of it was still seeing use long after the product was no longer even sold. The world is in some cases hanging on a thread of old software that no one understands any more and no one is supporting. Source code may not even exist.

I've worked in software QA also and abstraction is the bane of debugging, especially when you can't even see the code in the libraries you're using. Proprietary binary blobs in embedded systems are the worst.

Re: We have used too many levels of abstractions

#538
post #468

Earlier quoted context omitted.

Not sure I understand your point. I read "it's not that they did not know how to disable the feature, it's just that they were not told how to disable the feature". Or are you saying that they knew, but somehow did not do it?

They were literally never told such a thing exists and it can be turned off. So they tried what they can without touching it to no avail.

Plus - FAA and Boeing + contractors did too much high level abstraction.

Re: We have used too many levels of abstractions

#540

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…

> However, this is not for everyone; 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.

Knowing the nitty-gritty of the acoustics theory and the related math may not help you much as a musician... (that being said, if you're building a home studio or doing any mixing/mastering, you'll find it helpful to learn about physics of standing waves etc).

However, the details of how frequencies come to form the well-tempered scale with all the tradeoffs and imperfections, and the low-level details of music theory, would be something many musician nerds would actually know.

Post reply on HN