Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

Post reply on HN
Print view View original

541–550 of 564 posts

Re: We have used too many levels of abstractions

#541

Post by austin-cheney »

BHSPitMonkey wrote: post #530
sergiogjr wrote: post #481

Earlier quoted context omitted.

I think we have to make a discernment between operating and manufacturing when referring to knowing "how it works". The pilot needs to understand how a plane will behave on the fundamental level when given a set of instructions. A develop should have that understanding as well (and that's coming from a person who's been through CS, but have lost a lot of that understanding).

But what the vast majority of programmers are "operating" are programming languages, runtime environments, and operating systems—which generally treat the hardware and the CPU architecture as implementation details. The people who use programming languages and those who create/maintain them might as well be in different industries, like the pilot and the aerospace engineer.

I think that misses the point. A programmer who understands both their language and the environmental constraints with which that language, and it’s capabilities, execute likely understands enough to write and maintain original applications in that language.

As a JavaScript/Web/Fullstack developer I don’t live in that world. I live in a world of giant stupid frameworks. The only purpose of these frameworks is to supply an architecture in a box and put text on screen in a web browser. If a task cannot be performed using only the API provided by that framework then it must not be worth doing as it’s clearly far beyond the capabilities of the developer. There is far more to this software platform than merely putting text on screen in a web browser, for example: accessibility, security, performance, test automation, A/B testing, network messaging, architecture, content management, and so on.

God forbid you take the giant stupid frameworks away. It’s like castrating a person in public and then laughing at their great embarrassment. Many developers, some of whom shouldn’t be in this line of work to begin with, have built their entire careers around some framework API and absolutely cannot write code without it. The emotional insecurity is very real, as well as the completely inability to write original applications.

Re: We have used too many levels of abstractions

#542

Post by rewmie »

austin-cheney wrote: post #504
rewmie wrote: post #497

Earlier quoted context omitted.

> Unnecessary abstractions exist not to simplify any return on investment but to ease candidate selection from amongst a pool of otherwise unqualified or incapable candidates. This take is outright wrong. One of the most basic business requirements is turnaround time for features, bugfixes, and overall maintenance, which ultimately means minimize operational costs. All production-ready application frameworks are desi…

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…

> At least in JavaScript land all production ready frameworks only solve two problems: architecture in a box and put text on screen.

I don't think you have a very good grasp on the issue.

All production-ready application frameworks are designed to provide standardized application structures out-of-the-box that hide the implementation details that don't change and make it trivial to customize the parts that change more often.

That's what they are used for: to ensure developers do not have to reinvent the wheel poorly, and to provide very flexible ways to change the things that are expected to change the most often.

Front-end frameworks are used to help develop user interfaces. Describing user interfaces as "put text on screen" already shows you have a very poor grasp on the subject and are oblivious to fundamental requirements.

Unwittingly, you're demonstrating one of the key aspects where frameworks create value: gather requirements and implement key features that meet them, so that people like you and me who are oblivious to them don't need to rearchitect their ad-hoc frameworks to support them as an afterthought.

It should be noted that those who try to make the same accusations you've made regarding complexity aren't really complaining about complexity. Instead, they are just manifesting that they are oblivious to key requirements and as they are oblivious to them then they believe they can just leave huge gaps in basic features without any consequence.

Re: We have used too many levels of abstractions

#543

Post by austin-cheney »

rewmie wrote: post #542
austin-cheney wrote: post #504

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…

> At least in JavaScript land all production ready frameworks only solve two problems: architecture in a box and put text on screen. I don't think you have a very good grasp on the issue. All production-ready application frameworks are designed to provide standardized application structures out-of-the-box that hide the implementation details that don't change and make it trivial to customize the parts that change mor…

Strange. You are almost verbatim repeating what I wrote, expanding upon it, and then elaborating upon your expansion to justify the same conclusion that I wrote in about 4 words. To me this sounds like virtue signaling.

https://en.m.wikipedia.org/wiki/Virtue_signalling

These frameworks provide value to the employer, not the developers, because it eases candidate selection and turns otherwise unqualified developers into less capable commodities. In that regard the value is entirely regressive because it requires more of the less capable people to perform equivalent work that does not achieve disproportionate scale, which is the economic goal of automation. If the given developers only return value directly proportional to their manual efforts they are merely overpaid configuration experts on top of data entry.

Re: We have used too many levels of abstractions

#544

Post by palata »

numpad0 wrote: post #515
palata wrote: 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.

I know. My original point was that it is not completely clear that pilots know better how planes work than software engineers know how computers work.

Not at all saying that they were incompetent. On the contrary, passenger planes today are IMO much more complex than one desktop computer loading a web page: passenger planes are a group of many computers doing safety-critical stuff in order to maintain a giant machine up in the air.

I don't see how one can say that software engineers don't really understand computers, but pilots do really understand planes.

Re: We have used too many levels of abstractions

#545

Post by palata »

jemmyw wrote: post #486
palata wrote: post #412

Earlier quoted context omitted.

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"?

If I recall correctly, the crew of the Ethiopian flight that crashed were very experienced and they did understand what was happening. They just couldn't mitigate it in the short time they had.

Note that my point was not that the crew was inexperienced or incompetent. My point was that those flying machines are crazy complex, and actually made of tons of safety-critical computers.

I just did not find it fair to say "pilots know how planes really work, but software engineers don't know how computers really work". Both are waaaay too complex for one person to actually understand fully.

Re: We have used too many levels of abstractions

#546

Post by rldjbpin »

i see many comments disregarding the take. while the arguments put forth may not be the strongest, but there is a point to this.

most people only chase the next thing you can build on top of what we have today. they only look back inside the layers when the current tech is not enough to achieve your goals out of the box.

a recent example i see is with the quantization and tinyml developments in machine learning. while it is easier than ever to create a model and to run it, the underlying architecture, previously only up to the people designing the frameworks, is now finally being looked at. only because the LLMs cannot fit inside the memory of elusive enterprise GPUs as easily as you'd like.

in no other instance would most people care about how numbers are stored in memory in the past 15-20 years in writing software. i think necessity is mother of invention, and that would probably still apply to dealing with abstractions going forward.

Re: We have used too many levels of abstractions

#547

Post by BiteCode_dev »

meiraleal wrote: post #338
BiteCode_dev wrote: post #109

Earlier quoted context omitted.

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 l…

> 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. I agree with you but HTMX? That's a big abstraction layer. A good one but still, not really a way to avoid layers of abstraction. Pure JS makes more sen…

There are already plenty of good resources for pure JS, I have no added value here.

Re: We have used too many levels of abstractions

#548

Post by BiteCode_dev »

emptysongglass wrote: post #337
BiteCode_dev wrote: post #109

Earlier quoted context omitted.

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 l…

Your articles are so helpful: great Python guidance and now HTMX? What's next, React frameworks? ;)

I can last years with only Python, so those little detours won't expend as far as React.

It's more likely that I will do something like "a full web app from installing the OS on a fresh laptop to coding it to hosting it on server".

It would also be more beneficial: plenty of tutorials for individual techs, rarely they teach you how to integrate them together and go beyond the toy example on localhost.

But for that I need a better platform than substack. Therefore that's not going to happen anytime soon.

Re: We have used too many levels of abstractions

#549

Post by tight-ship »

onetimeuse92304 wrote: post #533
tight-ship wrote: post #330

Earlier quoted context omitted.

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

May I quote?

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

Thus one has to conclude that young people, not having perseverance, do not really understand technology (and lacking such basic skill, never will).

Re: We have used too many levels of abstractions

#550

Post by patrick451 »

hliyan wrote: post #48

In other words, cargo cult programming. I wrote about this two years ago [1] and received only polarised responses that either agreed with the point wholeheartedly, or attacked me viciously for gatekeeping. I wish there was a better way to cure this disease without triggering the professional immune systems of engineers who are highly vested in their favourite technologies. [1] https://medium.com/the-engineering-mana…

This idea of gatekeeping is so cancerous. Nearly every time I see that accusation deployed, there is an implicit assumption that gatekeeping is obviously bad. It's just used as a trump, "you are gatekeeping, so I win". I think this is a ridiculous idea. There's nothing wrong with advocating for a high bar of professionalism, which is essentially what gatekeeping is. I'm very glad that medicine is a gatekept profession when I visit my doctor.
Post reply on HN