AND SO TO DELPHI

Dick Pountain/13:30/01 December 1995/Idealog 16

Though it's been sitting on my hard-disk for over a year now, it's only in the last three weeks that I've started using Borland's Delphi in earnest. I should hastily add here that what I call earnest will probably not be considered so by professional programmers. Am I creating virtual drill-bits for data mining into corporate databases? 'Fraid not. Am I then perhaps building a virtual fork-lift truck to trundle through vast data-warehouses. Er, no. Actually I'm writing a Poker game. To be honest I've been writing a Poker game for the last 14 years, or rather writing several different Poker games.

I used to play quite a lot of Poker back in the early 1970's with a school of Bourbon-swilling reprobates who went on to become rock-stars, authors, publishing magnates and in some cases dead. The game has always held a fascination for me that Chess or Bridge could never rival. Just as puppies and kittens play-fight to learn how to catch dinner, the games we play are simulations of different aspects of real life. Poker is all about reading people's motives and characters - its technical aspects are not very demanding, apart from learning the probabilities of the different hands. Chess tests a much more abstract pattern matching ability, but life is seldom as simple as a chess board.  

When eventually a personal computer fell into my hands (An 8K Commodore PET) practically the first thing I did was to try to write a Poker game for it. That game worked quite nicely but it only supported two players, me versus the machine. I could vaguely see that it ought in principle be easy to extend it to five or six players, but I'd written it in Neanderthal Basic using only GOTOs and GOSUBs and the word 'parameter' had yet to enter my vocabulary. The program gathered dust.

When Borland launched Turbo Pascal v 1.0 I discovered what parameters were for, and records, and sets, and all the other structures of grown-up programming. In the fullness of time I rewrote my Poker program in Turbo 5.0 as a fully object-oriented program, built from objects like Cards, PokerHands, PokerPlayers, PokerPots etc. (As an aside, by this time I'd completely stopped playing real Poker. I'd spent so long pondering over algorithms for evaluating Poker hands that the real game no longer held any pleasure - like a conjuring trick that ceases to entertain once you know how it's done. Perhaps there is a warning here.)  

Then came along Windows. I tried Turbo Pascal for Windows and found it too much like hard work, the raw Windows API not nearly well enough hidden behind the OWL class library. So I defected to Visual Basic, whose brilliant visual programming paradigm was so clearly the way of the future. I loved the environment but I never did learn to love the language. Certainly it's light-years away from that old PET Basic, and supports most of the modern control and data structures, but it still feels clunky compared to the elegance of Pascal. Whenever I had to write some nonsense like 'A as Integer, B as integer, C as Integer' instead of 'A, B, C: Integer' my stomach would knot up. The US architect Louis Sullivan claimed that 'form follows function' (later to be taken up as the philosophy of Bauhaus modernism) and I still believe that - if something looks right it probably is right. I can get the same sort of buzz from looking at a well-turned Pascal procedure as from a well-turned sentence. While I might argue earnestly about the iniquities of C's unsafe type-casts and pointer manipulations, what really ruins the language for me is all those curly brackets.

I wrote quite a few programs in VB, including a diary/scheduler that I still use, but despite a few false starts I never translated my Poker program. It was just too depressing to have to replace proper objects with VB records and a load of totally unattached subroutines. And so to Delphi. My experience so far has been pretty good. The Poker program went from Turbo 5.0 into Delphi as sweetly as I could have wished. OK, some bits had to be totally re-worked - say to replace character-based cards by graphical ones from a DLL - but I didn't need to alter one word of the code proper. It felt like coming home after a long absence. About the same time VB 4.0 finally arrived, complete with objects, but I fear it has come too late for me.
 
There have been a few hiccups, mostly caused by Borland's woefully inadequate documentation for Delphi. Since my Poker program was predesigned in OOP fashion it wouldn't have been appropriate to rebuild it visually - instead I wanted to dynamically create certain Delphi visual objects (eg. TImages to display cards, TMemos to display speech bubbles) as fields within my own objects. It took me far longer than it should have to discover that such objects wouldn't appear on the screen unless you explicitly made the current form their Parent (a concept that doesn't exist in VB). I've since roamed around the Delphi conference on CIX and found that quite a few people share the same suspicion, that the reason for the poor documentation of many Delphi features is that Borland is desperate to present it solely as a database building tool and conceal the fact it's a general purpose programming language (and what's worse, NOT C++). I can fully understand why Borland might feel paranoid in a world stalked by the monster Microsoft, but this strategy reminds me of the old joke about the Snake that ate Big-Mouthed Frogs ("Oooh, is that sooo"), and it's just about as likely to succeed.