Re: EGL: Integration or Migration?

Hi John,

You make good points on some of that stuff. I for one consider myself more
of a "Modular Java" programmer if I could be so bold to coin the term. When
I do development off the i it is most always in Java and I usually employ
the equivalent of *SRVPGM modularity when coding in Java.

The thing about Java is learning to code for initial efficiency and future
maintainability (really, that's the truth for any project). Too many Java
weenies try to drown business processes in OO inheritance structures where
"Modular Java" would have worked just fine, because it created re-usable
code. On the flip side, OO for frameworks make things work much better in
that vein. But that begs a question, being that RPG kinda has a built-in
framework to the OS, DB, and 5250 it has much less need of OO (I am thinking
of Hibernate and JSF when I say this which could be equivalent to *DSPF and
CHAIN/READ/SETLL/etc).

I think EGL has potential to make Java programmers more efficient because
they can replace their Java business logic with a more business logic minded
syntax without leaving the familiar Java environment or development process
(i.e. thinking source control and deployment with EGL is the same/similar to
traditional J2EE).

(ever wonder why most - or all - popular languages all have OO features,

even PHP?).

PHP is an interesting one because it didn't have OO until much later in
life. And as I understand it the PHP OO flavor is much different than Java
or others because you can use PHP without even touching OO (it is more of an
optional feature), which actually makes it more digestable IMO. The PHP
developers found a happy medium between OO and creating their own native
opcodes (vs. having everything basing off of some generic object like Java).

Also note that popular features don't automatically make something a good
thing. Take note how most all frameworks and languages are trying to get to
the panecea of what we've had with RPG/5250 for decades (ease of
deployment/development/maintenance) - we just have an ugly version.

Just some thoughts. I also don't want to get into a language war :-)

Aaron Bartell
http://mowyourlawn.com

On Fri, Jun 6, 2008 at 4:05 AM, john e <jacobus1968@xxxxxxxxxxx> wrote:

Joe wrote:

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.

I really do not like to start another language bashing discussion, but i
had to
response on this.

Again Joe, you are saying that a procedural language is much more capable
to respond to business change than a OO language. I really have to object
(nu pun intended) to this generalization which is completely false and
misleading.
An OO language has more features than a procedural one to organize you're
code
into self contained modules and to make abstractions. Now, with these
features you
you also have more possibilities to make a compete mess with random
dependencies all over. And this happens a lot in practice.

You confuse the practical state of java development on the "i" compared to
RPG. RPG is straightforward (procedural) and heavily integrated into the
OS. Java is not straightforward and is not integrated because IBM did not
invest in it because of lack of interest. The straightforward approach
ensures
that developers without a strong OO skill don't make the wrong abstractions
and dependencies. Yes you have a lot of duplicate code. But this is not as
worse as having random dependencies which makes changing the code
dangerous. . And the integration ensures that simple tasks like retrieving
a record are indeed simple.

Anyway, RPG on the "i" is, in practice, much more productive than Java
on the "i". But this is NOT due to the OO capabilities of Java. To say that
procedural languages are much more capable of responding to business
changes is simply misleading. In fact, when OO concepts are applied with
care and thought, it's the other way around (ever wonder why most - or
all - popular languages all have OO features, even PHP?).

john

Date: Thu, 5 Jun 2008 15:24:36 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: egl-i@xxxxxxxxxxxx
Subject: Re: [EGL-i] 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
--
This is the EGL on and around the IBM i (EGL-i) mailing list
To post a message email: EGL-i@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/egl-i
or email: EGL-i-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/egl-i.

_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/
--
This is the EGL on and around the IBM i (EGL-i) mailing list
To post a message email: EGL-i@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/egl-i
or email: EGL-i-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/egl-i.