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.
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…
We have used too many levels of abstractions
481–490 of 564 posts
Re: We have used too many levels of abstractions
#482Earlier quoted context omitted.
Having been working on writing documentation, tools and homebrew SDKs for arguably one of the most influential arcade systems ever made [1], I could not agree more with this. Hardware and software gets left behind by the original developers all the time, but that in no way makes it no longer relevant - and it certainly does not make the underlying concepts outdated. Z80 or 68000 assembly language might be completely…
> And yet most of my 19-year-old university classmates want to stay away from "scary" embedded or kernel work in favor of web or game development. It seems that with more abstraction, more people throw up their hands and say "I'll never understand it", "The designers of this system did things in the stupidest way possible", "It's magic" or (in the case of the financial system) "It's a rigged game" "You're working for…
Re: We have used too many levels of abstractions
#483As a systems administrator who has been doing this for a while, I can attest to this becoming more and more of a problem. I've worked with CUDA programmers who weren't aware of what "architecture" means in the context of computing until I asked them to consider running binary code meant for NVIDIA on AMD GPUs. I've worked with network administrators who couldn't conceive of the simple math behind something like singl…
> and just as in the audiophile world where there's a huge amount of money and energy spent to try to convince people that pricey bits are somehow better than cheap bits I always assumed this came down to the analog part (usually some sort of speaker) being better, and all the extras on the cords were really just there because a cheap looking cord would ruin the aesthetic they're going for.
For me it began when I looked at a friend's catalogue that had a $2,500 (25 years ago) CD player that claimed incredible fidelity in part because they bathed the underside of the disc with blue light while reading with a red laser, as though this somehow made reading the bits better.
I explained to my friend that barring scratches and speed fluctuations, bits are bits, and none of that matters one iota until you get to the digital to analogue stage.
My example was that you could write the data on strips of cloth from old pyjamas using free crayons that restaurants give to kids, put them in Dixie Cups and transport them across the Sahara on camelback, and so long as you reassemble them in the right order, the bits will be identical to the bits from a $2,500 CD player.
He's a brilliant guy, but it took him longer to understand what I was saying than I could've predicted. The whole thing - the scammy market, the FUD, the bullshit, the desire to believe - was and still is fascinating, albeit sad.
Someone somewhat recently did a review, if you can call it that, of "audiophile" ethernet switches. Yes, they want you to believe that the bits somehow are better if you send them using their special ethernet switches. Might be worth a quick search.
Re: We have used too many levels of abstractions
#484Earlier quoted context omitted.
"Who cares? " You are proving my point. You should care.
Why? I’d rather care about ML. My point is that your question is some esoteric gotcha party question that may as well be out of Trivial Pursuit. But you’re treating it like anyone who doesn’t care is just being a bad engineer. There are countless ways engineers spend their time, and choosing what to work on is the most important choice of their careers. It’s on you to justify the claim that knowing the difference bet…
Re: We have used too many levels of abstractions
#485Don't worry, old guys. The reason coders don't know all the low-level skills you've devoted your life to now is because they don't need them. If the future really becomes bleak, they'll start learning the skills they need.
Re: We have used too many levels of abstractions
#486Earlier 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"?
Re: We have used too many levels of abstractions
#487Re: We have used too many levels of abstractions
#488Earlier quoted context omitted.
The Co-pilot of Air France 447 could fit that description. He went to fly highly automated Airbus planes as soon as possible, which means only 250 hours on different types. He didn't had a proper understanding of how stalls worked, since Airbus automation makes it almost impossible to stall the plane, unless something goes horribly wrong and it reverts to manual law, which is what happened in that flight. When the ca…
Sure, but that was an exceptional situation, not some sort of systemic problem. It’s also relatively easy to guard against in future.
Re: We have used too many levels of abstractions
#489Earlier quoted context omitted.
I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?
I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required. To give you a rough sense: - My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining. - It's all declarative so for example, for the back end, I don't wr…
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/JSON or create a new abstraction in JS to use in the HTML.
disclaimer: I'm creating a "similar" platform and got curious by what would set your SDK apart from mainstream frameworks but I don't think what you described is anything different. For the view part, is it using something like htmx, react or pure JS?
Re: We have used too many levels of abstractions
#490Earlier quoted context omitted.
Questioning everything also gets you stuck in bed asking why the sky is a different shade of blue. Others might have accepted the unknown and ate breakfast.
Personally, I find pithy comebacks like this to sound convincing to but to actually be mostly devoid of utility. They tend operate as a sort of social persuasion tool, but I'd like to Get Things Done, which requires deep domain knowledge. One thing I've been noticing with my current clients is the vast amount of churn generated by them only having a patchwork understanding of their overall architecture. Some grok the…
So uh, not questioning everything eh...
Sounds like you agree with me. That questions should be reserved for the meaningful and insightful.