Author: Kyle Cordes

Comparing PHP and ASP

PHP and ASP (Active Server Pages) have many ideas in common, and I tend to lump both in to the same category: page-based server-side web scripting tools. I use that category for small to medium sized application; I usually don’t choose it for large or complex web applications.

Here are a few points of comparison between the two:

  • PHP is more seamless across platforms. I can develop on my Windows box and deploy on Linux. (I know about ChiliSoft’s ASP implementation for Unix, but I don’t see much point in bringing my ASP code, which tends to use COM objects, over to Linux.)
  • PHP has a great number of functions that a web developer needs “in the box” – read through the manual to see the list. I found that I had to go looking around to third parties and COM objects to get some things in ASP which
    were already there in PHP. For example, the htmlentities() function.
  • PHP is very often available on external web hosts, if they use Unix/Linux servers, at very low cost.
  • ASP is not tied to one language. It uses the same infrastructure to work with VBScript, JScript, PerlScript, PyhonScript, and more! This is an excellent approach, and Microsoft should be applauded for it.
  • In ASP, the dominant model for DB access is to use ADO, which provides a degree of database independence; PHP has seperate functions for each database type, and requires an additional layer to acheive that degree of independence.
  • Code modules in a COM object can be plugged in to ASP or 100 other places.
    Code modules in C with appropriate PHP linkage are only for PHP, and are potentially more difficult to write.
  • ASP is almost always available on external web hosts, if they use Windows servers. Windows-based hosting tends to cost a bit more than Linux-based hosting, especially with SQL Server is provided.

Update (2007): PHP and ASP (now ASP.NET) have changed considerably since I wrote this; I suggest looking around for a more current comparison if you need to select between them now.

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:
    •   try
    try
      // yada
    except
      // yada
    end;
  finally
    // yada
  end;

    rather than

      try
    // yada
  except
    // yada
  finally
    // yada
  end;

    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, Oasis Digital offers 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.