
Snap: Programming for Everyone - jherritz
https://blog.miosoft.com/2015/02/snap-programming-for-everyone/
======
pmalynin
I'm not exactly sure what is the fascination with these blocky-looking, dumbed
down, drag-and-drop languages that look the same? First code that I wrote was
in QBASIC at age 10 (I'm 19 right now), which I found to be very accessible
and then later moved on to learning C# with the help of various XNA tutorials
(which, I think is great as you get to make your own games as you go and that
keeps you interested -- talk about gamification of learning!) and the help of
a C# Design Patterns book (a terrible choice for a beginner, but you might as
well learning the right way at the start).

In fact, the way I see it, by peddling this view of programming we're loosing
something, something that I can't define and yet I can feel as being
fundamental. Perhaps people (kids?) will develop an idea that programming is
childish and when they grow up they will grow out of programming as well? I'm
not sure. Actually, I remember a great experience toying around and
programming Crysis through CryEngine 2 Sandbox editor at age 12, where you
could design flowgraph for AI movement (enter this, go there, etc.) and other
cool things, and the awesome thing was that you got this immediate feedback
and could, for example, observe awesome battles between AIs. This could be a
fascinating teaching route to explore, whereby students learn by programming
existing (or new!) games in something like UE4 with blueprints, considering
most people go into CS with the mindset of "I just want to make games, man" so
we should try tapping into that mine.

~~~
myhf
I think associating programming with childish blocks is less of a risk than
associating programming with menial, simple, useless tasks.

Most people never get a chance to develop a feel for iteration and emergent
behavior, because they have to struggle with typing and syntax and
tabs/spaces/braces holy wars.

With Scratch, I can get 9-year-old with no math or typing skills to make an
interactive system with realistic physics, that keeps iterating and simulating
even when they let go of it. Some kids might treat that as an art class, and
grow up thinking of programming as unapproachably childish instead of
unapproachably strange. But others will remember learning a little about
iteration, and object property accessing, and physics, and emergent behavior,
instead of learning a lot about syntax.

------
protomyth
"This is the kind of class that attracts students who actively want to take
it: students who are already interested in programming."

I would love programming to be more accessible and a much more diverse
community, but I think people are starting far from the problem.

Look at the percentage of K-8 teachers teaching Math and Science that did not
major in their field. Now look at the ratio of female to male teachers in both
K-8 and pre-K.

We are not providing proper role models in the math and sciences since the
teachers teaching the subject didn't consider them in detail enough to major
in them. Neither are we providing proper role models for both sexes
professionally interacting. The problem is long standing by the time students
pick majors and their perception of STEM is long formed. Their are reasons you
have to be already interested to succeed and it has to do when "already"
happened.

~~~
jherritz
You make some very valid points. There is an underpowered feedback loop here
that would take years to amplify naturally. That's why it's important to have
programs like BJC right now. It helps tilt the scales without relying on
changes to the composition of the teaching field.

~~~
breakforge
> It helps tilt the scales without relying on changes to the composition of
> the teaching field.

What's are the initials BJC? My searching turned up nothing that immediately
fits the context, and I'd like to read more

~~~
sudont
[http://bjc.berkeley.edu/](http://bjc.berkeley.edu/)

It's in the article.

"Snap is the programming language for UC Berkeley’s Beauty and Joy of
Computing curriculum (BJC), which aims to bring introductory CS to a wider
range of students than the typical intro to programming does. BJC is also used
at the high school level, and is a curriculum for the new AP Computer Science:
Principles test."

~~~
breakforge
Thanks. I was under the impression that it was some channel for experimenting
with education. Whoops.

------
FD3SA
This insane obsession with making programming the "everyman" skill boggles the
mind.

"Programming", better described as applied mathematics, is not and has never
been an accessible profession.

Just because you have no trouble taking medication, doesn't mean you are
qualified to be a doctor. Just because you use a smartphone, doesn't mean you
are qualified to commit to the Linux kernel. I am constantly fascinated by
attempts to frame computer science as a trade similar to bricklaying or
plumbing. It really could not be further from such work.

Computer science is the application of mathematical logic, which by
definition, is out of the reach of the majority of students. One look at
mathematical aptitude test scores for the general public will disabuse you of
the notion that everyone can program. At best, you need to be at least one
standard deviation above the mean in mathematical ability to be a competent
computer scientist. At worst, factoring in global competition in an
unregulated profession, you need to be two to three standard deviations above
the mean. Assuming a normal distribution, that's about 2.5% of the population.

So, why are we lying to kids with promises of Google jobs? If they're that
good at math, they'll know it. They'll be autodidacts, and will use the
plethora of resources already available to reach their potential.

I'm all for easy to use graphical programming languages, as they truly help to
visualize algorithms in a tangible way. But selling it along with an "everyone
can program and make money doing it!" promise is absurd.

~~~
sparkie
Less than a millennium ago, the idea of making reading (let along writing) an
"everyman" skill boggled the minds of people like yourself - the already
literate who had pretty comfortable jobs because they had a skill that maybe
2.5% had. Fast forward about 400 years and more people can read than those who
can't (at least in developed countries)

Perhaps the reason you're stuck in this old mindset is because you see
programming only as a means of employment, and not a basic skill that nearly
every will have in a couple of centuries. Not being able to program will be
akin to not being able to read, and we'll have developed a wealth of special
needs programs to help those who can't hack it.

------
phren0logy
Interesting point from that page is that Brian Harvey
([http://www.eecs.berkeley.edu/~bh/](http://www.eecs.berkeley.edu/~bh/)), one
of the last hold-outs who was teaching intro Computer Science with Structure
and Interpretation of Computer Programs (at Berkeley), is involved as a
contributor.

Here are the materials from his excellent SICP course:

* Videos - [https://www.youtube.com/watch?v=zmYqShvVDh4](https://www.youtube.com/watch?v=zmYqShvVDh4)

* Supporting docs - [http://inst.eecs.berkeley.edu/~cs61a/sp11/](http://inst.eecs.berkeley.edu/~cs61a/sp11/)

* SICP textbook - [http://www.mitpress.mit.edu/sicp/full-text/book/book.html](http://www.mitpress.mit.edu/sicp/full-text/book/book.html)

~~~
tygorius
Harvey is really a force for good when it comes to making programming and
computer science topics accessible to more people. In addition to SICP and
SNAP work, he was also a force behind UCB Logo and wound up writing a three
volume introduction to computer science for high schoolers. People can read
them online at
[https://www.cs.berkeley.edu/~bh/logo.html](https://www.cs.berkeley.edu/~bh/logo.html)

------
kazinator
> _The thing is, the students who are succeeding with this approach to
> computer science education are primarily white and Asian men. No other
> demographic is even close._

So, cue solution: some toy visual programming language that cognitively
challenged (i.e. not white or Asian male) persons can understand and work
with?

How can people who are trying to address social discrepancies (sensitive
types) fail to clue in to the possibility an obvious angle on their message?

(Of course, I have all seasons of Daria in my phone, so that helps with the
cynicism. La la la LA la!)

Maybe they should just say, "we have courses in a nice, fun graphical computer
language that doesn't require typing in program text coded in a cryptic
notation. We believe it appeals to a wide range of personalities and
temperaments, including ones that are not commonly associated with people in
the engineering fields". That already contains enough of a stereotype about at
least one group; no need to get into naming races and sexes.

------
TsukasaUjiie
The Australian National University teaches a course in Snap aimed at non
computer science majors.

Whilst I was originally skeptical of the language and thought it might be
"babyish" I was pleasantly surprised to see how expressive it was. Most of the
labs use a javascript-y like object model behind the scenes and provide useful
functional programming primitives (map/fold/etc <3).

The response from the students thus far has been pretty great. Some of them
are looking into taking more programming courses as part of their degrees;
often very separate from computer science. I'm not sure if we would have
gotten this result chucking them straight into a CS101 course.

[https://artofcomputing.cecs.anu.edu.au/](https://artofcomputing.cecs.anu.edu.au/)

------
unscaled
I like the idea of visual programming as a way of making introductory
programming classes more engaging and draw kids into programming. But it's
definitely not a new concept, and many kids in previous generations have had
LOGO classes.

I have a major problem with this post's attitude though. In the same way LOGO
classes did not make programming more accessible to "non-White/Asian males",
block language like Snap wouldn't.

Girls don't need the programming language to be pink and pretty so that they
could properly learn program. In fact, the period where the female programmers
in the US had the largest representation was exactly the period of
inaccessible beasts which had to be fed machine-code instructions directly in
plugboards and switches. I know it's hard to tell from the black-and-white
photos today, but the ENIAC switchboards were definitely not pink.

What drives women out of technology today is that they are discouraged by
society to be enthusiastic about computers and Math early on, and when they
become older and do want to try, they find a largely-male field with people
who had early access to programming having the upper hand on them, and often
treating them with prejudice.

The reason black and hispanic people are underrepresented in programming (in
the US, of course - in other countries that would be other ethnic groups, but
railing against Americanocentrism is out of fashion I guess) is that they are
provided a much lower level of education _in general_.

The best way to increase the number of female programmers is to simply
encourage young girls to program by not making it 'a boys' thing', without
segregating them into programming in visual block languages which would earn
them (undeserved, but very real) scorn later on. The best way to encourage
more ethnic diversity is to raise the level of education in the schools the go
to, as well as dealing with the socio-economic problems that make them
disadvantaged compared to their peers.

As much as I like the idea in general, introducing Snap as a language
specifically targeted for 'underrepresented demographics' is only going to
strengthen the misconception that these demographics are 'less smarter' than
the White and Asian boys who ace programming without needing all these fancy
visual blocks.

~~~
skybrian
It seems like there must be some other reason why you're bothered by this
project, because these just look like rationalizations:

First of all, why do you think Snap is dumbed down? It's a language that has
macros (special forms) and even call with continuation. It seems like that's
rather advanced stuff.

Second, as I remember it, Logo was pretty fun and reasonably popular. It seems
like it was a success. Scratch is also a success. Why not build on success?

Third, the Snap UI is not pink. Nothing in Snap's UI says it's specifically
targeted towards anyone other than beginning programmers.

The researchers say they're interested in reaching minorities. As you say,
it's a tough problem, and it's likely that a good programming environment
won't solve it alone. But that's why they're putting together a curriculum for
teachers. And who knows, maybe learning about computer programming might get
kids interested in math, rather the other way around?

This project is at the very least harmless. They're going to do the experiment
and if it doesn't work, they'll make adjustments or maybe rethink their
approach.

Maybe think a bit deeper about why you really find it objectionable?

~~~
unscaled
Did I ever said snap is dumbed down? Read my post again. I said it would get
the undeserved reputation of being "dumber" than "real programming".

Did I ever say Logo was unsuccessful? It was at the very least tremendously
popular in schools. But it didn't bring more underrepresented demographics
into the fold.

Did I ever say snap's UI was pink?

Before ascribing ulterior motives or unconscious reasons to me, please make
sure to read what I wrote properly.

If it wasn't clear, I've got nothing against Snap and I think it's very good
to have a visual programming language that tries to support important CS
concepts like recursion and closures. I've got nothing against Snap - rather
the contrary.

I just thinks the premise of this post is misguided and the spirit behind it
is actually detrimental to its stated goals.

Snap could be great as an engaging teaching tools for novice programmers of
ALL demographics. But marketing as an aid for increasing diversity is not just
wrong, but could be even harmful, since it could pave the road for technical
segregation.

~~~
skybrian
Okay, fair enough. Sorry for misunderstanding you.

But I'm still not clear about what the turnoff is supposed to be. Marketing
something as an "aid for increasing diversity" to teachers seems likely to be
appealing to them. Teachers are interested in reaching all their students,
particularly in a place like NYC.

Maybe it's not great for reaching kids directly, but that's a different
marketing campaign. (Snap doesn't seem to be designed to let kids jump right
in like they would with a game.)

Technical segregation seems unlikely; assuming the kids become genuinely
interested in programming, they will move on to other languages like they did
from Logo.

------
shiggerino
If we're going to have drag-and-drop programming, why not do dataflow, which
is where it really comes into its own? Of course if you want to churn out code
monkeys for conventional languages, this is great, but if you want to expand
people's minds, not so much.

~~~
dyarosla
There is a big issue with teaching to code and that is if you want it to scale
and have teachers introduce kids to coding, you have to make sure that the
material taught is very in line with core requirements. Computer science and
coding curriculum is not set in stone yet, but where it's going covers the
most common language constructs of today, like loops, conditionals and
procedural coding. It is a stretch to show how learning to create dataflow
programs maps to procedural understanding and algorithms. Moreover, there's
very few general purpose dataflow environments that are widely accepted in
computer science, and so learning dataflow won't necessarily ease the
transition for students to later learn modern programming languages.

TL;DR For a layperson, the association between dataflow and 'real coding' is
very weak. For a programmer on the other hand, the association may be less
weak, but the skill may nonetheless not be applicable to most real world
applications.

~~~
harperlee
> For a layperson, the association between dataflow and 'real coding' is very
> weak.

Excel is basically a dataflow. You can avoid talking about loops with maps,
that can be understood immediately with excel tables.

Something like Excel that does not divide so strongly between cells and VBA
should be ideal. Resolver One was very interesting.

That's the approach that I think it's the best: Excel is right now how people
that need sort-of programming but don't program bridge the gap. It's huge.
It's everywhere. And it's _VISUAL_.

Perhaps a simplified Excel for educational purposes is the ideal way to expose
people to programming, formal thinking, systems thinking, functional
definitions, etc. And, when they jump to real-life Excel, and get culture
shock, perhaps they keep using that original program that they were taught.

Perhaps there is a viable startup here....

~~~
dyarosla
I believe the closest startup/visual language in development now is Eve :
[http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-
rethink-...](http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-
programming/) But it's pretty hush hush atm beyond some blog posts.

------
jastr
A lot of the comments on this thread seem to find these drag ’n drop, “dumbed
down” tools not only useless but also harmful to future programmers.

Did you write the compiler your code is running on? What about malloc? What do
you mean you’re using “abstractions”… shouldn’t you be writing in assembly
right now so you can tell the computer exactly what it should be doing?

Programming is not about typing text into computers, it’s about getting
computers to do what you want. When we say that in 15 years, everyone will be
programming, it doesn’t mean everyone will be writing C code. We mean everyone
will be better at telling their computers what they want them to do, and this
is most certainly a step in that direction.

~~~
dragonwriter
Not all abstractions are equal, however. The people that don't think this kind
of environment don't dislike it because it's an abstraction, they just don't
think it's a beneficial abstraction.

------
evolve2k
I love this progression and think it's exactly right for high school and entry
college programs.

Conceptually when do people think is the right time to switch from one of
these visually languages (optimized for asthetic and visual approachability)
across to text based coding?

What key 'ah ha' moments for the new student define when they are ready to
cross over?

~~~
analog31
I think the cross-over occurs when the graphical language becomes too
cumbersome due to ergonomics or readability. I have only seen two graphical
languages -- Scratch and LabVIEW. I think that these languages may be easier
to learn, but are not more _readable_ than text based languages, and vastly
less ergonomic. To this day, my eyeballs and carpal tunnels ache just thinking
about LabVIEW.

My guess is that the corresponding ah-ha moment is when programs grow to where
they depend on the benefits of modularity.

~~~
striking
LabVIEW makes the syntactic stuff a lot easier, but as soon as you want a
modular program or you want to create something polished, it stops working the
way you want it to.

And I'd argue that it's because LabVIEW is meant only for R&D purposes. It
does work fairly well for FPGA-based applications but that's often because
those programs are fairly compact and uncomplicated when done right.

I wish there were a more modular and useful version of LabVIEW (or G or
whatever the language is called) because I'd like to use something like that.
Not having to worry about execution order is a marvelous thing, and it really
transforms the way one thinks.

~~~
analog31
Agreed. I used LV for some R&D stuff, many years ago. More recently, I became
responsible for a product whose support software had been written in LV -- by
a guy who was certified as a LV expert -- and the code was impenetrable.

------
bloaf
Consider middle/high school Spanish classes. There are a diverse mix of people
in them and they are taught by a diverse range of people with all sorts of
colorful textbooks and methods. Do most students come away from those classes
with any long-lasting appreciation for Spanish? Do they retain any useful
information? In my experience, most people took it because a foreign language
was required, and promptly forgot all but the basic tourist phrases once they
got to college.

Basically, I think we shouldn't be setting our sights too high with regards to
programming education. It certainly is possible for everyone to learn, just
like every other language. But life is short, and it isn't reasonable to
expect everyone to be interested in speaking math to computers, just like it
isn't reasonable to expect everyone to be interested in speaking Spanish to
people.

------
davidhariri
Programming is _already for_ everyone!

------
kmenzie
I really like snap and scratch, and I think they're part of the right
approach, but I can already here "those kids" (you know who they are) talking
about how whichever students had to take the snap class were dumber, and
couldn't really code, and weren't 'real cs majors'\-- probably before lecture
in some early college cs class while the snap kids are sitting around them.

To be clear, I don't have a solution to this part of the problem, but I think
that moment (listening to 'those kids' talk about who the 'real hackers' are)
can lose as many non-typical engineers as the moment when they have to install
their first IDE

~~~
quadrature
Well if everyone took snap as part of the curriculum then you probably won't
have that problem. You will always have varying competencies in education.

------
jherritz
It looks like there was a nice discussion not long ago on Hacker News about
Snap as a programming language.

[https://news.ycombinator.com/item?id=9591460](https://news.ycombinator.com/item?id=9591460)

------
copsarebastards
This isn't the first time something like this has been tried, and my criticism
of it is the same: this isn't really "programming".

When you create a learning language, you're inherently taking a bunch of
concepts from modern programming, and you're dividing them into two groups:
things that you think are necessary for what the student is doing to be called
programming, and things that aren't necessary.

Somewhere along the line, Snap, and its precursor, Scratch, decided that
_text_ wasn't a necessary part of programming. The motivation for this
decision seems to have been that they think that text is part of what scares
some people away from programming. That may or may not be true, I don't know.
But what I do know is that if you aren't using text, I have a hard time
describing what you're doing as programming.

Sure, a lot of programming concepts can be expressed visually. But rapidly
these visual representations break down when you try to build anything
complicated out of them, because you start having to do more complicated
things along the way. Version control is tied to text: you can't revert part
of your changes to a flow diagram easily. As you learn more about a problem
domain, you decide you want to rename a variable? Good luck with find/replace
without text. Or are you just going to drop the concept of a variable? What's
the visual representation of a type?

The result might be that you get people interested in something you're calling
programming, but their interest is based on false premises. When you finally
expose them to actual programming, all the parts that were too scary to show
them to begin with are all there. All you're doing is losing them later.

I think that BASIC did a much better job of this back in the day. It gave you
a lot up-front, and to do this, some of the concepts weren't _ideally_
scalable, but there wasn't really any upper limit to what you could do with
BASIC. The result is that all those scary concepts were there, but you didn't
have to confront them all at once. Eventually you'd have to learn that, say,
turtle graphics aren't the way we really draw things, but until you learned
that, you could still do everything you wanted, it was just a little slow. I
got all the way up to writing code for real, full-sized robots in BASIC
(albeit by that time I had started learning C++). There's nothing that would
have stopped me from writing real-world applications in BASIC (and indeed,
many real-world applications _are_ built in BASIC).

It may be that Snap or one of its ancestors will someday reach the level where
you could build a real-world application in it. I hope that happens, and I
hope it makes programming accessible to everyone. But for now, I don't think
that what Snap teaches is really programming.

~~~
hardmath123
Well, part of the motivation for blocks is that you don't need to know any
special incantations. Instead of being faced with a blank text editor and a
cursor, you're given a toolbox full of toys to explore, which (for me, at
least, when I was in the 5th grade) is extremely empowering.

> But what I do know is that if you aren't using text, I have a hard time
> describing what you're doing as programming.

The thing is, kids using Scratch end up creating amazing stuff: I've seen
recursive raytracers, real-time multiplayer-over-the-network FPS games, a
chess AI (game tree + alpha/beta pruning), emulators for various video games…
I can't really look at that and not describe it as programming.

> What's the visual representation of a type?

Shape. In Scratch and Snap!, a block that returns a boolean is diamond-shaped,
and holes for boolean arguments are diamond-shaped. So you can't accidentally
put a number into the condition for IF--the shape literally doesn't fit.

This beats TYPE ERROR: COULD NOT COERCE "INT" TO "BOOL" (LINE 12) any day.

> Good luck with find/replace without text.

I think it's _easier_ to right-click a variable's block and select "rename…"
from the dropdown than to run :%s/badname/goodname/g and hope you don't
accidentally change non-variable instances of that substring. And since the
block knows its scope, you know that only in-scope uses of that variable will
be updated.

> Version control is tied to text

It turns out that version control with Snap! and Scratch projects is really
easy, since the internal datastore is just XML and JSON, respectively, both of
which play reasonably well with git. But when you're teaching someone to
program in an introductory CS course, version control should be very low on
your priority list. There are so many more exciting big ideas worth teaching.

> When you finally expose them to actual programming, all the parts that were
> too scary to show them to begin with are all there.

The way I see it, once you get them excited about computer science, the things
that were too scary aren't scary anymore: they're exciting.

~~~
copsarebastards
> Well, part of the motivation for blocks is that you don't need to know any
> special incantations. Instead of being faced with a blank text editor and a
> cursor, you're given a toolbox full of toys to explore, which (for me, at
> least, when I was in the 5th grade) is extremely empowering.

Okay, so why couldn't you do the same thing with text? If you can fit a bunch
of blocks on the screen, why can't you fit a bunch of function names and
keywords on the screen?

> The thing is, kids using Scratch end up creating amazing stuff: I've seen
> recursive raytracers, real-time multiplayer-over-the-network FPS games, a
> chess AI (game tree + alpha/beta pruning), emulators for various video
> games… I can't really look at that and not describe it as programming.

Okay, that is impressive. But are those same kids also writing C or Python?
I've done some cool stuff with Scratch back in the day, but I don't think I
could have done it if I hadn't already been pretty well-versed in HyperTalk,
BASIC, and C++ (at the time).

> Shape. In Scratch and Snap!, a block that returns a boolean is diamond-
> shaped, and holes for boolean arguments are diamond-shaped. So you can't
> accidentally put a number into the condition for IF--the shape literally
> doesn't fit.

That's certainly easier to understand, but it's also far less capable. How can
it handle structs (or classes)?

> The way I see it, once you get them excited about computer science, the
> things that were too scary aren't scary anymore: they're exciting.

I really hope this is true, I'm just not sure it is.

However, I really hope people keep researching this and prove me wrong.

