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



>From: "Joe Pluta" <joepluta@PlutaBrothers.com>
>Date: Tue, 26 Feb 2002 18:57:50 -0600
> ...
>To take a language and remove functionality is questionable.  To do it
>without good reason is absurd.  To do it because you think you know better
>without having actually used the language for what it is intended is
>criminal.
> ...

Joe, no functionality has been removed.  You can still use MOVE.

My problem with MOVE is that it is too powerful.  I maintain that
it is easier to tell what this does
   eval   x = %editc(%dec(year - 1) : 4 : 0)
                     'X')
than what this does
   move   year        x
given a reasonably experienced RPG programmer.

Less is not always better.  No matter how experienced, an RPG
programmer should look at the definition of at least x to see
what's happening with that move.  With the eval %editc, the
experienced RPG programmer knows that x is character, and that
its value is completely replaced by the assignment.

In many cases, including the case for this thread, using MOVE
would entail declaring a variable to hold the result.  But the
value is only needed to build a larger result, so the variable
is unnecessary other than for the MOVE.  Using builtin functions,
the sizes of temporary variables get adjusted as the operands
change their sizes.  With MOVE, the maintainance programmer has
to ensure the sizes are correct.  This is made easier by LIKE
with increment, but is still error prone.

Imagine maintaining code where someone made use of the more
arcane features of MOVE, such as multiplication by 10, or changing
the sign to positive.  Yikes.  Such code does exist.

Our intention was that /free should be used for new code.
We don't think it is quite complete yet; some of the opcodes/functions
that are missing are missing because of resource constraints.  But I
admit that MOVE, MOVEL and MOVEA were omitted deliberately.  Refer
to the previous thread about MOVEA - there still hasn't been a winner
in the "suggest a reasonable use for MOVEA" contest.  I can't make
the equivalent challenge for MOVE and MOVEL, because there are still
some things that they do that are somewhat difficult to do in /free.

I don't think it's a good idea to convert code to /free, unless
someone writes a converter that makes conversions that do _exactly_
what the original does, with full knowledge of all the field
types and all the oddities of RPG semantics.  Some of the
"suggested replacement" bifs don't do exactly the same thing as
the fixed opcodes.  They are fine when writing new code, but
not for replacing old working code.

Converting most code to /free will introduce many many more
inconsistencies than converting from OPM to ILE.

I realize that if we'd allowed all opcodes in /free, then every
program could be converted.  Our feeling is that there is a
lot of code that hasn't been changed since RPG-II-time, that
should really be revisited before being converted again.  For
those who don't want to revisit their code, and those who don't
want to learn new ways of doing things, don't convert, and just
keep on coding the old way.

/free is a work in progress.  If it turns out that we should have
supported MOVE and MOVEL in /free, then we can add them.  But even
with the spate of questions about how to move character to numeric,
and date to numeric, I believe we made the right decision.  If
we'd supported MOVE and MOVEL, we'd have had to keep the bath
water with the baby.  By not supporting them, we have also thrown
out the washcloth which we plan to replace (stretching the analogy
too far as I always do).

Regarding RPG turning into Java, I think this idea originated
with some Java-centric IBM marketers who thought that all RPG
programmers should start using Java.  Certainly it is not and
has never been our intention to turn RPG into Java.  If some
of the changes we have made to RPG have enabled people to
learn Java more easily, that is a by-product, not an intention.
The only way that RPG resembles Java that I can see is in the
syntax of expressions, but that syntax is similar to many if
not most programming languages.  We _could_ have invented a
whole new syntax for expressions, but we didn't.  We took what
we could from the common syntax for expressions (that we all
used even in Jr High math), and made up RPG bits where we had
to (like the colon separator because the comma was busy being
a decimal point).  Perhaps I'm missing something obvious - is
there something else Java-like about RPG now?

Sorry, this is way too long.  But I don't know what to trim
out.

Barbara Morris



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.