Sunday, May 20, 2018

Don't Just Code in Delphi, Think in Delphi

I have always struggled with fully understanding the object oriented nature of Delphi. I still struggle with it today. For example, I have tried to read Nick Hodge's book "Coding in Delphi" three times and can't get past page 23. I'm currently on page 96 of Pawel Glowaki's book "Expert Delphi" and had to stop because he talks about using the TTextWriter class which is a class with virtual abstract methods. Virtual Abstract Methods, are you kidding me. What the hell are Virtual Abstract Methods.

(Expert Delphi page 96) "Notice that the TTextWriter class is a class with virtual abstract methods that just define the interface to the text writing functionality so we need to use one of the text writer descendants such as TStringWriter."

Okay, so I get a small glimpse into what Pawel's talking about. These VAM's are just interface definitions. They don't really exist. The real functions exist somewhere else. In this case the TStringWriter class. I'm just barely hanging on here, but I'm hanging on.

I blame my Delphi ignorance on my lack of going back to square one and learning Delphi's OOP think from the beginning. At the time I started using Delphi I just plowed ahead and made the code work. I wanted a Windows program and that is all I cared about. Looking back at it, I'd say I forced Delphi to work like my top-down procedural thinking. I never fully embraced the Delphi OOP think.

Hodges, Glowaki, Cantu, and all the other Delphi authors out there think in Delphi. And if I want to understand them and be proficient in Delphi I need to think in Delphi too.

So, how do you think in Delphi?

You find a resource that explains Delphi in a simple straight-forward manner. Perhaps a resource that teaches you how Delphi came into being. Does such a resource exist? Yes. And I just so happened to have a copy on my bookshelf.

Here are three paragraphs from page 7 and 8. If these paragraphs speak to you like they did me, then I highly recommend you read the entire Turbo Pascal 5.5 Object Oriented Programming Guide.

The challenge of object-oriented programming (OOP) is that it sometimes requires you to set aside habits and ways of thinking about programming that have been considered standard for many years. Once that is done, however, OOP is simple, straight- forward, and superior for solving many of the problems that plague traditional software programs. 

A note to you who have done object-oriented programming in other languages: Put aside your previous impressions of OOP and learn Turbo Pascal 5.5's object-oriented features on their own terms. OOP is not one single way; it is a continuum of ideas. In its object philosophy, Turbo Pascal 5.5 is more like C++ than Smalltalk. Smalltalk is an interpreter, while from the beginning, Turbo Pascal has been a pure native code compiler. Native code compilers do things differently (and far more quickly) than interpreters. Turbo Pascal was designed to be a production development tool, not a research tool. 

And a note to you who haven't any notion at all what OOP is about: That's just as well. Too much hype, too much confusion, and too many people talking about something they don't understand have greatly muddied the waters in the last year or so. Strive to forget what people have told you about OOP. The best way (in fact, the only way) to learn anything useful about OOP is to do what you're about to do: Sit down and try it yourself.

I'm convinced this little 124 page resource will give me the solid foundation of Delphi think that I've  been missing. I was so excited to find this little gem and what it offers, I had to stop reading and tell you guys about it.

A copy is available on


Semper Fi
Gunny Mike