Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

171–180 of 564 posts

Re: We have used too many levels of abstractions

#171
post #8

I support the notion of this post. In the last 6 years I’ve mostly been busy removing layers of abstraction in order to uncover the set of tools which is a good balance for me. In example, replaced clojurescript with Javascript and then eventually Typescript. Replaced Clojure with Java. Replaced docker with VMs. Avoided ansible in favor of simple bash scripts. Avoid all kinds of firewalls in favor of understanding an…

Whilst I agree with most of this: > Replaced docker with VMs This doesn't make sense to me, as Docker and VMs are not the same thing. Replace LXC with VMs, sure.

You can build infra with cloud-init to achieve something similar. You start with base image (e.g. debian cloud-init image), you craft cloud-init script (like Dockerfile) and you end up with VM disk file which you can run.

It won't be better than docker, for sure, but if you're going to use VMs and stay sane, you'll need to reinvent it.

Re: We have used too many levels of abstractions

#173
One cause I've seen of this is the "college is not needed to be a coder" trend from the past few years (decade?). it is true that most of my skills were acquired after college, but there is some sort of global system understanding that you get from college (in my case computer+software+network engineering) where you can quickly narrow down potential sources of a problem, all the way down to say, the TCP/IP stack, CPU architecture, memory management, how some code might be optimized incorrectly by the compiler. It also helps a lot in asking the right questions. If all you know is [latest framework/language/tool], there is a whole world around this that can bite you when circumstances stop being perfect. One superpower is looking at a marketing page for a tool and knowing within seconds what it can't do and whether it would be a good fit for your use case, just by what is claimed on the page.

Regarding abstractions: I've sort of always ran away from languages that encourage it a lot. Java was one of them, where the entire OOP trend just fell flat to me even in college (I understood the benefits, but meh). The concept of dependency injection is another one, I think it was introduced in Javascript? Idk, I use it if the framework forces me to, but IMHO, it only makes sense when I'm the one building it. Define constructors that take interfaces and instantiate them explicitly with whatever implementations you want (ie. mocks vs real, etc). So that you understand everything that is happening.

My Biggest fear with frameworks (especially JS) is they are abstracted to such a level that I can't hope to fix an issue in a reasonable amount of time without begging for help in forums or github bc I don't understand even the concepts. What are effects? How does react work? How does Angular work? etc.

Re: We have used too many levels of abstractions

#174

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…

[flagged]

Re: We have used too many levels of abstractions

#175
There is no process that can prevent unknown failure modes.

Legacy software is almost always going to have issues, and some use complex frameworks knowing full well they have heavy maintenance burdens.

Saboteurs come from all skill levels and backgrounds. Integrating accountability in the development and deployment process is wise.

Most modern "Hackers" are just the sane old cons repurposing common auditing tools to check for known CVEs. Most others simply don't care about some obscure website.

When you catch unknown people poking hardware in COLO data centers... the real problems start to become apparent.

With enough coffee and doughnuts anything is possible. =)

Re: We have used too many levels of abstractions

#176
And nobody here knows how to raise a cow, milk it, and slaughter it. Neither can anyone make a fire in the rain, and god help us if the internet stops working. We’re so far from basic humaning that every generation needs to relearn how to change a baby.

Bleak stuff indeed.

Re: We have used too many levels of abstractions

#177

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…

> For them, spending a decade working with a low level programming language before you jump into high level programming language is simply not an option

As a counterpoint, I'd say that it's also chance to build on top of these abstractions without having your brain cluttered with how they're implemented. That's also how science grows.

And don't underestimate the new players. They're perfectly capable to understand the low level details if they have to, and they have much more resource available to learn too.

Re: We have used too many levels of abstractions

#178

Earlier quoted context omitted.

> ...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.

Thanks! That one frequently trips me up. If I think about it for a moment I know "his affect" is different than "the effect something has", but, as is sadly and normally the case, I power thru writing w/o thinking as much as I should.

Re: We have used too many levels of abstractions

#179

Earlier quoted context omitted.

Do you have any ressources to share ? I am a self taught developer, I do stuff at my level (typescript, lisp), also because when you work alone, such high level languages allow you to express things nicely and fast . I kinda know how a cpu works, I understand what is going on when you perform some bare metal programming, but I never barely went down the rabbit hole and performed some low level stuff. I'm in the situa…

I'm also self-taught. I've been doing it since (roughly) 2009, and like many others I started at the highest level of abstraction with front-end web dev. I've worked with some mid-level languages like Objective-C and Java, but like you I've never really dug deeper than that. I know this is tired and cliche at this point, but literally this week I sat down with ChatGPT and asked it to teach me how to write WAT (web as…

Very cool! Have you already taken the time to cross-examine the output to ensure it's hallucination-free?

Re: We have used too many levels of abstractions

#180
The problem is not only the level of abstractions but the cross dependencies and assumptions across abstractions. For example, in higher level frameworks (e.g. React) you should firmly follow the rules in a way that makes assembler a toy language comparing to the stuff you need to know ahead.

The security issues expand beyond what is described in the article: you assume the security is solved by a stack of layers where is not. A single issue impacts everything doesn't matter where in the stack it is.

Post reply on HN