Regular readers of my blog may be aware that I started out programming using Borland Delphi. Actually, that’s not really true—I started out programming on the PC using Delphi. I first programmed a computer back in the early–to–mid 1980s on a Sinclair ZX Spectrum, but that was a long time ago and my “programming” mainly consisted of laboriously entering listings from magazines, which usually didn’t work because of misprints. The best one that did work was a Pac-Man game, which was gratifying after all that typing.
The first version of Delphi that I used was the 16-bit Delphi 1.0 and shortly afterwards I moved to the 32-bit Delphi 2.0 that had just come out. My guide was the brilliant “Delphi Programming For Dummies” by Neil Rubenking of PC Magazine. Don’t laugh, I really was a dummy back then and didn’t even know what an API was. Besides, it was a very well written book and the example programs were great.
The reason that I absolutely adored Delphi was that it let me easily create Windows applications that looked like proper grown-up applications. I could just drag and drop controls onto a form and concentrate on producing a great UI. Now Delphi wasn’t the first to market with this idea, but I soon learned that its implementation was superior to Visual Basic’s.
Gradually my programming abilities improved and I was soon getting acquainted with the peculiarities of the Windows API on a regular basis. I was churning out simple desktop utility programs at an amazing rate, although I only finished a few of them, because the tool I was using made it so easy to be fickle and to start something new as soon as an idea was hatched. I loved the instant gratification Delphi gave me.
The high point of this period was probably when a friend and I ended up in a sort of competition to see who would be the first to work out how to put an icon in the notification area near the Windows clock, as Windows 95 had just come out and this was a hot new feature. Some people have never got over it, judging by the number of apps that put crap down there. Although my friend was the better programmer, I got there first by getting to grips with the Shell_NotifyIcon API.
My confidence bolstered, I set about trying to learn more and more about how Windows and Delphi worked. I remember starting a new Delphi project once and just compiling the default form into an EXE and marvelling at how Windows and Delphi’s Visual Component Library (VCL) combined to give you a window with associated behaviour—all for free. I was fascinated by just how much stuff was in Windows and how the more you learned about it, the more there was to learn. It was a good job Raymond Chen wasn’t blogging back then.
I brought Danny Thorpe’s seminal “Delphi Component Design” book and was blown away by the elegance of Delphi’s VCL. In fact, just writing this makes me want to dig the book out again and take another look and wallow in nostalgia, but sadly I don’t have it here. One of the revelations in the book was a discussion that explained that when you place a Delphi component on a form, you’re not dropping some static design-time representation of the component, but rather a real live instance that just happens to be working in a different mode than from run-time.
I learned more and more and graduated to writing my own simple components, and different versions of Delphi came and went. At the same time, I didn’t really understand the direction Delphi was heading in. It seemed to be moving further and further away from developers like me who just wanted to write cool Windows apps. Borland kept adding things to make it easier to develop Web applications, something that I didn’t know anything about or couldn’t really see the point of.
Sometime around Delphi 5.0 or 6.0, I finally got a job as a programmer and had to learn Visual Basic 6.0. I went into the challenge open-minded, knowing that Delphi was totally superior and that VB was a steaming pile of crap, but thanks to some great training courses from a very good teacher, I learned that actually it was rather neat, particularly when it came to doing things with COM. Then my employer got Java religion and I had to learn J2EE.
I was initially enthusiastic about the prospect of practising enterprise Java. I felt like I’d arrived because I was going to be using proper enterprise tools. This was going to be software engineering using the UML and RUP, none of this chucking buttons on a form malarkey. I wanted to learn what these EJB things were that people spoke about in reverential tones. From hanging around with contractors I picked up that Entity Beans are rubbish, although at the time I didn’t know why.
I learned about JDBC and Servlets and JSPs and I lovingly crafted every Javadoc comment for my getters and setters. Or accessors and mutators as I liked to call them. Then I learned Struts and thought it was quite neat, and then I taught myself Ant, and before I had time to pause for breath the Spring Framework was getting a lot of hype so I started to look into that. Then I started to notice that boy, just getting anything done with J2EE is an awful lot of work and I kind of missed the fun of writing some code and instantly seeing if it worked. Or not!
Like so many, I’d become disillusioned with the complexity and over-engineering of J2EE. I was spending most of my time editing arcane XML configuration files and I started to question whether all this up-front indirection and flexibility was worth the trade-off in terms of how long it took to get anything up and running. The whole J2EE way of working made me feel like I should be barking instructions to someone else to do the typing because I was too tightly coupled to the keyboard!
I quite like the idea of J2EE containers which are Java programs for running other Java programs, as ever since I started to learn about how Windows worked under the covers I’ve been fascinated by virtual machine technology. However, I didn’t want to spend the rest of my days waiting to deploy my application to the container before I could see if the one line of code I’d changed had worked.
Fortunately I discovered Ruby on Rails just in time. I can’t remember how I first came across it and at first I thought “what is this?”, but the more I learned about it, the more it just seemed to make sense to me. The tipping point was when I bought the Agile Web Development with Rails book last summer. Learning about ActiveRecord in particular recalled in my mind the experience of reading about something not only well thought-out, but beautiful, that I got when I read Danny Thorpe’s Delphi book.
Rails seemed to make everything easier, with its Convention Over Configuration and Don’t Repeat Yourself principles. Why should I have to specify the properties of an object multiple times as I have to in Java? Let’s see, I do it once in a SQL script for the database schema, then again in a Data Transfer Object which probably has a tautological name like UserDTO. Also there’s probably a Data Access Object that knows all about the Data Transfer Object and there may well be a specific DTO for the user interface layer, because the other DTO was written by another team and doesn’t do quite what the UI needs. It’s madness, and that’s before you start to consider the mess of supporting configuration files that you need just to stitch it all together. With Rails I just create a model object and then write some Ruby code in its associated migration file to specify what its database table should be like. I don’t even have to write getters and setters because I’ve already specified the object’s properties in the migration.
I don’t need to waste time with a lot of up-front flexibility, because Rails makes it so easy to change things at any time. Lots of people have mistakenly inferred that Rails’ Convention Over Configuration principle means that there is no configuration available, but that’s simply not true. There’s plenty if you need it. It’s just that the creators of Rails have refactored the configuration/convention equation so that the default case covers what you probably want to do most of the time. The upshot is that I no longer spend my time editing XML files and can be productive again.
I’ve saved the best part about Rails until last. I’ve found that Rails has brought the fun back into programming. Ten years later and with Web applications instead of desktop applications, this framework makes me feel like I did when I used Delphi. It gives me instant gratification. It makes me want to try things and generally seems to reward me when I do. With J2EE I find that sometimes I don’t feel like programming, simply because it takes so long to get results. Enterprise Java may have a lot of heavyweight architect types and industry thought leaders behind it, but that doesn’t motivate me to create code. Anything that does get me programming and gives me quicker feedback on how I did is good in my book. Delphi ticked those boxes and so does Ruby on Rails.
