Path: utzoo!utgpu!attcan!telly!evan From: evan@telly.UUCP (Evan Leibovitch) Newsgroups: comp.databases Subject: Whatza 4GL? (Was: SQL = 4GL) Summary: why care? Keywords: 4GL Message-ID: <319@telly.UUCP> Date: 29 Aug 88 16:57:45 GMT References: <5829@ihlpf.ATT.COM> <5266@pasteur.Berkeley.EDU> Organization: System telly, Brampton, Ontario Lines: 96 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.