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...
Wow, this "story" is a really blatant advertisement for a commercial website.
No, BASIC is not a good language for much of any purpose, including education. Especially not the archaic type of BASIC they're using. Computer science really has progressed in the last four decades. Personally, I'd recommend Python as a starting language - it's easy to learn enough to do simple things, it's a well designed language that teaches good habits, and it's a "real" language that you won't outgrow as soon as you start writing anything beyond toy programs. But if you want a language designed specifically as a learning tool, there are lots of those that are a lot more modern and let you do a lot more than this company's offering: Processing, Alice, etc.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
I think Python is a better contemporary choice now (and I learned on structured BASIC - QuickBASIC)
There is noting inherently complex with OO, unless you already have a head full of linear or procedural programming that you need to get rid of.
A nice, stripped-down OO language - I'd sugest parts of java if it was a free language - would be a good start. Even a graphical interface, although they are undeniable useless for real programming, would be useful for starting off.
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
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.
Dear FBI, please stop by sometime later this week. As you can see, I am at home at 7:12pm CST. Thanks!
FTFY
"Going to war without the French is like going deer hunting without your accordion." ~General Norman Schwarzkopf
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.
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.
I might, if there were a simple, cross-platform, one-click-install download bundle for all of the major operating systems which included pygame and a decent IDE, and even then I'd target motivated 13 year olds as the youngest users.
You can run Python directly in the browser - no need for installs at all. In fact one of the motivations for getting CPython working in JavaScript was for things like this. (Note: It doesn't work perfectly yet, but all the hard work is already done.)
For a basic IDE, that demo includes Skywriter. Integrating some additional features like load/save etc. would make it very usable I think.
Regarding pygame: It would be possible to get something like that working in the browser, targeting an HTML canvas element. See this demo for C++ code written against SDL, compiled into JavaScript and an SDL implementation that targets a canvas.
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.
b) The leap in the reverse direction, to functional languages, is mostly a simple matter of wrapping blocks in headers and return statements.
Nay, no, notta. Functional languages make you think completely differently about how the computer operates. Simply wrapping things up like that is how you get spaghetti code. The budding programmer will tend to keep writing this way for a long time. Some never grow out of it.
If you start in a language with these two attributes, you're already 1 - 2 years into a collegiate computer science degree.
That's the biggest indictment of CS curriculums I've ever read.
Not a typewriter
I learned to program in BASIC, on an Apple ][+, back in the early 80's when I was 10 or 11. I loved it, but I started wondering how programs like word processors could access a large document in RAM, and work with files bigger than available memory, and other mysteries...which led me to learn C (with a classic Borland C compiler) at 15, and eventually to a CS degree.
In my case, BASIC (and I did LOGO too) didn't ruin me, it made me more curious and moved me into the more complex languages. When I got to college, data structures class was a piece of cake, as I'd already done linked lists and other structures while learning C, and I could easily deal with pointers and pointer arithmetic, multiple indirection, function pointers, and more. I feel a debt of gratitude to the humble BASIC language.
Just a couple weeks ago, I started teaching my son Apple BASIC from a web-based Apple BASIC emulator, hoping that he'll be as excited about programming as I was.
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).
10 INPUT "Who is poster?";A$
20 IF A$="plover" PRINT $A;" is a jerk" else 30
30 PRINT A$;" is not a jerk"
There are literally millions of programmers that cut their teeth on little 16K machines with basic in ROM. It stopped nobody from going on to OO languages. Dykstra was wrong.
--
BMO
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 suspect a lot of people, maybe not Dykstra, would point to the failure of Lisps to take hold in the marketplace as evidence that Basic has corrupted minds.
Don't blame me, I voted for Baltar.
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.
However the statement that "Programmers who've learnt BASIC tend to be harder to retrain in a modern object oriented language" requires statistical study.
Is C# "a modern object oriented language"? If so, then there's a dialect of BASIC that requires little or no retraining because it's functionally equivalent to C#, just with different syntax. It's called Visual Basic, and it's part of Microsoft Visual Studio Express.
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
Your right, programmers should always work in confined, carefully-constructed environment where there is no possibility of a program getting too large or too confusing - that will certainly prepare them for their first programming job - maintaining legacy spaghetti code, likely written in a "dead" language running on "archaic" hardware...
Ken
I worked for 11 years writing payroll applications in a version of basic. It powered a significant number of payroll systems in the UK and probably accounts for most people's wage slips even today. Now I write web sites in ASP, running VBScript. BASIC lives and will always have a place.
Pro Coffee Drinker
Procedural languages turn into a spaghetti mess.
Then what of OOP? When you get right down to it, OOP is just procedural with a heavy amount of implicit data indirection.
..and don't even get started on the more complex OOP stuff like polymorphism, because thats spaghetti 3.0.
The original BASIC's were spaghetti 1.0 while anything fully OOP is spaghetti 2.0
"His name was James Damore."
How did the author of AppleWin get the right to redistribute the Apple IIe's copyrighted ROM?
I don't think that Microsoft protects this copyright.
(What... you didn't know?)
"His name was James Damore."
As the owner of an HP calc, I have to say that what you say is not really the problem. The problem is and was inertia in the way math is taught. This inertia has led to "one way or the highway" with recommendation by HS math teachers everywhere for the TI-30 and its descendants.
Couple that with the *much* lower price point of the TI-30 compared to the HP "equivalent" (the 10 and the 15), the choice for a HS student to pick the TI-30 style calc is a no-brainer. The love affair with TI then extends into higher education.
Thus, millions of people never *ever* consider RPN. It has led to a stranglehold on the academic market by TI over the decades.
It took me to be out of school to even think of going to HP.
Personally, I won't go back to algebraic calcs. I even use a HP48 simulator on my desktop instead of the regular calculators that come with Gnome, KDE, or Windows.
HP has come up with algebraic calcs over the years. They are always inferior.
YMMV.
--
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.
Agreed, but I think Python is even better for that purpose - less things to deal with. And it has a decent turtle graphics library, which is a very good learning aid.
I think you proved my point eloquently.
John
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.
Modern versions of Basic have those. You know, Basic has also evolved just like many other programming languages.
Python treats whitespace as syntax.
Yes, and that's one of its stronger side. Using whitespace to delimit blocks of code is very natural to someone with no programming background.
That was demonstrated to be absolutely stupid 30 years ago.
It was?
At least the FORTRAN fucks had an excuse with punchcards
The way FORTRAN used significant whitespace has nothing in common with the way Python uses it, except for the fact that it's significant.
No offense, but take a breath
Judging by the overall tone of your post, you should really take your own advice.
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!
Saying that the smartest programmers you know "are the ones who know their low-level stuff" is not a very supportive reason for that sequence of teaching. All it says is that, when all is said and done, they had learned those things at some point. Did they start there? Did they end there? Who knows? Did they know those things because they actually had the interest to learn them for the same reasons that they are the best programmers you know? Is there, in fact, not really a causal relation at all?
I actually did think for myself when I rejected GOTO. I actually went back and read the "GOTO considered harmful" essay.
Can you provide an example of when goto is appropriate -- in particular, when it's appropriate to use a goto rather than actually structured programming, or even a safer option like break, return, or throw?
Don't thank God, thank a doctor!
The thing is, BASIC encourages use of GOTO, rather than being an unusual thing to use when unusual circumstances call for it. If they call for it.
Using goto everywhere creates code that rapidly becomes an unreadable, unmaintainable mess for anyone else trying to follow it.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
And you avoid learning GOTO.
What the hell is it with the BASIC detractors just making stuff up? BASICS with full structure have been available since 1982. That's 29 years ago. Seriously, loose the mullet and the walkman and join the present day.
SJW n. One who posts facts.
Yeah, ideologically Python is all wrong and should be terrible. Trouble is, when you actually come to use it, it's great. So religiously you're right, scientifically the post you replied to is right. Evidence beats dogma.
Quidnam Latine loqui modo coepi?
Editors are for wimps. Real programmers use Hollerith cards.
Quidnam Latine loqui modo coepi?
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.
Oh that's right. Copying and pasting is FAR more efficient. Cause when you find a bug in the original code, there's nothing easier than locating all the spots where you copied and pasted that code to make similar modifications.
XML is like violence. If it doesn't solve the problem, use more.
When the language is designed to have code run primarily in a linear fashion and doesn't (generally) nest the code into more than one layer deep, then a conditional GOTO is just the ticket for flow control. It's not 'harmful' any more than a hammer is 'harmful' - give either to a ten year old boy and he's going to make a mess, but used in proper context neither is particularly bad.
The funny thing is - all the GOTO bashing by the same people that salivate at the opportunity to throw random exceptions in their code, have them bubble up the call stack and get caught three calls up the stack. Guess what folks : that's the most gnarly and evil reincarnation of the GOTO most of us seasoned professionals have ever seen.
As for why BASIC is such a good beginners language - it has nothing to do with any of the above. It's about instant gratification - when newbies don't know the first thing about what makes a computer tick, being able to copy-type a few lines of text from a book and run it, then start tweaking it and seeing what the changes do - THAT is what hooks the new developer and gets his mind working. All this talk about OOP and high level languages - just scares them off. Get the fundamentals (the way, way low level fundamentals like what a variable is, that it holds a value, that the values can be changed and displayed on the screen, that you can do math on the variables) out of the way first - like showing a kid how to hold a hammer, that you only use it to hit nails on the head to drive them into wood, how the nails hold pieces of wood together - and BASIC is perfect for demonstrating those concepts without all the infrastructure surrounding bigger languages.
(And I can't believe I just defended the use of GOTO. Damn.)
Glonoinha the MebiByte Slayer
Javascript
It has a simple syntax, supports a number of paradigms, and practically everyone has an interpreter for it already installed. It also has a simple, robust UI framework in that interpreter.
You either have never used OO correctly or don't know what you are talking about. Copy and Paste to reuse code is the worst possible idea. You simply spread maintenance work and bugs through out your code base. Good OO lowers line count, maintenance time/cost and bugs. Bad OO like bad anything can be bloated and the ruination of a project. Modern IDEs and documentation tools allow you to find object and discover methods quickly and as you code. (Think CTRL-SPACE). Large systems with many developers cannot be built in the simple way you suggest. Some larger form of design and control is needed. It does not "need" to be OO but, OO can provide the necessary structure.
No sigs in BETA. Beta SUCKS.