|
Jon, Thank you for taking the time to read those long posts. See comments inline. 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 10:47 PM > To: midrange-l@midrange.com > Subject: IBM's failure to provide AD tools > Importance: High > > > jt, a lot of what you write is clearly your opinion and what I think of it > doesn't matter a hoot, Matters to me, Jon. > but there are a couple of serious misconceptions in > what you wrote that I will comment on. > > >> 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. > > Any business has to cost justify what they do. In this case while I would > love to see Rochester fully implement descriptors, the fact that Toronto > would like them is irrelevant. Even if the RPG compiler was built in > Rochester they still wouldn't have done it - mostly I suspect because Java > doesn't need it. No argument from me. > > >> a) The hardware/OS/languages/tools are no longer integrated > > If you mean that the tools now run on PCs I can't disagree. Personally I > think that is a good thing. Anyone still using SEU is (IMO) not being as > productive as they could be. No, I don't mean that the tools now run on PCs. I favor this also, but don't much cotton to the implementation I've seen so far. I need to look at V5R1, though. > > >> b) RPG has turned into C > > Or COBOL, or Java, or Pascal. People tend to specify whatever > language they > most dislike. I disagree. RPG is still RPG, but it has grown up and > sprouted chest hairs. I may not like all of what has been done, > but it has > for the most part retained the essence of the language. I disagree. It has, IMHO, lost a lot of what made it effective. Result fields lined up in a column, emphasis on D-specs over defining fields on C-specs (see below on Code/400). > > >> e) Compilers don't compile to MI anymore > > Correct - and for me that is a good thing. MI is way too "lumpy" and does > not lend itself to optimization. See also W3 comments later. > > >> g) Info-less Center > > 100% agreed - you'll have to pry my softcopy V4R3 CD out of my cold dead > hands! Same here...! > > >> h) QCMD getting no attention > > I haven't a clue as to what you mean unless you mean CL enhancements which > are coming. I'm talking about the fact that the Command Entry display has not been enhanced. I don't recall any (ICBW) since it was released with the AS/400 in '88. No interface is THAT good, that it couldn't see significant enhancements in 13 years. I believe it hasn't been enhanced because entering via command line has gone out of fashion. No matter that it is still widely used, and probably the predominant interface used on pSeries and zSeries, as well as iSeries. The command line has gone out of fashion, with most of the industry and with the people designing the 400. > > >> i) Daggone editors not sufficiently integrated with languages > > If Code/400 were any more integrated with RPG you'd be out of a > job. I just > don't know what you mean here. I'm looking for tabs for each type of spec. I'm looking for Code/400 to take a field defined on a C-spec, and create a D-spec automatically. I can't imagine why I have to define a field length on DDS, and then define it again in RPG. That's a few example of what I mean by "integrated sufficiently". > > >> ..... And that new blood figured they had better ideas than the "old > fogeys" who originally designed the 38. > > Not really. In the "old" days there were a fairly large group of folks in > Toronto and Rochester known as the DCG (Design Control Group) > whose job was > to make sure that all the pieces of the system were in sync. e.g If > Rochester implemented x in the database then RPG and COBOL had to > implement > it. For a number of reasons (mostly timeliness of new function and costs) > that function was cut way back in the late V2 timeframe. It still exists > but is not the guiding force that it was. Thanks for the insight. I think it's high time to re-establish the DCG as a guiding force. That group was one of the primary justifications for paying the premium prices on an iSeries, IMV. > > >> However, they've turned RPG into C. > > I've already agreed to disagree on that front. OK. But I've always felt that RPG coders that wanted long names and free-form should just program in C or even more, Cobol. Instead, RPG took on aspects of these languages. I'm not against that, so much as the fact that (IMV) some of the primary benefits were sacrificed. IMHO, the CX was the worst of both worlds, not the best of both worlds. Very difficult to see the advantage of mixing free-form with old-style, so I'm afraid a lot of folks will sacrifice the advantages of the old-style RPG in order to gain the perceived advantages of CX and free-form. The primary advantage of free-form is that this is where the compiler enhancements are going, more than it being inherently superior, in all respects, to the old-style code. > > >> 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. > > Sorry but I couldn't disagree more. MI is way too arcane for the kind of > development most RPGers do. Whoa, there...! I'm not advocated coding in MI, if that's what you mean. ===> I'm talking about the columnar format of MI. I'm talking about result-field column on the left; opcode column next; followed by either factors 1 and 2 or free-form. It's the layout I prefer, because it DOES combine the best of both worlds. Could have been accomplished by moving the result-field column to the left, rather than by eliminating the usefulness of it entirely. > > >> The implication was that anyone who prefers a columnar approach is a > moron. > > Personally I think a columnar approach is outdated. It is a throw back to > the fixed position plug boards it replaced. The crucial point here though > (and the one you ignore in all of your comments in this area) is that you > can still write RPG that way if you want! No one has taken that away!! I do not ignore this argument at all. There is little value in coding RPGIII-style. But even worse, IMHO, is mixing both in the same block of code. We have, again IMHO, the worst of both worlds. We now have two RPGs. Now according to many, a columnar approach is archaic and "bad code". But according to many, it is one of the strengths of RPG, and a strength that is found in few other languages. The situation is also that the compiler-developers are giving all the development dollars to free-form RPG. IMV, this is unnecessary, as both goals can adequately be achieved by the layout of the C-spec I outlined above. > > >> I base that on one single solitary fact: Anybody who has > ever designed > a decent-looking screen intuitively ...... Columns are "a good thing". > > Sorry but I think this comparison is seriously flawed. Writing > programs is > much closer to writing a novel than filling in the blanks in an > order entry > screen. We agree to disagree, then. Coding is inherently NOT like regular text-based processing, IMV. > > >> 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. > > This wasn't the community they listened to. If that had been the > case then > RPG IV would have been fully free-form from the very beginning. It was > because the bulk of the community (outside these lists) had educated > themselves to the joys of free form and were asking for more and more > function there that the developers responded. I have letters I wrote way > back before V3R1 where I predicted that exactly that would happen. But not the bulk of RPG coders. Otherwise you wouldn't have seen so many wait for so long to try ILE, IMHO. The flaw wasn't with the "old dogs" who refused to learn new tricks, primarily. It was in how RPG IV was implemented. It gave you a choice: either you coded in RPGIII style, or you mixed and matched, or you coded according to the new style-guide that was issued in News/400. If you chose the latter, you lost an awful lot of the advantages that RPG had to offer. If you coded exclusively using CX-specs, as the style-guide promoted, you lost almost half of the screen real-estate of your C-spec. That made little sense to many RPG-coders. > > >> Another example: I don't much cotton to the LEAVE statement. > > Neither do I, but it is an attempt to get people away from using > GOTO and at > least into a somewhat structured alternative. It has nothing to > do with C. It has to do with providing features that other languages have that, IMHO, RPG doesn't need. > > >> 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 don't believe so. It runs under WAS because it was too expensive to > re-invent the wheel in terms of a middleware layer and they could leverage > developments on other platforms by going this way. If it was "from above" > do you really think they'd be working on a Tomcat version? As to running > under interactive -sorry but it was designed to run in batch but > the brakes > haven't been taken off yet. I understand the need to try to leverage software from other platforms. IMHO, that is short-sited, in some cases. And the fact that the brakes haven't been taken off indicates, to me, a directive "from above". > > >> Another example would be compiling to W3 instead of MI. Now I > understand, fully, the economics and politics behind that decision. It > still stinks. ...... given it was almost certainly a directive > from higher > up in the Software Group. > > Wrong again. We had to _fight_ "higher up" to do it - for years. Without > it there could never have been an RPG IV, there wouldn't be Java > (yes I know > you probably don't care). The benefits so far outweigh the disadvantages > that it is not even a close thing. I'll have to consider that some more. > > >> The difference is that MI still has a component of being columnar, and > IMV that approach was never seriously considered because of that. > > ROTFL. I'm sorry - most of the fights we had were with people who wanted > total free-form - we fought to have a hybrid approach that kept the old > fixed form while adding some free-form elements. Again you completely > overlook the fact that fixed form is still there. > Don't like free form? Don't use it! It's real simple. Again, very ineffective to use the old-style. It's not getting any enhancements. > > >> Thanks again for your comments, Jon! Hope I haven't made you > sorry you > wrote... ? > > No but maybe you type a lot faster than me. I'm afraid I don't have the > time for dealing with this length of epistle. There were just so many > mis-spokes in what you said ......... Thank you for clearing some of them up. Some are a case where I was /too/ concise, in that I didn't fully explain what I was meaning. As for "epistle" I think you misinterpret my passion. I'm old fashioned, I guess, and tend to prefer to confine religious feelings (or some people would say religious "fanaticism") to the subject of religion. I /sure am/ passionate about the 400, though. I think that's why Mr. Haines and I did that "Vulcan Mind-Meld" thing. > > If you want to comment further how about a few _small_ notes?? Hope this is better...:-) > > Jon Paris > Partner400 >
As an Amazon Associate we earn from qualifying purchases.
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.