David Brin Laments Absence of Programming For Kids 355
An anonymous reader writes "David Brin is an award-winning science fiction writer who has often written on social issues such as privacy and creativity. Now, he's written an essay for Salon.com titled 'Why Johnny Can't Code'. He discusses his son's years-long effort to find a way to use his math book's BASIC programming examples. All they were ever able to find, however, were either children's versions (on the Mac) or 'advanced' versions which attempted to support modern programming requirements (and which required constant review of the user's manual). Ultimately, they ended-up buying an old Commodore 64 on Ebay — Yes, for those of you under the age of 30, 'personal' computers like the Apple II and C64 used to all include BASIC in their ROMs."
There are options (Score:3, Interesting)
Re:There are options (Score:4, Interesting)
This sounds very much made up to write an article.
Having said that, I have tried to find kid's programming books for my 8-year-old daughter. I started learning computer programming at 8 using my Commodore VIC-20 manual. It had a little cartoon computer character that led you through BASIC programming from the typical 10 PRINT "TIM" 20 GOTO 10 all the way to "advanced" games. As a kid, I absolutely loved it.
However, I have been able to find *nothing* like that for her... Any thoughts out there?
How is it that (Score:2, Interesting)
Why should kids learn programming when they'll only be able to compete for a programming job if they take an East Indian's dollar-a-week salary?
First Big Tits Dupe (Score:5, Interesting)
Perl seems to fit the bill, since it can be as simple as you want and doesn't even have the type issues Basic has. Perl is happy to be procedural. When you are ready to step up to objectsperl is ready.
Object oriented perl is a wonderful way to learn objects. Wait don't scream. I said "learn". I'd been object oriented programming for years in Java and other languages. But I truly did not understand how all the pieces worked till I wrote perl objects. In perl it's like one of those "visible man" models. You learn how inheritance works. You learn how binding of an instance to a class works. You understand closures for the first time. You understand how the namespaces are kept separate and how instance memory is allocated. It's not just some voodoo that simply works, like in JAVA. Moreover all of the voodoo is not out of reach but right there for you to mess with. An instance can change it's own inheritance if you want it to. An instance can create a new method and write it into it's own namespace if it wants to. An instance can trap calls to it's own methods and redirect them or intercept calls to methods that don't exist and respond to them.
Those features are not unique to perl (for example pyhton implements objects identically to perl). The difference is that All of that object management occurs in perl itself and is not hidden behind syntactic sugar (like python and java). You quickly appreciate what dereferencing costs, etc...
The other thing that is nice about perl for learning is all of those prefixes like $ @, and so forth. They may make perl look like cursing but they force you to think about what a variable is. When I index out an array, I get what? an array? no I get a scalar, so $X[2] is how I index @X. You can look at someones perl program and if it's written well tell what every word is. You cannot look at a bare name in python or java and tell if it's a method, an array, a hash, a scalar or reference. Perl you can. (Oh and by the way let me explode a perl/pyhton myth. python has more special markup characters in use than perl, the main difference is that in python they are suffixes instead of prefixes and are overloaded with multiple meanings--try counting how many modifiers there are some time (e.g. () , [] ** and so on))
Now once you learn perl objects. Well it's time to put down the perl and back away slowly. Python, java are much better languages for writing re-usable, easily read, complex object oriented programs. Perl is still a much more powerful language than either. But it's powerful for efficiently creating compact or single use programs quickly. Not for well designed complex systems.
Perl is good language to start in, plus it's useful enough to work throughout your career. Basic is not.
http://dups.slashdot.org/ (Score:3, Interesting)
Re:You know, though this is a dupe (Score:3, Interesting)
Even better, find an emulator that runs CP/M which also emulates various types of terminals. One fun thing about computers is making them do fun looking *stuff* like display hacks, moving the cursor, typing backwards, etc. Learn how to control the display by issuing character sequences. Find some books by David Ahl. CP/M had an incredibly rich set of simple tools. Part of the fun is that you have to do some actual building to make things work. Sample any number of the host of languages available under CP/M. Use a line editor. Print out program listings, etc.
Use the computer as a *tool* to learn something else - like math. Number fun - magic squares - rectangular, triangular, perfect numbers. Find prime numbers and pythagorean triplets, etc. Do number base conversions. Learn dimensional analysis and units, etc, etc, etc.
Let the child enjoy saying "Whoopie. I made this."
Re:You know, though this is a dupe (Score:3, Interesting)
But seriously what could a kid do in Excel that would actually hold their interest longer than half a second?
Write a macro the does all their math homework for them, including showing work? Figure out how long it takes them to save up for a new bike? There's lots of ways a kid could be interested in Excel.
Re:Flame Baby Flame (Score:2, Interesting)
One scary article I encountred (on ora.com) suggested starting kids out on tcl/tk.
YMMV.
Re:Despite the Dupe - I *Hated* BASIC; PASCAL Baby (Score:3, Interesting)
It was a catastrophe. When I first started composing this, I was going to blame it on BASIC itself, then on the crappy line editor I was trying to use. But as frustrating as these things were, my greatest shortcoming was that I had no adult supervision. When you try and teach yourself, rather than learning from an expert, you tend to not realize when you've missed something very, very important.
I feel a deep sense of shame even today for admitting this level of stupidity, but I didn't know what a subroutine was. Knowing that I could have called the same snippet of code from different parts of the program would have saved me much heartache, but I had the concept of a flowchart firmly in my head, and it seemed to demand a single, unbroken flow of execution. Which demanded cut-n-paste. Which I couldn't do with that crappy line editor.
Thinking on it, I should probably try tackling that project again, so that next time I set down to writing a long anti-BASIC diatribe, I'll at least know what the hell I'm talking about.
Re:Perl OO (Score:2, Interesting)
In perl there are references. A reference is created by \ on a container.or you can create a reference with anonymous array and/or hash syntax.A reference can have a namespace associated with it. This is done with bless(). Such a blessed reference is called an "object".Subroutines can be written to work on objects. They expect their first parameter to be the object being worked on. Subroutines that expect an object as their first parameter are called "methods". Often this parameter, by convention, is named $self.If you use an '->' between an object variable and a subroutine then the parser rewrites this to provide the object as the first argument to the subroutine.A method call is first searched for in the package the object is blessed into. If it is not found there the package's @ISA array is examined. Each namespace in the @ISA array is searched (while in turn any @ISA's in that namespace is searched if the method is not located in the namespace) until the first method is found or none is.
That's it. Everything else you can put together from general OO techniques.
Here's a small Point class. _init() is seperated from new() so that any sub-classes of Point (those packages that have a @ISA list with 'Point' as an element) can override it without having to rewrite new(). Alternately a sub-class could do some additional work and call $self->SUPER::_init(...) to call _init() in some super class.