Visual Studio Vs Powerbuilder

[Former Member]

ok guys,

I have to prepare for a session to a meeting where I have to convince developers to switch from Visual Studio to Powerbuider.

Can you give me 10 good reasons for the mission?

ty

GMY

[Former Member]

Hello Gimmy,

A late answer but my 2 cents:

Pro PowerBuilder (Classic):

1) Visual Inheritance

An incredibly underestimated feature of Powerbuilder that instead cuts development at least tenfold when developing a business application and allows the creation of new framework or usage of existing ones a game like playing with LEGO.

Visual Studio designer is simply ridiculous and broken in this area.

Yes, you "can" inherit a window or a control but the whole events code management will become now completely manual: double-clicking to an inherited button will add the example "Handles Button1_click" to the event and it will now fire twice unless you either manually remove the handler by code or you go back to your base class and take away the Handles from the event (should not do this because otherwise the object inspector won't see the event associated to the object any longer and your base window becomes totally unusable unless you inherit and re-associate all events.

Or you may start to maintain a very long list of RemoveHandler on the load event of the form so that they won't fire twice (may be you have 100 windows from a base class and now you need to remember to go through each of them every time you add an event on the base object.. enjoy)

In little time it becomes a complete mess and it's hell to maintain it as the designer is basically useless and you end up working like in Notepad.

Basically in Visual Studio it becomes like playing with those cars of many years ago that they hit a wall, turn a little bit go ahead, hit the wall, turn a little bit, hit the wall.. recursively without having any clear way to develop a project as you would do in PB.

You'll find that many developers that are used to work in Visual Studio by "HAND" advocate the superior "elegance" and "patterns" offered by those languages. Reality: your project will cost a massive amount of money, you end up an un-manageable bunch of spaghetti code or a nicely,

elegant, beautiful but extremely manually updated code where the designer does little to help you.

Later changes especially affecting multiple places will take way more time.

In PB it is so easy to have a very complex hierarchy of inherited windows, controls whatever you want that you control with ONE click that it really puts the Visual Studio designer to shame.

Overriding completely an event or extending it is again ONE click.

PB makes it so easy that a Junior Programmer can do miracles with it.

2) End User customization without effort

Another under-estimated free feature of PB.

You can distribute your framework and application in PBD and give your users the ability to change

the software without even distributing the source code.

Place an empty library (PBL) on top of your library list and have your end users inherit from any of your base objects (or child object) and save them on the "top" PBL.

Now your end user or local support team can make any changes for a specific client without bothering the main development in the same way you can do an ABAP procedure and customize an existing SAP transaction. You can add this function on any existing software developed in PB.

Note you can do this with VB as well but it's WAY more complicated to do and maintain.

In PB this is embedded in the system without effort.

3) Can't beat working with Updateable "datasets" or "datawindows" in PB

I am not sure how many years Visual Studio has been around but in those many years being able to do an update on a "dataset" with the following SQL:

select * from orders o left outer join vendor v on o.vendorid = v.vendorid

is still impossible (or a very very manual process where you type all your commands, columns, etc manually).

In PB is ONE click on ANY complexity of SQL. You can even update multiple tables if you like with like 2 lines of code (like telling the datawindow which table to update and update).

PB can in addition generate the update optimistically by key, checking each column from initial or by  any column. Again ONE click but you can keep the default if you are lazy 🙂

Sure, you can add some ORM in VS where you may have certain degree of luck but all of them have limitations, produce a laughable SQL syntax (really look at what they generate and you will understand why all of the ORM are slow like snails).

Don't believe the million examples in the Web that say otherwise. They are meant for people that have never developed an application in their life. How many times you had to work with ONE table only in your app. How many times you did not need an Outer Join in your app? Come on Seriously...

And please LAUGH when they tell you that you can do without Outer joins and only use SUBSELECTS.. please Laugh Hard.

4) Report Generation

Any datawindow can be printed without effort with a single line of code.

But of course you can create a datawindow to enter the data and another to print the way you like it and share the data between the two (without another retrieve) in like one or two lines of code.

The report designer is extremely powerful and easy to use.

It's funny how many times you see yourself struggling with a simple task in Visual Studio that comes for free in PB.

In many years I have rarely seen something that the report designer in PB could not do. Printing RTF in a Grid Report without doing sommersaults being one of them for example (but neither microsoft SSRS can do that easily).

5) Drop Down Datawindows

No only in PB showing columns of related tables in the same UPDATEABLE grid is a joke, but also adding a database driven drop down that shows multiple values but saves the FK in the main table is another few CLICKS.

Not that it's impossible in Visual Studio but it's a lot more complicated (especially if you need to display multiple columns in the drop down or a complex view/form)

6) When you get a result set in PB you get also the correct metadata.

This is something that will really make you angry in VB that in PB is given for granted.

A Datawindow will tell you always which table and database column are you in. No matter if you use aliases, no matter if you have tables in joins, no matter even if the same table is joined to itself.

Why should it matter? Because some times it's very useful to take dynamic decisions in so many use cases.

Example:

I am in a Purchase Order and I have the column Vendor. I double click on the Vendor Column and the system opens the

Vendors screen that shows me all information of the selected vendor.

In Powerbuilder I can abstract this functionality at the base object with few lines of code and it will work for

every screen in my application. Without knowing the database column name where my user is (within my form) I will have to rely

on some manual TAG done by the developer at the control level manually (to enter and maintain).

Remember that sometimes the name of the control won't always match the table or column name in the DB when you do it in Visual Studio so you can't use the default names (especially when you use aliases).

7) PB works with multiple DB without the ORM hell.

Yes, you don't need to re-compile or do much in PB if you need to deploy to multiple DB.

You make an app and it will work in Sybase, Oracle, SQL Server (you name it).

Outer joins are converted by PB in the correct dialect automatically etc.

Yes it's not perfect especially when it comes to functions that only exists in Sybase or Oracle but really how long it takes to

do make a base datawindow and say "If DB = Oracle change SUBSTRING in SUBSTR" (it will then replace automatically what's needed on all your child datawindows).

Again in Visual Studio ORM do the same if you want to go to the nightmare of LINQ (for your sake.. forget the hype and use SQL ) or

go to the nightmare that your megapowerful ORM now can't really talk with your report designer as easy as passing a string of SQL

to it cause now you have Object to deal with.

😎 PB application speed when dealing with data

It's FAST. Sorry but I can't see business application built in Visual Studio achieving the same speed given the same complexity

than what you get in PB. And it's not because .NET is slower (probably faster as a language in itself) but the whole mess that

developers need to go through before they can build a business application make the end product sluggish due to the layers and layers

and layers of stuff that they have to produce so that they can save a form. Ah you need security, you need formatting, you need multiple

tables often in outer join, you may need some calculated field and may be some linked screen in referential integrity. Never try

to compare the usual single table no update no insert no delete screen examples in the web. Make it real, download 50000 records

and word with them and please stop talking with people that say that if you have 50000 records on your screen your application

is badly designed cause there are some apps where scalability to 120033040 users is not necessary and you favor "user flexibility".

9) Visual Objects and Non Visual Objects

This is DAMN so easy to do in PB. Really. Combine this with visual inheritance and the combination is really un-matched.

We are talking about few clicks here.

10) Compile today and Compile Tomorrow

Seriously.. you build an app in Powerbuilder 5 and you can probably re-compile it in 12.5 without much effort.

Good luck doing this between Visual Basic 6 and Visual Studio 2010

And it's not that PB did not have any changes between 5 and 12.5 but the changes took into consideration the

work you had done previously and did not force you to a complete rewrite.

Pro Visual Studio

1) Visual Studio is a Multipurpose Development Environment

You can do anything with it. You can build a Game, a Business Application, A console tool, Anything you want.

You can make a windows service, you can program for the web.. Really, not many limits with Visual Studio.

Powerbuilder is definitely relegated to Business Type of applications such as (ERP, Inventory, Procurement, Maintenance

etc) and anything that works with databases but not more.

2) The best Windows integration

It's a Microsoft product. Everything that has to do with Windows Integration works here.

Do not expect any crash accessing OLE, COM, or anything that other development environment may struggle with.

Powerbuilder has improved but can't compete with Visual Studio here.

3) The "Code" Designer is really good

Forget about RAD, but the pure code designer is really some clever work.

Refactoring, Intellisense, Debugging.. everything is fluid and works smoothly and productively.

4) The Documentation and samples available are no match.

You have a problem? Google in your friend and for sure there will be a forum, page, article, blog

or anything else that talks about your issue.

5) Programming for the Web in Visual Studio and PB is like day and night.

Really. PB has gone in circle trying to find his way to deploy for the web

and never found a stable place. Everything else but Appeon nowadays seems to be dead technology in PB

and Appeon is not an option for the average development company.

Deploying for the web should have been embedded in PB long time ago but never made it

(there are solution but not clear where they are going).

Visual Studio has everything you need to make web applications. Now if only Visual Studio had the ability

to work with data as easy as in PB we would have a winner.

6) Amount and Diversity of Components Available

Let's face it. If a company makes a development component, they will first make it .NET/Visual Studio compatible.

A new chart module? .NET/Visual Studio, a new PDF creator? .NET/Visual Studio a new component suite? .NET/Visual Studio etc.

7) Number of resources available in the market

Powerbuilder resources are very few in number compared with what's available for .NET/Visual Studio.

😎 Number of opensource projects

Again, not even comparable with what you can find in Powerbuilder.

Most of the times you can fetch libraries for free that can be used freely commercially cutting your development

cost in case of complex libraries.

9) Elegance of the Language.

No battle here. The standard languages (vb.net, c#) are simply richer, allow stuff that in powerbuilder is just impossible.

like callback functions.

10) Ready for newer operating systems

If you are interested in maintaining the look and feel of the modern operating systems (so that your application

does not look "outdated" in a new O.S.) in Visual Studio you'll find all necessary control to ensure you are "up to date"

in terms of UI.

This is typically way more difficult for PB applications to obtain.

I believe by now I have bored you and probably confused you more than helped you.

Best Regards

[Former Member]

Hi Alessandro ;

  Very well stated and a great summary!

  I would also add a #11 for PB Classic ...

11) The ability to build and deploy Web, Cloud and Mobile applications from the same application source code when adding Appeon to the picture. VS can not do this and you have to completely re-write your applications for the web or mobile platforms. Whereas Appeon allows you to deploy from the same source code.  🙂

Regards ... Chris

[Former Member]

Hello Chris,

Glad you did not fall asleep reading my long comment 🙂

I did not add point 11 because in my personal opinion Appeon is not Powerbuilder although it is born to resolve Powerbuilder's limitations (in a very effective way).

But the same could be said by using Citrix XenApp / Citrix Receiver that allows you to run PB applications on the Web, Mobile without even re-compiling and supporting all of its features 🙂

Both platforms are charged separately and have their own model of licensing (Appeon charges by CPU, Citrix XenApp is concurrent user based).

Both platform don't help a software company to develop a Run Time free application which means that if you sell software you must include in your sales price the Appeon or Citrix XenApp licenses.

This could make your product too expensive in certain markets.

I would personally prefer if SAP could make PB deployment to Web an embedded feature of Powerbuilder without any run-time (it would be incredible if it could deploy to Linux / Apache in addition of Windows / IIS so that one could make a dedicate PB application server completely free on deployment)

As it is, the current external market offering (Appeon, Xenapp) make most sense for a company that has an in house PB application and wants a web solution without going for an expensive rewrite.

My personal opinion of course and won't criticize who thinks differently.

Best Regards

[Former Member]

Hi Alessandro ;

  A good point about the Cirtix alternative. The only major flaw with products like that is that they do not allow you low level device control like Appeon Web and Appeon Mobile does. So as long as you just want a  no device interaction application - then that is a good alternative.

Other bonuses for Appeon though are:

1) 64 bit ready

2) Does not use the PBVM

3) Makes your application multi-threaded

4) n-tier ready

5) fail-over

6) load balancing

etc

Regards ... Chris

[Former Member]

Re: 7 - LINQ

To be clear LINQ is NOT an ORM.  One core thing it really does is provide a syntax that allow you to do "set-based" things in your procedural/OO languages.  In that respect it is similar to SQL and the syntax is (confusingly at first) SQL like.  LINQ = Language Integrated Query.

It is a technology that can be used to provide "ORMish" capabilities:  LINQ + SqlDataSet = "Kinda like an ORM".  I wouldn't use it as an ORM except for the simplest cases.    MS has a real ORM called Entity Framework.  LINQ was used as an ORM because MS had a lot of delays in getting EF working.  LINQ was used as a "time bridge" technology in the ORM area.

LINQ is an incredible tool.  Explore using LINQ with Lambda's on strongly-typed collections and I think you'll be amazed at what it can do.  I finally took the time to learn it myself (I thought it was an ORM before that too) and was able to reduce some of my code (non-database) by 80-90% - I was truly shocked.

[Former Member]

Hello Randy,

I think the clarification is absolutely correct.

LINQ is surely not an ORM but it is heavily used in conjunction with an ORM such as Entity Framework (there are also other implementations such as NHibernate or others)

But, if we look at the history, LINQ was advertised like the best thing after bread and butter (LINQ to SQL) before EF was invented. If you were a development company and went in that direction you would find yourself now having to rewrite the entire DAL from zero or stick with a Deprecated feature.

With most new release of EF like with 6.0 for example, you end up having to modify your code here and there (and re-test everything)... in PB this has been always an extremely rare case.

I see people still struggling with the performances of the generated SQL, struggling with EF downloading the entire content of a table just because it is referenced, struggling with the development environment when really you should spend your time on your business instead.

There are things that are very nice in LINQ such as the fact that it can be used almost on anything not just on databases but also on simple collections and you get the same features.

You can also do very nice shortcuts such as

IQueryable<T>getPage<T> (this IQueryable<T> mydata, int fromrecord, int torecord)

{

   return mydata.Skip(fromrecord).Take(torecord);

}

and be able to do things like:

var mydata =

   from o in orders

   select o.formno;

mydata.getPage(10,20);

This and more only reinforce my opinion that as "pure language" (the typical supported in Visual Studio such as C# or VB) there is no comparison between VS and PB.

But in my experience in VS things get way too complicated when you have more than 1 table involved (despite the beauty of the language)

Not only because we start to get back anonymous classes (that can't be updated automatically)

but also because the syntax starts to be way too convoluted.

I am sorry, I might be getting old but this to me:

SELECT orders.formno,

       vendors.code,

       vendors.name,

       accountcodes.code

FROM orders

LEFT OUTER JOIN vendors ON orders.vendorid = vendors.vendorid

LEFT OUTER JOIN accountcodes ON orders.accountcodeid = accountcodes.accountcodeid

is a LOT easier to read than THIS:

from Orders in db.Orders

    join Vendors in db.Vendors

    on new

    { VendorID = Convert.Todecimal(Orders.VendorID) }

    equals new

    { VendorID = Vendors.VendorID } into OrdersVendors_join

from Vendors in

     OrdersVendors_join.DefaultIfEmpty()

    join AccountCodes in db.AccountCodes

          on new

          { AccountCodeID = Convert.Todecimal(Orders.AccountCodeID) }

          equals new

          { AccountCodeID = AccountCodes.AccountCodeID } into OrdersAccountCodes_join

from AccountCodes in

      OrderAccountCodes_join.DefaultIfEmpty()

select new {

  Orders.FormNo,

  Code = Vendors.Code,

  Name = Vendors.Name,

  AccountCode_Code = AccountCodes.Code

}

Not to mention that the second script requires to have the DB generated in some kind of model (with references etc)

And.. I only joined 2 tables :-).. in a real application you can even have 10 or more joins..

Plus in Powerbuilder the first script can update any modified table / record really with one or two lines of code,

With Visual Studio one ends up having to make all the updates, inserts and deletes commands manually.

I know a lot of people that prefer to do things manually because they say they have more "control" or may be we can remember plenty of people working in Visual Studio used to advocate strongly the use of Stored Procedures (because they really had no other choice).

Me, I am for getting the job done fast (that does not necessarily mean making a bad job).

Seems I am bashing VS but I am not. I think that for anything else beside a Business Application working with data, Visual Studio is really fantastic.

[Former Member]

Hi Alessandro,

You have good points.  I went from two pure PB shops to a MS/PB shop and there are tons of things PB does better - it's really data focused.  I missed a lot moving away.  Yes, that second example makes me cringe.  My skills are balanced between database, mid-tier, and GUI, but I mostly and architect and management.  Have to say when I look at either example or any code non-db (including LINQ) that says "SELECT" I have a little panic reaction

Fast is where it's at.  Things change fast and "building to accommodate [possible] change" is silly in my opinion.  For a basic data-centric application used in-house I'd rather build it simply client-server from scratch three times in three years with PB (2 months to build and use it for 10, rinse and repeat) than build one "bullet proof" n-tier app over 12 months and then be stuck with it for two.