Nov 95 Dialog Box
|Column Tag:||Dialog Box
By Neil Ticktin, Editor-in-Chief/Publisher
Jim Gagnon [Dialog Box, September] may have many reasons for not using Dylan. However, ...unreasonable to ... expect success from a proprietary language... shouldnt be one of them. [The fact that it isnt 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
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 arent called Dylan because they arent 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 havent 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
According to John OFallon, the point about using memory within a thread context is true, but remeber that a call to MaxApplZone is required before threads allocate memory. See MacTech, November 1994, P. 68 for more details. There are many things that Responder doesnt do, mainly because Responder is a simplified application to teach CGI programming. - Ed. nst
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 Macs iconic interface. Im 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 Jorgs Folder, then Jorg, then FORTRANs from the Mail Order. I know it isnt 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 dont think that FORTRAN is dead by any means and it is disappointing not to have Jorgs Folder any more, especially with the evolution of the Power Mac versions of FORTRAN.
- Stu Cook, Mt St Hilaire, Quebec
[Stu: Our biggest reason for not running FORTRAN articles is that weve not seen anything worthy of printing. While FORTRAN articles shouldnt get the same volume of coverage that C++ or even Pascal should (since there are more users of those languages), it does deserve coverage. Were open to publishing FORTRAN articles - anyone interested in writing one? - Ed. nst]
But, You Missed The Point
Thank you for your comments at the end of my letter complaining about Symantecs 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 doesnt 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
[Fred, your prayers have (or will) be answered shortly. Will Iverson at Symantec tells us that Symantec has come to an agreement with Language Systems Corp. LS will provide an Object Pascal compiler that will drop into the Symantec Project Manager environment that should compile THINK Pascal 4.0.2 source code. For more information, contact Language Systems can be reached at http://www.langsys.com/langsys or 800-252-6479.
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
S.A. Klein, Madison, Wisconsin
Chris F. Riley, Miami, Florida
who also expressed similar opinions about wanting to bring THINK Pascal to Power Macintosh. - Ed. nst]
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 hasnt 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 Johnsons opinion of C and C++ (or rather, Symantecs 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 cant 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 dont know why. C is best described as a cryptic high-level assembler. Pascal is a well-designed high-level language. Cmon Symantec, support Pascal.
- Steve Ross, firstname.lastname@example.org
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 youd adopt a more progressive approach to teaching programming. Old notions of efficiency are passe.
- Don Winston