Gregory's Server@Natanox @lorq @blacklight I think it is due to the abstraction of technology. As products and services lower the barrier to using tech they usually remove the need to learn the underlying fundamentals. So more people use the tech but less understand how it actually works. Itβs both good and bad.
|
28 comments
@blacklight @cybeej @Natanox I think it's a combination of the evolution of education (Pro Tip: Education is NOT permanent from generation to generation and we need to remember that as a society.) and lower barriers of access to many technologies all at once. And one of the fundamental "learning to code" problems professionals face in teaching coding is that those abstractions get in the way of learning some of those fundamentals. @blacklight @cybeej @Natanox I learned TinyBasic and TinyPascal and TinyFortan and TinyCobol and TinyAssembler around the age of 10 or 11. Then I learned more of the full-blown languages again in college. My personal angle on the "learning to code" problem is that; A.) Not everyone is meant to be a deep thinker and analytical problem solver. We need all kinds of other professions as well, and we STILL dig holes with shovels.; and B.) In order to teach youngsters to code, we also need... @blacklight @cybeej @Natanox - ...to teach them how computers "think", and therefore old tools like Z80 and 6502 Assembler, BASIC, Forth, and a few other contrived languages are helpful in instructing even if they're not used in the "real world" anymore. Then they also need to understand the fundamentals of how the Internet works; things like TCP/IP and ICMP, along with historically significant developments like AT&T T-Carrier, IS-IS, IPX, and Token Ring versus Ethernet. @blacklight @cybeej @Natanox - I think that Robert Heinlein pretty much addresses the core of this problem in Glory Road and the character Rufo has most of those answers for those of you who had the time and inclination to read while you were growing up.  @Natanox @blacklight @cybeej A "must read"? Well, that's a hard one. Let's just say it's a "strong buy". Anything by Heinlein or Niven or Asprin or Asimov is a "must read" or a "strong buy" in my book. @lorq @blacklight @cybeej @Natanox If you've not listened to "The Fall of Civilizations" Podcast, then you're losing some long form/history context for that statement! @blacklight @cybeej @Natanox So basically I'm a holistic technology teacher when I have the good fortune to teach. -- Now, all of that said, I still believe that, statistically speaking, the number of kids ditching class and smoking weed out behind the bleachers or getting drunk during and/or after the Friday Night Football Game in high school is still the same as it was back in the 1980s and 70s and 50s, and the smartest 3-10 percent are still out there learning, doing what they do. @blacklight @cybeej @lorq There are multiple bad developments I see at work here. One would be "dependency hell", another one the abundance of "jack of all trades" libraries and frameworks that can't be split up at all. Web development became quite monstrous in this regard, though some IDE's (or compilers?) are also quick in silently attaching 3 to 4 megs of libraries onto your hello world program unless told otherwise, just in case you need them. @Natanox @blacklight @cybeej You are not wrong. And that is also why I have to have "the talk" with devs before they put fresh code randomly into production. Then I attack it to see where it breaks. Then I give them hell if it's a large business entity I'm consulting with. Sometimes we learn by doing. Sometimes the dependencies teach us lessons we didn't know we needed. @lorq @blacklight @cybeej I feel like we should get back to the UNIX / GNU style of toolboxes (not sure right now where the philosophy originated from). Make a tool that does *one* thing, and does it exceptionally well. @blacklight @cybeej @Natanox @lorq Abstraction and hardware independence are two very separate concepts. E.g., Multics which has many levels of abstraction but was so tied with the hardware that it was EOLs when it was to expensive to maintain the hardware.   @blacklight @cybeej @Natanox @lorq Hey, they didn't even agree on character sets! (see EBCDIC vs ASCII). @cybeej @Natanox @lorq @blacklight It does also feel like not needing to understand (so many of) the fundamentals is a sign of maturity. Throughout my career, Iβve needed to understand things like networking/quirks of multi-socket systems/endianness etc. however, those things didnβt have anything to do with βthe problem that a bunch of people were being paid to solveβ. @tom @cybeej @Natanox @blacklight I have got to say that a body of knowledge can only be made more valuable (up to a certain point, of course) by expanding depth and periphery to other connected thoughts and concepts. That's why they always used to call me into the horribly damaged, difficult, lingering problems that would get 27 VPs and engineers onto a conference bridge for a couple of hours. And, to be honest, I reveled in solving the hard ones. -- Jack of all trades.... @lorq @cybeej @Natanox @blacklight Oh, Iβd fully agree with you - just that I think that depth etc. may be of a non-technical nature (or totally different areas of tech). @tom @lorq @cybeej @blacklight Especially the dopamine rush when you figured it out and suddenly all makes sense. π @cybeej @lorq @blacklight @tom @Natanox then it's "plus 1 to the list". Or more, depending how hard it makes you think! |
@cybeej @Natanox @lorq good point there.
I've looked at some of the Assembly code that was written at NASA in the 1960s and 1970s (the one for the Apollo programs was also open-sourced a while ago).
I was impressed by how "embedded" it was, with literally zero room for abstractions. The code was tightly coupled to the hardware. Each single bit was crafted and optimized for its specific purpose on that specific hardware.
You can do amazing things once you remove all the abstractions. You can get very creative on how to optimize resources if you know that your code will only run on one specific piece of hardware, for a very specific purpose.
Let's not forget that until at least the early 1980s most of the computers didn't even agree on the "word size", and even on the byte as the minimum quantity of addressable information.
As we started seeking for compatibility, more general-purpose hardware and software, lower entry barriers for coding etc., we started introducing abstractions.
Those abstractions came with many advantages - namely lower barriers for coders and greater portability. Also, decoupling software from hardware meant that you no longer have to be a electronic engineer (or an engineer who deeply understands the architecture the software is running on) in order to code. But I also feel like there's an inflection point, and once we pass it those advantages start to fade.
It's obvious why a compiler that can digest the same piece of C/C++ code and produce an exe on different architectures is a useful abstraction. Same goes for a virtual machine that can run the code on any architecture without recompiling it from scratch.
But when building a basic website ends up creating a node_modules folder of 200 MB, requires the developer to be familiar with npm/yarn/gulp pipelines, transpiling etc., and maybe also with deploying their code to a Kubernetes cluster running on somebody's private cloud, I wonder if we've already passed that inflection point.
@cybeej @Natanox @lorq good point there.
I've looked at some of the Assembly code that was written at NASA in the 1960s and 1970s (the one for the Apollo programs was also open-sourced a while ago).
I was impressed by how "embedded" it was, with literally zero room for abstractions. The code was tightly coupled to the hardware. Each single bit was crafted and optimized for its specific purpose on that specific hardware.