That's hardly what I said.

It's good that computers are more accessible. But by making it easy, we're providing less opportunity for people who are curious about innards at an early age.

Of course, now we're teaching computational thinking in schools, but IMO it's a really big open question whether our attempts to teach that work, especially in elementary school.

It's more like "now we don't have to teach everyone to read and write, we do the (filtered/censored/etc.) communication for them."

I think you missed my point.

Before, a huge portion of the population was using computers and had to peek under the hood. This means you got a lot more people who got curious about how the machine worked very early on.

I am teaching STEM stuff to kids these days-- programming in Scratch and python, etc. My friends and I, back in the day, were all poking around memory, rekeying Basic programs from magazines and moving on to writing Turbo Pascal programs, etc, at a pretty early age. I don't see this with the kids I teach. There's not as good of a path/funnel there, and I'm not sure whether the stuff we do to e.g. teach programming in elementary school, etc, are analogous exercises in computational thinking.

I encourage you to spend some time getting to know the linux command line. I had a similar path and I gained the most enlightenment (and productivity) when a got some help from a good mentor and learned how to find my way around. Menial digital tasks that most people suffer through all day turn into small puzzles with big rewards: you get your day back. Sure, maybe half of it went to figuring out a syntax error, but then the rest of the days get to benefit from that work. Moreover, you learn the most when trying to fix that little bug, and you're better for it the next time.

Stuff like renaming 200 files, or converting 200 images to a different size, or normalizing 200 audio files you recorded yesterday, or finding the right few words in 200 files all can be done with minutes of effort once you unlock those powers. I use 200 because that's about how many times people are willing to sit there and bang out something manually. Tasks larger than that people tend to give up on, or buy a tool to help. The neat thing is, the same solution for 200 items could be applied to 200 million items without changes.

I would love for the full power of the CLI to be available to everybody without training. Until that gift comes from on high, we use the tools we have, GUI or text or SMS or whatever. Today you can pick your path.

The internet does unlock all of those doors to those who want to learn. There are incredible resources for learning new things and fixing problems that others have ran into. Reading man pages and printed manuals may be fun for some, but I'd rather search for answers, and chip in some when I can.

I firmly believe that the best technology can do both. Tools should be designed firstly for the 95% of users who only need them at a surface level, but provide pathways that encourage users to explore deeper, as they become ready.

macOS kind of does this, whether intentionally or not. On the surface, it's a basic consumer machine, with a web browser, media player, and office suite. But dig a little deeper, and you'll discover Automator, a great little tool for automating menial tasks which puts you in a programmer mindset. Probe deeper still, and you may discover the Terminal icon, full of secrets to be discovered.

It could be taken further. Imagine if TextEdit had built-in syntax highlighting whenever it detected code. "Regular" users would never see the highlighting, and professional programmers would stick to real IDE's or more advanced editors. But as a hidden built-in, it could be a wonderful stepping stone.

Now compare all of this to iOS. Yes, it's true, no one really wants to program on an iPhone anyway—but what happens if you give a child an iPad instead of a laptop? There's now much less opportunity for them to grow and discover more. This isn't to say that every child with a Mac will discover the terminal and become a power user, but some will, and be thankful for the opportunity.

> It uses separate "command" and "data" channels

This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.

FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind.

As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.

Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare.

That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.

And that’s also why SFTP is slower than FTP: because it’s a separate protocol implementing its own windowing which interferes with TCP’s, thus performance goes down the toilet when using SFTP over a high latency connection.

Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.