30 years later, QBasic is still the best
nicolasbize.com
nicolasbize.com
Because of this, it might be preferable to introduce a child to the more linear, concrete programming model with goto and let them experience the thrill of programming then as they develop more and their programs increase in complexity, introduce them later to other more abstract methods and languages such as structured programming, oop, and functional.
(Probably not functional programming, though, since functional's not very good for games, and what else do you think QBasic is going to be used for?)
You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address.
I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.
Yes, this is a critical and valuable step in learning. You can't easily learn the solution until you've encountered the problem.
Can you elaborate on that? People have actually written games in FP languages ([1], [2]).
[2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen.
The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads.
In a way, this is a way of saying that functional languages are good for games, though...
meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game.
Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.
OOP is just an enormous win for games; I actually learned OOP with ZZT and Megazeux. Something simple like Pac-Man _might_ fit in a stateless paradigm, more or less, if you have a non-painful way to do I/O; but the more ambitious a game gets, the more it benefits from objects (including rule-processing objects).
MVC is also a good thing to use in gaming. For those who haven't heard yet: the model is the database and the deterministic, stateless parts of processing ("characters lose 1 point of nutrition per turn"); the controllers are the player's and any AIs' decisions (both are almost certainly stateful across rounds/timer-ticks); and the views are drawing the game (for the player) and giving a selective picture of the gameworld's state (for the AIs).
The statefulness is managable in FP generally, you could see things like the State monad in Haskell. After all, the current state is just recursive applications of the rules. Experienced users of the FP languages will feel at home
The high nesting that would end up in your data will probably mean you want to reach for deep data accessors and the like. This is managed through things like Lenses in Haskell. But that's an extremely high learning curve to basically get what you get for free with dot notation in so many other languages. If you're experienced in the language already, it's fine, but if you're just starting out in the FP language, and you had experience in iterative-style languages... ouch.
I really like the idea of applying MVC for game patterns. it makes so much sense! Going to explore that the next time I have the chance.
GOAL had a fast coroutine implementation written in it that enabled, among other things, autosave while the game engine kept running without a hitch in the Jak & Daxter series.
(Lisp also has terminology that's much easier to understand than Haskell. What exactly is a monad, again? And why would I care about monads when I already have Java?)
(And also note Bitwize's observation that GOAL is imperative with the option of doing a little FP.)
https://wiki.haskell.org/Applications_and_libraries/Games
I still don't get the "aggressively unhelpful for games". FP does not mean "no state", just that state is expressed differently.
(For the aggressive unhelpfulness of Haskell, I mentioned that Pac-Man project -- and see my other posts in this thread.)
What would those consequences be?
And people have written games in Erlang. [0]
The language even has some structured procedure/function definitions, though I didn't grasp these until much later. In contrast to control flow, which has lexical structure, procedure invocation has dynamic structure. This exceeded my abstraction ability at the time.
Probably the most important parts about QBasic were 1) it was easily accessible in C:\Windows\System32\qbasic.exe, 2) the interface was streamlined enough that I just had to hit F5, no need to figure out tooling, REPL-like, and 3) it gave an easy interface for drawing things on the screen, which is captivating.
(And as an aside: in no way did I end up with the brain damage Dijkstra would have predicted. Unless programming in Haskell and Lisp are symptomatic -- or maybe antidote?)
By the way, did anyone else use Klik N Play or The Games Factory (both by Clickteam)? I got a lot of milage out of them. They are essentially event-driven graphical programming languages for designing on-the-simpler-end games. I wouldn't have traded them for Scratch.
FWIW QBASIC is pretty advanced compared the the BASIC Dijkstra's comment was referring too.
For my youngest son I introduced him to awk first. In an editor he would edit the script and then run it in the terminal. I explained how every line goes in order. At first his script would output things like:
jake is awesome I love POTATO
but soon he was using $n, variables, arrays, and conditionals from one line to the next. I had some silly stuff I had already written for awk to make it work one keypress at a time and I created a little h -> awk project for him. Then he wrote a game:
https://github.com/msliczniak/jake/tree/master/games/letters
Just yesterday he said he wants to make it so that after every 100 points more enemies show-up.
A nice benefit to this is it is a whole lot like JS. That's the way to show-off for friends, I'm still mulling how to get him there though without over complexity. I'd appreciate advice.
Not that scheme is a terrible language.
"Creating Languages in Racket - Sometimes you just have to make a better mousetrap." http://queue.acm.org/detail.cfm?id=2068896j
Realm of Racket might be a good non-school introduction to programming. [1] I feel like How to Design Programs would be better suited for the classroom, whereas RoR is all about having fun.
[1] https://docs.racket-lang.org/quick/
[ed: Ie: one can't simply cut'n'paste from: http://el.media.mit.edu/logo-foundation/what_is_logo/logo_pr... and get pretty pictures, one has to manually compile (or transpile if you will) from Logo to Scheme first. Which is obviously a job for a computer, not for a brain.]
As if that were not enough, it is lightning fast, small, and powerful. When Aho, Weinberger and Kernighan invented AWK, their intent was to invent the next generation C, without having to allocate memory or deal with pointers or data types, and in that, they were a success. AWK is C on steroids.
How do you do graphics in awk? If you don't then using js and one of the html5/canvas based game engines might be a reasonable step forward.
In any case I spent some time on it tonight for my son. I've made a little html file that is a nice harness for him to write JS so he does not have to know much of anything other than innerHTML.
https://github.com/msliczniak/msliczniak.github.io/tree/mast...
Phaser is a pretty decent "batteries-included"-style engine (definitely easier to use than pygame, despite js not being as nice as python).
A good summery/list in general can be found at https://html5gameengine.com/
For now I've thought a bit and it would be pretty easy for me to abstract sprites and text drawn to a canvas with clicking and keypresses so I think I will do that first when the time comes. My youngest son was EXTREMELY happy this morning and began porting letters2player to JS before school.
All the constructs you mentioned have an almost trivial mapping to assembly language.
For reference, the Microsoft BASIC 7.0 implementation contained about the only implementation of a GUI (text mode) framework that did not use pointers to functions. The result was something that worked, but had immense amounts of repeated complexity and boilerplate code.
30 years ago you turned on, and in seconds were at a DOS prompt. Now you had to load something, to do just that. A C64 or other 8 bit turned on instantly to BASIC. Everyone could program enough to make scrolly insults of their sister or swear and beep on the demo machines in the store.
All the improvements have added layer on layer of insulation from the tedious guts, which is great when you just want to work, web surf, write a mail or play farmville, and the machine, even a phone, takes ages to boot.
It's terrible for kids in my opinion - all the things that would feed their natural curiosity are just not there. What's there instead is appstores and notifications reminding of social messages and games to play.
I made a heavily curated PC for the kids and they were able to do remarkable things in paint (the youngest could do more with paint at 6 than I ever could) or build little programs or make tunes in something that looked like an old tracker. Best part, they did it nearly all themselves.
It's a shame for the next generation we've mostly reduced all tech to consumption only devices.
Then they hit teen and just got addicted to WoW anyway. :)
I use LG auto switchers to connect everything so anyone just has to turn on the equipment they want to use. On top of that I also have an av switch reversed so one can choose between the big screen or the crt.
My kids proved frogger is just as addictive as 30 years ago! :)
Mid spec, but old, games machine (mum or dad's old one after an upgrade).
Spent a bunch of time locking down what was in windows, what damage they could do (like deleting icons, menu items, random important things). Weekly restore from FreeBSD box. Uninstalled or removed visibility of pretty much anything that could do damage. :)
Mostly it was things that came up as they happened, and experience supporting non-tech friends and relatives - causing chaos uninstalling the wrong things, installing kazaa or whatever.
s/w wise I found a Logo (turtle graphics), Basic, couple of other languages, Amiga-like Music tracker, couple of graphics things to complement MSPaint, MAME with some classic games, a few infocom adventures and a couple of newer games for the Z interpreter (Infocom games not as popular as I thought they might be), a crossword puzzle and a few other logic/tile arrangement type puzzles.
Overall it was a great success - we didn't really need to teach anything.
Qbasic has subs and functions, so structured programmig is entirely possible in that environment. Additionally, it isn't compiled -- every time you move your cursor off of the currently edited line, qbasic converts that directly to bytecode for interpretation later.
This isn't the 1988 PC BIOS basica.com. :-)
First, I think it's really cool that he's exposing a young mind to programming. But I'm also old enough to have installed QBasic from floppy disks and part of me thinks his statements I quoted are romanticizing QBasic a little bit.
I think that Javascript in today's browser is a fine substitute. I've had good experience with children that age by going to the browser, pressing F12, go to Console tab and start typing code. It can start as simple as:
alert("hello world");
What I like about the Javascript-for-kids approach is that it shows them that programming isn't some other universe where you install QBasic in a vm. Instead, the initiation into programming/experimentation is just 2 keystrokes away. There's something about the immediacy of F12-Javascript that keeps it from being an esoteric dark corner. The kid can also get more mileage out of his "programming" knowledge because he can use his Javascript console tricks at his friend's house on any web browser. On the other hand, playing with QBasic today is more isolating. The use of QBasic in 1980s had more utility because the syntax of '10 PRINT "HELLO"' also worked on Apple II, Commodore 64, Radio Shack TRS-80, Texas Instruments TI-99, etc.
The problem is that as soon as you go beyond "write a series of statements and run them" and in to actually trying to write something interesting and fun with a little abstraction or actual software design then JS very quickly stops being a good choice. You can quickly hit synchronicity problems, weird scoping issues, data typing difficulties. Those are things that could easily frustrate an interested person.
A hour or two of JS as an introduction followed by learning a BASIC variant is probably a really good bet.
No. It's a language to scare - and scar - young programmers for life.
myArray.forEach( (item) => {
// process item
});
for (item in myObject) {
// process item
}true == 1 → true
true == "1" → true
false == 0 → true
false == "0" → true
false == undefined → false
false == null → false
null == undefined → true
"\t\r\n" == 0 → true
"\t\r\n 16 \t\r\n" == 16 → true
"\t\r\n 16 \t\r\n" == "16" → false
var a = "foobar"
var b = typeof a → 'string'
var c = a instanceof String → false
I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier.
That said, there is a logic behind that. Days we usually represent with numbers. Months we often represent with names. So the month numbers are returned as an index of a sequence of names. (Not saying I like this logic, but it sort of makes sense.)
Continuing forward with bad designs doesn't absolve you from them, though. Plenty of languages avoid this--look at how .NET handles dates and times, it has no real relation to the underlying OS on either Windows or *nix.
When I taught my daughter about programming I actually installed an old copy of Visual Basic 6.0 and it was really good for that. You draw the UI and the interact it with it mostly procedurally. She created a small useful application out of it. It's kind of crazy that in 2016 all our programming environments are more complicated than VB6.
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import turtle
>>> turtle.forward(100)In Python it'd look like
@GtkTemplate("my_window.ui")
class MyWindow:
@GtkChild my_textbox
@GtkCallback
def button_clicked(self, btn):
my_textbox.text = "Hello, World!"I've been thinking of switching over to some other environment the next time we do that. The immediacy and integration into an environment he already uses every day are compelling advantages, and it'll be a shame to lose them. But it does feel like the downsides easily outweigh the benefits.
And then there's interfacing the other way around, which the Canvas doesn't help at all with or makes even more complicated. It's somewhat easy to explain an onClick handler for a HTML button; doing a useful onClick handler for a canvas, or body-level onKeyDown handler are again much more complicated affairs.
That observation is fascinating to me. Isn't it possible that we're judging it with adult eyes? To me, kids can filter out "ui complexity" that's not relevant to whatever exploration they are doing. Examples I think of:
A microwave oven[1] might have 25 separate buttons on it but a 6-year old will know the 2 buttons to press to heat up the popcorn. Yes, the keypad complexity handles more advanced techniques of 2-stage cooking with different power levels etc but the child just ignores all of that.
Or, how many of us grew up with those multi-component integrated stereo racks?[2] The front panel has all those buttons, sliders, knobs, and lights. And yet, a small child knows how to turn the FM knob to find his favorite radio station or rewind a cassette to replay a song.
I also see video games[3] that 6 to 8 year olds play (even if the game wasn't intended for that younger age group). To me, the screenshots show a complex "dashboard" at the bottom of weapons or other status. (I'm not a Starcraft player and it all just looks complicated and confusing to me.)
I think kids can look at the "complex" F12 screen the same way as microwave ovens, stereo receivers, and Starcraft screens: ignore the non-relevant UI elements and just type "alert ("hello");"
[1]https://www.google.com/search?q=microwave+oven+keypad&source...
[2]https://www.google.com/search?q=integrated+stereo+rack+turnt...
[3]https://www.google.com/search?q=starcraft+ii+screenshot&sour...
This is what I miss about older technology - especially dumbphones. The input always worked, and always worked with the same timing. I could operate my Sony Ericsson K800i without looking at the screen because my brain memorized the sequences of buttons and timings of common operations. Joystick press, up, up, press, down, press, wait about a second, press, done. Compare with Android phones which routinely ignore or misinterpret input ("that was a swipe, not a press!"), and hang at unpredictable moments for unpredictable amount of time (usually also ignoring input while hung).
(At least every microwave I ever operated was pretty loud when cooking.)
Most of appliances provide functions expected from devices of their class and follow obvious patterns that you quickly internalize. I have a running bet with my friends that I can operate any electronic appliance without a manual. The hardest case I've ever had so far was setting the clock on a microwave that provided alternative functionality under "START" button when the oven doors were open. It took me a few minutes to crack that one.
[0] - https://xkcd.com/627/
I believe the timer is clockwork.
Touch-sensitive membrane buttons like the ones the use on the front of microwaves are much cheaper than mechanical timers.
$c00000 - FAKE FAST LOCATED
What miss most is using tools like ExoticRipper to grab music modules from memory after reset, to then play them at leisure and examine/change them with a tracker. Or playing around with the "Action Replay" modules I-III, that blew my mind too. Making a pause toggle by connect the mass of the case to a specific pin of the extension slot, haha, I was so scared doing it and so shocked it actually worked. I may not have learned so much I ended up still using (except today I prefer Renoise to all other DAW), but I sure learned a lot about learning, that is, wildly poking around to figure things out.
I decided I wanted to learn to "program" when I was 8, but I had no mentors, and no adults I knew could tell me how programs were made. I found QBasic lurking in the C drive, and got some books from the library, but without anyone to help my 8 year old brain couldn't get far alone. I got it to switch resolutions and draw some static pictures, but nothing else. I was frustrated.
Eventually I found and started playing with Games Factory, then Multimedia fusion from Clickteam, which is is sort of related to this, programming without typing. It was something my 10-year old self could understand on its own! I got a solid intuition of thinking in logic, and. Being able to set up some crazy causes and effects myself was really exciting. I made some "cool" stuff, for a 10 year old.
Once I found that limiting I tried to learn text-based programming again and by that time I was able to read code and puzzle out what it did from the concepts I learned. Maybe being a couple years older helped too.
I can't stand using tools like that as an adult, but without visual programming, I probably would've given up. Yet I paid my way through college writing Java/AS3/C, and now I made a living in games.
Almost almost all modern programming environments, including JavaScript in the browser, require a lot of work to produce a simple visual.
However, Scratch feels like it does too much and becomes more like solving puzzles rather than creation.
You could create GUIs and easily share self-contained exes with your friends. Also very cool was the documentation, complete, offline and and with lots of examples.
I initially got into programming through Apple HyperCard/HyperTalk on the outdated school computers, but it was rather clunky and limiting in what you could do without going through the C interface.
I think 'online' [1] is the word you wanted to use. ;)
I think you can still download the whole MSDN help library for offline use, but I don't believe that nowadays that would be enough for daily work use. Lots of useful info and example use is scattered around blog posts and StackOverflow answers now, instead of being a part of the documentation itself.
Not really. The VB6 exes required a huge runtime to be installed. Plus all the visual controls lived inside of OLE DLLs als native code and you had to ship these too (and register them on the target machine)
This was the biggest motivator for me to move to Delphi because that actually produced self-contained exes and allowed you to call any Windows API directly without any COM wrappers in between.
And you had a real type system. And pointers. But you still had an easy GUI editor and a very good class library that was incredibly easy to use.
I've since learned a few more languages, and I don't particularly enjoy writing complex JS programs, but I'm very glad it was there when I got started.
How's that?
var drawing = document.createElement('canvas');
document.body.appendChild(drawing);
var ctx = drawing.getContext('2d');
ctx.beginPath();
ctx.moveTo(0, 0);
ctx.lineTo(100, 100);
ctx.stroke();
SCREEN 13
LINE (X1, Y1) - (X2, Y2), COLOUR2) typing your code (on this page) ... nothing happens. Element was added at the bottom of a very large page, element was not visible, so I didn't see anything happen.
3) the added element is a white box on a white background. Grand total indication of it getting added was a small adjustment in the (hidden by default) scrollbar on the right of the page ...
4) after that you want to start people out with paths and stroking and state storing and evaluating ?
Making a program like this that responds to keyboard input at all in javascript is dozens of lines, and you have to know DOM, properties, and event handlers in addition to the base language to make anything happen. Getting keyboard handling good enough to have a simple game ... let's not go there. Hundreds of lines. And of course, doesn't work on your friends machine (different browser ...).
I hope you can see that this is less than optimal to get people exited.
I am one of those guys that thinks web programming sucks, that it's far inferior for most programs as compared to Qt/QML and even to Delphi/VB like languages.
The howto could be a whole lot simpler it seems, see this example, helpfully provided by neckro23 https://news.ycombinator.com/item?id=11637866
http://www.bing.com/search?q=sarcasm
I sincerely wish that the post you linked was sarcastic as well, but it was probably serious which makes the (former) QBasic programmer in me a little bit sad.
I thought it was a well intended explanation that just wasn't detailed enough.
data:text/html,<svg><line x1=0 y1=30 x2=40 y2=50 stroke=black>
line(0, 30, 40, 50);
There are also clumsier ways to draw lines, like with DOM manipulation in SVG or drawing stuff on a <canvas>, and those might be desirable for the extra flexibility they give you. But you don't have to start with them.
Depends on the browser. IE > 8 doesn't support it.
[0]https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs
I cannot think of a more complicated way to introduce someone to programming. Yes, you can use `alert` and print things, but that's about where the ease of interaction ends.
However, like many others, QBasic was not my first experience with a BASIC language. Prior to that was GW-BASIC on PC (it was part of our introductory course to Computers at high school), and before that was Sinclair BASIC, which I learned in part from a book called "Peek, Poke, Byte and RAM"
http://www.worldofspectrum.org/infoseekid.cgi?id=2000269
But my first encounter with a programming language was Logo:
https://en.wikipedia.org/wiki/Logo_(programming_language)
I'm sure there was a BBC Kids show that featured Logo programming (yes, they drew shapes with the turtle), but I can't remember the name. What I liked about Logo was that, as a child, it seemed very intuitive, and I felt like that even without having touched a computer I knew what programming was about, which is a lot more than I can say for any other language I've worked with.
After loosing my memory, I have to relearn programming nearly from scratch. I took a challenge to do specific program in around an hour, from language to toolchain to solution. Had to be system-like language. Got bogged down by toolchains, IDE's, whatever. Said screw it: why the hell is it so hard when I faintly recall starting lightening-fast on QBASIC? Found a BASIC, FreeBASIC, that was just like it with simple command to launch stuff made in text editor and good documentation. Maybe half an hour of my challenge gone.
Next, time to apply lessons I remembered from high-assurance and Wirth. First, subset the language to minimum necessary. Used docs to test each in isolation to develop template & functions for using them, esp file I/O. Wrote formal spec in English & pseudocode of my problem with decomposed functions. Mapped almost 1-to-1 to FreeBASIC as expected. Did one refactoring. Executed code for first time to see successful run & solution to problem.
Yeah, BASIC is friggin awesome. I stretched industrial BASIC's, esp 4GL's, really far back when I was a hacker as they did rapid iteration, safe-by-default, and ran fast. Today, I'd say do a Wirth language like Oberon or Component Pascal instead. Still, BASIC has lessons to teach us and a painless bootstrapping for developer that many modern tools lack outside of scripting.
Wow, so you forgot how to write code? May I ask how that happened?
But, yeah, lost most memory except stuff I repeated most along with muscle memory anx hand-eye. (Shrugs). Supposed to be thoughtless drone but I do well here on many topics despite working with pieces and little short-term memory.
Since then, although my condition hasn't changed, I've at least pursued that hardware research to get very far. One thing was finding where SW and HW connect with those FSM's as I predicted. Already have 2-3 methods to express software that (a) can integrate with verification tech and (b) can auto-generate hardware from it. So, slow but steady progress toward grand challenges and such. :)
My first QBASIC/FreeBASIC program I've managed to write some 15 years ago: https://bitbucket.org/tarballs_are_good/nibbles-and-bits/raw...
FreeBASIC has multiple dialects; there's the qb dialect that supports most of QB except some audio and real-mode DOS-related commands, and the modern fb dialect, which is all of C plus half of C++ with BASIC syntax. And it does improve on C and C++ in several ways, like much better string support and a "preprocessor" that looks like the C preprocessor but is far more powerful (it's not a preprocessor, so it knows about types and variables, etc).
Of course it's not better than QBasic in every way: it's not interpreted with that awesome edit-and-continue ability that QBasic had. And the compiler can be quite buggy.
There are also a number of other QB successor languages, like QB64, which has a focus on the QBasic IDE and supporting all of the audio-visual stuff QB had fully. But (after comparing the codebases) will say FB is written far more like a professional product.
That efficiency on arbitrary hardware is something industrial BASIC's and Wirth languages have in common. Only Go can touch it these days but still not low-level as Wirth stuff gets.
I learned to program in 2004 in QBasic, although I very rarely fire it up anymore. By then it was not considered a "serious" language and we all knew it. But that meant the stakes were a lot lower. It's a lot of newbies and a few old-timers who do things for fun. This makes things a lot less intimidating for the non-coder. There are no conferences, no corporate sponsors, no polarizing big-shot Twitter personalities. It's a realm surprisingly insulated from the pissing contest of modern engineering culture and technical progress, where things that are acknowledged to be easy in other languages are nonetheless praised as impressive when done in QBasic.
Another thing is that QBasic has no decent library functionality for code reuse (QB4.5 has a linker but no one knows how to use it). This means people constantly reinvent the wheel, and they aren't told not to. People copy and paste snippets of code and learn how they work, but they don't build ever more complex mashups every year. Thus, you're not on the framework treadmill or starting 5 years behind the curve. Things are done simply and idiosyncratically, pretty much the same way they were done in 1995 or 1988.
Makes me nostalgic just thinking about it.
I agree with the blog author, and I still think it's the best language to learn programming. Everything else is software engineering, and gets in the way of the instant gratification that got so many of us hooked on programming.
What's wrong with starting with BASIC like I did, writing increasingly complex code, getting frustrated with the resulting spaghetti, then learning to use GOSUB more, which then gets you ready for a procedural language like Pascal? At least this way you know why pros don't code in BASIC. The same path of frustration (and fun) can also be used to go from Pascal to an OO language like Python or Ruby.
And for the record, I don't think using gotos as a child sabotaged my ability to write structured code later in life. "GOTO considered harmful" gets taken way out of context!
GOTOs are certainly not harmful on their own. But they offer a power that leads to unmaintainable and unreasonable [0] code. Like the spaghetti mess that is callback hell today. Languages which offer structured constructs that are really just syntactic sugar over GOTOs are better [1]. Structured use of GOTOs are feasible. But it requires a discipline that is not found in the community at large. If you're responsible for any project involving more than yourself as the developer, you cannot assume that discipline is present.
With regard to assembly, yes, the branching and jumping instructions are the gotos Dijkstra was talking about. No, he wasn't wrong. The thing is, they have to be used in a disciplined manner or the outcome is extremely fragile code. Which was one of his biggest hobby horses. He viewed programming as a branch of mathematics. Where programs could be derived from first principles. GOTOs, as commonly used, necessarily broke that process. They also make it nigh impossible to understand poorly disciplined code. Same thing with magic numbers, weak type systems, and a number of other topics. They aren't bad on their own. They're bad when used in practice because they make undisciplined code trivial to produce.
[0] In the sense that the code cannot be reasoned about.
[1] In a strict sense, they're equivalent. In a less strict sense, they remove or minimize the ability to make unreasonable [0] code.
I disagree with this statement. "Learning" is a long process of acquiring and also discarding habits and knowledge. The best intro I ever read for relativity was "An Equation That Changed the World" and it's a series of dialogues between Newton, Einstein, and the author (a modern physicist). Newtonian physics is relatively (haha) easy to understand. Once you understand that and then you can throw in some edge cases where it fails, you can introduce relativity and it makes relativity much easier to grasp.
Likewise for programming. I learned with QBasic. Then as the code got messier, I started using "sub", etc. and then started playing other concepts until I outgrew the language. Functional programming came to me the same way. I outgrew my existing methods and reached for more advanced ones.
All this is to say it's OK to start with easier and imperfect methods. We learn by acquiring new knowledge and then knowing them well enough to see their flaws before moving onto something better.
But coding isn't like that. Sure, GOTOs as a means for control flow, suck for most serious applications compared to the readily-available alternatives, it's not like you can't build your own control flow mechanisms with their own properties out of the GOTO primitive, and learning how these work and fail is really good practice.
Time spent mucking about doing the wrong thing in coding teaches you how to ascertain the right way. Other skills don't necessarily offer this.
The arts are mostly practice led, so there are efficient and comfortable ways to get an expressive result, which may not be intuitive or obvious to beginners, and which probably need to be practiced.
But plenty of people pick up instruments by experimenting, and some of them go on to have successful careers - because results matter more than technique, and if you're getting good artistic results perfect technique is secondary.
And I think the GOTO thing is overblown, and misses the point in exactly the same technique-vs-outcome way.
The desired outcome is legible, maintainable code. If you bracket a thousand lines inside a single if statement, you're not any closer to that aim than someone who uses GOTO.
What's missing from BASIC - and from any kind of training that's syntax-based instead of concept-based - is that sense of using structures to simplify and highlight program logic and flow.
PASCAL was fairly new when I was learning to code, and it was billed as some kind of magical mental training tool that would eliminate bad habits and make you a better programmer.
In fact it's just a vanilla C-family language with a few quirks, and the mental training side of it was always wildly oversold.
Currently no language at all teaches separation of concerns, chunking, relative abstraction, DRY, and other fundamental concepts in an accessible way - and there should be. Because they really can help turn hard problems into simpler problems, and make all kinds of challenges more manageable - which is more fundamental to programming than knowing that POKE 53280,1 will make the screen frame white on a C64.
[1]http://www.stuffaboutcode.com/2014/05/minecraft-graphics-tur...
Electrical Age doesn't have computers. (Yet; I'm working on a PDP-11 simulation.) But it does have a functional DC electricity simulation, and "signal processors" that let you do amazing things with simple functions, as well as OC integration. If you're interested, I could show you around the setup on my dev server.
(Or you could join. High quality players are always welcome. And of course we've got both mods, if you want to experiment... :)
Plus who doesn't love writing software to create spirograph graphics.
I think I'll fire it up again this weekend - any hints?
Turtle Geometry: The Computer as a Medium for Exploring Mathematics
http://www.amazon.com/Turtle-Geometry-Mathematics-Artificial...
...and I've not yet tried it, but netlogo sounds interesting.
Coming from GWBasic, I knew it was not supposed to be the best language ever. I had been using Turbo Pascal, and knew the IDE to be great, and the language more structured. I was also using C, and knew it to be fast.
But QBasic was better where it mattered to me.
When I learned to tame it - to name things accordingly (variable names could have dots!), to not use line numbers or GOTOs, it was so easy and fun doing anything in it.
I could press F2 to jump to any function/method declaration I needed. I could press F1 on any method to quickly jump to its declaration/help, and then navigate help in the same manner (it was all hyperlinked!).
I could stop my program in the middle of the execution so I could issue inline commands, print vars, and even CHANGE it, before continuing execution... even today, with proper debugging/logging any modern IDE/platform provides, I never got a dev/test workflow as easy as that quick iteration cycle that QBasic allowed.
In time I started using QuickBasic instead (not the same thing!), learned to call interruptions, create actual executables, and do all kinds of crazy stuff most people were not supposed to do from there. Sure, running assembly from it wasn't as easy as Turbo Pascal (where you could do it inline) but as long as you had a library of common assembly calls created, it was just a matter of reusing it.
The language wasn't fast, and the compiled files were a bit bloated. In time I moved to something else. But I still miss the intimacy I had with the editor and the language. It's like a first love, the one that got away.
Scratch https://scratch.mit.edu/
CodinGame https://www.codingame.com/games
Squeak http://squeak.org/
Logo (even in browser https://turtleacademy.com/)
JsFiddle if you want to go for somewhat longer javascript https://jsfiddle.net/
Alice http://www.alice.org/
And it supports both a text mode (with a "write string at grid position" operation for easy game making - text mode is a must on the CPU-starved TI-84+) and a graphical mode, with tons of stuff to do in both. For example, in high school I had a program that accepted a string of "DNA" and used it to repeatedly call the built-in pattern-drawing command with different arguments, producing a mosaic of overlapping patterns, so that each different input string produced a different final pattern. It's like 4 lines of code and kept me endlessly entertained in class.
And that brings me to its greatest advantage- its presence in the math classroom. In middle school and high school, math for a gifted student is boring as death, and you've got a little BASIC interpreter sitting right there on your desk. You can transform hundreds of wasted hours a year into productive learning time.
But why is it that the rate of failure in programming projects hasn't fallen?
I've heard it said that the computing world in general operates on the edge of acceptability. As soon as the browser became fast enough to become an applications platform, we implemented the browser in the browser; as soon as good command-line interfaces develop, we replace them with bad windowing ones; as soon as dumb phones become a mature technology, we all move to highly experimental smartphones.
This is probably most severe in programming itself, where our field's most free to make its own choices. The percentage of projects that fail remains more or less constant as our level of experience grows -- because, as we become more experienced, we move to more complicated models. Any modern programming shop could churn out successful COBOL waterfall projects at a rate of two or three a year; so, as we got good at waterfall and old languages, we all moved to Agile and OO. Then, once we developed dangerous amounts of expertise in Agile and OOP, we moved to the Web (and lost most of our ability to use IDEs). And now, with even Web programming in danger of becoming a mature discipline, I'm hearing a lot of talk about Haskell.
Why does this happen? I don't know -- because I don't feel the temptation to do it. I program in C++, and I carry a feature phone...
My first introduction to programming was QBasic in the 90s, and I had a great time making little pictures, beeps/bloops, and text on the screen. I then moved on to some basic Fortran and other engineering-type languages in undergrad c. 2006. My impression of the workflows for Fortran at that time was "this is more annoying than BASIC, but I guess its because its more powerful and complex. I bet they'll fix the awkwardness eventually though."
Imagine my supersize when I decide to pick up the trendy modern language of Haskell in 2015 and find out that installing, configuring, and working in it was just as bad as Fortran back in 2006. WTF has everybody been doing for the past 10-20 years?
It seems to me that because programming is a new discipline, lots of people are trying to reinvent wheels. There is nothing wrong with this, in and of itself, since we'll essentially be making sure that we get really good at making wheels and end up with really high quality specimens. The problem is that wheels by themselves aren't that useful, and no one is bothering to make an automobile.
QBasic might have had square wheels, but at least they felt attached to something.
There's a lot of truth to that. People are blazing forward, without even looking at the past that's beyond the most recent trendy languages and frameworks. End result is that there's a lot of wheels reinvented, but poorly.
Learning Lisp was a particular eye opener for me. It was a gateway drug to discovering that there were so many things, so better thought out than what we have now (maybe because people did actually think about what they're doing back then, instead of releasing glorified CRUD apps "early and often"), and we're only sometimes slowly reinventing them.
https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgo...
They have mostly been touching and stroking themselves by inventing a new programming language every 15 minutes, rather than sitting their asses down for ten years, mastering one language properly, and then squeezing the living daylights out of it in performance, simplicity and efficiency... nope, that requires actual work, it's much cooler to invent yet another way of doing the exact same thing: wheee! Look at me, I invented yet another language!!!
THAT is what they've been doing.
I've get a lot of the start with JS comments. But that would be the last thing I do. As a child learning, you need to remove the complexities and distractions of a modern system. Windows, browsers, edit js in one app, run it in another, use a mouse, open the js debug console, etc. Just wayyy to much stuff for a young mind to try to focus on.
Don't get me wrong, they probably _can_ learn js, but after decades of programming in all kinds of different languages, just because js is the latest fashion, doesn't mean I'd every try to teach it to a kid. No way.
BASIC, on the other hand, was created _for beginners_. I learned A LOT over the years when I was using BASIC. I also had magazines (COMPUTE! & Gazette) and books that helped immensely. I was just thinking yesterday actually, that it was awesome having the C64 Programmers Ref Guide that had the machine schematics and port pin outs in it!! You'll never get that for a Mac or iPhone nowadays (and these sorts of things usually only show up on 'hacker' sites). This was a book put you closer to the hardware so you could more easily understand what PEEK and POKE really did. :D
I'm _really_ looking forward to the instruction days. The C64 was so popular for a reason: it was powerful & simple. This is how I want to introduce my kids to programming. They'll figure out Ruby, JS, C and things (maybe 8-bit assembly too!) later.
I loved my C64 (still do) and I hope that will rub off on them. Can't wait.
Keep in mind that most young kids can use modern technology very easily. My son was easily navigating around computers with a mouse at 3. I had him playing old ScummVM games at 4.
> BASIC, on the other hand, was created _for beginners_.
Yes, but C64 basic was also created when hundred dollar machines had 64k of RAM. And it's pretty painful to use. Not everything about it is just for beginners, it works a certain way because of hardware limitations. You might have forgotten that variables can be 80 characters in length in C64 basic but only the first 2 letters matter (Index$ and Input$ are the same variable).
I've got a Raspberry Pi and if I wanted to go the small locked down computer for programming route I'd probably use that. Get a nice display and keyboard and not mess with technology so obsolete that there is no upgrade path.
And then there's this: http://www.lexaloffle.com/pico-8.php
I spent hours and hours making stuff written for DEC/MS-BASIC work on my TI-99/4A with its limited language implementation..
https://en.wikipedia.org/wiki/BASIC_Computer_Games
PDF: http://bitsavers.trailing-edge.com/pdf/dec/_Books/101_BASIC_...
I had the later yellow-cover edition myself.
I volunteer at a local Coder Dojo and there's nothing to give these kids who want to fiddle around like that. Scratch is the closest I've found (with the bonus of not having to necessarily be able to read or type), but it's still cluttered with logins and passwords... and, being a GUI, it suffers when the kid's computer doesn't have a big enough screen to manage the complexity they eventually create. It's a shame. I tell kids who've grown tired of Scratch that they can "graduate" to Stencyl, a game engine that uses a similar visual programming metaphor but lets you drop down to the Haxe beneath. It also compiles natively to desktop or mobile, so that's cool too.
Python, ruby, and JS are all really close to the ideal "type and go" environments, but they're also littered with speedbumps. Installing packages and keeping the environment sane are difficult enough for some professional engineers, let alone kids who just want to mess around and make cool stuff.
The woman who started my local Coder Dojo got her son started with his own Linux computer at a really young age and he's a whiz at it, so maybe there's no real problem here and I'm just underestimating the ingenuity of these kids. They'll get it done if they really want it, I guess?
EDIT: Kinda apropos, but check this out! http://beagle.applearchives.com/the_posters/ I would've killed for these posters when I was a kid.
https://www.raspberrypi.org/blog/celebrating-50-years-of-bas...
Seriously, play gorilla.bas. It's one of the best games I have played.
I personally liked modifying nibbles, for instance adjusting the timing loop so it'd be playable on a modern computer. On some occasions I made a special key which would put the snake on auto-pilot (just towards the goal, no graph search or anything), or which would temporarily turn off collision detection. Somehow both of these were possible without really understanding how the whole program worked.
There is newer, multi platform implementation called QB64 http://www.qb64.net/
I wouldn't start kids on Basic now. My daughter is learning Simple Basic at school, but we use Macs at home and the only way to run it is in a Silverlight container. All the variations of Basic I know of are too restricted. Don't get me wrong, Basic back in the day was is a fine learning tool. The fact you could PEEK and POKE memory and DIM arrays actually taught you low level programming and system concepts that are abstracted away by modern languages and environments. Those early Basics were truly suspended part way between high level languages and machine code.
I appreciate the advantages of JavaScript, but also it's flaws. Learning to pop up alert messages is a cool hack, but beyond that it gets messy fast.
Scratch is fantastic. It's cross platform, can run in the browser and specifically designed to be very visual and intuitive. You can watch the code run. Brilliant.
Beyond that though a learning language needs more. It needs to be cross platform, support both procedural and object oriented forms and be capable of text, graphics, UI and web programming. For me that means Python. It helps that I've got pythonista on my iPad and phone. On the desktop there's also Jupyter notebook.
At the end of the day though, teach what you know and what you enjoy. All the technical arguments in the world can't beat passion.
If you want to teach a visual person like myself programming and the programming environment requires more than one statement to put something on the screen (including import statements), it has already lost to QBasic.
Once a kid might want to move up from that to solve perhaps more practical problems using PCs, I think a combination of bash (including basic usage of rsync, crontab, grep, sed, find, wget, ssh,...) and maybe VBA/Libreoffice Basic can take you a long way. (You can easily make nice little form/button based applications by dragging and dropping in the office suites. Also check out http://excelunusual.com/ for some inspiration on things you can do in VBA which I would not have thought practical!).
I learned code from QBasic and its help because books were in short supply at the library and there was no internet for me.
As much as Xcode or VS or Qt creator are great tools they seriously lack in that regard, as do most modern development environments. QBasic is very easy to learn and easy to use - and trying to solve hard problems with it requires some genuine skill and ability...
I learned to programm with BASIC [0] before on a Spectrum ZX clone, however that GORILLA.BAS [1] was a good programming lesson. I remember even now, after 25 years, figuring out the algorithms and the parameters of the flying banana.
[0] https://en.wikipedia.org/wiki/Sinclair_BASIC [1] http://www.jefflewis.net/archive/programming/gorilla.bas
[0] http://smallbasic.com/ [1] http://smallbasic.com/program/?TETRIS
I managed to make it solve second-degree equations in less than 33 steps (using the RST jump to re-run part of the program on modified data). Without the trick it'd require, IIRC, 35 steps, which were beyond the limits of that model.
I've toyed with writing my own GW-BASIC interpreter for yucks (because I've never written an interpreter) but never gotten around to it. Perhaps I should... I've been meaning to learn Rust, maybe that'd be a good excuse?
It's a fortunate thing to have common interests with your child. I can't wait to have my daughters show even the slightest interest in coding. They are toddlers, so I have to just wait.
The Pi is $35 and has HDMI out and lots of USB ports. It's pretty great.
What software do you have running on the Pi for your 3.5-year-old?
A colleague of mine had a lot of success with Edubuntu. [2] Her six-year-old is a whiz at the command line. Again with the keyboard use, so not quite appropriate.
I'm still looking, basically. He likes clicking around and seeing that he's having an effect on things, but he usually ends up at YouTube, which isn't so great.
[1]: kano.me
I spent some time fiddling around with assembly when I was a teenager to run a TSR (terminate and stay resident, what daemons were called before they were daemons). It would hijack the screen when my little sister was playing a computer game and type out spooky messages like "Help me Sarah... I'm trapped in here" and then go back to the game after a few seconds as if nothing had happened.
Ah, how we laughed (after her nightmares stopped)...
But you have other BASICs such as the one for computers such as the ZX Spectrum.
Python in my opinion can also be used to teach programming, since many high level constructs are optional and syntax is simple.
One of the best things I remember about QBasic is the help system (also referred to in the article). This where I found everything I wanted to know, including examples, about the language. I believe that's one of the reasons why I'm still more patient when it comes to studying software documentation compared to the average programmer.
Personally, I would start with code.org or Scratch. If you have an ipad, there is Hopscotch. Here is a huge list of more tools to teach young kids programming: http://bit.ly/ortonacode
But if you start with basic or python, you'll be teaching them that coding is basically similar to solving boring puzzles - not of any real use, and not as fun as videogames.
Start instead with something they would find motivating or useful, not you. Making a game, or creating a useful little app/tool that solves some problem they think is important, etc.
> Start instead with something they would find motivating or useful, not you. Making a game, or creating a useful little app/tool that solves some problem they think is important, etc.
The thing is, I can't look into their head. Before my children had done any programming whatsoever I had no concrete reference point for the type of programming they would enjoy. My best reference point was my own experience being their age. And when I was their age this approach was the interesting, fun way to do it. This is a very common story. It is anecdote and suffers from all of the bias and unreliability that entails. But then again I've seen lots of un-reproducible "research" that suffers from bias and unwarranted assumptions also, especially when it concerns human behavior and motivation. I'd love to see, specifically, the research you are referencing.
When I was 8-9 I started with QBasic with the first program being pretty much identical as what the kid in the article did. Then we did text adventures with friends. They were simply awesome back then. Then we moved to graphics as we figured out how to draw lines etc. Animation was beyond us but managing to draw something was brilliant.
Around 12 it was C and games by using Allegro, and getting into slight trouble due to the nature of them. But it would not have been possible without first learning the basic stuff in QBasic (Oh the amount of IF blocks was ridiculous in some of the games).
10 echo "hello"
20 goto 10
Sorry MS, I didn't understand how valuable it was.
Imagine my disappointment when the Pi's getting started experience was "Boot into a graphical window manager, open up the Python IDE, start writing Python..."
https://www.raspberrypi.org/blog/celebrating-50-years-of-bas...
Why do we need to install 50 frameworks, tell a window how to spawn, basically create a universe just to start experimenting with creating computer graphics? It's a (Width x Height) matrix of RGB values-- why can't we get a simple way to create a simple 100x100 box for kids to draw in?
No reason your son couldn't tell a screen to print colored pixels in RGB value with the right syntax.
Logo is cool because you see the things you tell the little cursor to draw being drawn-- how could a kid implement something like his son's program, though, where a user is prompted to type their name and hit enter-- then a smiley face is drawn if their name is noah and a sadface is drawn if their name is anything else?
Handling hardware, give them primitives to write to and read from devices. Build up the code on top of that to handle more complex situations like manipulating external servos over a serial port.
I absolutely love Processing. It's a subset of Java with a dead simple IDE. Bonus points for exporting to Android, javascript, and executable jars for the desktop. Comes with excellent examples. The community is generally quite supporting and open as well.
And to answer your question "why can't we get a simple way to create a simple 100x100 box for kids to draw in?"
Here's the processing code that does exactly that:
void setup() { size(100,100) }
That pops a blank 100x100 box onto the screen. Drawing a line is line(start_x, start_y, end_x, end_y).
Adding interactivity and animation is as simple as adding:
void draw(){ ... do stuff ... }
You, and everyone else, should check it out.
Fast forward 13ish years and I own my own mac and know more programming languages than most of my workmates :) Although now I try and specialize in just three Rust, Javascript and Python to avoid being the 'master of none'.
The voice synthesis with the "say" command is impressive: http://doc.basic256.org/doku.php?id=en:say
Say "Hello, World" (instead of Print...)
There's nothing like that in modern programming. Python comes close, but is too magical.
When I was 13 I taught myself html. I used to write webpages by opening up notepad in Windows 95 and typing in all the tags (frames tables even the dreaded blink tag). I consider this my first real experience with programming.
It is not surprising that Noah's desire to program comes from his desire to make games. That's where I got my start, with QBASIC ~20 years ago.
Before that, I remember wanting to take a Entenmann's Donut box and put action figures on sticks to make my own analog fighting game.
How many of you got into programming because of a desire to make games?
I remember going to GaTech early 2000 and there was a teacher named Guzdial pushing Squeek like it was gods gift to children and humanity. There is nothing wrong with the language but I have yet to see kids use it or like it. I have seen high school kids use racket though.
Instant, complete acceptance; no complaints about parentheses or lack of infix or anything.
GOTOs are easy to abuse, but they would really come in handy sometimes.
Great insights for education
Below is an example of it draw dialect:
view layout [
box 320x200 effect [
draw [
pen black
line 20x20 80x80
]
]
]
QBASICScript
QBASIC in a browser
http://www.lexaloffle.com/pico-8.php
The fact that everything you need to build a game is built-in is very key to their enjoyment - they don't need to deal with any operating system in this environment, and have (almost) everything they need to be self-contained developers. (Built-in docs would be nice..)
Its interesting, having watched the evolution of PICO8, to see the mass explosion in creativity around the scene, and I have observed a key to its success - by putting constraints on what you can do and how you can do it, while also filling in the inner space of those constraints with excellent tooling, you give people freedom - within a limit - to create amazing things that push those limits.
You can read more about PICO8 (if you're interested) in this wonderful 'zine, which reflects the culture of the scene very well:
http://pico8fanzine.bigcartel.com
Another big hit is LOAD81, from antirez:
http://github.com/antirez/load81
This, I think, is better than QBasic, in that it has all the same functionality in the IDE, but teaches them a better language: Lua. Plus you can install it almost everywhere you can't install QBasic.
Anyway, in case any other HN'er out there is interested in doing stuff like this with their kids, give PICO8 and LOAD81 a try .. they're both, in my opinion, great ways to get young minds programming ..
All the primitives are there and I've never written any code with much GOTOs in them. Just did not feel the need even when I was 10 years old.
What this article clearly lacks is
SCREEN 13
The python way is to import pygame and get mired in page flipping, creating canvases, creating your own event loop, etc.
The javascript way is to create an HTML5 canvas, learn how to get page elements and store them in a variable, and where to put your code so it will run at the right time, etc.
Both have so much scaffolding before you can just create some procedural graphics and begin to reason about x and y coordinates in a way that's fun and shows the power of programming visually.
My hobby with QBasic was making variations on Conway's Game of Life. So easy and fun in that language compared to anything else.
You can put pixels on screen, draw lines using simple functions and later do 3d stuff in it...
I really miss the simplicity of QBasic sometimes.
You can learn to code any time, when you are older. As far as I can see, there is no advantage in learning to code early.
But there are skills you need to pick up, and experience that you can only have when you are a kid. Let us encourage to kids to do those stuff..
an acronym for Beginner's All-purpose Symbolic Instruction Code.
Yep, I'd say that checks out.
I mean, just make the title "my kid wrote a text game in Qbasic" and do your bragging there. No problem..