Re: EGL: Integration or Migration?

Aaron wrote:

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.

To effectively exploit OO, one really has to do some upfront thinking and general design.
Not into much detail, just a simple overview of the different pieces that work together
and how. Not every piece, but the essential pieces. To do this, one first has ta have
a good grasp on what's needed. This is normal good programming practice. But in
practice most programmers start coding away with just a vague understanding of
the requirements. Also, it takes experience, to be a good programmer, to know what
is important in the long run, etc. Most programmers i know just have no clue about
software design and architecture but just try to finish the current project or assignment.
And, worse, they don't care. These programmers can not effectively exploit ILE (i.e.
modular programming) let alone OO.

Making OO designs that are over architected (many *Managers and *Factories and *Builders)
etc and deep class hierarchies resulting in inflexible designs are the sign of an over
enthusiastic programmer with not enough experience. The key is to strike a balance, and
that is true for every aspect of programming. But this takes experience (and i mean
conscious experience).

Point is, applying OO to business apps is good thing, but only if it's applied correctly and
with care (like all technologies). The software much more directly reflects the business
environments. In a modular approach one would have *SRVPGM CUSTOMER with
a procedure getCustWithId(id) which returns a datastructure (custds) with all the customer
data (like custds.name). To retrieve the total ordered amount one would have to call another
proc. in the same sp to retrieve the total ordered amount.
A datastructure is a static thing. With OO, the datastructure would not only have the data, but associated to it. To
also the code associated with a customer. To get the total ordered amount one would invoke
a procedure that "lives within the object", like custds.getTotalOrdered. The difference is that
the code knows about datastructures and procedures, which are completely separated. In an
OO environment the software knows about "customer objects" which have data and procedures
(taken together these two constitute behavior). So it's a further abstraction of the code where
we not only have re-usable code, but re-usable data with it's associated code (i.e. objects).
The combination of the data together with the code is very powerfull. As you may know, the
data and it's representation in a program is most important, the code just follows. Therefore,
re-usable code is fine, but re-usable data-and-code is really powerful.

I object to Joe's constant referring to OO as not suitable for business code as it is not
able to react to change easily is because it is utter Bogus, and i suspect Joe knows that.
EGL is ok as a language (environment) simply because of it's procedural orientation it's
easy to learn and use by most RPG programmer's. Many banks and insurance companies
invested heavily in OO (and still do) in the 90's (smalltalk) simply because of the fact
that it enabled these companies to change the codebase quickly when business conditions
changed. For example introducing a new financial product.

tBut 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 don't think you can say that *DSPF and CHAIN are "frameworks". These are features
delivered as a black box you can use. A framework is not a black box. It is there
explicitly and consists of the basic implementation of several problem domains. This
is code that is explicitly there and which you can extend and build up-on.
Further, i think there is a big difference between *DSPF (5250) and JSF, i.e. the way
the an app with a user interface is architected. JSF is a framework which builds
upon web technology to provide some out-of-the-box functionality to build
a web front-end, which interacts with server code. It supplements the underlying
technology, i.e. http/html, which is rather primitive. While 5250 and *DSPF is
simply the implementation and interface of the user interface technology (like
http and html). Furthermore, web apps are client/server. I.e. the browser always
acts as a client making requests to the server. But 5250 / *DSPF is not client/
server. It's a completely different architecture where the application on the host
(the server) is in complete control and is in fact the client, where the terminal
(browser) acts as the server. In fact, the underlying technology was peer-to-peer
(APPN and LU6.2). Completely different beasts. And we know (we RPG'ers) that
the latter is superior. Because the app consists of one source, where the
source not only sits on the server but also executes completely on the server (in
this case we call it a host). So we have one language and one execution environment.
And a very stable and predictible execution environment. It has only one drawback.
You are bound to 24x80 characters because IBM never bothered to update this
architecture to modern times (i.e. employ a graphical UI at least). So now we must
resolve to the error-prone web software stack to build "i" apps with a "decent"
user interface. And EGL is certainly going to help us with this. Somehow i think
we are throwing away the child with the bathwater. If apps are built with EGL then
we do not have that one language / one environment anymore and i suspect that
the advantage of the "i" is going to diminish if every "i" app is going to be build this
way (although i dont expect this considering the inert RPG community).

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).

In Java you don't have to use OO, just code one main class with only static
methods. But i wouldn't recommend it. The vast array of functions within one
large name-space is a main problem in PHP. To sort an array there is choice
between 10 or more functions, all doing the sort a bit differently. And there
is no consistency between function names. In java the functions are all
organized around object types so it's much easier to find one. PHP is cobbled
together as the language evolved. A bit like RPG actually. Therefore i'm glad
there is EGL which seems to be much more consistent and well architected and
thought-out. I have no doubt that to build a web app with the "i" as back end EGL
is the way to do it. But to shun OO with saying bogus as it's not suited to
business logic just to explain why EGL is procedural and why thats better is
simply Bogus. It is misleading which could result in RPG'ers all holding on to
procedural coding and not trying to investigate the OO paradigm.

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.

It's very true that organizations want web apps because of the easy deployment.
We on the "i" even have much easier deployment. You can say we have the
holy grail of deployment, i.e. one language (although not a pretty one) and
one environment where the source sits and the program executes. But we
want web apps not because of the easy deployment, but because of the
modern UI it can provide to us. But by doing this we leave the simple and
desirable one-language / one-environment. This is kind of interesting.
We don't have an ugly version, it is rather a bit 70's. But hey, old ideas
are often good ideas. GUI's where also invented in the 70's. Host-based
applications (like we have) are a good idea, albeit old. GUI's are also a
good idea. Now we seem to leave those good ideas and replace it with
the (fat) client / server idea, which is not so good for data driven apps (but
more for scientific/engineering). Yes fat client, if i see the enormous amount
of html and javascript EGL produces it certainly is fat client. It complete
app is loaded everytime. The difference with "classic" client/server is that
the compete app is loaded and started from scratch each round-trip (no
shared state which makes things more robust). And we seem to skip
the GUI completely to delve into the "document" oriented interface which
is good for... documents. And interface for which a document-interface
is the natural choice (reports). But not for transaction oriented stuff. There
seems to be a gap somewhere, something that is needed but not there. That
is the combination of some good old ideas. No HTTP, XML, AJAX, Browser
and all this new and cool stuff. But simple host-based execution, P2P networking
for flexible networking and "traditional" GUI's.


gr. john

Date: Fri, 6 Jun 2008 07:10:32 -0500
From: aaronbartell@xxxxxxxxx
To: egl-i@xxxxxxxxxxxx
Subject: Re: [EGL-i] 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 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.

--
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.

_________________________________________________________________
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolie&FORM=MIINTM