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 · Accepted solution]

So, let me start off by saying that you're in an unenviable position: trying to convince Visual Studio lovers not to use Visual Studio. "You know what you love, and you love what you know." I'd suspect that this is akin to convincing them that the table you're around doesn't exist, the chairs they're sitting in don't exist, and they're actually naked in a vat of goo (xref The Matrix).

You haven't given us much to go on in terms of what the project is. It's hard to argue what the best tool for the job is without knowing the job. For some examples, if you project involves any of the following as a primary component, I'd argue in favour of Visual Studio:

• Console application
• Sharepoint integration
• Office plug-in
• WebForms (OUCH!! Too soon?)

That being said, here's some generic arguments:

• DataWindow (all features below come built in, with little or no coding required)
  • single object can be used visually or nonvisually
  • dynamic sizing / positioning of controls based on data
  • dynamic modifications of almost all UI attributes either based on data (expressions in attributes) or based on run time conditions (Modify(), although expressions can do this too)
    • e.g. alternating background shading between rows takes a one-line expression; I've seen an article that suggested it took 2-3 pages of code in .NET
    • e.g. each row can have a distinct UI based on the data (e.g. walk-in customers can show a different UI than shipping customers, all integrated into a single list)
  • WYSIWYG printable, or run-time-modifiable for printing (e.g. add a page number footer)
  • SQL injection prevention / input sanitization
  • Null argument handling (e.g. "CustId = :custarg" gets translated when arg is null to "CustId IS NULL")
  • Minimal SQL creation on updating databases (e.g. doesn't update columns that haven't changed; often not the case when programmers build their own SQL)
  • strong field formatting and validation
  • controlled retrieval of large quantities of data
  • disk-cached retrieval of large quantities of data
  • handling of identity values
  • conversion of database errors to events
  • ability to monitor, intercept, modify or cancel generated SQL at any time
  • ability to export data to many formats
• PowerScript
  • probably the easiest sell to this audience is quoting the Appeon Pet Store Lines of Code study

And so you can start thinking about responding, with my clients recently, the most compelling argument against PB (at least that I have a hard time arguing against) is the lack of available, active talent. If they can't* hire people now to code the system, or in the future to maintain it, they're painting themselves into a corner. (* "Can't" doesn't have to mean impossible; it can just imply high cost or effort.) This isn't to say that SAP couldn't possibly turn this situation around by changing PB's position in the market (imagine if every SAP installation needed a team of PB developers for customization?), or that .NET's position is secure (many think Win8 / WinRT was a body blow to .NET). However, hunting for bodies today, this is the situation managers face.

Good luck,

Terry.

[Former Member · Accepted solution]

Hi Terry;

I must say ... "Very well put"!  

  Personally, I have tried this scenario over 5 times in the past many years and seen many others attempt this feat. The outcome for me is PB - 0 and VS - 5 and the same for the few others I have seen attempt this change in IDE argument. Add to your VS list: integrated testing, integrated SCM, integrated SSIS reporting, proper support for SS2012, etc and you pretty much wipe PB out of the game from the VS developer's perspective. Now add proper support for ASP, Windows 8, Windows Mobile .. etc and you would be better off defending yourself against a pack of wild dogs IMHO.At least the chances of survival might be better.  🙂

  So let me also say ... "you are in an unenviable position: trying to convince Visual Studio lovers not to use Visual Studio"! 

  Now, can SAP turn things around ... Hmmm - no road-map, no PB 15 (maybe 2014 now), no change in management, maybe no PDC this year, no PB Classic "how to videos", retiring / no longer using PB resources, no support for education from major ED centers like Learning Tree, etc and I doubt whether SAP is in a position to effect any PB change in 2013 .. just my impression FWIW..

Sorry to be so negative! While I am personally super productive in PB - especially adding Appeon Web & Mobile to the mix - this is "hard sell" for VS developers who have grown up into IT through college & university using VS.

Regards ... Chris

PS: Good Luck anyway!  

[Former Member · Accepted solution]

Hi Terri,

Well said.

I'm assuming the discussion centers around PB Classic and not PB.Net since PB.Net uses the VS shell.

Disclaimer: I'm not VS expert by any stretch (yet) but I do use both environments daily. I suspect the VS experts Gimmy works with would have some rebuttal to a few of the suggestions. Here are a few I would be leery of  mentioning (in my humble opinion of course).

Dynamic sizing or positioning of controls based on data can easily be controlled in XAML by specifying "Auto" as the width and/or height among other properties.

Any property can be modified dynamically at runtime in VS as long as it is a dependency property (which most are) via the binding mechanism in .Net.

To alternate the background color of a datagrid you add this property to your XAML: AlternatingRowBackground="LightBlue"

To make it alternate every other row's color you add this property in your XAML AlternationCount="2"

Not exactly 2 or 3 pages so I wouldn't make this argument.

I think SQL Injection can be a pro or con either way depending on how queries are written and what tools are used (LINQ, EF etc).

Minimal SQL creation can go either way too (Garbage In Garbage Out). If and ORM is being used it is probably creating the best (but probably most obfuscated) SQL.

The field formatting and validation is fast and easy in PB but I've found that the functionality in VS is much more powerful and extensible if using data annotations. The ability to create custom validations, use regex expressions, localizing error messages, and code sharing across server and client make it very powerful.

Regarding your negative experience with attracting PB talent we've actually seen just the opposite here of late. We've found it is much easier to find local PB talent than it was a year or two ago. This doesn't make it a negative for PB but a push.

The biggest and most important advantage PB has over VS is the reason it is still around and the reason we still use and support it. It is far and away the best and easiest tool for Rapid Application Development (Bruce's #4). IMHO All other reasons pale in comparison. I am an order of magnitude more productive in PB than VS. I've been doing PB a lot longer than VS but that is not the entire reason. I would surmise that if two equally skilled developers went head to head the PB guy/gal would win. I would also warn that if you lay down that gauntlet you better be ready to back it up.

Anyway just my 2¢

Mark

PS Too soon

[Former Member · Accepted solution]

Hi Chris;

I am with you. I would add to the VS list

• Entity Framework with Code-First-Model
• Intellisense
• NuGet

Hi Gimmy;

If you want to argue with the DataWindow, keep in mind the VS guys have Databinding. You can bind fields on different Tabs, Windows and Views to one Datamodel without feeling bad if you want to add a new field. With the concept of bundling data and view in one component, this flexibility isn't reached.

[Former Member · Accepted solution]

Hi Ben;

  Some more excellent points to ponder!

  IMHO .. if Sybase had spent 1/1000th of the R&D effort on PB Classic's AutoScript feature vs PB.Net - the AutoScript feature could be like Intellisense, delivered way sooner and been a much better ROI!

Just my $0.02

Regards ... Chris

[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.

[Former Member]

I don't think the question is actually correct.  Visual Studio is an IDE - it has no "language", so if you don't switch to VS you would switch to something like C#, asp.net, or something supported within VS. 

We use PB, .Net (C#/asp.net), and Java but have been moving away from PB.  The move is a lot easier from PB to Microsoft then from PB to Java for PB developers.  Five years ago I would say PB had the edge over .Net but that lead is far gone in my opinion.  VS2012 just rocks with features and .Net is a tier 1 platform.

My biggest concern is the same as some other's which is the lack of direction or seeming commitment to the Sybase products.  I use PowerDesigner extensively and it has become almost useless in many areas.  e.g., .Net is at version 4.5 and PD only supports up to 2.0.

When it comes down to it though in my experience the cost of change should be the greatest concern.  I just can't imagine switching to PB at this point with so many concerns around support, resources, and a product roadmap.  If you had a large product portfolio in PB I might say stick with it for a while and see what happens, but I think it would be pretty hard to argue for a change.

Be careful you don't get slaughtered by the VS/.Net advocates if you don't have all of the details nailed. 

[Former Member]

As I don't really know Visual Studio, I did a very personal list of PB Native (classic)

pros and cons, so that everyone reading it can compare and contrast his favourite

development environment with Powerbuilder. I currently use PB 11.5.1.

(I'm not considering PB.NET here because of its poor performance and long-term strategic issues)

Pros:

    RAD GUI development

        Very fast, very easy

    In-depth help with examples to get you started

    SQL development, with visual query tool

    MDI applications

    Datawindow

        Simplicity

        Powerful builtin commands (easy insert/update/delete )

        Good performance even on millions of records

         Takes care of all problems and returns a simple error code

    Reporting

    ETL with pipelines

    Client/Server Development (especially ODBC over LAN)

    Built in debugger, even if it's quite old

    High level and open handed community

Can't really do:

    Linux

    Manual memory handling (pointers)

    Multithreading

    Builtins for Lists, queues, B-trees of any datatype that doesn't fit in a datawindow

    Interfaces

    Templates

    Lambda functions

    Operator overload

    Embedded programming

    Drivers development

    Real-time computing

Can't do without tools, still being hard to very hard to work with:

    Web ( Appeon Web uses .NET and Java on IIS and costs x000$ )

    Mobile  ( Appeon Mobile costs x000$ too )

    Fast heavyweight string manipulation ( Novalis uses C++ for Enable )

    Regular expressions (Sébastien Kirche uses C++ through PBNI, I use JScript )

    Callbacks (PBNI C++, PBInvoke)

    XML parsing ( Datawindows are limited to 2 levels nesting, PBDOM is C++ )

    Runtime object serialization / deserialization (We've done it in JS.NET)

    Console applications with access to StdIn and Stdout ( C++ through PBNI )

    Dynamic code execution ( see www.embeddingperl.com, PBNI, Perl or VB/JScript needed )

    User level reports creation ( like Crystal Reports or the one from Novalis )

    Custom controls (C++)

    Modern graph controls for BI reports ( Crystal Dashboard, HTML + JS + CSS)

    OpenGL (PBNI C++)

    Early bound COM (QueryInterface())

    Sockets, FTP, SMTP, SSH

    Web services (requires .NET)

    Image library ( plot, filters, SVG )

    Windows Event Log

    NoSQL databases

    Object-Relation mapping ( Powerdesigner? )

     Test Driven Development

Could have been done better:

    Null handling ( string + null = null )

    Structures

    Compiler - has lots of regeneration issues. PowerGen costs 2000$

    Garbage collection. Never rely on it, just CREATE and DESTROY.

    Arbitrary decimal precision. Try "ceiling( 40.0 / 8 )": PB tells you it's 6.

    PBL format: proprietary and obscure package of source code + semicompiled sections

    The Datawindow mixes application, presentation, interaction code

    InterProcess Communication

    Source Code Control integration ( ProDiff needed at least to compare objects )

    Powerbuilder Native IDE has been looking the same since PB 9

        hopefully this will change in PB 15

        IDE editor - looks like Notepad with autocompletion

    Exception handling, it's just a stub. Most functions fail with return code even on critical error.

    Direct3D

    Windows Services

    Window layout and autoresizing

    String formatting ( where is a serious printf/scanf? )

    Deployment and packaging

    Loops. There is no "foreach", no iterators...

Other environments have:

    Very huge opensource libraries:

        Scientific (SciPy)

        Imaging, Audio, Video

        Distributed messaging (ZeroMQ)

         Operations Research

    IDE plugins

    ... enter your favs here.

[Former Member]

Hi Paolo;

  That is a pretty good list!

I would like to correct one item though ... PB has always been multi-threaded since PowerSoft added the SharedObjectxxxxxx commands. I have a new PB application that I built last year that runs 50 threads in production 24/7 and has been running continuous for 6 months now.

Regards ... Chris

[Former Member]

Take that item out of the list.

Sorry, I don't know why I always thought that it was a time-sharing based mechanism.

My i5 (2 physical cores 4 logical) CPU is running 50% after creating a shared object with a full CPU usage test, so they're actual threads.

Unfortunately looks like no "edit" or revision function is available here on SCN after the post has been moderated.

Thank you Chris

[Former Member]

Hi Paulo;

  Yes, real threads ... nice eh!  

  As I say .. "Its always a good day when you learn something new"!   

Again ... nice list and a good overview / comparison as to ho how PB "stacks up" feature wise to other products.  This is the kind of thing that SAP needs to focus on when deciding on new PB 15, 16, 17, etc features that will give PB back the prowess in the IDE marketplace.

Regards ... Chris

[Former Member]

Reading this thread I found a lot of things comparable to my current situation and my (still growing) problems in the last years.

I'm using Powerbuilder since v3 and found that migrating from/to v5, v7, v8, v10, v11.5, 12.1 and currently 12.5.2 was an easy walk.

Powerbuilder saved me a lot of time, so I spend this time over the years to have an eye on MSDN, Visual Studio and C#. There they have a lot of books/docs, samples, source snippets, components, ideas, tutorials, trainers, evangelists, gurus ...,This must be the look of paradise.

I started more than one approach to switch over to Visual Studio; at the end and everytime I ruefully come back to Powerbuilder classic.,Most of the times the reason was that one of my clients wanted to have their apps "now" up und running; not interested in implementation details (out of budget).

Then PB.NET comes up. Does someone really read my enhancement requests from Techwaves in Vienna, Paris, San Diego...?,I know PB wanted to be everybodies darling; but the old lady does not want to change her "look and feel" and not her behaviour.

So I gave PB.NET a try in the isolated shell and ... went back to PB classic.

I don't feel very comfortable with PB.NET. Where is my MDI?. Why does rendering/migrating to WPF have such ugly results? (compared to my old lady which is suddenly looking younger and more agile then ever)?.

There is an migration path for my old ActiveX-Controls, from which I tried to get rid off in the past. But there is no real and stable support for new attractive and fancy 3rd party WPF controls (e.g. Spreadsheetgear, Syncfusion) which I want to use instead, with intellisense, visual designers, documentation, examples and so on...

The Sybase engineers have done a great job. Inheritance of visual controls (that saved me a lot of time maintaing my applications) is still supported in PB.NET; but this is at least not a usual concept in a XAML world. 

I love Powerbuilder. But to be precise at this point: I love the datawindow control (including DDDWs), the datastore and transaction class. They are the heart and core of powerbuilder. I can use all of them very easily in "Visual Studio 2010 Pro" with C# by including a few Sybase.Datawindow.* DLLS and inherit and extend their classes/interfaces. For designing datawindows I use PB (classic or NET; InfoMaker should also be fine) and export them into SRD-files. I picked them up in VS/C# and feel happy and at home. OK there are some drawbacks. The rest of my GUI is missing, my business logic has gone. But therefore I have all the wide opportunities of a dotnet and (wpf-based?) 3rd party world.

Finally my suggestion (IMHO) is:

Stay tuned with PB classic for mature applications and try to think about Visual Studio for your new applications including a datawindow wpf component. Answer yourself: Do you really need a wpf-based application or want to use a 3rd party component, which is not supported by pb classic (with pbni, pbinvoke, com access) ?

For some "non visual" parts, I (re)implement them in C# as COM visible classes/components, so I can use even the new logic in "old" PB classic apps. For example: Last week I build a COM-visible REST-Client using C# o access a Wakanda NOSQL-Server and returning his json responses into my CRUD classic datawindow.

Last but not least I hope the (near?) future will bring some simple answers to me:

• Will Microsoft announce that wpf should go the same way as winforms, webforms and silverlight (as rumoured) ?
• Is Javascript (HTML5, CSS3) rising (or declining or replaced by ...) ?!
• Wouldn't it be a good idea, if SAP-Sybase could change (extend) their migration process for pb.classic to pb.net in a way that pure C# comes out(skipping powerscript and the isolated shell)? ... Chris could this "give PB back the prowess in the IDE marketplace" ?
• Is it possible for a "lone warrior" (like me), to handle a growing DEVStack with sophisticated, multi-targeting IDEs, APIs, Specs, Technologies, cloud enabled mobile devices ... in the future
• Who knows ?

[Former Member]

Hi Hans;

1) So I gave PB.NET a try in the isolated shell and ... went back to PB classic.

=> Yes .. all my Canadian Federal government clients did the same!

2) Why does rendering/migrating to WPF have such ugly results? (compared to my old lady which is suddenly looking younger and more agile then ever)?.

=> I agree. All we got was another poor implementation of a native MS-Windows only based application development IDE! Add Appeon to PB classic and you are a lot further ahead with Web, Cloud & Mobile!

3) Will Microsoft announce that wpf should go the same way as winforms, webforms and silverlight (as rumoured) ?

=> MS has already stated that they are not extending WPF any further. (Hello .. wake up Sybase)!

4) Is Javascript (HTML5, CSS3) rising (or declining or replaced by ...) ?!

=> Np .. HTML5 is where its at. The whole Canadian government for example is now standardizing on it for all their websites: 

CLF:  http://www.tbs-sct.gc.ca/ws-nw/index-eng.asp

WET:  https://github.com/wet-boew/wet-boew

5) SAP-Sybase could change (extend) their migration process for pb.classic to pb.net in a way that pure C# comes out(skipping powerscript and the isolated shell)?

=> no .. don't forget that 52% of the IDE market is Java. PB needs to be just as good at inter-operating with Java as it does with .Net. That is why it makes more sense to continue with PB Classic as its C++ based and can inter-operate with J2EE as well as .net (and that's what SAP should focus on - the BIG picture, not just the declining MS world)!

6) Who knows ?

=> The "Shadow knows"!   🙂

http://en.wikipedia.org/wiki/The_Shadow

Regards ... Chris

[Former Member]

4) Is Javascript (HTML5, CSS3) rising (or declining or replaced by ...) ?!

=> Np .. HTML5 is where its at.

I agree with you Chris - HTML5 is the way to go.  Generally JavaScript is a poor solution - fragile and interpreted, but there aren't really a lot of good options.  Story is MS is working on a ".Net plugin" that will allow you to write .Net Lang (like C#) code, compile it to IL and run that in the (any) browser.  Native in IE of course; no plugin.  There are a few tools that convert C# to JavaScript but the result is still interpreted in the browser.

[Former Member]

Randy Buchholz said:

I agree with you Chris - HTML5 is the way to go.  Generally JavaScript is a poor solution - 

JavaScript is what powers HTML5, if it's a poor solution, then so is HTML5.

http://radar.oreilly.com/2011/07/what-is-html5.html#javascript

[Former Member]

We are trying to figure out whether to continue with PB or convert all our programs in VS / Java.

we run an entire system:

- accounting

- warehouse

- orders

- bubbles

- Invoices

- statistics

- MRP

- etc.

A very large project started with PB V3.0A and currently in development on PB 12.1

i'm so sad in PB

The team consists of 10 programmers.

[Former Member]

If the code is already in PowerBuilder then converting the applications you have to VS and/or Java is going to cost a HUGE amount of money, the applications will run many orders of magnitude slower (which will then require significantly more money to buy faster hardware), and like as not, NEVER GET DONE.

I cannot tell you how many projects I've run into where PowerBuilder applications were being "sunset" in favor of Java and/or VS and where the "new" application was subsequently cancelled due to cost and/or lack of performance, leaving the PowerBuilder app still running many years after it was supposed to have been replaced.

True story; my current main client brought me on back in 2008 to baby-sit their customer service application (written in PB 10 and supporting 500+ users) for the last year of its life while the new Java app was being finalized.  Due to budget cuts they let me go in 2009 figuring "enough" had been done to allow the PB app to live long enough.  In 2011 they brought me back part time to upgrade the app to PowerBuilder 12.5 and Windows 7; a project which I completed in a whopping 29 hours.  As they had budgeted 1,000 hours for me to complete the project, they just kept handing me bit work to keep the app limping along until its (new) scheduled retirement date of 2013.  Not surprising, my part time gig got extended into 2012 and then 2013 with the sunset date being extended to 2014.

Two weeks ago it was revealed that the Java app had thus far consumed between 45 and 60 million dollars (depending upon which group you talk to), and after all of money and years of development it was still only able to do about 25% of what the PowerBuilder app could do.  Needless to say, when the gross expenditures leaked out, there was a management shakeup and within days the new Java application was "suspended" until further notice.

And the PowerBuilder app?  It is now the "new" (again, it was initially developed back in the PowerBuilder 3/4 era) enterprise customer service application; I'm suddenly being handed more than enough work to keep me busy full time and it looks like we're going to be nosing around for another PowerBuilder resource by year's end.

[Former Member]

Definition of "legacy application": that boring old software that actually runs your business. I suspect the key phrase in your post is "nosing around for another PowerBuilder resource" - management has a factory mindset and wants an environment where the supply of workers is boundless and wages are low - e.g. Asian manufacturing. So the problem is that many of the most productive, engaged PB developers have tired of maintenance and moved on to where they perceive the fun is, and the pool has not been refilled with eager graduates. It remains to be seen whether SAP can reverse that with the university partnership program, and marketing tools to bring back mind share. For instance, how much would it cost to fund an updated "PowerBuilder for Dummies"?

[Former Member]

For whatever reason, I have not had too much of a challenge finding PowerBuilder programmers over the last five years or so.

The thing is, while it is true that the quantity of qualified candidates is fairly low, the quality of said candidates seems to be rather high.  Speaking strictly for myself, I find it easier to choose one highly qualified candidate to hire out of a pool of say ten then it is to choose two or three moderately qualified candidates out of a pool of hundreds.

Recently I was talking with a developer I'd worked with on a PowerBuilder project back in the late 1990s and was suggesting to him that he'd have an easier time of finding a good paying PowerBuilder contract than he would say a .Net project.  He was initially dismissive of my premise, however, he'd been without a contract for several months at that point; two weeks after he re-added PowerBuilder to his resume, he landed a nice gig.

Sometimes it pays to work in niche areas. 

[Former Member]

Rewriting a software really goes beyond language problems.

There is nothing so "special" in what Powerbuilder actually does, that cannot be replicated in other languages (C++ for instance), given time.

The problem is that if you have a working enterprise-class software, it is almost always non-sense to rewrite it from scratch just because another IDE/language is fancier. If you are going to do a completely new version, with a new project, rethinking the whole software, there are many things that can go wrong, from analysis to implementation.

The biggest black hole that can drain all your energies and money is backwards compatibility.

Why would you rewrite a software that "just works" and has been tested for 5,10,20 years with a completely new one? Is there no refactoring or wrapping to simply make it better? Some bank and big assurance firm still rely on COBOL software on mainframes. Why? It just works.

The second trap comes in when you just realize you have big problems. You have to stop, talk with people, try to solve the puzzle and see if it's still a good idea. But you have to realize this before it is too late. Don't get emotional when marketing people tell you your software is old, it's the worse thing you can do.

In most cases, if your software is just modular and multitiered enough, you can make the new project and the old one cooperate side by side. If you write all the code in global functions called directly by datawindows, and have no framework to help you abstract your architecture, you cannot expect migrations to be easy.

Try to isolate the features you miss in your current PB environment. Regexp? Web? OLE?

You can start from those to build a complementary part in Visual Studio.

You can build a standalone PB.NET target and import your .NET assemblies... or viceversa.

You can build a Windows/Apache/whateverDB/PHP stack and get data from Powerbuilder through PB web services

Write tests that your actual software passes before dismantling any old code, so when you have a new software, there must be no regression - and if there is, you must know exactly where.

There is no "magic switch" turning a PB application into fully functional and 100% performing .NET/Java/Javascript/PHP/Python/Ruby/Haskell one in two days' time.

[Former Member]

It might help if you could give more details of the project being worked on then people could point out how PB would help.

[Former Member]

You have something to add between Java and Powerbuilder?

1K Thanks for your opinion.

I will treasure it.

Gimmy

[Former Member]

A lot of the same points.  Java is even more 3GLish than Visual Studio.

The reason I love PowerBuilder is because I want to spend most of my time actually writing the application, not writing application infrastructure to support writing the application.  Pair PowerBuilder with a decent framework like PFC and you can pretty much immediate get down to generating something the end user can use, and produce it rather quickly.

In the inverse of what Terry says below, people who have learned PowerBuilder and know how productive it can be can have a real hard time with anything else, particularly because of how much more time it seems to take to get anything done with them.

[Former Member]

8. The DataWindow performs better on retrievals because it retrieves rows in blocks rather than one at a time (assuming you don't have code in the RetrieveRow event).

9. PowerScript is a very clear, no-surprises language. Readable code means fewer bugs and easier maintenance. And the learning curve is very rapid.

10. PB is object-oriented. Pick one of the available frameworks, spend a little time customizing it, and each time you add a feature you will find 50% of the work is done by inheriting the appropriate object. And it's the boring part of the work, the wiring and plumbing, leaving you to concentrate on the business logic.

[Former Member]

Hi Jerry;

  FYI ...  #8 is not true ... while the DB driver get an entire packet, the DWO runs an internal FETCH loop 1 row at a time to get all the rows for the primary buffer. Things can also go better or worse on top of that depending on whether the developer used an ODBC connection, OLE-DB, ADO.Net, JDBC, native, etc driver connection mechanism.

Regards ... Chris

[Former Member]

Really?  Then what would be the point of the Block DBMS parameter?

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc33820.1200/html/dbparm/CC...

Block (ODBC, OLE DB, Oracle, and SNC)

Description

For those interfaces that support it, Block specifies the cursor blocking factor when connecting to a database. The blocking factor determines the number of rows that a DataWindow object can fetch from the database at one time.

Using the Block parameter can improve performance when accessing a database in PowerBuilder.

[Former Member]

"internal" = memory to memory = very very fast, mircoseconds. Blocking reduces the number of times the client must handshake with the server over the network. As I recall it's two or three messages each before and after each data block - regardless of the actual number of rows in that block. Time for each would be in milliseconds. As always, it depends on the speed of the network , traffic level, and load on the server, but with a substantial result set the difference is often discernible to carbon-based life forms.

[Former Member]

Hi Bruce;

  That is an excellent question and probably a big misconception in PB/DB-Land!

  You have to remember that the real DB client driver is the one that is handling the DB data packetization on both sides of the C/S fence. PB's DB driver is not the one doing that .. in fact, the PB DB driver ( for example PBSNC125.dll) is really only an "interface" to the real DB client driver that the DBMS vendor or 3rd party provided.

  So... many things that you put in the SQLCA.DBParm or other SQLCA settings are really just "passed through" to the real DB driver from PB's "interface" driver. Thus, when the blocking eature you refer to is activated its actually implemented at the real DB driver level - then, the PB interface DB driver runs a FETCH on that buffer to get it into the PB application.

  FYI: Just run a PB SQL Trace and a DB Driver SQL trace and you will see what I mean. 

HTH

Regards ... Chris

[Former Member]

6. Datawindows for adding data & reporting is significantly better than VS because the data entry form can be used to print the data, with no other objects/reports needed.

7. Inline SQL for times when you don't need a datawindow just to grab a value from the database (or doing updates that don't need individual value changes (ex: reset a flag in a table with a where clause)).

[Former Member]

Here's 4 for a start:

1.  The DataWindow allows for automatic handling of optimistic concurrency.  That is, you can tell it to check for update conflicts with just updated columns, or for all columns in the result set without having to add any special logic.

2.  The DataWindow renders at runtime as two controls, a bitmap and an edit mask, regardless of how many rows/columns are retrieved, reducing the demand on graphic resources.

3.  The DataWindow, if handled correctly, can be backend database agnostic.  You can easily have one set of code that supports a number of different databases.

4.  The Rapid Application Development features of the DataWindow and the PowerBuilder IDE mean that developers can be much more productive using the tool than other more 3GLish IDEs.

[Former Member]

While I'm not all that familiar wity Visual Studio, I do think I have one large item to add to the list:

5. Performance; PowerBuilder executes significantly faster than identical applications written in Visual Studio.

[Former Member]

3a. And when you use the DW painter, you don't waste time looking up the exact column name spellings or details of SQL syntax. For instance, when you do a join, it lists the options in plain English so you don't have to worry about which side of the = gets the *. And did I mention it's mostly point and click?

[Former Member]

Hi Gimmy;

  If you send me an email on this - I can respond with my $0.02 worth on the subject.

Regards ... Chris

[Former Member]

I have not tour email, but you can find my email on my profile Ty Chris  Gmy