UNDER THE CARPET

Dick Pountain/26 October 1998/Idealog 51

Colleague Jon Honeyball recently lamented that modern development tools are becoming so complex that "the days have gone when people can afford to be competent in a number of tools and switch between then as the needs arise". I agree entirely, and it saddens me as much as it does Jon. Once-upon-a-time programming was a source of pleasure, and I was damn-nearly addicted to learning new languages. I calculate that I could write non-trivial programmes in around 23 languages, including collectors items like Hope, POP-11, CLOS, PCL, Occam and Linda.

Beyond such anorakish games however, I actually value the ability to knock together quick-and-dirty PC programs that do real work (say converting all my telephone numbers when they changed the codes), and I use utilities I've written myself on a daily basis. Borland's Turbo Pascal became my favourite tool for such tasks, and what little PC programming I still do, I do in Delphi 3. I loved Visual Basic when it first appeared, but became more and more depressed as Microsoft rendered VB virtually unusable by piling on botched pseudo-object-orientation and mountains of 'enterprise computing' features that have no relevance to a personal PC user like myself. A similar proliferation of superfluous embedded object brokers and web-servers is what stops me from upgrading to Delphi 4. On paper Java looked right up my street, but I found I had no desire to run my utilities inside a web browser, and by the time Java applications came along I'd lost the will to learn.  

What has saved me from losing interest in programming altogether is the Palm Pilot. I'm not talking here about writing commercial applications, for which you really need to use C (probably CodeWarrior) and learn PalmOS's horrible API, but rather about quick-and-dirty utilities to solve particular personal needs. Incidentally, I don't feel this admission to be in any way demeaning: I've always believed the aim of programming is to get as far away as humanly possible from the hardware, and to hide as far as possible the crap that passes for an operating system. I've never considered C programming as a proof of manhood, but rather of the retarded adolescence of our whole industry. Recently I've been trying out some Pilot languages, and though there is still a long way to go I've found three that are quite usable for quick-and-dirty jobs.

The Pilot's symbiotic relationship with its host PC complicates your choices no end. Sometimes when far from home I'd like to actually be able to write small programs on the Pilot itself, but for utilities I use a lot I'd rather develop on the PC and download the result. Some utilities need to store data in a Pilot database (and hence to HotSync this data with the PC) while others don't, and so on.

For developing Pilot utilities you are going to use a lot, that need to store data, CASL is now my first choice. This simple and elegant language runs on the PC, with a nicely integrated editing/compiling/debugging environment, and it lets you create user interfaces VB-style by dragging-and-dropping standard Pilot buttons, edit boxes and list boxes. CASL generates almost identical-looking executables that run on the PC and the Pilot from the same source file, and comes with its own conduit to sync data files between them. Like VB, CASL is semi-interpreted and requires a runtime system to be installed on the Pilot, but at around 40 Kbytes this is hardly onerous. The latest CASL release 2.6 comes with library code to manipulate the Pilot's DateBook database, and also for the first time can generate executables for Windows CE too. It's shareware, available as a modest download from http://www.caslsoft.com.

For writing programs on the Pilot - to while away a long train journey for example - I now prefer PilotFORTH, which is a reasonably complete implementation of ANSI Forth that runs entirely on the Pilot, with remarkable efficiency. You write code in the Memo application, and by applying SwitchHack and a couple of judicious shortcuts I've made the edit/compile cycle remarkably slick, even with the pen interface. I was a Forth hacker (even wrote books on it) way back in the early '80s so the language holds no terrors for me, but I can't in all conscience recommend it as a solution for everyone. Reverse Polish notation and open stack manipulation take some getting used to, while Forth's ability to penetrate into every crevice of the machine make it rather like a loaded Magnum with a weak trigger spring: you will soon regard reset as an old friend. PilotFORTH's biggest weakness is its minimalist documentation. Its strength is that it lets you make system calls (and hence do anything you could do in C) if only you knew what they all were...

The third language I find occasionally useful is Chipmunk Integer Tiny Basic, better known as cbasPad, which like PilotForth runs entirely on the Pilot, but has its own integrated source editor. The cbasPad language itself is a very conventional dialect of Basic, with all the horrors that implies like line numbers, GOTOs and GOSUBs and a lack of named parameters for subroutines. It also has very crude output facilities so it can't produce anything resembling a professional user interface. So why do I like it? Because cbasPad's 'op' command can easily search for or insert strings into the Pilot's built-in Memo and Address databases without needing all the mess of file-opening code that CASL and PilotFORTH require - cbasPad sweeps all that stuff under the carpet, which is exactly the way it should be.