Archive for the ‘Python’ Category

Oberon-2 Episode 2

Thursday, February 12th, 2009

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

And the #1 reason why freeform RPG is best is:

Saturday, June 28th, 2008

#1. And the best reason to code in free-format syntax is: We can finally see the structure of our code as we work with it!

Just a few more words on that last point. Free-format is just that - free. A programmer can choose to start a statement in any column after column 7 and continue through to column 80. So nested logic can now be indented, allowing us to craft code that conveys an immediate and intuitive sense of the order and conditions of execution. Nested fixed-format code can be difficult to work with, and if it’s deeply nested it can be an outright nightmare. This problem is removed in free-format RPG. Properly indented nested control structures tell the story at a glance. It simply takes less mental energy to understand the intent of well-written free-format code.”

Before we go too deeply, note the use of “weasel” words. Weasel words are words that you can use to show, if someone questions you on the validity of a claim, that you qualified it so that it didn’t say what he thought it said. (I learned the expression in a book on advertising.) Note- nested fixed-format CAN BE (not IS) difficult to work with. PROPERLY INDENTED (not ALL) control structures tell the story at a glance. And the reference to WELL-WRITTEN free-format code. This allows you to say that if the nested code is obscure, it was not properly indented or well-written. Somewhat different than the common unqualified claims that free-format code IS easier to understand.

We are not under the illusion that what follows will convince people to use fixed format instead of free-format RPG. What we do hope is that a free-format advocate will look at the whole situation with a more open-minded attitude than he does now, that it is not an open-and-shut case that free-format is easier or more usable.

But to proceed:

1. Note that word “intuitive” used again. As with our previous posts, we ask: Intuitive for whom? And the answer is the same- intuitive for the person who has been trained on block-structured code.

Brian Kelly, a noted ex-IBM Systems Engineer, author, and lecturer, gave these comments in a discussion of what he did and didn’t like about RPG IV:

“Hey, I liked RPG IV when it came out with the larger field sizes and the D: spec and the date operations. I am not as fond of the new RPG with its ILE connotations, difficult to understand procedure prototyping, and Java like built-in functions. I would have been happy without those. I liked being able to debug a customers code by looking on the right side of the RPG page looking for where a variable was changed or an indicator was turned on.” In other words, he liked fixed format, where he could expect to see result fields and indicators on the right side of the page. Free-format is not so easy or comfortable for those who are used to fixed-format code.

But perhaps you would expect that. These old stick-in-the-mud, died-in-the-wool coders are just too set in their ways, aren’t they? So let’s look at it a little more deeply. (more…)