Re: EGL: Integration or Migration?

Brian wrote:

I fall into the "little bit of both" camp. While currently employing
RBD/EGL as my "SDA for the Web", I'm increasingly questioning whether
EGL could/should be used as the single development language for
business apps. Although it's not RPG, isn't this what Aaron is asking
for; a single business application development language that allows
modern interfaces to IBM i data? Most i folks will take up RBD/EGL for
integration initially, but I think after using the product some may
well start to question the validity of migration. With the benefit of
deploying the same code base to multiple platforms by just modifying a
build descriptor, ISVs will surely be making this assessment.

Personally, I don't feel that anybody will rewrite their order entry systems in EGL. I've been wrong before, but there's just no way. Same with an MRP generation. And in fact, that's my measuring stick: if an EGL-generated MRP program can't do a generation within 100% of the time of a native RPG solution, then EGL isn't a viable replacement. That's in fact *exactly* what I told my attendees yesterday at the conference: EGL is a great integration tool, but it isn't something you would us to rip and replace existing logic.

The question that needs to be answered is what does RPG provide the
business application developer that's not available in EGL? With its
CHAIN, READ, UPDATE and WRITE opcodes, RPG has tight integration with
the database whereas EGL uses SQL for its data access but other than
for random access to a single row, is this really a drawback?
What would be on your top ten list of RPG features that aren't
available in EGL? How probable is it that the EGL development team
could/would address these missing features?

Well, there are two reasons that Java hasn't replaced RPG: productivity and performance. When I talk about productivity, I mean how fast you can respond to changes in the external business environment, and as a procedural language RPG has that down all over Java. Now, the fact that EGL puts a procedural face on Java takes away a lot of that argument. EGL is the Java that Jon Paris could get his head around. However, that still leaves performance, and I'll stick with my 100% goal. It's not that you can't do random access from Java - the Java toolbox supports this quite nicely - it's just not fast enough.

The fact that EGL generates COBOL might address that issue, but somebody needs to prove to me that high-end applications can be written that way.

As to the top 10 features, there's little in RPG that makes it more palatable than EGL except its integration to DB2. The fact that RPG is so close to the database is what makes it so powerful. Most of the language constructs, especially things like procedures, are actually done better in EGL. But when it comes down to just plain blisteringly fast business logic, I'll still do my work in RPG.

Joe