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