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.
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.
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.
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.
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.
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.
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.
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.
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.
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. :-)
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.
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.
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.
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.
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"?
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.
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.
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 ;-)
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?
move up
move left
move up
move left
set
I mean, after all, that's exactly the "syntax" of the replacement icons!
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.
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.
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.
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.
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).
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).
I actually don't know any great coders that learned to code through these kinds of games. They might move the programming-is-interesting gradient, but I don't think the hard part about learning to code is the text.
The hard part about coding is the problems that aren't in the code. Doing research, setting up environments, understanding platforms, dealing with crashes, dealing with crappy tools, debugging, understanding other people's code. None of this is taught by isolated sandbox games like this. Sandbox games might teach some very useful analytical skills, but it's pretty far from coding.
The only thing you really need to get kids coding is to give them the tools needed to do interesting naughty things. Many of the programmers I know learned to code at an early age by hacking games to cheat against their friends. Reading text was never, ever a problem, but the disillusionment of finding out that coding doesn't involve pretty foolproof user interfaces might have been.
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.
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.
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.
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.
While I agree that I also don't know of any 'great coders' which started with these games, I don't think that these games were available for anyone coming from either my generation (in my 20s, now) or any of the previous ones. The Code.org push happened when I was in High school, far too old to be of target to any of these types of games, and the ones that did exist---let's be honest---were pretty bad.
As for
>The hard part about coding is the problems that aren't in the code
Yes, while I do agree, that's only true once you're already comfortable with coding. I know many people who can set up Eclipse, have no idea that Ctrl+Space is the autocomplete function, and who can write and compile simple programs, but given a slightly more difficult task involving some relatively simple (for us, now) algorithm, would throw their hands up in the air and say that they "don't know how to tell the computer how to do that" (approx. quote).
Though anecdotal, it might be of interest: my youngest cousin started learning how to code through Scratch and Mindstorm (all of which are graphical programming languages) and has had no problem picking up 'true coding' in the past few years, writing simple programs in Python. She's 8 now, I believe. Of course, correlation, causation, it's really up in the air to be honest, but I do think the graphical nature of all of this might have opened her eyes to a much bigger world than the cryptic matrix-like text which fills our screens---which, personally, is how I imagine many people view programming.
I'd challenge the idea that Scratch is a “visual” programming language. It has you put together blocks to write code, but those blocks contain text and behave like statements in any vanilla programming language. The advantage of the block system is that it's discoverable (all available blocks are shown in and can be picked from the menu) and it mostly avoids syntax pitfalls (either a block fits into another or it doesn't).
But it's also coupled with a sort of… game engine/scene graph kind of thing that your code affects and which you can interact with visually, which probably makes your code seem more tangible?
Yes, sorry, when I say "graphical," I mean that the language has a graphical representation of the logical flow that doesn't have to be inferred from the text.
E.g. in Scratch, as you mentioned, all blocks have text but the flow of the program is given in a graphical way, and can also be dictated in a graphical way. Additionally, the blocks themselves, while having text, also encode their purpose graphically (e.g. start, event-driven blocks, as distinguished from instructions, etc).
Also as you mentioned, there's something nice about these blocks in that the system is completely discoverable and has the flexibility of combining statements, etc., without the exponentially large space one would have to think about if they attempted to discover the language by typing out statements using the keyboard.
In other words, there is much-reduced complexity in graphical languages, along with the fact that programming becomes much less a question of remembering what a block does as opposed to finding the block which does what you want. A much easier problem for those unfamiliar with a language, which also allows them to focus on the problem as opposed to the specifics of learning the syntax of a language.
Yeah. I think the genius of Scratch is it's basically an advanced IDE for an ordinary programming language, rather than trying to create some alien “visual” thing.
I did use RPG Maker, having found out about it in middle school (though I had programmed before), it was actually kind of fun to mess with, thanks for reminding me about it! I may pass it on.
But, anyways, my point was less that they didn't exist, but rather than one had to know this was a community and actively seek it out, whereas now an interested parent can go look up "learn to program" in the app store and have plenty of apps to install and have their kids run on an iPhone or iPad ready to go, instead of having to go through several websites along with setting up applications on their computer, etc., to get everything ready for their kids' use. Perhaps more succinctly, they have to have no prior knowledge of programming or of the existence of this community in order to have their kids be a part of it.
Of course, before we could still Google stuff and see that it exists, but it seems to have more of an activation energy than a ready-to-install app from the app store; I should also note that this all was also pre-Code.org push, too. Compared to so many of the people I know with kids in elementary and middle school, many of whom are already starting to learn how to program, I can't remember this being the case at all with my year. All of this comes with the big warning label of "anecdotal evidence," but I'd love to know if there are any numbers on this!
I'm not calling myself great, but my initial introduction to programming was a Logo robot at the age of 6 or 7 in the 80s, so I'm not sure I agree with you. A turtle shaped robot we could get to draw things. All primary schools at that time usually had a BBC Micro in each class too.
Perhaps it was just a British thing. After that it was some BASIC on spectrums, some BASIC on Acorn Archimedes, then some random OO language on Amiga that I've never really been able to track down what it was called.
And I wasn't even that keen on programming, I was just exposed enough and wanted to build better games than my friends at lunch or on our graphical calculators. I remember running out of memory on my graphing calculator trying to get a working version of poker (which I now realize was wildly more ambitious than the versions of blackjack we all made).
A lot of programmers of my age will remember the turtle with fondness.
I guess all of those were incredibly simple to setup to start programming (for the spectrum it would go straight to the command line), but then again these days so's pressing F12 on a web browser to get a working command line.
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 do not think your professional experience is representative in any way of what is better for very young kids.
I know some musicians and I can tell that actually playing the instrument is not the hardest part. That does not mean a toy piano is not a good present to get a 5 years old started. And if painting the keys in colors instead of black and white (icons instead of text) makes the kids more willing to play it, I think it is something very interesting (more for toy piano manufacturers than musicians though).
Absolutely. "Programming" with cute icons may not make you a "great" programmer, but that's not the goal. It's to get you interested in the idea of telling a computer to do cool things.
As an example, my daughter had no real interest in doing anything with a computer until we showed her she could move Moana's raft around with some Scratch/Blockly code in a Disney Hour of Code game. Therefore, I think these games are absolutely worthwhile. Let kids start learning the "hard parts" of programming after we've got them hooked!
When I was a kid computers were just a text interface and you had to type code just to load the games (originally with BASIC, then with DOS). In the BASIC era writing games was as easy as turning the computer on. OK you'd need machine code to do anything advanced but BASIC was a fantastic gateway drug (for want a better description).
Trying to rekindle this was one of the aims of the Raspberry Pi but even with that, there isn't anything quite like the accessibility that the microcomputers of old had. Except maybe web development but in my personal opinion HTML+CSS+JS teaches bad programming habits (unless you're particularly OCD and disciplined).
So I'm all for games like that in the article. In fact in some ways, it reminds me a lot of LOGO (another good gateway drug).
I 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.
I grew up with BASIC as a gateway drug, too (that's a great way to describe it on a number of levels!) and PICO-8 and the like are the closest modern equivalent I've seen to that kind of environment. Simple games with simple graphics plus the ability to drop into a code/sprite/etc editor with the press of a key.
The only real negative to me is that Lua, like most any modern language (i.e. ones that regularly use indentation), doesn't seem particularly well-suited to being edited in a very low resolution window. But it's still the closest I've seen to something that recaptures that "immediate" magic of ROM BASIC.
I think the problem with trying to rekindle this for the current generation of kids is that computers are simply way more advanced now than they were for us. We didn't have a pocket-supercomputer with a touch interface, realistic games, and an AI assistant that speaks and (sometimes) understands our speech. Being able to draw a triangle on the screen with a few commands was amazing to us, not so much for our kids.
I 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.
- 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...
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.
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.
For “real coding” sure, that holds true. But as for what got me hooked, and what made me study CS, it was LOGO and seeing the turtle do really neat images with surprisingly few instructions—I still have a vivid memory of that day and that feeling of deep curiosity about what else could be created by that turtle.
> I still have a vivid memory of that day and that feeling of deep curiosity about what else could be created by that turtle.
If you haven't and are curious - you should look into what LOGO can really do. It's actually quite a complex language, far beyond just simple "turtle graphics". Unfortunately, most of the rest of LOGO was never taught to many people, and so all we learned was the graphics part.
But LOGO itself is surprisingly complex, and has more than a passing nod to LISP in what it can do.
I recall learning LOGO as a kid - but wrote it off as a "toy language" even then, until one of the magazines I got at the time (which I typed in BASIC games and other things from) had a game of Monopoly coded entirely in a version of LOGO that computer could run (I never did type it in, because I didn't have the language - and it was a fairly expensive piece of software from what I recall). All the graphics, logic, and sound, plus i/o, scoring, disk handling, etc - were all done in LOGO. It impressed me then; still does, in fact.
The 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.
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 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!
"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..
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?
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.
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.
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 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.
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.
> 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.
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.
> 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.
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.
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 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.
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.
>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.
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.
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.
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]
172 comments
[ 3.3 ms ] story [ 231 ms ] threadhttps://scratch.mit.edu/
The transition path between them is indeed what you described.
https://developers.google.com/blockly/
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.
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.
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.
Something I've noticed all the years, teaching is HARD. Well, teaching effectively and efficiently is.
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.
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.
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...
Not sure why these people don't believe that Boy Scouts and Girl Scouts can't tell the weather.
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.
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 don't see much difference teaching them programming with a real programming language. They have to be forced to embrace it first.
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.
But I still remember the BASIC syntax you demonstrate above, 30+ years after I last programmed BASIC.
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.
But I also dislike it and love "for ... in" constructs.Then again I've found an even more reliably workaround by not writing much C these days.
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
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 ;-)
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.
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 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).
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.
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 hard part about coding is the problems that aren't in the code. Doing research, setting up environments, understanding platforms, dealing with crashes, dealing with crappy tools, debugging, understanding other people's code. None of this is taught by isolated sandbox games like this. Sandbox games might teach some very useful analytical skills, but it's pretty far from coding.
The only thing you really need to get kids coding is to give them the tools needed to do interesting naughty things. Many of the programmers I know learned to code at an early age by hacking games to cheat against their friends. Reading text was never, ever a problem, but the disillusionment of finding out that coding doesn't involve pretty foolproof user interfaces might have been.
I think browser-based language introductions are great. They remove a huge obstacle and get you into the language right away.
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?
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.
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.
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.
https://archive.org/details/Rockys_Boots_1982_Learning_Compa...
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
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.
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?
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.
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
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!
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.
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_...
Maybe Amiga E? http://strlen.com/amiga-e/
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).
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!
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).
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 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.
- 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.
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...
TL;DR - MLX was a BASIC app for the C64 that allowed the key entry of hex code with checksums and live validation.
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
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.
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.
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...
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?
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.
Kids who want to learn how to code should just do it with regular tooling. You don't need any special approach.
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.
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.
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.
Huh? My codebases at work have never involved calculus. Not all programming proceeds along the lines of Project Euler when getting more complex.
Kids are in their teens before we even have them solving x=y algebra.
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.
- Numbers are keeping kids from learning math. - Text is keeping kids from reading. - Too many words are keeping kids from listening to lectures.
I don't understand why people find it difficult to just teach a kid how to do something rather than wait for some miracle solution.
A great preparation they should learn some math or ideally be having fun with their friends, running around outside or perhaps art or something creative.
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.
Not sure why there is a dichotomy between this and playing a game on phone for 30 minutes to learn coding.
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 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/