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