Text Is Keeping Kids from Coding(medium.com)
medium.com
Text Is Keeping Kids from Coding
https://medium.com/@dannyyaroslavski/text-is-keeping-kids-from-coding-b70988dd7541
172 comments
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.
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?
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.
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
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!
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.
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_...
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/
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.
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.
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...
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
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?
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.
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).
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!
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).
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.
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 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.
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 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?
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.
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.
- 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...
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.
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
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.
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.
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.
I started my professional life as a stockbroker and I remember my mentor saying "Money Magazine does not exist to advise individuals to make great trading decisions, it exists to sell copies of Money Magazine."
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'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
As someone who's grown up with computers, I think the biggest difference I see between ”technical” and “non-technical” people is a willingness to try things out and not be put off by intimidating new things. If you are willing to explore you will eventually figure it out, but if you are afraid you'll never get anywhere.
OP here. You're right that SpriteBox does not exist to teach kids to be great coders. It exists to get as many kids as possible engaged with what programming is and excited to learn more. Especially kids who may not be 'naturally inclined' to code.
What makes your argument fall flat is, we already had LightBot: it teaches kids to program with icons only. If text was a blocker for SpriteBox, why would we pursue it at all?
You end by saying that kids who fear text are not well suited for coding. That's like saying kids who fear symbols are not well suited to math. This kind of sentiment is what drives people to believe that they should give up things that they may excel at given enough time and interest. SpriteBox, like many coding apps, is about sparking that interest.
As for text, the real reason we tackle that is because there's a real gap for people between icons and textual programming: some people have this disconnect between what they perceive coding is. Is visual coding "real"? Are formulas in excel "coding"? These are answers programmers can answer, but not people unfamiliar with code.
What makes your argument fall flat is, we already had LightBot: it teaches kids to program with icons only. If text was a blocker for SpriteBox, why would we pursue it at all?
You end by saying that kids who fear text are not well suited for coding. That's like saying kids who fear symbols are not well suited to math. This kind of sentiment is what drives people to believe that they should give up things that they may excel at given enough time and interest. SpriteBox, like many coding apps, is about sparking that interest.
As for text, the real reason we tackle that is because there's a real gap for people between icons and textual programming: some people have this disconnect between what they perceive coding is. Is visual coding "real"? Are formulas in excel "coding"? These are answers programmers can answer, but not people unfamiliar with code.
> 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.
You do realize SpriteBox is targeting kids in lower elementary school?
Regardless, you didn't really identify any flaws in the primary thesis: decoupling the process of learning how to write error-free syntax (with raw text) from the more important development of an actual understanding of the underlying fundamental concepts may provide better results in many cases, perhaps especially so with younger kids.
You do realize SpriteBox is targeting kids in lower elementary school?
Regardless, you didn't really identify any flaws in the primary thesis: decoupling the process of learning how to write error-free syntax (with raw text) from the more important development of an actual understanding of the underlying fundamental concepts may provide better results in many cases, perhaps especially so with younger kids.
This. But also the problem with the OP is they seem to show people samples of a programming language without any explanation, expecting them to intuitively figure out the syntax and semantics.
There's no way this won't be confusing.
There's no way this won't be confusing.
I learned to code when I was 9 years old. It was in text. No one helped me. I found a couple books with my parents computer, 'Introduction to BASIC' and understood that if I learned what was in the book, I could make the computer do what I wanted.
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.
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.
"we got responses that estimated ages 9, 10 and up- "
The point is text looks too complex for younger kids. 5 year old won't sit down for a few hours and figure out things. He will just get bored.
The point is text looks too complex for younger kids. 5 year old won't sit down for a few hours and figure out things. He will just get bored.
Other than sales of this app, why is it necessary for 5 year olds to be programming?
People lie on a spectrum of ability. An app that works with 5 year olds that have a knack for programming will work well with 8 year olds who may not. Striving for an app that's approachable at any age is the real goal.
Maybe because their parents want them to. It's like dads teaching their kids how to use tools and fix things. Something they find enjoyable and useful, want to learn their children to have something in common.
But probably they just read somewhere that programming is the future.
But probably they just read somewhere that programming is the future.
I'm the dad of an 11 year old boy and a 8 year old girl.
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/
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/
I dont understand why elementary school kids need to code at all. Most of the developers my age didn't even see a computer until high school or college and they're great developers.
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.
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.
I feel like this needs to be higher up. While of course any parent would want their child to meet and exceed any academic standards you or the school system set, childhood is the only time in your life where you're relatively free to make mistakes with friends and relationships, and that's how you learn to be a better person.
It's a lot more difficult to learn that later in life than programming, in my opinion as someone who didn't start coding until he was in his early 20's but still struggles with relationships because of a unrelated, intense academic focus as a child.
It's a lot more difficult to learn that later in life than programming, in my opinion as someone who didn't start coding until he was in his early 20's but still struggles with relationships because of a unrelated, intense academic focus as a child.
>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.
Not sure why there is a dichotomy between this and playing a game on phone for 30 minutes to learn coding.
Not sure why there is a dichotomy between this and playing a game on phone for 30 minutes to learn coding.
Your text notation was:
Why not:
move(.up)
move(up)
Why not:
move up
pen down
forward 100
right 90
forward 50
pen upOP here.
So yes, we could have gone the "move up" route. In fact, we did at one point! Even then though, icons were far and away less intimidating.
The problem is, real programming languages don't eschew punctuation, Logo included (once you include loops and such). AND our primary goal was to get kids familiar with reading real looking code (in this case, Swift).
The last option would be to start with "move up"s, and then introduce punctuation later... but then players would get confused as to why punctuation, unneeded before, suddenly becomes required?
Finding the middle ground of jumping from icons to textual code (with punctuation) resolved all of these issues best.
And yes, we've read Mindstorms ;)
So yes, we could have gone the "move up" route. In fact, we did at one point! Even then though, icons were far and away less intimidating.
The problem is, real programming languages don't eschew punctuation, Logo included (once you include loops and such). AND our primary goal was to get kids familiar with reading real looking code (in this case, Swift).
The last option would be to start with "move up"s, and then introduce punctuation later... but then players would get confused as to why punctuation, unneeded before, suddenly becomes required?
Finding the middle ground of jumping from icons to textual code (with punctuation) resolved all of these issues best.
And yes, we've read Mindstorms ;)
Fair enough. I still disagree with your conclusion. Text isn't keeping kids from coding, throwing them at Swift's text (in your case) was. A simpler and more forgiving syntax, or a UI (a very capable IDE in this case) that walks them through the syntax (showing them only the valid options at any given point) since you chose a relatively complex syntax would also have helped. You achieved that via pictographs transition via pictographs, which ought to be effective (you won't be changing the rules of the game on them, from their perspective, just the notation used).
Pictographs are useful, and effective. I won't deny that. But kids can, and have, learned to code with textual languages when those languages were more effectively chosen and developed for the task of teaching kids. It's unreasonable to make such a strong claim.
We could make the same claim about math and kids (Notation is Keeping Kids from Mathing!), and it would be superficially true, if you started kids off with a notation like geometric algebra (bi-vectors, tri-vectors, multi-vectors, oh my!), instead of arithmetic.
Pictographs are useful, and effective. I won't deny that. But kids can, and have, learned to code with textual languages when those languages were more effectively chosen and developed for the task of teaching kids. It's unreasonable to make such a strong claim.
We could make the same claim about math and kids (Notation is Keeping Kids from Mathing!), and it would be superficially true, if you started kids off with a notation like geometric algebra (bi-vectors, tri-vectors, multi-vectors, oh my!), instead of arithmetic.
The point I want to stress is that text is keeping kids from coding. Like I said, even with punctuation-less text, the game was deemed difficult. Simpler and forgiving syntax simply would not help. The IDE in the game is actually extremely forgiving and could just as well walk players through the syntax, but interest levels then drop off. This is the difference between in theory and in practice.
Yes there are kids that had no problem with text or without text. Of course kids can and have learned to code with textual languages. Same with math.
The main idea here is that you can get an even larger population of kids doing math and coding, and engaging, by adopting pictographs first. As demonstrated in DragonBox. As seen in our own testing.
Yes there are kids that had no problem with text or without text. Of course kids can and have learned to code with textual languages. Same with math.
The main idea here is that you can get an even larger population of kids doing math and coding, and engaging, by adopting pictographs first. As demonstrated in DragonBox. As seen in our own testing.
Arbitrary syntax rules. Why would they be surprised that people find it confusing?
> What does the `.` do? Why can't it just be:
> move(up)
One of the latter pictures shows "swift syntax", so I expect that's that: .up is a shortcut for a variant in a sum type, as it is in Swift.
> move(up)
One of the latter pictures shows "swift syntax", so I expect that's that: .up is a shortcut for a variant in a sum type, as it is in Swift.
Not knowing Swift, I would've guessed something similar. But that hardly makes it a suitable language to dump on kids. For an educational language, you need to start off small with intuitively sensible constructs, and build up.
You can move towards that syntax, but you can hardly start there.
EDIT:
Actually, I'm going to make a stronger statement. You shouldn't make an educational video game, and particularly an educational programming game, until you've read Mindstorms and learned what Papert and others studied last century.
You can move towards that syntax, but you can hardly start there.
EDIT:
Actually, I'm going to make a stronger statement. You shouldn't make an educational video game, and particularly an educational programming game, until you've read Mindstorms and learned what Papert and others studied last century.
I thought the same thing when I saw this.
[deleted]
Why is is this a problem?
- 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.
- 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.
That numbers idea has been held by a lot of smart people. For a while some countries taught set theory before numbers.
I offer my miracle solution: text is a bunch of tiny pictures.
Text started as tiny pictures. Trouble is, there's an unbounded amount of things you need pictures for. The great thing about phonetically-based writing is that a tractably small number of symbols can combine in a natural way to express anything.
I took a break from teaching for a year, to be a 3D graphic artist, using Cinema 4D. The software had a drag and drop, node based, coding environment called Xpresso, that I became quite adept at using. I can remember showing it to my programmer brother, and he told me if I liked using Xpresso I should try a proper language. I dismissed him, saying that typing text held no appeal for me.
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.
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.
You might be interested in the Luna programming language/dev environment. It's designed to have a 1:1 correspondence between the visual, node-based environment and the written forms of the code. I haven't been able to try it yet since it's still in closed alpha, but it looks very intriguing! Given your experience with a similar visual language and later interest in more conventional programming, you could make a good case for getting into the alpha. There's a signup form on their site (one for the alpha and one for their newsletter, depending on your level of interest).
http://www.luna-lang.org/
Last HN discussion: https://news.ycombinator.com/item?id=14612680
http://www.luna-lang.org/
Last HN discussion: https://news.ycombinator.com/item?id=14612680
> We showed the above to playtesters (kids and parents) who told
> us what we didn’t want to hear: the game looks complicated.
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.
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.
> The graphic approaches quickly get tedious beyond toy examples.
The things I have seen created in LabVIEW would absolutely astound you - not just in their complexity, but in the fact that they work at all (for various values of "work"), and that someone somewhere out there is able to maintain them without going insane.
/then again, maybe there are more insane LabVIEW developers than I know...
The things I have seen created in LabVIEW would absolutely astound you - not just in their complexity, but in the fact that they work at all (for various values of "work"), and that someone somewhere out there is able to maintain them without going insane.
/then again, maybe there are more insane LabVIEW developers than I know...
Text is scary. They had the same barrier transition from picture books to books without pictures. It takes kindergarten where the set up of school give them the perception that they had no choice but to embrace the initial difficulty opened the door of wonder for them.
I don't see much difference teaching them programming with a real programming language. They have to be forced to embrace it first.
I don't see much difference teaching them programming with a real programming language. They have to be forced to embrace it first.
Well, to be fair programming is (currently, at least) an optional skill competing with soccer, guitar, and video games for mind space. Reading is the lowest bar for practically everything in modern life so there's more tolerance for sub-optimal teaching since we all are willing to hold feet to fire. Until coding is as ubiquitous as reading, we're going to have to do better.
I wonder if it isn't the text that's putting parents off, but the specific lesser used symbols like parentheses and the such. For that same reason I believe parents think that math is hard in comparison to writing, due to the large amount of domain specific iconography. I also wonder what effect leetspeak might have on bridging that gap, even though it's probably not the best solution.
Not a new problem:
I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make them first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it. — Grace Hopper, explaining COBOL (and by extension many modern style guides).
I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make them first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it. — Grace Hopper, explaining COBOL (and by extension many modern style guides).
That's a fantastic quote.
My reaction to maths is that the biggest challenge the symbols poses is that I need to remember each one of them and what to call them, whereas with text keyboards I can at least make an educated guess at pronunciation that other people will understand.
This, to me, is a massive barrier with maths. If I can't read it out without learning how to mentally translate a symbol to a word, it's a hassle. I have too many things I can spend my time on to deal with that.
My reaction to maths is that the biggest challenge the symbols poses is that I need to remember each one of them and what to call them, whereas with text keyboards I can at least make an educated guess at pronunciation that other people will understand.
This, to me, is a massive barrier with maths. If I can't read it out without learning how to mentally translate a symbol to a word, it's a hassle. I have too many things I can spend my time on to deal with that.
That is akin to saying reading is too big a bother because you cannot be expected to remember how to read spell and pronounce words. Maybe tolerance of willful ignorance is the problem here.
If I had to learn to read, spell and pronounce words in an alien language using an alien alphabet to read a book I wasn't sure would offer me any value when I have plenty of alternatives written with alphabets and in languages I know you might have a point.
The choice facing people is one of doing something we find unnecessarily hard and of uncertain payoff vs. doing something much easier with a more certain payoff (because we've got past experience with it).
How is your mandarin? Sanskrit? Klingon?
The choice facing people is one of doing something we find unnecessarily hard and of uncertain payoff vs. doing something much easier with a more certain payoff (because we've got past experience with it).
How is your mandarin? Sanskrit? Klingon?
But dinae we ust to spelle yust any ol wae?
I had the same reaction to that screenshot. The use of parentheses and dots is very scary, though as a programmer I can make guesses as to why they are there. Is there any reason the syntax couldn't have looked like this instead?
Yes, it will probably make your parser more difficult. Yes, for this use case, it's probably worth it. I'm guessing that a game targeted to 5-year-olds won't have such complex nested logic that you can't write a simple DSL like the above.
move up
move left
move up
move left
set
Yes, it will probably make your parser more difficult. Yes, for this use case, it's probably worth it. I'm guessing that a game targeted to 5-year-olds won't have such complex nested logic that you can't write a simple DSL like the above.
No huge reason. It is, after all, pretty much what Logo looked like:
http://www.calormen.com/jslogo/
Logo was explicitly designed to teach programming, and is pretty much Lisp with a different (and not that different) syntax.
You could probably push Logo even further along the "natural language" axis, but I think that's too brittle: It's too easy to come up with constructions which look like they should work, but fail in a completely opaque fashion. A better plan would be to improve the tooling, to give kids editors which know the language and can provide templates to prevent people from entering invalid syntax. Brad Templeton's ALICE Pascal was an example of this syntax-directed editing.
http://www.atarimagazines.com/v6n2/Alice.html
http://www.templetons.com/brad/alice.html
These days, we could wire in an extensive help system, complete with discussion fora and examples, to specific syntactic constructs and function calls. You know, like how Programming Professionals use StackOverflow.
http://www.calormen.com/jslogo/
Logo was explicitly designed to teach programming, and is pretty much Lisp with a different (and not that different) syntax.
You could probably push Logo even further along the "natural language" axis, but I think that's too brittle: It's too easy to come up with constructions which look like they should work, but fail in a completely opaque fashion. A better plan would be to improve the tooling, to give kids editors which know the language and can provide templates to prevent people from entering invalid syntax. Brad Templeton's ALICE Pascal was an example of this syntax-directed editing.
http://www.atarimagazines.com/v6n2/Alice.html
http://www.templetons.com/brad/alice.html
These days, we could wire in an extensive help system, complete with discussion fora and examples, to specific syntactic constructs and function calls. You know, like how Programming Professionals use StackOverflow.
I wondered the exact same thing. Having parentheses, periods, etc in seemingly-arbitrary positions looks complicated, at least in part because they are not self-explanatory. They tried "move(.up)", but did they try "move up"?
It would be so funny if COBOL turned out to be the ultimate starter language. ADD 1 TO X. But seriously, that is probably why languages like Logo and BASIC are englishy. Also the interactivity (e.g., logo turtle) giving you instant feedback on what you are doing is a big component.
That's a good point, and one reason I enjoyed BASIC and its dialects so much. Which is easier to explain to a new programmer:
For i = 1 to 10
Or
For (i = 1; i <= 10; i++)
Once you understand how things work, translating that knowledge to another language and adding on concepts is relatively easy.
For i = 1 to 10
Or
For (i = 1; i <= 10; i++)
Once you understand how things work, translating that knowledge to another language and adding on concepts is relatively easy.
This is an interesting example, because back then when I learned BASIC (around age 7 on a Vtech Precomputer 1000 [1]), I couldn't understand why the for loop was called "for". Why am I doing this "for i"? How does "i" benefit from this? I didn't know the mathematical idiom "blabla for a value of i equals 10".
I was also strangely afraid of the word INTEGER, which I read as INTER-EGER. "Integer" has no meaning to a kid, it's just called a number (as opposed to a dot-number or a fraction).
On the other hand, I never had problems with the fact that is was using text.
[1]: http://www.vintagecomputing.com/index.php/archives/324/324
I was also strangely afraid of the word INTEGER, which I read as INTER-EGER. "Integer" has no meaning to a kid, it's just called a number (as opposed to a dot-number or a fraction).
On the other hand, I never had problems with the fact that is was using text.
[1]: http://www.vintagecomputing.com/index.php/archives/324/324
i read all the Asterix comics pronouncing Julus Kazar ;-)
Then repeated at post-grad chemistry when first asking a question out loud about Orger Electrons (Auger - more like Aubergine, prior to lectures introducing them) - prof was non-plussed... Reading and talking huh ;-)
Then repeated at post-grad chemistry when first asking a question out loud about Orger Electrons (Auger - more like Aubergine, prior to lectures introducing them) - prof was non-plussed... Reading and talking huh ;-)
Haha. I read utilities as "ultilities".
I still to this day, after about 30 years of exposure to C, 22 years of professional development, and many years of using C professionally, avoid the for() look in C because I struggle to remember which position the comparison vs. increment goes. I prefer to use while() loops.
But I still remember the BASIC syntax you demonstrate above, 30+ years after I last programmed BASIC.
But I still remember the BASIC syntax you demonstrate above, 30+ years after I last programmed BASIC.
> because I struggle to remember which position the comparison vs. increment goes
Tip: they're in the same order they're used: comparison is always run at the beginning of each iteration, and increment is always done at the end.
Tip: they're in the same order they're used: comparison is always run at the beginning of each iteration, and increment is always done at the end.
for(init; cond; last) ...
init; while(cond) { ... ; last;}
Tried many ways of remembering it, gave up and decided a more reliable workaround. I don't know why I find it so hard to remember.
Then again I've found an even more reliably workaround by not writing much C these days.
Then again I've found an even more reliably workaround by not writing much C these days.
I don't know for US, but here, in France, children start to really learn to read at school after preschool, around 6-7 yo. Some succeed, some have difficulties to achieve.
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.
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.
The problem isn't reading ability, it's the rigid structure of words that confuses them (this happens at any age range). What is or isn't allowed? Grammar rules are invisible at the end of the day and to be honest what does 'move(.left)' signify? Even after 15 years as a programmer I find this grammar confusing, is it shorthand for 'this.left'? shorthand for an enum? I'm even wondering if this grammar is even useful, if it doesn't look anything like languages in commercial use.
Using icons makes a lot more sense, as they are immediately recognizable pictures that come with the expectation of no structure to learn, and it looks like from the article they just simply put one icon after another in a list.
Using icons makes a lot more sense, as they are immediately recognizable pictures that come with the expectation of no structure to learn, and it looks like from the article they just simply put one icon after another in a list.
I routinely send large text files to people around me, I noticed many people just refuse to read pure text.
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.
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.
It could be a layout thing too. White space magically helps sometimes.
Lack of human factors knowledge in people who write software tools is keeping kids from coding. And adults, for that matter. There's a huge amount of incidental complexity and fragility that we just tolerate.
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.
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 title makes me cringe a little. It implies the text-based nature of most programming languages is a problem, even THE problem. It is, if you're trying to simply get young kids to use <insert language here>, vs get them to use said languages to interesting problems.
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.
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.
My gateway drugs into programming were AutoIt (https://www.autoitscript.com/site/autoit/) and Ren'Py (https://renpy.org/).
AutoIt lets you control the mouse, simulate keyboard input and so on. It was pretty fun as a kid to make a "can't press this button" game and watch others try to beat it. There wer also bindings to various Windows APIs, which I used to build GUI solvers for my math homework.
Ren'Py is a framework for creating visual novels, and I made one that mocked the vocabulary tests by having each choice be a pun on bastardized French or a running gag in my French class. I think pretty much everyone in that class played it at some point.
My point being, there are tools out there with a special-purpose scripting language used by content creators who might themselves not be expert programmers, and I if you let kids play around with that they will probably build something they find fun without anyone telling them to do so.
AutoIt lets you control the mouse, simulate keyboard input and so on. It was pretty fun as a kid to make a "can't press this button" game and watch others try to beat it. There wer also bindings to various Windows APIs, which I used to build GUI solvers for my math homework.
Ren'Py is a framework for creating visual novels, and I made one that mocked the vocabulary tests by having each choice be a pun on bastardized French or a running gag in my French class. I think pretty much everyone in that class played it at some point.
My point being, there are tools out there with a special-purpose scripting language used by content creators who might themselves not be expert programmers, and I if you let kids play around with that they will probably build something they find fun without anyone telling them to do so.
I have a halfway decent solution to this problem.
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.
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.
I think this is an amazing idea! I played with Basic and Visual Basic when I was younger and it taught me all about logic loops, basic data structures, etc. Putting that type of playground on the web sounds interesting. Have you started yet?
I'm working on porting the language VM to asynchronous JavaScript. The language that I'm using is one that I've shared with HN before, although I've made major changes and added some nice features.
Here is the Duck source code: https://github.com/gregtour/duck-lang/tree/duck2 The documentation reflects the original version, but duck2.cfg shows the new grammar and the /js folder shows the current progress.
I have a mockup of the interface here as well: http://brainplex.net/gamepad/
One big issue is finding time.
Here is the Duck source code: https://github.com/gregtour/duck-lang/tree/duck2 The documentation reflects the original version, but duck2.cfg shows the new grammar and the /js folder shows the current progress.
I have a mockup of the interface here as well: http://brainplex.net/gamepad/
One big issue is finding time.
Text didn't prevent me to learn Timex 2068 Basic and Z80 Assembly at the age of 10.
What I would concede is that we had fun books to learn from, like these ones for the Atari http://www.atariarchives.org/.
What I would concede is that we had fun books to learn from, like these ones for the Atari http://www.atariarchives.org/.
Scratch is another solution for this problem
https://scratch.mit.edu/
https://scratch.mit.edu/
I don't think it is - after learning how to build things in Scratch, one still has to transition to a language with different syntax which is text-only. What was presented in this submission might just be the solution that helps reduce the anxiety of transitioning from icons to programming languages with text-based source code.
Scratch is intended for older children who already have a certain level of literacy. There is another product, ScratchJr, for younger children that uses an icon-based UI: http://scratchjr.org/
The transition path between them is indeed what you described.
The transition path between them is indeed what you described.
Blockly is based on Scratch and offers a transition path between visual and text-based programming.
https://developers.google.com/blockly/
https://developers.google.com/blockly/
Honestly, I've got pretty mixed feelings about Scratch.
It's a very cool initiative that helps make basic programming more accessible, and I value it as a way to show kids "hey, programming exists and can be fun!"
But I've also had the misfortune of running events where kids use Scratch. These were 7th-9th graders who self-selected in, so up to a decade older than the target audience in this article. The results aren't exactly pretty, and they don't make me optimistic about giving Scratch to 5 year olds.
Scratch seems to have two major problems: awkward control flow, and a gridless environment.
- The first comes through as a large fraction of programs having broken or absurd loop and branch logic - often with a clear plan in mind, but terrible results. The difficulty of establishing hidden state encourages all sorts of ugly practices like handling a health bar by nesting the same code three times in conditionals to handle taking damage.
- The second is that where SpriteBox uses grids to establish clear coordinate systems and touching/overlapping/separate states, Scratch uses a continuous field. It creates awkward and unintuitive collision results, adds a layer of unfriendly abstraction (what does "forward 200" actually mean?), and makes drag-and-drop initialization a touchy and miserable experience, even for adults.
Overall, I think Scratch succeeds at reducing text, but fails to make abstraction and control feel approachable. It also introduces lots of novel headaches not present even in 'real' programming.
It's a very cool initiative that helps make basic programming more accessible, and I value it as a way to show kids "hey, programming exists and can be fun!"
But I've also had the misfortune of running events where kids use Scratch. These were 7th-9th graders who self-selected in, so up to a decade older than the target audience in this article. The results aren't exactly pretty, and they don't make me optimistic about giving Scratch to 5 year olds.
Scratch seems to have two major problems: awkward control flow, and a gridless environment.
- The first comes through as a large fraction of programs having broken or absurd loop and branch logic - often with a clear plan in mind, but terrible results. The difficulty of establishing hidden state encourages all sorts of ugly practices like handling a health bar by nesting the same code three times in conditionals to handle taking damage.
- The second is that where SpriteBox uses grids to establish clear coordinate systems and touching/overlapping/separate states, Scratch uses a continuous field. It creates awkward and unintuitive collision results, adds a layer of unfriendly abstraction (what does "forward 200" actually mean?), and makes drag-and-drop initialization a touchy and miserable experience, even for adults.
Overall, I think Scratch succeeds at reducing text, but fails to make abstraction and control feel approachable. It also introduces lots of novel headaches not present even in 'real' programming.
Scratch is just a really pretty syntax highlighter where you don't have to type. You still have walls of text. It's just pretty colors.
It's more than a syntax highlighter, it's a language where validity can be determined by static analysis, that prevents the programmer from making syntax errors in realtime. I think its potential as a serious tool is underrated.
Good point. I was referring more to it's benefits in relation to this article. I don't think it adds much value over what the original app being discussed here did. I think switching to icons adds more value in that context.
There's a discussion of this on the Bootstrap blog: http://www.bootstrapworld.org/blog/blocks/Block-Getting-Star.... (That's Bootstrap, the teach-scheme-to-middle-school-children project, not Bootstrap the JS library.) They've tried it both ways. I'll quote their bullet points:
> 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
Context: they're working on something aimed at children no older than 8.
Why do children under 8 need to know how to code? They don't even have simple things like cause and effect established in their brain until they're about 11. I.e. "if it's raining outside I should wear a rain coat or I'll get wet". Nor do they have much logical reasoning capability. That's also why they don't get sarcasm.
Edit: paper on pre-adolescent and adolescent brain development, especially as it relates to cause and effect and abstract reasoning: http://www.sciencedirect.com/science/article/pii/S1878929314...
Edit: paper on pre-adolescent and adolescent brain development, especially as it relates to cause and effect and abstract reasoning: http://www.sciencedirect.com/science/article/pii/S1878929314...
You have a really weird idea of what an 11 year old is capable of.
Are sure it's me and not you? I have a 13 year old kid, and he still can't figure out that if he doesn't turn in his homework on time his grades will suck. :-)
Prefrontal cortex is still developing in 11 year olds which means they're not great at understanding consequences of actions or making complex future plans.
But most of them are certainly capable of making the evaluation used as an example above.
Not to be the "prodigy" kid, but I began game programming at 10 years old because I wanted to know how games worked. I tried to buy a Visual Basic 5 book from Borders before my parents gave me "Beginning Programming for Dummies" instead.
Not sure why these people don't believe that Boy Scouts and Girl Scouts can't tell the weather.
Not sure why these people don't believe that Boy Scouts and Girl Scouts can't tell the weather.
My son is two years old and he knows he needs to wear shoes to go outside. I think you're a little off the mark.
Good article. I hope this article inspires more people to come up with clever solutions that help bridge the gap with kids and coding. It's easy for most of us to discount the barriers of syntax because it's so familiar to us, but try to remember this: People consistently fail PEDMAS tests online. That's a trivial syntax.
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.
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.
I definitely agree that text is very intimidating, no matter how well it is represented, compounded by inclusion of numbers and punctuation like (, ), ;,. +,-,<,>, etc.
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.
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.
I had an excellent math education growing up (not in US) so programming did not seem intimidating to any of us as it looked a lot like math. For me the main motivation to code was to have my computer do the math and physics I was learning in school. US parents and teachers really need to push for better math skills rather than run away from it.
All we're doing here is separating logic from syntax -- which totally makes sense.
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.
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.
I think it's due to only 10% of humans primarily thinking in text/sound, whereas 40% are visual and 50% are emotional. This was exploited in e.g. Harry Potter books. I think we are due visually or voice-driven development environments that should be now possible with Deep Learning, even if initially a bit cranky.
Umm...where's the research on the efficacy of the change on how skilled the kid becomes at programming? All I see is they self-assessed that it was easier with pictures, and they were engaged longer. Great. But DID THEY LEARN TO CODE BETTER?
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.
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.
They did not do hard research, since they are still designing their game, but they did present it to playtesters. I think this is an appropriate level of diligence for a product early in the design phase, it's the equivalent of the "hallway usability testing" recommended for agile teams.
It may be impossible to say right now whether this change helps kids get better at programming faster, but presumably, more kids will play a game that they feel is more approachable, similar to how the playtesters responded.
It may be impossible to say right now whether this change helps kids get better at programming faster, but presumably, more kids will play a game that they feel is more approachable, similar to how the playtesters responded.
Like I said, I don't fault their methods for what they're optimizing for: sales. I -do- fault them for implying that it will improve coding skills when they never tested for that.
IMHO the more likely explanation for these results is that the human visual system has built in mathematical, logical capabilities actually far beyond advanced college math. These are used to identify and track objects at a very early age. It is much easier to access these abilities using pictures and icons.
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.
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.
[deleted]
By starting with icons first, you intuitively teach the idea of tokenization of the program code.
This idea is important, but trivially simple to an experienced programmer so easily dismissed. It is not that obvious to a beginner tho.
This idea is important, but trivially simple to an experienced programmer so easily dismissed. It is not that obvious to a beginner tho.
> From our perspective, we’d simplified the code to what looks like plain English.
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.
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.
I learnt to code with logo, and that was text based. why are we trying to force kids to learn how computers till they are interested in it. They should be learning to ride bikes or climb trees.
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.
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.
If software had started in China, we would not have these problems. There would be an ideogram for each operator or keyword. For one thing, the equals sign wouldn't be misused as an assignment operator.
And yet I hate game engine visual programming, whatever you call connecting those boxes together. I started out thinking the windows commands were doing something cool and then wanted to make games so i asked my parents for the Dark Basic software set and began moving images around that shoot sprites I drew. From there I asked for a Borland C book that came with a compiler and then jumped into web design a bit. That was about 20 years ago for me and now I'm a system admin and reverse engineering/making whatever I can on the side.
Didn't Alan Kay and team get a bunch of elementary school-aged children - who had probably never even seen a computer before, since this was in the 70s - programming in Smalltalk?
Yes. Not only that, but by observing the kids they iterated on different versions of Smalltalk. The approach there was quite different from what you see today. They built upon actual psychology and spent the money and time conducting studies. From that we got things like GUI, OO, etc.
When you see Kay harping on about the dismal state of affairs today, I think it's that he sees this constant pedantic bickering about static vs dynamic typing and all the rest as meddling around in the complexity of things that should be irrelevant.
To the point of the original post, it's also worth noting that Smalltalks were not just text environments, and that while yes much of the code was written in text, these kids were not writing text files that they then compiled/interpreted using their PDP Terminal emulation programs. They were doing everything in the live environment itself.
Considering the existence of things like Smalltalk and Hypercard, whenever some uber programming expert tells you this-or-that reason we cannot have such systems in wide use today, it's akin to saying: "See all this great stuff we used to have? We can't have it anymore"
When you see Kay harping on about the dismal state of affairs today, I think it's that he sees this constant pedantic bickering about static vs dynamic typing and all the rest as meddling around in the complexity of things that should be irrelevant.
To the point of the original post, it's also worth noting that Smalltalks were not just text environments, and that while yes much of the code was written in text, these kids were not writing text files that they then compiled/interpreted using their PDP Terminal emulation programs. They were doing everything in the live environment itself.
Considering the existence of things like Smalltalk and Hypercard, whenever some uber programming expert tells you this-or-that reason we cannot have such systems in wide use today, it's akin to saying: "See all this great stuff we used to have? We can't have it anymore"
Here is one of the relevant portions of Kay's documentary, which was recorded years later:
https://youtu.be/p2LZLYcu_JY?t=35m21s
[deleted]
This is a really good idea, separating the logic from the syntax. I remember when I was learning database design and they taught us using Access, so we didn't get bogged down in the syntax. When I had to switch to Oracle professionally, I noticed I was constantly translating what I saw in Access to the PLSQL in Oracle. After a while, I just thought in PLSQL rather than Access.
Something I've noticed all the years, teaching is HARD. Well, teaching effectively and efficiently is.
Something I've noticed all the years, teaching is HARD. Well, teaching effectively and efficiently is.
The kids they are working with are in an age group in which some children are just beginning to read. Yes, text is a problem if you're not yet literate.
Are you a coder if you don't understand what syntax is? We used LOGO when I was a kid, and for good reason. It had a limited syntax for classroom use and gave you instant visual gratification.
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.
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.
Cool! I feel like you could go further and let the student control the transfer to text. Give all the built-in functions both icons and names, and let student-defined functions be icons they create if they want. The point where it's less cognitive load to use text is going to be different for different students, so let text-based coding be a tool they discover, not a requirement imposed on them.
I was at a conference lately. After one talk, the presenter talked about his experiences with his children presenting how to code and teach other children. He commented that one of the biggest barriers he saw in his own children is that it took them so long to type out the ideas they have in their head. It requires immense focus to retain what to do next.
There was some great prior discussion of the topic of kids, text, and coding in a thread about Scratch 3 months ago: https://news.ycombinator.com/item?id=14274249
I thought this would be "kids are texting rather than messing with their computers".
> Problem is, many newcomers, kids and adults alike, believe that code is inherently complex simply because it looks complex.
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.
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.
>But it is complex. Anything beyond the most basic examples delve into the concepts of calculus.
Huh? My codebases at work have never involved calculus. Not all programming proceeds along the lines of Project Euler when getting more complex.
Huh? My codebases at work have never involved calculus. Not all programming proceeds along the lines of Project Euler when getting more complex.
The very concept of functions is calculus.
Kids are in their teens before we even have them solving x=y algebra.
Kids are in their teens before we even have them solving x=y algebra.
Maybe we're working from different definitions of "calculus".
To me, equations and relations between variables are not calculus, just algebra. Only when you start studying the infinitesimals of change does it start to count as calculus. I don't have any derivatives or integrals in my programs, and very few do.
To me, equations and relations between variables are not calculus, just algebra. Only when you start studying the infinitesimals of change does it start to count as calculus. I don't have any derivatives or integrals in my programs, and very few do.
I was playing this kind of games when I was a kid. More like a puzzle than coding though.
Kids who want to learn how to code should just do it with regular tooling. You don't need any special approach.
Kids who want to learn how to code should just do it with regular tooling. You don't need any special approach.
I wonder what it's like growing up in today's world learning to code... Very different from how I was introduced to coding.
Kids learn to read music at school so why should learning to code be any easier? Skills have to be learned. Simple as that.
if i had learned to code using those graphical things when i was growing up, i probably woupd not have become a coder. wheres the joy and fun in it? looks laborius and boring to me.
Are 5 year olds expected to read these days?
I learned it at 7-8.
I learned it at 7-8.
I remember getting frustrated with my kindergarten teacher because she insisted that the letters "T-H-E" spelled a familiar word, yet the word has no T sound, H sound, or E sound. What a garbage language, I thought.
So yeah, I'd say kids start to learn to read at 5 or earlier.
So yeah, I'd say kids start to learn to read at 5 or earlier.
[deleted]
I can't comment too much on this, except to say that it did cause me to recall something from my early childhood.
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.
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.
If you give your kids books, text isn't scary
I don't think what parents find scary is text but that programming is (for these parents) not text they comprehend.
Now, there is an assumption with a book that kids will learn to read the language. Maybe parents should have the same attitude towards programming.
Now, there is an assumption with a book that kids will learn to read the language. Maybe parents should have the same attitude towards programming.
If that held up, I wonder why (at least from the article) it seems that parents thought the same.
I think that sometimes parents "protect" their kids from complicated things. They underestimate what children are capable of.
I think it's because they think generally and not for just their own kids if they are already good readers/writers.
[deleted]
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.