Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!princeton!udel!rochester!PT.CS.CMU.EDU!andrew.cmu.edu!rs4u+ From: rs4u+@andrew.cmu.edu.UUCP Newsgroups: comp.sys.mac Subject: Re: LightSpeed C gripes Message-ID: <4Vw6hny00WAK5w00JJ@andrew.cmu.edu> Date: 17 Jan 88 07:51:15 GMT Organization: Carnegie Mellon University Lines: 166 Posted: Sun Jan 17 02:51:15 1988 In-Reply-To: <10928@duke.cs.duke.edu> This is in response to your varied and miscellaneous gripes about LightspeedC. Before I begin responding to your specific complaints, first allow me to say that I am a user of LightspeedC (and to a much greater extent its sister product Lightspeed Pascal). It is not a perfect application. It comes damn close, but it's not perfect. But I have *never* seen a perfect application, on *any* computer. You say that it "is one of the poorest products [you] have ever seen for a computer." But by comparison to what? The least you can do is tell us what you're used to. Or what you've found to be better. One caveat: A main reason that I am defending LightspeedC is because I like the program. It is a fact (know my most of the readers of this news group) that I worked for THINK Technologies (the producers of LightspeedC). But I am answering this message as a satisfied owner and user of LightspeedC. Whether the reader believes this or not is of little consequence to me. I simply am relating the facts as they are. Now, in response to your numbered points: 1a) "The documentation is awful." The function of a program's documentation is to tell you how to use the program. For a programming environment, you need to know the basics: how to use the editor, how to use the compiler, how to use the linker, and so forth. I've been a user of LightspeedC since I first took up the C language, and I found the manual well geared towards someone who didn't know how to use the package. The manual does assume a certain basic amount of Macintosh knowledge, and a certain amount of C knowledge, but this is stated in the manual's introduction. Also, it's worth noting that Macintosh documentation is more sparse than PC (or other) documentation, because there's less to learn. An important part of using any programming language system is knowing the language you're trying to program in. 1b) "The library reference is incomplete, and doesn't say little things like which headers & libraries you must include." Horsefeathers. Chapter 13 of the User's Guide gives (on each page) a library function, along with a prototype of the function's declaration, and #include directives for the necessary include files. 2) "The editor sucks and you're stuck with it." I may be just a poor stupid Macintosh user, but I've found the editor to be completely serviceable. There's no limit to the size of a source file I can edit, and the editor is uniformly fast no matter huge the source file is. I have used the editor to massage a 350K BinHex file, with no problems. The search/replace is fast and reliable, and has pattern-matching and multi-file search if I want to use it. I can also use the Option, Shift, and Command keys if I want to pull tricks with long-distance selections and position jumps. 2a) "The editor is so bad it isn't worth mentioning." It's no worse than any other Macintosh-based text editor. "Good" or "Bad" is a matter of personal taste, at any rate. 3) "The system is extremely limited by memory constraints." At best, this is wrong. You can run programs of unlimited size on your computer, be it Mac 128K, 512K, Plus, SE, or II. The segmentation is easy and painless. It is true that the Macintosh imposes a global-space limitation of 32K, but this is due to the A5-relative referencing of globals. To work around the limit, use pointers instead of large static arrays. This and other methods of getting around the limit have been discussed time and time again in this newsgroup. The 32K limitation can't be so awful -- many popular (and large!) programs have been written using LightspeedC; for example, Aldus PageMaker, Adobe Illustrator, Quark XPress, and LightspeedC itself. 4) "The system doesn't really handle Multi-Finder." It doesn't? If you get an "Out of Memory" message, the next step is to see how to increase the memory available to LightspeedC. If you only have one megabyte of memory, you're screwed, but the LightspeedC update notes for 2.13 do note that you'll need two megabytes to run all but the smallest programs. You can increase the allocation by choosing "Get Info" in the Finder, and bumping up LightspeedC's application memory size to a larger size, if you can afford the space. On a two-megabyte machine I use either 640 or 768K, depending on what else I want to have resident. 5) "The system doesn't support the 68881." This will change. 6) "I'm not sure how robust the compiler is." I'm not a C expert, so I can't comment on your specific example. But I will say this: in every case I've seen where the compiler has flagged an error, and there's been doubt as to the robustness of the compiler, the compiler has been right, and I've been wrong. 7) "The error messages are useless." They're error messages. They give a description of the error. What else can you ask for? I've always found them to be helpful. Maybe a bit terse at times, but if I get confused, there's an appendix in the manual that gives a listing or each message, followed by a fairly detailed description of the possible causes of that error. I've never been misled by a LightspeedC error message. 7a) "The compiler stops on the first error." I much prefer this to a cascade of error messages. I've hated cascades since the day a Unix C compiler gave me 140 messages, all stemming from the fact that I'd misspelled the name of a global and used the correctly spelled name in the references to it. All I need is the first error message to clue me in to the problem. 7b) "It gives this obnoxious box to click in." What's the alternative? Insert the messages into the source file? Write the messages into a separate file? The first clutters my source file, the second takes longer to deal with than simply reading the message, then pressing "Return" or "Enter" to dismiss the box. 7c) "The messages aren't too useful." You already said this. 7d) "It doesn't show you exactly where the error is." The cursor gets placed at the beginning of the offending line, and between the error message, the cursor placement, the source context, and a little parenthesis-matching, I have no problem finding the error. I do not expect the C compiler to bottle-feed me. C doesn't work that way. "Admittedly, I don't know the alternatives." You should try them. After you have tried them, you may find that LightspeedC is infinitely easier and quicker to work with. "Also, what I've been trying to do is to take a UNIX/MSDOS program (GnuChess) and get it to run on the Macintosh. This is probably not what lightspeed was meant for. " This is correct. LightspeedC is not a Unix C compiler that happens to be running on the Macintosh; it is a C compiler that's useful for writing Macintosh applications, drivers, and desk accessories in C. The Unix libraries are there, but they're simplistic, and shouldn't be used for writing Unix-style applications to run on the Macintosh. The Macintosh isn't a Unix machine, and no amount of library support is going to make it one. "I don't at all regret making the jump into the 20th century and buying a Mac ][. I do regret wasting the $95 bucks on LightSpeed C." As a Macintosh enthusast I admire your choice of computer. As an enthusiastic Lightspeed Pascal and LightspeedC user, I admire your choice of language environment. As I said previously, after trying the alternatives, you may find LightspeedC to be your C compiler of choice on the Macintosh. "Michael Lee Gleicher" "Duke University" --Rich =================================================================== Richard Siegel THINK Technologies, QA Technician (on leave) Carnegie-Mellon University, Confused Physics Major Arpa: rs4u@andrew.cmu.edu UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u ==================================================================