info-mac@uw-beaver (01/04/85)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> I sent a message about a month ago describing the logistical horrors we had this semester in using Macs and Lisas for our first 3 courses. We have now finished the semester, and have gotten back comments from the students. I am not going to comment again on the items I discussed before. It does appear that the students liked the Macintosh, even with the problems. Our impression is that for the first course Mac Pascal took more time to learn than what we used before, which was Cornell's PL/C Synthesizer. The Synthesizer made it nearly impossible to make syntactic errors. Rather than type text, you hit keys to create various program constructs. When you did have to type (as with expressions), they would be parsed immediately. Our faculty felt that this allowed them to concentrate on program design and data structures. This was a pleasant contrast to the normal experience in first courses, where much of the time is spent on syntax. Mac Pascal is better than the typical timesharing system. It does detect some kinds of errors in the editor. However there are still cases where you don't find a missing semicolon until you run the program. As with any compiler, there are cases where the error messages don't help a novice very much (though the error messages are quite good compared to what we see in normal compilers). Mac Pascal has some advantages over the Synthesizer in debugging facilities. It is my impression that most of our students do not use debugging facilities, so that was probably a minor benefit. The net effect is that our first course spent noticably more time dealing with syntax than it had before. However it is still good compared to most other software. The second course was using UCSD Pascal previously. (The PL/C Synthesizer could not handle large enough programs.) Mac Pascal is a dramatic improvement over that. The general quality of its user interface, the language that it implements, and it state of debuggedness (??) are all considerably superior. It is possible that the UCSD Pascal we were using is not typical of the current product. It was for the Terak, which is a fairly old machine. We have some reason to think that newer releases of UCSD Pascal were not ported to the Terak. As you might expect, the limiting factor in using Mac Pascal is memory in a 128K Mac. The assignments had to be carefully designed and tested to make sure that they did not exceed memory. Both array sizes and recursion depth could cause trouble. My impression is that the changeover to Mac Pascal helped the second course more than it hurt the first course. This is particularly true because it allowed us to use the same system in both courses. In summary, I recommend Mac Pascal for instructional use. However I think a full syntax-directed editor would be a real improvement for the first course. And I recommend using 512K Macs. Now for the bad news. We have continued to have problems with Pascal diskettes becoming unbootable. Between Apple and Think, we have heard the following hypotheses: - there is a bug in Mac Pascal, that causes it to garbage part of the diskette. - something about the copy protection scheme used by Think causes diskettes to be damaged. Apparently both Apple and Think believe this has caused some of our damage. However Think does not believe that it accounts for most of the problems. (Vendors who are considering fancy copy-protection schemes should think about this. I would think very carefully before using any scheme that involves nonstandard formatting or damaged sectors. Think believed that their scheme was safe. So did Apple. Neither do now.) - something about Mac Pascal makes it more sensitive to disk alignment problems. Our evidence supports the 3rd alternative, though they are by no means mutually exclusive. We don't think it is a simple software bug, because the problem seems to occur more often at certain sites, and in a couple of cases we have been able to localize it to a particular machine. When Mac Pascal is used long enough on one of these machines, it becomes unbootable. Unfortunately we are unable to find out which machines are involved, because of the way the diskettes are distributed. The most certain way to solve the problem would be to check alignment on all of our diskettes. I suspect that such a check would show a few machines that are marginal, and that if they are readjusted our problem would disappear. We understand that Think is working on the problem. Apple is very concerned, but they are not concerned enough to come check alignment on our machines. Unfortunately, checking drive alignment seems to be a multi-hour procedure. It has been claimed that Sony has given Apple a diskette that allows alignment to be checked almost instantly, but no one at Apple seems to be able to find this diskette. So the net result is that neither Apple nor Think has been able to do anything about the problem. We are hoping that it will not cause as much of an effect in the Spring semester. Each student will have his own diskette. There will be much less swapping of diskettes, since they will keep their current assignment on their Pascal diskette. We think that this decrease in disk usage will help the problem. Of course it is also possible that instead of 50 diskettes to get damaged we will now have 1000, and our problem will just become that much more unmanagable. -------