A problem I have had to deal with at home has caused me to meditate on the mentality a programmer must have. Of course, my wife suspects that I may have a mild case of Asperger’s syndrome. If that is true, I would venture to say that there are some aspects of the ideal programmer’s mentality that may resemble autism- and when I say that I do not mean to make light of a serious medical disorder.
I know it’s been quite a while since I’ve made an entry here, but sometimes real life intrudes on the fantasy world of the Internet, so I just became too distracted by the real world. Either that, or I’ve just gotten lazy.
I think of things to put into this every day while I’m at work. Unfortunately, I’m at work when I get these ideas, I don’t make a note of it, or I get too tired when I get home, and the idea evaporates.
One idea that has managed to sustain itself until this evening was an observation on the state of programming in the real world – that is, outside my insulated IBM-i world. Of necessity, even my client must run outside programs and communicate with the outside world, and that is when the sadly amusing state of the computing world presents itself.
I listen as others talk about having to get new systems working on the new Windows 7 boxes. I listen to them go through the song and dance about installing this driver or that, and how it becomes difficult to keep the existing programs running when you get new hardware or install new software or both. After a while, you notice that it’s a new rendition of an old song with new singers and a new group of orchestras.
In the IBM-i world, of course, this stuff is nonsense. We are currently running programs that were written back in the 70’s and 80’s. With this IBM minicomputer (as it used to be called) family, it made no difference. The programs might need to be recompiled when you changed machines, but you didn’t need to create a new version of it- you only did it if you wanted to. No wasted effort. Nothing about the programs had to be changed if the operating system changed versions. But in the Windows world (and I believe in the Linux world too), there are no such guarantees. This always puzzled me when I looked out at my Windows.
And it has touched my world. I played a little bit with VisualAge RPG, and one of my coworkers ran with the idea and wrote an entire system, albeit a relatively small one, using VARPG to talk to our AS/400. (I know, I know. It’s not what it’s called now, but it’s the name most people in the industry identify it with.) We thought it was a very slick piece of work, even though we were aware that IBM wasn’t exactly pushing it. All we knew is that it was a very easy way to leverage our RPG skills into the Windows world. The users loved it.
But now, as time goes on and we get Windows 7 machines in, we have to make sure that if the system goes on a Windows 7 machine, it must be set up to run in XP-compatibility mode. But how long will that last? How long will it be before another “advancement” in Windows takes that option away from us? How long before it no longer becomes “cost effective” for Microsoft to have an environment in which our programs can be run? Then we either have to rewrite them in another language, or we encase them in a virtual machine where it no longer matters what the outside world (operating system) is. I suppose I should be thankful that we at least have that option.
And you can tell that the mindset of the computing world in general is that somehow this is a good thing. Throwaway software. They worry about 32-bit and 64-bit software and the incompatibilities inherent in them. But it’s “progress”. I call it wasteful – but who am I? Just a grunt programmer in an increasingly less popular computing ecosystem.
Sorry, but I don’t have any solutions. I hope somebody does.
I have been reading and thinking about the future of my favored programming language and the computer platform upon which I use it. The latter has been the subject of an extended discussion in LinkedIn. Some feel that the naming of the machine is of little consequence, unless you use the wrong one. It is felt that to call it the AS/400 is inaccurate, since the AS/400 is not called that anymore- which is, of course, true. It is felt that RPG will not survive for an extended period of time because of its intimate connection via DDS (Data Description Specifications) with the 24 X 80 character display green-screen terminal. Others feel that newer innovations may allow it to survive, but only if it dispenses as quickly as possible with the fixed-format (“punch-card”) calculation specifications and move quickly to free-format. There are not many defenders of fixed-format RPG around, and those that use it are probably expected to turn in their coding sheets soon and retire. And, as always, proponents of each view have their own facts and anecdotes to support their view.
I could not hope to make much of an impression on that forum and accomplish anything more than stir up the pot of contention. It is much better to make a one-sided argument here. 
Anyone who cares to argue may feel free to do so. (more…)
It has been a long time since my last entry. Much has happened since then. I made two 2100 mile round trips by car back to Michigan, both of them in connection with my mother, who passed away in June at the age of 98. Other personal situations have cropped up too.
At my place of work, I continue attempting to gradually upgrade the system. In addition to my assigned projects and troubleshooting, I am attempting to use more modern techniques; but I find it interesting to look back and see what things I have tried and not tried to do.
One thing that comes to mind is that I am no longer determined to find a way to gradually move code to free-format. If I write new code, it will probably be in RPG-free; but I am no longer attempting to translate fixed format to free. The job is just too daunting; so many of the old programs are just hideously loaded with indicators, and to do a direct conversion, using Linoma’s RPG Toolbox, creates code that would, especially to a neophyte, be even more confusing than its fixed format parent. With proper use of the toolbox we can eliminate left-hand indicators while leaving it in fixed format, and the tool does a very nice job of cleaning things up.
In another context, I am making changes that effectively are advancing beyond RPGIV as presently constituted. Using IBM routines CEESCEN, CEEDAYS, and CEEDATE, I am trying to free the system from its self-imposed reliance upon a century that runs from 1961-2060 for 2-digit years, as well as the ILE RPG range of 1940-2039 for 2-digit years. The boldest move, of course, would be to change all date references in the data files to at least an 8-digit year, if not actual date formats; but in ancient code from multiple systems, that would take a prohibitive amount of time to convert hundreds of files and programs to do this. What I have done instead is create a number of programs based upon the IBM programs above to quickly do date conversions. In doing this, I am implementing a sliding century, such that the two-digit dates will always reference a century that references the current year as the 40th year of the century. Currently, this means that my floating century is 1971-2070. In ten years, it will be 1981-2080.
A typical call would be: To convert Gregorian (MMDDYY) to Julian, we would call:
CALL ‘GTOJ’
PARM ING 6 0
PARM JUL 5 0
You may note that I am using the RPGIII/RPG400 style of calling the program rather than using the one-line form: CALLP(ING:JUL), which involves the creation of appropriate prototypes. The program GTOJ, for instance, does consist of a module DCONV, which sets up and runs the IBM routines, and module GTOJ, which sets up the input and output for DCONV. They are then combined into program GTOJ. All the routines ultimately use DCONV.
However, I could not see the point of the extensive housekeeping involved in making the programs that call GTOJ and the other programs modularized. You, of course, have to create prototypes for each of the programs (about 15 of them, at last count). Of course, I could put them all in one service program, which to my mind creates another layer of unnecessary complexity. The chief justifications for this seem to be performance and the ability to catch inconsistencies between parameters of the called and calling programs. To me, these are not sufficient reasons. In this installation, performance will never be an issue. Trust me. Our new machine (stupid word processor! I can’t put our favorite machine’s name here – OpenOffice keeps trying to capitalize it) runs at least 10 times as fast as the one it replaced. As for parameter checking, any errors last until the first test is run, after which they are corrected.
Another thing that I have cooled on is attempting to get away from MOVE, etc , in existing code. New code that I write contains very few MOVEs, except for enabling date arithmetic. I just don’t see the point in changing existing code to remove MOVE, unless by doing so I can make the code clearer. IBM has not implemented MOVE in freeform, so I don’t see a meaningful amount of existing RPG code being moved to freeform. This means that any RPG neophyte is going to have to learn to deal with both freeform and fixed RPG formats in his maintenance programming.
So time marches on. We continue to watch the progress of IBM with its initiatives regarding RPG, and we wait to see what impact it will have on our day-to-day work. In a small installation like ours, I don’t think we will ever be cutting edge.
My recent experience on the forum on Bob Cozzi’s RPGIV website underlined the fact that I am not in contention for the title of “World’s Best RPG Programmer”. I posed a question that involved the use of APIs and prototypes, and I submitted my sample code. I got my question answered, but not before it was made very clear to me that my abilities as to APIs and prototyping were considerably below cutting edge.
How do you get to be a good programmer? You have to be intelligent, which can mean you have to know when to be as stupid as the computer. You have to be intolerant of errors. And you have to be willing to learn from your mistakes, as you will make thousands of them.
But beyond these basic qualities and attitudes, other circumstances may determine how deeply you will get into the more arcane aspects of your chosen programming language that will allow you to be among the “best”.
For one thing, your circumstances have to be such that you are exposed to advanced programming techniques. This will likely also be a function of your intellectual curiosity. But perhaps just as importantly, your circumstances have to be such that you will actually have a need for these techniques. You may never be in a position where you will need to access user spaces. While you may see some benefit to variable length fields, you may not see any burning need to start using them. And while much of the benefit of ILE is built around things like APIs and prototypes, it may well occur that your site simply does not need a wholesale conversion of code to make use of called procedures.
As it happened, my experience above came as a result of a need for them. Two-digit years are still used on my system. In calculating the maturity date of a 30-year loan written in 2010, I bumped up against the ILE default for two-digit date fields (1940 to 2039) and got an “invalid date” error when I attempted to generate 3/15/40 to represent 2040. To get around this, I decide to use an API I was aware of, CEESCEN, which allows you to float the 100 year range you want to use for the 100-year period in question. This is used in association with APIs CEEDAYS and CEEDATE to allow you to format dates in numerous different formats. (Google the API names for details.)
However, I was not familiar with how to set up the prototypes needed, and as a result I made some stupid mistakes that leaped out at the knowledgeable participants in the forum, especially Bob. But anyway, with some help, I got the prototypes and program calls to work.
But my learning things like these are in response to a specific need. I don’t have a burning need to learn all or even a substantial portion of the APIs available. I simply don’t need them. The fact is that I am getting paid to write production code, not specifically to “learn new things” . And the fact is also that I am not in a position where I can spend a lot of time outside the workplace learning new stuff, since family and other personal needs and circumstances have first claim on my time.
Other people, by reason of education, career choices, and the employers they happened to have, may have had open to them early in their careers opportunities to work on truly advanced concepts that I never was exposed to and likely never will be. Of course, their being smarter than me, not to mention better educated early on, would also make this more likely My task being to maintain and upgrade code that was from the 1980’s and 1990’s in style, if not always in vintage, I will likely be kept busy doing that for the balance of my career. I like to think I’m good, but I’ll never be the best.
I was going to discourse on another topic, but a response to Buck (to whom I apologize, along with Bill, for being derelict in checking my site’s e-mail), who commented on my previous post, demands a reply. He feels that lack of formal education, while being a contributing factor, is only a contributing factor; rather, it is the midrange habit of being exposed to one programming language.
Actually, I am inclined to agree. The isolation in RPG is real. But we also do well to consider the background of the situation. The earliest IBM minicomputers, the System/3, had as its programming language RPG II. That was it. Small businesses who wanted that computer worked in that language- at least, I’m not aware of others used on the machine, besides assembler.
When the System/34 came out in 1977, the choice of compilers widened. BASIC, COBOL, and Fortran became available. But still, RPG dominated. I’m not surprised that Fortran and BASIC popularity did not rise. But COBOL was big at the time. However, RPG was already a business-oriented language, so COBOL was not really needed from that standpoint, and RPG was perhaps felt to be more terse and easier to learn. Then too, COBOL programmers were already being kept busy keeping the IBM mainframes humming, so there were probably not an excess of them floating around. COBOL has never been much more than a peripheral language on the IBM midrange; useful probably only to those whose business already depended in some way on COBOL, perhaps having COBOL talent already available.
In addition, and perhaps most important of all, The System/34 had no need to talk to the outside world unless it were to another IBM minicomputer or mainframe. There was no need to handle HTML; there was no HTML, because there was no Internet.
This is not to say that RPG was a perfect language. String manipulation beyond the realm of MOVE and MOVEL was very difficult. The two things the designers never got right until RPGIV came along were string manipulation and date arithmetic- being able to get the date 30 days after today, for instance. (One thing I will never comprehend is why they have never been able to enable multiple dimension arrays. In earlier days in a different environment, trying to emulate multiple dimension arrays was a real pain.)
But since the programmers had no other languages to work with, they bent RPG to their will. They created these plug-ugly array- manipulation routines to piece together strings. And they created complex routines to do date addition and date format conversion. We must not forget the famous “magic numbers” - to convert a date in month-day-year for mat to year-month-day, for instance:
MMDDYY MULT 10000.01 YYMMDD. I am still reminded of the RPG programmer of my acquaintance who, with the help of engineers, created sines and cosines and other functions in RPGII.
Now, there may have been elegant functions created in C for such purposes as string manipulation and mathematical functions. But once RPG routines were developed, the C functions were not needed. It really didn’t matter. They couldn’t use C anyway. If you knew what you were doing, you could write assembler subroutines – but that was it. I don’t think RPG couldn’t even call COBOL programs; at least the techniques were not well known for doing so.
So when ILE came around, much of the motivation for calling the now-available C routines was missing. We didn’t need them. RPG routines were already doing the work. Unless there were some performance considerations, programming managers would probably take a dim view of programmers who ripped out the ugly-but-tried-and-true RPG routines just for their own amusement. One could make a valid argument that those routines were a maintenance nightmare. But unless management had a good deal of foresight, this might be a difficult thing to prove to management’s satisfaction.
And yes, programmer inertia was also a factor. My shop has had IBM midrange machines since the 1970’s, and AS/400s since the 90’s. But the first RPGIV program was written on this system in 2007, by me after I arrived.
But now, the IBM midrange does have to deal with the outside world. My company already has an Internet presence, and we quite frankly don’t have to know PHP or Java or the other languages in vogue in order to make the business work. All we have to do is make sure our Internet provider gets the necessary data. And RPGIV provides the necessary tools to alleviate some of the issues that plagued us with earlier versions of RPG. If we need outside routines like APIs or C or Java or Rexx, they are easy enough to call. I have expressed myself in earlier posts about my ambivalent feelings about freeform RPG.
But mentioning freeform brings us to the topic of: How do our employers find replacements for us fixed-format loving old codgers when we retire? That is a topic for another time.
I have been thinking a bit about how our backgrounds, educational and otherwise, may determine at least to some extent the style we use in our programming and indeed perhaps the language we use.
One of my fellow programmers (about my age) graduated from college with a background in computers. Almost immediately he was able to find a position programming in COBOL, then in ALGOL, which is a block-structured language with a relatively free format. He continued to do well at various positions; ultimately, he came to where I work, with many years of experience in programming, but none in RPG. The style here could be described as a blend of RPGII, RPGIII, and RPG/400; fixed format to the core, loaded with indicators. He learned RPG from the ground up in that environment. Sometime after I came along, he was shown freeform RPG.
I, on the other hand learned RPGII from a book and practical experience. I had no computer background when I started to learn. I was of an inquisitive spirit, though, and I advanced in my use of RPG as the language itself improved. I too ultimately became acquainted with freeform RPG.
Now, who do you think uses freeform RPG whenever he can, especially on new programs? You might have guessed it was my partner- if you did, you’d be right. RPG was actually stifling to him; given the freedom to use free format RPG along with the BIFs that work well with it, he has been liberated. On the other hand, as you may judge from this blog, I just have not seen the light or the point. When I write code for new programs, it is in fixed format RPGIV.
We learned to love the way we learned programming, and so our preference now is to do it the way have always learned it, just better.
Illustrating the point that the way we learn to program is greatly influenced by our programming origins was a discussion I just read on an RPG forum about the significance of certain characters when writing CL (Control Language on the AS/400). Instead of indicating a “not equal” test by the common expression *NE, the code used the combination ^=, where the ^ is really a character I can’t find on my keyboard, but looks like the upper-right-hand corner of a rectangle with the top leg longer than the right. The character, as it turns out, is the “logical not”, a character often used in Boolean algebra.
Now, I don’t know who originated that code. Some experienced programmers, though, just did not know what it meant. Therein may lie a tale.
During the time I learned, many if not most of my fellow programmers were not products of any kind of computer science curriculum. They did not learn BASIC or Fortran first, and usually not COBOL, though this was a bit more common. They learned RPG as their first language. They did not learn “computer science concepts”; many, like me, either never attended college or did so only briefly. They may have started as a computer operator, or maybe at another position in their company. Usually it was a small company; it had the smallest capacity IBM computer available, the System/3, or System/32, or System/34. Something about the programming process intrigued or excited them; they persevered, and they advanced.
As time went on, though, and RPG increased in importance, people with a background in computers and computer science began to program RPG. For a long time, they would prove to be stifled if they expected to program like they originally learned to program in other languages. And where the original programmers may have simply accepted, for example, the RPG cycle, and comprehended it entirely, by the time the System/38 came around, programmers who started learning RPG as RPGIII on the System/38 evidently found it mind-boggling.
I can’t count the number of times I have found a test for LR (last record) in the RPG detail cycle in code (usually written by programmers who came from the 38) using an input or update primary file. Unless explicitly set on with a SETON instruction, the LR indicator will never be on during the detail cycle. A programmer who started with RPG II would automatically know this – it would be a part of his upbringing. A programmer who started with a background in computers later would not necessarily know this. This would cause problems if the programmer intended to base output on this indicator test. Usually it would mean that last record calculations and total output would be missing.
Another difference in outlook comes with file processing. A programmer raised on RPGII (usually in a small shop) doesn’t mind the system reading files (primary and secondary) without him telling it to. But I have noticed in discussion forums that people raised on other programming languages (usually learned in college) seem to get bent out of shape if they don’t explicitly get to do the file reading themselves. They don’t really comprehend that this really is quite an advanced feature, much closer to SQL than Pascal.
It would be interesting to find a survey of programmers that told what level of education they had when they first started programming professionally. I would suspect that as a group, RPG programmers would have a slightly lower level of educational advancement than, say, a C or Java programmer. This would especially be true if they surveyed the most experienced RPG programmers. But then, it is results that matter. RPG programmers do not write compilers – we process information so that humans may comprehend it.
Who is responsible for creating software that works? Where should the responsibility lie?
In large software corporations, programmers will occasionally lose sight of this. A Microsoft e-mail involving Bill Gates and Moviemaker is instructive here.
This kind of situation, of course, is probably not unique to Microsoft. But still, who should be the one in charge of software quality? In this case, someone a lot lower in the hierarchy than Bill should have caught the errors and corrected the problems. And I don’t mean the project leaders, either.
I submit that each and every programmer is responsible for software quality, and he or she should be aware that the software he writes should never just be “good enough”. The software he writes should work as it is expected to work, and certainly not crash when it is being used as it is supposed to be used. This is not to say that your software will be bug-free; that may not be possible to guarantee. The next bug in your program (and obviously, we are dealing with non-trivial programs here) probably just hasn’t been found yet. But programs should not crash and burn under the most simplistic of test conditions. (I’ll never forget the time I double-clicked on the WordPerfect icon on my Windows 3.1 desktop and got an “Illegal operation” error.)
Recently, I was making some revisions to my file/program cross-reference programs. It was a substantial change striking to the source of the data I used in my program. When this was done, whole chunks of my program were commented out, to be removed later entirely once the new code was tested. Errors started popping up all over the place. (Never forget that a “bug” is not some creepy-crawly that got caught in your code; it is an ERROR.) I was actually trying to get work done that more directly relates to my job- which is not to create utility programs. I was trying to get a project done with my utility as an aid, and if it wasn’t crashing the programs, it certainly wasn’t acting as it should.
But I was taking it personally; if I write a program, it is supposed to work as designed. My program may not do everything it might ultimately be able to do; but what it does, it should do right. If I right-click on a program name, it should bring up the source for it- look in the right place for it- not tell me it can’t find it or bring up the wrong one. When I click on a file name in a program and hit the appropriate function key, it should show me the file and field description or even the data; it must not lie to me and say the file is not there, and it certainly should not crash because I performed some subfile operation wrong.
What should be the first line of defense against errors, then? It should be the individual programmer. He should consider errors unacceptable. Bugs should not become “features”. He should be willing to beat on his code, test it by as many avenues as possible. Often it is best to forget you are the programmer and just USE the software as the individual user would. If you test it in “programmer” mode, you may tend to not test it in situations where the logic is more complicated and likely to fail; to save face with yourself, you might test it in “safe” areas under ideal conditions rather than push it to its limits.
Consider it a matter of pride. Beat on the program yourself. If errors are to be found, you be the one to find them, not the user. Consider it a matter of dishonor when a user finds an error. You may not be able to prevent users entirely from finding errors; but don’t let their finding errors be the accepted mode of software quality. Whether the tester be the user or some testing team, make their work as light as possible.
Don’t let “Bill Gates” find your errors. You find them.
Take it personally.
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”.