Nov 95 Dialog Box
- Jan 95 Dialog Box
- Feb 95 Dialog Box
- Mar 95 Dialog Box
- Apr 95 Dialog Box
- May 95 Dialog Box
- Jun 95 Dialog Box
- Jul 95 Dialog Box
- Aug 95 Dialog Box
- CGIs in C
- Sep 95 Dialog Box
Volume Number: 11
Issue Number: 11
Column Tag: Dialog Box
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
According to John O’Fallon, 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 doesn’t 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
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
[Stu: Our biggest reason for not running FORTRAN articles is that we’ve not seen
anything worthy of printing. While FORTRAN articles shouldn’t get the same volume of
coverage that C++ or even Pascal should (since there are more users of those
languages), it does deserve coverage. We’re 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 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
[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
JTenor11@aol.com
S.A. Klein, Madison, Wisconsin
Anthony Panos
Luman Wing
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 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