Actually, the new IDE doesn't arrive until next year. But I thought we could start talking about it now. In case you didn't make TechWave, any of the PB 11.5 road shows or webcasts, you may not know what's planned for PowerBuilder 12.0. There's a lot that they're talking about already (and that in itself is new), but what I want to focus on is the new IDE called WPF Workshop.

One of the big differences from the outset is that the WPF Workshop is based on the Microsoft Visual Studio Isolated Shell. Microsoft makes two versions of the Visual Studio Shell available to software development tool vendors: the Integrated Shell and the Isolated Shell (http://xrl.in/1awu). The Integrated Shell allows software development tool vendors to essentially create plug-ins for an existing Visual Studio installation (if you have a programming language that you want developers to be able to add in and use with an existing installation). The Isolated Shell is intended for software development tool vendors that want to create a tool that installs separately from any existing Visual Studio install and contains its own branding.

The big advantage of using the Visual Studio Shell is that all of the features that developers expect from a modern IDE (collapsing code blocks, intellisense, tabbed MDI layout, docking and auto-hiding panels, etc.) are all available "out-of-the-box." Why does Microsoft do it? Essentially, it's their way of competing with Eclipse. Interestingly enough, Sybase isn't the only major player taking advantage of it. The Delphi folks have come up with a version of their product called Prism that is also based on the Visual Studio Shell, but theirs is based on the Integrated Shell.

Initially, the WPF Workshop will only support the WPF target as well as the .NET assembly and .NET web service target types. Over time, support for the other target types will be added to the WPF Workshop as well.

Another major change is that the WPF Workshop doesn't use PowerBuilder Libraries (PBLs) in the traditional sense. In WPF Workshop, there are "virtual" PowerBuilder libraries that are simply folders on the operating system. The primary advantage of this is that it greatly simplifies source control. Almost all source control products are designed to work on an operating system file basis, which has always made source control integration with PowerBuilder a bit complicated.

The traditional PBL also contained p-code for every source code object that was generated automatically when the source code object was saved. That's why PowerBuilder usually doesn't have to go through a long compile phase when you run or debug the application from the IDE using traditional PBLs; the code was already compiled while you were editing. The downside was that you weren't able to save a source code object if it couldn't compile. With the new virtual PBL, you will be able to save a source code object, even if it won't compile. That's also likely to mean that PowerBuilder will also now require a longer compile time before you can run or debug an application after editing. Or perhaps, like many Java-based IDEs, they'll find a way to do a background compile of the application so you can have the best of both worlds. Only time will tell.

All in all, I'm excited. It's the improvements to the IDE we've been looking for, as well as the "death to the PBL" that a number of us having been asking for a while now. My only complaint is that I would like to see more of the other target types supported in the initial release. I get the feeling working with the old one after experiencing the new is going to cause some struggles or at least having to work with both for a while will.