corre@csd4.csd.uwm.edu (Alan D Corre) (04/10/90)
I have been using ProIcon (Icon for the Macintosh computer) continuously for some three months, and am writing to share some impressions at this point. I feel that one's response to ProIcon will be largely determined by how one responds to the Macintosh. I am currently preparing some instructional materials for modern Hebrew reviving some ideas I tried to implement some twenty years ago using programmed learning. Many students liked the approach, but I was bothered by the almost inevitable clumsiness and turgidity of programmed texts, and did not pursue my ideas too far. I feel that the computer offers real possibilities of helping students with the difficult task of learning natural languages, especially those which use exotic scripts. I decided to try to implement this on the Macintosh, because my impression is that students prefer this machine, and when they can choose between it and the other system, they vote with their feet. The fact is that soaps doubtless have a much greater following than dramatic masterpieces on public tv, so one need hardly be surprised that a bright, cheery sometimes gormless approach wins out on the computer too. I hope I don't seem to be an intellectual snob in saying this, because I realise that my tastes are often low-brow, and I could not honestly criticize the individuals (my son is one) who enjoy the Macintosh. But I don't care for the Macintosh. Bad enough that I still have to take out the trash in real life, I don't need to do it symbolically on the screen. These trivialities annoy me as a Macintosh user, but, more seriously, as a programmer I feel the lack of support of a consistent and powerful operating system which will willingly accept my written orders. Using ProIcon is quite pleasant; it just can't get away from the world in which it lives. True it adds some functions presaging version 8, and it has a development system comparable to that of Turbo Pascal, bringing you back to the Editor when an error is detected. But there is a trade-off; the ProIcon Editor is an Editor and, unlike the Editor in Apple Pascal for the II+ for example, does not have an automatic fill mode that avoids the carriage returns when writing straight text. Accordingly I find that having more or less completed a program in ProIcon for which I found the Editor quite satisfactory, I am now preparing the data files which the program processes on my Zenith using my favorite editor JOVE (Jonathan's Own Version of Emacs), and transferring them to the Mac. There is one big addition which ProIcon has, and that is the windows. You do not need absolutely to use these windows if you don't want to. I transferred a lengthy Icon program which gives a visually equivalent Jewish and Gregorian calendar for any year from MS-DOS and UNIX to the Macintosh and only needed to remove the screen controls to make it work nicely on the Macintosh using only the Interactive window. But it is a pity to waste this resource if you are working in the first instance on the Macintosh, and portability is not important. It does however inject a new element into one's programming. Suddenly one has to become to some extent a graphic designer, and this, like programming, is an art, but an entirely different one. The immense flexibility and power of the window functions of ProIcon force the programmer to think about all kinds of esthetic issues which were not really relevant previously. Perhaps someone could do for ProIcon's windows what Leslie Lamport did for TeX -- take over the visual design aspect and let the programmer concentrate on logical design. Lamport points out that "with a visual design system, authors usually produce aesthetically pleasing, but poorly designed documents." I have an uncomfortable feeling that I may be doing the same thing with my windows. With this admission, I would yet suggest some tentative guidelines for using these windows. Perhaps others will have further suggestions which will enable us to build up a body of expertise in this area. First plan the windows which you will need for the entire program. They can be set up at the beginning, their size, position and fonts can be determined, and decisions made as to how they will be connected with disk files, if at all. They do not have to be visible at this stage, or indeed at any stage (I'll address this later.) For example, at one stage of my program I have a setup which looks like this: ------------------------------------------------------------------------ | | | | | | | | | | | | | | | | Interactive Window | Hebrew Window | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ | | | | | | | | | Information Window | | | | | | | | | ----------------------------------------------------------------------- The upper left window gives information to, and gets responses from, the user. It derives its information from a disk file, but the window itself is not connected to a file. The upper right window is connected to an empty file which has been opened for writing, so this window is dynamic. Items appear there (in Hebrew script) which have been prompted by the activity in the adjacent window. This material can be saved permanently if desired. The bottom window is connected to a complete, previously prepared file which has been opened for reading. This is a static window, which the user refers to as necessary, moving back and forth at will by manipulating the bar, arrows and thumb on the right side of the window. This might be a help screen, or a set of relevant information which needs to be handy throughout the exercise. In addition there is a fourth window which the program never activates. This is connected to a file logging the user's activity, hour by hour and day by day, and measuring success. To this file material is constantly appended, and is saved at the end of the program. The user can see it at any time before the program ends by using the pull-down window menu, and clicking on the Log entry, dismissing it after perusal by clicking on its close box in its upper left hand corner. This window just lurks in the background, and some users might never activate it at all. I think this is sufficient to indicate that the permutations of the ways in which windows can be used are vast. It is probably best to try out the window functions in some trivial program, just to get a feel for the manner in which they work. They really do what they are supposed to, but often it is easier to understand what the functions do by seeing them at work rather than trying to understand a verbal description. The documentation does a pretty good job, and is pleasant to look at, but it is really hard to describe all these possibilities clearly in words. -- Alan D. Corre Department of Hebrew Studies University of Wisconsin-Milwaukee (414) 229-4245 PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.edu