Delphi/Pascal Through the Ages

(I apologise that this is a long post. if you are in a hurry, then please at least read the last 3 paragraphs)

Delphi started out life as Turbo Pascal on CP/M. For those of you old enough to remember, CP/M was prior to MS-DOS, which in turn was prior to Windows. While getting to grips with Pascal MT+, I saw an add for a new compiler called Turbo Pascal in the very early 1980's and I bought myself a copy.

From this simple, small and very fast compiler I wrote a small business accounting program that I sold on the Amstrad Computer. I used some code I found in another Borland addition called 'Database Toolbox' to add file and indexing routines.

It was about mid 1980's that my accounting program The Trader Series had a serious following in New Zealand amongst Amstrad computer users and I decided to devote all my time porting it to MS-DOS, I gave up my job as Marketing Manager for Panasonic Computers in New Zealand to become a programmer. Coding in Turbo Pascal was fun. There were several enhancements since that first version 1 that I purchased, these included such powerful things as Overlays. We were restricted to 640 Kilobytes of memory so using overlays I could now write much larger programs.

There were also a lot of third party programs and additions around, including a simple debugger which helped me a great deal. "The Trader Series", the accounting program I wrote, expanded to five separate modules and over half a million lines of code. Having much greater access to memory, I totally rewrote the screen handling so that all screens were built in memory and "shifted" to the screen, making it seem lightening fast for the user. I also abandoned Turbo Toolbox and rewrote the indexing system with a doubly linked, self-balancing B++ tree. These enhancements, along with using linked lists for transactions made it the fastest accounting program on the market at the time.

I remember running a demo for the company I selected to distribute the program (I decided that I can't be both a programmer and salesman/marketing person). Their high end product took as much as 30 to 40 hours to run an end of month process. I had built up a database of 30,000 debtors, each with about a dozen transactions. After the demo they asked me to perform an end of month and turning to leave, asked when I would be back in to see the result. I told them it had been done. I spent all afternoon proving that it could run an end of month process in less than a minute. That program won the New Zealand Computer Software Awards in 1987 and became New Zealand's largest selling small business accounting program for the next 10 years.

Turbo Pascal was a great language. Object Pascal raised its head in version 4.0 and I stayed with Turbo Pascal until I sold The Trader Series in 1990.

By now Windows was getting a grip and I needed to move into this arena. Borland's Pascal for Windows just didn't do it for me. I went with a number of other languages including FoxPro, C++, Visual Basic, and I even tried a new language called Java (it'll never amount to anything but hype, or so I thought - Sigh, I have been proven wrong before).

Borland then introduced Delphi and I managed to get myself a pre-release copy. Finally a great environment. Something that equaled the environment of Turbo Pascal when it was first introduced. Delphi however had a much larger price tag, but I purchased anyway and was thrilled with the power that even this first release had. Delphi was written in Object Pascal and the source code was included. You could learn lot with that source code and programmers were able to write their own components. The Component market was created with many outstanding components pretty soon there were thousands to choose from.

Delphi, the new Turbo Pascal, was alive and kicking again. I was a contractor through the 1990's and contracted to many different companies and corporations and was able to persuade more than a few to look at Delphi for their future needs (where appropriate).

While Delphi was indeed an excellent development environment, I was more and more disappointed in its growing price tag. By 2003, Borland had priced itself completely out of the market. The price for Delphi was now about the same price as a good second hand car in New Zealand and more than almost all other development environments.

I could no longer afford my favourite development language and companies everywhere in New Zealand were coming to the same conclusion. Sadly, I was shifting to Microsoft and C#. I still had, and still use, Delphi 7, but the call to C# was strong as the companies left Borland, and as Borland lost interest in Delphi. I could not find work as a Delphi contractor any more.

Earlier this year, I was invited along to the Delphi 2007 pre-release roadshow. There I learned that Borland had shifted Delphi into a separate company and concentrated on its team tools. CodeGear had been created to take over Delphi as its flagship product. Personally I thought it should have been the other way around, but that's the way it is. The price of Delphi was dropped by several thousand from what it was in 2003, and it had been given several enhancements since I last saw it in Delphi 7.

I saw this as a resurrection of Delphi and a possible push to get Delphi back to its space as one of the top programming environments. They have a long way to go to get back the loyalty that they once had. Companies had dropped them and now few companies will look at Delphi again.
However, in my intervening years with other development environments I have learned a few things: A team of 3 dedicated Delphi developers can totally outperform a team of 40 developers in Java and other Microsoft languages for a similarly large corporate application - by a factor of several months. I have also learned that, although Delphi can do .NET, Win32 can often deliver to the customer a far superior product, much more aligned with the customer's needs, in a much reduced timeframe/cost. And I learned that even a single developer armed with some excellent Delphi tools, can take on the giants.

CodeGear, your work now is not with enhancing Delphi (other than in the helpscreens), its marketing that will win the lost corporates and large companies back. You won't win them all, the "We're a Microsoft Shop" syndrome is too well entrenched for that. But you can win over a lot and make your headway in the world again, and give back the power to the average programmer.

I must admit, it's nice to be able to get back to programming without fighting the tool every single step of the way.

Getting the Time to Program

How many others have the same problem?

I have a number of ideas that I would love to program in my spare time. I have produced many retail programs previously with success so know the pitfalls. I have worked out most of the kinks in the logic of how to implement many of the features. I just need to program them.

The problem is that I spend a great many hours in the day programming at work. New Zealand is known for being a wonderful place to live, but its also getting known as the hardest working. Us poor Kiwis (the kiwi is our native bird and also the name we call ourselves), have the second highest rate of average hours worked per year compared to all other OECD countries. This means that when I get home, I am in serious need of relaxation and the things I want to program get put off for another night.

I have some wonderful ideas that I know will be good sellers, I just need the time to program them. Often the time I do spend on these ideas at home, ends up as code that is used in my work programs. This keeps the boss happy (I hope), but doesn't get my programs finished.

Mind you, with spending every weekend with my Fiance and her daughter, and spending about an hour on the phone to her every night (we live in different towns) does not help the situation so I suppose I'm my own worst enemy.

How do you make sure that you put aside the time and energy to program in the evenings?

Different Programming Styles

I was reading Serge’s Blog on Programmers and Temperaments this morning and it reminded me of a project I did for a company in Wellington once. It was a large international company (no, I'm not going to tell you which) and they had a very large project that they needed to produce. The project was technically difficult requiring a lot of thought each step of the way.

After a lot of design by their chief software architect, they called for programmers. About twelve of us were hired for this one project and it was really fun to get to work with a number of others on one project like that. We were given regular daily meetings to try to bring us all up to speed on the technical requirements, and then shown to a large, open plan room with a computer on each desk to choose our own work area.

What was most interesting though was a discussion that I was having with the project manager about a week later. He commented on the work styles of each of the programmers from the perspective of an observer. This wasn't a moan or gossip session, but a discussion on a real observation.

After all the meetings and the whiteboard sessions were over, we all drifted into the desks and work practices we wanted. The project manager observed the following different styles...

I found my niche in a corner desk that was on its own, then got out my pad and spent the next 2 days planning what and how I was to approach my part of the project, before I even touched the keyboard. I wanted to completely understand the requirements (which were mostly in the architect's head, given out on the whiteboard sessions). Once I understood and had a clear plan, then it was a matter of programming.

Two others immediately grabbed two desks that were joined to each other so they were sitting side by side, then simply pulled one chair over to the other desk to together at the same desk, one computer between them, and designed and programmed together. They needed to talk through what they were doing and help each other plan and program. Occasionally the second programmer would move to the computer on the other desk to program a sample procedure to help explain to the other his thoughts on a subject.

Another programmer sat down at the first available desk and started pounding out code. He needed to try out various prototypes and work from there, building up his code as he went.

Various others worked somewhere along the spectrum of the above three different styles. Some couldn't handle it and after a few days left for greener and much easier pastures.

What was interesting over the following several months was the general effectiveness of the different styles. I (admittedly somewhat surprisingly as there were some seriously experienced programmers that I enjoyed working with) ended up producing the end result much faster, followed by the pair/buddy approach. The person who immediately started coding, had to change and restart so many times that he turned out to be the least effective.

I'd love to hear your comments on what you have found in your experiences.

My Delphi 2007 program isn't debugging!

I think I've just found a little "think first" when using Delphi 2007.

Trying to step through the code with the debugger to find out how and why something isn't happening as it should, I placed a break point on the first line of my FormCreate method. When I ran the application in debug mode, my breakpoint changed to a green cross and the program didn't stop.

Aha! said I to myself thinking myself clever (always a mistake), It's a project option. I must have turned off the debugger. Nope - that wasn't it.

Aha then! (yes, clever again) I must have changed some other compiler directive somewhere. Nope - stumped.

Realisation is now dawning on me that I wasn't half as clever as I thought I was and I eventualy even reverted to the old "Microsoft's fault" fix-all - Exit Delphi and all other programs, close down and start the whole computer up again. Load up Delphi, place the breakpoint, run and ... Nope - that wasn't it either.

Several minutes of frustration followed in which it would not be prudent to relate all the details (I am Christian after all).

Then it dawned on me. A small 'thank-you' to Him and off I go to Project Options, Build Events. Yes, I had a Post-Build event.

My normal process is to build the application, then move the application to the ..\bin directory where it needs to be in order to run correctly. Being exceptionally clever (or so I thought at the time), I placed those steps into the Post Build event. That was several weeks ago and I had forgotten.

In order to correctly debug the program today, I changed the project's output Directory to the ..\bin directory where it needed to be to run.

What all that meant was that when I ran build (F9), I expected the program to run to the breakpoint and then stop. However, Delphi knew that I wanted some things to happen in the Post build routine and copied over the just-built exe with an older version sitting in the ..\source directory. Now there is an exe running that does not have the breakpoint and does not relate to the code I am expecting to run.

A interesting morning's lesson on trying to be too clever for my own good.

Have a great day.

Steve

Where'd the CopyFileTo command go?

What a busy month for me. It feels like I've barely got back from the wedding in Brisbane and that was a couple of weeks ago.

I was working with an older Delphi program today that I hadn't loaded in Delphi 2007 as yet (possibly not since Delphi 6 or 7). When I tried to compile, it failed - it couldn't find CopyFileTo().

CopyFileTo() is an Indy function that used to reside in idGlobals. It now resides in idglobalProtocols. I simply include ", idglobalProtocols" in the 'uses' statement and it compiled.

Strangely a search of the internet did not come up with the answer - other than to point me in the direction of Indy. A search of all *.pas files under "..\CodeGear\Delphi\5.0\source\Indy\Indy10" showed me the correct file I should "Use".