Top ten objections to PowerBuilder
- programmers are too expensive
- programmers are too hard to find
- fat client
- must be installed
- on windows only
- doesn’t run in a browser
- unsupported beyond very soon
- we are a .net shop
- we are a java shop
- power what?????
Top ten real challenges
- The real world thinks we are programmers. We are not perceived as domain experts, diplomats, rapid designers, architects, object orientalists, occasional script typist, testers or analysts…
- PB “Programmers” are hard to find. We are not over the hill; instead we are all hiding in a back room somewhere pretending to be busy supporting the legacy pfc systems that like us refuse to go away. As in: Reluctant to learn java to arm ourselves with a fighting chance of competing with recent engineering degrees from all corners, at half your minimum, already priced to sell, hourly rate. Or maybe working from home teaching our visiting grand kids phrases like “who wrote this darn thing in the first place”.
- 2Tier client server systems are hard to scale and can be painful to deploy.
- 2Tier client server systems have difficulty reaching the cloud where the database has been blown up to save on infrastructure.
- PB can deploy to windows 10, the web and even the mainstream smartphone. The real challenge is that we are so used to developing large applications with a framework best suited for window mdi with a few old controls thrown in and direct access to the local disk.
- PowerBuilder is not on anyone’s radar. If it is, 1-9 of above the top ten applies.
- A framework no longer cuts it. Frameworks used to be: be all/end all; now is more like just; end all. The challenge is to develop a bunch of design patterns that enable rapid, sorry, agile developments of functioning applications, sorry, apps and assemblies/web services.
- Finding a target market for PowerBuilt systems has always been challenging. A long time ago risk adverse financial controllers were reluctant to approve a budget for core enterprise systems using an unproven technology. Today, risk adverse CFOs are reluctant to approve a budget for in-house, bespoke systems using an ailing technology.
- PowerBuilder is extremely feature rich, so there is plenty in the shop, but little in the window and everything is bought on-line anyway. Not sure this a challenge or a strength.
- We need a vision; not a division amongst the few of us left. The developer community appears to be demanding a road-map of more and more features, but as someone pointed out recently, there are too many half-hearted somewhat not quite finished features. Won’t mention the ones that were rudely withdrawn.
(Just as I am about to click Publish, I notice there is a list of Categories I can choose for this blog to help others to find my content. It has one item. “PowerBuilder 15 Beta”. Had there been one called “PowerBuilder 15 Better” then I might have chosen it for this blog)
Lars, Did you watch the PowerBuilder Vision Webcast? What we envision for PowerBuilder should resolve most of the issues you listed. It won't address #4, #6, and #9, but not every single app will be HTML and browser-based as is evident by the proliferation of Cloud Apps for mobile and PC devices.
BTW, in case you decide to watch it or already have watched it, please note there are more detailed Webcasts scheduled for the coming months that will dive into deployment methodology and architecture, development and migration topics, product roadmap, etc. So please understand that the first Webcast was just meant to introduce the big picture and let people digest that first.
I am sorry, I meant the lists to be food for thought for the forum. I use the word "challenges" and not issues that I expect you to resolve
The web cast was great and informative and given your above encouragement I will look forward to the next.
I think what I am trying to point out to the forum is that we all need to think about how we get PB back into the mainstream. Part of the answer is to first understand that there are now different apps for different purposes and they will require different approaches.
Appreciate the food for thought! I hope your post will inspire other members of the PowerBuilder community to chime in, and also encourage more people to participate in our Webcasts. During the Webcasts we conduct very important polls, live Q&A sessions, etc. and the feedback we get is being directly fed into our plans and roadmap for PowerBuilder.
Active participation from the community will be critical to make PowerBuilder a vibrant platform for building the new generation of Cloud Apps (client/server 2.0). I believe this is the new wave after HTML apps, as is evidenced by introduction of technologies such as Apache Pivot for Java, Xamarin for .NET,etc.
The top objections are what I hear from decision makers and those who influence them.
Those sort of objections used to annoy me and I would object and argue to little avail. But that just makes me bitter so now I live in denial.
The second list is merely food for thought for all of us. The raison d'etre for this forum I would have thought. We were similarly challenged 15 years ago when EAServer first came out. It was a a paradigm shift to go from 2 to n-tier as well as learn the new IDE of PB7.
Top Ten used to be a very funny segment on David Letterman. When, particularly in the second list you read something you think is funny, it is not me being weird, it is reflecting my weird sense of humour. You may choose to think I am a bit weird.
The plan being outlined by Appeon for PowerBuilder really can't happen quick enough! Just yesterday I finished the formal training of two new developers in PowerBuilder Classic and so many times I had to point out all the "tips and tricks" to get around PowerBuilder's inefficiencies (both from and IDE aspect and the language itself). It's almost embarrassing, but at least I can pass the blame on to whoever made the decision to use PowerBuilder for our applications since that wasn't me!
Most all of the problems could be taken care of if what is being proposed by Appeon was already in place!
When I train a new developer I point out the advantages of PowerBuilder (the datawindow mainly), but that gets overshadowed by things like the auto-code complete wiping out your clipboard contents, no ability to overload the default constructor, no ability to inherit from a datawindow object meaning multiple have to be created and maintained just to display data slightly differently, etc.
To be honest the PB IDE could be improved and it is true the auto-complete clipboard issue is one of the most annoying issue, but this is certainly not a point that will stop you to develop at all...
For the rest, the PowerScript is easy to learn and powerful enough to develop anything without to have to learn multiples frameworks or libraries as it is the case with Java, Dot net, Python, C or C++.
Concerning OOP, PowerScript is a real OO language and most of the time it follows strict original OO rules, like not being able to overload default constructor. This said, this can be addressed simply by using PB inheritance capability, which again is a pure OO technics...
Finally, the fact than the datawindow can't be inherited is not a big issue comparing the ease of use and its powerfulness, of course it would be great if we could inherit from it in future version of PB, but seriously what language can natively address this issue nowaday ? None.
People that have developed DAO in Java, or any other datagrid control in dot net knows what I want to explain : you have to code a lot in any cases and almost for the presentation layer while in PB you have simply to share a datastore with multiple Dw that take a few minutes to set up, once the base SQL select or data definition is designed.
Definitively, PowerBuilder is still the best Data based Application RAD tool on the market for its ease to develop and maintain application of all size and complexity.
Long Live to PowerBuilder !
Patrice, I couldn't agree more.
In particular "PowerScript is easy to learn and powerful enough to develop anything without to have to learn multiples frameworks or libraries as it is the case with Java, Dot net, Python, C or C++."
Yes DW inheritance would just be icing on an already elegant cake, but not essential. Nothing else has anything like the power of the DW for managing and dealing with data from many sources. Just the other day I was talking to a project manager who was complaining about his developers. He is used to PB and the developers are using Ruby on rails, the developers were procrastinating about how they may load a CSV file and update the database with its contents. OMG, how technology has gone backwards.
Anyway, we all fully understand the annoying issues with PB and it's strengths too! Basically PB needs some investment, I don't believe it needs reinventing, more just taking to the next level. I battle with Visual Studio from time to time and then go back to PB with a smile 🙂 😘
I get annoyed dealing with PB limitations and smile when I get to work with Visual Studio from time to time! 🙂
I am in no way saying that Visual Studio is perfect (no language or IDE is), but no refactor tool? When I rename a variable or class in Visual Studio it politely asks me if I would like to refactor. With one click of a button it does so! When is the last time the PowerBuilder IDE asked you that? It does not, it just tells you that you cannot save until you find all references and manually fix them yourself!
I am not saying that PB is a lost cause, but when no meaningful enhancements have been made in years it is disheartening and only leads to developers like me looking to move on.
By the way, is SAP/Appeon ever going to sign off on moving PB? All this talk about what Appeon will do for PB is great, but it's all just talk so far. Something of substance needs to happen! Maybe that will get covered tomorrow in the webcast?
It is curious, I was thinking about this same issue over the weekend. The datawindow is not inheritable. I mean the datawindow Object, not the datawindow Control. Is this good or bad? I don’t know. The fact is that the datawindow Object resides in a realm different than the common objects used in the language, which is object oriented. And to manipulate it the only way we can do it is by means of the datawindow Control.
We all know how to do this. Is this an issue? Well, if the datawindow Object was meant to be used for a specific limited purpose like some mail control then it is Ok. But the fact is we use the datawindow Object for EVERYTHING. We create input screens with the datawindow Object. We create browse screens with the datawindow Object. We create graphs with the datawindow Object. We create full-fledged reports with the datawindow Object. We create lists with the datawindow Object that mysteriously get attached to datawindow columns inside other datawindow Objects (ie dddws).
And the list goes on and on. Can we do this in PB with common windows controls like in other languages like Visual Basic or C# where everything is an object? Well, some we can and some we cannot. For example, I could implement an input screen with only common windows controls like single line edits, drop down list boxes, checkboxes, etc. and use a button control to pass the values from these controls to an embedded SQL statement that will update the table. This will allow me to inherit the window and extend its functionality like any other OO language.
But of course, nobody with minimum experience with PowerBuilder will do this. We’ll use instead a datawindow Object attached to a datawindow Control and issue an update command in the control. That’s it. Easy to create, easy to implement. But the drawback is we cannot inherit this input screen to form a new input screen where we could add some new functionality. Again, is this good or bad? Well, from my experience working with classes in VB.NET using inheritance can be tricky. You can really get lost with just one inheritance level let along with multiple levels.
But even with this issue to struggle I have found many examples where I’d wish I could inherit a datawindow Object along with the code in the datawindow Control to form a new one where I could just extend its functionality as one piece or component. Or just so I can reuse it within other components. For example, I’d like to have a control that can search for customers in the database which I could reuse inside different input windows (e.g. quote window, purchase order window, payment window, etc).
But I can’t do this easily in PB. Nevertheless, I can do a lot of other stuff with datawindow Objects along with datawindow Controls that certainly will take a lot of time to do in other languages so I think the tradeoff is small and the balance is still weighed on PB’s side for common business applications.
But then there’s the scaling issue. The problem with this so tight coupling between the client and the database via the datawindow Object is that it just doesn’t scale when trying to reach thousands of users. (I know I can use Appeon but this implies additional cost and I see it more as a deployment feature rather than as a programming feature; but a feature nevertheless worth considering).
There’s a saying in my country that goes like this: In the sin lies the penitence. Well, I think PB has sinned too much by depending extensively on the proprietary, non-object oriented datawindow Object and now the datawindow Object is presenting itself as the show stopper when trying to migrate to a web solution.
But I strongly believe this will all change in the new PowerBuilder envisioned by Armeen in which native desktop applications connected to the cloud will present to ourselves as the new technological paradigm finally giving us the benefit of both worlds: Harnessing the full power of both the client and the server with zero deployment effort from our side.
I agree, the IDE in PB classic did not really evolve since PB 7 with the apparition of the workspace concept and the multiple views editors. The shame is that visual studio editor is used in the PB .Net edition since PB 12, and thus such functionality is available there !!!
It sounds odd that they did not do the same in PB classic - why not integrating visual studio editor also in PB classic ? (Appeon seems to want to go in this direction, wait and see...) Ha yes, for mercantile reasons...
Anyway, to my point of view, this is not a valid reason to abandon PB as there exist freeware like Global Replace that will do the job perfectly (even if it is not elegant like in Visual Studio, Eclipse or NetBeans)...
The most important thing to consider while choosing the right language to develop a new solution, is what the chosen language will bring in order to achieve it successfully,in time and without exploding budget. OK, I will certainly not use PB to develop Real Time Air Traffic Controller (C++ for sure, Java maybe ?) but certainly for projects like Automated Warehouse or Time clock Monitor, Bank front-end and back-end, TV/Cinema/Radio Broadcasting Planning Tools, Medical Imaging, etc. are projects that I have worked on with PowerBuilder - built from scratch or maintained during decades quite easily.
of course, decent developer should be aware of what language is surfing the wave during its entire career, but should certainly properly use the right tool at the right time and not necessary the last new "cool" shiny thing available on the market. The older PB application I worked on was developed in 1988 and still used and maintained in 2015...27 years, I think that only COBOL and C/C++ solutions are still running for longer time than that !
Definitively, PB with its PowerScript + Datawindow with an excellent IDE like Visual Studio, NetBeans or event IntelliGent Editor will be the Graal for developing or maintaining data based solutions, surely if Appeon make it also available on portable solution like smartphone or tablet transparently or even natively.
Remember PocketBuilder, it was a great and revolutionary solutions, but it was too ahead on its time, and was a business failure, like Optima++ for the C++, back in 1996.
The software market has also its fashion, like for the clothing, and certainly language like C/C++ and tools like PowerBuilder are classics, like Yves Saint-Laurent, Chanel, Armani, etc.