Comment by primitivesuave | Hacker News Reader

Comment by primitivesuave | Hacker News Reader

Parent Full thread

I have run an organization that teaches kids to code and advocates for coding literacy for the last 5 years, and I agree with you that kids as young as 8 years old can absorb a text-based language when presented in the right way. However, typing speeds are generally quite slow amongst elementary school kids, so the rate at which they can make interesting things happen is much slower. That initial dopamine rush when connecting Scratch blocks is a very effective way to get them to see programming as an exciting and fulfilling endeavor. By eliminating the possibility of syntax errors through block-based languages, you can put their entire initial focus on semantics, without having to divert their attention toward syntactical correctness.

Also, it takes a certain kind of computer scientist to teach computer science effectively, and most elementary school teachers do not match that requirement no matter how much PD you give them. I would say most elementary school teachers can't handle much beyond the basics of Scratch, but that is more than enough to get the platform in the hands of kids. If the teachers chooses to just let the kids mess around with Scratch rather than give them structure and clearly defined goals, they will still do just fine. If a teacher takes a similar lax approach with typed programming, the kids will most likely learn nothing at all, and will often develop an aversion to programming altogether.

But I completely agree with you on the importance of teaching typed programming. My heart aches when I hear of middle school CS classes using Scratch. That's the perfect age to start exposing kids to Arduinos, Python, Raspberry Pi, etc. The BBC Microbit foundation has been doing a great job in the UK bridging the gap between Scratch and typed programming with their Microbit platform (microbit.org), and (shameless self-plug) I work on this problem as well with techlabeducation.com and pythonroom.com.

I think what kids miss most of all from typed programming is the idea that a language is just like a human language, where each language has its own metaphors and way of thinking (an idea put forth by Seymour Papert in his 1998 paper "Mindstorms").

I think the main benefit of a graphical language, as opposed to text-based is the rapid feedback loop. You see the response after every click.

This is the same reason so many people can build complex spreadsheets, yet wouldn't know where to start if you put them in front of an IDE.

I brought a book 'Computer coding for kids by Carol Vorderman' for a friend's daughters for Xmas (aged 6 and 8, both VERY bright with grades above their age groups). As learning to program makes you think differently, especially problem solving skills. It's gone down really well. Especially with older one who spends hours reading the book, even when she doesn't have computer access (and is now set on buying Chromebook with her pocket money).

A language such as Scratch is great for sparking initial interest, before going on to more depth.

You are right that it is the rapid feedback that really helps with teaching. I don't think you need a graphical language though, just an IDE oriented toward rapid feedback. Putting a 3rd grader in Eclipse and having to compile and build a jar to see the effects of a line of code would be horrible. But IDEs like Processing Development Environment or Dr.Racket have great tight feedback loops.

> You are right that it is the rapid feedback that really helps with teaching

And possibly with obtaining an intuition about whatever it is that you are manipulating. Maybe "direct manipulation" is mostly about that rapid feedback, rather than the concreteness of the objects?

I know that when I hooked up an "as-you-type" evaluator[1] to my experimental programming language[2], I learned more about problems with the language in a minute than I had previously in days or weeks. The feedback bandwidth is incredible, and the short cycle times have a more than linear effect.

[1] https://www.youtube.com/watch?v=sypkOhE-ufs&t=57s

[2] http://objective.st

True, it's kind of a shame that more of the features from Bred Victor's demos haven't made it into mainstream IDE's, such as:-

Inventing on Principle - https://www.youtube.com/watch?v=PUv66718DII (He has a handful of great demos on Youtube and Vimeo).

Another interesting source is Epic's Unreal Engine Dev tools - https://www.youtube.com/watch?v=DshYHUvLaDc

This puts me in mind of RPG Maker 2000 event scripting: http://i.imgur.com/XCoeAHG.png

It's block-based—you write it by inserting syntax nodes from a big menu—but the visualization of said blocks is plain text. If it's the first type of programming you do, you come out of it able to quickly understand a "real" text-based programming language, because you've been looking at textual programming syntax for a good while already.

>By eliminating the possibility of syntax errors through block-based languages, you can put their entire initial focus on semantics, without having to divert their attention toward syntactical correctness.

This is very interesting because one often hears the same thing - the exact same thing! - about Lisp as a teaching language. And Scratch and Lisp are indeed quite similar, superficially, though Scratch doesn't think of itself as a "real" programming language and hence stops short of providing features that would make it usable as one, like lexical scope.

One big difference is that Lisp simply hides a lot of its syntax behind homogeneous parentheses (many special forms can only be written a certain way, but you have to remember where the parentheses go) whereas Scratch doesn't so much hide it as handle it for you ("here are the slots where things can go in this syntactical form").

Another, separate but easily conflated difference is that it's in some sense "strongly typed" - numbers go in number slots, predicates go in predicate slots, etc etc. The return type of an expression is represented by the shape and color of its block. All types are statically known, and relayed to the programmer. It is impossible to commit a type error because the editor disallows it (which is in turn possible due to the transactional nature of drag-and-drop - what do you do if someone types the wrong thing in, untype it?)

I think these are valuable concepts that don't automatically imply "toy" and should be explored in the context of a "real" programming language. Computer science has consistently unvalued human factors. There is still a lingering sense that "real programmers" don't need to be mollycoddled, and should suck it up and endure byzantine incidental complexity. Never forget the lesson of Python, a slow and technically unremarkable scripting language which is now one of the most popular languages in the world because it is easy and fun to program in. Or the lesson of Lisp, an enormously fast and powerful language that nobody programs in because...?

Reply on news.ycombinator.com