10 print "my sibling smells"
20 goto 10
Computers of that era booted up straight into BASIC and you could easily enter the above. It was obvious to anyone watching exactly what was going on and they could have a try.You can conceptually do the same thing now, but have to jump through hoops first. Download the right dev environment, work out how to start an editor, work out what code to write, work out how to run it and finally see the results. Devices are very personal now, so no one is likely to watch you do this, and trying to mimic it is far harder than turning your own device on.
Hopefully we'll end up with single function devices that can do this. The RPi is a good step in that direction, but still requires a lot to get going (look at all the cables and other bits and pieces you have to connect first.)
There are a couple of things "wrong" with the way we teach kids computers today.
Our educators are in the hands of the masters of consumers. When a new technology comes out, we all abandon the current stuff, and engage in the upgrade cycle. Repeat until generations have no clue any more about what the old ways were.
This is an absolute falsehood pushed upon society by those who wish to control the consumer base. It is consumption destroying education, plain and simple.
The point is this: Every C64 that was ever produced - heck, every 8-bit computer, ever - STILL WORKS, or can be MADE TO WORK in the area of computer education.
It is absolutely arbitrary that computers get old. Every machine that was ever made, is still just as useful as it ever was - the difference is, the user walked away (because they are consumers not users).
I have a large collection of 'antique' computers in my midst: C64, Atari, Oric, Atmos, Telestrat, MSX, heck .. even a BeBox and an SGI O2. All are still working, all are still quite capable of engaging a young mind in the exercise of exploration and discovery that makes a good developer.
And, my 3 year old and 6 year old kids LOVE THEM. They absolutely LOVE the old sprites, the old simple ways. The 6-year old takes immense joy out of typing:
10 PING
20 WAIT 15
30 EXPLODE
40 WAIT 50
50 GOTO 10
.. into an old Oric Atmos thats been set up exclusively for him to be able to do that .. in fact the very first writing he was able to do was in typing in a BASIC PROGRAM!!The 3 year old absolutely loves that he can turn the machine off and on, and off and on, and off and on .. and it will still work. Can't do that with Daddy's workstation!
So the point is, parents: disconnect your kids from the consumer trap. Give them old computers to learn computing on. Everything they will ever learn, WILL STILL BE VALUABLE TODAY when they 'grow up and get a bigger computer' - the reason is, because computers still work, fundamentally, the same way.
I predict my 6 year old will be hacking in assembly by the time he is 10 - just like his Dad did. And thats what made me the developer I am today.
(BTW: yes, I also have rPi's, Beagleboards, and so on.. when they're ready, they'll be available to the kids to hack on. But if the kids can't do their own low-level programming by the time they get the rPi dusted off, I will be very surprised..)
EDIT: Another thing that is 'wrong' with computers today, imho, is the decoupling of development from use. Again, our computers have been turned into consumption platforms - the moment that Microsoft removed the developer tools from being part of the base OS image, computers started to lose a lot of value. Any OS that doesn't ship with a way of building apps for it, inherently included by design, isn't an Operating System - its a Consumer Capture System.
Do everything you can to get development tools back into the OS, people. It is more important than the desire to reduce the effect of having 'too many smart developers out there'..
Basically, I think that the reason people don't program as much as some would like has nothing to do with access to programming environments.
I was actually kind of impressed with the Sugar environment when I tried it out with my nephews. They spent a lot more time experimenting with the thing than I even expected. Something was different about that system. It encouraged exploration in a way that their normal YouTube and video game habits didn't. Maybe it was just the nature of the applications.
- find out what platform they are using (Unix, Windows, Mac, iDevice, Android etc)
- Ensure Python gets installed or is accessible (add in version 2 versus 3, 32 bit versus 64 bit)
- Work out what the text editor or "IDE" will be
- Enter the code (no gotos in Python)
- Run the code and view the output
While these hoops are nothing for you or me, they are significant for others. Note how people report A/B testing showing that extra steps towards various goals results in big dropoffs.
Incidentally this is what repl.it does with QBasic:
> 10 print "hello"
Parse failed: Syntax error at 1:10: Token("hello")
> help
=> 0In my experience, if you can create that initial spark with your kids (as I did with my daughter, just by showing her the C=64 programming book I had as a kid), then they _will_ want to know more.
The proportion of people with access to a computer in 1984 was much lower than it is today as well.
Far more kids can get to a browser and to some kind of editor.
That gives you a javascript development environment.
In addition you have access to the internet that provides you will endless tutorials and places to ask questions.
How many teenagers would it take to produce Candy Crush, a highly-polished game made by a team of teams -- art team, multiple app coding teams, database team, facebook integration teams, financial team, and management team. Man-years of effort went into making that game.
Now be 12. Be a gamer. Be a kid who's choosing between struggling to make HTML5 Canvas work on a webpage, and playing games with friends.
A talented teenager could spend a few weeks writing a game and realistically hope to see it commercially published. Even the most ambitious games took no more than a few man-months. Several major UK games studios were founded by people in their teens and early twenties during this period, most famously Codemasters. Nobody really knew what they were doing and games were something of a cottage industry, so there were no real barriers to entry. There was a distinct punk sensibility, with weird and irreverent games being published on cheaply-duplicated cassettes.
The British programming boom also benefited from a variety of other factors - the BBC taking a major interest in promoting microcomputers, a very supportive government and an exchange rate that made Japanese consoles punitively expensive.
When I was 12 I wasn't trying to build Seven Cities Of Gold, I was happy just to have a little blinking sprite move across the screen.
Nowadays you can fire up a browser and scratchpad and have a hello world alert box pop up in five seconds. And there are arduinos, and raspberry pi's, and crazy cool robotics kits. There's still plenty out there to motivate kids who are interested in tinkering.
The stories kids write and the pictures kids draw are primitive when compared to what they could buy, but they still like to spend time making them!
My impression is that iOS developer tools (and modern high-level tools generally) provide beginning developers with a much quicker path to producing highly visual applications than I had as beginning C programmer decades ago.
More visual feedback == more fun == more motivation to continue.
http://durhamcountylibrary.org/2013/06/teen-tech-camp-2013/
http://exitevent.com/teen-tech-camp-hosts-future-developers-...
http://www.slj.com/2013/08/technology/powerful-partnerships-...
Kids learned to program in Python, on a Raspberry Pi, and each of them left at the end of the day with their Pi, and accompanying monitor, mouse, keyboard, etc. Some of these kids were underprivileged kids who had no computer access before, so the event was a pretty big deal for some of these kids. From what I heard, a few parents teared up at the end when they found out their kids got to take all their stuff home with them.
More programs of this nature, and more access to Arduino, rPi and the like, is one of the things I hang my hope for the future generations on.
Aside: I'm proud to say that our other co-founder here at Fogbeam Labs, snkahn, was one of the co-conspirators who helped pull that together.
Looks like the code is available at: https://github.com/kgrandis/teentechcamp
All joking aside, I think the advent of very accessible, low-cost SBCs, coupled with languages like Python, is a Good Thing. Our local hackerspace, Splatspace, also helped sponsor the Teen Tech Camp event, and we do a lot of stuff that's geared towards working with kids (teaching Scratch, doing "Squishy Circuits" demos, helping with "math and science night" at a local school, etc), and I'd like to see us do even more of that sort of thing.
One of my biggest regrets right now is that I'm so damn busy with Fogbeam Labs, that I don't have as much time as I'd like, to personally teach some classes and what-not. But I keep telling myself that things will stabilize eventually, and I'll be able to do more of that stuff...
- Sprites. You had to use pencil and paper to calculate the bit values on a bit map and convert these in to DATA statement in BASIC
- Modifying bytes directly on the disk to change some ASCII text to whatever you like.
- Going to K-Mart and program the demo machine with some prank program and let it run.
- SAM Text-to-speech. We hooked it up to the phone mic and used it to do prank call our friends.
- Peek and Poke any part of memory, sometimes get funny results
- Typing out programs from magazines and watch them do funny things, flip text or other effects
- Connecting to a BBS
Fun times!
We need the CompSci equivalent of Meccano sets for kids to tinker with. Something that's easy to just pick up and start playing with, gives instant feedback, and equips them with the skills to go and play with bigger and better toys.
The guys at Khan Academy understand this well, and they've built something pretty slick. <https://www.khanacademy.org/cs/browse-programs> I guess you could describe it as a cross between processing.js and JSFiddle, with a showcase for interesting new projects.
From my limited interactions with the system, I'd say it's already pretty good, but to be great they need to figure out how to make peer-teaching work better. Also, I think they would benefit from an even more accessible "just pick it up and play with it mode", rather than insisting that the kids sit through tutorial videos before they can do anything.
Went to my friend's C64, typed everything out and then sat looking at the screen after typing 'Enter' for the last statement.
Nothing happened obviously. That damn book didn't teach u about compiling, running and I am not even sure that book was about programming for C64 or what not.
When my dad got back from work, I showed him what I'd painstakingly typed in over the course of what seemed like hours to an 8 year old, and that's when I learned what pseudocode was. >_<
Of course that's a sample size of 1 but it's still worrying.
I'm not saying appliance-like functionality isn't a good thing ... for the masses it undoubtedly is.
But as the OP's article points out quite nicely, it's not conducive to lighting a fire inside a young mind.
I remember going to the back of computer magazines and transcribing pages upon pages of BASIC code corresponding to various games ... (on an Apple II) ... those were definitely the days.
Like Legos or Erector sets, kids are more fascinated with toys they can build with rather than play passively (which they get bored of quickly). Replace "toy" with "exploration venue" and you have a whole new world of possibilities.
Cheap enough for curious kids to buy themselves, very easy to use, both with a strong connection to the real world.
In addition, as well as a stand-alone internet connected device, the Raspberry Pi makes a cheap Linux desktop computer.
Out of the same notion I am doing a series of video tutorials on how to create browser games for my 14 year old girl and her classmates.
It's also in english so as a side effect they get into that as well.