× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Aaron Bartell's RPG/Java comparison
  • From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 15 Feb 2001 09:23:22 -0600

From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
----------
>Right.  So you're supporting my point that the langauge used has little to
do with it and the programming does.  Also, Java doesn't solve these
problems, which is why it is more theory that reality.  In theory, you can
do all this wonderfull stuff with Java.  In reality, rarely does it get done
that way.  The same applies for any language.
----------

I disagree 100% with your "point".  While it has been proven mathematically 
that any progamming task can be performed by any language with certain base 
functions, that by no means means that "all languages are equal".  Each 
language has areas where it functions well, and areas where it functions 
poorly.  The language DOES matter.

There are languages specifically designed to support parallel processing, and 
other languages designed for graphics.  I could do the same things in RPG, but 
it would be a very inefficient and time consuming venture.

For UI programming, RPG is inadequate.  It is much easier to present 
dynamically formatted text information in languages such as Perl, Java or even 
BASIC than it is in RPG.  On the other hand, RPG's native interface to the 
database makes it the language of choice for transaction server programming.  
RPG's ability to read a record, add two values (without reformatting of any 
kind) and then write a new record is fairly unique.  SQL can do some of that, 
but is woefully inefficient, especially when it comes to conditional database 
navigation based on data settings, which is the core of most business 
processing.

Java, on the other hand, is wonderfully suited for UI presentation because of 
its use of polymorphism and inheritance and its strict adherence to an object 
model, allowing the full gamut of design patterns.  By creating factories and 
adapters and decoration classes, it is possible to completely change the 
presentation of a data model without resorting to any conditional code in your 
application.

So, once again, I turn to my design of choice: Java UI connected to RPG 
transaction serving.

Yes, I could do it all in RPG, with some very cleverly designed service 
programs and a whole lot of foundation work.  I've done similar things in the 
past.  However, that foundation work is already available in Java.  The only 
reason not to use Java would be if I didn't understand it.

Write some real code in Java, Brad, before you start talking about the "theory" 
vs. "reality".  In reality, proper use of polymorphism and inheritance can 
easily double or triple your productivity, if not more.  In reality, learning 
to program to interfaces rather than classes and learning when to use "contain" 
rather than "inherit" and understanding how to keep your interface clean will 
make the language a powerful tool.  In reality, after maybe a hundred thousand 
lines of code, you may begin to appreciate the nuances of the language.  And if 
not, you'll certainly have earned the right to take potshots at the language.

Joe

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.