PowerBuilder Webcast – High Level Road Map
** Hot News **
In case you missed the High Level roadmap for PowerBuilder Webcast on Tuesday March 8, 2016 – you can view the recorded Appeon presentation here …
HTTP://www.tinyurl.com/newroadmap
Regards … Chris
I noticed one of the roadmap items was to remove the PBL.
Can I assume Libraryimport and SetLibraryList would still work as we need to be able to create/amend dynamic reports and child reports at runtime?
Otherwise roadmap looks promising.
Cheers Michael
Hi Michael;
Not only that ... PBL's actually contain two class items ... a) source and b) compiled P-Code. Its the latter P-Code feature that allows PB Classic developers to save & run immediately instead of waiting and waiting for interim compilations to occur before being able to test / debug. This is one of the key features of PB Classic features that Appeon (IMHO) does not want to "monkey around" with.
Also, when dealing with Source Control Systems ..the PB Classic IDE always exports object class source code anyways to flat files and then sends them to the SCM. In reverse, the SCM always returns object class source in flat file format which the IDE then imports. So why would removing PBL's help .. personally, I have no idea. 😕
FWIW: I hope that Appeon really analyzes the remove the PBL enhancement properly before proceeding and just fixes the SCM interface - which I think is the real problem - and not remove PBL's from PB Classic. IMHO this enhancement would be a total waste of precious engineering resources - much like PB.Net. There are a lot more important enhancements to focus on IMHO. 😉
Regards ... Chris
Hi Michael,
I didn't here anything in the webcast that feels like it will not be possible to create datawindows dynamically in future.
I really hope they will delete SetLibraryList and LibraryImport in future versions because it does not make any sense without PBLibaries. Keeping the framework clean is good practice to let new developers learn PB fast.
If Appeon focus on all the old bloated solutions and a 100% migration path. All these webcasts are for nothing.
best regards
Benjamin
Hi Benjamin;
You are absolutely correct ... many mission critical reporting PB applications here in the Canadian Government create PBL's, change PBL library paths and dynamically create object classes "on the fly". Removing PBL's from PB Classic would destroy this long time and key functionality. 😥
Great point for Appeon to consider IMHO! 😕
Regards ... Chris
I think their reasoning is that you would be able to use source control systems and text search/edit tools that do not support the SCC API.
There are a number of issues like what Chris said that need to be figured out they can move forward with that idea.
One I know of is that the application icon and global font settings are currently stored in a hidden binary object in the pbl, not in the source code of the application object.
Another great point Roland on all the related properties are not stored within the Application Object Class' source code! 😳
I would also like to add the Library list. Many PB developers use a TEMP like PBL in the library list to house "test" based object classes. You can work-up some object changes and place the duplicate (potentially higher version) objects in the Temp.pbl which is 1st in the library path. When the application runs, the PB Class Loader picks the objects in order of the PBL library list. This is grrrrrrrrrrrrrrreat way to test potential object variations before checking in you source code.
FWIW: My STD Framework makes use of this PBL Library list feature.
FWIW: Most of the reasons that people look at Non-SCC compliant SCM's is that many of the SCM's out there today are way over priced for the smaller IT shops. If Appeon shipped an integrated SCM with PB out-of-the-box - then I think that would curtail the need to look elsewhere.
Maybe you can make a deal with Appeon to ship your WizSource SCM as THE standard SCM with Appeon PB - like ObjectCycle was before!!!!! 😉 😉 😉
I cross my fingers that they put the PBL where it should be since years.
To the trash can!
Consider to realize big projects with Visual Studio and C#. You build your components, use pre-compiling, you will not miss your PBL.
I cannot count how much productivity was wasted in incosistent PBLs. This includes the searching for "ghost" errors and recompiling whole solutions (with hundreds of PBLs).
You can add to this black whole the issues with out-dated SCC-compatible plugins and the time it costs to check-out/check-in, import and export etc.
Please let it go!
I just had the same issue with VS2013 ... and it crashes the VS IDE really bad! There was no way to recover either ... so much for external source code files. I had to rebuild the source file by file as VS would crash when even trying to open the Solution file - never mind anything else.
So much for TFS either. You should see all the VS & TFS problems we have to deal withthese days (MS patching TFS weekly now for 9+ months). TFS - what a P.O.S. (french for lackluster product). 😉
VS is a piece of fundle duddle when its control & source code files get hosed by its own SCM and or O/S! No better than PB Classic's PBL's IMHO. 😡
Hi Chris;
I never made this experiences. I am working with Visual Studio and TFS since years and I love it.
But, and this is my point, for example, Microsoft killed VB6 in the 90's and replaced it with .NET and they gave a bit more than a *ups* on migration path.
This was the right decision!
I am still posting here because PB belongs to my skillset and I love the idea to have a specialized technology to build database oriented business applications.
But, if Appeon starts to think that a community that is not flexible enough to think about a PB without PBLs is the peer group, the product is finally dead.
FWIW: I look at the PB Classic IDE as its own encapsulated world. Based on the definition of encapsulation - the outside SCM world should not care how the IDE stores & manages its own internal resources. If everyone says PB is dead because it uses PBL's then IMHO that is a pretty ignorant statement.
In the long, long term I have no resistance to dropping PBL's if it makes business & technical sense. However in the short term (even within the 5 year spectrum) I can think of a lot more enhancements that need to be done to PB vs the removal of PBL's (very low ROI).
FYI: Just activate native PB Source control and you'll see PB create all the classes as flat files. Maybe the fix to the outside SCM world is through a modified native SCM approach vs rewriting the PB Classic (and InfoMaker) products to use something else which does not give developers any ammunition against IT management and business users who need O/S and GUI improvements now!!!!!! 😉
Agree, but this was not my statement. My statement was: PowerBuilder is dead if Appeon will try to make everyone happy and to implement a migration path. They should try to place PowerBuilder back in the market, there is the money to earn.
No hard feelings, we have different positions, good fight 🙂
Killing VB6 was a Microsoft business decision. I am not sure what "right decision" means in this case.
From the perspective of VB6 shops, why change perfectly working code just to be able use the latest compiler?
C/C++ code older than VB6 can run unchanged in side by side with newer modules with lambdas and type inference - that's another approach to "migration path".
Yes, it was a business decision. It was the decision to invest the (limited) resources to create a new software generation (.NET) and not to care on mirgations paths to much. IMHO: This is the right approach.
From the perspective of a VB6 shop: You don't have to. If you don't see any benefit moving to .net, stay on VB6. Don't upgrade only to use the latest compiler, nobody would do it.
C/C++ is only the language. It has nothing to do with a complete technology stack like PB or .NET. You are right your "hello world" will run from the first version until know. But if you have external references like Windows API or you want to compile to 64bit with a lot 32bit pointer in your code, you are on your own to migrate it.
BTW: This is the same point in .NET. You can run your old .NET 1.1 code, but if you have deep references to the .NET Framework you (maybe) have to migrate and change your code.
"From the perspective of a VB6 shop: You don't have to. If you don't see any benefit moving to .net, stay on VB6. Don't upgrade only to use the latest compiler, nobody would do it."
That's the point, they can't even upgrade, it's been killed.
Hi Frederick;
yes, and they killed floppy discs because they don't fit into cd drives.
Edit:
Petition to get VB6 back? What's next? Petition to get a new season of MacGyver?
You made my day 😆
best regards
Ahhh...analogies...
Was there ever a version of Excel that couldn't read documents created by the previous version?
Did you every try to put your COM port mouse to an USB port?
A mouse I can simply buy a new one. A VB6 application that took years to develop and has years of bug fixes checked in, how do I get that into VB.NET?
I am sure the CEO of the com port mouse factory had the same idea. If he was a smart CEO he reserved some money to make a team of engineers to design a new mouse model with USB plug. If his approach was to crossing fingers and pray for a compatible mode in USB to COM, maybe his factory is a wall-markt our a lasertag arena, today.
Actually there is a new MacGyver show in development.
Yes, I heard that too on the INNERSPACE TV program the other day! 🙂
There is a VB6 petition.
Bring back Classic Visual Basic, an improved version of VB6 – Visual Studio
But no .NET 1.1 petition.
Because it' not the same point.
Frederick, in the link you posted we can see that the petition was declined. And the reasons are very well put out. In fact, it strikes me how, if you replace the words VB6 for PB Classic and .NET for PB.NET you'll see that it applies perfectly to our case, with the only difference that PB Classic does not come bundled with Windows. So, I'm with Benjamin on this one. PB most evolve and adapt to new technology if we want to address new business demands. And if this requires work from our part so be it. I'm sure it will be well rewarded in the future.
Not perfectly.
Like Delphi (or whatever it is called today), PB continued in both native and .NET directions. So we got "PB most evolve and adapt to new technology if we want to address new business demands." covered.
Delphi eventually abandoned .NET as part of a business decision.
Microsoft imposed their choice on their customers.
So it is not simply about " evolve and adapt to new technology if we want to address new business demands." but about how your attitude towards your customers.
Microsoft''s C/C++ customers were luckier.
The need for some people to migrate to .NET was not covered by PB.NET. It was a good effort but was incomplete, with performance issues, and various bugs. I tried it myself migrating one of our applications and testing the IDE and found it not ready for production. And I believe this is the reason for the low adoption of the platform. (And not, as some believe that people are not interested in .NET). In the first webcasts Armeen made it clear that .NET was the direction to go. But he realizes there’s a big customer base that relies on PB Classic and so he is working on keeping the platform alive while still addressing the .NET market. And there may be good technical decisions why PB Classic shouldn’t die. But in the end he has to make a business decision. And we should be grateful that from what I see his business decision includes both Win32 and .NET development. Because in the end is not about Win32 vs .NET but about Desktop apps vs Web apps vs Cloud apps, the new business demands, which could be addressed with both technologies. But if not he’ll have to choose and concentrate on the one that has the most promising future. And we’ll have to adapt to it if we want to continue servicing our own customers.
The reason I responded to your first post was because you said you were with Benjamin who thought killing VB6 was (to quote him) an unequivocal "the right decision!"
Now what you are saying here about PB Classic (that it is a good thing that Armeen is keeping it alive) can just as well apply to VB6. So I am not sure what point you are making.
If PB Classic can be made to allow us to develop web and cloud based desktop and mobile apps then I’m in favor of keeping PB Classic. But if the only way to address these types of applications is by migrating to a .NET based PB then I don’t see the reason to keep it when a decision has to be made due to limited resources. I’m unaware if Delphi allows the creation of web applications and or cloud applications given that they’ve dropped .NET as you mention. If so it would be a good case in favor of keeping PB Classic.
There is another reason for keeping Classic alive. People who want to continue writing and maintaining applications for the desktop.
I don't understand this "I believe the product should be this way, if not, kill it even if other people need it" logic.
If the vast majority of paying customers want to continue with PB Classic for desktop only, killing it because you think being .Net only is cool would be committing business suicide.
Microsoft was only able to kill VB6 because it was a very minor blip in their revenue stream and they wanted to force developers into .Net which was still in it's infancy.
PB.NET was built so you could write desktop applications. (In fact, that’s the only thing you can do besides creating .NET assemblies and web services. There is no functionality in the product to build web applications). People can continue writing and maintaining desktop applications with PB.NET. Now, the new PB that Armeen envisions is based on the native version of PB where traditional 2-tier client-server development will be maintained and with new n-tier desktop cloud and mobile cloud app development on the way. .NET interop and .NET development via UWP are given the last priority. And Appeon will continue to be the means through which we can deploy applications to the web.
So, I wonder why we’re discussing if PB native should survive or not. Benjamin used VB6 as an example of not worrying too much on migration path, referring to the PBL issue, but then the discussion turned into Native vs .NET. But I agree with him when he says that we should be flexible enough to accommodate changes on current features that we might think right now are indispensable but will prove later not to be and after a while we’ll start to think why we embraced them so much. I’ve worked with Visual Studio (VB.NET) and yes, it takes time to compile but I was able to live with it and never had a broken project or file. But of course, there must be strong technical reasons to do this and FWIS source control compatibility is one of them.
Your point about the defects of PB.NET causing low adoption is correct but is beside the point because it is not being killed and according to your own post, is going to be given a new form by Appeon.
I am sure doing the equivalent of killing VB6 (abandoning PB Classic and moving resources to PB.NET) would have improved it but not everyone would agree that it would be "the right decision!"
I repeat that we are not alone in keeping native while attempting .NET. Delphi did. So doing the equivalent of killing VB6 to move resources to new technologies is not a slamdunk case.
"And if this requires work from our part so be it. I'm sure it will be well rewarded in the future." Shouldn't a customer-oriented organization also recognize that not all customers want or have the resources to do this?
It's time to drop one of my favorite quotes of Henry Ford.
"If I had asked people what they wanted, the would have said faster horses"
Not the first time in this community, but there is so much truth in this single sentence.
Good quote but wrong context.
Given a choice between horses and cars people chose cars.
Given a choice between native and .NET, Delphi customers chose native.
Only a company that creates it's own gravity like Microsoft can impose it's will on customers.
But not PB, not Delphi.
Company proposes, customer disposes.
A customer oriented company doesn’t have to be a company that relies solely on customer demands when making business decisions. It’ll be doomed from the start if it does that. It has to also consider new trends in the market and changing technology and design new products that customers don’t know they need right now but which will become essential to them in the future. They may recognize some customers won’t be willing to buy the new product but that’s a risk they’ll have to take. And if they were smart enough to foresee the future they will be well rewarded. For my part, if I see that the product helps me address my own customer’s need I’ll make an effort to use it and adapt to it.
And your philosophy is exactly the one adopted by Delphi. That's why they introduced .NET to Delphi and stayed with it a fair amount of time. But ,NET in Delphi went the way of horses and New Coke.
The choice is between an old paradigm and a new one. Not between two new ones. .NET is the car (new paradigm) and PB Classic the horse (old paradigm). So Delphi people actually chose to keep riding in horses.... but maybe the car was not ready for mass production.
Should FORTRAN programs be converted to something written in new paradigm languages?
Maybe for some.
So those who stay with FORTRAN, are they choosing horses?
The Delphi people are as smart as anyone here and behaved like anyone would. They made their decisions based on their own priorities.
Suppose there were 2 different new versions of Excel. One version could read existing Excel documents. The other required work on those documents before they could be read. Both had new features.
Some may like new paradigms. Others just want their problems solved the most economic way. They know what they are doing. There are many applications today running on the desktop using languages and API's that predate .NET that are continually being updated, that has old ancient unmodified code in "old paradigm" side by side running with new code with new paradigms.
The VB6 decision was made based on trade-offs centered around Microsoft's interests. Delphi decided that customers were different from each other had different trade-offs to consider - and left the choice to them. Eventually they discovered there weren't enough of those whose trade-offs favoured .NET.
Nothing wrong with cars of horses. Different people have different considerations and priorities.
The Delphi .NET implementation was excellent but hobbled by the need to make upgrade from native versions easier. Most of the discussion was on how to move their native code to the .NET version. There was no work required to upgrade to the new native version which also had new features. .
"...but maybe the car was not ready for mass production."
I have another maybe - maybe most saw they could have new features they needed without extra work and chose that option.
Company proposes - that's the part where the company tries new things, even things customers haven't thought of, and often times the company takes big risks here.
Customer disposes - that't the part where customers decide if they want the product.
I see we are in agreement here.
Killing VB6 - you only do that if you are big enough to lose customers for an entire product.
For Appeon and Powerbuilder is more to win than to lose.