Android Priests
So Jeff Jarvis has made a bet with Dave Winer that in a year’s time Google’s new App Inventor will have “not have had any effect on the priesthood of programming.” I’d be interested in the metric used to determine the winner, but that’s not really the question. Winer is incredulous at the idea that AppInventor will disintermediate coding, despite having in the past been an ardent cheerleader for the Internet end run around any other number of middlemen, most notably journalists. To Jarvis’ credit, he’s the only person I’ve heard in this discussion refer to programmers as a “priesthood,” though he tones down his usual slightly breathless revolutionary rhetoric:
As much as the web breaks down priesthoods, it created new ones. Developers are merely the latest. They say that mortals can’t do what they do. But what if they could? What if they could translate a thought not just into words and design but into action?
I think Winer is going to win, however, and the reason is that AppInventor is a solution without a problem. The “priesthood of programming” has already given its blessing to Android. The geek blogosphere talks about how it is only a matter of time before developers stop building apps for Apple’s evil, closed ecosystem, and the iPodiPhoneiPadiPhone 4 dies. It’s why developers are reacting with hostility to AppInventor. Developers are already developing for Android. They neither need nor want a Visual Basic like tool. The intended audience for AppInventor- the end users – don’t need or want it either. Google, having failed to attract non-developers to the platform with the ease of use and attention to user experience that somehow only Apple is able to deliver, are now trying to disguise a stick as a carrot. It won’t work. End users don’t want to be able to build Android apps. They want to be able to build iOS apps.
On what do you base this assertion? I'm an Android user (though more developer-oriented than most), and I'd really like to able to have a quick way to interact with a web service or two. Not sure if AppInventor will scratch that itch, but it's not to say it's not there.
This is definitely not the first time someone has tried to create a way for non-programmers to program. From Hypercard on one end to the various “Visual programming languages” on the other.
Some of these have been somewhat succesful, although usually either by ending up tricking the developer into becoming a programmer after all (Hypercard), or by limiting themselves to a very specific domain (Lego Robolab; perhaps Yahoo Pipes fits in that category too?).
It's an interesting thing to try to do, create a software construction environment for non-programmers, glad to see efforts in that direction. But whether it ends up finding a userbase or not, I'd bet the farm that it will NOT change “Programming as We Know It,” anymore than the others did. (Although some people might argue that Hypercard _did_, heh.)
I'm saying that just the fact that you even know that there's a web service or two that you want to interact with means that you're not the kind of end user this is supposedly meant for. The kind of thing you're describing would make sense if this was meant as scripting for Android.
I don't think it will either. I'm glad to see eforts in that direction as well, and I sometimes wonder why they all do eventually fail. Why is it we can't get really high-level abstraction layers onto coding that would enable non-developers to make apps? Is it that programmers can see the inevitability of disintermediation in every profession but their own? Isn't the “No, I will not fix your computer” t-shirt really a rather smug comment about job security?
“End users don’t want to be able to build Android apps. They want to be able to build iOS apps.”
And I would have thought that if end users wanted to build apps, they'd want to build them for the phone they have rather than for a particular OS.
I guess that now that people don't have to constantly tinker with their cars to make them work (thereby rendering pointless the incessant and useless automotive debates over whether Chevy, Mopar, or Ford is best), the consumer now is captivated by the fascinating world of handset OSes.
No, exactly the opposite. It's the programmer who's endlessly fascinated by handset OSes. My point being that the people for whom AppInventor is a great thing already have Android handsets, and are already programmers, so AppInventor is irrelevant.
I seriously doubt that it's because of programmers not trying hard enough, as you suggest, to protect their jobs. It's because it's a legitimately Hard Problem. After all, it's programmers who write those attempts at high-level abstraction layers, and those programmers generally do so because they think it's a really Neat Idea that they want to see succeed (and of course, those programmers writing such things aren't going to be out of a job if those things catch on, they'll still need to be written and maintained).
It's because it's just plain hard. Simplicity and Flexibility often competing pulls. To make something that is both very very simple, and so flexible as to be used to create solutions to real unpredictable problems… it's legitimately hard.
But the driving principle of programming language evolution is increased simplicity with flexibility. PHP is a lot more accessible than, say, writing assembly language on punchcards as a programmer in the 1960s did. Programmers too want to make things simpler while still flexible, because that's a lot more powerful a tool and allows the programmer to do a lot more in the same amount of time.
I predict that even with the most accessible tool though, doing complicated things will take the kind of analytical logical thinking that good programmers (not all programmers are good programmers) specialize in, and that not everyone has 'naturally'. Good programmers don't worry about being put out of a job due to easier to use tools, because they know easier to use tools might make current 'complicated' problems easier, but will put current 'infeasible' problems into the 'complicated' category and people will still want to tackle those. (Imagine trying to write Windows 2000 in assembley language on punchcards! Impossible.)