*BSD News Article 38623


Return to BSD News archive

Xref: sserve comp.os.386bsd.development:2735 comp.lang.basic.visual:27211 comp.lang.basic.visual.misc:665 comp.databases.sybase:11431
Newsgroups: comp.os.386bsd.development,comp.lang.basic.visual,comp.lang.basic.visual.misc,comp.databases.sybase
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!werple.apana.org.au!otis.apana.org.au!serval.net.wsu.edu!netnews.nwnet.net!oracle.pnl.gov!osi-east2.es.net!cronkite.nersc.gov!dancer.ca.sandia.gov!overload.lbl.gov!agate!howland.reston.ans.net!news.sprintlink.net!hookup!caen!saimiri.primate.wisc.edu!aplcenmp!birznie
From: birznie@aplcenmp.apl.jhu.edu (Gunther Birznieks)
Subject: Re: Visual Basic vs. PowerBuilder
Message-ID: <D01AKq.2n3@aplcenmp.apl.jhu.edu>
Organization: Johns Hopkins Continuing Professional Programs
References: <davebo.18.0010EDAE@mcs.com> <3be6q8$8ts@nermal.cs.uoguelph.ca> <dil.admin.1241.0008B1DB@mhs.unc.edu>
Date: Tue, 29 Nov 1994 14:50:50 GMT
Lines: 104

dil.admin@mhs.unc.edu (David I. Laudicina) writes:


>>        If you're looking to do. From the sounds of your setup, it looks 
>>like you need a serious Client/Server environment, in which case 
>>Powerbuilder would be the way to go. On the other hand -- if you're 
>>looking for a quick and dirty way of making a user friendly front-end, 
>>then you could squeak by with VB.

>><other opinions welcome>

>I disagree with your comments about VB. Powerbuilder is a beautiful product 
>but whne you start adding up the cost to put it on each developers desktop 
>with serious db access it is pretty expensive. VB gives you most of wht 
>powerbulider does at a very inexpensive price. We use ODBC and call stored 

I hate to get into religious discussions (OK maybe I do like to) but 
I think there is a definite difference in terms of VB and PB for C/S
development.  

I've personally developed C/S applications in both and found PB to be
my preference for a variety of reasons.  

Ultimately, Performance was defintately better accessing databases with PB
than VB with stock ODBC (its not odbc's fault, just the implementation of
data controls).  Chalk one up on the PRICE bit on having to buy some add
on to VB if you want decent data access.

PowerBuilder has a built in report writer that reuses the same datawindow
paradigm making it more seamless in terms of memory usage and performance
in not having to load a 3rd party DLL to do reporting.

With VB you have to pick and choose a third party report writer. Chalk one
up onthe PRICE bit on having to buy yet another add-on to VB.  VB should
be renamed to YAAO (Yet ANother Add-On).

If you develop ONE application in PB vs VB, you might find they compare.
But if you understand OO paradigm and either buy or make a good class
library for PB, development is much easier in PB.  Even internally to
an application, inheritance is an incredible thing that VB frankly
lacks.  I found that even in my first project with PB, I saved a lot of
time with just inheriting standard data entry screens within the application
I was writing (Not using class library at the time).  

PB has more flexible data access in terms of implementing views and stored
procedures as updatable modules than ODBC with VB.  (Reference the purchase
of requirement to buy a 3rd party data acess tool if you do serious work
with VB).

Although it is nice and powerful to be able to buy addons, it can tend
to lead down a road to hell and nightmares.  Remember that you have to 
keep track of not just one vendor, but multiple vendors.. This means
keeping track of updates on each product, making sure the updates integrate
properly with each other,... Not to mention that when you find a big
bug in an add on that you have to spend time back and forth arguing
which bug was caused by which 3rd party add on.

PowerBuilder very nicely operates as a one-stop solution to the whole
Client-Server develoipment cycle. With VB you HAVE To buy 3rd party.
When youHAVE to buy 3rd party instead of being a CHOICE, it ceases to
become a 'good' thing.

As for expense of VB vs PB.

Well,

(A) VB sans add ons is relatively inexpensive (VB Pro).
(B) You need addons and the best c/s ones to make it even remotely
compare to PB are going to cost you a bundle o' $$$.
(C) PB for more than one project and even internally to a project will
save you coding time through inheritence techniques.
(D) Maintenance has been shown to be upwards of 67% of the cost to the
development life cycle of a product.  By requiring developers to 
use multiple coding products instead of one, you increase overhead in
maintenance and making sure that updates to individual controls do not
interfere with old "builds".  When you have an integrated product, it is
easier to do this when you have one global update coming out.  

As well, maintenance cost is cut down with PB because if the application
is developed in a hierarchical inherited manner, it is easier to make
changes at the appropriate level.  With VB, it is much more difficult to
manage code when you have copies of windows that do the same thing instead
of inheritence where you can change the behavior of a button and have it
propogate to all the windows.  

Anyway, the above is an oversimplification of the matter and I am sure I
will receive some or a lot of flak for posting this, but giving a whole
long drawn out explanation would monopolize my time when I already know
I am using the best tool for the job. ;).

PS Dave, I agree that PB and VB lack in enterprise development repositories
and tools.  Although with PB it is better because you can have
a global class library stored on a LAN and access those as enterprise
objects.  In terms of team source control, you can buy add-ons to PB to
do this which integrate pretty well... since PB is made to integrate with
add-ons like PVCS etc.

This does not solve the complete problem, but of course, it makes PB somewhat
better I Think in this respect. 

Later,
  Gunther