× 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: Jon Paris
>
> I think one can make the argument that in some ways the on-going upward
> compatibility that RPG has given us over the years has done more harm than
> good.  Too many people still code RPG II (they just use RPG IV syntax).  I
> think it is about time that there _were_ features that can only be used if
> you embrace their intent.

Jon, you know I have great respect for you, but this is possibly one of the
most dangerous sentiments I've ever heard.

If I am a shop that's running just ducky on RPG II style code, and I have
programmers who program that way, and we're making our numbers and beating
our competition and doing what we need to do, then how can you possibly
justify making us change our ways?  Just because you, Jon Paris, don't like
the MOVE instruction?  Now doesn't that strike you as a tad arrogant on your
part?  Do you plan to come in and teach my programmers the new syntax for
free?  Will you pay for the retesting that's required on applications that
have worked for years?

Jon, I'm disappointed with you.

No, I'm saying that as you add new things to the language, if it's just as
easy to make them available in RPG IV as it is in RPG FF, then please do so.
After some serious consideration, I'm really of the mind that the only thing
you get from RPG FF is indent/undent and a few extensions to the base
opcodes.  And it costs you semi-colons, loss of function on a number of BIFs
(for example, DIV and REM) and the loss of the MOVE instruction.  For
someone who hates MOVE (and doesn't care about anybody else) then this might
be a good thing.  But I just don't see the justification.

If the extended factor two were supported on RPG IV, then we'd have the best
of both worlds, and if you really, really needed indent/undent, you could do
it, while my example client above wouldn't be disallowed the use of the new
features.

I can't see how anybody who isn't thinking entirely self-centrically (and
just a little bit Elite Architect-ish) wouldn't think this is a good thing.


> Any op-code that requires you to know the exact data type and size of both
> fields before you know what the hell will happen is in my opinion a bad
> idea.

I'm not being flip here, but why should it matter what you think about the
MOVE opcode?  Isn't that assigning an awful lot of weight to your viewpoint?
Because I would counter that any programmer who doesn't understand every
opcode he uses and the side effects thereof is in my opinion a bad
programmer.

This isn't kid stuff, it isn't supposed to be easy, and if you can't take
the time to look at a compile listing, then you ought to be thinking about
alternate lines of employment.  This silly notion that every line of code
ought to be self-documenting is the single stinkiest pile of dung I've
smelled in a loooooooooong time.

If you write code that's even a little bit unusual, write a comment.  THAT'S
WHY LANGUAGES HAVE COMMENTS.  "But comments get out of date."  Not if you
fire the lazy, incompetent programmer that didn't update the comment when
they changed the code.

Self-documenting code is for the button pushers - the ones who want to point
their mouse at pretty icons on a screen and have it develop an ERP
application for them.  And you know, you may get it, on account of people
who are willing to have slightly less efficient code and slightly less
powerful compilers, in order to make their jobs "easier", so they don't have
to actually think about it.  They'll plug together bloated, stupid modules
and get mediocre results quickly, and after a while everyone will think that
that's what programming is.  And when it gets to that point, where
programming is semi-skilled labor, programming jobs will zoom out of this
country so fast you won't even hear 'em leave.

And I guarantee you will miss the MOVE instruction then.


> I may pose a few questions to the attendees at next weeks RPG World
> conference and see what they think.  So far I've presented the V5 stuff to
> about 2,000 plus people.  Very few have ever complained about the MOVE
> op-code and those that have once they think about it tend to go
> "yea! it is
> a bit sneaky isn't it - I got caught badly by that x weeks ago"

Jon, I've been involved in the development of hundreds of millions of lines
of code - you know that - over decades, and never, ever has one of my
projects been bitten by a MOVE.  The one we has last month with the negative
sign was truly the first time a MOVE opcode ever was "too sneaky" for me.
Honestly.  But then again, I have a policy of beating programmers who write
"cute code" with a stick.

Just remember, it isn't the MOVE that kills programs - it's the programmer
who uses the MOVE.

Okay, enough.  The horse is dead.  I have my viewpoint.  I am going to stump
for am extended factor 2 syntax and a %MOVE BIF.  I'll be amazed if I get
them, and disappointed if I don't, but at least I've come up with a
compromise - a compromise that helps some people, harms nobody, and yet the
"3l33t d00dz" of RPG don't want to hear.

<<sigh>>

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.