Analysis

EGL - A Different Programming Language

David Norfolk By: David Norfolk, Practice Leader - Development, Bloor Research
Published: 4th August 2008
Copyright Bloor Research © 2008
 Logo for Bloor Research

IBM is currently promoting a new business-oriented programming language called EGL. Shades of COBOL (COmmon Business-Oriented Language)! Why do we need a new language at this stage? Surely, Simula 68 was the last new language we really needed?

Well, we were talking to Tim Wilson and other members of the EGL team recently (visit their blog at EGL Cafe) about just this thing. We first of all agreed that we'd taken a huge step backwards with the return to low-level languages in the 1990s. If (to quote Bloor's CEO, Justin Speake) "the term 4GL [is used] to describe an abstraction level...CASE [Computer-Aided Software Engineering] sort of being 5GL and true BPM [Business Process Modelling] being 6GL", COBOL is a 3GL and C and C++ are more like 2GL (1GL is machine code; 2GL Assembler), then we dropped a couple of levels in language abstraction around 1990. Wilson points out that other features of C++, Java etc. (such as frameworks) compensated for this, but the fact remains that business people don't really "get" Object Orientation but do understand (with a bit of help) the procedural flow even in COBOL; and can often work directly with 4GLs and BPM.

So, one reason for EGL is to produce a modern language, which takes advantage of all we've learned about frameworks and similar innovations; which relates closely to the way that business people think about automation (it's based on a lot of user research); and which abstracts away the things that programmers find difficult (such as database access). It will also learn from the comparative failures of previous 4 and 5GLs - it presents a "clean" programmer-style feel and is absolutely non-prescriptive about Process (we remember just how prescriptive, and annoying, things like Information Engineering could be).

But there's another reason for EGL: legacy modernisation. Much of the automation in businesses today runs on "legacy" platforms: mainframes. And it is written in languages like COBOL; and these legacy applications represent many man-years of resource investment and much practical "business knowledge" (they also often run the business). EGL is based on years of IBM experience with code generators, so it "compiles", not into machine code but into COBOL or Java (or potentially any other language your platform expects). This ensures portability (if your platform has a COBOL compiler, ISO-standard COBOL is almost guaranteed to run correctly; COBOL is even more of a "write once run anywhere" language than Java) and (equally important) clean interfaces with existing code. Plus, of course, there is some resistance to learning COBOL these days and EGL allows you to program for legacy environments in an absolutely up-to-date way. The main downside of compiling into another high level language instead of machine code, is that the programmers must have the discipline to resist the temptation to fiddle with the generated code, and resolutely maintain just the EGL source.

So. it's best not to think of EGL as generating code but just as "compiling", like any high-level language (after all, COBOL itself is simply a code-generator for machine code) It's all rather a matter of semantics. EGL is a high level business-oriented language (like COBOL) which compiles into "read only" Java or COBOL for portability. It integrates with Rational automated development tools (for configuration management etc.)—and, most interestingly, it might be the "sharp end" of a model-driven development environment such as the OMG's MDA—that, at least, seems to be IBM's ultimate objective.

How does this make EGL different from a 4GL? Not very, in any fundamental way, in our opinion, but people associate 4GLs with proprietary code and a restricted environment. EGL offers a much cleaner, language-like environment. How is it different, then, from an application generator like IBM's ADF2 from the last century? Well, again, not very, from one point of view; but once again, it carries less baggage and is more part of a "normal" development environment. So, how is the EGL environment different from a a 1980's CASE Tool? Well, again, not a lot in theory; except that (as we've said) CASE tools were usually very prescriptive about Process and EGL isn't. To reiterate, EGL relates to Javascript, C++ and so on much as COBOL relates to Assembler, but it has also learned things from modern developments such as Java frameworks etc.—so, for instance, it really simplifies database access for general programmers.

EGL is currently available in 2 products from IBM. The "full thing" is IBM Rational Business Developer with EGL (see here), which is rather more than just EGL. It is best to think of EGL as just part of a development platform as a whole—and this "5GL" platform is Business Developer. You can learn more about Business Developer in "IBM Rational Business Developer with EGL" by Ben Margolis (ISBN 978-1-58347-066-4)—you'll probably get a free copy from your IBM sales rep if you ask nicely.

However, as well as this, "Rich UI" is available on Alphaworks, and this demonstrates that EGL certainly isn't restricted to legacy COBOL environments—there's a FAQ here. The Rich UI framework lets people develop rich "web 2.0" applications (whatever that means—AJAX, REST and all that stuff in this case) and, interestingly, hides the EGL-generated Javascript code involved and makes it truly "read only". Which (with our Internal Control background) tends to make us much more comfortable with its use in its target, somewhat undisciplined, environment.

Let's now look at some of the obvious questions about EGL, such as where organisations today will find it valuable:

  • Anywhere you want to develop high level business logic and not worry about platform-specific detail (for example, if you want developers to code new business logic for a legacy mainframe COBOL environment without having to learn COBOL).
  • This applies to non-mainstream platforms generally, such as IBM iSeries; zOS and CICS mainframes; IMS database.
  • It will also be useful for developing business logic, in consultation with business domain experts, for (for example) modern JSE and JEE platforms

Usage scenarios we envisage include:

  • Cross-platform development generally.
  • Legacy modernisation—this may well be the first killer application for EGL but it certainly isn't all it can do. There are other approaches to legacy modernisation (check out Micro Focus, for example), but more choice is very welcome.
  • Getting your existing, experienced, programmers, used to conventional client server environments, to develop effectively for new platforms such as REST—in a short time.

The people using EGL will include:

  • Legacy coders in languages like COBOL
  • Conventional procedural coders beginning to develop for SOA and REST
  • In our view, just about anyone coding business IT development—developers should be thinking about business logic not C++ garbage collection. Although you wouldn't use EGL for writing operating systems, device drivers and compilers....

Now, is there a downside to EGL? Certainly, because it will probably meet cultural opposition from a lot of the people currently involved in IT. Many of them, even managers, got where they are by being very good at coding low-level Object Oriented (OO) languages for specific technology platforms. EGL is procedural rather than OO. This is no huge problem for people to understand what this means (remember that a lot of so-called OO programming is really procedural code playing about with objects) but it may meet opposition from people whose careers started with the elimination of procedural programmers in the 1990s OO bloodbath. However, EGL will involve a change in development culture, to focus on business service delivery and business outcomes. This is just like ITIL v3, which probably means that the time is now ripe for EGL, although ITIL v3 is also meeting opposition from older, silo'd, service delivery cultures.

Never underestimate the management investment needed when changing technology cultures, even after the technology arguments have been won. People mostly dislike change and react dysfunctionally to it—if you doubt that, try asking your change management department to change the way it works. However, the effort involved in changing to a "business service delivery" culture, of which EGL (we think) is a part, will be worth it.

Reader Comments

Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.

5th August 2008: 'Simon Williams' said:

Interesting but not new – EGL has been around for quite a while. It started life in 1981 as 4GL, the procedural language in IBM’s CSP (Cross System Product) mainframe application generator, and was renamed to EGL (Enterprise Generation Language) as part of IBM’s WebSphere Studio Enterprise Developer announcement in 2002.

Reply to Simon Williams?

5th August 2008: 'David Norfolk' said:

Simon, that's a fair point. No, it is not "new" as a language, although I think it has been fairly recently "revitalised", and perhaps I should have made that clearer. But the "Rich UI" environment around EGL is pretty new. And as I said somewhere, it's best to think of the development platform around EGL as a whole.

Besides, I think EGL will be "new" to many mainstream readers anyway.

Reply to David Norfolk?

7th August 2008: 'tslate' said:

All due respect, any OO language is going to have some procedural code in it in order to make the relationships work. Objects are all very nice until one has to either couple or de-couple them to a database, which is altogether yet another form of relation.

Me, I've been writing code for 25+ years from Assembler to "OO" languages like Java and C++. I'm comfortable in any environment or language, etc.

The point is very simple. I do not trust the same people who are responsible for the current mess to unravel it. It's just another stepping stone in total control. IBM is saying, okay it only took us 50 years to get it right, but trust us now and move everything to EGL. Then we can unplug all other compilers for end users(that’s me) and get rid of programmers altogether. They have done it before.

There are too many issues to discuss but the larger body of IT is way ahead of IBM.

Only IBM thinks the IT world still revolves around them. EGL is just another useless idiotic scheme to garner even more control for themselves. No real programmer is going to use EGL unless it's forced. IBM is making a serious tactical error (surprise) with EGL. It will just drive those that support those systems away and into the waiting arms of SUN, HP and MS.

The IBM rhetoric surrounding EGL (not here mind you) has taken on the same bitter tone it always does, well the "programmers" aka "coders" really never got it right, they really don't understand. So here's our new medicine, so all the simple minded people can get it right, because as the "best" of computerdom we say it's so.

IBM's best days were hardware, now that's no longer true (as far as the competition). What's left remains to be seen. The idea of legacy modernization has meant moving "away" from IBM not toward it. EGL is a last ditch and failed attempt at stemming the tide. Mind you I've worked on IBM mainframes but mostly mini line using legacy languages in the past. IBM could approach this far differently and succeed but a totalitarian approach just isn't going to work. Unfortunately I think illegitimate spawn of guys who dreamed up COBOL invented EGL.

I just don’t think claiming genius for yet another tortured code generator works and worse claiming it will correct the mistakes of all IT staff (aka simple minded) is a great marketing tool. If their game is to pull the compilers from programmers then I hope they fail miserably because so far that’s all I can see. And if IBM’s past is any indication they have no problem doing just that.

If businesses did not need individuality and uniqueness in their systems then there literally should be only one source code tree from which all software is derived, it just ain’t so. It reminds me of Gates idea to put a digital painting on the wall so that when you tire of viewing Mona Lisa you can switch to another great work of art. Idiots!

Reply to tslate?

7th August 2008: 'David Norfolk' said:

Well, that's a POV.

>> Unfortunately I think illegitimate spawn of guys who dreamed up COBOL invented EGL.

But COBOL was mostly dreamed up by a woman, the truly-onderful Admiral Grace Hopper a9see Wikipedia). Perhaps why it does what it does (describe business logic) so well...

Reply to David Norfolk?

7th August 2008: 'Steve Walkley' said:

The Simon Williams from Synon perhaps?

Reply to Steve Walkley?

8th August 2008: 'Simon Williams' said:

Hi Steve, yes it is.

Reply to Simon Williams?

8th August 2008: 'David Norfolk' said:

Simon, Hi again! I did wonder! What are you doing these days? Email me with an update if you like...

David

Reply to David Norfolk?

7th August 2008: 'Aaron Bartell' said:

It's really too bad IBM felt the need to revitalize CSP to EGL when it could have continued it's vitalization of one of their most solid application stacks to date which is RPG + DB2 + OS400. That combination has second to none simplicity concerning ease of programming modularity, integrated/seamless database access, and integrated language into the operating system without needing to sit on top of a virtual machine like how Java does.

Sure they have made steps forward with EGL, but they are starting from ground zero with needing to convince a customer base that it is worthwhile to pursue vs. making enhancements to RPG.

Aaron Bartell
http://mowyourlawn.com

Reply to Aaron Bartell?

7th August 2008: 'David Norfolk' said:

Yes, RPG - and OS400 - are something special. But RPG does seem to polarise opinion rather.

DB2 on OS400 is special too - I'm not sure it's really the same database as DB2 elsewhere.

I guess there are many ways to skin a cat - and people on iSeries are just lucky....

Reply to David Norfolk?

7th August 2008: 'tslate' said:

Now were being silly. “guys” is a euphemism for both sexes obviously unless of course you’re 80+ which means gay does not mean homosexual.

Well congrats to the Admiral, unfortunately I’m not sure COBOL goes down as a great anything just what was available. Besides, the invent part is a bit of a stretch considering it took many engineers and layers of technology to produce COBOL.

But according to your source she did not invent it anyway. From Wiki:

“She later returned to the Navy where she worked on validation software for the programming language COBOL and its compiler. COBOL was defined by the CODASYL committee which extended her FLOW-MATIC language with some ideas from the IBM equivalent”.

I already knew she was associated with COBOL but worked on it is not invent it.

Here’s a tortured version of “why” IBM invented EGL.

ftp://ftp.software.ibm.com/software/rational/web/whitepapers/RAW14018-USEN-00.pdf

Much of which dances around the notion of how difficult things are and how EGL fixes it all. IBM has tried this type of thing before – failed SF Project (see DDJ http://www.ddj.com/windows/184415597) and has also blocked compiler and machine access historically.

If it’s true that the average developer has a difficult time implementing technologies, which is probably more of a validation that there is a dearth of mediocre programmers who are really in it because it pays well and maybe all those inventors (like IBM) who think they’re ingenious, well just maybe aren’t. You cannot fix lack of ingenuity nor “generate” it.

Quote from IBM pdf above:
“EGL is a modern programming language specifically designed to help business-oriented developers leverage the benefits of mainframe and Java platforms without having to learn all the details. Enabling your developers to focus on the business problem…..”

I always get a kick out of that tired phrase (allowing programmers to concentrate on the problem).

The irony of this thinking is that the same programmers that find core technological concepts too difficult(according to IBM) are now going to be wizard visionaries tackling the most complex business processes using EGL. ROFL!

No code generator will fix 50 years of mangled thinking that created the IT mess. EGL’s time was about 2 decades ago. The thinking that created all of IBM OS ‘es is many more decades old. Again IBM misses the software mark. The most popular OS’es in the IBM line are the nix variations which all grew from Unix which they did not invent including probably the most popular Linux.. For IBM it’s time to go back to build only hardware and use others OS and compilers.

Sorry I tire of IBM's attempt at controlling everything.

Reply to tslate?

8th August 2008: 'David Norfolkj' said:

Yes, I did read the Wikipedia article I quoted - and I abstract away from the bits and bytes these days. Somewhere the article also says that COBOL largely reflects Hopper's philosophy - which is (I think) the important bit, not who was on the Codasyl cmmittee that actually wrote it!

And sorry if this reply isn't perfectly crafted - my laptop is balanced on my cases in a crowded train out of Gatwick...

Reply to David Norfolkj?

9th August 2008: 'RDean' said:

"Sorry, I tire at IBM's attempt to control everything?"

Really? You seem awfully invested as a loud and vocal dissenter. If you were *really* tired of it, you'd ignore it, like so many others with the attitude you claim to possess.

Personally, I find the concept of EGL novel, because it raises the abstraction level higher. One opportunity I think IBM is missing is that EGL should generate idiomatic Eclipse RCP and .Net WinForms applications as well as COBOL, Java/JSF, and Rich UI.

Reply to RDean?

12th August 2008: 'tslate' said:

To RDean:

Like others of your ilk your only comment comes not from original thought but to ding someone else. You could have just said your peace as is, but since you clearly wanted to “put me in my place”.

"if I really tire of it I would ignore it" is illogical. If I’m tired of something I usually react to it, like so many others of “my attitude”.

I said "sorry" in deference to the author. Only those with truly vested interests such as myself will certainly take strong opinions borne from experience.

OTOH bloggers like yourself will attack someone else as opposed to debating the issue.
The comment "because it raises the abstraction level higher" definitely states your approach to IT, elegant but immature. It is a meaningless non-sensical approach to software engineering, by acronyms. All languages are abstractions of machine language at some level.

I stand by my statements, which are correct. EGL will fail, in fact, IBM has already started to circle the wagons regarding their machines. As much as everyone wants to believe that IBM's proprietary OS'es will survive, they will not, that's already self-evident. If the proprietary OS'es don't survive whose going to shell out mega-bucks for further EGL development and licenses? The IBM machine cannot survive without those huge maintenance contracts that EGL would be a part of. No ones going to buy. EGL to modernize , modernize where? There's already 100's of products to support that effort which are very successful. For EGL to be successful, it has to be an IBM box, and no one wants to be stuck on the proprietary OS'es in a decade. So why would anyone risk getting locked into another code-generator by IBM, does that make sense to you? Yes, EGL is getting a lot of press because of the IBM marketing machine. But you either don’t know the market or are just plain naïve if you think it will gain any kind of foothold in true software development shops. IBM has missed the boat on EGL. All IBM OS’es, including COBOL and RPG were designed as a complete systems. The IT world is no longer like it was when these products were introduced. With the advent of EGL IBM still persists in the notion that they know best and that IT is a singular closed problem that is just waiting for one answer. The article by IBM that I cited clearly states that EGL will not solve all problems, but if you know IBM they actually believe the opposite, that it will. Why else go to all the trouble to produce EGL and keep making mention of how it’s too difficult for the poor average developer, just to replace COBOL? Of course, it’s classic IBM. Buy this one complete system, this one way and nirvana will surely follow.

IBM thought that SNA was better than TCP, now TCP is ported to IBM’s machines and used instead. IBM thinks EGL is the answer, history will tell, my bet is they’re wrong again.

Now if you think EGL is the way and the truth and IBM is the one, then debate that. And there’s nothing wrong with being and loud and vocal dissenter, that is if you have something to say. If you having something original to say regarding how or why EGL will be very successful then someone may be interested but otherwise buzz off. I abhor when a blogger cherry picks statements and then just takes the opposing side for no other reason then to argue or to try some useless psycho-babble . Put some collective thought together of your own. You can debate things that I stated but personally attacking me or trying to “tell” me how I think is BS.

Reply to tslate?

14th August 2008: 'RDean' said:

Slow down there, sparky.

Nothing in my reply to your message was a personal attack.

You say I attack you personally, when you do such things as calling me a "blogger" (which is untrue to start with, and an interesting choice of epithet). The favorite, though, has to be where you take my characterization of higher-order abstractions as "novel" to mean I'm somehow immature.

You said that all languages are abstractions of the hardware they run on. Building languages as an abstraction of the machine is an outmoded concept in today's multi-device, networked world. What we need are better, higher-order abstractions that can do more of the developer's work for them. EGL may or may not fill that need in practice, but conceptually, the idea makes sense.

Reply to RDean?

The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.