IN JANUARY 1990, CIO ran a double article weighing the value of the so-called "fourth generation languages" or 4GLs. These were and are special-purpose application builders customized to specific application domains, such as generating business reports. They are contrasted to general purpose languages (GPLs) or "3GLs," like Cobol or Fortran or C, with which a skilled programmer can build almost anything.
These articles were not, as is sometimes the case, introducing a radical innovation that was shaking up the IT landscape. 4GLs had been on the market, competing with the various 3GLs, since the 1970s. Their selling point was simplicity. 4GL functions were expressed in ordinary English and linked together with everyday syntax. (One offhand definition of 4GLs is "a language that can be learned in two days.") They achieved this simplicity by reducing the most common operations to single commands. A typical 4GL instruction might read: "Extract all customers where 'previous purchases' total more than $5,000." The same statement written in Cobol would run to the end of this article and beyond.
Since each statement taken alone was more powerful than an average statement in a GPL, 4GL programs were shorter and therefore easier to understand and maintain. Thus even those skilled in GPLs might choose to work with a 4GL because at least in theory they could do the same work with fewer statements. According to Gerald Cohen, CEO and founder of Information Builders in New York City, which introduced and still sells one of the very first 4GLs (Focus), "3GLs told the system how to do the application; 4GLs told it what to do."
Nonetheless, the CIO pieces did not add up to an enthusiastic endorsement of the technology. Since each command was like a little program that had to be separately executed, 4GLs were slow. They cost money, whereas most 3GLs came free with the hardware. Most important, 4GLs worked well only for their own problem domain. If any aspect of your project called for a function unanticipated by 4GL's designers, you were back paging through the manual of Cobol commands. An IT worker might as easily decide to stick with his 3GL as take a flyer with one of the new languages -- and many did. "4GLs were like houseboats," Jay Valentine, once a 4GL sales rep (and now CEO of InfoGlide in Austin, Texas), remembers today. "Not very good houses; not very good boats." The article reflected that ambivalence.
In the early '90s, 4GLs found a new opportunity and identity. By their nature the programs focus on the most burdensome task faced by IT personnel at a given moment. In the 1970s and '80s, that task had been writing programs that supported business reporting, that is, routines that pulled data out of a large, complex database running on a mainframe, processed it, configured it to the requirements of a given form and mapped it onto a screen presentation.
By the late '80s and early '90s, business computing began moving in several directions at once. Networks were migrating from terminal/host to client/server (and growing much larger and more heterogeneous); databases, from indexed to relational systems; operating systems, from proprietary languages to Unix variants; and end user interfaces to the Windows model. All the applications and files that had grown up in the mainframe/mini world needed to be ported into this dynamic, nearly chaotic, environment. There was no time to rebuild all these legacy resources, especially since the pace of change ensured that the job would just have to be done again in two weeks. The central task of IT personnel became finding ways of gathering up all these cats and lashing them into a common harness..
4GLs turned out to be ideal for the purpose. As before, their job was to isolate users from complexity, only now the complexity in question came not from programming languages (alone) but from a proliferation of operating systems, database types and application deployment models. The essence of the technology changed from application development to legacy management. In this model, 4GLs kept a reasonably stable interface, thus minimizing retraining costs, while vendors (such as Computer Associates and Cincom Systems) kept expanding the list of environments that 4GLs understood through frequent upgrades.
In the mid-90s, several trends arose that seemed favorable to the technology. Faster processors cut the performance penalties. Prices went down. The internet, with its webcentric browsers and distributed database querying, threw up another wave of complexity that 4GLs could shield grateful users from. 4GLs, with their mainframe origins, seemed perfectly positioned to address the internet-based popularity of server-side applications.
Indeed, the need turned out to be too great to be confined by a single software category. Every computing context started to demand specialized application development tools, from web pages to server systems through the whole middleware revolution. Perl arose, as did HTML -- both occupying niches that once might have been the property of 4GL tools. Graphical development tools emerged that undercut the language metaphor that had characterized 4GL technology.
Symbolically, programs were even developed that retranslated legacy 4GL code back into Cobol, where it could be more conveniently handled by newer middleware application development tools. The idea of a toolkit specialized to particular application environments became so pervasive that 4GLs lost their own identity. In a sense, that is testimony to their ultimate success.
This story, "Update 4GLs" was originally published by CIO.