dwh@rayssdb.ray.com (David W. Humphrey) (05/14/88)
Can someone please offer an experienced Mac user and a budding Mac programmer some sound advice as to how to get started in Mac pro- gramming? I have a 512Ke, but am considering selling it and getting an SE or a II. By what I've read, I think MPW seems like the best thing to buy, but I see that a lot of people use Lightspeed C. Also, what documentation and independently written texts do you recommend? I have vols. I & II of _Inside Mac_ and plan to by the rest. I just finished reading _MPW and Assembly Language Programming_ by Scott Kronick. The book is great, but I feel like there should be a vol. 2 to go along with it - it seems incomplete. Many thanks in anticipation! David W. Humphrey
dorourke@polyslo.UUCP (David M. O'Rourke) (05/14/88)
In article <1911@rayssdb.ray.com> dwh@rayssdb.ray.com (David W. Humphrey) writes: > Can someone please offer an experienced Mac user and a budding Mac > programmer some sound advice as to how to get started in Mac pro- > gramming? I have a 512Ke, but am considering selling it and getting > an SE or a II. By what I've read, I think MPW seems like the best > thing to buy, but I see that a lot of people use Lightspeed C. MPW, Yeah!!!! As far a the 512Ke goes, dump it! You need lots of memory, and lots of disk! If you can afford it go ahead and bite the bullet and get a II. Books: Inside Mac All Volumes. Macintosh Programing Secrets & How to Write Macintosh Software both by Scott Knaster. Also Programming with Macintosh Programmer's Workshop by Joel West Macintosh Revealed might also be useful. Subscription to MacTutor is nice. Also go out and buy lots of Jolt, Coke, Pepsi, or Mountain Dew, you have some late nights coming up. But it's worth it! David M. O'Rourke +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | dorourke@polyslo | Disclaimer: All opinions in this message are mine, but | | | if you like them they can be yours too. | | | Besides I'm just a student so what do I | | | know! | |-----------------------------------------------------------------------------| | When you have to place a disclaimer in your mail you know it's a sign | | that there are TOO many Lawyer's. | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
guido@cwi.nl (Guido van Rossum) (05/17/88)
In article <2586@polyslo.UUCP> dorourke@polyslo.UUCP (David O'Rourke) writes: >In article <1911@rayssdb.ray.com> dwh@rayssdb.ray.com (David W. Humphrey) writes: >> Can someone please offer an experienced Mac user and a budding Mac >> programmer some sound advice as to how to get started in Mac pro- >> gramming? I have a 512Ke, but am considering selling it and getting >> an SE or a II. By what I've read, I think MPW seems like the best >> thing to buy, but I see that a lot of people use Lightspeed C. > > MPW, Yeah!!!! I'd like to make a comparison between LightspeedC (LSC) and MPW. I have used MPW much longer than LSC, and am convinced that it generates better code, has a much more intelligent linker, and a much more powerful programming environment. Especially if you're used to Unix programming, MPW makes the transition easy (you can write Makefiles and shell scripts, albeit with lots of minor changes in the notation). It is also particularly easy to port all sorts of tools that were written for use under Unix. Often no changes are needed. For Mac hackers, MPW's resource compiler and decompiler (rez/derez) are superior to what LSC offers (I think 2.11 came with a prehistoric version of RMaker). However, LSC also has its advantages. The compiler and linker are so much faster than MPW's that program development time shrinks enormously, especially if you're working on a small machine (1 Megabyte, 2 800K floppies, or even a 20Meg HD). In general the exclusion of certain features and deliberate lack in flexibility have made it a remarkably fast system; you can enter LSC, run your application and return to LSC in the time MPW needs to execute the startup file... I plan to do my future code development under LSC, while generating production versions with MPW. Because of the better optimizer (automatic register allocation, for one!) and smarter linker (removes unused functions, not just unused files), MPW applications are easily 20% smaller than those generated with LSC. Unfortunately you have to make a conscious decision to use both MPW and LSC with the same sources. There are many differences, and porting a program written for one to the other may cause you many headaches. Some language differences I've observed (in LSC 2.11, vs. MPW 2.02): int==short in LSC, int==long in MPW names of standard headers differ, e.g. <Windows.h> in MPW, <WindowMgr.h> in LSC toolbox routines require Pascal strings in LSC, C strings in MPW Points passed by value to toolbox in LSC, by address in MPW MPW defines '\n' == '\r'; in LSC, stdio translates between '\n' and '\r' LSC's library contains more unix emulation functions LSC does strict type checks on pointer assignments, MPW doesn't care LSC doesn't allow "benign" redefinition of preprocessor symbols LSC needs glue to call pascal functions given as function pointers LSC doesn't automatically dereference function pointers in call contexts LSC preprocessor doesn't define __LINE__ and __FILE__ macros LSC has no equivalents of Unix -D and -I compiler options LSC has CtoPstr and PtoCstr, where MPW has c2pstr and p2cstr in LSC, the difference between two pointers is a long! It is possible to program around all of these using a few simple macros; however, if you didn't plan this you'll have a hard time, especially in finding all the incompatible toolbox calls. As far as I know, neither system has much debugging support beyonde generating symbols for Macsbug. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
dorourke@polyslo.UUCP (David M. O'Rourke) (05/19/88)
In article <321@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: >I'd like to make a comparison between LightspeedC (LSC) and MPW. Continues on with an EXCELLENT comparison of LSC vs. MPW. One of the best I've seen, listed some things I've never seen before. >As far as I know, neither system has much debugging support beyonde >generating symbols for Macsbug. I think one of the RUMORED features of MPW 3.0 will be souce level debugging. The one thing Mr. van Rossum leaves out is the fact that MPW supports more than just C, although C is the choice of many programmers there are other languages, and MPW supports most of them. Also I've found MPW to be quite useable on a 2 meg machine with a 20meg harddisk. And you can't deny the power of it's Unix style shell and the ability to add tools to the shell just like in Unix. Although LSC is fast, MPW is complete. I have also heard rumors that many of the Macintosh compiler companies are planning versions of there compilers to run under MPW, so you not only have a choice of languages you *MIGHT* soon have a choice of who's compiler you can use. This has already happend in the Modula Market, so why not Pascal, C, ect.. Both enviroments are very good, but I've gotten used to MPW and now I find it difficult to use anything else, what no shell scripts? Where are my shell variables, where are the user defined menus, no make facility, my god are we working in the stone ages here? David M. O'Rourke +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | dorourke@polyslo | Disclaimer: All opinions in this message are mine, but | | | if you like them they can be yours too. | | | Besides I'm just a student so what do I | | | know! | |-----------------------------------------------------------------------------| | When you have to place a disclaimer in your mail you know it's a sign | | that there are TOO many Lawyer's. | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
dtw@f.gp.cs.cmu.edu (Duane Williams) (05/20/88)
In <2729@polyslo.UUCP>, David M. O'Rourke writes (admittedly out of context):
> ...no make facility, my god are we working in the stone ages here?
In LSC you don't need a Make facility. The primary function of Make is
automatic. And it gets updated automatically as you modify your program.
And there is no perceptible time spent processing a Makefile.
You mean I have to somehow write a Make file in MPW? And wait while it is
rewritten each time I want to compile (or else do it by hand)? And wait
some more while it is interpreted each time I want to compile? My god, are
we working in the stone ages here?
Duane Williams
--
uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw
arpa: dtw@cs.cmu.edudorourke@polyslo.UUCP (05/20/88)
In article <1724@pt.cs.cmu.edu> dtw@f.gp.cs.cmu.edu (Duane Williams) writes: >In LSC you don't need a Make facility. The primary function of Make is >automatic. And it gets updated automatically as you modify your program. >And there is no perceptible time spent processing a Makefile. > >You mean I have to somehow write a Make file in MPW? And wait while it is >rewritten each time I want to compile (or else do it by hand)? And wait >some more while it is interpreted each time I want to compile? My god, are >we working in the stone ages here? Good One! But make files are more useful in a general sense of programming. They can also be used to maintain different versions of non-code type stuff, as well as interface specifications. When working in a multi-person enviroment LSC method don't work quite as well. When you have documentation, interface specifications, rez source code, and different modules on different machines in the network the only way to do it is with a make file that goes around to the different machines to check what's the latest version, also since the make can execute "any" MPW command as part of the make's execution it is much more useful than simply finding out what needs to be compiled. For example my make file goes out to the network, finds the work that my partner is working on and copies it to my workstation. Using LSC this would create a problem, since I would have to do all this in the finder first. I want the computer to figure out what I need to do my work, and since my compilation changes the modules slightly I need to leave a copy undisturbed on the original machine. And since when is being interpreted being in the stone ages? There are some very useful points to interpreted languages, can you say symbolic debugging? Also MPW is better in Multi-person enviroment since it has a varity of languages availible to the shell it allow a multi-person enviroment to choose the language that they would be most productive in, and once we have the interfaces specified I don't really have to know, or care what language the module that I want to use is written in. So once again I submit to you are we still working in the stone ages. LSC is wonderful, but it's starts to fall apart when you scale the development beyond one person, and start moving files off your workstation to remote servers, in fact we even store some code on a local mini-computer, and the make file is able to log on, retrieve the file, compile it, and distribute it through out our network so the everybody recieves a copy. Learn to use make files before you object to their purpose! -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
pem@cadnetix.COM (Paul Meyer) (05/24/88)
[]
As someone who is very familiar with UNIX Makefiles, and
maintains a system that plays a lot of network file games such as you
describe AT WORK, I find that the simplicity and speed of LSC is
refreshing when I go to hack on my Mac AT HOME.
As I interpret the thrust of the original question, 0% of your
comments on the superiority of MPW makefiles over LSC's automatic
system are applicable. At home (where presumably someone who is
getting started on the Mac will be), I don't have NFS. I don't have a
Sun4 to farm time-expensive work out to. I don't have 2 close
co-workers and a building full of library consumers to interface with.
What I do have is one machine that I don't like to wait for. LSC
minimizes my waiting, and that's what I want. A decent optimization
capability for final application build would be nice, but for normal
use LSC is exactly what I want, only less so (give me 0 compile time
as well as 0 link time, without slowing editing, and give me this
NOW!) but I will accept real-world constraints.
Now, If I were developing Mac software here at work, I'd still
be unsatisfied with MPW because the Mac OS is unlikely to ever support
NFS and rpc. I'd be wanting to use A/UX.
Nobody has yet convinced me I'd be better off paying twice as
much for MPW than for LSC. I don't consider this a religious issue,
and if I had the time and inclination to write a really big
application set where makefiles and object files would really help I
might get MPW, but for "the rest of the rest of us" I think LSC is
better.
Paul Meyer pem@cadnetix.COM
Cadnetix Corp.
5775 Central Ave. {uunet,boulder}!cadnetix!pem
Boulder, CO 80301 (303)444-8075x244mce@tc.fluke.COM (Brian McElhinney) (05/24/88)
In article <1724@pt.cs.cmu.edu> you write: >You mean I have to somehow write a Make file in MPW? While I agree that LSC is better for getting started in Mac programming, surely you had to "somehow" learn the LSC equivalent (projects). Makefiles are easy enough to learn, at least for programmers. It all depends on what you want to do. For example, try getting LSC to run Bison on your .y files and then compiling the resulting .c file. LSC is a nice environment, but only if you are working alone, and only if you are working in C alone. Would you fault someone for using a power saw for their work when you find a hand saw adequate for your own? MPW has it's own problems, but Makefiles are not one of them. >My god, are we working in the stone ages here? Actually, I think the dark ages, in both cases. The complexity of software is just not manageable; the real power tools have yet to be invented. Brian McElhinney mce@tc.fluke.com
dorourke@polyslo.UUCP (David O'Rourke) (05/26/88)
In article <2698@cadnetix.COM> pem@cadnetix.COM (Paul Meyer) writes: > Now, If I were developing Mac software here at work, I'd still >be unsatisfied with MPW because the Mac OS is unlikely to ever support >NFS and rpc. I'd be wanting to use A/UX. By rpc, do you mean Remote Procedure Calls. Because I just happened to work on a project that does just that for the Macintosh. Allowing a MainFrame programmer to Make presentation calls to the Macintosh. There is support for that, although not as standard as Unix is {I think}. AppleTalk has a variety of protocols which would be appropriate for RPC between machines on the network. But the Mac already does support NFS. Tops will mount NFS volumes in a Macintosh enviroment and make them availible through standard OS calls on the Mac. In addtion Appletalk also has it's own rather standard and powerful Network file protocol. In addition as someone on the net metioned LSC's make feature is nice, until you decide to do something else. The speed is nice, but I want services for my development enviroment. I used to feel the same way about MPW vs. the faster enviroments. But when I started using MPW and found the power of the enviroment, all others dropped our of existance. I also enjoy being able to choose which language would best solve the problem. And letting the linker figure out how to bring it all together. >application set where makefiles and object files would really help I >might get MPW, but for "the rest of the rest of us" I think LSC is >better. Yes LSC is better for the rest of us. But if you really want simply try an interpreted language, or even HyperCard. Learning the program the Mac is no cheap affair. By the time you buy the first three volumns the cost of a development system really doesn't matter. Face it programming the Mac isn't cheap. So if you're going to spend the money, might as well get something you can grow into, rather than out of. -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
dorner@uxg.cso.uiuc.edu (05/31/88)
>Yes, yes, yes: high level languages are great, but in the end, IT ALL >COMES DOWN TO ASSEMBLY LANGUAGE. My statement was to remind people that >knowing some assembly language is both helpful and essential in a good >computer scientist's toolkit of skills. I have developed major projects on machines whose assembly languages are TOTALLY unknown to me. This caused no problems because I had compilers, source-level debuggers and operating systems I could trust. Unfortunately, Mac compilers are suspect, source-level debuggers are hard to find, and the operating system is quirky at best. I have come to the conclusion that a reading knowledge of 68000 assembler is necessary for Mac programmers. I contest the assertion that it is necessary for any good computer scientist. >Dan Allen ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: ihnp4!uiucuxc!dorner IfUMust: (217) 333-3339