evan@telly.UUCP (Evan Leibovitch) (08/29/88)
In article <5266@pasteur.Berkeley.EDU>, larry@postgres.uucp (Larry Rowe) writes: > i sympathize with the readers of this newsgroup that complain that the > ``marketeers'' have co-opted the word 4GL to mean roughly what i defined. > the problem i see is one of communication. That's the problem most marketeers have, too. They talk too much. > when i say 3GL, most people understand what that means. they know what > kinds of programs can be written using the language and they can usually > identify examples of 3GL's. But, the same cannot be said about 4GL's. There is a major point hidden in here. As we know them, 1GLs, 2GLs and 3GLs have all been GENERAL PURPOSE languages. You could do trigonometry, change the baud on a serial port or write a new language with any of them. The major 'generation' step was mainly one of simplicity of coding. Try to program a 4GL to open, set and poll a dumb port attached to a barcode reader (without using a shell escape to stty), and see how far you get. As has been mentioned before, 1GLs, 2GLs and 3GLs have been named AFTER they became common, not before. In fact, I don't remember hearing the terms at all, until companies used them to help define 4GLs. > because there is imprecision > about the definition, people cannot tell what a 4GL means. I suggest that nobody would CARE what 4GL means if marketeers hadn't become involved. There is no question that the current crop of 4GL packages make database applications significantly faster to prototype and code than existing languages. In this respect, they satisfy the 'simpicity' criteria. But they are incomplete. There is still a GREAT number of things which cause 4GLs to poop out and force a fall back to a [123]GL. > if the unix shell, lotus macros, sql, and focus are all to be > considered 4gl's, I don't recall ever seeing the Bourne Shell touted as a 4GL. That's probably because marketers never got hold of it as a separate product :-). > i would be hard pressed to determine whether a particular language > was a 4GL (e.g., is the C preprocessor a 4GL?). I suppose to some, EVERY program which can parse commands can be called a language. What does this accomplish? Further, what purpose is served by cubby-holing each of these things into 'generations'? Such is marketing babble. Computer development is an ongoing process. Categorizing items of similar levels of accomplishment is for historians, not the people who create product names. > my objective is to define what a 4GL is so that people will understand what > capabilities that can expect from a 4GL, hence what kinds of programs can > be written in one. The confusion surrounding the database application > development languages (my notion of a 4GL) has hurt the progress of their > development, adoption, and eventual standardization. > i think the biggest problem in the area of database application development > is that there are no *standards* for 4GL's. Your problems will go away when you stop calling these products languages, and start calling them what they are: applications development systems. Or call them Fred. Whatever. Let the marketplace concentrate on what these packages offer, not what they're called. DBMS makers have painted themselves into a corner by developing PROPRIETARY products, and calling them languages. They didn't forsee at the time the massive confusion this would cause, as the marketplace tries to reconcile 4GLs with conventional concepts of what languages are. There is a significant difference between 3GLs, which are generic but have proprietary implementations, and 4GLs, which are TOTALLY proprietary in syntax (look at all the supersets of SQL), file structure, form design, etc. The makers of 4GLs have nothing to gain by applying standards, so don't hold your breath for them. > [4GLs] do not support good program structuring mechanisms, [...] > sophisticated program management tools, [...] source-level debuggers, [...] > or extensible environment facilities [...] If you accept my premise that these are not 4GLs languages, this makes sense. Availability of these extra tools depends totally on the company making the 4GL. > *THE BOTTOM LINE* > maybe we have to argue about the definition of 4GL before we can get on > to these issues. Maybe we should choose to use programming tools based on their merits, not their generation. Productivity always beats arguing. -- Evan Leibovitch, SA of System Telly, located in beautiful Brampton, Ontario evan@telly.UUCP / {uunet!attcan,utzoo}!telly!evan The advantage of the incomprehensible is that it never loses its freshness.
kbc@mdbs.UUCP (Kevin Castleberry) (09/04/88)
In article <319@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >Try to program a 4GL to open, set and poll a dumb port attached to a barcode >reader (without using a shell escape to stty), and see how far you get. > Knowledgeman integrates a communications programming language that should have little problem implementing this. I don't know if KnowldegMan should be classified as a 4GL or not, but it meets the criteria of most of the definitions I have seen here. ... > >Your problems will go away when you stop calling these products languages, >and start calling them what they are: applications development systems. >Or call them Fred. Whatever. Let the marketplace concentrate on what these >packages offer, not what they're called. That's what we call KMAN, except we use the term environment instead of system. >Maybe we should choose to use programming tools based on their merits, not >their generation. Productivity always beats arguing. That's what keeps me using KMAN and/or GURU. For developing clean, friendly applications that solve real world problems they are hard to beat. Technical Support for mdbs products: KMAN (a relational db development environment), GURU (an expert system development environment), MDBS III (a post-relational high performance dbs) (Our products run in VMS, UNIX, OS/2 and MSDOS.) is available by emailing to: support@mdbs.uucp or {rutgers,ihnp4,decvax,ucbvax}!pur-ee!mdbs!support The mdbs BBS can be reached at: (317) 447-6685 300/1200/2400 baud, 8 bits, 1 stop bit, no parity Kevin Castleberry (kbc) Director of Customer Services Micro Data Base Systems Inc. P.O. Box 248 Lafayette, IN 47902 (317) 448-6187 For sales call: (800) 344-5832
dc@gcm (Dave Caswell) (09/05/88)
In article <985@mdbs.UUCP> kbc@mdbs.UUCP (Kevin Castleberry) writes:
.That's what keeps me using KMAN and/or GURU. For developing clean, friendly
.applications that solve real world problems they are hard to beat.
.Director of Customer Services
.Micro Data Base Systems Inc.
Boycott companies doing advertising in comp.databases. Thanks.
--
Dave Caswell
Greenwich Capital Markets uunet!philabs!gcm!dc