Why use a 4GL?
Damien Powell
I am currently looking for a document, or documents, which will aid me
in convincing a client that the should use a 4GL instead of just using
a 3GL (hard to believe but there are still a few out there)
Thanking you in advance
Damien
Sean Cunneen
Interesting, I am currently trying to convince a client that 4GL's are
not the be all, and end all of programming environments. There are both
advantages and disadvantages of 4GL's and RAD environments.
/* as an aside what defines a 4GL - does a RAD such as VB rate
as a 4GL, even though Basic is a 3GL? */
FOR :
These environments allow rapid development, and when time is money
this is an important feature.
Special "database aware" attributes that tie in very nicely with
your DB.
Extra stringent checking and increase compiler responsibilities takes
away some of reponsibility from the programmer - ie. it is more
difficult to f*@# up than in something like C.
Any novice can sit down and churn out a form.
Very high level of abstraction allows the designer to focus on the
requirements of the system, rather than getting tied down in the
implementation problems.
AGAINST:
The generic style of code they produce hog computer resources and can
deliver sluggish performance compared to optimised 3GL code.
The massive proliferation of 4GL environments results in a lack of
standards, and calls into question their future support/maintainability.
With virtually every company producing a RAD environment of their own,
how long can the industry continue to support all of them? There is the
danger of being left in five years time with a product that is no longer
supported, or supported in limited numbers forcing your client into a
situation where they have to choose the only support available instead
of the best support available. (a bit like Netscape plugins I guess,
there are just too many for them all to survive).
Despite the immediate functionality of the environment, to become
competent enough to produce quality software takes as long to learn
as with a normal 3GL. You can't just pick one up and code a system.
Lastly, from a Software Engineering perspective, the speed of
developement and the built in safeguards tend to amek the design slack
in terms of specs and design ... with the growing attitude being that
if there is a defect in the requirements than a complete rewrite is a
feasible solution.
At least that is my view.
Also try http://www.interex.org/interact/jul95/pp44-46.html for another
view.
Hope this helps
Sean Cunneen
DGarr10276
In article <84435022...@cabinjet.demon.co.uk>,
dam...@cabinjet.demon.co.uk (Damien Powell) writes:
>I am currently looking for a document, or documents, which will aid me
>in convincing a client that the should use a 4GL instead of just using
>a 3GL (hard to believe but there are still a few out there)
>
>Thanking you in advance
>
>Damien
>
>
In my opninion, anyone who would not use a 4GL to develop a software
package is out of their mind. A 4Gl ensures the following:
1. Consistency between applications. I.E. each application would look,
feel, and operate the same, thus reducing end-user training. I have seen
systems which, even within the same module (i.e. Accounts Payable), one
function to the next function operates differently. One function may
require the user to enter something such as FI to save the infiormation,
another may require END, etc. etc.
2. Ease of application modification. I.E. adding fields to input
screens, adding columns to reports, etc. are much easier to do in a
package written with some type of
4GL
3. Ease of application development. I CHALLENGE ANYONE TO PRODUCE AN
APPLICATION IN WITH SAME QUICKNESS THAT THE SAME APPLICATION WOULD TAKE TO
PRODUCE USING A GOOD 4GL PACKAGE. I would even go out on a limb and say
that an application could be developed at least 4 times quicker using a
GOOD 4GL package.
4. Standard within programming department/contractors. Each application
created by various programmers internal/external to the company would
share at least SOME type of similarity if developed with the same 4GL.
You wouldn't believe the variations you would get if you weren't
developing your application in some type of controlled environment.
My two cents worth
Patrick A. Linder
Dean Goddard
Has anyone looked at PowerBuilder 5.0? It beats VB without a doubt! PB
is OO, VB ain't. PB has a patented datawindow - craps on VB. PB can now
be distributed and supports heaps more databases than VB with ODBC.
32 bit PowerBuilder can also compile to machine code - WAY FASTER THAN VB
WILL EVER BE.
Check out http://www.powersoft.com
Regards Deano.
jeff g.
Dean Goddard (go...@ozemail.com.au) wrote:
: DGarr10276 wrote:
: >
: > In article <84435022...@cabinjet.demon.co.uk>,
: > dam...@cabinjet.demon.co.uk (Damien Powell) writes:
[ snip, snip ]
: Has anyone looked at PowerBuilder 5.0? It beats VB without a doubt! PB
: is OO, VB ain't. PB has a patented datawindow - craps on VB. PB can now
: be distributed and supports heaps more databases than VB with ODBC.
: 32 bit PowerBuilder can also compile to machine code - WAY FASTER THAN VB
: WILL EVER BE.
YOu must own stock. But seriously, Powerbuildre is a major pain in the
ass to learn. I know, I've had to teach it to people. VB on the other
hand is MUCH easier to pass on to others. It also grows in leaps and
bounds, while PB grows in fits and starts. In fact, without Data Windows,
PB has nothing amazing to offer in place of VB. I'm also quite confident
that MS will continue to make VB a more than competitive product, while
the company which owns PB is in serious doo-doo. PB also gives you big
fat executables, the proverbial "fat client."Q§½گ¾’غلج›ر: Check out http://www.powersoft.com
: Regards Deano.
Qg»»؛·¦
jeff george
Joyce
DGarr10276 (dgarr...@aol.com) wrote:
: In article <84435022...@cabinjet.demon.co.uk>,
: dam...@cabinjet.demon.co.uk (Damien Powell) writes:
:
: feel, and operate the same, thus reducing end-user training. I have seen
: systems which, even within the same module (i.e. Accounts Payable), one
: function to the next function operates differently. One function may
: require the user to enter something such as FI to save the infiormation,
: another may require END, etc. etc.
I don't see your above point as a "for" or "against" a 4GL. Consistency
can be acheived by something called "standards". Don't get me wrong, even
though I'm marginally against 4GLs I don't feel that strongly about it. We
have 1500 Basic programs, ALL have the same feel, look and taste :) We
acheive this by sets of support subroutines. Except for a very very old
programs, we have been around in Pick/UniVerse for about 12 years, all
our programs call an input handler to input data. This input handler
does all input. It has the defined "go back", "abandon", "file" and
on-line help all built in. We have about 200 support subroutines. We
would suggest that our use of Basic is almost 3.5GL. We have program
generators, developed in-house, that also follows the set standards. We
can write a simple program in 3-4 hours. We can paint a screen and
generate an input program with about 20 "header fields" and half a dozen
repeating fields in less than two hours. We have about 150 "screen
generated" programs that can have a field added/removed in minutes, like
one or two minutes.
All this without a 4GL.
My 2c worth.
Louis
Damien Powell
jo...@wt.com.au (Joyce) wrote:
>My 2c worth.
>Louis
Wouldn't you say that you have in actual fact created your own mini
4GL?
Regards
Damien
GeorgeLand
In article <3254CF...@tartarus.uwa.edu.au>, Sean Cunneen
<sccl...@tartarus.uwa.edu.au> writes:
>Interesting, I am currently trying to convince a client that 4GL's are
>not the be all, and end all of programming environments.
[snipped]
>
>AGAINST:
>The generic style of code they produce hog computer resources and can
>deliver sluggish performance compared to optimised 3GL code.
Usually true up to a point although we have replaced basic written
applications with SB+ and got a performance increase - it really depends
on how good the basic is.
>The massive proliferation of 4GL environments results in a lack of
>standards, and calls into question their future support/maintainability.
>With virtually every company producing a RAD environment of their own,
>how long can the industry continue to support all of them? There is the
>danger of being left in five years time with a product that is no longer
>supported, or supported in limited numbers forcing your client into a
>situation where they have to choose the only support available instead
>of the best support available. (a bit like Netscape plugins I guess,
>there are just too many for them all to survive).
This used to be a problem but in the Pick arena everything has settled
down, there is only one major player (SB+) compared to the dozen or so
that tried to make it in the eighties. But I would agree that the size
and stability of the supplier is probably more important than anything.
>Despite the immediate functionality of the environment, to become
>competent enough to produce quality software takes as long to learn
>as with a normal 3GL. You can't just pick one up and code a system.
I wouldn't advocate that a 4GL is easier than a 3GL, there is a lot of
learning involved and some people who were capable of coding in basic
never get into 4GL development.
4GLs allow good developers to be far more productive, generally they are
not tools that turn users into programmers.
>Lastly, from a Software Engineering perspective, the speed of
>developement and the built in safeguards tend to amek the design slack
>in terms of specs and design ... with the growing attitude being that
>if there is a defect in the requirements than a complete rewrite is a
>feasible solution.
Some years ago a man from Informix tried to convince me that the fact that
changing a field length in an existing database design meant a rebuild of
the database to him and no work to me was a reason why Informix was better
than Pick. The theory was that if it was difficult to make the change
afterwards you would make sure that you got it right first time! You can
write good software or bad no matter what tools you employ.
George Land
APT Solutions Limited
Paul Freeland
georg...@aol.com (George Land) wrote:
>I wouldn't advocate that a 4GL is easier than a 3GL, there is a lot of
>learning involved and some people who were capable of coding in basic
>never get into 4GL development. >4GLs allow good developers to be far
more productive, generally they are
>not tools that turn users into programmers.
I Agree entirely. A few years back I was involved in a strategic
evaluation of the newly emerging SB+ 4GL (version 1.0.9.5) This involved
a visit to the System Builder UK head office in Chester. SB were, quite
rightly so, very proud of their new product and had started a
marketing/advertising campaign that boldly claimed that "SB+ turned users
into programmers".The company I worked for at the time immediately
grasped this statement as a twofold method to reduce development costs:
1. By reducing development lead time.
2. By enabling less skilled (less expensive) personell to develop ! C
Jim Idle
DGarr10276 <dgarr...@aol.com> wrote in article
<5335gq$5...@newsbf02.news.aol.com>...
> In article <84435022...@cabinjet.demon.co.uk>,
> dam...@cabinjet.demon.co.uk (Damien Powell) writes:
>
> >I am currently looking for a document, or documents, which will aid me
> >in convincing a client that the should use a 4GL instead of just using
> >a 3GL (hard to believe but there are still a few out there)
> >
> >Thanking you in advance
> >
> >Damien
> >
> >
>
> In my opninion, anyone who would not use a 4GL to develop a software
> package is out of their mind. A 4Gl ensures the following:
1) That you are tied in to the supplier of your 4GL for the lifetime of
your application :-(
This is the only real problem with a 4GL. Things like performance and
inflexibility you can live with quite easilly, and in some cases do not
exist. However, for many VARs in the Pick community their 4GL is becoming a
burden as they are charged for run-times of their 4GL as well as the
database and then they must make money on their applciations. The 4GL
suppliers cannot remove the burden of their own runtime fees because this
is how thier business makes money.
Of course, most of the newer 4GLs do not come with the burden of a runtime
cost so this issue goes away.
Other than my opinion here a lot of what Patrick says, I feel is true,
although not all would be as passionate about it ;-), and many would say
that their are other ways to acheive some of the same things.
Jimi
DGarr10276
>I don't see your above point as a "for" or "against" a 4GL. Consistency
>can be acheived by something called "standards". Don't get me wrong,
even
>though I'm marginally against 4GLs I don't feel that strongly about it.
We
>have 1500 Basic programs, ALL have the same feel, look and taste :) We
>acheive this by sets of support subroutines. Except for a very very old
>programs, we have been around in Pick/UniVerse for about 12 years, all
>our programs call an input handler to input data. This input handler
>does all input. It has the defined "go back", "abandon", "file" and
>on-line help all built in. We have about 200 support subroutines. We
>would suggest that our use of Basic is almost 3.5GL. We have program
>generators, developed in-house, that also follows the set standards. We
>can write a simple program in 3-4 hours. We can paint a screen and
>generate an input program with about 20 "header fields" and half a dozen
>repeating fields in less than two hours. We have about 150 "screen
>generated" programs that can have a field added/removed in minutes, like
>one or two minutes.
Well then, isn't this pretty much a 4GL? One thing a 4GL does is INSURE
that standards are followed. Most systems that I have personnally worked
on that did not use a 4GL or even a 3.5GL did not have the
consistency/standards to which you are referring. Usually, legacy systems
have been worked on by numerous programmers, including 'hired hands' that
write code however they want.
I guess this would now be considered my 4 cents worth
Patrick A. Linder