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.
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.
What visual programming languages do is lower the barrier for entry. Once you're hooked, and you begin gaining experience, you will naturally understand the limitations of the platform. By being inquisitive, you will realise that the software used in the real world isn't all built in Scratch. But, to breed that inquisitiveness in children at a young age requires making it accessible.
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.
I come from a similar background. I started with BASIC, moved briefly through QBASIC to Borland C++. I also learned programming through making games (before I had access to the web too)! Yet... I don't have the same reaction to these tools that you do.
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.
There are certainly other ways to do visual languages and it's worth experimenting with them. But this visual approach seems to work well so why not refine it?
"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.
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.
"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."
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.
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.
> "Programming", better described as applied mathematics, is not and has never been an accessible profession.
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.)
This is silly. Learning to program is learning a new language, learning to make something. It's being creative, persistent, and paying strong attention to detail. It takes time, energy, passion, blood, sweat, and tears, but is a skill that can be acquired and honed.
Interesting point from that page is that Brian Harvey (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:
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
> 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.
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.
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.
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?
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.
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.
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.
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.
> 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.
This, and Unix pipes is basically dataflow, so there's two useful tools laypeople will be able to easily access and work with if they can grok dataflow. "Real coding" just isn't terribly relevant to laypeople.
Do you have any thoughts about how you would implement dataflow programming in Snap? I know I'd be excited to see Snap hooked into some of the really interesting streaming data work we're doing at MIOsoft (beyond just the storage of projects).
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.
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.
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?
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.
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.
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.
I'm confident that is still an open question. That said, the creator of Snap would probably say there is no need to transition - ever. All Snap code can be viewed and edited as text. It's not an either/or decision, in other words.
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.
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
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.
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.
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.
> 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.
Snap lets you export, edit, and reimport the code as XML, so version control, types, all the other things you mention are just as feasible to use as with any other language.
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.
Yes, it really is true. The XML is not a "completely different language". It is an alternative (but 1:1) representation of the internal Snap code.
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, it really is true. The XML is not a "completely different language". It is an alternative (but 1:1) representation of the internal Snap code.
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?
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.