Hacker News Reader

Comment by jbandela1 | Hacker News Reader

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.

View on HN

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! :)

A cool idea could be to do something with those collections like open up an interactive historical technology museum or something like that.

OK, now I need to know what that curated PC specs / hardware / software :D

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:

https://github.com/msliczniak/jake/tree/master/games/letters

Just yesterday he said he wants to make it so that after every 100 points more enemies show-up.

A nice benefit to this is it is a whole lot like JS. That's the way to show-off for friends, I'm still mulling how to get him there though without over complexity. I'd appreciate advice.

You are teaching him awk? Are you trying to create a supervillain?

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...

Or How to Design Programs with Dr Racket. Same effect.

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.

Not that scheme is a terrible language.

Racket has turtle graphics. [0]

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.

[0] https://docs.racket-lang.org/turtles/

[1] https://www.nostarch.com/realmofracket

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).

[1] https://docs.racket-lang.org/quick/

[ed: Ie: one can't simply cut'n'paste from: http://el.media.mit.edu/logo-foundation/what_is_logo/logo_pr... and get pretty pictures, one has to manually compile (or transpile if you will) from Logo to Scheme first. Which is obviously a job for a computer, not for a brain.]

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:

"Creating Languages in Racket - Sometimes you just have to make a better mousetrap." http://queue.acm.org/detail.cfm?id=2068896j

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. :)

Python is nice, but pygame is just a wrapper around sdl. I am not surprised it was not appealing.

How do you do graphics in awk? If you don't then using js and one of the html5/canvas based game engines might be a reasonable step forward.

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.

https://github.com/msliczniak/msliczniak.github.io/tree/mast...

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).

A good summery/list in general can be found at https://html5gameengine.com/

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.

thanks ido

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.

>And as an aside: in no way did I end up with the brain damage Dijkstra would have predicted

FWIW QBASIC is pretty advanced compared the the BASIC Dijkstra's comment was referring too.

Yes, I used The Games Factory for many years! It would also create stand-alone installers that would fit in a floppy.

Construct 2 is like games factory but better

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?)

> you start to wish for some way of organizing the code

Yes, this is a critical and valuable step in learning. You can't easily learn the solution until you've encountered the problem.

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.

GOSUB got me pretty far!

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

> Probably not functional programming, though, since functional's not very good for games

Can you elaborate on that? People have actually written games in FP languages ([1], [2]).

[1] http://www.cliki.net/game

[2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

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...

Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).

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.)

John Carmack ported Wolfenstein 3D in Haskell.

And people have written games in Erlang. [0]

[0] http://prog21.dadgum.com/23.html

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.)

Well, sorry, I happen to be a lisp hacker and as such don't regularly follow other FP languages. But I googled it for you:

https://wiki.haskell.org/Applications_and_libraries/Games

I still don't get the "aggressively unhelpful for games". FP does not mean "no state", just that state is expressed differently.

If you do Lisp, why are you fighting for Haskell?

(For the aggressive unhelpfulness of Haskell, I mentioned that Pac-Man project -- and see my other posts in this thread.)

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 fear the consequences if it spreads.

What would those consequences be?

Determinism, libertarianism, Science!, that sort of thing. I suspect that Haskell creates a predisposition towards thinking that way...

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.

I would love to see that if you did built it.

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.

Yes, but it does not have closures, which are somewhat further removed from the bare metal.

All the constructs you mentioned have an almost trivial mapping to assembly language.

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.

This isn't the 1988 PC BIOS basica.com. :-)

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.

Reply on news.ycombinator.com