We have used too many levels of abstractions • Hacker News Board

Re: We have used too many levels of abstractions

#131

Post by danielvaughn » Sat, Oct 21, 2023, 11:45 AM UTC

arnaudvalette wrote: post #115

enriquto wrote: post #47

Earlier quoted context omitted.

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

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 assembly text format) so I could understand how memory is managed at a really low level (but not so low that I risk crashing my computer).

It turned out to be super valuable. This is where AI shines for me - I can ask it any question that pops into my head, and also validate whether what it's telling me is true by running the code and seeing whether it works. It was amazing.

If you're curious, I'm fine sharing a link to the chat:

https://chat.openai.com/share/583bf23b-b43d-4566-956a-e92b6f...

Re: We have used too many levels of abstractions

#132

Post by jsenn » Sat, Oct 21, 2023, 11:49 AM UTC

okaleniuk wrote: post #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…

This is a useful insight, but I think that many automations really are based on solid, honest-to-goodness abstractions of the same type you would find in math. Furthermore, that's good and important!

It's true that a compiler is merely translating a high-level language into the actual machine code, but it's simultaneously true that you can (generally) talk sensibly about the high-level language, and maybe even prove theorems about it, without making any reference to how it will be realized on the machine. That's a good abstraction.

The better your abstractions, the more your automations make sense, and the more you can reason about them. Automation without abstraction gives you biology, which is a gnarly mess of accidental complexity that's very difficult to reason about and control.

That said, I'm going to start thinking of my code more in terms of creating efficient and low-risk automation, and less about creating nice abstractions.

Re: We have used too many levels of abstractions

#133

Post by criddell » Sat, Oct 21, 2023, 11:51 AM UTC

arnaudvalette wrote: post #115

enriquto wrote: post #47

Earlier quoted context omitted.

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

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…

For very foundational stuff, Charles Petzold has put out some great books.

His book Code is fantastic. He starts at simple battery and lightbulb circuits and builds and builds towards a simple CPU.

He also wrote The Annotated Turing which is a breakdown of Alan Turing seminal paper and you only need high school math to get through it.

When I was in school my favorite course was compiler design and we used Compilers: Principles, Techniques, and Tools (aka the dragon book). It’s one of the best textbooks I’ve used but that was 30 years ago. There might be something better now. Understanding parsers and lexers and (especially) state machines is something that will serve you well.

Re: We have used too many levels of abstractions

#134

Post by eddyg » Sat, Oct 21, 2023, 11:52 AM UTC

onetimeuse92304 wrote: post #12

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…

Agreed!

It reminds me of:

https://github.com/alex/what-happens-when

and how many of today’s CS-degree holders would barely understand any of it. As someone who has also “grown up with all the technology”, I’ve learned and experienced all that. But as a percentage of “software engineers”, there’s fewer and fewer that do every day.

Re: We have used too many levels of abstractions

#135

Post by skupig » Sat, Oct 21, 2023, 11:54 AM UTC

okaleniuk wrote: post #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…

Those terms go hand-in-hand. Like a compiler, abstraction in art is essentially delegating some of the work to the audience.

Re: We have used too many levels of abstractions

#136

Post by danielvaughn » Sat, Oct 21, 2023, 11:55 AM UTC

criddell wrote: post #133

arnaudvalette wrote: post #115

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…

For very foundational stuff, Charles Petzold has put out some great books. His book Code is fantastic. He starts at simple battery and lightbulb circuits and builds and builds towards a simple CPU. He also wrote The Annotated Turing which is a breakdown of Alan Turing seminal paper and you only need high school math to get through it. When I was in school my favorite course was compiler design and we used Compilers:…

Code is an awesome book. Those first few chapters were nothing but lightbulb moments for me (pun intended).

Re: We have used too many levels of abstractions

#137

Post by ahoka » Sat, Oct 21, 2023, 11:57 AM UTC

otteromkram wrote: post #125

okaleniuk wrote: post #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…

I disagree and believe "abstraction" is the correct term for wgat the author intended. > Computer science commonly presents levels (or, less commonly, layers) of abstraction, wherein each level represents a different model of the same information and processes, but with varying amounts of detail. See: https://en.m.wikipedia.org/wiki/Abstraction_(computer_scienc...

I think it’s very common for developers to mistake indirection for abstraction.

Re: We have used too many levels of abstractions

#138

Post by jtode » Sat, Oct 21, 2023, 11:58 AM UTC

Ludicrous abstraction story.

I was once managing a few large file servers, with bog standard users as well as devs using a pretty complex directory tree of "assets".

There was a pretty high-up, specific directory level, which was where the ZFS file servers were given their different loads to handle. This was a directory level where new directories were created rarely (99% at the start of the project).

For reasons of money as well as speed, I asked that the server admins (ie. me) be the ones to create any further directories needed at that particular level. The head dev refused to entertain the idea of not being able to create directories anywhere he wanted at any time, and therefore, a new system was brought in at five-figure costs in order to make the file servers into a large abstracted blob that users never had to think about the complexities of managing.

I was given an opportunity to exit the IT dept and become a Python dev and I took it, shortly before that system came in, because it caused many problems which were much worse than needing to have an admin create a directory for you maybe once or twice, and the evident ignorance of everyone I spoke to at the vendor made it very clear ahead of time that it would.

This was not the only such massive expenditure on a toxic boondoggle in the name of "simplicity" that I witnessed.

Re: We have used too many levels of abstractions

#139

Post by donatj » Sat, Oct 21, 2023, 11:58 AM UTC

> 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 higher speed than you otherwise would have because your ability to actually slow down is greatly diminished. It’s a trade of braking distance for control. Basically we’re prioritizing rapidly swerving around an obstacle over less controlled but far more rapid deceleration.

I really don’t think this trade off makes any sort of sense in anything but the most sparse rural environment. In urban and suburban areas, swerving blindly around an obstacle will just mean hitting something else. Yes, you missed the car that pulled out in front of you but now you’re either throwing your vehicle into pedestrians on the sidewalk or into oncoming traffic. Both cases likely a far worse outcome than the accident you are taking evasive actions to prevent. The sanest option becomes just to hit the obstacle you would have been able to stop for were it not for antilock brakes.

In my eyes, the most fundamentally frustrating part, and what makes them a bad abstraction, is that the problems antilock brakes solve are entirely preventable by human intervention. Namely, pumping the brakes. The class of accidents antilock brakes cause are largely unavoidable. You can stop lessen their affect by not fully depressing the brake but it is still a much longer deceleration than no antilock brakes at all.

Re: We have used too many levels of abstractions

#140

Post by ixaxaar » Sat, Oct 21, 2023, 12:00 PM UTC

onetimeuse92304 wrote: post #12

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…

Hey I've struggled with this notion as well. But then I sometimes compare this with crypto - or how a bunch of kids simulated the entire financial system and made the same mistakes made 100s of years ago, with the end effect of an new generation that taught itself finance.

I suppose that is what will keep happening. At some point, someone will decide to re-write everything from scratch and re-discover lower layers of abstraction or challenge them.