Snap: Programming for Everyone
blog.miosoft.com
blog.miosoft.com
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.
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.
I've been trying to get our kids interest in programming, and the most successful attempt yet was using an iPad app called Hopscotch - a drag-and-drop language that's severely restricted.
My next step is to try and get them using Unity3D. I'm not sure if C# is the way to go, but maybe it doesn't matter. What's most important is motivation! It has to be fun, and accessible. These basic languages are a way to suck people in who otherwise might have passed over programming completely.
You, for example, probably very quickly realised that if you wanted to make games with a GUI, QBASIC was not the tool for you, but by the sounds of it, that didn't dissuade you.
Personally, I'm of the opinion that your very first language doesn't matter very much. As a programmer, you will (should) be learning plenty more, so the first one is more about learning how to learn than anything else.
QBASIC, to the best of my recollection, had none of those things. So how, exactly, is Snap "dumbed down" by comparison?
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.
What's are the initials BJC? My searching turned up nothing that immediately fits the context, and I'd like to read more
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."
"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.
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.
Just because you're not a cordon bleu chef doesn't mean you shouldn't know how to cook a basic meal.
Just because you're not a world-class fashion designer doesn't mean you shouldn't know how to reattach a loose button.
And, more directly: just because you're not a Linux kernel committer doesn't mean you should be mystified by your home's programmable thermostat.
Not all people who use programming in their work are professional programmers, just like not all people who use writing in their work are professional writers.
> Computer science is the application of mathematical logic, which by definition, is out of the reach of the majority of students.
No, the application of mathematic logic is not, by definition, out of the reach of the majority of students.
(And programming and computer science are different things, anyway.)
Here are the materials from his excellent SICP course:
* Videos - https://www.youtube.com/watch?v=zmYqShvVDh4
* Supporting docs - http://inst.eecs.berkeley.edu/~cs61a/sp11/
* SICP textbook - http://www.mitpress.mit.edu/sicp/full-text/book/book.html
f(a, b)
(f a b)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.
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.
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.
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?
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.
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.
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.
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....
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.
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?
My guess is that the corresponding ah-ha moment is when programs grow to where they depend on the benefits of modularity.
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.
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.
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
Also, at a younger age, programming doesn't have to be taught as "computer science." It can just be an activity.
For me, it was "real programmers don't use BASIC." I let my productivity speak for itself, in things like student research projects.
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.
The XML Snap exports to is a completely different language from Snap. You're not versioning Snap, you're versioning the XML that Snap exports to, and unless you're really planning to hand-code software in XML the composability is just not going to be there. Version control involves tying code changes to functionality changes, and unless you're directly writing the XML you have no way of being sure that such things are maintained.
Yes, you can version it, but you're versioning it as a black box, in the same sense as you would version an MP3 or a JPEG. The XML allows you better compression than a binary format, but it doesn't give you the ability to textually navigate changesets.
There's no absolutely reason why the Snap UI couldn't be feeding the XML to a version control system behind the scenes, and recovering previous versions from that system at will.
Oh really? What is the 1:1 representation of a diff on XML in the visual code?
Representation in a programming language is a huge feature of the language, and it's particularly ridiculous to claim that it isn't for a language whose key feature is having a visual representation rather than a textual representation. An alternative representation of a programming language is a completely different programming language.
> There's no absolutely reason why the Snap UI couldn't be feeding the XML to a version control system behind the scenes, and recovering previous versions from that system at will.
Yes, but that's not even the most commonly used functionality of version control. How do you propose we do visual merges? Or are you actually proposing that we write code directly in XML?
> 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.
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.