Re: MOVE opcode in freeform (was Strange behavior w/%editc)

Darn, another digest just rolled in while I was writing
this, and so some of my points are again redundant!  I
promise, this will be my last post for the morning!

Bob wrote:
>I think the bigger question is not even if a language that supports both
>free format AND fixed format useful, but rather, is the programmer that
>uses both free format and fixed format doing the right thing. In that, I
>can see your point. Mixing a MOVEL with all that free-format code isn't
>"cool".
>
>But to be honest, I have yet to see one example of free-format RPG IV
>code posted to this list that has been written in a way that is similar
>to code written by people that write applications with free-format
>languages for a living (not as a hobby). So perhaps we should continue
>using traditional RPG IV syntax (which includes the good old MOVE
>opcode) until we get a bit more experience or until is become more
>refined.

You know Bob, I DO tend to agree with you more often than
you might think.  I understand fully your concerns about
free-form calcs, and to a large extent, much of the talk
about free-form calcs is indeed hype.  (Perhaps even from
us!)  Since the intermixing of free and fixed calcs looks
so gawd-awful horrible, no one should even consider using
free-form calcs unless they are prepared to write whole new
procedures or modules in free-form style.  Although I do
prefer coding in /free style, and I would like to see more
/free code out there, I'm not sure I agree with the large-
scale conversion of existing fixed-form calcs.

Maybe you were right that RPG programmers weren't ready
for free-form.  But then, when would they be?  Perhaps
the problem was that expectations were too high?  I don't
think any one of us expected the overnight conversion of
all existing calc code.  Maybe some small percentage of
new V5R1 code will be written using /free.  Maybe that
percentage will rise as time goes on.  Unlike every
other enhancement we've done, this one has relatively
little practical importance in its first release.  It will
likely become more important over time as programmers warm
up to it and learn how to use it.

If anything, I think /free is a really profound statement
from us that we believe programmers will still be using
RPG many years from now.  In a sense, /free is more useful
as a statement of IBM's commitment to the language, rather
than as a useful function.

>On the other hand, since we have 6 or more ways to do the ADD operation
>in RPG, why not just include a new free-format opcode named MOVE and
>MOVEL?
>
>/free
>   movel  src  target
>/end-free
>
>Oh crap! I just wrote free-format, and I told Hans I would never do
>that! ;)

That's not valid free-form calc code anyways, so it doesn't
count, OK?  ;-)

As I pointed out in my previous note, we purposely did not
support all calcs in /free for the very reason that we
should not have lots of ways to code something.  If, and
this is a big IF, all new RPG code is written using /free,
then the point is moot - there would be fewer alternatives
to choose from.

>Actually, Joe, Hans is not your enemy. The enemy is us as a group, we
>RPG programmers who do not clearly articulate our views.  I think rather
>than say "I demand feature X in RPG" we need to say something like:
>"Feature X is valuable to me because A, B, C, D... and this is how I
>think it should be implemented."  And then let the smart compiler
>writing figure out how it should be realistically implemented.

I agree.  Often we see requests that we should add some
particular functionality where the request is worded in
terms of some specific syntax.  What we try to do is extract
the real requirement and then try to determine the best way
to meet that requirement.  That's not always easy, and it
might not always be obvious how some enhancement meets a
particular requirement.

Basically, we prefer adding "enabling" enhancements, rather
than enhancements that directly meet some specific need.  For
example, procedures "enable" a lot of functionality.  For
many things that programmers want to do, we would prefer
that programmers write procedures to perform the desired
tasks.  We had hoped that there would by now be a goodly
selection of procedures and modules commonly available
written by RPG programmers for the benefit of other RPG
programmers.  Robust publically available function libraries
is a prominent feature of many other currently popular
programming languages, such as C++, Python, Perl, and Java,
and is a big reason for the success of those languages.

I know someone will pipe up and point out some web page or
another with publically available RPG code.  But often,
they're just touted as "demonstration" code.  The biggest
problem is that there's no common repository of the code
that's available.  And there's little sense of community
with respect to improving the quality of publically
available code (as there is with other languages).  At any
rate, the amount and quality of publically available RPG
code just doesn't compare to what's out there for other
languages.  Just look at www.cpan.org to see how the Perl
community deals with library packages.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com