Thanks!
Most of the early design work was done in the context of the (US) College Board Advanced Placement™ CS Principles exam, so the target audience was high school juniors (age 16 or so). But it's turned out that Snap! has attracted university professors for their undergraduate classes, especially in Germany where Jens and Jadga have been very active in meeting with educators. And we've also attracted the child prodigies, who find us independently. And with our recent support for Parsons problems we're even used in teaching math to the youngest primary students! So we want to support education in the broadest sense. And, to be honest, we also want Snap! to be the language in which we ourselves want to program.
Do you mean "typing" as in keyboarding, or as in typed variables? If the latter, ugh. If the former, we do provide a keyboard editing capability for users with visual disabilities, and some of our users without such disabilities also find it faster to edit with the keyboard. But even for adults, a great thing about block programming is that there's no benefit to using short names for procedures or variables, and so we encourage writing self-documenting code. It's the inability to use names with spaces between words that makes programming teachers fetishize comments in code. Even before the block programming days, I always told my students that any time I find myself tempted to put a comment in my code, I rewrite it instead!
Tail calling is something programming language implementors should worry about, but not beginning students. This point is analogous to our disagreement about how best to present sieving for primes to students! When introducing a topic, the best pedagogy is to write the absolutely simplest possible code without worrying about efficiency. Efficiency is for CS 2, not for CS 1 or (especially) CS 0. But we do present CPS in the manual.
Are you saying that you have an anti-Lisp bias? ;~P
Jens actually grew up in the Smalltalk tradition, as did John Maloney, the main original designer of Scratch. That's why, from its beginning, Scratch has had sprite-local blocks (methods) and variables (fields), and so does Snap!. I, however, am a disciple of Scheme, God's programming language. That's why we have call/cc in Snap!, more planting the flag of Schemeliness than as something to teach our students. There's a reason why all the programming language theory guys are Schemers. :~)
But we try to be paradigm-agnostic. Our sprites, unlike the ones in Scratch, have object inheritance, and we recently introduced a more orthodox dictionary-based OOP implementation to accommodate the professors who want to teach a traditional OOP curriculum. We have APL-style hyperprocedures (hyperblocks) and a complete implementation of APL as a library. @qw23 is building a logic programming library for us. We've put a tremendous effort into supporting Mark Guzdial-style media computation, one of the motivations for hyperblocks. We've implemented metaprogramming (procedure text as data).
In fact, we actually worry a bit that instead of being a Scheme, we've become a PL/1, a language with every possible feature. But there isn't any feature in particular that I'd be willing to give up! Not even imperative programming, which some of our users love for some reason. :~)
