NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/mswindo/programm/tools/1947

Internet Message Format | 1993-01-08 | 5.6 KB

Path: sparky!uunet!pipex!ibmpcug!fredc
From: [e-mail] (Fred Curtis)
Newsgroups: comp.os.ms-windows.programmer.tools
Subject: Re: PowerBuilder
Message-ID: <[e-mail]>
Date: Fri, 8 Jan 93 23:04:21 GMT
References: <[e-mail]>
Organization: CONNECT Mail Feed via ibmpcug.co.uk in the UK [[phone]]
Lines: 101

In <[e-mail]> [e-mail] () writes:
>My company is considering an all-out development project using
>PowerBuilder. If anyone has used this product, would you please
>let me know of your experiences with it, especially regarding
>its so-called "cross between FORTRAN and BASIC" object-oriented
>language and database interface capabilities. A comparison
>against existing user-interface development tools (ie Telon
>for mainframes and Easel for PC's) would also be of help.
>
>Thanks in advance!
>Steve Lamotte
>--
>Steven Lamotte
>University of Manitoba
>[e-mail]

My company is currently building a large application with Powerbuilder.
Powerbuilder seems at first glance to be a good product, and I suspect
it is quite a good tool for prototyping small modules and developing
straightforward database applications.  It doesn't seem to scale very
well, though.  The project is currently running behind schedule (we have
about 8 programmers doing development) due to:

   a)  The large number of bugs in Powerbuilder for which work-arounds
       have to be found.  Admittedly, the more recent beta versions have
       fixed some of the more severe bugs.  Bugs in the user interface
       consume a _lot_ of time - you have to be psychic to deduce what's
       wrong since the error messages when Powerbuilder crashes vary
       from meaningless to merely misleading.  I find myself having to
       restart windows several times an _hour_.

   b)  The slowness of Powerbuilder.  A lot have time has been wasted
       in getting Powerbuilder code to work, only to find that it was
       too slow and the functionality had to be discarded or re-written
       in C [my company has chosen not to use C++ - the decision was made
       by the same non-techs who pushed that we use Powerbuilder, which
       admittedly _did_ look good for writing pokey little DB screens].
       The application is targetted at laptops, which will fortunately
       be 50+Mhz 486's.

   c)  The fact the a lot of the behaviour is governed by Powerbuilder
       scripts, accessible only though menus from within Powerbuilder.
       Plain text (ala conventional programming languages) isn't a
       perfect medium for programming, but it's a hell of a lot better
       for tracing execution or doing something mundane like a grep.

IMHO we would have been far better off using C++ & an application
framework like Borland's OWL or Microsoft's MFC.  The only advantage
of using Powerbuilder - being able to paint a few screens quicker than
using traditional tools and a compile-run cycle - has been far outweighed
by the time wasted on other problems, and the result is going to be a
maintenance nightmare.  The project has had an unbelievable turnover
rate (several new programmers have lasted less than 3 days, holidays
have been suspended for programmers working on the project until the
deadline).

Powerbuilder will have proved to be an extremely costly exercise for
my company.

Disclaimer:  I have only recently started using Powerbuilder myself;  most
of the horror stories have come from the bloke sitting next to me, whose
selfless delving into Powerbuilder (his Powerbuilder code was scheduled
to start before mine :-) has caused him, and saved me, much mental anguish.
Acknowledgement:  My US colleagues, some of whom have since left, under-
went the pioneering Powerbuilder trauma.  Lest we forget.

On a (marginally) less caustic and more informative note ...

I cannot comment on the programming interface to the database (we're using
XDB) since I'm using C to manipulate the database 'cause XDB doesn't
support blobs (regardless of the doco) and Powerbuilder isn't expressive
enough to extract and concatenate several Varchar fields, and would be
too slow if it was.

The script language?  What's there to say?  All these modern script
languages look the same to me (bring back punched cards!).  The OO
features consist of being able to type aWindow.aFunc(args) instead of
aFunc(aWindow, args), and being able to inherit behaviour from a parent
window.  Watch out, though.  You might expect a derived window to get
passed an event, with the option to call the base window method, ala C++.
Not so.  The base window (which, in OO fashion doesn't know that the
derived window exists) gets the event first.  The script language gets
compiled (probably tokenised) and runs through a 'for' loop - yes, not
the best of benchmarks - about 1600 times slower than C.

Powerbuilder is probably OK if you're writing a straightforward DB
application - if you've seen event driven code (e.g. written some
code under X or microscoft windows) then you won't have any conceptual
problems with Powerbuilder.  If you obtain some perverse sexual
gratification in specifying function parameters using dialogue boxes
and menus then you'll feel right at home. (Oops! I've started frothing
religious prejudices now!  Time to go!)

[The opinions expressed above are mine, not those of my company, which
 I have been very careful not to name - the IBM PC User group is just
 the place where I connect to the net and they are nice guys :-)]

--
[e-mail] | "Could you try smiling with more feeling, Sally?"
                    | "Feeling?  ....   I'm afraid you've lost me ..."
                    |      -- Drop the Dead Donkey -- 7 Jan 1993