Tap-Dancing on the Shoulders of Giants, Cont'd

(after Bernard of Chartres)

Some days you wake up feeling old. Some things that happen during the day make you feel much, much older.

In times technologically ancient but historically recent, people wrote computer programs by writing code for virtually every instruction to be executed by that program. Later, as capabilities grew (and we learned better), we used underlying systems and libraries to reduce the amount of new code we had to write for increasingly complex programs. Later still, networks and the Internet augmented the resources we could use in our creations. As anyone who's written desktop applications for a recent major operating system can attest, the complexity of these applications can meet and often exceed what one person can keep in his or her head. Consequently, a high priority became "doing more with less", while still delivering an efficient, usable, correct-enough system.

Recent development, especially Web development, has taken that priority and raised it to an imperative. To be a good developer, you don't just have to be able to code well, you must be able to efficiently find, evaluate, learn, use, and collaborate on further development of these components. Write code once, that's fine. Write code twice, write it again in a more easily reusable form, and rewrite the first two to use the new one. What used to take a team months and thousands of lines of code can now be accomplished by a single developer in days or weeks, with dozens to scores of lines of more readily understandable code — that uses ever-more-complete and -complex underlying libraries.

I was reminded of this yet again by a recent blog post by David Guttman (with accompanying Heroku demo and source code). There's a moderate amount of framework-type boilerplate around it, but the source file I linked does all the heavy lifting.

It's less than fifty source lines of CoffeeScript. Fifty. Lines.

Not since the heyday of APL has a fifty-line program done so much. However, fifty lines of CoffeeScript is far more readily understandable by mere mortals than fifty characters of APL. (Browse this to get an idea of what I'm talking about.)

When I was a wee lad in uni, I wrote code, in ALGOL 68 on a Burroughs B6700, to drive a Tektronix graphics display to produce graphics similar to Guttman's. My program, when complete, nearly filled two 1600-character-per-inch 9-track tapes. (Yes, those erratically whirring reels you see in old newsreels and oddball posts on YouTube.) Each tape stored about 40 megabytes. (Less space than the music file I'm listening to at the moment; about 1/8 of a CD altogether.)

That project took the better part of two school quarters, about four months.

You can still spend months researching if you have to learn some Brave (totally) New Domain and a Strange New Language at the same time, but to actually write a fifty-line program? Days? Hours?

And that brings me to the point of the title; too many of us, not just younger developers, now take these new tools for granted. The problem in doing so, in not understanding how things were done before, blinds us to important details about the now-modern tools we use today. By not having a clear understanding of the problems solved by our tools, by not understanding the tradeoffs and alternatives involved in developing the tools we use every day, it's practically impossible for us to make the most effective use of those tools. And that can have some serious, project-endangering consequences, obvious in hindsight to those who have hit them at least once or twice..

We all stand on the shoulders of giants. Don't get too cocky with your tap-dancing, lest you follow in the shuddering footfalls of one Wile E. Coyote.

Damn You, WHICH Auto-Correct?

If you've had a smartphone for any length of time, you're no doubt intimately familiar with the concept behind the site Damn You, Auto Correct! even if you've not yet visited it. (But you should.) :-)

Perhaps more subtle than the humorous mismatches between intent and attempted repair is the philosophy behind various implementations of auto-correct. I've recently been using a Samsung Galaxy Note exclusively after having had various iPhones for several years, and for all the similarities between the two, one thing is glaringly different: the way auto-correct works.

At first I was just drying out from the familiarity Flavr-Aid, thinking that the iOS spell-checker was simply better. And then I started to notice that the Android spell-checker followed a predictable pattern. The iOS spell-checker, as on iPhones and my current iPad 2, follows another. If you aren't aware of that, you'll be very frustrated when moving from one to another.

The iOS spell-checker, when it can't match your registered key-taps to a complete word in its dictionary, assumes that you've fat-fingered a misspelling, and so the (one and only by default) suggestion it offers is based on that assumption. There are linguistic principles that determine how it makes that decision. While those have been understood for some time, it's been only relatively recently that a real-time-capable implementation has been both (relatively) affordable and easily portable. Auto-correct on the iPhone has been steadily improving, likely due both to improved algorithms and more powerful processing capabilities. OK, fine; that's what people who've only used iOS lately expect; it works reasonably well as expected, what could possibly be different?

Android hasn't always had the top-tier processing capability or memory of an iPhone 4 or 5 to throw at anything, let alone spell-checking. (Recent high-end phones are extremely competitive, but that's a whole other post.) If they can't or shouldn't throw enough resources at spell-check to actually correct in real time, then what can be done?

Take the other fork in the road, of course. Don't assume auto-correct to be spell-checking; instead, use it to reduce the number of key-taps needed to type longer words, à la TextExpander. Of necessity, this will involve a fair amount of "real" spell-checking. Android's spell-checker seems to assume that any typos are typos in the first few letters of a longer word. Further, it seems to assume that the first letter typed in a new word is always correct, and rarely if ever shows alternate words with a different first letter. (Android, unlike iOS, shows a list of candidate words, allowing the user to select among them with a single tap — further speeding rapid [if initially correct] typing.)

Which is "better" depends on your preferences and the accuracy of your typing on the device you are using. With my Lincoln Log-like fingers, I could maintain an effective 2-3 wpm rate on an iPhone 4; nearly double that on an iPad. After my iPhone 4 was stolen (apparently for parts as it was never again turned on), I bought the cheapest 3G hotspot-capable phone I could find at Lucky Plaza, which turned out to be a grey-market HTC Explorer. That was easily one of the two most painful experiences I have ever had in over 15 years of using mobile phones. A very, very kind and loving soul loaned me a Samsung Galaxy Note running Android 4.0 ("Ice Cream Sandwich"). Comparing the Explorer to the Note was slightly more comical (and less fair) than putting a 1976 Chevy Chevette onto a track next to a Bugatti Veyron and seeing who can finish 20 laps before the other. (If the Bugatti gives the Chevette a 15-lap head start, my money's still on the Bugatti. I've owned a Chevette.)

I now find that I type comparably fast on the (~5.3-inch) Galaxy Note as on the 10-inch iPad. I'll be returning the borrowed Note soon (geologically speaking, at least); I'm just waiting to be able to have a good demo of an iPhone 5 to compare, and see which I really prefer. The new iPhone is going to have to be at least as good as the fans and reviews say it is; this Galaxy Note is sweet…

Companies Lose their Minds, Then their Partners, Then their Customers, Then...

Following is a comment which I posted to Jason Kincaid's article on TechCrunch, "Why Apple's New Ban Against Sexy Apps is Scary". I don't know why Apple seem to be deliberately shooting themselves in so many ways on the iPhone recently; I am sure that they are leaving golden opportunities for Palm, Android and anybody else who isn't Apple or Microsoft.

Even if you're not developing for the iPhone or even for the Mac, this whole drift should concern you — because its most likely effect is going to be that you have fewer choices in what should be a rapidly-expanding marketplace.

Thanks for reading.

---

Exactly; they're pulling a Singapore here. They're saying "we're better than anybody else" because they've got this App Store with hundreds of thousands of titles, and hundreds of useful apps. Then they turn around and say "we're the only game in town; we're not going to let you sell your apps to customers any way except through us — and oh, yeah, we can be completely arbitrary and capricious before, during and after the fact."

Let me be clear: up until very recently, I've been an unalloyed Apple fan; the only sensible response to 25+ years of Windows development and user support and 10 years hitting similar but different walls in Linux. I'm typing this on one of the two Macs sitting on my desk. I've got logs and statistics that prove I'm far more productive on my worst Mac days than I ever was on my best Windows days. And I've had several Switcher clients over the past few years who say the same thing.

I can write and sell any app I want on the Mac; Apple even give me all the (quite good) tools I need right in the box. I can use any app I want to on my Mac; the average quality level is so far above Windows and Linux apps it's not even funny. In neither of those do I need the permission of Apple or anyone else outside the parties to the transaction involved. Apple do have good support for publicising Mac apps; browse http://www.apple.com/downloads/ to see a (far earlier) way they've done it right. But developers don't have to use their advertising platform.

With the iPhone, and soon the iPad, they're doing things in a very untraditionally-Apple way: they're going far out of their way to alienate and harm developers. You know, those people who create the things that make people want to use the iPhone in the first place. And a lot of us are either leaving the platform or never getting into iPhone development in the first place.

And that can't be healthy for the long-term success of the Apple mobile platform (iPhone/iPad/iWhatComesNext). As a user, as a developer, as a shareholder, that disturbs me, as I believe it should disturb anyone who cares about this industry.