Event-based Languages (and phones) are the key to learning

When the user clicks the button,…

Computers were first designed to compute, to allow men with oversized glasses to write “recipes”, to take a large set of numbers and compute some formulaic result. Computers still crank through formulas, of course, but their purpose has expanded far beyond computing things. It is doubtful that Alan Turing and his generation envisioned Facebook, Google glass, or even people carrying around their computers tweeting camera-shots and using GPS to find where they’re going.

Though the reason we use computers has changed dramatically, our coding languages have not. Popular languages like Python and Java are still based on the “recipe” model with a “main” program of sequential instructions. This recipe model makes sense for computing things, but is a poor fit for modern software, which is much more like an event-response machine, reacting to the user touching a button, location information coming in from a GPS satellite, or a text arriving from a friend.

For experienced programmers, the dissonance between the language they use and the software they’re trying to build isn’t that big a deal. But for beginners it makes learning to code really difficult. Want to program an app in which clicking a button causes the button to turn red? Should be simple right? It’s not. In Java, for instance, you first create an object called a Listener, then register that listener with the user interface object (the button), then program the handler to…you get the picture! Its not a first hour or even first day exercise, and you have to understand many things before you can do it. This difficulty is the reason why most people’s initial engagement with coding is to display “hello world” on the screen or at most to add up a list of numbers. Couple these less than motivating initial results  with the fact the computer is barking error messages at them, and it is no wonder most don’t stick with the field very long.

The problem is that events, like the user clicking a button or dragging the mouse, are not first-class objects in our popular programming languages. The events must be constructed by the programmer, and its not easy to do.

Event-handling languages like App Inventor are different– “when event do” is a first-class construct in the language. Here’s how you program the”click a button to turn it red” example in App Inventor:

Such a program takes about 30 seconds to learn. You just look in a drawer of button events and function blocks, drag them into your app, and plug them together. Here’s another sample:

Can you tell what it does? It’s basically an answering machine for texts. You turn the app on when you get in your car, or enter a meeting, and it auto-responds to any incoming texts. Pretty powerful, but easy to specify, almost as easy as telling Siri, “when someone texts me send an auto response”.

Now this texting code is a bit more complicated than the Button.Click sample. You have to understand that “number” is the phone number of the person who sent the text and know how to refer to it to set the “PhoneNumber” of the out-going message. But it is still a first day or even first hour exercise.

Here’s one last example, for you game lovers out there. Let’s say you want to animate a flying saucer and have it move horizontally across the screen? Coding animation is really hard, right? Well, here’s the App Inventor code:

Screen Shot 2013-12-11 at 6.58.24 AM

The code is, again, a little more complex than a Button.Click. You need to understand that the Clock.Timer is like an alarm clock, and that there is another value somewhere specifying how often the timer should go off.  And you need to understand that the “X” coordinate of the flying saucer is its horizontal location, and that you can change it by setting it to “itself”+ 5.

The beauty of an event-handling language like App Inventor is that the events– the things that your app can respond to, are pre-defined. They’re organized into little drawer. You just click on a drawer, find what you’re looking for, and drag it into your app. Then you drag response (function call) blocks in to specify what should happen when the event occurs. The fundamental software behavior– event-response– is the fundamental construct in the language.

Now you’re probably asking, “why aren’t all language like this?” Well, they should be. Part of the problem is just the incredible inertia that exists in software engineering. People teach what they know, and programming language design became passee sometime in the 1990s. But it is also about control. Programming languages are designed for maximum flexibility– so you can build anything and make as general-purpose a program as possible. To enable reuse of code, abstraction is worshiped; concrete simplicity is disdained.

App Inventor was designed by a group of really smart Googlers whose target audience was  beginners, so they favored concreteness over abstraction. The language provides you with a fixed set of concrete event and response blocks. You can program just about anything that can occur on a phone or tablet, but not everything. And you cannot define a new component, you are at the mercy of the engineers who develop App Inventor. Such inflexibility drives programmers crazy, they want total control of the machine, and are wary of “toy” systems that don’t give them that. Unfortunately, the cost of this total flexibility– of having an abstract Listener object that you can program– is that learning to code is a horror story!

If you are new to coding and want to give it a try, go to ai2.appinventor.mit.edu. You can also try the App Inventor Hour of Code intro lessons or the I Have a Dream video tutorial at appinventor.org. You can be programming your Android phone in 10 minutes!


7 Responses

  1. Hey There. I discovered your weblog using msn. This is an extremely well written article.
    I’ll make sure to bookmark it and return to read extra of your helpful information.
    Thank you for the post. I’ll certainly comeback.

  2. Another variation for your flying saucer example that is a bit simpler is this: Since an ImageSprite has a default Heading of 0, Interval of 100, and Speed of 0, then placing the flying saucer on the canvas and having a button Click event set the Speed to 5, will move the saucer to the right 🙂

    • Thanks, Scott, for mentioning this other and often simpler way of doing animation. I used the when clock.timer method in the article as it fits into the basic event-handling model better.

  3. A colleague sent me a link to this post. After reading, I sent her my reactions. Other colleagues have suggested I share my reactions more widely. So here goes:

    Many thanks for sending me the link.

    In general I am very supportive of the sentiments and general points being made; but I have serious qualms about the details and the tone of the presentation. One that I’m sure you noticed is the first sentence.
    “Computers were first designed to compute, to allow men with oversized glasses to write “recipes”, to take a large set of numbers and compute some formulaic result. ”
    Apart from its rudeness and the obvious gaffe of ignoring more than half the human race, it’s just plain factually wrong.

    I know it’s hard to always acknowledge the work of the giants upon whose shoulders we stand, but this article misleads and misattributes. The tone conveyed by claims like
    “App Inventor was designed by a group of really smart Googlers”
    implicitly and inaccurately suggests that — until this group of Googlers came along — nobody in the computing community cared that many of our language tools, especially those typically espoused by the industry, were obfuscatory and off-putting to beginners. That suggestion is a disservice to history and to a host of caring and thoughtful pioneers, among whom — and far from the least — I include Hal Abelson.

    But my biggest complaint is the derogation of abstraction. The sentence
    “To enable reuse of code, abstraction is worshiped; concrete simplicity is disdained.”
    is foolish. Simplicity, especially effective and useful simplicity, comes about as a result of abstraction. What is the event and response block of App Inventor other than an abstraction of the event listener model of Java 1.1, which itself is an abstraction of…

    App Inventor is cool and appealing, not only to beginners, but to seasoned veterans such as myself. Eventful programming is a much more accurate model of the world current students will need to work in than is the public static void main(String[] args) mindset of some Java afficionados or the horrendous int main(int args, char *argv[]) of C. I agree we need languages for algorithmic understanding and tools for implementation that match current thought and technology, while generating enthusiasm and enabling creative expression. Where this article goes wrong is in thinking it needs to use derogation of current and past innovators and innovations in order to sell a cool concept like App Inventor. App Inventor can stand on its merits and appeal to millions. But to properly educate the next generation so that we will continue to be the innovative discipline that we are, and so that we can invent the successor to App Inventor, we need a whole lot more than App Inventor. David Wolber would be well advised to extol the virtues of App Inventor while placing it in the wider concept of enhancing understanding and creativity.

    • Rhys, thanks for your thoughtful comments. I was definitely trying to be provocative and get people to think about the languages
      we generally use to teach beginners. By no means did I mean to disrespect the pioneers of computer science, or to imply that there weren’t women pioneers, but on re-reading I can see how you might read it that way.

      And you may be right that “To enable reuse of code, abstraction is worshiped; concrete simplicity is disdained” is a foolish statement, especially standing alone. It was meant in the context of the languages we ask beginners to learn, as another way of saying, “why don’t our languages let us just say ‘when a button is clicked…'” I’m sure there are a million ways to say it better.

  4. What’s Going down i’m new to this, I stumbled upon this I have discovered It absolutely helpful and it has aided me
    out loads. I am hoping to contribute & aid other users like its helped me.
    Great job.

  5. Grateful for sharing tthis

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: