I would hope that something similar is still possible. The most obvious is learning javascript and making browser plugins with the ubiquitous "View source" as inspiration (though much less so with React etc, but you can still mess with the properties/css).
Ideally it would be good to get set up to auto-deploy a website (e.g. Netlify) based on code pushes, even if the setup is done for them. This way they can have a hobby website that they can keep changing and the results are immediately show-n-tellable to anyone on the internet. For backend, maybe something like Firebase or equivalent.
I am mulling this over, but I think I will recommend python and django. He can learn to old school web apps, focused on serving http from the server. Then he can move into more interactive stuff with javascript.
If there was a library/framework similar in scope to Django/Rails with a lot of documentation I would recommend that one. Even though Javascript seems like a good language that you can achieve a lot of with, lack of one big framework makes it hard for new programmers to learn the ropes.
I am curious about opinions of others. My brother did program a bit in python, creating a text game that gave him a lot of interest in programming, but other than that has very limited knowledge.
We use to have 7+-2 layers of thinking. When you program, you hold in these layers: what word are you typing, where are you typing, what problem are you solving, what parts of codebase are you changing. If you do not touchtype, you are wasting at least 1/9 of your brain's possibility. Each time you are interrupting your stare from a screen you actually performing some extra scanning job which gives you nothing except of fatigue.
Actually my first programming decision which I did in my tenths was to get rid of QWERTY and it was one of few things in my life which I did absolutely right. So telling me that touchtyping skill is not important is just counterproductive.
> I wouldn't put that much importance into a specific editor
vim does to my text editing experience as much as touchtype does to my text input, no not-touchtyping person can understand how cool is to make all kinds of edits without getting my fingers off the 5 rows of keyboard (3 rows plus digits plus space but in default configuration you also need Esc).
Fatigue may be involved, but I'm not buying the rest of the argument. Most programmers are not touch-typing wizards, some of them still hunt and peck, and a few of them have an issue using a keyboard in the first place. People can adapt, and programming is not a typing competition as I said, it's a thinking and talking one.
OK, you convinced me that touchtyping is not important when you program. But what about learning? The SICP book contains tens of kilobytes of code which needs to be typed, copypasting of code while learning just doesn't work for me. If I do not do any typos when learning a new programming language, I just do not feel it. But if I need to observe the keyboard while learning than all the learning process goes south because I do typos not because I do not know the language but because I do not know the keyboard. Nothing impossible in doing this without touchtyping but for me this is too annoying.
And there is nothing wizardy in learning how to properly press a few tens of buttons, this is not anything creative.
I think touch-typing is important, but not more important than being interested in what you're trying to do. If trying to learn to type properly detracts from that, it should be learned later.
vi and emacs are a bit special because they have demonstrated extreme longevity. So in the spirit of the original question, it could actually be prudent to commit to one of those from the get-go and the mastery could compound and last your entire career.
There were no data structures besides arrays, and there was no theory. The internet was not available to mere mortals and books and magazines were expensive. There wasn't any other option at the time, and the only classes were in high school or university.
Half of what I learned was by reading source code to other programs that were shared (printouts from friends with access to universities, or from magazines).
I don't think I really learned how to program until I was in my late 20s and fell into doing it professionally. (At the time I thought I was a better programmer than I actually was.)
So, I do wish I learned to program in a better language, with data structures and a smattering of theory/discussion about algorithm efficiency. Probably a tutorial that progressed towards making something fun and interesting, like a simple space invaders-like or text adventure game.
But I would not change the part about reading source code.
What's important in the language choice is one that can grow effectively with the student. You want something that let's you start off with the ease of BASIC, but not be crippled by the limitations of BASIC (the typical BASIC students would have access to in the 1980s). That is, you want to be able to write the analog of:
PRINT "Hello World!"
But still be able to grow into more complex types, a proper notion of procedures (in particular permitting reentrance and recursion, and eventually threads). No goto statements or very constrained ones, as is typical in languages today.But if you use many modern languages they're designed for industrial use, not for educational use or progressive learning. So with C, C++, C# (caveat, not true anymore [0] but still true in most educational material), Java, and others you have to enclose the above at least in a method/function and in Java and C# ([0] again) that method is enclosed in a class. You may or may not need an include/import type statement. So just to get a primitive program going is 4 lines of C (or 5 if you put `{` on its own line), two of which are hard to explain immediately to a novice (`#include <stdio.h>` and `int main ...`).
This is where Python works well as an educational language still. A student can be taught very basic IO and about variables in two lines:
name = input()
print("Hello " + name + "!")
And the only oddity is "adding" strings, which can be explained a lot more quickly than `#include`. Then you can start getting into other types (booleans), conditional logic, loops, and aggregate types. Classes and functions as things they use can be taught relatively early with their own class and function definitions following later.[0] https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tu...
Since then I've fallen in love with code, become a senior dev, and developed morals when it comes to using others' code. But still, I wouldn't change a thing.
If I had to do it all over I would start with robotics and competitive programming and something with databases. Robotics is mathy and library heavy and deals with real objects. Code golf is super math and easy to get into a tight loop and teaches you to research algorithms. Databases are just so useful and are a better way of learning APIs i think compared to restful stuff.
I don't think the beginning matters really. You have you love it to do it for decades, and if you love it you'll get good at it. Dont have to look back and think "aha that path was optimal"
20 years later and all I do is write software. If I could start over, I'd spend a few years on the fundamentals. Learning programming for the sake of programming. Understand how computers actually work, detached from my work goals.
Pick one or two, then try to master them for different purposes, say Dart/Flutter for frontend, and Go/Rust for backend.