Wednesday 28 November 2012

My Singapore Life, Part DXLVI

In what's become a near-weekly occurrence, I got hit by a car while crossing a crosswalk this afternoon. I was halfway through the crosswalk next to the McDonald's at Tampines Mart here in Singapore, walking towards my home in one of the adjacent blocks of flats, when a red cab hit my hip as I was jumping clear of him. He was doing at least 10-15 kph going up to the exit gate, which is typical for the cars here. A raised crosswalk with zebra-stripes, especially with posted "yield to pedestrians" signs, is supposed to mean that pedestrians, of whatever ethnicity, who are already in the crosswalk before a vehicle crosses the adjacent limit line have the right of way. What's left unwritten, in this most racist of officially non-racial "countries", is that the rules only apply to Chinese drivers if the pedestrian is Chinese.

As I indicated, this happens to me at least once a week, and there's a certain…predictability…to the particulars of the offending driver. I saw a Malay woman crossing the same crosswalk about three weeks ago get hit and knocked down, and the driver just kept going.

Singapore is a very popular tourist destination in South Asia, but if you're coming here, be aware of certain sensible ground rules. Stay in the tourist/expat "bubble" areas, generally downtown. Be prepared to spend lots and lots of money. And, whatever you do, don't take any of the tourist propaganda about "multi-cultural, non-racial Singapore" as anything other than the sick joke it has become in recent years. If and when we get a post-PAP Government, that may change. But I'd be very surprised if it was markedly less in any time-frame short of a generation or three.

Tuesday 20 November 2012

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.