There has to be a better way

IT News & Views

Subscribe to IT News & Views: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get IT News & Views: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IT News Authors: Joe Austin, Satyen Vyas, Elena Yakymchuk, Jim Malone, OnPage Blog

PowerBuilder: Article

Top 10 Features to Remove from PowerBuilder

This month I want to take a different approach and look at the top 10 features that Sybase should remove from PowerBuilder

Two months ago I discussed what I thought were the top 10 features that should be added to PowerBuilder. Last month I discussed some of the new features that Sybase had indicated would be incorporated in the recently announced PB version 10.5. This month I want to take a different approach and look at the top 10 features that Sybase should remove from PowerBuilder.

Why remove? As PowerBuilder has evolved over the past 10 years its feature set has become very broad. Some of those features have been superseded by other functionality and some may no longer be as useful as they once were. In addition, Sybase has limited resources to work on new features and bug fixes. I'm concerned the effort that could be used to bring us new features and bug fixes that we urgently need may be currently used to maintain features that are not of significant benefit to the majority of the user base.

The idea is to look at the feature set and determine which features are now "deadweight" that we could easily live without. Or another way of looking at it is to consider some new feature that you would really like to see implemented (e.g., a treeview presentation style or autosizing non-detail bands for the DataWindow). Then look to see which features of the product you could live without if it would help ensure that the feature you wanted got in.

In other words, there's a trade-off involved. It's like the old saying, "you can have it on time, under budget and bug free...pick any two." The Sybase development team has to make choices about what to do with limited time, and I'd rather see it focused on new features we could really use rather than on past features that we no longer need.

With that said, here are my choices.

1.  Automation server

2.  COM/COM+ component generation
COM is dead, or at least dying slowly. Further, I don't know of anybody who is using the automation server capability. If there ever were, I don't think there were a lot of them. Some people may be using the COM capability to deploy to MTS, but once again as far as I can tell not many. I can't think of any other significant use for that particular functionality.

3.  DataWindow Web Control for ActiveX

4.  DataWindow plugin

5.  PowerBuilder Window plugin

6.  PowerBuilder Window ActiveX
Sybase needs to find a couple of good ways to create Web applications with PowerBuilder and focus on those. I'd suggest JSP and XML DataWindows (and the ASP.NET compiler that's coming). Jettison everything else. The others aren't complete solutions and having too many partial solutions (and no one complete solution) just confuses the user. Also, if someone tries one or more of the incomplete solutions, it may leave them with a bad taste in their mouth for all of the solutions. Pick a couple of methods and make them work correctly and drop the rest.

7.  Machine code compiles
Let's face it. I haven't seen an application yet that warrants a native compile. I find it hard to justify the minor improvement in performance against the amount of time it takes to do a native compile. And consider now that the two most popular (at least in buzz) development methodologies out there right now don't do native compiles. Or at least they don't do them until runtime. Nobody cares about native compiles any more.

8.  PowerDesigner integration
Yes, sorry to say it, even if it was only recently introduced. I don't know that a significant number of people are actually using it. I'm afraid it's up there with PBNI. I could probably count on both hands (and perhaps a foot or two) the number of people outside of Sybase who are actually using PBNI. (Using in the sense of writing objects. Many more people than that are using PBNI objects, they just aren't writing them.)

It also goes to something I've recommended before. I'm looking at this from 30,000 feet, so what I'm saying may not actually be feasible. It's just that as far as IDE extensibility goes, I would rather PowerBuilder be brought into an IDE that is already extensible (VS and Eclipse). Otherwise the development folks come up with an interface that is PowerBuilder specific, and will probably be used as rarely as PBNI and the PowerDesigner plug-in are now.

That is, keep PowerDesigner integration, but do it by integrating PowerBuilder into Eclipse and both products into VS. Either that or drop the whole IDE extensibility thing altogether. It's a nice idea, but it's way down on the list of "must haves."

9.  PBNI
Gasp! The problem is that there are so few people using it. You'd keep it around, but not bother to try to support it for external use (or perhaps on a "partner" basis). It just requires too much C++ knowledge for most people to make use of it, except when folks who do know enough C++ make something and then make it available for others to use.

I'm also wondering (at the 30,000 foot level again) if some kind of Interop support might make PBNI mute. That is, if folks could create something in .NET and then call it via interop from PB, I don't know if we would need PBNI anymore.

10.  Fill in the blank
Well, I ran out of steam at 9, so the 10th item is up to you. Let me know if you agree with this list, disagree with this list, and what feature (or features) you would add.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services ( A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.