Closer To The Ideal

(In this post, I will let hecl stand in for all scripting languages that aim to make programming easy to do on cell phones.)

All through the 1980s and for most of the 1990s, Apple made efforts to make programming easy. In 1987, Apple released Hypercard, probably the single easiest programming environment ever. Apple’s dedication to empowering people – allowing minimally-technical people to program – earned it a great deal of goodwill, so much so that Bill Atkinson (the inventor of HyperCard) basically gave it to Apple as a free gift, in exchange for the promise that it would be included on all Macintosh computers. Sadly, in this decade, Apple has forgotten about Hypercard. My sense is that this represents a larger trend within Apple: a general retreat from the goal of giving minimally-technical people easy programming tools. The death of Hypercard lead to mourning among its many fans (myself included). Danny Goodman summed up the feelings of many:

I shed my buckets of tears for HyperCard (and what might have been) many, many years ago. The first crude demo that Bill showed me was, at its root, what the World Wide Web has become. Coulda, woulda, shoulda.

Despite valiant post-version 1.1 efforts by dedicated and exceptionally bright serfs (their recollection brings fond memories), HyperCard never truly recovered from its detour to the Claris dungeon and the dungeon masters. It’s a tale of perhaps the biggest opportunity Apple missed in its self-defense against a rising Windows tide.

When I look at the current product, I see facets that are still ahead of their time, not the least of which is the extraordinarily elegant HyperTalk language by Dan Winkler — a kid straight out of college, who Bill Atkinson said was the only programmer who could keep up with him. At the same time, aspects of the product have been embarrassingly behind the times for years. Kevin was well on his way to fixing that, but the scenery changed.

Back when Apple was still proud of HyperCard, and boastful of its use by minimally-technical people, this is the kind of article that I read over and over and over again:

I thought it was really cool to see – not because I’m interested in quilting, or the program is anything brilliant (it’s simple and functional), but because enabling stuff like this is part of what I built Hecl for: to make mobile phone applications easier, quicker, and simpler to create. Someone went and typed in the code on Heclbuilder, got the program running, and now a number of people have a handy tool to do some calculations for their hobby, which is a heck of a lot easier than fooling around with SDK’s, Eclipse or Netbeans, and so on and so forth.

But this is no longer Apple talking, rather, it is David Welton, talking about Hecl.

The other tool for programming by minimally-technical people that Apple has promoted has been AppleScript. Influenced by HyperTalk (HyperCard’s programming language), Applescript has a syntax that in many ways mimics English, and therefore it is easy for English speakers to learn.

The digital revolution continues to change our lives. The biggest change over the last few years has been the mass acceptance of cell phones. Most people that I know no longer have landlines, they only have cell phones. This is the next great frontier for computer programming. And yet, Apple hasn’t yet made Applescript available to run on the iPhone. Yet hecl can run on Android.

Personally, I would love to be able to write apps for the iPhone. But I don’t want to have to learn the Object C language. I don’t have the time. I agree with Simon Brocklehurst’s criticism of this decision:

Recently, Apple bowed to the inevitable, and has released an SDK for developer testing. The language they chose to base the SDK around is Objective-C. This wasn’t a complete surprise – after all, it’s the “native” language of Mac OS X. However, while it’s not a surprise, I wonder if it’s not a major strategic error on Apple’s part. The point is this: the Mac is a niche platform, and is especially niche in terms of numbers of developers building applications in Objective-C. Compare that to iPhone, which because of its technological lead, has the chance to become a major volume player in the mobile phone space. If Apple wants iPhone to succeed, it seems strange to attempt to force developers to use an unpopular language for programming it. That isn’t the way to win – developers have many, many choices of platforms they can spend time developing for.

Brocklehurst thinks Apple should pick a popular language for its SDK. I think Apple should pick one that is easy to learn. A light weight scripting language. If Apple came out with an implementation of Applescript that ran on the iPhone, then I would start writing iPhone apps tomorrow.

But for now, it doesn’t seem like Apple is planning on doing that. So when I look around for relatively easy ways to get into cell phone programing, other light-weight scripting languages jump out at me. And they lead me to platforms other than the iPhone.

So maybe hecl is the new Applescript/Hypercard? For people who want to put together a quilting site with a cell phone connection, what is the easiest way for them to do that? Who is, right now, showing commitment to the old ideal of empowering minimally-technical people to write the apps that they want?

There are several good posts over at David N. Welton’s blog, and I’m going to post short excerpts here.

Welton is one of the two people working on hecl:

Hecl is intended as a complement to the Java programming language, not a replacement. As such, it tries to do well what Java doesn’t, and leaves those tasks to Java for which it is best suited. Hecl aims to be a very immediate language – you can pick it up and start doing useful things with it quickly. It is also meant to be easy to learn. Where Java is verbose and rigid, Hecl is forgiving and quick to write. For instance, System.out.println("Hello World"); vs puts "Hello World" – 41 keystrokes (shifted letters count double) versus 22. Hecl is built to “scale down”.

This makes Hecl ideal for large applications written in Java that would like to provide a user friendly scripting interface, rather than, say, a clunky XML based configuration system. Examples include: scripted web pages, command/control logic in long running applications, and, I’m sure, many environments I’ve never considered.

hecl strikes me as arising from the same economic/technological forces that have in recent years lead to the explosion of script languages running on the JVM: JRuby, Groovy, JavaFX, etc. hecl doesn’t necessarily run on the JVM, but, as I say, its existence seems due to the same underlying trend – the reality that for many projects it is economically rational to trade away program execution speed in exchange for greater programmer productivity.

The mobile phone is a good environment for Java and yet hecl might work even better in this environment (in that sense, it might be a direct competitor of JavaFX). They’ve apparently gotten a prototype working:

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs!

Welton also writes the only article I’ve ever read that says something negative about git:

The whole thing seems kind of shaky in the sense that it’s not very confidence inspiring: I feel like it wouldn’t take much to make a wrong turn and find all my files gone forever. I can see some of the advantages, and will likely stick with it – git is quite convenient for local files that I might not have bothered putting under version control in the past, but it’s also a bit more “bureaucratic” in that you have more steps to do, and you have to fill in the forms just so… or else!

And this is the only negative thing I’ve ever read about github:

However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who ‘owns’ the project, rather than existing on their own. There are a few exceptions – there seems to be a ‘rails’ role account to manage Rails, rather than having it belong to, say, DHH, so it’s not impossible to do something in a project-centric fashion, but it doesn’t seem to be very common either.

What I’m wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to ‘fork’ projects. Could, or will this lead to a situation where people don’t try so hard to get their code in the ‘official’ branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they’re not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the ‘dead’ branch, or simply be confused as to who’s doing what. This could make things confusing for someone who just wants to check out some code and start using it…. trying to sort out various revisions and ancestry of a project could be quite discouraging.

Finally, Welton thinks of Coase and his Theory of the Firm when considering how smaller transaction costs in certain industries might be leading to more freelance gigs and less permanent jobs:

So if one wanted to look, in a less anecdotal way and slightly more scientific way, about whether the US, or other countries, are turning into “gig economies”, one could do worse than look at the transaction costs associated with utilizing contractors as opposed to permanent employees. If those costs have fallen (it may be easier to find people, thanks to the internet, for example), perhaps it is more efficient to have more contractors and fewer full time employees and so the equilibrium will tilt in that direction. Of course, another explanation might simply be that the economy is bad, and companies don’t have the budget to take on more people, so they get by with what they can in the short term.

For me, this is one of the main ideas I took away from the work of H. T Goranson. During the 1980s Japanese manufacturing firms used their focus on quality to beat American manufacturing firms. By the early 90s American companies were trying to catch up with the Japanese innovations in quality. Many American economists and business analysts worried that the next great zone of innovation would be agility. Organizations such as DARPA were sufficiently worried that they gave out a lot of grants to people like Goranson. His work concluded that, at least in the American context, small firms were uniquely innovative, but their innovations would be at least partially wasted if they could not be brought into the supply chains of the largest manufacturing firms. In this context, agility was defined as the ability to overcome the transaction costs associated with dealings outside of a firm. A truly agile supply chain would be one where numerous small suppliers could be quickly brought together into a completely new supply chain, with little additional cost (that is, the annoyance of dealing with lots of small firms would somehow be minimized). The model was Hollywood, which, in just a few weeks, is able to pull together a vast and diverse group of professionals to create a new movie. Goranson looked at everything from legal traditions to social mores to technological innovations that contribute to agility.

Needless to say, that kind of agility has become an increasingly important part of the economy, and possibly has become a unique competitive advantage of America.