Re: MODERATOR ALERT - Not true in my world -- JAVA400-L

Paul Holm wrote:

I'm talking about all levels of programming.  I've effectively used these
techniques on applications of all size and they work.  The framework handles
common processing, you tack on your custom processing.  This is the
industrial revolution for software.  The ability to pump out mass
application with the easy ability to customize where needed.  If you would
like, I can show you overridden code of any complexity.  The process is
gather your data, make your decisions, return your result to the framework.
If no complex decisions need to be made, I do nothing and the standard
framework processing handles everything needed.

I agree with you totally. I showed a very abstract example where you can achieve business programming by overriding methods. Furthermore when using good frameworks, you have plenty of extension points where to addon your individual stuff, the advantage is that you will find it quickly instead of going through function collections.

If you truly analyze the time you spend developing an application you will
find that the majority is spent on recording task as I've explained.  Your
custom logic of pricing, MRP generations, etc is probably a distant second
in terms of time spent. As you mentioned, to do those calculations, you are
getting data, etc.  The framework can get, cache, query, update, whatever
you need without effort.   Therefore I know solving these reoccurring
problems would yield far more benefit to your productivity than being
concerned weather Java can handle BigDecimal precision, and if then else
logic.

I observed that a lot of time is spend in the db query parts of programming, where people have to recall correct db field names, creating keys and stuff like that. With a good persistence framework, you can minimize this greatly. If you go a step further and choose a transparent persistence mechanism like JDO, you save really a lot of time compared to manually create keys and recalling field names or knowing formatnames. Embedded SQL in RPG makes it even worse, because you throw away time by writing SQL.

RPG would probably win in a performance race depending on the situation.
Again, I'm not anti procedural nor anti RPG.  Leverage them where you can.

Of course RPG is more performant on the iSeries, especially RLA seems better than SQL/JDBC on the iSeries, but thats another story.

> I disagree again. Frameworks can handle the routine work, you add you

custom logic where and when needed.
To produce business applications of any type, you need to incorporate these
common reoccurring requirements.  How many applications (even your MRP) that
you write don't involve selecting records, updating, displaying, processing,
validating, inserting, etc?

As I mentioned as a friendly educational and learning project, if you want
to challenge your approach against what OO can provide, I'm ready.
(Actually I'll be at a client next week so I'm ready this week  :^)

I am also quite positive that you can do all those things in OO, because thats exactly what my company does :-) I heavily rely on MVC Frameworks to do daily programmings business, they provide hooks where i can implement custom logic without any problem. What i really like in RPG, they incorporated the MVC pattern many years ago and they got it right. So RPG is in many respects not too much different from Struts, but Frameworks like Struts go a step further by providing great validation hooks and some more important ideas for application development in general. Of course it can only be used in Webbased applications, but similar frameworks exists for Desktop Development.

There is one spot where RPG beats them all. Reports! The idea with PRTF and RLU and other stuff in this area is still great and with Java, you have a hard time to create good reports. Normally you get them by doing:

1. XSL/FOP -> gives you a hard time and takes long
2. OpenSource Report Generators -> not too mature
3. Commercial Report Generators -> not too cheap

Unfortunately, if you have a lot of Java stuff on your iSeries and recode some of your RPG stuff, you dont like calling RPG just because of the Reports, perhaps its not a bad idea at all, just feels odd.

Again, i dont have anything against calling RPG modules/programs where business logic resides. When you are converting some part of a very large application, you have to do this anyway. IBM created the PCML stuff for that and i like that approach, its transparent and elegant. I prefer this way instead of going via RPG-StoredProcedures and JDBC.

Marc Logemann