Text Is Keeping Kids from Coding

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.

I've since applied this logic fairly universally and I'm going to apply it here: SpriteBox does not exist to teach kids to be great coders, it exists to sell copies of SpriteBox.

The challenge of text undoubtedly is a blocker to the sales of SpriteBox.

I do not believe that it is a blocker to a kid becoming a great coder.

Coding absolutely requires a high level of comfort with abstraction. It requires the ability to mentally model abstractions, maintain relationships between abstractions, and make a (sorta) concrete reality of those abstractions.

Coders must be able to make intuitive mental leaps based on disparate and distributed data. Often the solutions that coders come up with are based on little bits and pieces of the puzzle based on SO answers, documentation, blog posts, example code found on github, etc. The solutions to tough problems are rarely found in a single neat all-explaining resource.

So... if a kid is having trouble with text I would candidly posit that the kid may not have the ability to deal with abstraction that coding requires. Not a problem for the industry as there are already enough coders who have this issue, but it creates a sales problem for SpriteBox.

EDIT: typo, clarity

I don't know programming was supposed to be hard. I didn't know some adults did it as a job. I just knew that if I learned what was in the books, I could do stuff. So I started reading, and I never ran into anything that was beyond my grasp. I do recall reading one part that said a person who did not draw a flowchart before writing a program was either a genius or a fool and resolved to be a genius (hey I was 9). Not even refusing to create flowcharts prevented me.

I feel in love the day I wrote: 10 PRINT "I LOVE YOU MOM" 20 GOTO 10 And filled the screen then called my mom into the room to look at it.

Text is not keeping kids from coding. Adults are. Adults making kids think it's difficult, adults standing in the way and shuttering them into unnecessarily dumbed down environments, standing over their shoulder and making sure they don't do anything inappropriate, etc. But more than anything, adults filling kids free time and never giving them the opportunity to just sit down, have a quiet few hours, and figure things out.

Text IS scary, because it's nontrivial. There's a reason schools start with the ABCs and spend the first four years of school teaching kids to read. And even then we don't stop there: middle school focuses on grammar, and high school focuses on creating long-form content.

Programming is similar: it's non trivial to stand up a knowledge base to be a programmer.

I think the big difference is that most programming classes start in high school or college, well after we've mastered text in general.

But that doesn't mean it can't be done. The key is to start small: don't expect novel-sized programs, expect words and sentences, and make those words and sentences FUN.

For example, my son has had a TON of fun with the micro:bit [1], and it's scratch based system, and Swift playgrounds. [1]

[1] http://microbit.org/

[2] https://developer.apple.com/swift/playgrounds/

A great preparation they should learn some math or ideally be having fun with their friends, running around outside or perhaps art or something creative.

  move(.up)

  move(up)

Why not:

  move up

  pen down
  forward 100
  right 90
  forward 50
  pen up

- Numbers are keeping kids from learning math. - Text is keeping kids from reading. - Too many words are keeping kids from listening to lectures.

I don't understand why people find it difficult to just teach a kid how to do something rather than wait for some miracle solution.

A couple of years later, and I was back teaching ICT and the curriculum was being axed, in favour of Computer Science, so I decided to teach myself a little Python, and ended up being a secondary CS teacher in a fairly elite school.

What strikes me now, is at no point did I make a connection between the graphical language I was using back then and the text based languages I would go on to use later. In hindsight it seems obvious that if I enjoyed controlling pixels on a screen with blocks, I would probably enjoy doing it with text. It's anecdotal, but it has turned out to be true.

In my professional capacity as an educator, I have seen how engaged young students can be with graphical languages such as Scratch, and how those same students eventually want the power and control of more powerful languages. These types of games don't teach everyone how to code, but they do awaken a desire to control and manipulate computers, in people who might otherwise never have realised this ambition.

For people who say that the hard part of programming is "not in the text", watch a seven year old try to control a turtle in Scratch and then watch them try to do the same thing in Python. Typing speed is a major factor, as is understanding the importance of case and white space. Not to mention the symbol nightmare of commas, full stops, colons, semi-colons, single and double quotes, hyphens, underscores, equals and double-equals, square braces, curly braces, angle braces, and parenthesis.

That's because real programming is complicated.

Software systems, with billions or even trillions of switch points, are the most complex things humans have ever built, by far.

We have tried mightily, for many, many decades, to make programming simpler and more accessible. The problem: instructing a computer precisely and unambiguously what to do means you have to precisely and unambiguously specify...what to do! There's no getting around it, just like there's no way (yet) to write a novel without choosing words and pushing letter keys.

The graphic approaches quickly get tedious beyond toy examples. Graphs are fine for telling your Lego robot what to do, but with the Web and app store overflowing with cool apps, the bar for grabbing and keeping a would-be programmer's attention is now quite high.

My bet: non-programmers will "program" at scale when where's a fundamentally new computing model. Machine learning & deep learning are the most promising for this, I think: instead of telling the machine precisely what to do (and how), you show examples of the behavior you want and give feedback when it's wrong.

I don't see much difference teaching them programming with a real programming language. They have to be forced to embrace it first.

Of course they start learning concepts in preschool, but it's not an obligation to put your kids in preschool (most parents do, but you don't have to)

So isn't it a problem with text, reading, words... than a specific code problem ?

As a parent, I'm going to teach coding to my kids, starting next year, they'll be 8 yo. I'll start with scratch then probably some python. And I'm lucky my kids are both fluent readers. But I'll still start with scratch.

So I convert the text to pdf and add some flavor, pictures etc. Then people read it.

edit: by "large" I mean, by my standards, ridiculously small, like 300 to 3000 words top, but people are scared by simple text.

I mean, how does move(.up) look like plain English? What's wrong with "move up"? Are we really so blind as to not realise that any normal person looking at that is going to get the strong impression they don't know what the hell is going on? Hell, I don't know what's going on. What's with the period? What happens if I don't type it? Fragile and incidentally complex.

Now to be fair there are intrinsic differences between typing in a blank text box and dragging and dropping icons. You can type anything in a text box, while icons present a limited selection. This hurts discoverability, which is why the author saw better results when they gradually swapped out the icons for text. Dragging and dropping is an atomic transaction which can be cancelled with good feedback if the user attempts something invalid; this is not quite so easy with typing, because valid code must be reached through invalid states on a letter-by-letter basis.

But proper coding in a Turing-complete sense (which none of the games seem to offer) involves defining your own symbols and wrestling with abstract notions like iteration that lend themselves increasingly badly to representation in sprite form. Scratch is a good example of a system that attempts to use the best of both worlds - its building blocks are text-based, but selectable from a limited number, atomically placed, and statically checked to practically preclude syntax errors. Text itself isn't intrinsically bad.

Lastly - it's a shame the industry moved on from BASIC. Programming was never more accessible than when the average personal computer booted to a REPL of a standardized, easy-to-use language.

The problem as I see it is that parents across the country are trying to prepare their children for a job landscape which may change radically between now and when they graduate high school by getting them while they're young and attempting to introduce them to coding as early as 3. Not programming, not learning how to solve problems with an algorithmic mindset. Coding. As in getting them comfortable with slinging around functions that build a website using magic.

Really, we should be teaching them to do the thing that we're trying to do with programming languages in the first place, which is solve problems with an algorithmic mindset. I think SpriteBox gets it, kinda, where it falls short is that in the end they're still hung up by the whole "let's teach kids how to code" trap and gradually replace the icons with text and do this weird thing where icons are indented because text-based code is indented. In the end kids know how these languages work, and how to do simple things with them, but they've learned all of this within the context of what looks like a platforming game. Extending this to the act of creating something is different.

If you really want to teach kids how to program, create an environment that teaches them how to build and create something cool using a few simple and easy to understand rules. Allow them to experiment with the rules to see what happens. Make it so that the upper threshold for how you can bend the rules, combine rules, etc, is to all concerned essentially non-existent. Enable and reward creativity, which is something a lot of "coding" games and toys and whatever simply don't do. They enable and reward you to help a cute robot walk in a damn line.

Currently, I'm working on a web-based game development language. Essentially, I would like to create a simple programming language, like BASIC, Lua, or others, and provide built-in libraries for 2D game making.

Much of my formative programming experience was using using Blitz Basic, a game language. As a teenager, I was able to use it to create games easily.

With all of the visual and graphical game development kits available today, I feel that it has become more difficult to learn programming in the way that I did. Providing a programming-based offering is the only solution, I think.

When constructing functions and loops to coordinate and move or draw sprites, I think it becomes much easier to think about the logic of a computer program and how that knowledge can be practical.

What I would concede is that we had fun books to learn from, like these ones for the Atari http://www.atariarchives.org/.

https://scratch.mit.edu/

    > Things we love about blocks

    > 1. Blocks lower the barrier for entry
    > 2. Less frustration
    > 3. Useful hints
    > 4. Visual reinforcement of structure

    > Things we don't love about blocks

    > 1. Penalizes fast typers
    > 2. Higher demand on short-term memory
    > 3. Small space of visual cues
    > 4. Poor Accessibility

I like their approach to transitioning from an icon/diagram approach to a text approach. It highlights that text and iconic/diagram representations don't have to be a false dichotomy. These two ideas can complement each other if done carefully.

If there's one thing I'd love for every person who aspires to create a visual development environment is this: Visual representations should be used to enhance and project program structure, not to replace text altogether. Much in the same way that the CoffeeScript --> JavaScript translation page illuminates the language, I believe we should be projecting our text languages into various clear visual representations.

Having been made to suffer through a few Enterprise Integration Tools (BizTalk, MuleSoft) that take a diagram first approach, I concluded they would be much better served if they took a text-first DSL approach that is isomorphic with a diagram representation. By binding the two at the hip, working with the diagram based UI would visually teach the user's understanding of the DSL syntax. In the other direction, playing with the text interface could instantly reveal how the parser is interpreting the intent of the program.

Again, I'd love to see more people take perspectives past the usual false dichotomies and start researching how different approaches can complement each other rather than compete for attention and mindshare.

Another is that we no longer have the text-based interface in things that we use. In the classic computing era, text games like "Zork" were popular, and even DOS and *nix text shells were the norm. Even adventure games like Sierra Online games had graphic view but had text interface. Perhaps text-based user interface could lessen the anxiety of text in coding, but I think that we no longer value text UI.

Instead, everything is GUI now, with touch-interface on iOS/Android in the mix - and perhaps someday, we no longer will have mouse/keyboard, but rather just verbal and physical interface. By then, we can program things using complex language such as "I'd like to move the yellow box sprite on top of the tree to the left about 50 pixels", then programming code becomes more approachable to average human. We are already on our way, with Alexa and Siri.

Ironically, a lot of business software development works like this (not that it should, just that it does). You have a bunch of BAs who churn out flow charts and hand them over in the form of requirements to developers who implement that logic via syntax.

The algebra comparison is telling; "a study was done that showed that 92.9% of kids using the app achieved mastery of basic algebra after 1.5 hours of play" - where's the similar comparison?

And, how do we measure 'mastery'? Because the mathematical lexicon requires numbers, not pictures, and coding non-trivial things are done with languages that are text, not pictures, the way we test that is also important.

Note that fundamentally I agree with their conclusion that, pursuant to being marketable, they HAVE to use pictures, because people's impressions matter. But in terms of actual benefit, I'd want to know more details.

Text is an additional layer of abstraction probably involving language and communication systems outside the human visual system. The text is a label or abstraction for the visually represented concepts which must be encountered and learned first.

There is a consistent pattern in learning mathematics and other technical areas that most students learn better and faster with pictures and concrete examples. Abstraction comes later.

This idea is important, but trivially simple to an experienced programmer so easily dismissed. It is not that obvious to a beginner tho.

How do they square that with the presence of parentheses and the use of a syntactically significant period?

It seems strange they didn’t start with something that looked more like Logo before concluding the text was inherently off-putting.

I’m not sure their conclusion was wrong — but I’m confused about the point where they gave up with text.

Also - the final syntax at the end is ugly as hell. Is that the best they can do?

Finally - not even a hat-tip to Scratch/Blockly? If they aren't aware of it then it's very odd. If they are and decided not to mention it - I find that equally odd.

what we lack in the computing world are games they can make by following a book, eventually they'll want to diverge from what's in the book and make their own stuff, the problem is no games are too complex and a simple game might not hold their attention.

Something like Mario Maker is where they probably should start but the extra options to change variables and access scripts later on.

Something I've noticed all the years, teaching is HARD. Well, teaching effectively and efficiently is.

Sometimes I wonder if being limited to text adventures when I was really young was a benefit. If I typed something that the computer didn't understand, it told me so. It forced me to have patience and to learn to look up the right way to ask for something.

But it is complex. Anything beyond the most basic examples delve into the concepts of calculus.

If we don't expect most children to comprehend advanced mathematics until they're teenagers, why would we expect most of them to grasp anything but the most basic conditional logic until then.

That's not to say that we shouldn't attempt to teach children coding at a young age, but the idea that anyone but a few would understand genuine coding at the same developmental period where they're learning to spell "dog" and to add 2+2 is a bit ridiculous.

I wonder if the authors consulted a child psychologist before beginning their endeavor.

Kids who want to learn how to code should just do it with regular tooling. You don't need any special approach.

I learned it at 7-8.

I remembered that in the first grade of elementary school, when I was 6 years old, that we used these workbooks with tear out pages to do these "math" problems. Simple addition and subtraction, IIRC.

But these workbooks didn't use numbers and symbols; instead quantities were shown by fixed objects (like coins, or other images), symbols were replaced by something else, but I don't recall exactly what (maybe simple words - so not completely "text free").

On a different note - a few years ago my wife asked me to look over a friend's child's homework, to try to figure out how to do the problems, and what the answers were, because her child was having problems doing the homework, and neither she nor my wife could figure it out (neither are very math fluent).

I looked at it - and at first it was "gibberish". There were some "standard" symbols for multiplication and addition, subtraction and the like. But everything else was symbols.

Like, there'd be a problem that visually was something like "circle + ? = triangle" or "2 square + 3 triangle = ?" (I may be mis-remembering things, too). It was very confusing, but fortunately the worksheet (which was all I had) had a couple of "example problems" and their solutions included. I studied things for a bit, then it dawned on me:

It was algebra - but it was being taught with symbols instead of numbers, and the solution (and how to arrive at it) was pretty simple to understand, once this was realized. In short, numbers are symbols (hey, I'm not a big math whiz myself - I know just enough to blow my foot off) - so it made sense that swapping these out wasn't that big of a deal, provided you had some base knowledge about the rules (which were provided by the examples).

I was able to figure the problems out, then write down how things worked for her (and her child) to read and understand. AFAIK, the homework was completed and turned in with correct answers.

At the time, her child was probably in the 4th or 5th grade, and it was interesting to me that the school was using such a system to teach algebra at an earlier age than what I recall having learned it (my first real algebra class wasn't until 7th grade, though in elementary school in 5th and 6th grades we had been doing some of the basics beforehand - I guess for "prep" for the coming years).

So, in the case of coding, I can see how this idea of starting with "abstract icons" (somewhat) to represent certain coding statements and ideas - and gradually phasing in text - seems like something that should work (and they seem to prove that it does, too).

Oh - another early example from when I was younger; arguably I first started to "program" when I got my first programmable toy - a Milton Bradley Big Trak. It's keypad used mostly symbols (plus some numbers) - but had other symbols for other actions...hmm.