They’ve revised the title so it no longer indicates that it’s comparing PowerBuilder 5.0 and Delphi 2.0. For that matter, even though PowerBuilder 5.0 was out (and compiled to machine code) the benchmark tests in the paper were done using PowerBuilder 4.0. Then again, when you read statements that indicate that PowerBuilder is not object-oriented and does not support inheritance, you’re pretty much left saying “there you go again.” (The statement in the paper is that the PowerScript scripting language is neither of those, neglecting to note that a scripting language wouldn’t and the tool does.)

Why bring up that ancient history? Because currently the folks at IdeaBlade are hosting their own “Moving to .NET from PowerBuilder: A Perspective for Client/Server Developers” white paper, which is a “high-level overview of how PowerBuilder developers can migrate to .NET and smart-client development” using their products. (As an aside, in an earlier editorial on whether RAD is dead, I noted how newer products keep comparing their RAD capabilities to PowerBuilder. The IdeaBlade white paper is no different, another indication that RAD is not dead. Even Microsoft, when promoting their latest version of Visual Studio, makes RAD one of the major selling points.

I think it’s always good to evaluate these white papers because they can contain useful criticism, pointing out areas where the product does need to improve. For example, the Borland paper did note that PowerBuilder didn’t provide exception handling capabilities, something Sybase finally rectified in PowerBuilder 8.0 (and wasn’t supported in machine code compiles until PowerBuilder 10.0).

There’s another reason this particular white paper needs a good looking at as well. Few if anybody in the PowerBuilder community had ever heard of Michael Lant (the author of the Delphi hit piece) before his paper came out. That is, there’s no particular evidence that the author of the paper had any extensive experience with PowerBuilder. The IdeaBlade white paper, on the other hand, is written by Sean Flynn, a managing partner at Infinity Systems Group. Sean has been working with PowerBuilder since the 1.0 days, was a member of the PowerBuilder Customer Advisory Board, and has presented at a number of PowerBuilder user groups and conferences. For a while he worked at Riverton and was the principal developer of their OpenFrame distributed business object framework. He knows of what he speaks. That alone doesn’t mean he’s particularly unbiased or impartial. The Sybase newgroups have a small group of former PowerBuilder developers who have moved onto other tools and yet apparently still feel compelled to hang around and convert others to their new tool (or at least bash PowerBuilder). But it does mean that he’s not speaking out of ignorance.

If you’re interested, you can read the white paper for yourself. The following is the main items I gleaned from it.

A majority of the paper appears to be devoted to pointing out the perceived benefits of object-relational mapping tools of which the IdeaBlade product is one. ORMs are popular in the Java development world and are gaining traction in the .NET world. In particular, Microsoft has their own implementations (ADO.NET Entity Framework and, perhaps more interesting, ASP.NET MVC) in the final stages of development.

If you were convinced that ORM was the way to go for .NET, why go with a non-Microsoft implementation though? There’s a good chances that Microsoft’s implementations will do to third-party ORMs what PFC did to PowerBuilder third-party frameworks. As far as PowerBuilder developers are concerned, once Microsoft releases one or more ORMs as part of .NET, Sybase is sure to evaluate how it can be leveraged from within PowerBuilder, much as they are already doing for WPF, WCF, etc.

I’m also not that convinced that ORMs are such a great solution. Part of the argument, at least from the white paper, is that it means that the developers don’t need to know SQL. However, the ORM typically writes rather generic SQL that you would want to eventually tweak before going to production. In other words, it might be a SQL generator, but it doesn’t free the developer from having to learn SQL.

Another argument from the white paper is that an ORM isolates the developer from database schema changes. That might be true for minor changes. I’m always a bit frustrated with the amount of work it takes to update DataWindows because the size of a string column was increased. However, my own experience with ORMs in the Java world is that the objects have to be regenerated or tweaked by hand as a result of schema changes (e.g., added columns) as well. Because of the separation of concerns, there are often more objects in the ORM environment that end up needing to be changed (one for each layer).

Another proposed benefit of ORM is that the objects are strongly typed, which facilitates intellisense support and compiler time syntax checking. I’ll give them half a point for this one. In most cases, it would be quite useful if the PowerBuilder IDE supported intellisense and syntax checking for dot notation references to DataWindow object columns. The downside (and one of the reasons I only give them half a point) is that one of the advantages of the weak-typed approach is that the DataWindow object used in the control can be switched out and the code will continue to work properly as long as the columns that are referenced exist. In addition, if such intellisense (but not syntax checking) is really desired, it can be provided through the PBIntelli utility.

The white paper indicates that the product provides a database vendor-neutral implementation using OLEDB drivers. I’m still puzzling over why OLEDB drivers are used, except perhaps in order to provide that database independence. I’d much rather user “real” .NET drivers in a .NET development environment. And frankly I’m suspect of any “vendor-neutral” implementation. There are just too many differences in the way various databases handle some of the intimate details (i.e., non-intelligent primary keys). I’d rather see an implementation that allows for vendor-specific customization. For example, when you want to support a different database with Ruby on Rails, you do a compile against that database and then tweak the results. You get the advantages of an ORM, but you still get to take full advantage of the features of various target databases.

The white paper argues that PowerBuilder does not promote a strong separation of data access from the UI. I’ll have to give them a full point for this one. The problem in this regard is the DataWindow object. It mixes the data access and UI layers in a single object. I’ve long argued that the Query object should be something we can assign to a DataWindow Object, not something you can base one on and then throw away. More recently I’ve begun to think what we might need is a MVC DataWindow. One that would generate MVC (model-view-controller) objects, but would do so more behind the scenes. The developer wouldn’t need to dig into the details to know which layer the code was being executed in unless they wanted to. That is, we need to get the separation of concerns, but without piling on all the baggage that is dragging Java frameworks down right now.

Another issue the white paper raises is the last of extensibility of the DataWindow. I’ll have to give them another point for that. One of the big advantages in the past has been that the DataWindow is a custom control that is rendered as just an edit mask and a bitmap at runtime. It offered simplicity in coding and reduced system resource requirements at runtime. However, one of the current problems with the DataWindow is that it’s a custom control that is rendered as just an edit mask and bitmap at runtime! There aren’t any hooks that the developer can use to send standard Windows control API messages to it in order to customize its appearance. I’m hoping the XAML DataWindow in PowerBuilder 12.0 will help address that.

There are also several points that aren’t really relevant that should be pointed out. One is that there are a lot of third-party controls for .NET, and not as many for PowerBuilder. Now, while there aren’t many that are written exclusively for PowerBuilder, PowerBuilder can use most of the ActiveX and OLE Automation controls that were developed for Visual Basic. In addition, PowerBuilder 11.0 can use non-visual .NET assemblies in .NET targets and PowerBuilder 12.0 is supposed to provide such support for visual assemblies. The white paper indicates that WPF is coming, but Sybase is aware of that and addressing it in PowerBuilder 12.0. The white paper argues that the Visual Studio IDE is superior to the PowerBuilder IDE. I do believe they do intellisense better. But Microsoft has also opened up the Visual Studio IDE to be used as a shell by third-party vendors, so Sybase can choose to leverage that as well.

So far they’ve made a couple of points, but nowhere near enough to convince me to abandon PowerBuilder. There’s one more issue raised by the white paper that needs to be addressed though. It indicates that PowerBuilder is seen as a legacy tool, and that it is getting increasingly hard to find developers who know how to use it. As someone who is responsible in part for recruiting such developers, the latter does seem to be the case. I think that’s one of the things that Sybase is attempting to address by making PowerBuilder a .NET development tool. The real key will be just how well they do the full on .NET development implementation in PowerBuilder 12.0. One of the main things I’m concerned about is how .NET assemblies are consumed. I don’t think (and have argued here before) that the current approach of including quasi-PowerScript/quasi-C# in a conditional code block that isn’t validated until deployment is really viable in the long run.

I see two options open to Sybase. One approach would be to make PowerScript a full .NET language. The language would need to be expanded to fully support all aspects of .NET. Even so, I don’t know that it would end up attracting attention. I don’t know any of the non-Microsoft .NET languages that really have any traction. The other approach would be to add support for an already established .NET language as a scripting language within the IDE. That means that potential new PB developers wouldn’t need to learn a new scripting language, just a new way to use it. You might be thinking “if it isn’t PowerScript, is it really PowerBuilder?” I think it is. PowerBuilder isn’t PowerScript. PowerBuilder is a 4GL IDE and the DataWindow. PowerScript is just the scripting language we’ve been using for now.