RE: Assembly programmers do it a byte at a time

I agree with what you say Joe...but I'll take it a step further.  You have been 
programming & will continue to do so, simply because YOU want to be able to do 
the best job you can.  If you didn't have the desire (or as I like to think of 
it..WORK ETHIC!!!) to do your job to the best of your ability, then & only then 
would I dare think it wasn't programming.  As someone else stated (sorry I 
don't remember who...) it's the people who continue to write new code in RPG IV 
using RPG II methodologies simply because they have no desire to change with 
the times.  There are some cases where the old methodolgies can be beneficial 
but in most cases there are much better ways to accomplish the same goal.  
Personally I prefer to code in a fashion that myself or others can make a 10 
minute change vs. a day & a half change due to the old copy/paste one hundred 
times.  Do both methods work? yes.  But when maintenance comes into play, I'd 
rather change a single subroutine, subprocedure or program than have to modify 
one hundred places in a monolithic monster. One example I can think of in our 
workplace.

We have a set of files that we duplicate & transfer to a remote system via DDM. 
 I could have created a huge CL that does

CpyF &Library/&FileName &TempLib/&FileName + 
     MbrOpt(*Replace) CrtFile(*Yes)
CpyF &Library/&FileName1 &TempLib/&FileName1 + 
     MbrOpt(*Replace) CrtFile(*Yes)         
more files here (84 total...)

OR use a driver CL & a control file
to call a single CL that does this:
pgm (&library &filename &templib)


CpyF &Library/&FileName &TempLib/&FileName + 
     MbrOpt(*Replace) CrtFile(*Yes)                     
endpgm

then should sometime happen that we had to change keyword values on the CPYF 
command I change 1 line of code in 1 program vs.
84 lines of code in 1 program.  This is a small change to the way you can 
program that can save 100's of manhours in maintenance.  It's not really 
changing the WAY you program, just the way you DESIGN the program.

(sorry for the CL example but the same type of logic applies to RPG as well 
<VBG>)

Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces+tommy.holden=hcahealthcare.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+tommy.holden=hcahealthcare.com@xxxxxxxxxxxx]On
Behalf Of Joe Pluta
Sent: Tuesday, June 28, 2005 8:42 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Assembly programmers do it a byte at a time


> From: Fleming, Greg (ED)
> 
> It just seems to me like this and some other recent threads here are
> beginning to get at the real reason why so many of us are finding it
> difficult to move to ILE programming.  It's that some of us don't know
> how to program.  I'm not sure that what I've been doing with RPG for
> eight years is really programming.  I guess it's analagous to what a
> handyman does vs. a builder.

Don't sell yourself short, Greg, and whatever you do, don't let the
Computer Science uber-geeks belittle your skill set.  Many of the
concepts being presented in this thread are "nice-to-haves" that are
absolutely unnecessary for certain classes of program.

What you see here is more of the difference between a factory mechanic
and a garage mechanic.  The analogy plays on a lot of levels.  First and
foremost, there are a ton of factory-trained mechanics who will never be
able to get a '67 Mustang fastback running at peak efficiency.  Why?
Because a lot of the techniques used in that baby are out of style
today.  In today's computer-controlled, fuel-ignited, catalytically
converted cars, there's no need to know how to fix a distributor with a
pencil eraser and a paperclip.  Does that make the factory mechanic
"better" than the garage mechanic?  Hell, no.  Just a different skill
set.

The interesting thing is that as the technology progresses, the factory
mechanic tends to know less and less about auto mechanics and more and
more about specific tools and procedures, and the diagnostic equipment
tells them what to do.  This is not so far from using a wizard when
coding; you tell it what you want to do, and it tells you how to do it,
or in many cases does it for you.  You have no clue what it's doing or
why, just that it works.

Continuing the analogy, who would you rather have in your shop?  A
garage mechanic with decades of practical experience who is willing to
learn the new equipment, or a guy brought up on the computers who tells
you that carburetors are old technology?

Anyway, I'm not going to get dragged too deeply in here.  Because I've
dared to opine that functional decomposition is not the Holy Grail of
programming, I'm sure I'm going to get labeled as anti-something,
probably a Luddite and most likely deserving to be hanged in the
courtyard at noon.  The truth is that many of the concepts mentioned by
the folks here (encapsulation and so on) are great concepts that all of
us, you included, should learn.  But don't buy into the premise that
what you've done all these years somehow isn't "programming".  It most
certainly is.  It's just programming of a different type. 

Joe