Lambda the Ultimate

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

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

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

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?