For young children, QBasic and goto may indeed be superior to more structured languages. From a neuro development perspective we know that young children are very concrete and have limited abstraction ability. With Basic and goto, a program is more concrete (you run a line which is more or less 1 command) and linear (no nested structures). With structured programming, it is more abstract, and has an recursive structure (with arbitrary levels of nesting).
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.
Agree with this, there's also another big advantage that the article doesn't mention - the instant response and lack of distraction.
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. :)
This is why I collect, maintain and most importantly, make available at a whim many old consoles and computers. Anyone can experience the joy of instantly available basic, duck hunt, Mario paint and many other classic and historically significant games and programs more easily than even when I was a kid.
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.
Great idea. I really regret turfing out some of the older kit that weren't PCs. Some of the early games were much more creative (and of course some were terrible).
My kids proved frogger is just as addictive as 30 years ago! :)
Blimey, it was a decade or so ago. :p As they hit teen years just a normal PC+Internet was enough. From memory...
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.
I think you might be onto something. For my oldest son I tried to help him along in python. Just poking about in the interpreter went great, but pygame overwhelmed him and when his laptop died he never picked-up again where he left-off.
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:
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.
AWK is one of the best and simplest languages for a beginner to learn programming.
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.
Well, it could be worse, (s)he could be teaching him REBOL/SPITBOL - and then he'd be disappointed by all new programming languages he encounter later in life...
I was actually suggest Racket as a great platform for learning programming (it's a "real" language/platform, decent IDE, support for building stand-alone executables, great documentation, sold cross-platform support) - but was a little surprised that I couldn't find a BASIC #lang-uage extension for Racket. It would seem that a BASIC mode and maybe a pure turtle graphics mode should be pretty trivial to make for Racket.
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.
As far as I can gather, that module doesn't support traditional (non-lisp) syntax, along the lines of traditional logo graphics? Which could be why the tutorial section[1] prefers the (apparently more well documented) "#lang slideshow", which gives some of the same benefits (a simple syntax for graphics) with some of the same [ed: drawbacks] (an IMNHO slightly higher bar for entry, due to being Scheme, rather than an even easier language).
[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.]
Racket is a very nice scheme setup. As a SICPer I initially wondered if I should use a scheme variant for my oldest son but I thought back to my youth and decided against it. in HS I wrote a TP program that plotted functions for my math class. It would run through the line entered looking for whitespace operators like * and + and only keywords like sin before (. Then it would write a .BAS file and run it in qbasic to plot ;) Having later taken SICP in first year CS was mind opening regarding REPL, but I really appreciated having that earlier experience and honestly I needed a certain maturity for the mental abstractness. There's a time for scheme, about the time someone is ready for learning calculus.
Sure. But there's no reason one couldn't start with a BASIC-like language in Racket. Someone would just have to implement it and support it. It's crazy powerful, see eg:
I originally started with BASIC, created a 4GL with it for productivity, discovered LISP, and re-implemented BASIC in it for incremental compilation & macros. So, yes it's doable. :)
The awk script just does terminal escapes, so no real graphics. Canvas is pretty complicated, I'm shying away from that and also since it's time consuming and orthoganal to create pretty pictures for modern hardware. JS is even worse when you try to teach enough to be fancy and portable.
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.
yeah, i agree canvas is too low level, that's why i suggested one of the game engines that use it under the hood (thus abstracting a lot of the complexity).
Phaser is a pretty decent "batteries-included"-style engine (definitely easier to use than pygame, despite js not being as nice as python).
Be sure to look into LÖVE2D. A bit distantly similar to Pygame but completely self-contained and in Luna, so no dependencies to worry about. Installation couldn't be simpler.
LÖVE2D is fantastic, wish I had known about it cause it is exactly what I was looking for when I tried to help my oldest son, thanks. When my youngest son decides he wants to do sound I will start both of them down that path.
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.
QBasic was one of my first languages I learned (as a young child), and I am fairly certain I rarely used goto, since the language does have if/for/do/while. Interpreting these structures is still fairly linear, since each part manipulates some variables, and possibly jumps to one of the delimiters (if to end, do from loop, etc.)
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.
From my experience back when I was 12: once you get ambitious enough in QBasic, you start to wish for some way of organizing the code and making it easier to follow. At that point, an intro to structured programming or OOP is natural.
(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?)
QBasic supports subroutines (called SUB for procedures and FUNCTION for functions). You can write very structured code with QBasic; pretty much the only thing it lacks is pointers, but it's a very capable language otherwise.
> pretty much the only thing it lacks is pointers, but it's a very capable...
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.
I learned programming in QBasic when I was 12, wrote thousands of lines creating a Windows 3.1 style GUI complete with a help file reader that included hyperlinks. For me the limiting factor wasn't organization -- functions and subs worked well (and I loved the byref and byval parameter definitions). The real limit was speed, which drove me to learn C and was amazed that everything I wrote appeared to execute instantly compared to QBasic
GOAL is hella imperative by design -- it gives you better-than-C-level control over memory and control flow, and the option to drop down to assembly (for the PS2 CPU, GPU, or sound processor) inline, in Lisp syntax.
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.
I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table.
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.
Games would benefit from having the ability to plug in FP to resolve particular rules, but the aggregate game-world is stateful. (Remember that article here on HN where someone took several months to sort of write Pac-Man in Haskell, then admitted at the end that it would've taken him a week in C; and look at some of the other hoops that Haskell tutorials jump through when writing games.)
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).
(Talking about FP, but mainly aout Haskell and other languages with some weak OOP tools)
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.
How is the current state just recursive application of the rules, if the rules integrate randomness? It would mean saving every call to rand(), as well as every piece of user input...
We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.
Oh, you get much more, and better with Haskell. (It's just that stuff is currently widely in flux. Not at the base language, but at the level of basic libraries there's great improvements.)
Saying "FP languages" and only giving examples for Lisp is cheating. Lisp has state, it has an imperative-programming mode, and it has well-developed database libraries; it's not monomaniacally FP (and therefore aggressively unhelpful for games) like Haskell is.
(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.)
Oh, I did not know about Carmack's port of Wolfenstein 3D, very neat. Here he is talking about motivations and lessons learned: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-... (Summary: The worst problem he had with the port that he could not motivate himself enough to work on a learning project instead of a current, commercial one.)
I don't fight for Haskell, I was hoping for an enlightening answer; since all I got was a referral (not a link) to another comment that again refers to some other thread (again without link) that apparently only provides anecdotal evidence based on one guy's story who had a hard time with his project I call it a day you a troll.
Call me whatever you like, just don't make me use Haskell. The language makes my hair stand on end; it feels math-y and determinist, like the triumph of H.G. Wells and B.F. Skinner. I want nothing to do with it, and I fear the consequences if it spreads.
I was in the same boat at that age. I was trying to build a text-based BassTour clone in QBasic, and the book my dad bought from Radioshack didn't get into OOP. It would have made it much easier to do than that static-state version I cobbled together.
Aren't you confusing QBasic with some older BASICs? QBasic is a structured language. It has blocks, functions, different kinds of loops, custom types... It doesn't require gotos or line numbers, though it supports them for backwards compatibility.
The lack of anything like a pointer or reference type is more significant. That and pointers to code would go a LONG way to adding useful expressive power to the language. As things stand right now, there's really no way at all to abstract control flow, which makes a number of useful programming styles very difficult to implement, if not impossible.
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.
I don't quite get this assumption -- qbasic doesnt have line numbers unless you want them. Noah's code didnt even have any in the pictures.
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.
QBasic offers structured programming. QBasic has both subroutines and functions and the IDE actually displays them in their own window, separate from the main program and other subroutines and functions. It also has if blocks, loops, etc. I don't see what else you need for structured programming. When I was young I was able to create many complex games including breakout, tennis, basketball, arcade shooters, etc. with QBasic alone.
>to realize that in more than 30 years, we have not been able to come up with something better for our kids: Qbasic ..., but we have never really made a simpler or more direct access to the thrill of programming than QBasic.
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");
And boom, you get a popup. You can also show the kid he can type in arithmetic stuff like "2+3" and he'll get back the answer 5. You can then show him how to modify the existing web page. You can ramp up a slight bit of complexity by showing how to create a text file and writing Javascript and then having the browser run it. The 8-year olds I've seen can handle this no problem.
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.
I agree with your complaints about QBasic but I disagree a bit about JavaScript. You are totally right that the environment being right there in the browser is great. But if you press F12 right now you'll find an amazing complex dialog box -- as a professional you just implicitly skip over that complexity. And JavaScript is a significantly more difficult language than QBasic even if it's one of the simpler professional languages.
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.
>But if you press F12 right now you'll find an amazing complex dialog box -- as a professional you just implicitly skip over that complexity.
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");"
The real problem is there is no ISO Standard for the appliance interfaces. Do you press power level first? Or time first. Is it Forth like, numbers then operation or Haskell like, Function then number. My refrigerator has illuminated bars indicating how cold it is set for. Even after downloading a pdf of the user guide I can't figure out if I'm setting it correctly. Placing a thermometer inside and using trial and error solved the problem (after a few frozen bags of spinach).
My microwave has two knobs. One for power, one for time. It turns on automatically when you turn the timer and turns off automatically (sounding a mechanical bell) when the timer hits zero.
I used one of those microwaves once. Best interface ever, and so much simpler than the high-tech beepy button matrix! Do microwave manufacturers just not realize that they're making their products worse by complicating them? I don't get it.
Actually, yes. Anything with a moving part is painfully expensive, which is why cheap monitors try to reduce the number of buttons or use capacitative touch-sensitive controls.
Touch-sensitive membrane buttons like the ones the use on the front of microwaves are much cheaper than mechanical timers.
My family had a microwave like that for ages, and I loved it. I think it was over 20 years old by the time they got a new one, because it was so rugged and easy to use.
Personally I think problems people have with appliances like microwave ovens are a combination of fear and intellectual laziness (aka. not expecting to have to figure out anything for themselves anymore). Probably the same thing as with computers in general[0].
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.
So that you know it worked. Even without looking at the small display that also usually changes in response.
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).
Input lag is the mortal sin of UI design, and it's ignored everywhere except on dedicated appliances (touch phone, microwave, fridge). Instant response is not a given. I wish OS designers treated the user as a real-time system with hard deadlines.
One benefit, though not necessarily intended by the manufacturers, is that blind users get some kind of feedback for each keypress, since there's usually no tactile feedback on a microwave.
I once spent half an hour reading the microwave manual (in Japanese) looking for some hidden way to disable the beeps. If you hold down one of the keys for over 5 seconds it puts you in silent mode, also disabling the annoying melody when heating is finished.
Yeah.. kids are tougher than we tend to give them credit for. I got an Amiga 500 when I was 10 years old, try playing Carrier Command, Elite or something like that without a manual and no clue what any of the words mean :) We sometimes didn't get very far, or missed out on many aspects, but there was still so much we did get out of it, so we kept hanging on, and with everything we understood, other things became easier to understand. I basically learned English that way, once I got a dictionary, since the coolest and best games and applications generally were in English. I didn't even notice I was learning you might say, I was too busy stacking boxes to get the banana :D
Ah, Carrier Command... I'm going to have to play that again. Powered on my Amiga 500 on my desk yesterday after almost two years, and to my amazement the battery kept the correct time.
My A4000T is also still working fine (last time I checked), but of course the HD died. One of these days I will get a CF or even SSD in there, maybe get a nice mouse and indulge myself to bits. http://aminet.net/ is still here and nice things still get made, after all :)
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.
Yes. I've been doing Javascript + HTML games with my 9yo nephew every now and then, and the complexity of the environment as a whole is incredibly discouraging. Sure, he gets assignment, functions, conditionals and other basics. But the interface between the logic and the presentation is just so incredibly abstract that getting from those basics to anything interesting is way too hard.
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.
Consider using an HTML5 canvas (with a 2D rendering context) instead of DOM manipulation.
It makes programming very similar to QBasic's LINE, CIRCLE, PAINT.
I write a lot of stuff with the Canvas in general, but it's not great for teaching programming. The Postscript imaging model is again very abstract, complex, and easy to misuse early on. It can be made to work if by setting up a lot of scaffolding up front.
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.
Visual Basic 6.0 was great for learning how to program!
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.
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.
Well yes it was online in that sense, which was great. But what I meant to point out was that the complete MSDN help library came shipped on two CDs that you could locally install. It was really really good. There was a description, detailed background info, and usually at least a few example code snippets using the function. I was later a astonished at how sparse and useless documentation for many other libraries/languages was compared to that, especially when it came to example usage. Some notable disappointments included e.g. the Java/JDK docs (v1.4) and the early Android docs (v1), which both required looking at the code because the docs were severely lacking (both have improved by now).
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.
I think the "thrill of turning text into action" might be an adult sentiment. I wouldn't write this off.
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.
My daughter learned to program with Scratch. It is definitely the right approach for more visually-oriented kids. She created some cool (to her) games, and found it so compelling that she turned some of her friends onto Scratch, who also then created games. Playing each others games and looking at the "code" was an important aspect of the learning experience.
Don't get me wrong, I think that any environment aimed at children needs to be highly visual. One of the most common environments for teaching programming to kids used to be Logo. But it was still 'type commands' => 'produce visuals' and I think there is value in that. A lot of Logo wasn't even producing programs but seeing what crazy affects you could get through one line of "code".
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.
It's always Python+X somehow, where X is a whole different thing you have to learn to get a fraction of the whole thing shipped in Python. Keep I.T. simple - teach the kids BASIC.
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)
Isn't TK usually part of the standard library? Of course, then you have to build your UI in code, which can be a lot for a beginner - which I why I stated QML or GTK Composite Templates, both allow you to design your UI in the relevant tool (QtCreator, Glade) and then just wire it up. Speaking from experience, the trial and error of creating UI's in code instead of through a markup language with an editor that can preview it is a pain.
I don't really think GTK is that difficult to get a grasp on with composite templates. It's a little less "magic" than VB6 since I'm not just dumping code into a partial form class where the rest of the accessors to the COM controls are generated for me, but it's pretty straightforward in Vala right now (I use glade to design a UI, much like the classic WinForms designer - annotate a class with a GtkTemplate attribute and then put GtkChild attributes on class members to have the widgets automatically assigned there).
GTK in FreeBASIC is simple as well - just translate the C function calls into BASIC. FreeBASIC is really C++ without the curly braces so it's really a good covert way to gradually turn userland programmers into system programmers
> I think that Javascript in today's browser is a fine substitute.
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.
Is it simple to draw a line in JS? Like in one line of simple and straight code, yes? I mean, not adding some divs to some DOM, but actually drawing a line or circle. Drawing is simplifying things for kids.
1) Ok, in firefox I opened the console window. 29 buttons. The one to type this in was the thing at the very bottom that looked like ">> " with no cursor in it indicating that you could type in it.
2) 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.
Sure! Just locate the element you want to draw in, set up a 2d context, start a path, move to one end of the line, draw a line, and then stroke that line so it fills in! How much simpler could it be really?
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.
That's really a question of the APIs you're using rather than the language. If you're using a browser, you don't even need JS to draw the line; you can just go to this URL:
and that works. (Although you could surely argue that the language of processing.js isn't itself JS, but you can invoke its facilities from JS.)
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.
If I was going to start a child on coding javascript, I would probably do this or codepen rather than a full fledged text editor, ide, or browser built-in console. Move them to the console once they're comfortable and teach them how to use the debugger.
As someone who actually learned programming with JavaScript, back in IE 5 days, I agree. Writing dumb little "guess the number" games or copy-pasting snippets from DynamicDrive.com to study and adapt made it very easy to get started, and that you can upload it to a free host and share the link gives you an extra incentive.
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.
You missed out - there is nothing quite like getting your first picture on the screen with the Copper, or doing your first scroller with the Blitter, or hearing your first Future Composer tune play correctly inside of a working level 3 interrupt request...
Yeah, we couldn't afford a computer back then. I learned by spending my Saturdays on the public computers at the library, hence why having access to an interpreter that didn't need to be installed was awesome.
JS is a fantastic language for teaching the basics of programming - introducing variables, flow control, 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.
> My favorite is the date, where you months are 0 to 11, and days are 1 - 31.
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.)
> I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier.
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.
This was a design error introduced by, apparently, Dennis Ritchie (RIP) in the early 1970s, when ctime() was split into asctime() and localtime(), around the time UNIX was rewritten in C. It kind of makes sense in the context of implementing ctime(). But it was still a design error.
Part of learning HOW to program has always been how to SELL your program. The BASIC programming language has always offered an easy path to doing just that. No googling what to use to turn the code into an executable like Python, no learning a whole library to do that either like Javascript& the node.js nightmare. Code -> Ship -> Profit (or get famous) - Any Basic, any platform, whether your machine runs at 8Mhz or 4Ghz.
I don't think QBasic's mainstream popularity can be understated. Googling "gorillas.bas" gives you a predictable result. I suppose it can be argued that Gorillas and Nibbles are partly responsible for QBasic's popularity (is there a lesson in here somewhere?).
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"
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.
I've been using FreeBASIC for about 10 years and help maintain a 100+kLOC codebase written in it (a game engine).
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.
Thanks for the review. Sounds like it's what I used to call an "industrial" BASIC where it has the features and compiler to get real work done. Many people think some toy with a few key words and interpretation when they think BASIC. Yet, I used to do all my hacking in it and Visual Basic 6 for GUI layer. Loved VB6 specifically for rapid iteration: instant load, instant test-run, instant... you name it on P3 400Mhz w/ 128MB RAM.
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.
Yes, I would agree with "industrial", especially since you can link with any C library after translating the headers with SWIG (translations of common libraries like C, winapi and GTK are included with FB). I've never used/don't know VB, but it appears that quite a lot of FB's design is borrowed from it. In recent years FB has been focused on borrowing C++ features instead (and even aiming to be ABI compatible with g++, not sure if that works). E.g. recently added "dim byref" (like a C++ reference variable) and polymorphism + RTTI. Sometimes things move in the other direction, like binary literals new in C++14 :)
Just a head injury. Dont give too much detail as too solud testimony might be used against me in hiring or court or something.
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.
Appreciate it. Just functional enough to recall pieces of a good, in-depth conversation with you here on programming, software quality, etc. I gave you credit elsewhere for being unusually knowledgeable about present and past techniques of getting job done. Plus noticing high assurance implementation came down to rigorous FSM's and their connection to hardware. Impressive.
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. :)
Cool! Congratulations! I also think that approach sounds potentially very fertile, and painfully feel the inadequacy of existing methods of programming to the tasks we face today. What kinds of media of expression have you come up with?
Tks. Looks like a nice BASIC but appears closed-source from Microsoft. They trash a lot if their side projects over time. So, I'd recommend it only for temporary stuff in learning. Maybe OSS imitate any good qualities it has, too.
One important thing about QBasic that's often overlooked is that it's a community of 100% amateurs.
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.
What's nice with BASIC is that no context is required from the programmer: you don't need to know about the call stack or about variable scope. It's the programming equivalent of WYSIWYG. It also doesn't hurt that BASIC used to be resident in ROM (thinking back of the Sinclair ZX Spectrum), and that there were nice and simple primitives for drawing on the screen.
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.
My favorite thing about this story is that Basic was meant to be used exactly this way, for getting new programmers off the ground. And like everyone, I've got fond memories. We had an IBM PS/2 80286, with a whole megabyte of memory, a 20 megabyte hard drive, and MS-DOS three point something. At some point, I discovered that it had Basic, but it didn't have a graphical editor. It had edlin, which was still enough to write programs that told their users how awesome I was. Forever, with gotos.
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!
I've always thought that learning to follow GOTOs and GOSUBs was the key to understand assembly language. "GOTO considered harmful" is really what's considered harmful. I never take anyone who says "X considered harmful" seriously because of "GOTO considered harmful".
"GOTO considered harmful" is about a style of unstructured programming that was prevalent in its era.
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 agree -- the whole "considered harmful" meme is long overplayed. I don't even click on links with "considered harmful" in the title. The original point, which was that GOTO abuse was letting undisciplined programmers create impossible-to-follow control structures, was true in its time. I've seen some truly headache-inducing GOTOs in 1970s-era FORTRAN that involve jumping into the middle of loops and the like. But the modern point of view that rejects GOTO out of hand is just ignorant.
"When developing a skill, it is much better to acquire the right reflexes from the start rather than have to correct years of bad practice."
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.
I'd argue that programming isn't like other skills in this regard. Obviously if you're teaching something like the violin, where there's one right way to hold the bow and learning how to play holding the bow in any other way will ultimately hamper you, sure, it's worth it to drill the One True Way.
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.
There isn't really a One True Way in music either. There are stupid ways to hold a bow, and there's a small range of ways that works. But it's certainly not something you can reduce to a formula of so-many-inches along and an angle of theta.
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.
No love for Logo? I currently have my kids experimenting with ucbLogo and FMSLogo. And one of our latest endeavors is to hook it up to Minecraft [1], but that is certainly quite convoluted, with having to run minecraft servers with various plugins, and then working around the borked networking capabilities of FMSLogo, etc.. I wonder what other simple approaches there are to programmatically control Minecraft.
OpenComputers is pretty nice, but involves writing Lua code. It features a virtual UNIX-ish OS to put your programs in, including editors; in many ways it's like stepping twenty years back in time.
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... :)
I learned through logo in middle school.
A language sophisticated enough to later (high school) write programs that would take equations and graph them.
Plus who doesn't love writing software to create spirograph graphics.
I come back to Logo probably once every 2 years, for about 15 years now. First used it in primary (elementary) school but never really progressed past spirographs.
I think I'll fire it up again this weekend - any hints?
That's what I was missing! Lots of love for Logo here. Started with that first, then eventually to QBasic. There was a lot of time spent on KidPix for a while too. That thing was insane.
I have so many fond memories of QBasic, and QuickBasic.
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.
I think TI-BASIC is a strong competitor. A free-form keyboard can be overwhelming and the different things you can do aren't very discoverable. In the TI-BASIC environment on the TI-82/83/83+/84+, the keywords (Goto, While, Disp, ClrHome, etc) are tokens which must be inserted into the program by selecting them from menus. So you get a rich set of powerful commands (easily in the hundreds, even for the simple TI-84, and many more for the TI-89) but they're all discoverable through the normal menus and through the catalog menu. You start out knowing a few commands like Lbl and Goto, but through the process of scrolling over unknown commands (like maybe For or While in the control flow menu) repeatedly you start to wonder what they do, and then try them out, until you know what everything does and you can write the cleanest possible code. It's a wonderful way to learn.
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.
This is exactly how I fell in love with programming. My first program of any size solved systems of equations using 3 or 4 methods and showed its work. The satisfaction was incredible.
To be honest I don't think modern languages are all they are cracked up to be. Back in the day, very large and complex systems were managed quite well with languages like QBASIC, COBOL and FORTRAN, and ran rock solid for decades (hell, a few are still operational). But today, programming is such a polyglotic mess and conceptual navel-gazing nightmare -- it really is no wonder that so many projects end in failure.
As an outsider looking in: programmers, fix thy tools.
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.
> 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.
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.
> WTF has everybody been doing for the past 10-20 years?
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!!!
Fortran is still numero uno when it comes to finite element analysis and high performance computing industries: not only does the Formula TRanslator language lend itself particularly well to expressing physics and mathematical equations needed for doing finite element analysis, but intel and PGI ship ultramodern Fortran compilers which generate very fast machine code, faster than even optimizing C compilers. intel ships their Fortran compiler with support and optimizations for their latest processor features and instruction sets (for instance, AVX), and PGI pioneered a Fortran compiler which can compile Fortran directly into NVidia GPU code.
Beware of survivor bias. Most old projects failed, like most new projects.
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...
Author is spot on. My son and daughter have about 2 and 4 years to go before I probably intro them to programming. When I do, it's going to be a C64 all the way. And a real one. With a real old school monitor and a luxury a didn't have for about a year or two: a floppy drive.
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.
> Just wayyy to much stuff for a young mind to try to focus on.
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.
QBasic was my first exposure to programming, when I was 9 years old. Fond memories. Despite it having what today I consider terrible syntax, it made programming extremely approachable. After a quick "hello, world" intro from an IT guy at my mom's office, I spent countless hours reading the help pages and learning the commands. Sometimes I wish programming could be as simple again.
I learned to program on an Apple ][, where the programming environment was always a CTRL+RESET away. BASIC was great. I carefully typed long programs that I found in the back of computer magazines, broke them by changing stuff, and fiddled around endlessly. Those incantations are still in my fingers (CALL -3116 for a nice visual effect, PEEK -16384 for the current keyboard key, VTAB and HTAB to get around the screen, etc).
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?
QBasic was a truly incredible way to start programming.
Today I'd probably recommend python with pygame, and especially the book inventing computer games with python:
https://inventwithpython.com/
I got my 4th grade class to play gorilla, which interestingly came with the Windows NT machines at my school. That and that reskinned Full Tilt! Pinball table Space Cadet. Quite a contrast.
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.
Yes, there are a number of QBasic reimplementations and compatible languages. FreeBASIC is one that aims to be a (compatible) successor rather than just a reimplementation. I can't remember what the others are...
I started with MBasic on a Superbrain running CP/M, a very early ancestor of GWBasic and QBasic.
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.
QBasic is what got me started with programming more than 20 years ago. The thrill of writing a program that draws a rectangle, than erases it and draws slightly to the left and then watching the rectangle zoom across the screen hasn't been surpassed ever since.
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.
I think BASIC! for android by Paul Laughton is a modern good modern alternative for an entry to programming. It comes with good documentation and examples, and is a classic basic-type language.
link:
https://play.google.com/store/apps/details?id=com.rfo.basic&...
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...
Honestly this thread put a tear into my eyes....I was literally your kid like 15 years ago when i first discovered quick basic on my own as a 10 year old. I feel this so deeply. It was much easier to learn that than anything else I've ever learned since.
I remember doing the same. Starting with a Qbasic book I had bought with the little money I had, I was already writing mud-like games and calculating prime numbers after only an hour. Though I wasn't lucky enough to have done it at that age. Lucky kid :)
Ha! Who didn't hack the gorilla throwing bananas? :)
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.
I am curious what's there to stop a kid from starting a Jupyter notebook (or even Mathematica with all the FullSnakeCaseNames) and firing away? Sure it isn't complex at least wrt. the basics (pun intended)?
Grandpas know BASIC and they can teach any version of it to their grandkids in under 2 weeks tops, they don't necessarily know Jupyter notebooks or Mathematica (how much does that cost these days?).
It's mentioned in the article, but Microsoft have a nice BASIC environment called SmallBasic[0]. It's got a decent editor with IntelliSense, there's a community with a bunch of programs shared online[1] and it can interface with .NET code so you can extend it with whatever shenanigans your kids might require.
I learned to program on Texas Instruments calculators in the same form as this seven year old's application, I made really elaborate choose your own adventure games with if statements.
My first programs were for a TI-55 calculator. No conditional jumps, only a RST that restarted the program with data intact, so you could do some tricks.
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.
GW-BASIC (QBasic's kinda sorta ancestor) was my first programming language (well, other than Logo I suppose). I still have a soft spot for it and might not be a programmer today if I hadn't first learned on such an easy-to-grok-for-11-year-old-me language.
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?
This made me smile. I remember trying to learn coding at 6 or 7 from my Tandy 56K Basic manual. I didn't get it but I tried all the same. It would have been cool to have someone there to help me understand.
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.
I was around the same age. My dad was a big ZBasic fan, and he had me copying BASIC games out of a book and getting them to run, on our Tandy 1000. My oldest is 5, and I'm trying to figure out the best time to expose him to it. With the entertainment-focused nature of computing we have now, I can't rely on the lack of distractions that were present with a non-networked computer with a monochrome display. Right now, we don't even have a regular computer for him to play around with—my wife and I have our own laptops—so I think the first step is setting up a desktop machine that the kids can fool around with.
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)...
I've had a lot of success with a Raspberry Pi 3 and a 15" monitor. My 3 1/2 year old learned how to use a mouse nearly instantly and can click around on the desktop.
The Pi is $35 and has HDMI out and lots of USB ports. It's pretty great.
I almost bought a Pi for my son when he turned five, but then I decided to hold off (he didn't seem mature enough to be trusted with it yet). I want each of my kids to have a device that they can use how they please—whether it be playing Minecraft or tinkering with the hardware (including destroying it—I broke quite a few computers growing up...).
What software do you have running on the Pi for your 3.5-year-old?
Well... the Kano distro is pretty good for "I'm gonna learn how to type and move around the computer". [1] They have a build-a-computer kit and are coming out with a screen soon? It's a little old for my son, though. It really wants you to type things which is great except he can't read yet.
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.
As a person who taught himself programming (and a bit of English) with QBasic, and also have known many people that did the same. I agree with this article.
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.
I couldn't agree more. I started programming with QBasic -- basically teaching myself on my own -- when I was seven. And it worked. I was programming little interactive stories, drew crazy stuff on the screen, wrote small games. I was happy with it. The only things I was always curious about (and know one I knew back then could help me with) was on how to access the computer's mouse and the sound blaster. With my limited knowledge I never got that working until I switched to Delphi and Windows four years later.
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.
Try to teach your kids programming this way, and you are more than likely only going to turn them off programming for many years. There is actual research on teaching kids how to code.
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.
Boring puzzles? The very original article showed what kind of programs the kid made. Far from boring puzzle.
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).
I would love to see the research you are referencing.
> 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.
Unfortunately, I agree. I burnt my kids out on programming because I went the old school route. Of course, it depends on the child, but expectations of computers (and applications) are much greater now.
I'm a bit late to the party on this one but if you are looking for a great way for kids to learn basic and make video games, check out http://www.blitzbasic.com/
Last month I reconnected with QBasic, was surprised about the live formatter and linter. And the pseudo module handling. Each function being seen as a separate entity.
Sorry MS, I didn't understand how valuable it was.
One of my disappointments with the original Raspberry Pi was that I felt that its genesis story was from people whose early experience with programming came from Apple II's and QBASIC. It was pitched as a way to expose kids today to that same kind of low-overhead, get-in-and-start-making-things-happen experience some of us had 25 years ago.
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..."
I think Qbasic was so fun because it was easy do do graphics. Doing graphics in any other language is just insanely hard as you have to understand university grade math.
I agree- we should also have just as easy of a way to start off with drawing.
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.
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:
Processing is a great and fun way to learn programming! I learned it that way, and I found that it kept my interest cause I could use it in a creative way while it also was easy to use.
Ya I can see that, I'm imagining a way a kid could make his OWN logo implementation, though.
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?
Start off with lower primitives. In Logo, for instance, have a "draw at pixel" command. Have a way of recording a state. The student can then recreate the notion of pen on/off and pen placement and movement on top of the basic primitive plus a conditional. Pen is moving from A to B, if it's on, it draws along the way, otherwise it just moves. Some challenges with the math involved in movement, but it's solving a linear equation. Minor issue with rounding, perhaps allow the numbers to be floating point and let the renderer handle which pixel to draw. Everything up to the external turtle can be handled in this same way as long as they have the primitives.
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 learnt Qbasic not that long ago it was my first taste of programming. However back then I couldn't afford a computer, so I had this Qbasic book and just had to 'imagine' how my programs run.
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'.
Key to get people coding, doesn't matter what the language, platform, etc. is in my opinion. Think I've worked in more than 20 or 30 languages to help someone new to programming write some programs. Each language has it own set of strengths and weaknesses, but normally my experience is that the person having a choice, is really important to them sticking with it.
I introduced my 10 years old cousin to turbo pascal when we met a few years ago. It took less than 3 hours to download it, install (also the patches to run on modern computer), make a game where you can move a circle around the screen, and teach him how can he modify it and how basic syntax works.
There's nothing like that in modern programming. Python comes close, but is too magical.
My Dad taught me Turbo Pascal when I was about 7 or 8 years old, this was the early 90's msdos environment. I wrote one or two very simple programs got bored and moved on to other things. I just didn't have the attention span for it at that age.
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.
Wow... good job man. My first experience with programming was QBasic, and that was about 16 years ago. I only did it for a couple of weeks but when I picked up on programming several years later as a young adult, it all came back to me - assigning variables from user inputs, printing on screen, if then else, all the basics. Good stuff!
I think Racket comes close but is still a little more adult.
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.
Oh man I am having a nostalgia heart attack right now. I remember coding a "guy shooting falling aliens from the bottom of the screen" game and hilariously having the aliens move not only through a timer but ALSO when you moved since there was no threading. Classic.
I also started with BASIC. First was Commodore BASIC and then QBasic. I remember there was also LOGO, one of the original didactic languages.
IMHO, if you want a simple language in the same spirit as BASIC, the closest you can find is Lua.
My post won't add much to the discussion, but QBasic was also my very first language. I was a little older than Noah when I first used it (I think I was ~12/13) and I still remember having so much fun with it :)
So who will do an equivalent of QBasic for the web? It seems that the language is simple enough to be implemented entirely in Javascript. Then you wouldn't have to deal with the hassle of installing.
I remember learning to program with QBasic as well. It was so much fun as a kid. I painstakingly drew out full scenes with line and circle commands for a small text based adventure game. Good times.
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:
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 ..
Absolutely, this is what I miss, both for myself and for teaching youngsters. Not even Python or Javascript has an easy way to just get a full screen canvas that lets you set RGB colors onto pixels and draw shapes.
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.
Some screen modes[1] like screen 9 actually had page flipping as an option. You could write to the "back" screen buffer and then switch which buffer was shown. I used that to make a poor man's strobe light.
Wonderful post. I did something similar for my younger daughter and one of her friends with Lua and Love2d. In just a couple of hours they had written a Breakout clone and also understood every line of code. Very satisfying.
The Monkey X programming language is a great alternative to qbasic. It's simple to install, cross platform, procedural, OOP, and incredibly powerful the more you get to know it.
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.