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!

Obama says, “Don’t just play with your phone, program it!”


As part of code.org‘s terrific “Hour of Code” week, Barrack Obama has called out youngsters to learn how to code. There are some great learning tools at code.org, including Blockly, Scratch, and App Inventor. The initial “Angry Birds” code challenges involving programming character’s movement through a maze is a great beginning to programming. My twelve-year-old son Tomas had a blast and learned a lot of programming (if, loops, complex logic, etc.).

App Inventor Answers the President’s Call

Learning to program a maze is great, but App Inventor stands out as a tool that actually lets you program your phone and build all kinds of apps. You can build apps that auto-respond to text messages or an app that with a single click sends “thinking of you” to a list of phone numbers; You can build apps that remember where you parked your car, or how far you’ve run. And you can build meaningful, media-rich apps such as an “I Have a Dream” app that plays the speeches of MLK and Malcolm X. Most importantly, you can share your apps with your family and friends because App Inventor works on the open Android platform.

The “I Have a Dream” screencast tutorial is below. If you have an Android, click on the link and follow along, and you can have a cool app downloaded within minutes. And you’ll learn enough programming to build your own apps of various types– the sky is the limit!

For more, see appinventor.org and  MIT’s Hour of Code lesson.

App Inventor 2 is Here!

Screen Shot 2013-12-05 at 9.39.58 AM

App Inventor 2 is the new version of App Inventor now available at http://ai2.appinventor.mit.edu. It is fabulous– a real game changer in terms of app building and computer science education for beginners. Congratulations to the MIT team for this great achievement!

The tool is much easier to setup and usually requires no downloads on your computer. If you want to build apps and learn some programming, and you have an Android phone, you can literally get going within minutes.

Besides the better setup, the new system provides a much more elegant programming experience. The blocks editor loads immediately — its now in the browser, not a Java app!. And there are a number of new features that simplify the app building process. Once you use it you will NEVER go back. However, AI “Classic” (beta.appinventor.mit.edu), and the projects you’ve already built, will still be available for some months. For a description of the key changes in AI 2, see http://www.appinventor.org/appInventor2Changes.

appInventorBook

Teachers– you should teach with AI2 this Spring. For my take on why, see http://appinventor.org/appInventor2. In terms of supporting materials, the App Inventor book has been partially translated into AI2. You can find some chapters in web form at http://appinventor.org/book2. Most of the book will be translated in web form by early January. I am also working on a new book which will be available in plenty of time for next Fall.

There are also a number of AI2 video tutorials available at appinventor.org, and Shay Pokress and the MIT team have also created a number of nice tutorials available on the MIT site.

 

Dave

App Inventor students, professors, and Googlers discuss their experience

Angelo Taylor is a University of San Francisco student who took my App Inventor course last year. He has created this video about our App Inventor course. Great work Angelo!

O’Reilly Webcast on App Inventor and Its Future

My O’Reilly Webcast on App Inventor and its future is now archived (it was given Sep. 2, 2011). I talk about some success stories with App Inventor, what’s going to happen as it transitions to MIT, and how the language might be developed further. I even tell a really bad App Inventor joke. Check it out.

O'Reilly Announcement

App Inventor is not only about education

App Inventor team’s initial impetus was education. But when it was released on July 12, 2010,  thousands of people showed up to the party. some were experienced programmers who love how easy it is to develop apps and prototype, some were web designers who suddenly could create something other than static web pages. Still others were creators/entrepreneurs who had found a way to prototype and create marketable apps, to take part directly in the development process.

Nobody really knows what to make of them because they are a new social group, a new phenomenon made possible by App Inventor’s low barrier to entry. Hard core programmers scoff at them and say they’ll ruin the Android market with trashy apps– they don’t want them at the party. The business world doesn’t even realize they exist. Its like we needed a Malcolm Gladwell to come in and make sense of a new social entity.

Anyway, this group has been ignored somewhat in the discussion concerning App Inventor’s closure, with most of the focus on educators like myself. Many of them have worked incredibly hard, taught themselves programming and app design, started businesses, and contributed greatly to the advancement of the language and Android in general.

Like teachers, this new technological group will have the carpet pulled  from under them if the transition to open source doesn’t go smoothly. Its a shame because our society needs more creative people with the skill to create not just blog posts and web pages, but interactive media, i.e., apps.

I guess this is, in a nutshell, why Google is closing its labs and focusing on fewer projects– they just aren’t able to fully support and promote the very cool projects they had. Perhaps in the transition to open source, with more organizations having a chance to contribute directly, this new group of software developers can be nurtured as they should be.

App Inventor Discontinued: The Good, the Bad and the Ugly

Google quietly announced the discontinuation of App Inventor, effective end of the year. They plan to transition the product to a non-profit organization, the goal being that, for App Inventor users, only the URL will change come December 31st of this year. They will also open source the project.

There’s some good in this announcement, but it’s mostly bad and ugly.

Will I still be able to access the apps I’ve built and create new ones?

This question is especially important given that your work lives on the corporate servers. If Google shut App Inventor down today (they won’t), you would have no way of accessing the existing apps you’ve created.

Google has promised to keep the current version of App Inventor running until Dec. 31, 2011. The plan is to turn the system over, at that time, to a non-profit organization. If things go smoothly, you’ll be able to access your apps and App Inventor on Jan. 1, 2012 just as you do now, just at a different URL. Update 8/12/11: Karen Parker, the App Inventor Program Manager, notes that legally, Google can’t transfer user data– your apps– to another site. So there may be some download/upload on the part of developers to get their apps to the new system. The key, of course, is that the new system can upload apps created by the old system.

The “if things go smoothly” is the kicker, of course. There will be uncertainty unless Google pledges that a smooth transition will occur, which I believe they should do.

Until then, it’s a matter of trust. I’m optimistic, based primarily on my experiences with Hal Abelson, Mark Friedman, Karen Parker and the rest of App Inventor team. They put their heart and soul into the project, they want to see it succeed in the new form, and they feel responsible to the community they’ve created. I trust them to get the job done.

App Inventor is being open sourced. Isn’t this good news?

There are two separate things going on here. Google is discontinuing App Inventor, which is bad. They are also open sourcing it, which is good, even if it does come packaged as damage control.

First the bad. As of January 1st , App Inventor will no longer be administered by Google. The 5+ wonderful engineers on the team will no longer be fixing bugs and adding great new features. Perhaps a non-profit with equally great engineers will take over and provide a seamless transition, but this is uncertain. All we know at this point is that the greatest tech company in the world won’t be running it.

It is a good thing that App Inventor is being open sourced. An open source App Inventor means that developers and researchers can make use of the App Inventor code base to build new tools. We could see an App Inventor for building iPhone and iPad apps, for building cross-platform apps. In the long run, it could spur innovation in visual programming.

But make no mistake: these are potential benefits for the future, and really are not helpful to App Inventor developers and educators in the near term. The truth is that a closed source App Inventor, supported fully by Google, is far and away better for App Inventor enthusiasts. This announcement is a blow to the many kids, students, educators, and newly empowered software developers who love App Inventor, and will at the least  slow the momentum of the project.

I’m a teacher planning to teach App Inventor in fall 2011 and in the future. Should  I abandon this idea?

Teachers hate uncertainty and don’t have unlimited hours to prepare a course and learn new tools. But my advice is to stick with App Inventor. I believe its a revolutionary tool for teaching beginners and non-computer-geeks programming. It combines a visual blocks language proven successful with Scratch with the motivating force of mobile computing. Young people are fascinated by the little computers they now carry around with them and they are blown away when they realize they can actually create software for them, actually control them.

There is risk here and there will no doubt be issues. But as I mentioned above, I trust that the App Inventor team will come through. For me, the rewards—a bunch of highly motivated students in my class—are worth the risk.

Did Google behave poorly by cutting App Inventor?

Yes.

Can you expand on that?

I’m a mild mannered professor. I don’t know beans about corporate politics and even less about the best way to make money. But I’d say the following is probably good policy:

Don’t start initiatives to inspire, empower, and educate, then indiscriminately pull the plug.

I understand the Google Labs closure: focus more on fewer projects. And Google has every right to cut Google labs projects– users of such tools should be aware of the risk.

But in the case of App Inventor, the decision effects more than just your typical early adopter techie. It hurts kids and schools, and outfits like Iridescent, who use App Inventor in their Technovation after-school programs for high school girls, and Youth Radio’s Mobile Action Lab, which teaches app building to kids in Oakland California. You’ve hurt professors and K-12  educators who have developed new courses and curricula with App Inventor at the core. You’ve hurt universities who have redesigned their programs.

I don’t want to over-dramatize this: these groups will be fine, especially if Google makes good on transitioning App Inventor. My melancholy is more about what could have been had Google truly supported and actually promoted the tool, and about the loss of momentum for this wonderful project. We really need more programmers and inventors, and App Inventor can have a profound effect. If President Obama knew about App Inventor’s potential to inspire a whole new generation of engineers, he’d be really pissed at Google for this move.

Even looking at it from Google’s perspective, I find the decision puzzling. App Inventor was a public relations dream. Democratizing app building, empowering kids, women, and underrepresented groups– this is good press for a company continually in the news for anti-trust and other far less appealing issues. And the cost-benefit of the cut was negligible—believe it or not, App Inventor was a small team of just 5+ employees! The Math doesn’t make sense.

Let’s end with Clint Eastwood

As a teacher, I like to end things on a positive note, on the Good. The App Inventor project has shown that ordinary people, not just computer geeks, can program the mobile computers we all now walk around with us. It provided a glimpse of a world in which people don’t just use phones and tablets but take control of them, customize them for their personal use.

It fired up a bunch of kids, college students, and tinkering adults, empowering them technologically beyond their dreams (click on the pics below for  just a few of the success stories). It drew the interest of young women and demonstrated a way to lure more of them into computing. Larry Page may not get it, but his tiny group of 5+ engineers created something revolutionary. In the long run, the ideas and design behind the App Inventor project will live on and fulfill their great promise, Google or not.

In closing, I encourage Google to do the right thing, to support those 5+ engineers in the transition, vigorously fund the non-profit entity that takes over, and most importantly, make a firm pledge to the App Inventor community that the transition will occur seamlessly. If they do, the ugly will turn to beautiful, the bad to good, and App Inventor will outlive the Spaghetti Western.

Just a couple of the many App Inventor success stories….

HS Girls in NYC build apps for the Technovation challenge

USF Student-Teachers at the Technovation Challenge

USF students learned App Inventor, then taught high school girls

A new app developer at BAYCAT SF.

Follow

Get every new post delivered to your Inbox.

Join 62 other followers