RPG and Programming

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”.

In considering the craft of programming, sometimes not enough attention is paid to the people you program with. Of course, if you program alone, this is not an issue, but it raises the issue of who is going to keep you in line.

To give a quick example: During the last couple of days, I wrote a little Visual Basic program to facilitate access to an organized group of mp3 files- more specifically, oral readings of Bible books. To make the routine somewhat generic, I put the location of the data in a record of a data file, and the next record in the file was of the location of the program used to read the data- in this case, Media Player. I would then use these pieces of information to build the command VB would use to play the mp3 files. It worked on my computer just fine, and I copied those locations and reentered them in a data file on the system the program was intended for. It didn’t work. But why?

I came back home to my computer and puzzled over it awhile. I then decided to go lay on the living room couch to relax. About ten minutes later, I bounced off the couch. “You idiot!” I said to myself. I realized that the drive location I specified was G:\Bible. This was fine for my home computer, but my destination computer only had a drive C. I went back and corrected it, and all was well.

This illustrates the value of being able to work with others. I didn’t discover the solution until I had disconnected my mind from the problem. In effect, I had created a new, objective observer to critique my code and the situation. The problem might have been easier to solve if I had had another pair of eyes to look at it, instead of having to clone a mental image of myself for the purpose.

Thinking of that reminds me of a situation of my earlier career (not sure if I already blogged about this or not). I had a problem with a piece of code. I sweated over it for hours. I finally decided to share it with my co-worker, a more experienced programmer. I started to describe my program as I spoke to him: “First I want to do this…..(Description) And then it’s supposed to do this….. (More description) And then I do this… And….Ohhhhhh Boyyyyyyy.” The solution to the problem leaped out at me, and my partner never had to say a word.

I am normally not a fan of having two programmers work together closely while coding, but sometimes having one or two people around to bounce around ideas can help. Once a group gets above three or four, the benefits of having a group seem to waste away. Too much clutter. If you can get a few very good programmers together, I think you can write almost anything. If you get a lot of programmers together, they seem to get in the way of each other. Doubling the number of programmers does not get double the work done. Of course, much better programmers than I discovered that fact a long time ago.

I think I like the group I am in better than any other group I have ever worked with. The oldest one in terms of experience is about my age, but he started when he came out of college, I believe. I think his first language was Algol. (I’m serious.) He has also worked the longest with my current employer, and he has the deepest understanding of the current system. The other programmer is a bit younger than me, but he worked for this employer when he was young as a computer operator, left for about 25 years, then came back to program RPG. Both of them have degrees, one of them with a Master’s in engineering, I believe. (Not sure what kind of engineering.)

Their styles are quite different. The older one is quite methodical, and he navigates the AS/400 with lightning-fast use of the menus. The younger one loves the AS/400, but he is definitely a PC guy. He has enhanced a PC programmer’s editor until he can cut, slice, and dice any data or program from the AS/400 he wants to, any way he wants to. He’s comfortable with Java and Rexx too, which makes his choice of programming options that much greater. I thought I had a quick mind until I met him; now I know I’m hopelessly slow. He is not afraid to make mistakes-if he makes a mistake, he fixes it -  while fear of making mistakes is my biggest fear. The only claim I have to superiority over them is my greater experience with RPGIV - but as fast as they can learn, that advantage will not last indefinitely.

And the best part is, we value each others’ abilities. Blend all this with management that points us in the right direction without being intrusive and lets us brainstorm and try fresh uses of our programming resources, and it would be hard to find a better programming group or programming environment.