App Inventor: Programming for non-programmers... again

From the App Inventor about page:

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app's behavior.

It seems we've been here before. (and I don't just mean that it's based on Open Blocks and Kawa)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"NO programming knowledge"

Because we'll teach you on the job...

It's hardly a bad approach. And event-driven programming (when button clicked, do something) seems an approach people are readily familiar with (aka find 'intuitive').

An awful argument

We shortly dove into programming in another thread. On my college, I actually had a hard time against former EE colleagues explaining that, no, this cannot be a substitute for training programming in an embedded engineering curriculum. They're hardly doing anyone a favor with that line.

Environments that can Teach

There isn't any fundamental reason we can't automate the progressive education of programming knowledge as part of an IDE. Maybe Rosetta could help.

Most applications are effectively mashups of other applications. That is why scripting languages are useful. That is why these 'app inventor' techniques can succeed.

If you aren't teaching computer science, but rather the programming craft, these sorts of tools - along with sufficient illustrations and help fora and personal motivation - may substitute for disciplined training. [edit: but remember don't ask how they did it]

Taming complexity with higher level languages

Yes, using an IDE to teach a language is actually a good way to go.

And it is not just for non-developers. One of the problems with large IT organizations is precisely that when developers leave there is a lot of lost knowledge. At OutSystems we have created the Agile Platform with the goal of making complex systems become easier to manage. One of the results is that the simplicity in the language (if you have the correct extensibility hooks in place) will actually bring you more power. You'll loose less time dealing with understanding legacy and standard code and have more time to invest in smarter algorithms and innovation.

The argument wasn't on this particular application

But more in general, that, say Simulink or Labview, would be enough for someone trained in embedded systems, whereas I think they'ld better be served with assembly and C.

Teaching with an IDE

There isn't any fundamental reason we can't automate the progressive education of programming knowledge as part of an IDE.

Indeed, this has been tried before - BlueJ is one example.

More recently, Microsoft funded Bertrand Meyer to do an Eiffel-based take on this, which is very, very different from BlueJ. Meyer teaches kids using a metro simulation environment written in 140,000 lines of Eiffel, but students only interact with a small portion of the system at any given time, and can peal back the system as they want to add new features, augmenting how the system works.


This looks a lot like Apple's Automator, but I'm not very familiar with Open Blocks/Kawa. But what really comes to my mind right now is Kodu, which advances the event-driven programming paradigm into an autonomic paradigm based on sensors, actuators, and prioritized reflexes. Not sure how that could be leveraged in non-game programming tasks though.

Other related work

Other tile-based systems include Etoys, Scratch, BYOB (a powerful Scratch extension), Elements (based on full Smalltalk), TileScript (based on JavaScript), Turtle Art (based on Logo), and to some degree class-browser systems like Smalltalk's Morphic environment and the Lively kernel.

I've also been working on a similar JavaScript-based system which I'm calling "TurtleScript". The most interesting thing about that currently is its README.

It is syntax

When dealing with textual code as a programmer, you have to worry about the correct syntax. Scratch, AppInventor, etc. nearly eliminate the burden of a syntax by replacing it with a visual (and almost tactile) interface to which we can bring our physical intuitions.

Scratch has some interesting semantics such as message broadcast/receive which traditional programming languages don't quite support or encourage. Any unconventional ideas like that in AppInventor? I couldn't spot, but maybe I missed something.

We cannot resolve the

We cannot resolve the fundamental contradiction of programming: programming is so easy that it opens the gates for casual programmers ( mostly domain specialists, who are otherwise very knowledgeable, highly reputed and intelligent ) who produce crap, which has to be later maintained by more skilled programmers whose life becomes miserable. In order to avoid this the entry barrier has to be raised instead of lowered. But the safest recipe for raising the entry barrier is to produce hard to penetrate crap.

Foundation first

Many things are this way - it is easy to throw something together that looks like a house, or a toy, etc., or to start raising a child - but producing a quality result takes a lot of work.

The previous owner of our house did lots of work we need to undo..

But a good foundation can go a looong way, and without it the best built house will need a huge amount of work, or simply fail.


We've always had this, accountants with spreadsheets, scientists with FORTRAN, everyone with Visual Basic, and so forth. It is a scary thought that so much of the world's financial structure depends on the programming output of non-programmers. It is nasty work, having to reverse-engineer Excel.

No reason why tools like App Inventor could not be a stepping stone to 'real' programming. However, they should then be extensible, so that for instance a knowledgeable person can optionally code some parts of the logic rather than having to do everything with Lego-like blocks.


Lay off AppInventor. Stop arguing distinctions that don't make a difference.

Yes, technicians are valuable, but you still have to tell them what to do. If you let a technician go and do whatever he wants, he will gravitate to whatever technical things interest him, and have no regards to what the business actually needs to get done. Technicians are the ones who think they can solve a "silo problem" in an information system by building another silo - because this one is cooler! Technicians are the folks that can build impressive Cubes in very little time that tell you which doctors have the most infections, but they don't have any conceptualization of how to tie that to a business process so the problem can actually get corrected. What ultimately happens is non-technical people print out the report, then never do anything with it. It sits on their desk. And because it is outside of the Orwellian Fantasy of Corporate America where everything a worker does is tracked so we can do "process re-engineering", they are not accountable for it. Those sticky note on their monitor has been there six months, they've just re-arranged where on the monitor each one is. Those non-technical people have a billion other "multi-tasking" responsibilities they are accountable for, and at any given moment they are going to gravitate to the one where if it is not done, they are going to get fired. That's the real world, where you are a 40 year old paper pusher in some office, and you have a wife and two kids and work a 9-5, trying to figure out how to put your kids through college, hopefully so they can have a better job than you and escape the rat race. And when their manager is breathing down their neck with a bunch of "I need it now" demands, all the stuff that has no paper trail -- like what follow-ups were done on that Cube report from 3 months ago -- DOESN'T EVEN EXIST. Bottom line: Their brain is so completely baked with fear of not getting key tasks done that stuff without a paper trail never gets done, even if if takes 5 minutes. Even if a technical person like me has it set in their Outlook calendar to bug them every Tuesday at 10am for six weeks, and they still don't do it, they won't do it. Why? Because they're so completely frazzled they stop thinking rationally. And these are polite people.

Yes, problem domain experts are valuable, but frequently they lack formal training in programming languages (and even when you have formal training in programming, you can still be awful at it, as I've witnessed many times in my life). They need better tools. Stuff like AppInventor is trying to open up the possibilities towards better tools. AppInventor itself I don't think is any hero-saving device. But the methodology is interesting: using Kawa and OpenBlocks, and so on. At least these visual language designers have stopped rolling their own everything, and seeing how to modularize the problem.

More often than not, you need somebody who is an "architect" who can bring sanity to the way non-technical people and the technicians behave and think. You need somebody who is simply great at design. How you write the code really doesn't matter that much. I've learned in the real world I spend way more time trying to accomodate ridiculously bad third party software than any other task. And this seems to be true across all software. Rob Pike once said most of the effort in Plan9/Inferno was implementing legacy protocol support.

Yes, Excel is a lousy tool and reverse-engineering it is a pain. But that problem actually has nothing to do with the spreadsheet interaction metaphor. If you think it does, then you don't have a fine enough eye for detail. Recently, Lex Spoon wrote a blog about SEC Interested in Smart Contracts? where he concluded by asking about how good is spreadsheet software, anyway?, and I pointed out to him just some of the severe bugs -- from a programming language theory perspective -- with Excel. And, no, if you are an "expert" in programming language theory, you cannot be guaranteed to invent something better than Excel. People try, all the time. Usually they end up with something no better than Lotus Improv, which means how they report errors to the user is still as bad as Excel. And academics in language design don't appear to understand the issue well, either, since I've seen some rather dismissive "this will help spreadsheet programming" idea papers, and they all come across like they author has never used a spreadsheet or even sat down and read the literature.

Bottom line: Visual programming languages are difficult, but dismissive discussion takes the state-of-the-art nowhere. Where do you think you could actually benefit from a tool like AppInventor? If you can't think of anywhere in your code base, then why not? What problems do you face that can't be solved better visually, and why?

Reads like Oscar Wilde

"Working is the problem of the drinking class."

actually benefit from a tool like AppInventor

... And, no, if you are an "expert" in programming language theory, you cannot be guaranteed to invent something better than Excel.

This is not a constructive comment. Obviously, we shouldn't expect a special correlation between PLT expertise and knowledge of usability or human-computer interaction. But you should clarify what makes Excel an usability win compared to Improv or other ideas: telling us to just "sit down and read the literature" is unhelpful.

... Bottom line: Visual programming languages are difficult, but dismissive discussion takes the state-of-the-art nowhere. Where do you think you could actually benefit from a tool like AppInventor?

My impression is that domain experts would benefit most from applying the snap-the-blocks interface to custom, domain-specific languages. Adding an OpenBlocks-like plugin to Xtext might be especially useful: novices could use the snap-the-blocks mode to learn the abstract syntax, and the IDE integration would enable an easy transition to textual editing.

a small recent visual builder

quark which is based on cal (haskell on the jvm).