RE: Advantages of RPG -- RPG400-L

IMHO, (and sorry to repeat myself), the real advantage of RPG is it's midrange heritage, and it's intergration with the OS. The language itself, i.e. the ability for a programmer to express it's intentions in readable, maintainable and extendable code is quite limited, and i think this is an important feature of any business language. Because especially in a business environment, the program source is a means of communicating with fellow programmers, now and in the future.

The thing i mostly miss in other languages is the lack of a native decimal type.

But to use decimals in Java, you dont really have to use the BigDecimal class everywhere. Problems only occur when you have to divide or multiply two decimals. So a good practice is to simply work with integers, and when you have to multiply or divide you convert the integers to BigDecimals first. This keeps the code clean.

Furthermore, business apps does a lot of I/O and not so much processing. And with it's OO nature you can easily encapsulate code to hide the somewhat ugly code, like someproduct.calculateTax(quantity).

What i miss in RPG are the many collections you have in Java. In RPG there is just the fixed array, which is quite primitive (it's simply a reference to a continuous block of memory). I regularly see a hundreds of lines of RPG code which does a lot of data sorting using several arrays which could be done in Java with 5 lines of code simply using a Map for example. And in business apps, sorting and manipulating data is very common.

So, of course, every language has it's pro's and cons and i think Joe makes Java look much worse for programming business apps than it really is.

And performance of BigDecimal is not an issue, because business apps operate in a I/O bound environment. The difference in performance between integers and BigDecimals is therefore negligible.

Date: Mon, 23 Jun 2008 10:02:16 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Advantages of RPG

David Gibbs wrote:

Fixed point decimal for one.

I don't think core C has a such a concept. I'm pretty sure that the
early versions of Java didn't have such a concept either. In fact, the
support it currently has are not native implementations ... they are
Objects (BigDecimal).

Exactly, David. And in fact the BigDecimal implementation in core Java
performed so poor initially that IBM created their own; you had to
choose between them. And to this day, BigDecimal still has issues; you
can't simply add to a BigDecimal; you have to reassign it to itself:

BigDecimal bd = new BigDecimal(1.1);
bd = bd.add(3.4);

I realize this is to allow chaining of operations, but even that is evil:

BigDecimal tax = quantity.multiply(unitprice).multiply(taxrate);

Joe

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/