[dead]
We have used too many levels of abstractions
81–90 of 564 posts
Re: We have used too many levels of abstractions
#82Software's re-usability is both a blessing and a curse. Hardware also has modularity, but it is still common to build hardware from scratch. On the other hand, once a library or framework exists, many people no longer feel the need to understand the underlying algorithms. One side effect is that many of the frameworks or libraries still in use and that are important for the dependent software to work are written with…
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.
Re: We have used too many levels of abstractions
#83Earlier quoted context omitted.
There will always be hyper-nerds and just super smart people who will study all of the low level stuff. Granted, they will be vastly outnumbered by high level programmers.
That's what I mean by "precious few". I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up. Two decades ago that was common knowledge. It went away just as the knowledge of how networking works. Currently, if they try to open…
Unless they're working in that space they won't know it. And that's fine. There's enough to keep in our memory and tools and resources for us to look up information if we need it.
Re: We have used too many levels of abstractions
#84I 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…
I'd look at it in the opposite direction. Good abstractions are powerful when you understand what they build on. That recurses all the way down. Learning bottom up is a natural path, but there is still plenty of opportunity to explore top down. The difference is that top down discovery needs to be an intentional journey.
Re: We have used too many levels of abstractions
#85Earlier 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…
I've heard that advanced math has a similar problem, that some subjects are quite deep that only a handful of people really understand the topic and passing the knowledge down to younger mathematicians is not a given.
I guess in IT it's the other way around, where you can start with advanced abstractions and frameworks without bothering what kind of rabbit hole is underneath (at least while it's going smooth), it gets deeper as you go closer to the hardware. While in maths you need to understand the basics to even know what's going on with more advanced areas. And this already applies to the fundamentals too, where in school it's expected you understand the stuff from previous years. At least that's my impression as a non-mathematician.
And then there's the mix between the two in languages that rely heavily on powerful type systems.
Re: We have used too many levels of abstractions
#86I 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…
Yes. Anything that is destroyed during the process of compilation is not architecture. It is just a method of code organisation, and we've turned the subject into a holy war, pulling in mindshare that should be spent on more important problems (e.g. we have fibre lines and Ghz multi-core processors, but why are user interactions slower than they were in 1995?). 80% of code organisation problems require doing a couple…
I agree that is a large problem with industry.
Folks that have really strong opinions on issues of taste, but then they output apps that send a couple of thousand requests ( with several second latency ) are extremely difficult to reason with.
Re: We have used too many levels of abstractions
#87Earlier quoted context omitted.
> Software for dialysis machines A sizeable percentage of which is made without source control, unittests, and just slapped together like the rest you described Hospitals don't check software quality when making purchasing decisions (much beyond "this button doesn't work")
> Hospitals don't check software quality when making purchasing decisions (much beyond "this button doesn't work") This! The worst piece of low quality garbage I've seen from the inside is hospital software. Nobody really cares or understands software on the hospital side, so anything goes. The product is inherently complex, so there are only a small number of large companies who don't care either since they can rely…
A good book on the subject
"Fix IT: See and solve the problems of digital healthcare"
https://www.waterstones.com/book/fix-it/harold-thimbleby/978...
Re: We have used too many levels of abstractions
#88> A big percentage of so-called experts today only know how to configure some kind of hype-tool, but they understand nothing about how things work at the deeper level.
This resonates with me strongly. Everyone seems to know how to do things by rote memorization ("to do X, add this line to your config file") but nobody knows how to go off-script if you need to do something slightly different (not-quite-X or a variation on X). Worse, people will waste your time trying to steer the conversation away from not-quite-X back to X. (Insert the parable of the man searching for his lost wallet under a streetlight because that's where the lighting is best.)
Re: We have used too many levels of abstractions
#89The author's "Advice to people studying technology" goes against the dominant practices for individuals making money in software right now.
This is sometimes a misalignment with organizations, though other times a company is playing games (e.g., priority is to appear externally as having growth or progress).
Re: We have used too many levels of abstractions
#90Earlier quoted context omitted.
That's what I mean by "precious few". I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up. Two decades ago that was common knowledge. It went away just as the knowledge of how networking works. Currently, if they try to open…
How often does a front-end developer need to know about /proc/pid/mem? I think it's important to keep things in perspective here - when I took my first programming job the first week was setup. On my team, our onboarding has you branch, review and merge on your first day. Those abstractions allow for people to focus on the areas they're working on, and iterate there. A game developer doesn't need to understand the co…
"How often does a front-end developer need to know about /proc/pid/mem?"
It's not about any particular detail, obviously.
He himself does not ever have had to previously see /proc/pid/mem before in his life in order to solve a problem involving it.
However many times a day he gets a question of any kind, that's how often.