What do you want to see in PowerBuilder 12?

That's not just my question for you this month, it's also Sybase's question for you as well. Two things demonstrate that. The first is the recent invitation to participate in a survey by Sue Dunnell, PowerBuilder's product manager, so PowerBuilder users could "provide some feedback to us as we plan for the next major release of PowerBuilder." The survey may still be assessable by the time you read this at www.zoomerang.com/survey.zgi?p=WEB226LD7N48ZT

The second is a series of posts by Dave Fish, PowerBuilder engineering evangelist, in the sybase.public.powerbuilder.futures.discussions section of the Sybase newsgroups. In those posts, he discusses in broad terms particular areas where they're planning new features for 11.x and 12.0 and solicits input on the direction.
Specifically:
• 11.x enhancements (incremental compile, Informix 10, Vista support)
• Managed Code (including a feature reduced DataWindow based on WPF)
• .NET 3.5 support (particularly LINQ)
• Presentation Layer (support development for WCF, XBAP, and Silverlight)
• Visual Studio Shell (OEM Visual Studio editor for window and DataWindow painters - particularly to support Silverlight and WPF development)
• Language enhancements (interfaces, parameterized constructors, generics, partial classes)
• WCF, WorkFlow, and CardSpace

Dave notes that it can't be stressed enough that these enhancements are currently in the consideration stage and so "this list could change and some features could be added and some dropped from the final implementation."

I've made my own comments in the threads there in the newsgroups, but I'll summarize them here as well. As much as I see the PowerBuilder 11 release as a step in the right direction, there are at least four areas where I believe that dramatic improvement are still required. The other enhancements that are being considered are important as well, but these four are the highest on my priority list. In particular:

Incremental Compile - There are subtle differences in the behavior of a Win32 deployed application and its WinForm and more significantly its WebForm deployed versions. Therefore, debugging the Win32 target is not always useful in determining where a problem is occurring in one of the .NET deploys. Currently we have to do a full compile of a .NET target application after making even the smallest change before we can debug and run it. For particularly large applications, that can significantly hinder developer productivity. We need incremental compile to ensure that the productivity of developing .NET targets is roughly the same as for developing Win32 targets. The sooner, the better.

Managed Code - Web server administrators are very reluctant (to put it mildly) to host .NET WebForm applications that have dependencies on unmanaged code. That current limitation of the product is a significant barrier to small shops that have their sites hosted by ISPs and large enterprise shops that have separate Web application hosting departments that essentially act as internal ISPs. Fully managed code is important for the other .NET target types as well, but it's critical for WebForm targets. Assuming these enhancements are included in DataWindow.NET, it will reduce barriers to that products adoption by .NET shops as well.

Visual Studio Shell - That particular enhancement is of interest to me only to the degree to which it gives us additional features (more powerful intellisense, collapsing code blocks, refactoring, smart tags, track changes, tabbed MDI sheets) without tying up Sybase developer resources. The advantage I see is to reuse something that's readily available and functional rather than try to build it internally to free up developer resources to work on enhancements in other areas of the product. If integrating the shell turns out to require significant resources and might result in reducing resources available to work on other enhancements, then I'm not sure it's worth the effort.

Language Enhancements - I'm not a big fan of PowerScript playing "me-too" with Java and C# as far as language features go. Akin to my arguments concerning the Visual Studio Shell as an alternate editor, I'd rather see Sybase reuse something that's readily available and already provides the features rather than trying to add them to the existing product. In particular, I believe one of the concerns that many companies have with adopting or continuing to use PowerBuilder is the proprietary nature of the language, one of the major features of both Java and C# that modifying PowerScript will do nothing to address. I had a couple of major misunderstandings about what the conditional compilation feature in PowerBuilder 11 was going to be, and didn't realize what it was actually going to be until fairly late in the beta. My original impression was that the code that would be entered between the conditional blocks would actually be C#. I was also under the impression that the result would work not only for .NET targets but also with Win32 targets. The latter impression had to do with what "interop" truly is - interaction between .NET and Win32 code. I'm convinced that what my original impression of conditional compile was is still where we need to be. It's good that I'm able to reference .NET assemblies in my PowerBuilder code. However, we shouldn't need to use a modified version of PowerScript to do it. When I look up documentation on those .NET assemblies, there's bound to be sample code provided to demonstrate how to use it, and that sample code will be provided in VB.NET or C#. A PowerBuilder developer shouldn't have to guess how to convert that into something that PowerBuilder will understand. Let's just open it up so that I can use C# directly in those conditional blocks. Frankly, I didn't find C# all that hard to learn - it's just another scripting language. Similar to when you were first learning to use PFC, the hard part about .NET programming isn't the scripting language. What's hard is sorting through all the classes and methods available and then figuring out which to use and how to use them. Being able to use the results of referencing .NET assemblies in a Win32 target is also an important, and overlooked, enhancement need. I've demonstrated in previous PBDJ issues how to create a COM-callable wrapper for .NET assemblies and use them within a Win32 PowerBuilder target. What we need is the capability in PowerBuilder to create such assemblies and their wrappers and then use them in Win32 targets without having to handle the "wiring" that you have to do today.

That's my list. The question is: what's yours? You don't need to agree with me. But what you do need to do is make sure your own voice is heard. If it's still available go answer Sue's survey. Sign onto the Sybase newsgroups and add your comments to Dave's threads about the future of the product. Sybase is showing an interest in getting user input into the direction of the product like it never has before, and we'll only have ourselves to blame if the product doesn't meet our needs because we didn't respond.