Comments on the survey #3: .NET

We have legacy Win32 code, but are moving toward .NET. Nevertheless, on the survey, I said that CodeGear should focus on Win32 support.

Now, why would I say that? Because our .NET plans do not include Delphi.

There are several reasons for that.

Communication issues

Borland/CodeGear blew it when they promised us a .NET 2.0 version of Delphi, and then changed their minds without telling anybody. As late as February 2007 (and possibly later), CodeGear was still promising that they were “going to” release a .NET 2.0 compiler the previous year, even though they had scrapped those plans long before.

Guys, changing your minds is fine. You’re a business; you’ve got to do what’s right for the business. But if you do change your minds, you need to actually tell your customers. The sooner the better.

Keeping up (or not)

Delphi hasn’t kept up with .NET, and there’s no evidence that that will change. .NET 2.0 shipped in November 2005; Delphi got .NET 2.0 support in September 2007, almost two years later (and how long had .NET 2.0 been available in prerelease forms before its release, precisely so that other vendors could keep up?). And Delphi’s .NET 2.0 support just barely scratches the surface.

RemObjects, the guys behind Chrome (another Object Pascal language for .NET), had the right idea: just do the stuff that adds value (i.e., make a language), and let Microsoft do the grunt-work and heavy lifting involved in writing an IDE. Maybe that’s why Chrome has kept up with, and in some cases gone past, C#’s feature set. In fact, from what I can tell, it looks like Chrome had a production-level release with LINQ support before Microsoft did.

A small company like RemObjects or CodeGear should be able to be nimbler than Microsoft, should be able to release major innovations on a tighter schedule than the Microsoft behemoth. RemObjects has done that with Chrome. CodeGear hasn’t — not for .NET, anyway.

(To be fair, Chrome isn’t currently in our plans either.)

Incompatible frameworks

VCL.NET apparently isn’t compatible with the rest of the .NET world. You need to make a special wrapper before you can use a WinForms control in VCL.NET, and I have yet to see anyone breathe a word about whether it’s possible to go the other way and use VCL.NET controls in WinForms.

That means that VCL.NET is only a viable choice when you’re a group of Delphi programmers who will only ever work with other groups of Delphi programmers. If you’re ever going to work with C# programmers, hire a contractor, look for code on the Internet — or if you already have C# WinForms code of your own — VCL.NET is a non-starter. This may not be a big deal for everyone, but it is for us.

Refactoring tools

I’ve already talked about the lack of refactoring tools for Delphi. Visual Studio, on the other hand, has two big things going for it here. #1, it has a handful of built-in refactorings that actually work; and #2, it has ReSharper.

I’ve already talked at length about how much ReSharper rocks (see my series, “The 31 Days of ReSharper”). I filled 31 days just talking about version 2.5; I haven’t even had a chance to look at all the new stuff in 3.0 or 4.0 yet. Delphi doesn’t have anything that comes close.

(It may sound like I’m contradicting myself here. On the one hand, I’m complaining about VCL.NET locking us in to a single vendor; on the other, I’m singing the praises of ReSharper, an add-in that only works with Visual Studio. There’s one big difference, though: I can still compile my code without ReSharper.)

Buggy IDE

I could make a long, long list of the bugs in the Delphi IDE that slow us down on a daily basis. Visual Studio? Not so much.

Delphi has half-baked features (strict private is fabulous until you use Class Completion or the refactoring tools), regressions from previous versions (missing Help topics jump immediately to mind), minor annoyances that add up on an hourly basis (using the IDE makes the command-line compiler stop working), compiler bugs (like the spurious “unit Foo recursively uses itself” that’s fixed by doing a Build). Just off the top of my head. At least there aren’t as many outright crashes these days; thank heavens for small favors.

Don’t get me wrong: Visual Studio isn’t perfect. We’ve had some problems with it too. But far, far less often than Delphi.

No comparison

Frankly, there’s just no reason to use Delphi for .NET development — not when we could be using a stable IDE and kick-ass refactoring tools.

We cross-compile some of our Win32 code into .NET, and that will continue. But CodeGear, don’t put more effort into .NET for our sake. Not now. It would be too little, too late.

Comments on the survey #2: Refactorings

The survey had little room for comments, so here are mine, starting with refactorings.

Delphi’s refactorings are crap. They leave you with non-compilable code more often than not.

A few examples of brokenness off the top of my head:

  • Class Completion got broken in CDS 2007. It usually completes stuff into the wrong class.
  • Class Completion mangles your visibilities if you ever try to use strict private or strict protected.
  • Delphi’s refactorings still don’t work across units if you don’t have every single unit explicitly added to your project file, so a Rename will usually break the build.

And that’s just the brokenness, not the suckiness. Extract Method still won’t do functions, but that’s just an annoyance. Automatic variable declarations usually get the wrong type, but that doesn’t break code that already compiled. What’s utterly unacceptable is that there are cases where the “refactorings” actually make previously-working code stop compiling.

Pretty much our entire team just ignores Delphi’s refactorings, because we know they’ll usually break our code. Please, please, please, put some effort toward making the refactorings work. In this day and age, we should not have to refactor by hand.

Comments on the survey #1: Saving in the middle?

The Delphi survey did not take me the 20 minutes they claimed.

Guys, any chance the next survey could be savable and resumable? I’d love to be able to answer a few questions when I’ve got time, save, and then come back to it later from another computer and pick up where I left off.

If I could save and resume, I would’ve been done with the survey weeks ago. As it is, I had to wait until I had an uninterrupted chunk of time to devote to it.

If it’s important enough to comment, it’s important enough to test

Several people disagreed when I said you should try to write code that doesn’t need comments. I’ll be addressing some of their thoughts — sometimes by saying they were right, but sometimes with constructive suggestions.

I’ll start with a couple of people who suggested that comments should try to explain code that was put in to fix a bug, or to explain the “tricky code” that you sometimes have to write.

Those are both scenarios where a comment isn’t enough. You need an automated test.

Tricky code

The best way to deal with tricky code is by not writing it. But I’ll assume you’re dealing with a case where some manner of tricky code is indeed the best way to get the job done.

Suppose you’re writing a Delphi constructor, and for some reason you need to put some code before the call to inherited Create. (That certainly qualifies as tricky.) Assuming there’s a reason why that’s necessary (and not just sloppiness), you should have an automated test that proves the resulting behavior is correct… something that will pass with the tricky code, and will fail without it. A test that would break if someone else (or you, for that matter) later misunderstood the importance of that ordering, and “fixed” it by moving the code after inherited Create. A test that would pass if someone found a less tricky way to accomplish the same thing.

Bug fixes

If you’re fixing a bug, you should definitely be writing an automated test, if at all possible. That way, if someone later makes a change that breaks the same thing again, you’ll know. As Brian Marick said (and we had posted on our wall for a while), “No bug should be hard to find the second time.”

Then look again

Once you’ve got your automated test, take another look. Is the comment still necessary?

Depending on your audience, maybe it is. As someone else pointed out, if you’re a library vendor, then comments have a lot of value.

But I often find that, with the test in place, the comment can just go away.

Making comments less necessary, part 2

Back when I was a solo programmer and knew everything, I commented my code. I needed those comments to figure out what my own code was doing. They went stale as I made changes, but I kept writing them.

Then I moved to Omaha and started working with a very sharp team. Six years later, I’m still learning. Among the things I’ve learned is that you can eliminate much of the need for comments by breaking down methods into smaller pieces, extracting classes, and naming things well.

When I posted about making comments less necessary, I figured there would be a lot of people who could benefit from that same knowledge, and tips on how to make it happen effectively. But when I read the comments, I found that most of you already know all about good naming.

There goes the next post I was going to write.

But that doesn’t mean I’ve got nothing to say. Stay tuned, and we can argue some more. 😀

Making comments less necessary

Compas Pascal posted about how to comment source code. I would argue that good comments are a poor goal.

Comments go stale. This is tough to avoid. When the code gets changed, the comments don’t necessarily follow. The more comments you put in, the faster they get out of sync with what the code actually does.

There are times when comments are necessary; there are things they’re useful for. But whenever possible, you’re better off writing code that doesn’t need comments in the first place.

There are a lot of ways to do this, so I’ll be posting more about it. Meanwhile, what do you think about comments? What do you use comments for? What do you do to write code that doesn’t need comments?

Visual Studio 2008 Feature Matrix

At long last, the Visual Studio 2008 feature matrix is available.

I was mainly interested in the differences between Standard and Professional. For my own use to play around with at home, it looks like Standard would be plenty good enough: the only thing it’s missing that I find even remotely interesting is Object Test Bench.

(Now I just need to find the cash to buy it, since they refused to honor my certificate that was supposed to be good for employee pricing.)

Things that are only in Professional

  • Object Test Bench
  • 64-bit C++ compiler
  • Crystal Reports
  • Server Explorer (explore remote databases and services)
  • Extra templates:
    • “Database Project” template: a “project template for direct manipulation of database objects and data”. I’m not sure what they mean — what does it mean to make a database “project”?
    • SQL Server Project template (I think this is for .NET stored procs. You should be able to create them without the template, though.)
  • Office 2003 Add-in support:
    • Office 2003 Add-in project templates (Standard does have the Shared Add-in template, but not the Excel-, Outlook-, etc.-specific ones)
    • Action Pane designer
    • Outlook Form Region
    • Ribbon designers
  • Windows Mobile development tools
  • Visual Studio Team System stuff (Microsoft’s test framework, etc.)

Things that are only in Standard

  • MSDN Express Library (the one tailored for the Express SKUs). Is this a typo? They do say that the full MSDN Library is also available.
  • Database Explorer (presumably Professional’s “Server Explorer” is meant to be a superset of this)

Other differences

  • Professional’s installer is supposed to give you more control over which optional components you install. It’s not clear whether this is just marketing-speak for “there’s more stuff so there are more checkboxes”.

Full Visual Studio 2008 feature matrix

Looking at Delphi game development with Asphyre

Delphinian pointed out two Delphi game-development SDKs I hadn’t known about: Pyrogine and Asphyre.

I’ll ignore Pyrogine, since it’s still vaporware at this point — nothing available to download. But Asphyre has some possibilities.

Editions of Asphyre

Asphyre comes in four different flavors, and they don’t try very hard to help you figure out which one you should use. As far as I can tell, though, it comes down to this:

  • If you want bleeding-edge 3D effects, use Asphyre 4.1. It’s not yet release-quality (all they have are snapshots) and it always requires the latest and greatest version of DirectX.
  • If you want something more stable, and don’t mind requiring DirectX 9, use Asphyre eXtreme. It’s billed as their “most stable” version.
  • If you don’t want to require DirectX 9, use Asphyre Casual or Asphyre 1.5.2. Asphyre Casual is not yet release-quality (all they have are snapshots). Asphyre 1.5.2 is an older version and is no longer in active development. Take your pick.

Asphyre eXtreme looks like it’s probably the preferred choice for most applications.

Asphyre license

Asphyre is open-source, released under the MPL.

This makes it a much better choice than (un)DelphiX, which has a license agreement saying it’s illegal. So I’ll definitely be looking at using Asphyre going forward.


The big downside I see so far is that Asphyre clearly wasn’t written by experienced Delphi developers.

  • They don’t throw exceptions. They don’t even return numeric error codes. Everything is Boolean result codes: “it worked” or “it didn’t work”. With a rich exception system just waiting to be used, it’s pretty inconsiderate for them to give such crappy feedback, especially with something like DirectX where poor drivers can make so many things go wrong.
  • They don’t seem to have heard of try..finally. As a rule, they don’t do any resource protection. (This may be because of the previous point, but it’s still pretty sloppy coding style.)
  • They seem to like using global variables to hold non-global state. To take one specific example, the “Basic” sample project, in the Asphyre Casual package, stores form state in a unit full of global variables. Shouldn’t form state be on the form?

Less damning, but just as interesting, is the way they don’t follow common Delphi coding standards. They indent blocks by one space instead of the usual two. They clutter their code with empty parentheses after method calls and declarations. They don’t prefix field names with F. They don’t use FreeAndNil. In short, they don’t seem to have spent any time looking at Delphi code.


Screenshot of the “Shooter” example, from the sprite engine add-on for Asphyre eXtreme

they certainly can do graphics.

New digs

My site is now on a new Web host, and my blog is at a new URL, moving from to (All the old links should still work — I’ve put in redirects — but you still may want to update your links.)

That means that you can again post comments on my blog, and the contact form (broken for so long) should be working again. It also means there’s an actual blog search feature now.

The move was mainly prompted by comment spam. Instead of an outdated version of .Text with cranky CAPTCHA and a custom spam hamster, I’m now running WordPress, which has built-in comment moderation, as well as a plug-in for spam filtering (that I’m not using yet, but probably will be soon).

It’s been an interesting experience. There is no .Text-to-WordPress importer, so I had to make do with some documentation for the MovableType import format, plus a curious mishmash of Delphi code, Ruby scripts, and false starts. (Three false starts, in fact: three times, I imported all of my posts, found something wrong with my import file, and had to delete all of my posts and import again. My biggest complaint about WordPress so far is their refusal to implement a “mass delete” feature: I’ve clicked “Delete”, followed by “Yes”, well over 1,500 times now.)

But the move itself is done, if still a bit rough around the edges. I’m still looking through all the archives to make sure everything looks okay in the new layout. If you see anything that looks off-kilter, like text falling off the right side of the page or some such, feel free to hasten the process by letting me know.

And now that I’m not fully engaged in blog moving, maybe I can actually start blogging again.