bharvey

I'm afraid the exclamation point was my doing, not Jens's. I was scared of how many other things were called "snap," including the US welfare program that used to be food stamps, and was hoping to stand out from them. Didn't work; I didn't realize that search engines pretty much ignore punctuation.

We were very happy with the name BYOB, but we had a few teachers tell us very insistently that they could never use a language called that with kids. Those of you who live in civilized countries can't appreciate Americans' lack of a sense of humor. So we were looking for a reasonably short name for which the ___.berkeley.edu domain was available, and Snap was what we found.

We have a few who've just shown up on their own, but my friend Paul Goldenberg (my own nominee for best educator) has a project using Snap! with second graders, not to teach programming but to teach mathematics using Snap!-based microworlds.

I can second that. The code of Snap! itself is virtually all Jens. My main contribution was teaching him about lambda.

Wow, thanks! My own opinion is far less extreme. :~) But I definitely appreciate hearing yours.

On my when-things-slow-down list is to write a version of Structure and Interpretation of Computer Programs using Snap! as the language, aimed at high school kids, so replacing the examples that require calculus, for example. I (no doubt naively and arrogantly) can't help feeling that a transition from Snap! to any language that isn't Scheme would be a step downward.

Jens wants to do that in Snap! as the next big feature.

The first version, BYOB, was an extension of the Scratch 1.4 source code, but since then we have moved in different directions. But we are still inspired by how careful they were in designing visual metaphors for computer science ideas and have tried to extend that care to things like lambda and object inheritance.

I was lucky enough to meet Ken Iverson and Adin Falkoff at age 14 and have been an APL fan ever since, so the APL library has been a labor of love for me! It still needs a lot of work but it's getting the ideas out there.

Thanks for the kind words both about Logo and about Snap!. That article is in fact not yet officially published, but if I'm reading the ACM legalbol correctly, authors are allowed to put an "author's last draft" version on their institutions' web archives, so that's what you found.

The article has eight authors, and of course the time required to write something is \Theta(n^2) in the number of authors, so it was a long slog, although worth it because in between yelling at each other we had some great conversations about education and computers and Logo technology.

I am inordinately proud of Snap!, which is almost entirely the work of Jens Mönig. My big contribution was to talk him into lambda. (Coming in the next version: APL-style vector and matrix operations. After that we just have to find a way to shoehorn in Prolog and we'll be the unification (pun not intended) of all the good programming languages.)

> The only thing I miss in (Berkeley) Logo is a better fill function.

Thanks for volunteering! :) The code's at

https://github.com/jrincayc/ucblogo-code

I have to confess, that function, even though I always call it Y when I write it so people will get what it's about, isn't a combinator at all. Writing a real Y combinator in an applicative-order language is possible but complicated, so I never do it. :-) (The difference is that this function takes a _two input_ function as input and supplies itself as its first input. Really it should take a one-input function and magick that into a two-input one first.)

Have a look at Berkeley Logo, https://cs.berkeley.edu/~bh/logo.html

About S-expressions, you can fully parenthesize everything if you want. But Logo uses square brackets, not parens, as list delimiters, so you still have to do a little bit of tokenization.