Growing up with AI
medium.com
medium.com
When I was a teenager not long ago, I was mostly motivated by cheating in games which got me learning basic scripting for keyboard/mouse macros which then led me to increasingly complicated stuff for botting.
But there are so many more motivating factors for learning how to code today, and they have never been more accessible. For example if you want porn of your high school crush? You gotta train your own deepfake for that. You will start off as a script kiddie but when you grow up you can tell people you've been training neural networks since you were 12.
That's all gone now... At some point I started to get darker and more cynical, and began to see technology not as a way to improve the world, but rather as a way to take what is mine. It started as a few disappointments here and there, then into short bouts of anger, then expanding into a constant simmering rage. Don't know if I'll ever recover.
What happened...
And when you're 16 it's normal to be attracted to other 16 year olds.
Who says society is going to shit?
Maybe I'm wrong, any thoughts from people who worked with kids? I can give anecdotal evidence from my son (had no problems with Python or CHIP-8) but that's a sample size of 1.
I wouldn't say that Scratch was my gateway to programming, but I played with it a lot in my early teens. In my opinion Scratch is very good, for the following reason:
Programming is about achieving something by abusing the tools you have, right? (This is not all of programming, but I would say it's ~86% of it. You might call it technical sophistication). And for that, Scratch is wonderfull. The tools are colorful, easy to understand and while there are a lot, it's limited in size. You're learning the soft skills of programming with a lot more fun.
What about the limitation? In scratch, you will explore the borders yourself and will have much easier time to understand why the solutions which exist in other languages are usefull ("Oh, finally I can automatically spawn a lot of the same object in")
Limited, of course, to my own expierience...
No IDE to set-up, no installation, simple interface, tons of kid based examples, highly WYSIWYG, speed to first output etc...
I think we techies forget how much patience it takes to just get an environment up and running.
For example, a kid can spend an hour adding a tree of dialogue to their text-based dungeon crawler, only to get a compilation error they've never seen before. They might have forgotten a curly brace somewhere and I'll help them find it, then they give it another go only to find out they forgot a semicolon or misspelled a variable name. That series of events can be pretty demoralizing, and it takes some coaching to get them through.
The above is obviously a teachable moment to test early and often, but the point is kids often lose motivation in the face of errors they don't yet know how to interpret. On the other hand, kids get really interested when they can see the fruits of their labor come to life, which can happen without a lot of friction in Scratch.
So to give students a taste for that success without the slog through syntax errors and stuff, things like Scratch are fantastic. Especially for younger kids where attention span and getting bored or disinterested come more easily. We quickly move on to real languages, though, and the concepts they picked up in Scratch are easily portable to Python or whatever else.
For kids younger than that, maybe it's better to learn scratch, but I wouldn't trade Small Basic, it's a great language to learn, the only bad thing is that it's made by Microsoft and only runs on Windows.
Edit: I'll also point out this:
> It was pretty obvious to me that I had committed a mistake at some point of my code.
How a student handles this is also often a sticking point. "Oh no, another error, I'm bad at this, maybe this isn't for me." Is an attitude that I've had to turn around. It goes a long way to convince a kid that it's actually the computer's fault because it isn't smart enough to understand what you're trying to tell it. So you have to be really specific in how you write to it. Then suddenly error messages are informative clues on the way to making your program work, rather than the computer scolding you for being a bad coder.
I tentatively agree with them. If I can take a stab at what "real" programming is, it's when you can't expect everything to just work out of the box. You can screw it up in unexpected ways. Sure, that's demoralizing. But you either win or you learn, and I wonder if winning too much, too early prevents cultivating the mental ruggedness it takes to really program.
Critical thinking and problem solving is something that seems like it's slowly fading away in modern education. So much of it is pure memorization for fill-in-the-bubble style tests. Letting kids at an early age tackle a problem that requires them to use separate steps and pieces of logic to complete seemed very developmental to me. Even over that short time span I noticed a huge difference in the mentality of how the kids approached problems after the course was finished.
As far as being excited about coding, I can't say just how important this is. Especially at a young age, as long as they feel like they have the capability to use the tools, almost 95% of the students I taught were fully engaged in playing with Scratch. I've taught adults js for a while now, and I usually get about a 30% engagement in any course, so those numbers were crazy to me. The problem though is when they get stuck, it has to be intuitive enough for them to figure out how to solve without being able to pour through stackoverflow posts. Kids don't use SO, they use Youtube to figure things out. Youtube had great scratch tutorials for them to follow, and so it was easy for them to get past things in a way they were comfortable with.
Overall while I think it isn't something that should be invested in heavily by kids, it's a great lauchpad to get them excited for coding in general. I see it as something akin to lego - it's there to fuel creativity and interest, not necessarily to replace architecture or engineering.
The last major step we had for making technology more accessible and easy to use for more people was the touch screen which made it possible for anyone to understand what "click the button" or "drag the folder" means.
My kids speak with Google Home all the time. They get more and more creative with what they ask it for.
Furthermore, you can interact with it at naturally at a dinner table or in a meeting room without having to look down at a screen. It really just becomes a natural no-obstructive participant of the group of people which I think is going to be it's biggest
Whatever weirdness my generation feel around speaking to tech it will be totally normalized by the coming generations.
As if the two concepts follow or are related at all, it seems more like a extremely convenient way to pivot the conversation to this new area of hype in technology while not actually owning up to anything.
How about we talk about anti-trust law, privacy, and busting up Facebook and Google instead?
What they are as companies is an entirely different matter, in which case I would not doubt your comparison.
Take, for example, the decreasing quality in user experience in map apps over the last few years. Mining our data is apparently much more valuable than doing a simple job better.
This is not to take away from the work - I’m a big fan of Cynthia Breazal’s group and the work her graduate students have done over the years. But it would be nice to see effort put into removing the artificial separations between user/programmer, or learner/professional. An apprentice carpenter uses real hammers and table saws, an apprentice baker uses real flour and sugar and ovens, so why are apprentice programmers using the plastic playset/ez bake oven equivalent of Tensorflow?
(and if the answer is just “because tensorflow is too hard for a 7 year old”, then how can we get somewhere where there is something as powerful, if not more so, than Tensorflow, while also being accessible to 7 year olds?)
Put another way, you generally don't give interns root access to production servers.
(You want the people complaining about how Go doesn't have generics to be stuck with a programming language that contains "only concepts a 7 year old can understand"? I'll even stipulate you the 99th percentile 7 year old. You'd never read about anything else on HN ever again; it would be nonstop complaining.)
[1]: https://en.wikipedia.org/wiki/Piaget%27s_theory_of_cognitive...
But that doesn't mean that every feature has to be that complex. The concept of typing commands into a Basic prompt was apparently not too difficult for many kids who were lucky enough to have access to a computer.
I think the crucial ingredient to make a feature easy to understand is the ability to see its effect, so that you can experiment with immediate feedback, and many common language features can actually be made to satisfy that requirement with the help of a sufficiently powerful debugger.
It doesn’t have to be like that tho’. The original Beeb was designed for pedagogical uses sure, but people used them for “real work” too, including controlling lab experiments, machine tools, even financial applications. People used STs and Amiga’s for real work too.