I have been considering taking a visual programming language, such as Snap!, to my high school students as a way to make some of the concepts we delve into a little more fun. The kids themselves already have a pretty substantial background in Java, Python, C and 6502 assembly, and many of them are also familiar with the JS/PHP/SQL stack for web dev.

I have a very strong feeling that they won't consider a block-based language to be a real language, even though it contains typing, parameters, lambdas, etc. How do I get past the initial hump and persuade them that this is worth their time?

  • 38
    $\begingroup$ I'm curious why you think it'll make things more fun or what you plan to do to make things more fun. One of the downsides of DnD languages is that to do something substantial you need some serious screen real estate and in my experience, experienced students have found repeated dragging and dropping tedious over using text editor functionality. This is not to say that DnD won't be great in your case but I'm looking for more info on how you want to use them $\endgroup$ – Mike Zamansky Jun 20 '17 at 12:12
  • 21
    $\begingroup$ If these kids already have that extensive a programming background, what you're proposing isn't likely to be fun. $\endgroup$ – user2357112 supports Monica Jun 20 '17 at 17:17
  • 4
    $\begingroup$ Put your money where your mouth is. Build something useful/cool in the language and demo it for them while introducing it. $\endgroup$ – Jeutnarg Jun 20 '17 at 18:27
  • 7
    $\begingroup$ From the sound of it, your students use programming languages to do things. Snap! is going to have to earn its keep in the minds of students like that. I'm a developer, not a teacher, but my first thought when I looked at the examples on the Snap! page was "this is actually just a text based programming language given goofy colors." Contrast that with something like LabView which is a serious language used in serious contexts (and with a serious price tag, of course). You're going to have to convince them that it's not different for the sake of being different. $\endgroup$ – Cort Ammon Jun 20 '17 at 20:06
  • 3
    $\begingroup$ What kind of high school students are you lucky enough to work with?! I don't know many high school students with that substantial a background in programming. $\endgroup$ – Sam Weaver Jun 20 '17 at 23:25

14 Answers 14


Two thoughts:

  1. I'd start with telling them why you think it's worth their time. Whatever I or anyone else says on here, you're the one who thought it would be fun and worthwhile, and you must have reasons for that. Your reasons are more authentic and probably more applicable to your students than our reasons will be. Just be straight with the kids about what they are.

  2. You mentioned assembly, C, Java, and Python, which means that the kids not only have experience with "real" languages, but they have experiences with languages with a wide range of abstraction. You can present DnD/block programming languages as yet another level of abstraction, in which common language structures (blocks and certain bits of syntax) are abstracted visually rather than textually. This is not so radically different from what Python does when it visually presents code blocks as indented regions rather than as text sandwiched between curly brackets. You can point out the similarities between the block interpreter and the Python interpreter. You can compare the power, efficiency, learning curve, and programmer time requirements for each language and maybe even make a nice chart on the board. This will reinforce the idea that when comparing Snap! to Python to C, they really are comparing apples to apples.

  • 8
    $\begingroup$ so after comparison it turns out that visual blocks are worse in all aspects. then the students won't really understand why the teacher did bring it up at all. $\endgroup$ – Display Name Jun 21 '17 at 5:06
  • 3
    $\begingroup$ "This is not so radically different from what Python does when it visually presents code blocks as indented regions rather than as text sandwiched between curly brackets." Actually, yes, it is quite different. Python is enforcing an arrangement of text; it isn't abandoning text. The rest of your answer might still fly. $\endgroup$ – jpmc26 Jun 21 '17 at 5:26
  • $\begingroup$ @jpmc26 Python is still text, but you don't get to pick the keyword you want to use, e.g., for a while loop. Snap! effectively just replaces the fixed scaffolding you would type with a graphical element. Python still gives you more flexibility in what you can do within the fixed elements, but the similarity is still there. (Full disclosure: I've only used Scratch, and that years ago, but Snap! looks fundamentally the same.) $\endgroup$ – chepner Jun 21 '17 at 17:40
  • 1
    $\begingroup$ @chepner What I see as "radically" different is the departure from typing simple words using standard characters to using custom non-text, graphical/binary items that are more difficult manage because we don't have dedicated tooling for them (like keyboards and find/replace). I do understand that there might be similarities in terms of structure, especially after the text is parsed, but I see abandoning text as quite different. I understand that, in some ways, this analysis supports the rest of the answer. $\endgroup$ – jpmc26 Jun 21 '17 at 18:13
  • 1
    $\begingroup$ @jpmc26 considering that assembly is a "radical" departure from the underlying machine code ("you can read it now!"), and C is a "radical" departure from the ~1:1 of assembly to machine code, and Haskell is a "radical" departure... etc. I would say this supports Neal's arguments more not less. "...are more difficult to manage because we don't have dedicated tooling for them..." is generally what managers say to resist switching to new paradigms. The real question to potentially bring up is "Is this abstraction of programming particularly useful? If so, for what classes of tasks?" $\endgroup$ – Blackhawk Jun 21 '17 at 20:54

Everyone uses high-level languages these days, and we let compilers do the grunt work. Block-based programming is just a kind of IDE with a slightly different autocomplete mechanism. Block-based code can be trivially transpiled to textual form. After they complete an exercise, you can have them perform that conversion to textual code or pseudocode.

To debunk the "Real programmers don't use _____" fallacy, you could discuss what happens when you take that mentality to its logical extreme.

XKCD 378: Real Programmers

  • 1
    $\begingroup$ Some of the commenters at the top should make note of this answer. $\endgroup$ – Ben I. Jun 21 '17 at 17:44
  • $\begingroup$ Don't believe it, it is not true. We use sed. $\endgroup$ – ctrl-alt-delor Jul 10 '17 at 17:41
  • 1
    $\begingroup$ Snap has a facility to allow you to write a translator, to convert snap code to any other language. And another to make snap look like another language. $\endgroup$ – ctrl-alt-delor Jul 10 '17 at 17:43

You could use some environment that lets you switch between blocks and text and work in both. That way, students can see firsthand that the code in the blocks converts to textual "real" code. This can help them understand the leap.

Here's one example of blocks switching with text on a Karel program on CodeHS (Note: I'm one of the founders of CodeHS)

enter image description here


Here's how I explained it to my students after teaching with App Inventor during a pre-college summer program:

With textual programming languages, your program won't work if you have a semicolon or even a space character (in Python) out of place. This can be frustrating, especially for beginners. They might conclude that programming is about punctuation, when it isn't; it's about logic, design, teamwork, and problem-solving. The argument for starting with visual programming languages is to expose beginners to the essence of computer science, rather than the superficial issue of placement of curly braces, colons, etc. If they enjoy it, they can go on to learn those things.

To use an analogy, programming with blocks is like writing stories with word magnets. On the positive side, you don't need to worry about spelling or punctuation; on the negative side, your vocabulary is limited.

Programmers disagree about whether using languages like App Inventor (or Scratch or Alice) is really programming/coding. To me, it is, since the logic is there. I don't see a fundamental difference between using a mouse and using a keyboard. That would be like saying that Jean-Dominique Bauby wasn't a real author because he used blinks instead of a keyboard or pen. (See also these Dilbert and xkcd cartoons.) To be fair, not everyone agrees with me.

Nonetheless, I can understand the frustration of students who wanted to learn "real coding" and why visual programming languages tend to be used just by beginners. One of the most common questions about App Inventor is: Why can't I see and modify the Java code created by App Inventor? The answer is that App Inventor doesn't create Java code; it creates something called byte code that is not human readable. Learning textual programming languages is incredibly useful and fulfilling; it's like moving from Lite Brite to an unlimited set of paints and brushes. I hope that some of you go on to do so.

Disclaimer: I am one of the creators of App Inventor.

  • 1
    $\begingroup$ My personal definition (or test) of a "real" programming language is if you can use it to directly call the host system's platform API or not - so C and C++ are, as is C# and Java (through P/Invoke and JNI respectively) but not Flash ActionScript or LOGO. Would you agree with my definition? $\endgroup$ – Dai Jun 21 '17 at 6:43
  • 2
    $\begingroup$ @Dai That should be a separate question, not a discussion within comments. $\endgroup$ – Ellen Spertus Jun 21 '17 at 17:53

I was at this camp one summer, and it was a programming camp for building models of different systems. I was super excited - I'd already been programming on Khan Academy and Codecademy. So I walk in, and they say that we'll be using this language called StarLogo Nova. We open our chromebooks, go to the site - and I begin questioning things, because I figure out pretty quickly that it's a drag and drop language.

I had (have?) a dislike for drag and drop languages - I had tried Scratch after doing what I considered "real" programming, and I didn't like it. However, that class changed my mind. We created a model of an epidemic, a model of an ecosystem - and I was hooked. I literally still occasionally take a look at those programs when I'm in the mood and add new features.

The about-face was because, I think, it felt useful. I felt more able to create something cool in StarLogo Nova than Scratch. So I guess, I'd say to first, pick a good, fun DnD language, and second, build something cool in it and show it to them.

You might also go into the idea of higher vs lower level programming languages, with DnD languages just another step higher than something like Python. Assembly is no more "real" a coding language than Python is. (If anything, it's the other way round =P)

All this being said, don't stuff beans up your nose - your students may not even be thinking any less of DnD languages and may have quite a bit of fun without you saying anything at all.

  • $\begingroup$ I haven't used StarLogo Nova but have extensively used NetLogo (and years ago StarLogo). The things you liked - were they because they were drag and drop or were they due to the modelling environment which NetLogo provides with a text based language. Just curious. $\endgroup$ – Mike Zamansky Jun 20 '17 at 23:43
  • $\begingroup$ @MikeZamansky StarLogo Nova does provide a nice modelling environment with a wide array of things you can do with it, which I enjoyed - I didn't like it for being drag and drop, I liked it for its usefulness. That it was drag and drop didn't seem like such a bad thing because of how much I liked everything else. $\endgroup$ – heather Jun 20 '17 at 23:47
  • $\begingroup$ Yes, build something useful. Something fun if you can. That would probably work with Scratch as well. $\endgroup$ – Buffy Sep 21 '17 at 11:48

Here I would go to Microsoft's Project Spark (even though it is discontinued, I think it is still downloadable. I have a local copy, so I'm not sure. But it's worth a shot)

Project spark is Microsoft's "experiment" as a game for making games. It is visual. And you can say block based. It's not like Scratch or Snap!, but it is visual.

It makes game creation quite easy, (there are limitations on the game models that can be used and other stuff, but that's not too relevant for this answer) and is very good to teach programming. Types, Objects, Methods and many other things can be taught with it.

I have used it for a while, and it is a real language. I suggest you try it, and maybe search videos in youtube that show aspects of Project Spark.

A sneak peak to the block programming (or "Kode") of Project spark:


The kode (not a typo) is fairly straight forward and self-explanatory.

EDIT: It is discontinued, but can still be used. It is free, and a very good way to learn programming concepts (as well as a good way to have fun)


It isn't very "fun", but there are visual languages widely used in the industry. For example the FBD language.

From Wikipedia:

The Function Block Diagram (FBD) is a graphical language for programmable logic controller design, that can describe the function between input variables and output variables. A function is described as a set of elementary blocks. Input and output variables are connected to blocks by connection lines.

EDIT: here my try at a real example:

Here in Germany Siemens-hardware and -software is widely used in a wide variety of factories, power plants and most other aspects of automation. The programming languages the PLCs of Siemens are programmed with are based on the IEC 61131 and the EN 61131 (German). They are called FUP (function plan, looks like Flipflops, I had those in my electrical engineering studies), KOP (contact-plan, looks like a circuit diagram), GRAPH (flowchart-style), AWL (really basic Statements) and SCL (a high language based on another language... i think pascal).

The first three of those are all graphical and most people simply use whatever fits them the most. You can translate those languages into each other with a simple click, within some borders.

There are several IDEs used, but the most common is TIA-Portal (that's kinda new for newer PLCs of the S7-series), Simatic Manager (older S7-series) and an even older one I don't know the exact Name of for the S5-series. The naming process of Siemens is extremely weird and a world of itself.

Siemens is used in other countries too, but of course I don't exactly know how much in detail.

  • 1
    $\begingroup$ Welcome! Could you please add details on why FBD would be a good idea? $\endgroup$ – ItamarG3 Jun 20 '17 at 13:52
  • 2
    $\begingroup$ That's a good example - I'm also entirely unfamiliar with FBD. Can you flesh this answer out a little bit (so that I can use your answer better in the classroom)? $\endgroup$ – Ben I. Jun 20 '17 at 14:26
  • $\begingroup$ @BenI. he's not saying to consider it for use in the classroom, but rather consider it as an example of real world usage of a visual programming language. That is, visual programming need not be necessarily "for kids". $\endgroup$ – David Liu Jun 20 '17 at 19:11
  • $\begingroup$ @DavidLiu I understood that. But if I will even use it as a passing example in class, I would need to give at least some more detail about the language, which could totally fit into the answer here to make it more useful. $\endgroup$ – Ben I. Jun 20 '17 at 19:20
  • $\begingroup$ In real industry, there's a reality that not everyone who uses our software can be versed in C++ and have 4 years of practice with the software. They need a powerful language to interact with our software which doesn't pack such a training price tag. FBDs are really popular for solving that problem. They show that there are many levels with which one can interact with a piece of software. The C++/Java code at the bottom is only one of those ways. $\endgroup$ – Cort Ammon Jun 20 '17 at 20:08

You used two key words here: "persuade" and "convince." Let's approach this issue from the perspective of the three Aristotelian rhetorical appeals: logos, ethos, and pathos.

  • Logos: Appeal to their reason as programmers. Have them create a program in Scratch or Snap!, and as they add each block, have them write the corresponding line(s) of code in a language of their choice. DnD is merely an interface for "real code" that is in fact being executed underneath the hood. Have them use their proficiency to attempt to reconstruct what might actually be happening. For example, how does one of these programs handle event-listening? How can something that looks so simple on the surface actually be running a number of more complex processes that are abstracted away? You could even start by having them focus on just the logic of their program without the implementation of the graphical implementation of the language (i.e. treating a graphic as part of a pre-constructed whose logic they don't need to worry about). Then, have them consider the sprites themselves. If they're still not convinced, give them the assignment of designing their own DnD language/interface/block and color system based on Java, Python, or C (or even assembly (!)).

  • Ethos: Appeal to two big names in computer science: Harvard and UC Berkeley. Harvard begins their famed and incredibly well-designed CS50 course with Scratch. They introduce computer science at the university (viz. Ivy League) level with a couple weeks of DnD programming. It clearly plays an important pedagogical role in the course. Similarly, Berkeley's CS10 utilizes Snap!. They build almost an entire course around this environment because it is important to emphasize the thinking behind and the logic of programming languages, not the interface or the syntax. (This is a nice time to remind students that "computer science != coding".)

  • Pathos: Appeal to the incredible complexity of some DnD programs, and let them simply feel amazed. Here is one program I just found called "Landscape Generation" in Scratch. Here's quite a bit going on here that is far beyond dragging some simple blocks around. If something like that doesn't impress them, send them to the Games tab and have them explore those and encourage them to "See inside" to examine what went into designing the game. Snap! doesn't have as easy a database of sample programs to explore (at least none that I can find). However, the same logic should apply to Scratch and Snap!. There is incredibly impressive work being done in both environments, work that clearly demands a level of skill that goes far beyond what beginners are capable of. If you really want to blow the away, show them Pokemon Go in Scratch (Harvard used this in Week 0 last fall).

  • $\begingroup$ Landscape Generation => define (Create Perspective Hack) Yep, it's real programming when it's all built on a hack :P $\endgroup$ – CAD97 Jul 26 '17 at 18:02

Full disclosure: I'm generally not a fan of DnD programming languages in high school (maybe even late middle school) and I think DnD languages are frequently used by stem oil salesmen and used incorrectly so I'm frequently down on them.

More disclosure: DnD languages can be real languages and can be properly and soundly used in educational settings.

Ok, now to answer the question.

I think the easiest way is to head over to code.org and show them their DnD language which has a convenient "show code" button which will show the Javascript (a real language!!! :-)) equivalent to the blocks. You now have a platform to talk about how the block based language visually described the same code but visually (as opposed to textually with indentation).

codesters.com also has a pseudo DnD environment and while I like codesters very much, their DnD doesn't really feel like block based programming since it's really text chunk based - I'm a fan but I don't know if it would help in your situation.


A lot of people are talking about how visual scripting is a higher abstraction, and that's all the difference, and the debate has moved more to a question of "is visual scripting 'real' programming?" The general consensus appears to be that yes, DnD languages are still real languages, and sure, it's a higher abstraction, but what does that mean?

There's a value to higher abstraction that no one seems to be mentioning, and that's the speed of it. When you remove details, you can write more, in the same amount of time. It's why we compare Python to C as 1 line for every 6. The value of visual scripting for people who are experienced programmers is the speed at which you can develop. This is an incredibly important factor in development, especially when smaller teams try to produce large, complex software.

A good example of a visual scripting system is the Playmaker extension for the Unity game engine. Every Unity developer and their grandmother uses it, and for good reason. It allows them to rapidly prototype ideas and build complex systems in hours instead of weeks. And once the prototyping phase is done? The system they built is production-ready in most cases. Time is a very expensive resource in the software industry. If the cost of time needed to perfectly optimize your game in C is more expensive than the slight loss in efficiency you'll have for a fraction of the development time, it's a foolish business decision to ignore the option which enables you to make more money.

  • $\begingroup$ Welcome to CSE? This is an excellent answer, and I hope we hear more from you in the future. $\endgroup$ – Ben I. Jun 21 '17 at 22:43

First and foremost, don't let your feeling about their feelings affect your judgement. It seems to me that most kids want to learn new things, they want to be 'beta testers' and on the cutting edge. Visual programming is something relatively new, let them be an early adopter as this new form of programming matures.

More importantly though, programming isn't about the process of programming. Programming is about accomplishing a goal. We can use different programming 'tools' to accomplish our goals.

Different languages make the process easier just like having a screw driver gets a screw in the wood easier than using an awl. And planing is easier with a planer than with a claw hammer.

Perhaps instead of convincing them what is better, have them do various exercises and let them choose their own tool set. Of course the exercises should do something interesting and in some or most cases allow the visual tool to save time. The grade should be given on the finished product - not which tool was used to accomplish the goal. If you have short exercises, have them do them in class and when the visual tool is faster, those students will be done sooner. Let them decide how they want to spend their time.

Remember the goal - it isn't just to learn a language, it is to teach students how to make good decisions and (hopefully) those lessons carry over into everyday life.

  • 1
    $\begingroup$ Very nice answer. Welcome to CSE! $\endgroup$ – Ben I. Jun 22 '17 at 20:31

Have your students write a visual programming editor.

It sounds like your students are pretty savvy, so what better way to show them how awesome a visual editor can be than to have them build their own! There are many benefits to this approach.


They're creating software to make them more efficient at what they already do and love.


The students can choose their preferred language.
This could also be a solo or a group project.


This is an assignment with some legs. It's not something that will go into a folder and be forgotten. They can use it on their next assignment or in their own personal projects!


Real-world motivation

I have a neutral opinion on visual programming. I have dabbled in it and decided that I am not interested. But. It is simply a tool.

Tools are complicated to motivate. Just enter any room of programmers and give them the exercise to, once and for all, decide on whether vi or Emacs is better. You might as well ask them to choose the new Pope...

On the other hand, in my opinion, an intelligent person (which your pupils certainly are!) does not need to actually be fond of or deeply knowledgeable of a tool to appreciate its merits. In the same vein as being able to learn about war and famine (which are decidedly not fun), they should be able to learn about Visual Programming even if you do not find a "fun" exercise for it.

So, you can easily teach them that there is a place for almost every tool. Visual Programming has its place in certain niches (depending on viewpoint, obviously) where you just do not need the expressive power of a general programming language. For example, if you are into Business Process Management, you can achieve a lot with visual programming. If you are using one of the game engines which focus on higher level creation, the same is true. A program like Blender can go far with a very domain-specific visual "programming" for what it does (physics simulation and so on). CAD/CAM systems are largely "programmed" with very, very domain specific visual tools.

Pick a few nice examples, and maybe you find some open source / free visual programming environments where they just play around, as a bonus. Even if they never touch them again, they will at least know that such things exist, and they may appreciate that somebody out there (who, likely, would never "program" anything at all, if they couldn't do it visually) puts them to good use.


Try not to convince them. Show them what is real, what exists, and that in itself should be convincing enough.

This might sound like nitpicking, but in the business world, if people start to try to "convince" someone of something, then it's usually a red flag. I prefer if they show me that something so I can understand and appreciate (or deny) it myself.


Just because you are using abstraction does not mean it is no longer programming.

Anything above actually flipping the bits by hand is us just being lazy.

My only objection to using an obscure language just for fun is. Why learn it if I would not use it in real life later?

Essentially I’d say. As long as the problem to be solved is fun. I.e. Not how to implement a solution using a recurs7function, I’d say you are grand. Especially if there is text or graphics output involved.

Blinkenlights are fun.

  • $\begingroup$ That's a fair point. Though we also teach 6502 assembly at my workplace, and I learned ML, BASIC, and Pascal - they all served a pedagogic purpose at the time. If it helps to get at an important concept, then that can be reason enough. (And keeping student engagement high enough to actually learn and explore is part of communicating the concept) $\endgroup$ – Ben I. Jun 21 '17 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.