On 9/28/2010 11:17 AM, Tom Huff wrote:
Actually, I think it has more to do with maintaining the integrity of the
code.
I don't see what integrity has to do with it? Are you saying that the
LOKUP opcode in RPG III is more stable than the %LOOKUP BIF? Or that
the %LOOKUP BIF in fixed-format has more integrity than the %LOOKUP BIF
in free-format?
When you have a couple of million lines of code, it is not nice (or
practical) to have to rewrite every time IBM thinks of a new way to do
something.
Listen, Tom... so you know where I'm coming from... I correspond with
hundreds (if not thousands) of RPG programmers all over the world. I
travel and speak to them at conferences. Talking to RPGers and
understanding what's happening in their shops is a major part of my life
for the past 13 years.
In all that time, I've never heard of a shop where the newest features
are implemented in every single program the moment they are released.
Not once. I've heard of isolated instances where a given programmer
tried to replace all of a single feature with a single new feature --
but afterwards, the programmer was barred from ever doing that again.
Or even fired. This sort of thing is rare to begin with, and when it
does happen, it's shut down pretty much immediately. It just isn't a
major problem in RPG shops.
And I certainly am not suggesting that every new feature be implemented
in all existing code the moment it's released.
But I _am_ suggesting that programmers learn these new features, and try
to use them when they are applicable. Try to gain value from the new
features, as they were implemented for a reason. Believe me, if you try
to get a new feature implemented in the RPG compiler, it's not done
lightly. It requires some serious convincing, and a lot of review by a
whole bunch of people before anything is ever done.
So when a new feature is added, they almost always offer some sort of
value. You should learn this value, and use it in _new_ code, or to
meet business requirements that involve _updating_ existing code.
I never advocate making changes to working code, unless there's a
business requirement to do so. My shop still runs quite a bit of RPG II
code, and a _ton_ of RPG III code. But when business requirements tell
us to change a program, we don't keep it in RPG II! We convert it to
RPG IV, and we use new techniques in RPG IV to satisfy the requirement.
There's a big problem in the RPG community, where shops stick to
outdated techniques... not because they've evaluated them as the best
for their business, but because they've always done it that way, and
because they're used to it.
Subprocedures are a great example. They do everything that subroutines
do, plus offer a heck of a lot of value over subroutines. Yet people
insist on still using subroutines because "if it ain't broke, don't fix
it". That's BS. You'll never learn the value of something if you don't
try it. Just like a kid who won't try a new food -- he doesn't know he
doesn't like it... he just won't try it because it's different.
MONITOR/ENDMON is another great example. People keep using *PSSR, and
coding workarounds for it's shortcomings. Why? Because they're used to
it. It's "better" because they can find a workaround that makes *PSSR
do what they need to do. Why not at least try using a tool designed for
the job you're doing?
ILE is another example.
Free format is another example.
RPG III vs. RPG IV is another example.
And you make it sound like these things are cutting edge! They aren't!
ILE, RPG IV, the %LOOKUP BIF? You must be kidding, these have been
around for more than a decade! In many cases, 17 years or more! They
aren't new or cutting edge. They're pretty much old-school at this point.
The list goes on and on and on. The vast, vast majority of shops you
talk to are stuck on old techniques, and really need to invest more in
learning. See what value the new techniques offer. See what value it
can offer the company.
Complacency is the big problem in RPG shops, not breaking integrity!
midrange.com
