Hacker News Reader

Comment by avaer | Hacker News Reader

I actually don't know any great coders that learned to code through these kinds of games. They might move the programming-is-interesting gradient, but I don't think the hard part about learning to code is the text.

The hard part about coding is the problems that aren't in the code. Doing research, setting up environments, understanding platforms, dealing with crashes, dealing with crappy tools, debugging, understanding other people's code. None of this is taught by isolated sandbox games like this. Sandbox games might teach some very useful analytical skills, but it's pretty far from coding.

The only thing you really need to get kids coding is to give them the tools needed to do interesting naughty things. Many of the programmers I know learned to code at an early age by hacking games to cheat against their friends. Reading text was never, ever a problem, but the disillusionment of finding out that coding doesn't involve pretty foolproof user interfaces might have been.

View on HN

While I agree that I also don't know of any 'great coders' which started with these games, I don't think that these games were available for anyone coming from either my generation (in my 20s, now) or any of the previous ones. The Code.org push happened when I was in High school, far too old to be of target to any of these types of games, and the ones that did exist---let's be honest---were pretty bad.

As for

>The hard part about coding is the problems that aren't in the code

Yes, while I do agree, that's only true once you're already comfortable with coding. I know many people who can set up Eclipse, have no idea that Ctrl+Space is the autocomplete function, and who can write and compile simple programs, but given a slightly more difficult task involving some relatively simple (for us, now) algorithm, would throw their hands up in the air and say that they "don't know how to tell the computer how to do that" (approx. quote).

Though anecdotal, it might be of interest: my youngest cousin started learning how to code through Scratch and Mindstorm (all of which are graphical programming languages) and has had no problem picking up 'true coding' in the past few years, writing simple programs in Python. She's 8 now, I believe. Of course, correlation, causation, it's really up in the air to be honest, but I do think the graphical nature of all of this might have opened her eyes to a much bigger world than the cryptic matrix-like text which fills our screens---which, personally, is how I imagine many people view programming.

I'd challenge the idea that Scratch is a “visual” programming language. It has you put together blocks to write code, but those blocks contain text and behave like statements in any vanilla programming language. The advantage of the block system is that it's discoverable (all available blocks are shown in and can be picked from the menu) and it mostly avoids syntax pitfalls (either a block fits into another or it doesn't).

But it's also coupled with a sort of… game engine/scene graph kind of thing that your code affects and which you can interact with visually, which probably makes your code seem more tangible?

Yes, sorry, when I say "graphical," I mean that the language has a graphical representation of the logical flow that doesn't have to be inferred from the text.

E.g. in Scratch, as you mentioned, all blocks have text but the flow of the program is given in a graphical way, and can also be dictated in a graphical way. Additionally, the blocks themselves, while having text, also encode their purpose graphically (e.g. start, event-driven blocks, as distinguished from instructions, etc).

Also as you mentioned, there's something nice about these blocks in that the system is completely discoverable and has the flexibility of combining statements, etc., without the exponentially large space one would have to think about if they attempted to discover the language by typing out statements using the keyboard.

In other words, there is much-reduced complexity in graphical languages, along with the fact that programming becomes much less a question of remembering what a block does as opposed to finding the block which does what you want. A much easier problem for those unfamiliar with a language, which also allows them to focus on the problem as opposed to the specifics of learning the syntax of a language.

Yeah. I think the genius of Scratch is it's basically an advanced IDE for an ordinary programming language, rather than trying to create some alien “visual” thing.

> I don't think that these games were available for anyone coming from either my generation (in my 20s, now) or any of the previous ones.

S.E.U.C.K. [1] was published in 1987. RPGMaker [2] was first published in 1992 and is still going.

[1] https://en.wikipedia.org/wiki/Shoot-%27Em-Up_Construction_Ki...

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

I did use RPG Maker, having found out about it in middle school (though I had programmed before), it was actually kind of fun to mess with, thanks for reminding me about it! I may pass it on.

But, anyways, my point was less that they didn't exist, but rather than one had to know this was a community and actively seek it out, whereas now an interested parent can go look up "learn to program" in the app store and have plenty of apps to install and have their kids run on an iPhone or iPad ready to go, instead of having to go through several websites along with setting up applications on their computer, etc., to get everything ready for their kids' use. Perhaps more succinctly, they have to have no prior knowledge of programming or of the existence of this community in order to have their kids be a part of it.

Of course, before we could still Google stuff and see that it exists, but it seems to have more of an activation energy than a ready-to-install app from the app store; I should also note that this all was also pre-Code.org push, too. Compared to so many of the people I know with kids in elementary and middle school, many of whom are already starting to learn how to program, I can't remember this being the case at all with my year. All of this comes with the big warning label of "anecdotal evidence," but I'd love to know if there are any numbers on this!

I'm not calling myself great, but my initial introduction to programming was a Logo robot at the age of 6 or 7 in the 80s, so I'm not sure I agree with you. A turtle shaped robot we could get to draw things. All primary schools at that time usually had a BBC Micro in each class too.

Perhaps it was just a British thing. After that it was some BASIC on spectrums, some BASIC on Acorn Archimedes, then some random OO language on Amiga that I've never really been able to track down what it was called.

And I wasn't even that keen on programming, I was just exposed enough and wanted to build better games than my friends at lunch or on our graphical calculators. I remember running out of memory on my graphing calculator trying to get a working version of poker (which I now realize was wildly more ambitious than the versions of blackjack we all made).

A lot of programmers of my age will remember the turtle with fondness.

I guess all of those were incredibly simple to setup to start programming (for the spectrum it would go straight to the command line), but then again these days so's pressing F12 on a web browser to get a working command line.

My first steps I did with Robot Karol (which uses Karel as a programming language): https://en.wikipedia.org/wiki/Karel_(programming_language)

Fun times, I could sit there for hours trying to figure out how to build shapes like pyramids: http://www.wschellenberger.de/informatik/inf_robotkarol/inf_...

> some random OO language on Amiga that I've never really been able to track down

Maybe Amiga E? http://strlen.com/amiga-e/

Definitely not just a British thing - that was part of my introduction to programming in the US in the 80's. It might be a very 80's-specific thing, though.

I had a similar experience in the US in the 80's. Logo and BASIC on an Apple IIe.

I learned a lot about programming and debugging from Rocky's Boots (https://en.wikipedia.org/wiki/Rocky%27s_Boots) , so at least you have that.

I don't think there has been enough time to say if any "great programmers" (ugh, that's a horrible horrible term) have learned from graphical tools. MIT's Scratch came out (just) 15 years ago, and was quite primitive. Many career developers really start programming at around age 10, so even if they started on scratch, they would be just 25 now. Only beginning their journey to becoming "great". There just hasn't been enough time to say if this is an effective introductory tool or not.

Another fan of that gem. I really wish I could get my hands on a port or emulation.

Spent hours upon hours with that game. The advanced logic required in the harder levels wasn't trivial.

One thing that I remember is that with longer circuits you had to factor in propogation and lag times which basically forced you to refactor down to simpler solutions.

To me the game felt more real or organic than any modern equivalents, although I haven't tried them all.

It looks like a version is now playable on archive.org

https://archive.org/details/Rockys_Boots_1982_Learning_Compa...

As a kid, I never played "Rocky's Boots" - but I did fall in love with their other game, "Robot Odyssey":

https://en.wikipedia.org/wiki/Robot_Odyssey

There used to be a fan-made online version, done in Java, called "DroidQuest" - but apparently it is only available via github now:

https://github.com/ThomasFooteDQ/DroidQuest

You already got a lot of replies about your first paragraph here; I wanted to emphasize and second your next paragraph though: things like setting up environments, by far, is what prevents people from getting into coding. It even applies to both beginners and professionals! (anecdotally, I know that mentally I've resisted getting into iOS dev all these years is because setting up the whole toolchain to even start a hello world iphone app feels too much work for side projects.)

Thinking about my own growing-up, while it's true that at school I've had classes about PC Logo, Quick Pascal/Turbo Pascal (and I've had fun with those and enjoyed them, but they were no more than class assignments to me), what really got me started to build stuff in the real world (as side projects back in middle and high school) was essentially the web. Realizing that I could open up Notepad in Windows, with no extra tools, write some HTML in there (even some simple Javascript with alert boxes!), I could then double click the .html file to open it in Internet Explorer and see stuff I've written in code to run, was what really got me into taking coding seriously. Better yet, in the late 90s, HTML code in web sites were not complex, which brings the possibility of just viewing source on any HTML page and understanding what the HTML tags or JS code do and figuring out how to replicate some functionality on your own web page.

I have a theory that once you put someone in front of a system where you can immediately start tweaking attributes, properties and code, press a button to run it to see its effect, most people would be interested enough to keep going. It's how you get to that point of having that system in front of you. In most cases this isn't simple. Even in the case of PC Logo, having to get through installation and running the program and figuring out the first things you can do, can be obstacles. Maybe web pages and simple HTML are a good place to start?

Sadly, current trends in front-end dev (yes, I'm looking at you, React) make this pleasure a thing of the past. The front-end tooling required to produce today's web apps is soul-destroying even for seasoned devs who have survived Enterprise Java config hell. Maven's a piece of cake compared to webpack.

You have a good point in that figuring out how to set everything up to code is a hindrance for those wanting to learn to code.

My start in "real programming" was after I received my TRS-80 Color Computer "for Christmas" (my parents actually purchased it much earlier for me, with my understanding that I wouldn't be getting much for actual Christmas - not a problem, I was thrilled).

Plug it in, turn it on, and bam - there you were at a flashing prompt, begging you to type in some BASIC code - which, there was a "tutorial manual" helpfully provided to teach yourself with.

Today, there isn't much like it any more to do the same. The closest would be the various online REPL systems for various languages; these fix the issue of setting up an environment, but very few (there are some) are designed to teach the beginner (to the language, or in general) programming.

I do not think your professional experience is representative in any way of what is better for very young kids.

I know some musicians and I can tell that actually playing the instrument is not the hardest part. That does not mean a toy piano is not a good present to get a 5 years old started. And if painting the keys in colors instead of black and white (icons instead of text) makes the kids more willing to play it, I think it is something very interesting (more for toy piano manufacturers than musicians though).

Absolutely. "Programming" with cute icons may not make you a "great" programmer, but that's not the goal. It's to get you interested in the idea of telling a computer to do cool things.

As an example, my daughter had no real interest in doing anything with a computer until we showed her she could move Moana's raft around with some Scratch/Blockly code in a Disney Hour of Code game. Therefore, I think these games are absolutely worthwhile. Let kids start learning the "hard parts" of programming after we've got them hooked!

Maybe playing the instrument isn't actually the hardest part for a pianist, but for us string players... ;)

When I was a kid computers were just a text interface and you had to type code just to load the games (originally with BASIC, then with DOS). In the BASIC era writing games was as easy as turning the computer on. OK you'd need machine code to do anything advanced but BASIC was a fantastic gateway drug (for want a better description).

Trying to rekindle this was one of the aims of the Raspberry Pi but even with that, there isn't anything quite like the accessibility that the microcomputers of old had. Except maybe web development but in my personal opinion HTML+CSS+JS teaches bad programming habits (unless you're particularly OCD and disciplined).

So I'm all for games like that in the article. In fact in some ways, it reminds me a lot of LOGO (another good gateway drug).

I grew up with BASIC as a gateway drug, too (that's a great way to describe it on a number of levels!) and PICO-8 and the like are the closest modern equivalent I've seen to that kind of environment. Simple games with simple graphics plus the ability to drop into a code/sprite/etc editor with the press of a key.

The only real negative to me is that Lua, like most any modern language (i.e. ones that regularly use indentation), doesn't seem particularly well-suited to being edited in a very low resolution window. But it's still the closest I've seen to something that recaptures that "immediate" magic of ROM BASIC.

I think the problem with trying to rekindle this for the current generation of kids is that computers are simply way more advanced now than they were for us. We didn't have a pocket-supercomputer with a touch interface, realistic games, and an AI assistant that speaks and (sometimes) understands our speech. Being able to draw a triangle on the screen with a few commands was amazing to us, not so much for our kids.

I feel like this is something that helped a lot of people learn. The first programming language I started to learn was TI-BASIC on my calculator because I was bored to death. I wouldn't really recommend a BASIC-esqe language as someone's first. I really with we had some easy preinstalled language on Windows machines. Maybe have Python come with it or something, and some way for people to know it's there.

Yes, this. Number one thing that will flatline my love for learning a new language is setting up the environment. When I'm 10 pages deep into stackoverflow search results trying to fix an obtuse package's error code, I'm close to giving up.

I'd say in general, the biggest problem with most tools is that installation on average tends to require too much effort. People experienced with the tools don't tend to work on fixing that because it's a solved problem for them. But the number of tools I've rejected because I was not yet convinced it'd be useful and so was unwilling to invest the time in getting them working is huge.

Every time I do this, I wonder how any beginner ever gets their environment set up. Because as soon as something goes wrong (which happens more often than not), I'm drawing on years of experience that the beginner won't have. My first was C++ on Windows 95 and luckily we had internet at the time - it still took me multiple days before I got Hello World working.

I think browser-based language introductions are great. They remove a huge obstacle and get you into the language right away.

I agree. Coding is not fun because writing a command that a machine can compute is inherently enjoyable. Coding is fun because you can manipulate a machine and build something you want that didn't exist before.

I downloaded GameSalad one weekend. My 6-year-old son and I ran through the tutorial which took about an hour. Part way through he got distracted. He spent about 20 minutes changing movement speed properties, object colors, & sizes. I was happy to see him get engaged and just start experimenting. While he did not learn how to code, the seed was planted that creating mobile games is something within his reach.

"Naughty things": My first BASIC program asked for your name, then printed "Hello <name>", except if you entered my sister's name, where it would print "Haha, you are stupid!".

I have experimented with building an Android app [1] for graphical programming, but except for some more-or-less funny exercises slightly inspired by Rocky's boot, it feels like graphical programming might be too cumbersome in terms of input effort per instruction. Of course this might be because "my" UI is crappy, but I don't really have good ideas how to make it an order of magnitude better...

So I have started switching to text-based [2], will see how that goes..

1) https://github.com/stefanhaustein/flowgrid

2) https://www.youtube.com/watch?v=zY4TIW3jDM0&list=PLhEJPa6dXG...

> I actually don't know any great coders that learned to code through these kinds of games.

How many people do you know who were exposed to these kinds of games as a child, and are now old enough to plausibly be great programmers?

It's just an anecdote, but back in junior high I literally ended up teaching my computer class with a silly programmable pacman game; it looked very much like the ones in this post. Long story short, the teacher rolled with it and so did the rest of the class. (I really should dust off the disks and back this stuff up to Github...)

Anyway, the only kid I know from that class that also ended up a programmer (at Google) spent it getting in trouble for messing with the school network by editing Windows config files.

My two earliest programming memories:

- Using logo to draw stuff, and watching my brother using it to draw a recursive tree and copying him

- Copying[1] games out of old magazines to play them, including torturous sessions with my brother where one of us would read out the assembler array[2] and the other would type it in.

Now, I might not be great, but I'm definitely Good Enough™, and I would count those two experiences as protozoic versions of this kind of educational coding software: make a picture do something, plus video games (because kids like video games).

[1] Yes, I was born for stack overflow

[2] This was an Amstrad c64, and some of the game was BASIC, but for the clever stuff they'd encode a giant array of machine code and just have you type it in. This got me interested in assembler, and I learn (some) while I was there.

"Copying games out of old magazines to play them" - a big yes here. I learned SO much from tracking down typos. It forced you to look at the code, understand how pieces of it worked, so you could fix it. Your reward? A fun little game. That was enough incentive.

...except those games and other pieces of code that were machine language "disguised" as a BASIC loader with an almost literal ton of DATA statement to POKE in all the machine code.

You'd sit there for hours, typing page-after-mind-numbing-page of DATA statements - numbers and commas would blur together.

Then - once you had it all typed in (largest one I typed in had to have been around 16K of text - took up around 10 or so pages in the magazine) - you were smart to save it to disk or tape (actually, the smart thing was to save it incrementally as you worked, and break up the task over a few sessions).

If you didn't and you ran it and it had a bug - CRASH - computer would give you a visual (sometimes audio) "lightshow" if you were lucky, but usually, the computer would just hang or reboot - and all the code would be lost.

The fun was just beginning!

Now, if you still had the code saved - you could load it back up, and start the arduous process of comparing the code to what the magazine printed. You'd hope like hell that the magazine wasn't misprinted, or hadn't left a section out, or that the printing wasn't illegible (and you confused things - seriously, wasn't that one of the charms of those days - the listings were printed off a cheap 9-pin dot matrix printer then lithographed for printing - causing all sorts of artifacts to confuse the typist?)...

Some magazines printed next to each line a checksum, which you could run a program to type the lines in and use to compare with the number (it would calculate it on the fly) - but as a kid, I was too stupid to know what it was for, and it seemed pointless.

I probably should've read the fine print on that one, but I probably couldn't - because it was too schmeared by the cheap printing...

Ah then there was MLX! https://en.wikipedia.org/wiki/MLX_(software)

TL;DR - MLX was a BASIC app for the C64 that allowed the key entry of hex code with checksums and live validation.

They weren't all that long or written in machine code. I mostly typed in BASIC programs that fit on a single page. The games weren't that sophisticated, obviously, but it was still fun.

Exactly. yay 80s

Happy days at school - about 1978/9 - I was 13...

Commodore PET 3016 - PET BASIC

Acorn System 1 - 6502 machine code

BBC Micro (pre-prod unit) - BBC BASIC

Later at home: Commodore 64 - BASIC and machine code

I didn't learn coding from games explicitly for that purpose. But I definitely credit games in general for some ability to navigate arbitrary rule sets in order to accomplish a goal... Oh, hey, that sounds a lot like programming!

To be honest you can say this of every subject in school; they all exist in a vacuum and are missing a ton of knowledge to actually use practically. Rote learning. Revise for the exams then forget etc. At least this is a way to introduce them to the concept of coding, and they can learn the other stuff later if they decide to pursue it.

The primary problem for many people (including kids) is motivation. Struggling, especially in the beginning, can be demotivating. It can even make people feel like they must be a failure or that the material "isn't for me".

Introducing basic programming visually then slowly transitioning into text should allow more learners to get over that hump and imagine themselves doing fun & interesting things. (Some kids will jump directly to more difficult tasks and eschew non-text immediately).

I don't think we have nearly enough evidence to say whether any of these kids will be "great. Not to be rude but your anecdotes aren't data either.

For “real coding” sure, that holds true. But as for what got me hooked, and what made me study CS, it was LOGO and seeing the turtle do really neat images with surprisingly few instructions—I still have a vivid memory of that day and that feeling of deep curiosity about what else could be created by that turtle.

> I still have a vivid memory of that day and that feeling of deep curiosity about what else could be created by that turtle.

If you haven't and are curious - you should look into what LOGO can really do. It's actually quite a complex language, far beyond just simple "turtle graphics". Unfortunately, most of the rest of LOGO was never taught to many people, and so all we learned was the graphics part.

But LOGO itself is surprisingly complex, and has more than a passing nod to LISP in what it can do.

I recall learning LOGO as a kid - but wrote it off as a "toy language" even then, until one of the magazines I got at the time (which I typed in BASIC games and other things from) had a game of Monopoly coded entirely in a version of LOGO that computer could run (I never did type it in, because I didn't have the language - and it was a fairly expensive piece of software from what I recall). All the graphics, logic, and sound, plus i/o, scoring, disk handling, etc - were all done in LOGO. It impressed me then; still does, in fact.

The hard part about coding for 5-10 y.o. kids is typing without errors. Programming is hard as it is, adding typing errors makes it even harder - 1 mistake and computer is yelling at you and you have no idea what went wrong.

I can't say that I'm a great coder, but I learned from ZZT and Megazeux back in the early-mid 1990s. No idea if something like that would work today, though, and both ZZT and Megazeux seem to be stagnant at present...

I agree the hard problems are ones that aren't in the code... but not the ones you list. The ones you list are only a particular sort of intellectual devolution that has occurred with Javascript. Other languages do not suffer the same psychotic level of being nothing but a morass of constantly churning half-broken tools, a new framework every week, platforms shifting like sand, debugging made into a herculean task, etc. If you're writing in a sensible environment, you can rely on your tools, you can learn them and rely on them for ages, etc.

Reply on news.ycombinator.com