Letters

Response to Question on Neon

Chris Noe

Yes, Neon excels at prototyping! The Forth "environment" is natural for incremental function construction, while providing MacApp-like support long before MacApp was ever heard of. The object-oriented approach is what the Mac is all about.

Pierre has come across a persistent problem with Neon version 1.5: if you have any material on the Clipboard when starting Neon from the Finder, it will produce a bomb box. This happens because the nucleus and dictionary are kept as separate pieces, and must be "docked" at an exact offset. Having anything on the Clipboard wedges a small but deadly datum between the two pieces, rendering the dictionary useless. Neon version 2.0, now available, corrects this problem by using an improved launch technique. In addition, version 2.0 is Mac Plus compatible, supporting HFS & all the new ROM routines and providing an integrated decompiler. Also, applications compiled under 2.0 install as a one piece file and are Switcher compatible. Many of the things we have done with 2.0 have been a direct result of our users' wish lists.

You Made Our Month

Anthony Urrico

I am delighted to see that the Best of MacTutor is now available. I have been receiving MacTutor for six months now and I find it to be an indispensible resource when it comes to the Macintosh. Even reading the articles based on languages that I am not familiar with provides useful insights into the inner workings of the Mac. I especially like the articles that demonstrate the use of various Mac programming techniques through the development of small applications. This type of article is particularly enlightening, for it provides both a technical discussion of the relevant concepts as well as meaningful program examples that demonstrate the use of these concepts. I hope to see more of this type of article as well as more articles using Modula-2, since Modula-2 (MacMeth from the Modula corporation) is my language of choice.

Although I am not an "expert" programmer (yet), in the course of my graduate work I have read many computer journals, and none provides the reader with more practical information about programming than MacTutor. I take my hat off to you and your staff.

ZBasic is Bug Free

Howard Craft

As described by some of your other readers, I have lived through the frustrations of the series of bug-fixes of ZBasic. Last week I received version 3.2. The bugs are gone! As far as my programs are concerned (each is about 120K of code), there are no more system bombs, no more freezes, and what works on the Mac Plus works on the Mac 512K. Hurray, the Gariepy's of Zedcor have produced what I consider to be the ultimate development package for the Mac! With each new beta version, they have added new features until there is no longer a need to understand very much about Inside Macintosh. I am free to pursue MY ideas, not the inner workings of the Macintosh ROM. I have one request to make of Zedcor, however. Do the same for the IIGS, the ST and MS-DOS running under Windows and I'll be ecstatic. Then I can stop worrying about how I'm ever going to convert my thousands of lines of code into C so that I can create programs with the elegance and sophistication that I can now write for the Mac using ZBasic.

Chairman of Zedcor Speaks

Michael A. Gariepy

Quite a number of changes, fixes and enhancements have been made to ZBasic. INKEY$ may be accomplished during event trapping with DIALOG(16). In many respects, this is much more useful than INKEY$ since it will hold up to 64 keys in the queue.

Compile time errors may be edited with the Macintosh type Editor now. After the error shows up on the screen, just press Command E to put the cursor directly on the offending line for editing. The line editor does not have to be used at all if you don't want, since we include two Macintosh type editors along with the regular editor. In addition, version 3.02E is being worked on, which will have a completely rewritten EDIT WINDOW.

ZBasic has only been on the market since May 1, 1986. First releases invariably have glitches, since 50 or 60 beta testers just don't find the problems, or give us the feedback, that 10,000 plus users will.

Byron G. Zollars

Yours is the best Mac magazine I've ever seen. Keep up the good technical articles that have made your magazine stand out from the "business-oriented" Mac journals. Please find enclosed an order for all the back issues that I missed by not subscribing soon enough. I can't wait to digest them.

Back to Resume Procedures

Jim Matthews

Thanks for the follow-up re: resume procedures. You can test a resume procedure by making your program crash (dereference an odd address, call non-existent traps, mess up the stack pointer, or just call SysError) without any means of recovering, such as a debugger or one of the public domain "crash-saver" programs. In Lightspeed Pascal I assume that Lightsbug would regularly trap system errors, so you'd have to "Build Application" and run the program standalone. The fact that debuggers and sophisticated development systems like LSP catch system errors is one reason that developers can get along without resume procedures, but most users aren't so well prepared.

There's a good discussion of resume procedures on page 362 of Scott Knaster's How to Write Macintosh Software. Knaster argues that the resume procedure should try to save important data and then reset the machine, since the system heap might be screwed up in a way that could come back to haunt the user if it just exited to the finder. I disagree. For every time that a program might mess up so badly as to wipe out a disk, a hundred ramdisks could be saved by a resume procedure that just quits to the finder. But it is something to think about before saving a crashed system.

He Likes It

Charles H. Rutledge Jr.

Please send your author's kit containing information for submitting articles to MacTutor. While I have your attention I might as well mention that your magazine is great great great great!!! Thanks for the only magazine (except MacUser) of the twenty or so I see each month that I read from cover to cover!

On Mac Languages and Speed

Robert B. Basham

Mike Morton's October article on timing code segments addresses a concern familiar to anyone who works with languages other than assembly. Due to my own concerns about program speed with Neon, I have made extensive use of a timing technique similar to Mike's. After timing almost every word in the application I am working on, I have reached some tentative conclusions about program speed and Macintosh languages:

1) The Sieve benchmark greatly exaggerates any user-apparent speed differences between languages.

2) Modifications in basic algorithms and language-specific techniques can have far more effect on program speed than overall language speed.

3) A user-apparent improvement in speed usually requires anywhere from a 4- to 10-fold increase in speed. In other words, a screen redraw that seems slow to most users will still seem slow if its speed is only doubled (much less improved by only 30% or so). But an exception to this is when you are trying to dodge the vertical retrace while drawing on the screen. In this instance very small differences in speed can determine whether or not the image will be flicker-free.

4) In screen-oriented programs, almost all of the program's time is spent in toolbox calls, which are, of course, independent of the program language.

5) Efficiency bottlenecks other than toolbox calls are often confined to very small code segments. By effectively identifying such bottlenecks and coding them in assembly, supposedly slow languages can rival the fastest compiled language in terms of speed.

(Note: Source code for my Neon timing word is available on GEnie as file #171 in the MacPro RoundTable).

More on Mac Languages and Speed

Richard Ward

Reading Mike Morton's Advanced Mac'ing article made me curious to try to time out a few ROM routines of my own. I tested SetPt, SetRect, AddPt, and EqualRect in both LightSpeed Pascal and TML Pascal v2.0. Results are as follows:

This set of timings was done with the loop counter set at 100,000. Base time for the empty FOR loop statement was 8.3 µsec for LSP and 9.5 µsec for TML.

The times for LSP and TML are nearly identical in every case except for the "roll your own routine" where the compiler has to set up a procedure call. Here, LSP is about 10-20% faster than TML. Comparing the SetPt times to the times Mr. Morton indicates for LISA Pascal shows LISA Pascal about 35% faster than either TML or LSP in the "In-line time" comparison. It would be interesting to see some timings for other types of ROM calls besides QuickDraw.

What is probably the most important benchmark though, is the turnaround time. This is 8 seconds for LightSpeed and 59 seconds for TML (on a 512E with a Warp Nine 20-meg HD). I really enjoy reading MacTutor. Keep up the good work!

Correction on QUED™

Jim Lewak

One of MacTutor's readers in the August issue got some misinformation about our Editor QUED™. The maximum file size it can edit is memory size, not 32K.

The following features will be included in next year's 2.0 version: user-programmable macros, wild card Search/Replace (regular expression), multiple clipboards and multiple Undos. We'll need to raise the price for 2.0, but registered owners may upgrade at the price difference.

In the November MacUser, Steve Bobker refers to QUED™ 1.3 as the best Editor on the market. We have heard of excellent reviews in other publications and have received nothing but praise from its many users.

All About C

Rollo Silver

Here's perhaps the most poignant bug I've been bitten by in more than 30 years programming, man & boy:

#define b *SS  /* top of (my) stack */
#define a SS[-1] /* next to top */
...
(several lines of code involving lots of a's and b's)
return a/b;

This bug is a black widow, and it took me many days to recover from the bite, praying hard for the souls of Kernighan & Ritchie. The last line expands to:

return SS[-1]/*SS;

The "/b" is turned into the beginning of a comment (!!) and the compiler barfs about a missing semicolon, or some such red herring. Most UNIX C compilers have a "-P" option, or "-E" in Berkeley 4.2 UNIX C: "Run only the macro preprocessor on the named C programs, and send the result to the standard output", which quickly unmasks this kind of horror show, but most Mac C compilers I've used lack it. I swore to myself years ago that I'd always put #definientia in parens!

By the way, my candidates for what's most egregiously missing in Mac C systems are:

1) A symbolic debugger, capable of handling names for variables allocated on the stack.

2) A lint (the next version of Lightspeed C is supposed to have a construct which will help catch inconsistencies between the formal parameter specs in a function definition and the actual parameters given in a call).

3) A preprocessor-only option in C (Consulair C has it)

4) A full-featured grep

5) 32-bit ints (Aztec C68K, Lightspeed C have 16-bit ints).

The lack of 32-bit ints creates more problems than one might think. I know you can hide long/short/int choices in typdefs - but there are still problems:

a) Switch statements can't handle quantities > 32767.

b) You can't have static arrays with > 32767 elements.

c) You need a special, non-portable "mlalloc" or "lmalloc" to allocate dynamic arrays with >32767 elements.

d) I get lots of system bombs due to stack misalignment bugs (mea culpa).

e) I'm constantly (pun intended) forgetting to put the "L" after numerical constants that are (in some contexts!) too long, e.g., 100000, and having them silently reduced mod 32768.

f) Library functions like write are restricted to writing at most 32767 chars.

g) Finally, the worst possible screw (K&R, sec. 7.4, page 189): "If two pointers to objects of the same type are subtracted, the result is converted to an int representing the number of objects separating the pointed-to objects...". I know I can do something like

((long)p - (long)q)>>2

if p and q are e.g. pointers to ints too far apart, but...shit! How do we get from the PDP-11 world, with its 16-bit address space, to the 6800x0 world, with its 24/32 bit contiguous address space (leaving segmentation to Intel)? Since this is an impossible restriction for the Mac, both Aztec and Lightspeed depart from the K&R specification to make the following kind of thing work:

int *p,*q
p = 0;
q = p+75000;
printf("q-p=%ld\n",q-p);

except that a properly structured program incorporating that fragment and compiled by Aztec C68K (version 1.06h) prints "620265475", unless the second arg of printf is explicitly cast to long: (long)(q-p).

[At MIT in the 60's, a hacker was a programmer who had great love for programming and produced code admirable for its elegance, speed or compactness. Since then, the term has been redefined to mean a kind of electronic burglar or vandal. Sigh.]

More On Lisp

Stephen Miner

I have enjoyed reading your magazine for the past year and look forward to another year of informative articles. Despite your overall quality, I have to admit disappointment at your recent lack of articles on Lisp programming. I was originally attracted to your publication because of its column on Lisp, and I'd like to see more coverage of Lisp in the future.

But instead of just complaining, I've decided that I should try to contribute something to help promote Lisp on the Macintosh, so please send me an author's kit.

Reactions to MPW vs IBM

Roger Voss

Other than perhaps working on Sun Microsystems workstations, I know from the range of my experiences with software development systems and programming languages that I can state quite unequivocally: Apple's Macintosh Programmer's Workshop (MPW) environment is the best, bar none, software development system that currently exists (notice I didn't was say commercially available) on any industry-popular microcomputer.

If only the rest of the programming community knew of the productivity, ease of use, sheer power of the integrated script language, etc., of the multi-window MPW Shell/Editor. The MPW Shell embodies the great ease, simplicity, and beauty of Macintosh text processing combined with the power of a Unix-like shell. I have seen or used the great editors and command shells touted for MS-DOS and a lot of Unix systems, but none so far have approached being as impressive and highly productive as the MPW Shell/Editor.

Then there is the flagship language of this environment, MPW Object Pascal (the word object denoting that this is a hybrid object programming language with such characteristics inherited from Smalltalk). MPW Pascal is highly modular and separately compilable, a la Modula-2 and Ada. It also has a mixture of C-like abilities added to it. The fact that this language is object-oriented makes it currently the most modern and of course the best production programming language around. MPW also has a GreenHill C compiler with it that is fast and supports all the latest popular C extensions. I like it a lot. What is really tremendous is that it's simplicity itself to link Object Pascal, procedural Pascal, procedural C, and the 680x0 assembly language routines together into the same program while under the MPW environment. Object programming lends by far the best approach for constructing complex software projects that need to be easily extensible and maintainable. My own software consists mainly of separately compilable Object Pascal Units (Brad Cox "Software ICs"). But then C will do a few things here and there that make it highly desirable. About 5 to 10% of my code is in GreenHill C. Then every so often I need to add just a smattering of some arcane assembly language manipulation. I should add, though, that the MPW assembler is a mind blower. It, too, can be used to do stand alone object-programming and interfacing to the MPW Macintosh MacApp object library.

Instead of C++, check out the latest Objective C from Productivity Products International (PPI). This is the firm that has both Brad Cox and Kurt Schmucker. They are designing a new version of Objective C that will have all the wonderful things of C++ but will not have its stupid limitation in regard to selling procompiled Software ICs.