RPG and Programming

I finally found the article I read back in the 80’s about “Why You Should Learn to Program“, by Chris Crawford, an Atari game developer at the time. Evidently he had spoken on the subject somewhere; afterwards, he put his notes essentially into article form; he then felt it necessary to flesh it out with additional material.

At first glance, though, this seems to clash with the message of Peter Norvig, who either works at or has worked at Google, in his article (which I also find authoritative and based on good research) ” Teach Yourself Programming in Ten Years “. These two articles present somewhat contrasting views of the craft of programming; but I find them complementary.

Mr. Norvig’s view is the kind of view that I would expect of professional programmers. He believes that programming that not something that you can learn from a “Learn Language X in 21 Days” kind of approach. In fact, he even mused that 10,000 hours would possibly be a better view of the matter than ten years.

However, in giving his recipe for learning to program, his recipe, which obviously will involve hard work, mentions a very important first step: ”  Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.”

He obviously believes it should be fun. And so it should. Even if it comes relatively easily, it will almost certainly bring one a degree of frustration, if for no other reason than that you must, for any nontrivial task, explain what you want to the computer in excruciating detail.

Which brings us to Mr. Crawford’s thesis, consisting of three main ideas on why each of us should learn to program:

1. Recreation.

2. To learn the importance of clear communications.

3. “Learning to program will make you a better thinker.”

I leave you to read the article to get the details of his argument.

Where Mr. Crawford and Mr. Norvig differ are in the goals. Mr. Norvig’s recipe is for a master programmer, who could and would be paid well for mastering his craft- even if he still is doing it for fun. Spending 10,000 hours learning to program is serious stuff.

Mr. Crawford, in contrast, recognizes that there are professional programmers who will be paid well for their work; however, you don’t have to be good enough to write programs for money, to write programs. He gives the illustration of the man who takes pictures of the Golden Gate Bridge and his family while on vacation. A professional photographer would likely take a technically “better” picture and put it on a postcard for the man to buy; but he prefers his picture, because he did it himself. A person need not be a master finish carpenter to enjoy doing his own woodwork. As Crawford says, programming is not nuclear physics; anyone can do it.

He recommended BASIC in his article; even he now backs away in this respect from his 1985 recommendation. The Wirthian languages (Pascal, Modula-2, Oberon) might be better choices. There are free Pascal compilers around; if a visual environment is more your speed, try Delphi; you may be able to find earlier versions for free. You can even try Visual Basic, if that suits you. Both BASIC and Pascal were originally designed as teaching languages; if programming interests you, try one of them. (Look for them; Google is your friend.)

The main thing is, the sooner you can get payback for your learning efforts, the better. For me, RPG allowed quick output, quick results at the start. That made up for the times of frustration that could and would come later.

I highly encourage you to read these articles, which give you a good perspective of the entire programming experience. Mr. Crawford, in particular, may just incite you to find out how pleasurable the ability to program can be.

My previous ruminations on my attempts to learn Oberon-2 has made me think about what motivates people to program, given the native intelligence to do so.

My cohort at my place of employment provides an interesting contrast to me. He has a lot of energy and a very active mind. He started out on computers as an operator in the ’70s running the IBM machine (a System/3, I believe) at the very place we are now. Interestingly,  I found at the same time he had bought a SOL microcomputer as a kit, which he then proceded to assemble. This was while he was yet a teenager. He then learned to program it. He went on to get engineering degrees, continuing to program in whatever programming language was necessary to run the machine he was working on- not necessarily a computer per se, even. He has tweaked a text editor to do some very sophisticated things.

Obviously, he gets a charge out of making the machine that he is working on work. He was doing it before I had ever seen a real computer in person, even though he’s younger than me. I think he is the sort of person who would program even if he wasn’t being paid to do it. The more complicated the task, the better; but he seems to be drawn more to seeing what the system can do more than to any particular mundane, normal business application.

On the other hand, for me computers are an annoyance; they sometimes get in the way of computing- that is, the solving of problems. I have no patience when a computer goes belly-up in the middle of something I’m trying to accomplish. I learned programming when I was 30, past the age of youthful exuberance and loaded with family responsibilities. I would have been in trouble if the programming language available as the way I could support my family had not been RPG, or perhaps COBOL or BASIC.

My orientation has never been on the technical side of things. A simple set of instructions for assembling a bookcase throws me for a loop. Once I was trying to install a set of windshield wipers. There were no words in the instructions, only a series of diagrams. It took me about 15 or 20 minutes to figure out the instructions. My expertise is in logic. I learned to read at an early age, and I can see patterns of ideas very quickly. I can see solutions to problems very quickly; but I have a very narrow focus; sometimes this results in my missing the “forest” (solution) because of looking too closely at the path between the “trees” (the details). I can be very original in finding solutions, as long as the goal is clearly defined, preferably by someone else. I do better building on other people’s ideas than originating my own.

So I get no pleasure from the gory details of computing. The C programming language annoys me because it seems like you jump through hoops to do what you want to do. “Print” becomes an exercise in control characters; in BASIC, “PRINT” is just that, print. And C has loose ends; I don’t like a language with loose ends. C is too close to the metal- or the silicon, if you will.

So I like a programming language with clarity. C may be clear to some people; it is not to me. The same goes for C++, Java, and any number of other languages you could name. I like order; perhaps that’s why I tend to gravitate toward the Wirthian languages- Pascal, Modula, Oberon. I want a language that will help protect me from mistakes by making at least the gross mistakes illegal. I feel uncomfortable with a language that allows you make a variable numeric at one point and alphanumeric at another point in the same program, as some scripting languages do. I am not adventurous in that respect.

So when it comes to screen displays, I prefer to have the system do the work. That is not a hard and fast rule; I once built an AS/400-style data entry screen using GWBASIC because I thought line-by-line BASIC data entry was so gauche. But in general I prefer to program and let the system take care of the screens.

But sometimes I wonder. I do also like system- level things, like writing my own program-file cross reference program. I would get geeked when my partner would suggest various functions for my program, like being able to click on a file name in a program source and actually look at the data in the file or the file’s descriptions or what fields are in the file. I wanted to make my AS/400 do some things his PC could do.

So different people are motivated by different things. My partner enjoys the process. I do too. Sometimes, I guess,  it’s better not to worry about “why” and just appreciate the pleasure.

One thing that has cooled somewhat my desire to learn Oberon-2 is the fact that I still want to program for Windows-styled environments. Command lines and line-by-line data entry just doesn’t cut it. To do that, I will need to go to Blackbox, a programming environment that allows you to generate programs with a Windows feel (or Gnome/KDE, if you are a Windows hater).

To that end, I wanted to find a quality way to produce such a program. I was already aware that there are a number of GUI environments available for Python, so I decided to give Python another try. The GUI package I selected, after some research, was WxPython. I downloaded Python, WxPython, even Eclipse for a good editor and Python compatibility.

After I downloaded these things, though, I became aware of one thing I should have thought of before, something I was aware of even from my IBM midrange experience.

From the very beginning, Screen Design Aid (SDA) was part of the programming experience. DDS was the language used to generate the midrange screen displays, and SDA was what you used to generate the appropriate DDS specifications, which were (and are) compiled. If you wanted a heading on your screen, you typed it where you wanted it. If you wanted a field on the screen, you prefixed a set of special characters with a + in front. For example, putting a +6666666 on the screen indicated a 7-character numeric field; +BBBB, a 4-character alphanumeric input-output field; +99999999, an 8-digit input-output numeric field. When you pressed enter, the + disappeared and the field remained. Since you would no doubt want to give the field a name so you could use it when interacting with the program the screen was associated with, you would put a ? in front of the field and press enter and a prompt screen would pop up and allow you to give the field a name and even change its length if desired. To change other field characteristics, you would put an * in front of the field; this would pop up a series of prompts that would allow you to specify such characteristics as high-intensity, blink, reverse-image (from white on black to black on white), and so on. When done, you ended SDA and it would generate DDS specifications, which you then compile as a “file” for use by your RPG program.

Now, Visual Basic it wasn’t; but it protected you from having to key in those DDS specifications line by line. You did not have to get a deep understanding of DDS to produce acceptable screen output. Of course, once you got a good understanding of DDS, you could often make changes directly to ths DDS faster than you could do it by opening up SDA; the point is, you didn’t have to.

With this in mind, you may imagine how disillusioned I was when I opened up the tutorial, and what did I see in the first lesson for WxPython? Being able to size and resize radio buttons, list boxes and pushbuttons and text boxes? No. Source code. To get a box, you type in code. To get a window, you type in code. To get any widget, you type in code, with lots of lovely parameters to enhance your programming experience.

This was not enthralling. I found that WxPython doesn’t act like Visual Basic; neither does V(isual) Python, for that matter. For every little widget, you have to grind out parameter-laden code. The result, judging from the illustrations, is very nice, but it don’t come easy. (Note: There is apparently a plugin for .NET called IronPython that allows Python to be used in the .NET environment; but I’m not sure of the details about it, particularly whether or not it is free. )

Now, whether it’s RPG, Python, or Visual Basic, there is still code to write; but it is not screen code. In fact, you have to work hard to even find the actual source code generated by VB. You are shielded from the details, even as you are (or can be) using SDA in association with the RPG program.

So I will likely shy away from learning Python and WxPython. So what will I do? An experienced Oberon-2 programmer recommended I try the POW! Oberon development environment before I tried Blackbox; but even with POW!, I will still not have the GUI widgets to work with. Since I already have a good feel, I believe, for the semantics of Oberon-2 based upon my study up to now, I may just dive into BlackBox. I am an experienced programmer, so I don’t see that I’ll need to start at “Hello World”.

I am still trying to push myself into actually learning to put the programming language Oberon-2 into practice in an actual project. And I’m still dancing around the periphery of my programming course.

Much of the early portion of the book “Oberon-2 Programming With Windows” concerns itself with actually setting up and getting acquainted with the programming environment. An interesting aspect of this environment is that it is not exactly like the environment Niklaus Wirth created when he created the Oberon language to enable the creation of the Oberon operating system back in the 1980s. The original Oberon system did not require that modules be linked explicitly to a program. They are somewhat independent entities. How this can be so is beyond the scope of this post; but in this implementation of Oberon for Windows named Pow!, one module has to be designated as the main module, which then can be explicitly linked to other modules.

The idea of modules being integrated into a whole is hardly unique to Oberon, of course. The idea of “top-down” design goes back at least to the 1970s, where it was felt that the best way to handle complicated tasks is by breaking them down into less complicated tasks, which could also be further broken down into simpler tasks of simple resolution.

For a general purpose language, this is truly an elegant concept.

Perhaps this is where we see the main difference between elegant block structured languages and the old business languages like Cobol and RPG. I will speak of RPG, since that is what I am most familiar with. RPG IV is what might be considered a “large” language. Everything you might ever want to do in business programming is part of RPG; and when you read discussions of how RPG might be improved, you will read suggestions of features that should be ADDED to the language. You will never hear talk of modules or “libraries” or even “service programs” being able to be referenced by the language. New features must be PART of the language; and if they are implemented, they simply make the language bigger and, in most cases, more complicated.

And so we see this world-view even in the structure of RPG programs. Usually, an RPG program does not consist of a few program or procedure calls in a relatively short mainline. It usually consists of a substantial mainline with occasional calls to subroutines or procedures. There is relatively little need or use of the top-down paradigm, or conceptual model. It is possible to do it in RPG, but the very layout of the language does not encourage it. For example, I recall being amused years ago by an RPG program that had only one one line in its detail calculations; it did all its work in a subroutine named DETAIL, which was called by the calculation   EXSR    DETAIL. The very phrase “service program”, used today to refer to a collection of often-used routines into one module, suggests a servant pressed into duty of a superior routine, rather than a coequal partner in the main processing. The name “subroutine” has the same connotation, even if the subroutines do the bulk of the processing. They are subordinate, called by the main “detail” routine.

As RPG is currently constituted, I would consider this the most effective way of using the language. For example, there is the concept that all file handling operations should be consigned to a service program, which would then handle accessing, inserting, deleting, and updating records in a given file. I know I’ve seen the concept recommended, though I can’t give specific  examples offhand. But when  file handling is so easy in RPG, why bother with a service program when you can do it directly?   ACCT#    CHAIN   MASTER.

So I’m up against a wall of habit and preconceived ideas as I continue to try to expand my horizons, and perhaps my effectiveness, by learning a language built on new concepts and that can be completely described (in the official report on the language) in 16 pages of normally spaced text. Just for comparison, the report for C++ is 740 pages in length. (I am already acquainted with BASIC.)  If I can’t learn Oberon, there’s not much point in trying others.

In a blog post on my son’s blog, I ruminated on helping young people to learn to program and what might be a good place to begin learning programming. At the end of the article, I suggested Oberon-2, a language created by Niklaus Wirth (creator of Pascal and Modula-2) and an associate. At the same time, I bemoaned the fact that I seemed to be unable to learn new languages, perhaps because of burnout or fatigue, perhaps lack of time, or even lack of a suitable project.

I have just about concluded that it is time to put up or shut up. I have a compiler, I have a book, and I have a project. It is time for me to go ahead and exercise some initiative and learn the language.

But perhaps you wonder why Oberon-2? Why not Java, which is also on the AS/400? I have commented on the steep learning curve. I have attempted Java tutorials; I have found them to be of a most forbidding nature. I don’t know if Java is supposed to be a “small” language or a “large” one; all I know is that one look at the documentation (see how long it takes you to scroll through the class list) makes me want to cringe. Of course, with any language, you usually use only subset of a language in your day-to-day programming; the problem here is finding what your subset consists of.

Why Oberon-2? It is object-oriented programming without the gobbledygook. A “method” is a procedure. A “class” is a record type. A variable of a record is an “object” or an “instance” of a “class”. A procedure call is essentially the same as “passing a message to an object”. I find the unquoted terms in the previous sentences more comprehensible than the corresponding terminology (in quotes) that has been perpetuated for the Java and C++ and Smalltalk environment. And it does not appear that it will take that long to learn how to write useful code; that is important for me.

So I propose to begin learning this language, and from time to time report on my progress. Knowing that at least a few people might be observing may also exert a certain social pressure to press on.