Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

521–530 of 564 posts

Re: We have used too many levels of abstractions

#521
post #512

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.

Ask a pilot to recite Navier-Stokes from memory. They won't even know what you're talking about. Building a gas turbine engine without training? Forget it. The only electrical engineering a pilot needs to know is the difference between volts and amps, and what it means when a breaker pops. The EEs who design the avionics are not so fortunate.

Nobody is talking about building the engine lol, you're all making the exact "just program everything in assembly" comment the author was taking the piss out of.

You have probably 80% of people using React that have absolutely no idea how the three main functions in it's API work. That's the equivalent of a 747 captain having no idea what the TOGA button does and only knowing that that's the one you press to do a take off or a go around.

Re: We have used too many levels of abstractions

#522

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…

If you do something even slightly unusual you can quickly get into a situation where you spend more time debugging your toolchain than writing code. I really hate the state of modern software. We have so many layers of utterly unknowable abstractions that it isn't even possible to understand what your code actually ends up doing. And that's how we ended up with Electron, which I think is the pinnacle of shitty softwa…

[deleted]

Re: We have used too many levels of abstractions

#523

Earlier quoted context omitted.

I’ve seen decades old Fortran codebases that everyone is too scared to touch. So instead all the new ‘features’ marketed to clients are just window dressing around the existing Fortran core.

Side question: what kinds of codebases were those? What products were built on top of decades-old Fortran code? I'm curious.

Engineering simulation software. So being hesitant to change code is probably fair, in case you introduce new bugs. However that view ties your hands when improving the software and at some point becomes counter-productive.

Re: We have used too many levels of abstractions

#524

There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…

"One day the stars will be as familiar to each man as the landmarks, the curves, and the hills on the road that leads to his door, and one day this will be an airborne life. But by then men will have forgotten how to fly; they will be passengers on machines whose conductors are carefully promoted to a familiarity with labelled buttons, and in whose minds knowledge of the sky and the wind and the way of weather will be extraneous as passing fiction." -- Beryl Markham, West with the Night, 1942 (first person to solo the Atlantic east to west)

Re: We have used too many levels of abstractions

#525
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…

> These are trivial to achieve at substantially lower effort without the frameworks, but it requires a more experienced or better trained developer.

Say more? What do you see as the trivial non-framework path (choose any example problem you like)?

Re: We have used too many levels of abstractions

#526

Earlier quoted context omitted.

While I also attended college, I sometimes wonder if a college degree is really needed to learn these general stuffs. I learn a lot while doing projects completely unrelated to schoolwork, before registering for the course. I still have to register for the course because of graduation requirements, but I just skipped all the lectures and only took the exams. There are nice materials and textbooks available, and I thi…

I think it's dangerous to think in this way: I succeeded without college, so everyone can, so college should be abolished. Not everyone has the discipline to self learn through a course. Not every one knows how to properly and effectively absorb and retain knowledge, and not everyone knows how to make that knowledge useful. What college does is provide structure and a favorable environment for learning where you're a…

Yeah I don't think college should be abolished, I just think that college should adapt to this trend of online education, instead of just acting like 100 years ago where there is no internet. And they should probably try to make better use of online education materials instead of offering their own courses that are worse...

Re: We have used too many levels of abstractions

#527
post #245

Old man yelling at cloud vibes. Yes some people are experts and some are just adequate. Nothing new here. Not everyone can be a messiah like the author, who spends half of this short essay telling us how great he is. This article has almost nothing to do with abstraction. The author loses interest in his own thesis after the first two paragraphs.

Same feeling. How this article came up to the top? The example he gives is terrible "someone used a modern framework was hacked, but the performance was not caused by the hacking, but the frameworks was terrible slow" - Ok, which was the framework? How did you find it was slow just by looking at a diffs? What someone not knowing how to trim a tool for performance has to do with abstractions?

That exactly at that hacked framework example that I closed the tab.

Re: We have used too many levels of abstractions

#528
The author claiming that no single person can master development and ops and security is missing the point. By abstracting over some of the details of all of those fields, someone can be proficient in all of them, and therefore gain the perspective that comes from bridging those three separate but aligned skillsets.

We haven't used _too many_ abstractions. We've merely leveraged abstractions in a way that makes a different tradeoff. A small number of abstractions trades off deep expertise for narrow perspective. A larger number of abstractions allows us to trade off a wider perspective for a shallower understanding.

Neither is wrong. Both are useful. Different situations will call for each.

Re: We have used too many levels of abstractions

#529

Earlier quoted context omitted.

> I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code. I think you are missing the point of no-code. Your solution isn't even low-code, you just created a framework with well-thought components to start a project. If you need to integrate a third-party component that uses code, you'll need to integrate that code in your HTML/JS…

It's definitely no code. I built some dynamic pages of my service to manage data with it that are all HTML markup and JSON. I would have used it for all pages if I had created the components earlier. HTML is markup, not code. JSON is object notation, not code. I used very little code to build my service. I think this type of highly flexible low-code is the right path to no-code. I know from experience that people wit…

> HTML is markup, not code. JSON is object notation, not code.

They most definitely are code. They are not programming languages, and writing them is not 'programming', but they are still code.

Re: We have used too many levels of abstractions

#530

Earlier quoted context omitted.

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

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.
Post reply on HN