It took me 5 years of screwing around with Java, Python, and C++ "I want to help humanity" projects before I found that I really should just write small game clones in P5.js for fun. I'm a new stepdad, and if I want to be motivated to work on side projects in my tiny amount of free time, it's going to have to be a game.

Project: 80's game clone. Library: P5.js. Toolset: Notepad++, Python SimpleHTTPServer.

I cut my teeth on c++ on lab computers. I was crap at it. The compilation and debug cycle was slow and frustrating. I couldn't Google for answers on anything.

It's easier than ever to start programming, without any question, and so many batteries are included everything else is easier too.

People in some ways do expect more from their software now, and to help deliver all that there are tons of open source libraries available that can feel overwhelming at times, but that's moving the goalposts. Somebody learning to code doesn't need all that just to get something basic and interesting working. If you're tasked with making a functionally equivalent piece of software now versus 20 years ago, it's better and easier in every single way.

How long does it take to actually understand what all of that does? I can claim to understand it, sure--but I'm also thirty years old and I've been getting paid for this stuff for the last fifteen. (Not, like, random POKEs into memory to make syscalls, for sure, but I understood why stuff like SCREEN 13 worked, along with the general constructs of the language.) On the other hand, I pretty much fully understood how QBasic worked and its interactions with DOS at age 5. I was able to parlay that into C and C++ and into understanding how the thin virtual machine there, simultaneously into PHP and Java and how those actually worked by relating them back to lower-level concepts I'd picked up...

Cargo-cult monkeying about doesn't adequately, to me, replace understanding and insight--and "just make a Rails app and push it to Heroku" is fundamentally cargo-culting. If you don't understand how your tools work, you don't understand what you're doing. (I've written everything from CPU emulators to Rack frameworks to prove that I do understand what I'm doing.) I started doing that literally from the jump as a kid, and the systems were built so that it was something you could easily do.

There is nothing stopping anybody from digging into lower level languages now, in fact that is also easier than ever with open source IDEs, free compilers, fast processors, ubiquitous documentation, and helpful communities too. The mere existence of a totally open source operating system like Linux and its ability to function on commodity PCs and embedded devices is huge.

You can argue (and I believe this is the point of the article) that people don't bother going deeper because for most computing purposes interacting with very high level abstractions of really complex systems is sufficient (and indeed becoming the norm), which leaves users at a loss when asked to grok lower levels of abstractions. It's also true that there is now more complexity and there are simply more possible things to learn, making it less likely that any individual has the time to develop deep knowledge of all of the systems they use.

Those assertions may well be true, but I'd argue they are not the same thing as it being harder to learn anything in particular. It's daunting, maybe, because of the sheer possibility space, but all of the knowledge is out there and the tools are better than ever.

at some level, you're always going to be assuming the layer before reasonably works the way somebody gave it to you.

Its not cargo culting if you know where the actual dependence is, and both rails and heroku make it fairly clear what kinds of things they are doing. Even if you don't know how they're doing it, you know that without running the heroku part, you cant load the page in the browser, and without the rails part, you don't get any files you can change.

Same here, and I was a kid who a) had no idea what he was doing b) couldn't afford to buy Inside Macintosh c) really had no idea what he was doing. But honestly, I achieved more with C and some cargo-culted System 7 (6?) Pascal calls than I have with Go, with respect to UIs. I achieved more with HyperTalk than I have with Common Lisp, with respect to full-fledged application environments. Honestly, HyperTalk was by far the single most productive system I've ever used in my life.

Life was pretty great back then. I can only imagine how much better it could have been with highspeed Internet in my home. Or maybe we'd just be on the dozenth round of Macintosh Toolbox wrappers written by sleep-deprived college students by now.

Maybe, ironically, one of the advantages we had is that these difficulties forced us into a much better learning environment, when the answers weren't all immediately available through Google? Being the one who can self-learn extremely well gives us a big advantage when given a new problem or technology stack.

Now of course you don't need that to do hello world, but a beginner doesn't know that!

Ah, that brings me back to memories of boot floppies in order to change the memory settings of the system.

Recently I had this surface, some RT kernel extension we use would display possible conflicts. Despite programming a lot these days, my background is electronic engineering, so I still have a rough idea of what an IRQ is and does even on the lowest level. However had no luck trying to explain that to a 'pure' programmer.

Interrupt requests are easy to explain to even a novice computer user if you frame them in the context of something they're familiar with.

For example, when you press a key on your keyboard an interrupt request will be created to make sure the computer knows you've pressed the key. So in simplified terms, you could say when you press the "A" key on your keyboard, there is a part of the computer that says "pause what other things you're doing, respond to the "A" key press, then continue with what you were doing before".

I mean, it pokes the keyboard controller in order allow the processor to control an additional bus line to the memory controller. Then, thanks to 8086’s overlappping segmentation architecture, you can access 65519 additional bytes that were never intended to be there in the first place.

There’s Cthulhu mythos that is more acc si le than that.

Now, we have a proliferation of computing environments, and it's hard to give people generic advice about how to install and use a tool that would apply equally across all those various environments. Browser standards seem to be the one thing that's relatively common across platforms, so a lot of that stuff moves online.