Update 4GLs

By Fred Hapgood, CIO |  Development

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.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness