How do I convince my students that visual programming is real programming?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.

Answer 6

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)

Answer 7

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.

Answer 8

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).

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Relevancy

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

Flexibility

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

Pay-Off

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!

Answer 13

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.

"Convince"?

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.

Answer 14

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.