Dialog Box

By Neil Ticktin, Editor-in-Chief/Publisher

Dylan Lives

Jim Gagnon [Dialog Box, September] may have many reasons for not using Dylan. However, “...unreasonable to ... expect success from a proprietary language...” shouldn’t be one of them. [The fact that it isn’t out yet in ready-for-prime-time form is a reason.]

The language spec is in the public domain. The keepers are at CMU...take a look at

http://legend.gwydion.cs.cmu.edu:8001/dylan/

The name Dylan remains with Apple for the purpose of controlling its usage to conforming implementations (aging entertainers who themselves appropriated the name notwithstanding). Apple may someday have a Dylan implementation available for Mac developers. Meanwhile Dylan-like things are “all over” on other platforms (and Macintosh). They aren’t called Dylan because they aren’t yet (as in “Mindy”...Mindy Is Not Dylan Yet).

- John W. Baxter, Port Ludlow, WA

CGIs in C - Some Tweaks

Just a few notes on the article “Writing CGI Applications in C” in the September, 1995 issue of MacTech.

POST arguments can be up to 32k in size (not 24 as indicated on pg. 36). The username and password are both limited to 32 bytes.

You state on pg. 41 that “you can not allocate or release memory within a thread context.” This only applies to pre-emptive threads, which were only implemented in the 68K Thread Manager. Cooperative threads can do what the main application thread can do.

I haven’t looked at the responder code recently, but it used to be missing the call to MaxApplZone() during startup. That becomes quite necessary if the application is going to be dealing with large chunks of data.

Thanks for writing the article - I got some useful ideas from reading it!

- Grant Neufeld

What Ever Happened to FORTRAN?

First, let me laud your publishing of articles on Prograph CPX. This certainly is the way of the future of programming on the Mac. Indeed it is a natural extension of the Mac’s iconic interface. I’m also delighted to find that there are two books in the offing concerning the programming of CPX. My background has been in the procedural languages, and I need some extra help in making the culture change to OOP.

Second, let me moan. In the past MacTutor and then MacTech gave coverage to the language I use most of the time - FORTRAN (LS FORTRAN). But the past year or so has seen a withering and then total absence of coverage of this language - first Jorg’s Folder, then Jorg, then FORTRANs from the Mail Order. I know it isn’t the most modern language, but there is a considerable opus of large scientific/engineering codes written in FORTRAN which have been debugged over decades. Those who use these codes are first of all rather intimidated by the idea of converting them to other more modern languages due to their size and second do not relish the large amount of time it will take to make the new codes as reliable as the existing FORTRAN codes. So, I don’t think that FORTRAN is dead by any means and it is disappointing not to have Jorg’s Folder any more, especially with the evolution of the Power Mac versions of FORTRAN.

- Stu Cook, Mt St Hilaire, Quebec

But, You Missed The Point

Thank you for your comments at the end of my letter complaining about Symantec’s C++ 8.0, but I think you missed the point of my last comment.

If it would be so hard to write a PowerPC version of THINK Pascal, then how about a compiler that will accept THINK Pascal source code and produce native PowerPC object code. We programmers could do our program development using the present THINK Pascal development environment in the 680x0 emulator.

The THINK Pascal 4.0.2 compiler in the emulator is so much faster than any native C or C++ compiler that there is no real speed penalty for using the present compiler. After we have a working 680x0 program, we can feed the source code to the PowerPC compiler to produce the final code.

Since we will only be using this compiler a few times per program development cycle, it can be a slow dog like the Symantec C and C++ compilers. It doesn’t have to have an editor and debugger like a real development environment. It just has to reliably compile previously proven code that was developed using the present excellent THINK Pascal development environment.

- Fred Johnson, Knoxville, Illinois

In addition, there is a version of the Universal Headers modified to work with THINK Pascal that Symantec will make available by the end of October, 1995. These files will be available on the next SDA CD and probably online. Check the MacTech web site (http://www.mactech.com/special.html) or the Symantec site for more information - Ed. nst]

[Many thanks to:

0 Daniel Lidoff, Atascadero, California

Brain Damaged Languages?

Fred Johnson hit the nail on the head with his letter, printed in the Dialog Box section of the March issue of MacTech. He praised the editor and linker of THINK Pascal, as compared to those of Symantec C++. But he did not go far enough [to fully expose the languages behind the environments].

I, like Johnson, am somewhat of a Mac hacker. I have programmed the Mac professionally, but I consider myself to be an engineer who programs rather than a programmer. I have programmed using THINK Pascal, THINK C, and Microsoft QuickBASIC.

The BEST feature about THINK Pascal is its debugger, LightsBug. It is superb and clearly better than anything else I have used. (Why hasn’t Symantec made the C/C++ debugger more like LightsBug?) I can examine all global and local variables immediately, without having to first select them for display as in the THINK C debugger. I can see the chain of calling routines, examine register variables, look through the heap, modify variables, and set watch points. And I can also examine and set memory directly.

I also share Johnson’s opinion of C and C++ (or rather, Symantec’s “C with objects”, which is as close as I have gotten to C++.) Both are a mess. For example, what kind of brain-dead language knows the type of a variable in a “printf()” function call, yet makes the programmer specify it again with a formatting control code? I end up debugging my “printf()” function calls. (And that is just one example. I could go on and on.)

I made two serious efforts to learn “C with objects” but gave up in frustration both times. Object Pascal was a breeze after wrestling with C. (Even the manuals bear this out: the “Object Pascal” chapter is 14 pages for version 4 of Pascal; the “Using Objects in Think C” chapter is 37 pages for version 5 of C.)

The Object Pascal implementation of object-oriented programming is simple and elegant. With the use of just 3 additional keywords (“object”, “inherited”, and “override”) and one function (“member()”), I can program in an OOP language. Although I can’t speak from experience with C++, if my experience with “C with objects” is any indication, C++ is a mess.

The world seems to have run after C, but after using both, I don’t know why. C is best described as a cryptic high-level assembler. Pascal is a well-designed high-level language. C’mon Symantec, support Pascal.

- Steve Ross, steve_ross@smtp.svl.trw.com

Criticism of Programming Style

I just received the winning solution to the programmers problem. It uses several goto statements and is not object oriented. As the only programming journal for the Mac it would be nice if you’d adopt a more “progressive” approach to teaching programming. Old notions of “efficiency” are passe.

- Don Winston