Overseas Letters and Required OOP

By Kirk Chase, Editor

December 1990 comments

Jon Kleiser

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

My comment:

A SIMULA compiler for the Macintosh is available from

Lund Software House

P.O. Box 7056

S-220 07 LUND

Sweden

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

Denmark

E-mail addresses: mjolner@mjolner.dk

jlknudsen@daimi.dk

olmadsen@daimi.dk

Telephone: +45-86-202000

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

My comment:

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, it’s all Norwegian. I may translate it into English one day, but I can’t say when.

Simula-67 For The Mac

Erik Svensson

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. It’s 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 can’t 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

Box 7056

S-200 07 Lund

Sweden

Smalltalk Benchmarks

Jean-Luc Schmitt

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

“Sieve test”
| 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?

Conrad Weyns

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 Symantec’s 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 won’t 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, didn’t I ? With many regards to MacTutor, I would not miss it for the world.

On Location Helps Developers

David Kramer

I recently purchased On Location, and I’ve 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.). I’ve 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. It’s fast, and it’s a great way of learning.

Required OOP

Jeffrey Evans

Several times I’ve started to write about this, but have always preferred to spend my time on other things. Seeing yet another discussion of Apple’s supposed intent to require object programming has finally gotten me into the word processor.

Many times in the last year I’ve 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 can’t be any more clear about it,” or words to that effect, and added that those who don’t 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 didn’t 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, it’s 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 ain’t true.

February Correction

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"