Improving Delphi Object Pascal

In a conversation between me and others in a newsgroup thread a while
back, I made some comment about not caring for the Object Pascal syntax
in some way. Someone asked:

> If you dislike Pascal so much, please explain what you like and
why.

This is a slightly more detailed answer to the question than I presented
at the time:

I actually like Delphi / OP, just not as much as I could. In case
you are interested, here are some things I wish were different:

  • I find the begin and end keywords to be needlessly verbose.
  • Control structures could have matching, non-optional blocks… like
    Modula-2 or (!) VB. if .. then .. endif would be more concise than "if
    .. then begin .. end", and make it easier to read code and prevent
    bugs. The whole begin/end thing really belies Pascal’s origin as a teaching
    language. When you write 2-page programs, it doesn’t matter if begin/end
    is verbose.
  • Case insensitivity permits sloppy coding.
  • Now that I’ve used Java quite extensively, I am really sold on garbage
    collection as a Very Good Thing for large-scale projects.
  • I wish there was a more effective structure for handling large amounts
    of code, other than the flat module structure. Java packages are nice.
  • I wish the RTTI covered everything about the class, not just published
    properties.
  • Why do we have to do:
  • rather than

    Borland could easily allow the latter, short and clear syntax.

The underlying point to all of this is that Object Pascal is Borland’s language;
they can do anything they want with it. The things above are within their
power to change; it’s not like that are complying with a standard.

But do I really want them to change all this? Probably not. Would I choose
OP for my code if it weren’t for the great stuff around it (the IDE, VCL,
weatlh of third party components, etc.)? Definately not.

In my opinion, the core strength of Delphi is not the language. It’s the IDE, VCL,
lightning-fast compiler, linker, and overall environment which have made it possible for Delphi to have
a vast array of available plugin components. Delphi has attracted a remarkable
number of vendors of high quality components. Using those components as well
as Delphi’s (object-oriented) core features, it is often possible to build a working solution in Delphi
much sooner than would be possible with another tool… and that is what I
like most about Delphi.

Web Services

There has been a lot of buzz recently about "Web Services". A short examination shows that essentially a web services is an RPC (remote procedure call), generally across the internet, using SOAP/XML over HTTP.

RPCs are nothing new – so why all the excitement? Here are some reasons:

  • Web services work over the internet, through firewalls. Getting other RPC technologied to do this can be challenging.
  • Web services carry "WSDL" service descriptions, which will make it possible for software development tools to greatly automate the process of using them.
  • Web services are truly language-neutral; many other technologies carry baggage that belies their origin in one primary language.
  • Web services are text-based; the protocol is human readable and hence much more debuggable than (for example) IIOP, DCOM, RMI, etc.

Borland has made it near-trivial to expose functionality as a web service, or call web service functionity in Delphi 6. With just a few clicks the needed client or server side "stub" code is automatically generated, allowing you to use a web services as easily as any local function/procedure.

Many publicly accessible web services are listed at http://www.xmethods.net/

Extreme Programming

Here are some notes from my early XP investigation:

Extreme Programming (commonly called “XP”, an unfortunately overloaded acryonym with Microsoft’s impending release of Windows XP) is a relatively new, lightweight method for software development. I have been applying XP practices in recent projects with excellent results. There are a number of excellent web sites about XP:

http://www.xprogramming.com has a good general introduction.

Martin Fowler offers a concise description of the merits and mechanisms of Continuous Integration, a core XP practice. There is also material on Continuous Integation on the WikiWikiWeb (mentioned below) here and here.

A common objection to XP is to call it “gloried hacking”, implying that XP does not value good design. Fowler addresses this issue in “Is Design Dead“. The short answer, towards the end of the article, is “Not by any means”. A higher-order answer to this objection is to note that many XP adherhents are people with quite strong design credentials.

A team at ThoughtWorks released Cruise Control, a tool for implementing automated builds for continuous integration. I have used Cruise Control with good results, and am looking for something similar to use in Delphi – Cruise Control works with Java and Ant. (If you need assistance getting Cruise Control or a continuous integration process working on your project, I offer consulting services.)

Is building and testing your whole product every day impossible, or ludicrous? I don’t think so, and apparently neither does Microsoft (a newer article has more details). If they could do it in 1996 with 5.6 million lines of code, it should be easy in 2001 with much faster hardware on a million-whatever lines of code project, right? Yet I have worked with groups who think of this as impossible on much smaller projects than that.

Another good source of insights on development processes including daily builds is Joel On Software. Joel does not talk about XP per se, but there are similarity between his recommendations and XP practices.

Pair Programming is probably the most controversial practice of XP. Many people (managers and developers) abhor the idea immediately upon hearing it. I’ve done some pair programming myself, and been pleased with the experience. It seems to work better in practice than one would expect. On the other hand, there are many programming tasks for which having two competent people working in parallel seems like overkill. A good starting point for information is pairprogramming.com.

Ward Cunningham’s WikiWikiWeb, though it has an odd name, contains a large amount of useful thoughts on XP, OO design, design patterns, and other related topics.

“Real” XP involves significant organization change, and buy-in (or at least acceptance) from many levels and parts of a company. Some of the practices, though, can appear quite radical, such that getting widespread adoption is difficult. Also, XP is not advertised as the solution to all problems. Even if your organization/project/etc. does not “go XP”, though, many of the XP ideas/practices can be applied in a not-really-XP environment with good results.

Refactoring

Here is a common situation where refactoring can be used:

Problem:

You have a body of code which exposes and API (set of entry points). You want this code to have a different API.

Non-refactoring based solution:

Take the old code apart. From the pieces, write new code that has the desired API. The problem with this is that it’s a big leap… with little confidence along the way that the code will work.

Refactoring based solution:

Create a empty implementation of the desired API. Use the old code’s API to implement these functions – create a wrapper around the old code. Verify (with unit tests) that the code does what you want, using the desired API.

Now, consider the “wrapper” and the old code as a body of code to be refactored… incrementally change it to improve the design, maintainability, etc.

Alternatively, if the code is “throw-away” code not of long term important, you have the option to stp – just leave the code wrappered and un-refactored.

Right now, most refactoring is happening “manually” – but in the future, a direction that IDEs can add more value is by automating the process. Imagine right-clicking a method and selecting “refactor up to superclass”. You can take a look at this idea with a tool that “adds-in” refactoring to your existing IDE, like TransMorgify. A new Java IDE, IntelliJ IDEA offers a limited set of refactoring tools, built in to the IDE.

Recommended Reading

Design Patterns, Gamma et al. I have purchased and read several other books on this topic, including language-specific books and longer books. I still like this one best.

Programming Perl, Wall, Christiansen, and Orwant. The "camel book" is a clear and concise book about a perhaps unclear but very concise language.

UML Distilled, Martin Fowler, Kendall Scott, and Grady Booch. An excellent introduction to and explanation of the UML. This book can clear out the fog of an initally dizzying set of diagrams and distill out (!) their importance.

Refactoring : Improving the Design of Existing Code, Martin Fowler. This is a book that resonates strongly with experiences I have had where an existing code base had to be brought under control, cleaned up, and then enhanced. Such work is not totally ad hoc, but instead can be understood (and performed) as a series of well defined transformation. By doing so, and talking about it, our ability to talk about and manipulate software at a higher level is enhaced.

Extreme Programming Explained, Kent Beck. There is a lot of merit in going to original sources… the first book on a topic, a specification document on a technology, etc. This is that book for Extreme Programming, and the subtitle on the cover expresses the core thrust of XP in two words.

 

The links all go to Amazon for simplicitiy’s sake; you can perhaps get them elsewhere at a lower cost.