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