Apr 91 Letters
Overseas Letters and Required OOP
By Kirk Chase, Editor
December 1990 comments
Some comments/answers to articles/letters in the December issue.
On page 76, Modula-2 Mods / Discrete-Event Simulations, Allen Stenger says:
But the language of choice for simulation work is an old one, SIMULA 67.
As far as I know, none of these specialized simulation languages is available on the Macintosh.
A SIMULA compiler for the Macintosh is available from
Lund Software House
P.O. Box 7056
S-220 07 LUND
UUCP address: ...MCVAX!ENEA!DNA!BORIS
Telephone: +46-46-108044 Telefax: +46-46-131021
It requires MPW. The price (if any!) is unknown.
One of the creators of Simula, professor Kristen Nygaard at the University of Oslo, has now created a new programming language called BETA. As far as I know, BETA covers most or all of SIMULA, and much more. BETA is also available for the Macintosh, partly thanks to Apple, Cupertino.
An extensive article about BETA appeared in the Salamanca EUC Conference Proceedings (1990). You may get more info about BETA from
Mjølner Informatics ApS
(Attn.: J. Lindskov Knudsen, O. Lehrmann Madsen)
Science Park Aarhus
Gustav Wieds Vej 10
DK-8000 AARHUS C
E-mail addresses: firstname.lastname@example.org
In the future we may see regular articles about SIMULA or BETA in MacTutor. (Who knows?)
Page 92, Mousehole Report, From: Derek, Re: BBS Writing ...
I had much the same needs as Derek, and I decided to write my own BBS software. Since I am very fond of HyperCard, I used that, and I am quite pleased with the results. My BBS has been in use at a test site for about four months. However, its all Norwegian. I may translate it into English one day, but I cant say when.
Simula-67 For The Mac
FOA 22 (National Defense Research Est.)
In the December issue of MacTutor, there was an article by Mr. Allen Stenger. In the article, he mentions Simula-67 and professes to no Simula-67 available for MPW. Its sold (and Made) by Lund Software House AB (full address at the end). The compiler confirms to the SIMULA standard and has no restrictions. The data segment is restricted to 32K, and this places some restrictions on the total size of the program. The data segment is used for:
1: local variables of the run-time system
2: for templates (a description of a block used by the RTS)
3: for strings and floating-point numbers used in the program
This means that a SIMULA program cant be bigger than between 4000-10000 lines of source.
Also the generated code for a block may not be bigger than 32K, but in practice this is not a problem. Note the above applies to version 4.07. There might well have been changes to newer versions.
I might add that FOA, a long time user of Simula for both event-driven simulations and general programming is converting (or has converted) to Ada, mostly due to industry demands.
The address to Lund Software House is
Lund Software House AB
S-200 07 Lund
As the OOP stream is going stronger in the Mac world, MacTutor forgets Smalltalk and specially the implementation from DIGITALK. I have tried the benchmarks you ran for Prograph. For the accuracy test, it took 0.733 seconds, and for the sieve test, 16.866 seconds on an SE/30 (without any add-on). As long as the tests are meaningful, the results are good if you consider that Smalltalk/V is not native 680X0 code but uses a virtual machine and byte-code.
The following is the Smalltalk/V code:
accuracy test | x s start stop|
start := MTrap TickCount.
x := 0.0. s:= 0.0.
1000 timesRepeat: [ s:= s + (x * x). x := x + 0.00123].
stop := MTrap TickCount. ^(stop - start)/60
| flags k count k prime start stop|
start := MTrap TickCount.
10 times Repeat:
[flags := Array new : 8191. count := 0.
1 to:8191 do: [:i|flags at:i put: 1].
1 to:8191 do: [:i|(flags at: i) = 0
ifFlase: [prime := i + i + 3. k := i + prime.
[k <= 8190]
whileTrue:[flags at: k put: 0. k:= k + prime].
count := count + 1]]].
stop := MTrap TickCount. ^(stop - start)/60
Benchmark Challenge or Brain Challenge?
About Benchmark Challenge. Walt Davis, Steve Bayer in the September issue.
Looking at their Table1 and Graph1, I ponder upon two questions, both to do with the results of the Case examples:
- Does the processing time get close to zero if the control variable b were to increase further?? (Hurry and buy Symantecs Pascal in that case)
- Why is the processing time in the Case-examples constant?
Please publish a disassembly of the produced code. It should be most enlightening!
And let me congratulate: A timing of 20 seconds for either 1x1million or 15x1million useless Pascal Case-tests on a MacPlus is about 3 times better than I can manage with assembly .
Here is a list of the Mach2 Forth Case-equivalents. (I wont divulge what the If-Else-Then equivalent used: too much parameter fetching, pushing and popping). Run on a MacPlus, in Secs & Ticks, with 60 Ticks = 1 sec.
b Forth-Case my-poor-Assembler-Case
1 18-56 9-43
2 23-57 13-19
3 29-26 16-47
4 34-22 20-21
5 39-17 23-53
14 85-26 55-27
15 90-13 59-08
>15 88-15 59-06
Included in both the Forth and the Assembler Case is the time used by the MACH2 Forth DO-LOOP construct which was a constant of 3 secs and 44 ticks.
My Assembler is lousy, or my MacPlus is living a life of its own.
Still, I took up the challenge, didnt I ? With many regards to MacTutor, I would not miss it for the world.
On Location Helps Developers
I recently purchased On Location, and Ive found an interesting way that programmers can use this indexing utility. I have about 4Mb of sample source code scattered through thousands of files (TML Source Code, Apple DTS code, etc.). Ive used On Location to fully index these files. Now, when I need an example of how to use any function, I just call up On Location and search for all of these references to this function from my source code collection. In addition, I can view the text in each sample source code file and cut & paste into my own program. Its fast, and its a great way of learning.
Several times Ive started to write about this, but have always preferred to spend my time on other things. Seeing yet another discussion of Apples supposed intent to require object programming has finally gotten me into the word processor.
Many times in the last year Ive heard this talk: programmers will eventually be required to use object programming to work on the Mac. People have gone on and on about it.
The whole thing started with an article in Apple Direct in which a certain Apple guru made the announcement that future operating systems would require OOP. He was very explicit, even saying, there-we cant be any more clear about it, or words to that effect, and added that those who dont learn OOP now will have to learn it later. At the time I discussed this with a friend, and, dumb guys that we may be, neither of us could figure out a way that such a trick could be accomplished without leaving behind ALL existing Macintosh software, something no sane company would consider doing. So I wrote the author of said article and, guess what-he replied that he didnt really mean it.
What he really meant was that he thinks object programming is neat and that, in the future, those who use it will be more successful, so that everyone else will have to use it in order to compete. In a manner of speaking.
Clearly, this is not the same thing as saying that Apple will require OOP in future operating systems. In fact, its the same sort of thing that could be said by any committed fan of any programming environment. But no correction has ever been issued, and editor and readers everywhere apparently have swallowed this dubious-sounding proposition without a trace of doubt. It aint true.
A line, at the bottom of page 22 in the February 1991 issue was inadvertently left off. The line reads as follows:
"The cursorEvt event informs the EA that the cursor is inside"