Re: The value of ILE

This is crazy. You left out the number one advantage of ILE. Service
Programs. Programs are slow to call but the big problem is that this have a
single point of entry, ie one function. Service programs export procedures,
1 to whatever. You can break things down into small pieces. Small pieces of
program logic. You can encapsulate your business logic.

The example that I always use was the first service program that I wrote in
1994..

Our company had an extremely complex method of calculating prices. It took
a lot of logic to come up with a price. What had been done previously was
the usual RPG III thing of putting the same logic with different
implementation in three different programs. To make a change meant going to
three different programs and changing three different versions of the logic
and retesting everything. Even the simplest change was a mufti-week
project.

Instead I created a service program (lets call it ORCPRI) that had four
different functions (procedures).

1. BasePrice = ORCPRI_GetBasePrice(ItemNumber) - Get the base price without
discount.
2. CustomerPrice = ORCPRI_GetCustomerPrice(CustomerNumber: ItemNumber,
DiscountDate, SaveDiscountDetail) - Calculate customer prices with
discounts for a given date and save detail true or false.
3. Count = ORCPRI_GetDetailCount()-Get number of discounts.
4. OneDetail Record = ORCPRI_GetDiscountDetail(DetailNumber)

Now ORCPRI_GetCustomerPrice calls ORCPRI_GetBasePrice to get a base price.

Now how do you do that with a program? The only way I know to do something
like that would be to create a program with function number and every
parameter passed at once and that have a switch to figure out which logic
to call. I would call that a disaster and how many people would actually do
it?

With a service program it is simple.

With ILE, I can build a screen program with modules, one per screen. Each
module performing one function and create CL modules to perform specific
functions and bind them all together into one program.

I mean the list is endless of things you can do with ILE that you cannot do
with OPM and the number one reason that you use procedures. Local
variables. Small pieces of code with their own variables.

Would you use Java or C3 or VB with functions or classes? Why would you use
RPG without ILE. Question I have asking since 1994 when V3R6 shipped.


On Sat, Jul 19, 2014 at 10:39 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On another thread, Scott Klement wrote this:

I mean, ILE really just gives you the ability to have
procedures ("functions" in other languages) that can
be stored in different objects and called... Big deal,
EVERY language in the world has some implementation
of that. (Except the OPM ones like RPG/400, et al.)

This strikes me as an unusually tame endorsement of ILE, by the
standards of this mailing list. The fact that it's Scott saying this
makes me feel a *little* better about my seemingly contrarian lack of
enthusiasm for ILE.

But my view is even a step more heretical than what is presented
above. Maybe a big step. From where I'm sitting, even OPM provides
the ability to "have procedures that can be stored in different
objects and called". These external procedures are known as... OPM
programs.

Yes, prototypes provide a measure of compile-time checking that PLISTs
do not. Yes, I'm aware that ILE modules somehow or another have
performance advantages. But for me, these are not game-changers. I'm
used to making sure my parameters match up. Our i is more than fast
enough to handle anything we throw at it. (And that's certainly a
credit to the i and to all versions of RPG.)

I will say that ILE procedures *do* provide much better support for a
functional (as opposed to imperative) style of programming. That is,
a style that a Lisp programmer would use, which is to say heavily
dependent on return values (not mutable parameters) and recursion.

But how often do you need this for business logic? In my experience,
not a lot. Return values are nice. They are definitely convenient.
Newer versions of RPG allow you to skip the redundant prototype for
same-module procedures, so I'm all for that. But recursion? I've
used this once, for a somewhat fancy home-grown fuzzy string matcher.
(And from a pure computer science standpoint, there isn't anything you
can do with recursion that you can't do with loops. It's just that
some algorithms are easier to express and implement recursively.)

To be clear, I'm not *against* ILE. I think it's nice, actually. And
I do believe that shops that already have widespread ILE use are
better-positioned than those that do not. I'm just not seeing the
pain points that are *solved* (and not traded for other pain points)
by switching from "modular-style OPM" to ILE.

Also, before anyone gets into RPG IV syntax, please also be clear that
(1) RPG IV syntax has nothing to do with ILE, and (2) I am
enthusiastically, like ten thousand percent, in favor of RPG IV
syntax, BIFs, etc. These solve a TON of pre-RPG-IV pain points, and
do so at basically no cost whatsoever.

John
--
This is the RPG programming on the IBM i (AS/400 and 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.