Re: Free Form RPG Opinions Wanted -- RPG400-L

Joe,

>There are three options: stick with MOVE, recode your MOVEs to evals, or
>have a mix of /free and fixed code.  

Are you referring to a mix of /free and /fixed within a single program, or a mix
within the shop's collection of programs?

I don't think anybody is arguing that switching formats *within* a program is
elegant.  Just look at what SQL looks like in a /free program. :(

But I never suggested that anybody *should* mix styles in a program, nor did I
suggest existing legacy code be converted to /free.  I do recommend any program
which needs maintenance get converted to RPG IV, but I do so in /fixed format.

I have never yet converted an existing program to /free.  So far I'm sticking
with IBM's recommendation and only using it for new work.  If / when I write or
acquire an intelligent converter, that position may change.

>I don't accept the last one as a viable
>option because it's just plain bad coding.  If you think that's a good
>solution for your shop, then we have little to talk about, 

Here is what I do:

 - Any program which needs maintenance, gets converted to RPG IV /fixed
 - Existing MOVE operations remain MOVEs, unless that section of logic is
        being re-written anyway
 - I never code the MOVE opcode anymore, and haven't for years (for new
        lines of code; legacy code remains as is until a reason to change)
 - If a section of code which includes MOVEs is already changing, and the
        program needs testing anyway, I will generally rewrite the MOVEs
        into EVALs (but only in those part(s) of the program where I am
        already making program changes).  It is not uncommon to replace
        a whole series of MOVEs with a single expression.

>On the other hand, if like me you think it's a choice between /free and
>fixed, then here's where working code breaks: you have to remove the MOVEs
>to go to /free.  This is the point you're very stubbornly missing.  

No I'm not.  What you are missing is that I never said to convert legacy code to
/free.  You are the one who keeps talking about putting /free and /fixed in the
same program.  I've never done that, and never intend to do that.

The closest I could see coming would be where entire new subprocedures were
being added.  I personally wouldn't have a problem with one or more local
subprocedures being written in /free, even it the rest of the program was
/fixed.  However, I'd want the entire subprocedure to be /free.

>And
>since just about every program ever written uses at least a few MOVE
>instructions, 

As I said, every new program I've written for the last several years has
absolutely no MOVE, MOVEL, or MOVEA operations.  There simply isn't a
justifiable reason to use them anymore, when coding a new statement.

Granted, just about every program I wrote prior to RPG IV will contain MOVE
operations.  But then I never suggested they get converted to /free.

>then by definition you are recoding - and possibly breaking -
>every sinble program.  Are you missing this fundamental point, or am I just
>explaining it poorly?

I'm not missing that point; but neither am I recoding every program.  Nor am I
changing any of them to /free.  Are you missing that fundamental point of mine?

>So the only other option is to stick with MOVE, and thus be barred from
>using the /free-only extensions.  

So what?  Fixed format will always have some compromises due to space
constraints, whether it is using short field names for array indexes or
squeezing multiple operands into factor 1 or 2 separated by colons, or whatever.

The single biggest thing, IMHO, which ever happened to RPG was the addition of
subprocedure support.  This of course required the extended factor2 as a
prerequisite, but the ability to code my own functions has transformed the
language, as far as I'm concerned.  Service programs take that one step better.

If some features are not easy for them to add to both /free and /fixed, I'm fine
with that.  Let the developers concentrate on enhancing the compiler in the most
cost effective manner.  Don't waste resources with some mandate that says /free
and /fixed must remain 100% in sync from a feature standpoint.

>This because the compiler team chooses not
>to give us extended syntax in fixed form (even though, as I've shown, it can
>be done).

No, you've only shown that in your opinion it *should* be easy to add.  People
use to say the same thing about why some named constants weren't allowed within
expressions in D-spec keywords.  However, I understand it was quite a bit of
work to recently relax that constraint.  Of course it can be done.  It is a
matter of what it would take to do it.

I'll leave that for a future $100 budget survey, where somebody in the know can
provide an associated cost estimate.  You can vote how you want; I'll do the
same.

>Long term, I still don't agree with your comment about MOVE and EVAL.  My
>personal opinion is that the people who can't read a MOVE instruction might
>seriously want to consider other lines of work.  

I can read MOVE instructions.  But I don't know exactly what they do without
intimate knowledge of the operands.  Do I recognize hundreds if not thousands of
field names?  Sure, in my own code.  Do I know every single one?  Nope.

I've been coding in RPG IV for years now, and can honestly say I have never yet
met a case where I needed to use MOVE -- or even wanted to do so.  For those
cases where I want to perform numeric to character conversion (or vice versa) I
just use service program routines I wroteback  in V3R2.  When I want to affect
only a portion of a variable I use %subst() or whatever else is appropriate.

The simple fact is that string operations with EVAL are so vastly superior to
MOVE that I don't miss them one iota.  Combine the various BIF's with a set of
simple string-handling service program routines, and anything you do with MOVE
can be just as readily coded without it.  And the result is code which IMHO is
easier to maintain in the future, and not subject to introducing subtle bugs if
business requirements mandate a field size change and all of a sudden an
existing MOVE instruction does not perform the same operation it did in a
previous compile.

>If we're
>turning out generations of programmers who can't read a MOVE instruction,
>then we're in a serious downward slide in programmer ability.  Cripes.

So tell me what does this line of code do?

      C                   MOVE      A             B

I can "read" it, but I can't tell precisely what it does.  Can you?

OTOH, the way I've personally coded for the last several years, the above move
would be coded as an EVAL and I (or you) can unambigiously tell precisely what
it does.

Doug