Fixed Format: Is It an Addiction?

[Guest.Visitor]

Hi Bob, Hopefully you know that I was just giving you a gentle prod there with the "Good-ol-Days" comment! This was a great article that has really brought out some good points. I definately know from following your articles and books that you advocate the "Good-new-days" over the old days. Sorry to temporarily paint you with that brush. I do agree with you that there are many things wrong with IBM's implementation of /FREE. I was just encouraged that they even considered it in the first place-- since that's so un-IBM. I was interested to hear that /FREE originated from one really expereienced coder. I guess I'll have to thank him/her for overcoming such a daunting task without the backing of IBM. That's pretty impressive both from a project management standpoint as well as from a self-management standpoint. I guess I should also be thankful that IBM bothers to publish a good portion of their coding examples in /FREE. Anyhow, keep up the good work and thanks for the reply!

[Guest.Visitor]

Fixed Format: Is It an Addiction?

Hi Dave, Though I must admit to a chuckle or two, just remember that those of us with clients in both the business and scientific communities can't be so cavelier about C! Also, I agree that RPG is a term that must be further defined. Saying "Let RPG be RPG" is tantamount to saying that the languauge shouldn't evolve. Simply remembering what the acronym RPG stands for drives home the point that languages must evolve. Just think if RPG was still relegated to report generation! Yikes. The only people who would be happy would be those creating reports. It's not sacriledge to wish that RPG was more like C and vice-versa. Every language has it's strong points-- although I'm opening up the forum for more humor related to "mistake" languages of the past! I once had to code a Hurricane analysis and forecasting package for FEMA in QBasic. It even implemented fuzzy logic gates. I think it might have been easier in assembly language Scott

[dacust]

Fixed Format: Is It an Addiction?

So, I wonder when they are going to write an INTERCAL compiler for the iSeries. Then we'll find out who the REAL programmers are.... Actually I like most of what has happened to RPG over the years since I worked on the 34. It just seems to me that the /FREE code is moving to another language. I'd be happier if they'd write a /FREE compiler and also have the old RPG IV compiler. The mixing of the two just seems patched to me. Now I have more opcodes to track down. There are opinions on both sides as to which is easier to read, but mixing them together in the same source file makes BOTH harder to read. I personally like the /FREE code because it looks like other languages I am used to programming in. But, day-to-day I find I'd rather code the old column RPG. Maybe it's just because I'm an old fart stuck in my ways. -dan

[elassiter@coresource.com]

Fixed Format: Is It an Addiction?

The mere mention of the preference of arcane fixed format over the modern easy flow of /free makes me cringe. It's akin to the statement 'We are the government and we are here to help you'. IBM is doing everything it can to keep RPG procedural coders alive with all the functionality, API's, and modernization of its language, trying to ease them into a more object orientated, reusable code environment. I wouldn't scoff at their efforts with such superiority, but would embrace any efforts to keep it moving forward. Look how COBOL is left dying on the vine by IBM on the iseries, don't think RPG is so good on this platform that it couldn't experience the same fate.

[robberendt]

Fixed Format: Is It an Addiction?

Too often I hear about a shop dictator that forces fixed format upon their shop because they wrote a tool years ago that only works on fixed format code. They don't allow any new technique: /free, sql, newer keywords in F specs, continuation lines, certain methods of defining constants, etc; that may conflict with this inflexible tool. Time to either rewrite the tool, or purchase one, or reevaluate why you were using the tool in the first place. For instance, on the S/36 I used to love DocuMint. But lately I just haven't found a use for it. Maybe it's because the editors, (and the processors), have progressed to the point that scanning for a certain character string in a library is no big deal.

[David Abramowitz]

Fixed Format: Is It an Addiction?

SMMinke wrote: "Let RPG be RPG" is tantamount to saying that the languauge shouldn't evolve. That is your interpretion. I never said that nor implied it. There is a major difference between form and function that IMO should not be taken lightly. Providing a different style, or "look and feel" for performing the same functions is not evolution, it is transmogrifcation. IMO RPG has plenty of room to evolve without changing the entire style and character of the language. For instance the basic tenets of RPG IV have been an evolutionary step over previous incantations, but the style is still RPG. Here are two things that might be done to improve the RPG language:

1. Provide a natural method of establishing multi-dimensional arrays e.g. ArrayFld(x,y)
2. Provide an easier method of CGI programming. Here Sysin and Sysout could be defined as files within the "F" specs. Perhaps as SPECIAL rather than DISK.

I'm sure that if given only a little bit of thought, virtually every reader could come up with one or more evolutionary RPG improvements that do not change the basic character of the language. Dave

[rmorita@agriumretail.com]

Fixed Format: Is It an Addiction?

Hi. I'm posting for the first time. Years and years ago, Paul Conte (whatever happened to him ???) came out with what he called RPG/free back then. I still think of him as a pioneer of free format RPG programming. He had some excellent, revolutionary ideas. RPG/free was a translator that ran before the compilation. It converted your RPG III source program that was written in a completely free format into the fixed format. It worked great except for a couple of problems. Since it had been written in C, it run very slow. Then when we upgraded to the next version of the IBM software, it no longer worked. I ended up having to write a free format translator myself, using RPG III. Although I am now programming in ILE/RPG, I'm still writing in a completely free format, using my own translator to change my source program to the fixed format before compilation. I'm very pleased that the IBM is FINALLY supporting the free format programming. But I find their methods very cumbersome. It required the use of /FREE and /END-FREE, and a semi-colon at the end of each line. This is besides the fact that they do not support all operation codes. Although my method will add several seconds to the compilation time, I like the fact that I can code my program without having to worry about whether an operation is supported or not. Ryoichi Morita Programmer, Western Farm Service, Inc. Fresno, CA

[Guest.Visitor]

Fixed Format: Is It an Addiction?

Seems to me that everyone here has completely missed the point - not on the article, but the core issue of "readability" of programs. I can't recall the number of programs that I have seen - whether C/C++, C#, Lisp, Fortran, Cobol, RPG, or whatever - that are syntacticly correct and totally incomprehensible! Most of this stuff we write is not Plasma Fusion Analysis. And, even if it was, if it was WELL-COMMENTED and designed it could be easily understood and maintained by any decent programmer. The basic purpose of readable syntax is maintainability in my opinion and has little to do with Free vs. Fixed Format. There's nothing you can write that can't be written, but there's plenty you can write that can't be read! The advantage of Fixed Format is it's limitations. A place for everything and everything in it's place. Limitations can offer us conciseness and inventiveness (in overcoming the limitations). Free Format also offers us inventiveness, but without discipline and direction it becomes just another bag of worms impossible to sort out. This is not to say that Fixed Format cannot produce excellent spaghetti code also - we've all seen (or written) fine examples. Maybe, if anything, all program compilers should be created to reject source code that isn't at least 1/3 comments or so. Not that this would ensure better programs, but it would at least REMIND us everytime we compile that we should be WRITING BETTER PROGRAMS. Believe me, it is no solace at all to see neatly indented program source code (one freaking parenthesis or brace looks the same as any other to me) if you don't know what the hell was running through this person's mind at the time.

[Guest.Visitor]

Fixed Format: Is It an Addiction?

While I disagree that fixed format's limitations are any type of advantage, I think that the discussion you are starting here has to do with programming style-- regardless of the language. I regularly tell programmers that THE number one rule is to comment your code. The pattern I see all of the time is that our new coders-- fresh out of college-- are taught to comment their code. Most of them have cut their teeth on C or Java, and thus know the importance of commenting. They often ask me if they are "over-commenting", to which I reply that "over-commenting" is the least of my concerns. Where I run into trouble is the older dyed-in-the-wool "Senior Programmers" who have long ago abandoned commenting because they mistakenly assume that they are the only one who need to be able to know what their code is doing or mistakenly think that they are creating "job security" by not commenting. The worst are the Senior Consultants who abandon commenting to "Get the Job Done and move on to the next Client"-- leaving a mess of spaghetti code that only works when they are getting paid. They will argue up and down with you on the value of commmenting their code. Either way, I get what you are saying. It's just sad to have to rely on fixed format (and don't even get me started on those who still use numbered indicators) to guarantee that code looks somewhat uniform. Most folks comming out of college know how to make free format code look uniform. As you mentioned though, it does give them the ability to make a real mess. Of course, IMO, as long as they will indent their DO/IF/FOR/WHEN 's-- it beats fixed format to death on that fron t alone. I can't tell you how many times a "hard-to-find" bug is found to be an error in a loop in fixed format. At least in free format, when coders take the time to indent you have an inherent idea of where you are in the logic. But, as you say, if they fail to COMMENT, then it doesn't matter what they've done. I had a professor who would fail your project if, in his opinion, you missed a SINGLE spot where commenting should have existed. He would say, "If you lose me, you lose". Too bad this type of training doesn't show up more often. It would make all of our jobs easier.

[rmorita@agriumretail.com]

Fixed Format: Is It an Addiction?

The problem with comments is that they are never compiled and therefore not verified. Comments can be ANYTHING. I've seen too many programs whose comments do not match the actual codes, which add a lot of confusion. Wrong comments are worse than no comments at all. If you do decide to comment, it's best to describe "why" instead of "what". You can tell what the program is doing (well, most of the time, anyway) but it's oftentimes difficult to know why it's doing it. ________________________________ Ryoichi "Roy" Morita Programmer Western Farm Service, Inc. Fresno, CA

[David Abramowitz]

Fixed Format: Is It an Addiction?

If you want to compile comments, place them in an array. Dave

[dacust]

Fixed Format: Is It an Addiction?

Yep, David, at a software compamy I worked at, we put the copyright notice in an internal table so it'd be included in the complied object. Now days I think I'd do the same as a constant(s), instead (don't have to code the comments at the bottom, and then jump back up top to make sure there are enough elements to hold it). However, I'd think it'd be a little cumbersome to do this for normal comments. They wouldn't be near the code they commented. Using Turnover or Aldon CMS, or any other source control package, you could be sure that the source always matches the object, so IMO making sure the comments are in the objects should not be necessary. -dan

[buck.calabro@commsoft.net]

Fixed Format: Is It an Addiction?

> If you want to compile comments, place them in an array. Hi Dave, I think Roy means that you can have something like c* increment by 35 c eval x = x + 34 In other words, the comments don't match the code. The compiler can't verify that the comment means what the code does. This is an extreme and ridiculous example, but I think we've all seen comments like this. I tend to follow Roy's advice and comment 'why' rather than 'what.' When working in a new section of code, I type my comments first, and then fill in the code around them, so c* prime the loop c* top of the loop - once for each subfile record c* out of records too early - exception! c* validate the product code c* invalid code - exception! c* next record c* if any exceptions occurred, disallow the update key and c* force to make the user fix all errors before c* updating. Then I'd write the code required to do what the comments indicate. This way my comments tend to indicate the intent of the code rather than try to elucidate the code. I'm of the opinion that if the code is obscure enough to require comments to the maintenance programmers (me) who will follow, then the code needs to be reworked so that it is easier to understand without the comments. Not arguing against comments; rather in favour of more legible code. --buck

[Guest.Visitor]

Fixed Format: Is It an Addiction?

Don't you mean this? x += 36; Just kidding. Chris

[Guest.Visitor]

Fixed Format: Is It an Addiction?

"I type my comments first, and then fill in the code around them" This is the method that I teach at our shop. It does two things: 1) Insure that at least rudimentary comments exist. 2) Keeps the programmer in touch with what he/she's trying to do in that section of code as it relates to the BIG PICTURE. Also to agree with your point about obscure code, I often tell folks that if they are having trouble commenting a section of code, then that's a clear sign that the code may need to be reworked. In this way, commenting serves as a double-check on your logic.