Slashdot Mirror
Why Teach Programming With BASIC?
chromatic writes "To answer the perennial question 'How can we teach kids how to program?', we created a web-based programming environment. As we began to write lessons and examples, we surprised ourselves. Modern languages may be powerful and useful for writing real programs, but BASIC and Logo are great languages for demonstrating the joy of programming."
There is still the theory that once you teach someone basic it becomes impossible to teach them programming. /running and ducking...
Sig Battery depleted. Reverting to safe mode.
I learned to program pretty much with Applesoft BASIC and a Franklin Ace 1000 manual
Now I'm teaching my mom (!) to program in Python using the Hello World book.
Honestly, I wish Python were around when I was learning. Trying to squeeze a new instruction between line 11 and line 12 kinda sucked sometimes. (Then again, I wish a lot of things were around...)
10 print "hello"
20 goto 10
This is why we can't have nice things.
John
...They GOSUB and don't RETURN.
despite their limitations and age, procedural languages are a better way to teach kids (or anyone)how to think logically about the steps required to make a computer do something they want it to do.
It worked for me in 1971 on a teletype at Cory School in SJ connected to a Stanford mainframe -which I had to feed my 'saved' paper tapes to
and it will work just as well today on whatever BASIC emulators (or even VB.NET god forbid) that are available today on PCs, pads or whatever.
Although Java is probably better for middle/high school, I do believe that Basic or Logo are better for those younger who have not yet learned how to deconstruct a desired outcome into a bunch of logical steps.
-I'm just sayin'
"Here, son, let's look at this Wordpress site that hasn't been updated in 18 months. Now, this is called 'SQL Injection' and 'Cross-site Scripting.'"
Nothing better than learning by example...
Those of us who were kids in the 80s and grew up playing on microcomputers with BASIC have a very distinct property:
We grew up together with computers.
When we were kids, computers were simple, single-tasking, small memories, and it was easy for a youngster to understand the entire system. As we got older, systems got more complicated, and so did our ability to understand them.
Today's kids start with computers that are already large systems with complex operating systems, millions of times more memory than we have *disk* when we started, that are difficult to understand at a low level. I think this puts them at a loss. Every child should be able to play with and learn on an Apple II, C64, or similar small system. Of course realistically that won't happen. So emulated "systems" with simple programming languages may indeed be a good idea for today's kids.
the correct question would be...
how do we get our kids interested in learning how to program?
and the answer to that would be...
tell them they're not allowed to do it.
I came for infotainment but was disappointed to find an edutizement
If you mod me down the terrorists will have won
You can teach people logic statements and procedures and about objects, even - with ENGLISH.
In my grade 8 class, there were no computers except the ones at the University I was by then programming with punch cards using stolen student accounts. But the math teacher asked us to write out our procedure for tying our shoes - in precise, motion-by-motion detail so another student could do it exactly the same way as we did, without help. Most people required over a page, and it was a revelation how excruciating it was. Later, in CompSci 501, I learned about logic statements and predicates and the wonderful Lewis Carrol problems ( 1: All my turtles that are not green are old....) All English.
"Computer Programming" on the other hand, is about making computers do things for you. By hook or by crook, by object or procedure, just get 'er done. I completely agree with the language snobs and detest BASIC. And I do most of my programming in it because you can make Excel about 10X more useful with just a little VBA here and there.
Learning Python or Java is just great if you plan to be a professional programmer one day, those languages can solve very large problems without the codebase becoming unmanageable. If your problem is getting a bunch of kids excited about what computers can do, you have no choice but to use whichever language will produce results with the greatest WOW factor with the shortest learning time.
That cuts out ALL verbose languages, languages that demand typing. The "Hello world" program should be one statement long.
Notice that doesn't chop out Perl or Python. But also notice that at kid-levels, those languages can only take screen input and produce text output. That was cool for me in the 1970's but I think today you'll get better results with something that can go graphical right away. (This also just cut out your original BASIC).
So, if your school has MS-Office on every machine, well, as a FLOSS fan I hate you, but you're crazy if you don't leverage the presence of VBA. You can show them what cool stuff a computer can do with Excel alone, show them some formulas in action and all that. (This, by the way, keeps them from thinking of "computer programming" as necessarily procedural right there - clearly, you are instructing the computer, but you are NOT using a procedure, just setting up conditions for behaviour of the cell objects!)
Then show them procedural programming by modifying the spreadsheet with VBA. This can lead quickly to manipulating the Excel data structure, which is a huge collection of objects with properties and methods. Many can manipulate charts in pretty ways, or turn Excel into "graph paper" with coloured cells in funny shapes, like ASCII art. You can take it all the way to them inventing their own objects in VBA.
AND: It will be useful in a job, even if they only learn to write 10-liners. Bonus.
Famous quote, but nonsense. In many ways, trying to build large BASIC programs and ending up with unmaintainable spaghetti code is one of the most valuable lessons a programmer can learn.
When teaching students how to program (which is entirely different from teaching them computer science), you should begin with the most fundamental concepts: talk about raw memory and opcodes. Discuss briefly how these instructions are actually interpreted and implemented (how a half-adder works is fascinating, even if most people never have to build one in real life).
Once your students understand how to make computers do basic things with raw instructions, teach them jumps, conditionals, loops, and even subroutines. After that, introduce higher-level languages and compilers, and demonstrate that the compiler merely automates what your students have already been doing. From there, teach progressively higher-level constructs, including second-order function references, data structures, and so on. Object-orientation falls out naturally once you get to structures and function pointers.
If you follow this approach, your students will have an understanding of the entire abstraction hierarchy, which is not only of immensely practical value, but also underscores the principle that nothing in this field is "magical". You can always pierce an abstraction, and even more importantly, erect new abstractions where appropriate. The most common flaw I find in programmers is the inability or unwillingness to build new abstractions. The only way we make progress in this field is by the old reductionist approach of breaking a hard problem into smaller parts and attacking each individually. When you teach your students how to do that by demonstrating the power of abstraction, you make them better programmers.
Programmers shown UML, Java class graphs, and so on right away become too familiar with that level of abstraction. They think of lower levels as some kind of magic and don't realize they can and should build their own levels on top of what they're given. The result is often incoherent, rambling, brittle, and ugly code. Don't let that happen.
When i first saw Scratch, included with the XO, got stunned on how powerful it was, and how visual and intuitivel could be for the children. Not sure if there is a web based implementation, but is open, available for all platforms, and maybe more important, already included in a computer meant for children (not sure how much it count in the rest of the world, but in my country almost all school chidren have it).
C# forces one to think in OOP terms - you can't write a hello world app without "class" in it. Now learning OOP is definitely the important part, but it's not the one that should come first - before that, one has to understand the basic blocks of algorithms. Conditionals, loops, recursion - that kind of thing. A language that lets you deal with those without bringing any unnecessary stuff into picture is the language you want to use for teaching programming. BASIC is one such language. C# is not.
I've got a big soft spot for pascal. I started wtih basic, and then LOGO (home computer had basic, then logo in school as a kid), but Pascal was the first useful language that actually taught me about data types, functions, and later, object oriented programming (TPv6).
Its easy to read, not prone to bugs like using = when you mean == (in C), and fast enough to get useful stuff done.
Problem with programming these days is that to get anything useful done you're buried under a hundred layers of toolkits and abstraction from what is actually going on.
Give kids an old PC with a copy of DOS, turbo pascal and some basic instructions on VGA mode 0x13 and you can write fun stuff pretty quickly.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I thought he was making fun of reporters when they try to talk about computers.
Duct tape, XML, democracy: Not doing the job? Use more.
Line numbers and gosub/goto s haven't been used since the mid80s.
Ever program with a VBA object model, using Intellisense prompting? Name a better, more complete, and useful IDE environment...
Count curly brackets all you want. Regard semicolons as essential. But you can't craft code that reads like simple English in any other language. Well named objects only make BASIC better.
BASIC is like the O'Reilly cover that was chosen for it: A big friendly St. Bernard or a language.
If you haven't built dozens of useful, maintainable, systems quickly, with small teams, maybe you should keep an open mind...?
"Knowing everything doesn't help..."
This reminds me of the joke about the programmer who died in the shower: "the shampoo bottle said lather, rinse, repeat".
They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance. - Terry Pratchett
No, it probably means that most people think procedurally instead of functionally. And while that's just a guess, I'd be willing to bet a case of beer on it.
It also probably means that most everyday problems are procedural/imperative. I'd be willing to bet a case of beer on that, too.
The beatings in academia that people get over the head with functional programming turns off a lot of people. Emphasis on functional programming in academia seems like mental masturbation instead of getting shit done. Kinda like what goes on between pure and applied science and math factions.
"Lisp is superior to everything" - oh hell no. That's like saying a hammer is superior to a screwdriver.
There is space in the toolbox for all kinds of tools. Not everything is a nail. If a problem can be solved easier in a procedural/imperative language, then use that. Similarly, if a problem can be solved easier in a functional language, by all means, use Lisp.
But don't tie your brain in knots trying to fit the problem (or the way you think) into the language.
That's just stupid and masochistic.
--
BMO
So the *BEGINNER'S* All-purpose Symbolic Instruction Code, and a language created exclusively for educational use are great languages for demonstrating and teaching kids how to program? What a shocker. You "surprised" yourselves how/why? By having ridiculous notions that "any idiot" knows how to teach kids better than the experts who set out in the 60's and 70's to EXPRESSLY do just that ?
You've been suckered by language-purists, people who spend so long arguing about WHICH programming language to write something in that I could have written something in ten languages before they come to any conclusions whatsoever. BASIC is *wonderful* for teaching programming. I know, I've done it, from class-mates back in the 80's to modern-day kids nearly 30 years later. And yet my ENTIRE intake year for university sat through a whole year of Java lectures from a qualified professional and still didn't understand what half the statements they were using actually DID, while I didn't attend a single lecture and passed the course just by emailing in the assignments from home 30 mins before they were due. That's not to make me a genius, I was just taught properly, encouraged to learn, and started with simple tools - I wasn't forced to learn, by rote, a complex tool that requires deep understanding to know what it's actually doing. I started on something I *could* understand and progressed in steps. BASIC didn't corrupt me, it was a stepping stone that I outgrew.
When you teach a child to write, you don't teach a 2-year-old quill-calligraphy, or demand their first piece in iambic pentameter. You give them a crayon. If it hits the paper 3 times out of 10 you congratulate them. Then you progress to more advanced things as the need requires. But guess what? If you think that's the last time you'll ever write anything with a crayon, you're wrong. If you're still submitting your CV (resume) in orange crayon aged 30, you have a problem (the same as someone routinely programming important code in BASIC at the same level of experience). But neither should you go and hunt down a quill and parchment to scribble the note that says you're out of toilet roll.
Some people can't understand that BASIC is *excellent* for teaching. It was *designed* that way, and beats 99% of mainstream languages for that. But if your company is still running exclusively off it in 2010, it's a bit like sending out invoices in crayon. However, even in a modern office, sometimes you just need a tool for a small, simple job and sometimes BASIC works fine there (in the same way that scribbling "pay the caterers" in crayon on a post-it is perfectly acceptable as an aide-memoire). There are schools that, without a bit of BASIC, or shell-script, or DOS batch file, etc. wouldn't be filing their accounts, or importing the new student-intake data each year, I know that. When the job is once-a-year, with changing requirements, with specific needs, with various "mental hacks" that have to be applied anyway (i.e. "we need to drop column X this year if column Y is less than 20 because that old law no longer applies"), and needs to be done quickly it can happen in any language you like.
I have taught BASIC only a year or so ago, to a top-class prep-school student, in a single one-to-one session, in a single afternoon. That was from *zero* programming knowledge (but a keen mind), exclusively on paper and the next day they were writing (working) games and hadn't required a single extra tool, library, download, reference or command-lookup - we ran them through QBASIC to see them in action but they worked perfectly. I have also spent several HOURS trying to clean up a single function written by a top-class MSc CS-student that had only ever been exposed to Java in order to find out WHICH of the several dozen syntax errors, scoping errors, operator-precedence errors, etc. was actually the main cause of their function returning junk. I could have taught them a whole programming language AND done the same job quicker than I could teach them to d
No, it's a worthwhile comment. He could have phrased it more diplomatically but it is a useful thing to know.
C, C++, C#, Java, Ruby, Python, assembly... - these languages and all others are tools. They go in the toolbox and are brought out as needed. Each does something better than the others.
Were I to write a VM I would use C as well. A good way to think of C is "user friendly assembly". This is an excellent language to use for an interpreter. For a VM you want SPEED. So you need something with as little baggage as possible. It must be fast, and C has that going for it. After primary compilation it creates asm files. So why not go straight to assembly? A VM is complex. For something huge and complex ASM is a little too fine grained. You want C. So C was used. Best tool for the job.
Writing a gigantic user space application? C may not be your best bet. A lot of those types of programs spend a lot of time just sitting there waiting for input. You may not need anything that optimized. A big fat high level object oriented language can be a better pick. That's where Java/C# shine. You can do a lot with the fat libraries that go along for the ride. The UI creation is simple. Lots of bang for the buck.
Match tool to task and you'll make better software.
Weaselmancer
rediculous.
And you avoid learning GOTO. I don't care how easy it makes initial learning, it's building bad habits that you're going to spend years killing.
Now what's wrong with goto? It's a perfectly valid statement when used appropriately, just like any other statement. What's wrong is this old dogma that tell young people to not think for themselves and instead just repeat what everyone else says.
Programming should NEVER begin with OO. If for no other reason than the cruft you need to add in OO languages before you can even begin to introducing basic concepts.
Objects are great when used appropriately. However, knowing how and when to use objects takes experience. Beginners by definition don't have experience.
"Pure" OO languages are even worse. When everything is an object, you don't have a choice about when to use them and, consequently, are much more likely to use them inappropriately. (Bad OO code makes you wish you were maintaining bad VB code!)
Sure, a good programmer can write great OO code, but such programmers are extremely rare -- You're not likely to find an introductory class full of competent and experienced OO programmers.
Having taught programming to many different age groups (from children to adults) I know from experience that OO is not the way to go. You can't just start off with structure -- it's totally inappropriate. They simply can't learn to structure their code until they're capable of writing some!
Teaching someone programming is a bit like teaching someone to think. A good teaching language should let you introduce all the basic concepts like direct sequencing, bounded and conditional iteration, conditional branching, variables and types, i/o, etc. without a bunch of indecipherable code cluttering up the program and confusing the student ("magic" just-ignore-this code does not aid in the learning process).
For that, the submitter is spot-on. Languages like BASIC and Logo are excellent introductory languages. All meat and no fat. I prefer Logo for children under 10, BASIC for everyone else. I've tried Java, JavaScript, C, Pascal, and even COBOL. Nothing stays out of your way like BASIC or gives you the instant satisfaction (crucial to younger children) like Logo.
Required reading for internet skeptics
I'd agree that interpreted languages (with BASIC and Logo being examples) are great for programming. The edit/compile/run cycle causes too much friction, discouraging kids from experimenting.
But having taught hundreds of kids programming, there's a huge difference between BASIC and Logo. Logo is a simple but powerful language that teaches kids how to express what they want to a computer. BASIC is a complicated but limited language that mainly confuses kids and teaches them loads of incorrect beliefs that make it hard for them to eventually learn to express themselves clearly. Certainly starting with BASIC can be recovered from (Dykstra was being overly dramatic) but I would advocate doing that to anyone on purpose.
Of the introductory languages that I've taught, I think that Logo was the best introduction, because it's the simplest, most natural syntax, with the ability to easily generate graphics that engage students. And while most people don't notice, Logo is a fully expressive programming language.
For comparable, but more modern languages that are good for introducing kids to programming, there is Scratch (http://scratch.mit.edu/), which is friendly and interpreted and visual. Also free and open source.
Reading the ClubCompy web site, they built something that is intended to be simple for kids to experiment, with no install, and thus is a "computer" interpreted in JavaScript. This seems like a nice idea. No real connection to BASIC or Logo, other than they want to achieve the simplicity and openness to experimentation that those languages represent. After giving it a look over, I like the fact that their language based on LOGO, but am not thrilled that they added LINE NUMBERS. I can't believe that it's a good idea to make kids learn about line numbers, with all of the associated complexity, rather than to use a simple text editor. The only reason that line numbers ever made sense is that back in the era when BASIC was invented, you couldn't assume a text editor, or even the ability to move a cursor on the screen (remember working on printing terminals?). But I think that limitation no longer applies. So while I like their goal quite a bit, I have a feeling that they would have been better off sticking with an existing simple language, such as python, lua, or even Logo.
Enable 3D printed prosthetics!
And you avoid learning GOTO. I don't care how easy it makes initial learning, it's building bad habits that you're going to spend years killing.
This is a common criticism - that you will spend 'years' killing the 'bad habits' you learned from using GOTO. I don't buy it. When I learned programming (on BASIC, back then, as a kid, that was 'the' language to learn on), and I progressed from GOTO's to subroutines, it didn't take me "years" to undo the "bad habit". On the contrary, the moment that I understood I had a better tool for so many jobs, I immediately started using that instead. Why would a programmer keep using a tool if it's much worse for the job? It just doesn't really happen. As soon as your programs get longer than a few hundred lines, or you want to start re-using code, you need something better than GOTO anyway ... it's really only useful on a very small scale, it is naturally self-limiting in use.
Also, I think GOTO's have one advantage for a learning language aimed at small children: It's easier for a child to learn and understand, as a building block / stepping stone toward more complex things. For some reason, I even remember this learning process (using basic, that was popular then) when I was a small child, on our 48K ZX Spectrum ... GOTO's were easy and obvious, but I recall seeing these weird GOSUB things that seemed more abstract somehow. But, once they were explained to me, it wasn't that bad.
Finally, any good programmer needs to do significant amounts of assembler at some point in his life, and you're gonna be doing lots of JMP's there anyway, and yet nobody considers that 'learning bad habits', because most people agree that learning assembler makes you a better high-level coder too, and there are reasons for that.
The criticisms against GOTO are largely exaggerated.
I have spent probably years cleaning up and maintaining other peoples really bad code. And yet, of all the horrors in the code I had to maintain, I don't recall once ever encountering a "GOTO problem" in the real world, where any programmer had made a big mess because they had learned GOTO's. Never. I've never seen it, and I wonder if anyone here has actually seen this mythical disaster that learning GOTO's supposedly leads to. There are many other bad habits that cause FAR more damage in real-world programming, and yet nobody even cares to teach those in formal Comp Sci or Engineering programs.