Re: EGL: Integration or Migration?

Aaron Bartell wrote:

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

Actually, Jon Paris coined the term "procedural Java" as a way to express the concept of being able to use the OO capabilities of Java without being mired in the syntax. And I've long said there are two kinds of Java programmers: class creators and class consumers. Class creators are the ones who develop the hierarchies, class consumers use them.

It's not too hard to become a class consumer. Using pre-written classes that take advantage of OO for code reuse is a good thing. But for business rules, procedural syntax is much easier, especially when that procedural syntax makes it easy to package code for reuse.

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

More importantly, EGL (to finally bring this back on topic) provides one of the biggest missing pieces for code reuse: name spaces. EGL allows you to fully "package" (pun intended) your code with package names so that you write procedures with meaningful names without having to worry about collisions. That in and of itself makes it a very powerful thing.

Again, I'm not saying that OO is a bad thing. I'm just saying that it has its place in the programmer's toolkit like everything else, and I don't find that place to be writing business rules.

Heck, these days most of the new features of Java aren't OO anyway, they're aspect oriented. You code using annotations, which to my mind aren't strictly object oriented. But I digress...

Joe