RE: IBM's failure to provide AD tools -- MIDRANGE-L

Jon,

Thank you, so much, for your insights.

First of all, I don't know what goes on behind the scenes.  I may have
implied otherwise, but I woulda thought that was pretty obvious.  In case
there's any confusion, I run a Mom-and-Pop contract programming outfit, with
my Wife.  I have never met anyone at IBM, outside of Columbus and that was
basically CEs more than 5 years ago.  I've never been to COMMON, and have
little to no private correspondence with folks inside the Community.  I get
most of my news from News/400 and scan the ComputerWorld and InfoWorld
e-zines.  All that to say... I'm not claiming ANY inside information of what
goes on behind the scenes.

I accept all you say, below, as facts.

I wrote a post on the News/400 V5R1 RPG enhancements forum, back last May or
whatever, and the post was (close to) "You need to take a different approach
to the problem".  I wrote that I had the same impression which you state
below.  I said that Rochester and Toronto needed to "get on the same page".
I cited the example that when I heard Toronto was "waiting on code from
Rochester, to implement numeric parm op-descriptors", that the situation was
messed up.

So when I said there was a difference in mindset, I have seen nothing in
your post to contradict that.  I may have implied I blame Toronto more than
Rochester but, in actual fact, I have found it little to be gained by
blaming anyone for anything.


I have found errors in judgment, but that's from my POV only, in how the
direction the 400 is going.  We've all seen them, but may not agree on each
of the items I list below:

a) The hardware/OS/languages/tools are no longer integrated
b) RPG has turned into C
c) DDS, one of strongest assets of 400, left unenhanced
d) IBM attempts to force users into a direction, by not enhancing their
products in certain areas (OPNQRYF, DDS, SEU, and basically all the primary
strengths of the platform)
e) Compilers don't compile to MI anymore
f) Ooops Nav
g) Info-less Center
h) QCMD getting no attention
i) Daggone editors not sufficiently integrated with languages

Obviously, this is just a few of the high-points of my objections to the
direction BOTH Rochester AND Toronto are leading the 400.  I think, from
what I recall of your prior posts, you would agree with some (although maybe
not all) of these objections.

I don't see the problem as the fact that the experts on the 38 have retired.
I see the problem as:  when they re-wrote CPF in C++, they swelled the ranks
of OS coders with "new blood".  And that new blood figured they had better
ideas than the "old fogeys" who originally designed the 38.  I'm sure some
of their ideas WERE better.  But on balance, I say they had a lot to learn,
but didn't...  That intends nothing personal against any of these folks in
Rochester and Toronto.  That's merely an observation based on the direction
the 400 is heading, at present.


I'll give two examples.  I'll go easy on the folks up in Toronto, because if
you tell me they're good people, Jon, I take that on faith.  However,
they've turned RPG into C.  IMV, the better direction would have been to
take it in the direction of MI which is, IMV only, the superior approach to
combining columnar and free-form coding.  I remember a letter to the editor,
when someone complained about losing having a column you can scan, to
determine fields that are modified.  He felt there was a place for the
result field column.  I distinctly remember the reply: "We've covered that
already".  The implication was that anyone who prefers a columnar approach
is a moron.

I beg to differ.  In fact, I'll go far as to state that free-form coding is
a throw-back, even though the entire industry says otherwise.  I base that
on one single solitary fact:  Anybody who has ever designed a decent-looking
screen intuitively knows what what stated in the _Handbook of Screen Design_
(written by somebody a decade or so ago, and periodically updated; I have
2nd edition, I know there was a 3rd edition 5 years ago).  You design decent
screens by lining up input fields in a column.  A la SAA standards.  A la
the command prompter and every screen in CPF.  Columns are "a good thing".

But somewhere along the line, somebody decided RPG is a bad thing, because
it's based on columns.  I don't believe that.  I believe that is it's
strength.  I've heard a fair chunk of the discussion on the advantages of
making RPG free-form, and been reading it since RPG /free.  I still don't
buy it, because we don't design user-screens in a free-format style.
Because it's hard to read and hard to use.  Programmers are users.

With V5R1, RPG is now free-form.  In fact, this Community asked for it.. and
they got it.  I admire the RPG compiler developers for listening to their
Community.  Problem is.. these lists hardly reflect the marketplace.  Other
problem is, I have a sneaking suspicion RPG is looking more and more like C
for one primary reason.  The compiler is written in C.

Another example:  I don't much cotton to the LEAVE statement.  (Which is to
say, I avoid it.)  Sorry, Nathan...  We've never discussed it, so I don't
know your views.  But my view is that just because all so-called "modern"
languages have it, doesn't mean RPG needed it.  Somebody (it was Edsgar
Dyskstra, among others, but I don't know how to spell his name) said that
you can construct ALL program logic by sequential instructions, a DO
statement, and an IF statement.  I would allow some modifications to this
view, but I would keep them as minimal as possible.  IF, LEAVE, CAB, and
GOTO are all fundamentally the same.  Some are better than others.  I would
much more prefer LEAVESR, which has an definitive and easily spotted exit
point than a LEAVE.  But I mainly object to the idea that RPG needs all the,
IMNSHO, worst features of C.


I have great respect for the compiler developers, on balance.  However, I've
written a lot more RPG than they have.  In retail, whole entire businesses
sprout up and die off like mushrooms.  So I can safely say:  I've thrown out
more code than the RPG compiler developers will ever write.

Now.. I appreciate full-well that the RPG compiler developers are the 400
programmers' best friend.  They're the stalwarts waging a defensive war,
with no ammo, against EJB and all that crap that pretty much the entire
industry supports.  I think I appreciate their struggles fairly well,
although I would have no clue what all it involves.

For example, I have little doubt that the crew that was given the WebFacing
project was given the task of coming up with something that ran in Websphere
and ran under interactive.  I firmly believe, but would have no way of
knowing for sure, that this was a directive that was issued from above.
IMV, that project was shot in both feet, if this was amongst the initial
design goals.  You can correct me, Jon, if you know otherwise.  Have I read
all the writings of George Farr, to know that WebFacing should be
avoided...?  No, I think I read a couple or three, maybe.  But that was all
that was necessary to see that what WebFacing is presenting is a new
paradigm of programming.  Maybe one the whole entire industry is supporting,
but I think programming paradigms are sprouting and dying off like
mushrooms.  IMV, another paradigm is something that should be approached
with caution.  But given the assumed design goals, I doubt if there were any
better alternative approaches.

So whether or not I have an understanding of what the compiler-developers
are up against, I do have a great deal of respect for their efforts.  I may
imply that I don't think their efforts are strong.  Quite the contrary...
However, I still think they're heading in the wrong direction, so are
mis-guided.

Another example would be compiling to W3 instead of MI.  Now I understand,
fully, the economics and politics behind that decision.  It still stinks.
So I understand there would be no benefit to anyone in Toronto objecting
strongly to compiling to W3, given it was almost certainly a directive from
higher up in the Software Group.  I don't question whether anyone has the
guts to raise strong objections against something that is politically
impossible to fight against.

But when RPG was being restructured as a free-form languange, it could have
just as easily taken the approach of MI.  But what happened was it basically
became C, with strong I/O capabilities.  The difference is that MI still has
a component of being columnar, and IMV that approach was never seriously
considered because of that.  Because of the attitude that no serious
programmer would prefer columns over indented IF statements.

But IMV, anyone who has looked at RPG/Alive! would know that IFs can be
documented quite easily with the editor.  And IMV, anyone who has poored
over RPG code for any length of time would notice that the proportion of
time spent reviewing program structure is far less than the time analyzing
how result fields get "wigged", or incorrectly updated.  That has been my
experience anyway.  Good coders don't spend a lot of time matching IFs and
ENDs.  And those bugs are easier to discover than the field that doesn't
have the correct value.


I can almost hear the argument coming:  "you don't understand the
complexities of writing a compiler".  As a matter of fact, I've seen that
argument posted in various forms...  Well.. I think I do.  Do I have a
Computer Science degree...?  No.  Do I know C...?  Only seen it.  Am I
arrogant...?  I don't think so.  I still say I understand the complexities
enough, and I also say that the language design is the most critical element
anyway.  I think optimisization is a very important specialty, and I don't
slight that at all.  But I think language design is key.  I am more than
willing to accept any and all comer's, if anyone wants to challenge
statements in this paragraph...  Go ahead...  "Make my day..."


I am still working on this write-up.  I think I've pointed out a few of the
examples where I think the 400, and RPG in particular, are headed in the
wrong direction.  I think this is basically due to people not respecting the
wisdom of the user's of the 400, as much as anything else.  I'm really not
trying to cast blame around, but if that's what I'm doing I think I've shown
there is plenty of blame to spread around.


What I'm writing now is a further example of this.  I may, or may not, post
it.  May, or may not, depend on responses to this post.  It's starting to
look like this is Part 1 of 3, rather than being half.  May not get to part
3 anyway, though.  (Shoulda probably re-read this thing, to see if it makes
any sense, but I'm trying to get this done before too long...)

My next post, if any, is about the Info-less Center.  Now I'm sure some
people think this is no fair.  The Info-less Center is far, far to easy of a
"target" to go after.  The fact that few, if anybody, on this list feels
that way, doesn't influence me one way or the other...;-)  It is symptomatic
of how SOME people at IBM do not respect the wisdom of the Community of
people that use the computer.  The Info-less Center is surely the easiest
target, in the entire iSeries Division.  But I think it's "fair game".

Again, I mean no disrespect...  But I've taken the "kid gloves" off.


Thanks again for your comments, Jon!  Hope I haven't made you sorry you
wrote...  ?

jt


"Have a GREAT day...!  And a BETTER ONE TOMORROW~~~:-)" (sm)





> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Jon Paris
> Sent: Monday, November 12, 2001 3:24 PM
> To: midrange-l@midrange.com
> Subject: IBM's failure to provide AD tools
>
>
>  >> Thus, the languages and AD tools come out of Toronto...  Now, these
> days, distance means nothing, in theory.  In actual practice,
> your talking a
> wide gap in mindset.
>
> I have to comment on this, although I should admit up-front that I am an
> ex-Toronto (and ex-Rochester for that matter) developer.
>
> In my opinion - these days I find the Toronto crew have a far better
> understanding of what their customers need/want than do most of the
> Rochester developers I meet.  The majority of the Rochester developers who
> really understood what the 400 was all about are retired, or working for
> BPs.  Those who remain are Unix/Linux folks who happen to work on the 400.
> If Rochester had their way there would probably be no RPG (or at least no
> enhancements) there would be no Code/400, no VARPG, no WebFacing,
> etc. etc.
> The Java Toolbox, C/C++ and Ops-Nav would be about all there was.
>
> Following the infamous hamburger ad, it took Rochester a good two years to
> understand that their RPG users could not afford to dump
> everything and just
> leap into Java (ignoring the fact that it wasn't a good idea
> anyway).  It is
> only in the last 12 months or so that they have realized (in some quarters
> at least) that they need to join the Toronto folks in trying to move
> customers forward incrementally.
>
> Of course there are many in Software Group who neither know nor care about
> the 400 - and because of that the 400 crew don't get the funding
> or support
> they need to really do their job.  I fault Rochester for much of this - as
> the platform owner, if they really care about their RPG users
> they have the
> ways and means to ensure that Software Group fully support them.  The fact
> that they don't should tell you something.  The Toronto group
> working on the
> 400 are as dedicated to the platform as any group you'd find in Rochester.
> I know many who have effectively risked their careers by
> insisting that they
> stay in the 400 arena and not work on AIX or whatever.
>
> As I said - just my opinion, but I do at least have some idea what goes on
> behind the scenes.
>
> Jon Paris
> Partner400
>
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>