Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

411–420 of 564 posts

Re: We have used too many levels of abstractions

#411

Earlier quoted context omitted.

There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields. I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention". I'd love to hear from somebody with experience in scientific or other disciplines and IT who could contrast their fields with ours. I only know that I have had…

>as a result, we've had unbelievable amounts of "wheel reinvention". During the crypto boom I distinctly remember hearing someone say something about creating a decentralized Discord. I was like... that's IRC.

I wouldn't call IRC decentralized, but yeah, all the new messaging systems like Slack/Discord are basically proprietary versions of IRC with only one (shitty ElectronJS) desktop client.

Re: We have used too many levels of abstractions

#412

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.

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

Re: We have used too many levels of abstractions

#413
post #120

Earlier quoted context omitted.

>You can actually see this with new frontend devs. They know only full SPA frameworks, ...... Around I guess 2017 or even 2016? I used to think this is some sort internet troll comment about people never seen a dump of an HTTP message, until...... >Because they started with assembly. It wasn't necessary starting with assembly or something low level. ( Although that certainly helped ) We have less entertainment, more…

Having to figure it out is not specific to a generation. My generation had magazines and forums. Then came out google and SO. Now chat gpt. The difference is where you start figuring things out. Before, you needed to figure things out at your level, because it was the immediate area of mystery. Now this level is generally solved, you need to figure things out at a different level: - filter out the mass of irrelevant…

Judging solely by the date of publication is not the best criteria for filtering. For example, Vannevar Bush's article "As We May Think", published in 1945, is the oldest dated item in my reference library. Conway's Law comes from Melvin Conway's 1968 paper. David Parnas' 1972 paper "On the Criteria To Be Used in Decomposing Systems into Modules" still applies.

Re: We have used too many levels of abstractions

#414

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…

[deleted]

Re: We have used too many levels of abstractions

#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 specialize at the higher layers of the stack.

Programming is more like building with legos than building or using a car. So much of programming is composing units of work, even if you are starting at a low level of abstraction. And those units are very generic, very reusable, with little need for each unit to know about the goals of the end result until you get very high in the stack. In other words, we specifically avoid using specialized parts unless it becomes necessary.

I would wager that >90% of the useful, beautiful, functional software that I enjoy using every day was written by people who don’t know how to write assembly. Whether you measure it by lines of code, work hours, whatever. And that’s okay. They had time to add features and work on their business model rather than having another go at correctly loading their data into the CPU registers.

Re: We have used too many levels of abstractions

#416

Earlier quoted context omitted.

Do you know that antilock brakes slow down you faster comparing to car with locked wheels?

I think the point was that anti-lock brakes remove options and make things less safe in certain (not very uncommon) instances. With anti-lock brakes, you're protected if you've never learned anything and you just try to put the brake pedal to the floor. If you know how brakes work, you're worse off than if you don't have anti-lock brakes, since you can no longer properly control your brakes. In other words, we're pun…

> With anti-lock brakes, you're protected if you've never learned anything and you just try to put the brake pedal to the floor.

That sounds nice on paper, but in reality you need training in order to overcome the instinct to smash the pedal through the floor... and you need regular practice to avoid reverting to instinct. Needless to say very few people can _actually_ take advantage of manually controlling the brakes.

Re: We have used too many levels of abstractions

#417

As a 15+ years webdev my recent projects in the front-end are almost pure "vanilla JS" (Just JS) + Html, and CSS with only Petite Vue / Alpine on top. I find the modern Vue, React etc. stacks absolutely insufferably complex and prone to breaking in 1000 places each time you upgrade some package, or change som random thing in the already stupidly complex "Tooling/Build" chains people are setting up by default. And it'…

[deleted]

Re: We have used too many levels of abstractions

#418
post #22

I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'. Programmers too often add indirections which don't provide abstraction: * The programmer wants to POST an object to a web server. * The programmer also wants to think about it at the level of POSTing an object to a web server. * And yet the programmer creates an HttpClient.java and an AbstractClient…

[deleted]

Re: We have used too many levels of abstractions

#419

“Everything in the tech industry is driven with a very hardcore eye for profit and very little interest in anything else” What is up with the discourse lately - of course it’s all about the profits - we’re talking about companies right not non-profits? How else are they going to pay you? The whole “expecting companies to care about so many things” apart from profit seeking mindset is just bizarre to me

[deleted]

Re: We have used too many levels of abstractions

#420

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…

[deleted]
Post reply on HN