Learning to program is getting harder

I have not seen any age-correlation in what you describe. For sure there are "career" programmers who don't know much about computers beyond their narrow scope of expertise.

You're admittedly obsessed with computers, which presumably means you spend a lot of your free timing tinkering and learning. You've picked up a lot of very useful knowledge, but surely there's room in a profession for those who are not obsessed with their field? The programmer who doesn't know anything about a BIOS perhaps spends their free time bike riding.

To add to this, one other way programming is getting harder is that there is no incremental path to becoming a developer. In the past, you could easily become a programmer by accident. You wanted to edit your MySpace page, google around, learn some HTML and do it. You wanted to mod a game, you started messing around with the game, download other mods, and change them.

I think this incrementally is gone in two ways. One is that programming is so abstracted away from how we use computers that it's almost in a different world. But even if you figured out what programming is, when you actually attempt to do it, the sophistication of our tools make it a lot harder to get started. Everything that makes us programmers more productive: compilers, build systems, package managers, etc make programming less accessible. There is a lack of coherence between all these tools, no one person designed them, they're the product of bottom-up innovation (the bazaar) which has the problem of making things messier.

I think open-source/bottom-up innovation is great, but eschewing "the cathedral" for a wholly bazaar-based approach is making it a lot harder to learn to program.

What I'm working on now (I'm the founder of Repl.it) is taking a lot of these awesome tools and putting a nicely designed experience on top of them. We want to bring back the welcoming cursor that invites you to program the computer and bring back incrementality to programming, you start from a repl, and from there you can move on to web-dev or what have you. You'd be surprised how fun it is for kids to build CLI programs before moving on to build other things. We put together a page where kids can post about what they're building with Repl.it and it's really inspiring to see: https://repl.it/ibuiltthis

I've written more about what I call a "Holistic development service" here: http://repl.it/site/blog/holistic And also here I describe how we went wrong with "Disintegrated Development Environments — How Did We Get Here?": https://amasad.me/disintegrated

I do Java programming by day, and I still find the IDE to be a pain in the ass. It offers me a lot of power (enough that I still use it for all my Java code), but the configuration is so opaque. It's a GUI, but what a confusing, complicated GUI.

In contrast, opening a repl in python/node is super easy, and it was super easy even when I was a beginner.

Building a GUI like you said would be hard, (though I did a very simple tkinter gui in my first year), but I think that even for a beginner, opening a repl and starting to muck around is easier without the IDE in the way.

ASU has a degree called 'informatics' that's run by the computer science faculty but focused more on rather than

I just transferred into it from computer science, because I spend all my free time making games anyway, and the informatics program lets me take an elective track to get credit for that. I do think CS is probably a better fit for what I see as my long term plan, but I think this program has a lot of potential for people who wouldn't otherwise call themselves engineers.

One of the consequences of the transition from command-line interfaces such as DOS and Unix to contemporary GUIs such as macOS and Windows is we have moved from environments that do not make a sharp distinction between programmer and user to environments that make a sharp distinction. One of the nice things about command-line interfaces is being able to make powerful tools that are composed of smaller tools. Unix has a powerful collection of tools, and if those tools aren't powerful enough even with combined by pipes, there's awk and sed, and then there are scripting languages. Contemporary GUI applications, however, work very differently. Instead of being composed from smaller programs, many contemporary GUI applications such as Microsoft Word, Adobe Photoshop, and iTunes are large monoliths that are expensive to write (just consider how large the teams engineering these products are, and consider how much effort it would take to write a clone of these programs from scratch), difficult to combine, and are difficult to script unless they are specially designed to support scripting (e.g., AppleScript, Microsoft Visual Basic for Applications, etc.). Web applications are even harder to write than native GUI applications, and they are even more difficult to deal with in regards to interoperability and scriptability.

It didn't have to be this way, and there's room for a future where it doesn't have to be this way. The Smalltalk-76 environment demonstrated that it is possible to construct composable and interoperable GUI applications. The Genera operating system for LISP machines worked similarly. Apple's OpenDoc initiative would have introduced the wider world to the concept of composable GUIs, although it was canned as a consequence of Apple adopting the tried-and-true OpenStep platform as the basis of future Mac development. An operating system environment inspired by the Smalltalk environment and LISP machines that provides both a REPL for tasks that are equivalent the Unix command line and an OpenDoc-like API for designing composable GUI or even web applications would create an environment that is both easy to use and programmable. I've been growing more and more excited about the possibility of such an operating system for workstation users that could one day serve as an alternative to contemporary desktop operating systems and environments such as Windows, macOS, and the Linux desktop.