Archive for January, 2009

Oberon-2 - Episode 1

Tuesday, January 20th, 2009

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.

Operating systems and programming style

Sunday, January 11th, 2009

A few days ago, I was editing a program in WebSphere, the IBM-supplied Windows programming environment. I was scrolling the screen when, without warning, the program died. I was presented with the disappearance of WebSphere, replaced by a message box: “Eclipse” in the Windows header line, followed by the message line “JVM terminated. Exit code=8096.” This was followed by informative details like “Xquickstart” | “Xms40m” |, “Xmx768m”,…    I’m sure you get the picture. Thirty-one lines of error message. To anyone but someone in tech support at WebSphere HQ, totally useless. And if you did a print screen and found an e-mail address to send it to, their first response would be, “What exactly were you doing when it happened?” and the second would be “Could you replicate your error?”; since I wasn’t logging my keystrokes, just doing my job, all I could tell them was “Scrolling my screen” and “No.”

But this is getting to be a bit of a rant. What I really want to mention is how my background affected my reaction.

I started on an IBM System/3, then graduated to a System/34, then System/36, then AS/400. IBM midrange all the way. All of these systems were rock solid. Probably no computer user who has not worked on one of them (except perhaps mainframe people) can appreciate this. In almost 30 years of experience, I have NEVER had a system go belly-up on me. No blue screens of death. No “Illegal operation” errors. If a program crashed, it was because I or some other programmer had made a mistake, and the system usually told me very clearly the source of the error. No “exit code=7096″. If it gave you a message code, it also told you what the code message said.

And even Unix people, users of the other supposedly rock-solid operating system, have no reason to be smug. For example, I remember working with a Unix guy on a project that involved running RPG on a Unix box. In the course of his work, at one point, his cursor disappeared (!)  Not dismayed, he entered: “tty” (and remember, he couldn’t see what he was typing), hit a control key combination, then “sane” (Cute. The keyboard was insane, and he would restore its sanity.) .  And it worked. On the IBM midrange, such shenanigans were unnecessary. You never lost your cursor. And as for Linux, there have been countless times, while I was working in Linux, that the system locked up when I wasn’t doing anything more than what any other normal, non-technical user might be doing.

When you work on operating systems like the Midrange boxes had, you get spoiled. And, I have found, your programming style is affected. It may be the old batch processing mentality getting involved here, but if you have been a long-time user, you tend to be more careful. My Unix friend was of the sort that would throw together code on the fly and immediately run it, without any sort of desk-checking. I suppose he was of the sort that would let the debugger catch the errors, if the program didn’t show that it was wrong by crashing. I and others on my chosen platform tended to desk-check more. I feel that the more you examine your code, the less likely concealed errors will evade your notice. (And the devil-may-care problem solving process seems to be an issue with programmers of both Windows and  Unix background.) Maybe it was better that debugging facilities in early RPG were so lousy- you inserted a temporary DEBUG opcode into your calculations.

I guess when you are on the Midrange, you are less tolerant of casual errors. When your operating system spontaneously self-destructs, you are not overly concerned when your program you wrote self-destructs. Just hit Ctl-Alt-Delete, and everything will be okay.

I know I probably haven’t proven that Midrange programmers (and by extension RPG programmers, since most Midrange programmers write RPG :) ) are better than programmers on other systems. I probably didn’t prove much of anything. All I know was that my fellow programmers knew exactly what I was talking about when I did a print screen of my Web-Sphere message and gave them a printed copy with my caption: “The difference between the AS/400 and a PC.”