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

Re: We have used too many levels of abstractions

#451

Post by okaleniuk » Sat, Oct 21, 2023, 5:48 PM UTC

skupig wrote: post #135

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.

Don't get me started on compilers. Compilers don't compile. Linkers compile. Compilers should have been called translators from the start.

Re: We have used too many levels of abstractions

#452

Post by rewmie » Sat, Oct 21, 2023, 5:53 PM UTC

austin-cheney wrote: post #285

stakhanov wrote: post #191

Earlier quoted context omitted.

The problem is that it takes a really long time until technology is so good and so reliable that you really don't need to understand it to be able to operate it. Take, for instance, the "Yes, let's all go back to coding in assembly!" line -- The thing is: For a really really long time after high-level languages had become mainstream, you really did still have to know assembly to be a programmer, even if you did most…

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

> Most are overpaid API monkeys.

I think that's a highly dismissive and ignorant view of what software development, as a value-creation endeavor, actually is.

The responsibility of a software engineer is not mapping high-level constructs to low-level details. The responsibility of a software development engineer is to implement systems that meets the business requirements, and operate on those systems at the abstraction level that makes sense to the problem domain.

It is entirely irrelevant what machine code is running, or even what machine is running the code, just like being able to model fluid flow over the control surfaces of an airplane is entirely irrelevant to steer the plane. A pilot needs to know how to control the plane using the plane's interfaces. Being able to whip out a computational fluid dynamics model is entirely irrelevant for a pilot if all they want to do is turn left/right.

High-level languages and abstraction layers are the key to simplify and speed up delivering value. No one should care about what pages of virtual memory their application is writing to if their goal is to serve a webpage in multiple continents.

Re: We have used too many levels of abstractions

#453

Post by okaleniuk » Sat, Oct 21, 2023, 5:54 PM 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 don't challenge the author's use of the word "abstraction", I challenge the validity of the very word "abstraction" in the context of computer science. What we're dealing here is not abstraction, it is something else. But thinking of is as of abstraction brings us to the state of affairs the author criticises.

If you remember that there is very specific very concrete automation behind every abstraction, you don't stack them up until the pile becomes impossible to either control or understand.

Re: We have used too many levels of abstractions

#454

Post by anonzzzies » Sat, Oct 21, 2023, 5:56 PM UTC

YoshiRulz wrote: post #403

anonzzzies wrote: post #378

The future looks especially bleak because LLMs, for many who I work with, are doing with logic what Google did with memory. 'Just ask chatgpt' will be a thing ; maybe not chatgpt, probably indeed just google but with a their chatbot which can do 'logic' and abstractions built in. Google -> you don't need a longterm memory, just Google it. So with good LLMs (and the latest iteration of chatgpt is really good at a lot…

While I agree with you that programmers increasingly relying on LLMs would be (is?) a problem, there is an element of neo-Luddism to this, as was excellently framed by xkcd[1] some years ago. Could we not choose to fill all that time we used to spend writing code on testing/verification instead? Or on performance, or documentation, or security? Or, to go back to the premise of the blog, on re-educating ourselves in t…

But I think it will eventually end up in having less understanding of what people are doing, which won’t help us.

And I don’t think we will become mindless code monkeys: I think we will end up telling the computer what we need in english but us having 0 clue or memory on how it achieves that. That’s the ultimate ‘too abstract’ issue.

Re: We have used too many levels of abstractions

#455

Post by steveBK123 » Sat, Oct 21, 2023, 5:58 PM UTC

sgarland wrote: post #355

steveBK123 wrote: post #312

Earlier quoted context omitted.

Agree that devs not needing to know this is how things should be, and that CTO/tech management however is not acting this way. It is basically idiotic to me, as a highly paid senior application dev.. that they basically want me to spend any cycles on stuff that would ordinarily be done by someone making 1/5th my TC. If I can do it more than 5x as fast/efficiently, sure, but I don't. IaC is something I worry about at…

> stuff that would ordinarily be done by someone making 1/5th my TC Did you mean for this to be condescending towards ops? Because that’s how it sounds. Ops is not easy, at all. Even if you’re doing zero IaC, I defy the average dev to try to provision a Linux box from scratch and install, configure, tune, and maintain the stack you need to run your code. Throw IaC atop that, and now you need to understand declarative…

I do not mean to be condescending. I am being literal. Every job is hard, and the pay is not exactly commensurate with effort.

Ops is absolutely hard and theres a lot to learn. And in doing so you generally may end up with DevOps teams with minimal to zero domain knowledge in what the company delivers to end users.

So if you have a team of people who built a deep level of expertise in something over 10, 15, 20 years and that something is business facing, domain knowledge, etc.. then it is not of value to have their time spent on other tasks.

Often these DevOps roles are filled by more junior staff at the earlier stages of their career. This is another reason the staffing is usually lower cost.

Re: We have used too many levels of abstractions

#456

Post by BHSPitMonkey » Sat, Oct 21, 2023, 6:00 PM UTC

austin-cheney wrote: post #285

stakhanov wrote: post #191

Earlier quoted context omitted.

The problem is that it takes a really long time until technology is so good and so reliable that you really don't need to understand it to be able to operate it. Take, for instance, the "Yes, let's all go back to coding in assembly!" line -- The thing is: For a really really long time after high-level languages had become mainstream, you really did still have to know assembly to be a programmer, even if you did most…

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

There's a limit to how much about a plane the pilot understands (e.g. how much about the electronics, circuitry, software in the cockpit is understood? what about the chemical composition or manufacturing process behind the rubber in the tires? or the subatomic physics that helps explain why air and the plane interact they way they are known to in aviation?). I don't disagree that poor practitioners exist in every field, but that's a sign of what the technology permits you to get away with not knowing.

Re: We have used too many levels of abstractions

#457

Post by jen20 » Sat, Oct 21, 2023, 6:00 PM UTC

palata wrote: post #412

austin-cheney wrote: post #285

Earlier quoted context omitted.

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

Tell that to the passengers of those 737 MAX flights where the pilots did not know how to disable the failing AoA correction... I wouldn't bet that most pilots know more about how the planes they fly work than software devs know about their computers. For one, most planes today rely heavily on computers. Do they teach electronics in "aviation"?

As I understand it, the 737 MAX issue was not because the pilots didn't know how their plane worked, but because they were lied to about a feature that was installed to try to reduce costs. Had they been told it was there, no the outcomes could well have been different.

Re: We have used too many levels of abstractions

#458

Post by steveBK123 » Sat, Oct 21, 2023, 6:01 PM UTC

hibbleippo wrote: post #390

steveBK123 wrote: post #312

Earlier quoted context omitted.

Agree that devs not needing to know this is how things should be, and that CTO/tech management however is not acting this way. It is basically idiotic to me, as a highly paid senior application dev.. that they basically want me to spend any cycles on stuff that would ordinarily be done by someone making 1/5th my TC. If I can do it more than 5x as fast/efficiently, sure, but I don't. IaC is something I worry about at…

Staff SRE here: I comfortably exceed your TC by a factor likely approaching 2.0 doing harder shit than your whole team combined. That’s nothing against you, only that you don’t really know what you’re talking about here. I can safely conclude that because 20% of your app dev TC is not in any ops in the US, particularly not DevOps-school, not even “legacy-style” SA; hospital SA, for example, used to be a high six-figu…

It may be true your TC is so high, and I salute is so. Clearly my tone implied a level of looking down my nose I didn't intend.

Now take all the stuff you are an expert at, and imagine the CTO assigned to you - build dashboards of accounting information. You don't do UI, and you don't know accounting (maybe YOU do, but your average SRE/DevOps do not).

It wouldn't make sense right? And a lot of those tasks can be done by a junior "data analyst / BI dev". So it would be an expensive mistake as well.

This is my point.

Re: We have used too many levels of abstractions

#459

Post by frank_nitti » Sat, Oct 21, 2023, 6:03 PM UTC

sholladay wrote: post #415

So is the argument that everyone should be a mechanic? Including the long haul truckers, the race car drivers, stunt people, taxi drivers, etc? Such people use their vehicles professionally, full time. Obviously technical knowledge is useful to them in case of a problem or to fine tune their vehicle. But in general, no, being able to steer without a steering wheel doesn’t really do much for them. It’s okay to special…

That is a good point. What I take from the article as valid is the value of an engineer’s general attitude toward these matters.

Having worked with a fair amount of devs who are very clever, but instead of having a sense of wonder and curiosity about the tech their systems rely on, they show a disdain for it. The kinds of fixes I’ve seen almost go into prod are scary, e.g. “the packaging system will not pack this 3rd party exe in with our code, so I’ll rename it to txt” - anything to avoid understanding the lower level mechanism and devise a sane solution. And management is thrilled because they deliver on schedule; engineers who protest the “working” approach are, at best, placated with a tech debt story in the backlog.

Your comment and many others here start their criticism by conflating builders with end users - does every taxi driver need to be a mechanic? This comes off as a bit of a strawman since the author is referring to building software, not simply consuming it. If the person who designed my car is just selecting prefab components on the strength of blog posts and industry hype, with weak knowledge of how they are built, I’d be worried.

Re: We have used too many levels of abstractions

#460

Post by dihrbtk » Sat, Oct 21, 2023, 6:18 PM UTC

graypegg wrote: post #262

Kids today don't get enough credit. A friend's son was so excited to show off the Roblox game him and his friends were making a couple of weeks ago. Was there for (Canadian) thanksgiving so there was some family friends and tons of people from his family there. He had already picked out something he thought each of us would be interested about it, and I was the "show him the Lua!" guy! People assume that because thei…

I think game-making is an underrated point of entry into programming and software development in general. It worked for me!