urlichs@smurf.ira.uka.de (02/08/90)
In comp.sys.mac.programmer philip@pescadero.stanford.edu writes:
< I find this discussion a bit disturbing. There's a consistant thread
< that says, "Why isn't MPW more like unix?"
<
< My question is, "Why is it so much like unix?"
<
Please, don't. Not another I-like-MPW versus I-like-Think war.
Some people like/need/must use one, and some the other.
There is absolutely no rational basis for saying "X is better than Y", only
"I use X rather than Y because of Z".
Some people like windows with plain text which doesn't do any stupid
reformatting any time you press a semicolon, need to automate fairly complex
projects (take some Pascal for convenience, some Assembler for necessity,
Modula-2 for structure, C because Apple didn't provide Pascal interfaces for
MacTCP ;-) :-(, and the odd Fortran maths code which works but no one
understands any more. Sprinkle liberally with complex resources.
Put together by selecting "Build" from the Apple menu, leaning back, and
finally double-clicking your application.), hand many other reasons why _I_
think that MPW is a very important thing, and much better than any other
development system. (Now just merge Sade into it, fix the damn _GetCatInfo
bug, let it run under A/UX, and some other things I think I need...)
Other people like program editors which show them the correct structure (and
syntax errors) no matter what nonsense they type :-), an environment which
provides for a much simpler and faster edit-compile-run-crash-debug cycle
(_if_ your project structure and the environment are compatible -- with MPW
it's easy, write a skript to _make_ them work together...), and a whole lot of
other reasons why many people prefer integrated development environments of
the ThinkP/ThinkC type.
< LS environments are by far the biggest step forward in my experience.
< MPW doesn't add anything to the state of the art; the LS environments do
< for personal computing programming what the Mac did for the user. What I
< would like to know is how an environment of the LS variety could best be
< extended to provide the functionality of unix, without losing its low
< learning threshold. [...]
This may be correct (I wouldn't know, I don't use Think environments because
of the above reasons). However, you are talking about "How can Think{C,P} be
improved"; don't start talking about "Why is MPW so bad". You don't seem to be
talking about the problem anymore if you do.
Besides, a whole lot of people would take serious exception to the "MPW
doesn't add anything to the state of the art" part of your statement. MPW does
some things worse than Think[CP], some better, and about a whole lot of
features we can argue until the cows come home (or maybe until the Macs gets
protected memory, or until Inside Mac is one useable volume instead of ... --
but I digress) without getting anywhere.
Disclaimer: Whatever for?
--
Matthias Urlichsshap@delrey.sgi.com (Jonathan Shapiro) (02/09/90)
In article <1496@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes: >Please, don't. Not another I-like-MPW versus I-like-Think war. > >Some people like/need/must use one, and some the other. >There is absolutely no rational basis for saying "X is better than Y", only >"I use X rather than Y because of Z". >-- >Matthias Urlichs Here here! I wholeheartedly agree that there isn't much profit to be had in arguing about people's sense of aesthetic in the context of computer interfaces. I am hard pressed to think of a case in which a person's preference in this domain might be considered morally repugnant. On the other hand, and in support of my earlier comments on MPW editing, the fact that people have strongly disagreeing senses of taste and preference is a strong argument in favor of tools build to be as modular as possible. I'm not interested in trying to persuade Apple to right MY favorite editor into MPW. It isn't THEIR favorite editor, so even if they did it it is likely they would get it wrong. I AM trying to get them to tell ME how to build it for myself. Now, a response that says: "We don't have the resources to solve that problem" is acceptable. A response that says "we think your screwed up and we won't consider what you want because it disagrees with our views on the Rightness Of Things" is just stupid. Jon Shapiro
jln@acns.nwu.edu (John Norstad) (02/10/90)
It is not just esthetics or a matter of taste. It is possible to argue rationally about the merits of a traditional Unix-inspired approach as in MPW versus a more Macish direct manipulation approach as in Think C. There are also larger related and very important issues which need to be discussed. These larger issues are in fact central to the notion of how we do computing today and in the future. I use MPW for one reason - I need the power. For example (just one, I promise - there are many, many others), I write MPW tools to build complicated custom resources that are part of Disinfectant. These tools are called by my makefile. I can't do this in Think C. This isn't a matter of taste, it's a matter of fact. I could not have written Disinfectant in Think C (well, I could have, but it would have been much, much harder). Think C is very nice, and MPW could steal lots of ideas from it (especially the debugger), and Think C is just fine for beginners, and like everybody else I wish that MPW were half as fast as Think C, but real programmers use MPW. I think that more research needs to be done into how far one can go with direct manipulation progamming environments and command languages. MPW could certainly use more of this in many areas, and SADE desperately needs it (I find SADE so cumbersome that I still do most of my debugging with MacsBug). But I also think that it's incorrect to claim that graphical direct manipulation approaches will ever be able to completely replace the traditional command language approach. I have some experience with this sort of thing. I wrote the original tile editor in Odesta Helix. That was an attempt to implement a graphical point-and-click direct manipulation interface for building complicated expressions and search criteria in a commercial database program. The basic idea was to let the user use graphical tools to build the parse trees for the expressions. The Helix tile editor is popular in some ignorant quarters, but I think it was a failure, and it's the primary reason I no longer work at Odesta. If I want to add x and y, I much prefer simply typing "x+y". Please don't make me spend several minutes dragging tiles around, dropping icons into them, connecting them together, etc. I have an absurd example I like to show Helix fans - try getting Helix to add 1+1 and display the answer 2 (starting with an empty relation). The amount of window opening and closing and clicking and dragging you have to go through is absolutely ridiculous. This example is a bit unfair to Helix, since the program was not designed to be a calculator, but it does get the point across. Also, although I don't follow the new Helix versions closely, I believe that my friends at Odesta have improved this situation in recent releases. Direct manipulation graphical interfaces are indeed a tremendous advance, and it's what makes the Mac a Mac. The Finder is an almost perfect example of how truly wonderful this can be. But there still some areas (programming languages and environments, operating system command languages, database languages, etc.) where traditional linear languages with their complicated syntaxes and ugly warts are still in many cases the best way to do things. If icons are really so much better than traditional languages in all contexts, why aren't we still using hieroglyhics to communicate? As a former student of mathematical logic, I must in fact insist that formal languages are one of the crowning achievements of our civilization, and they will never be totally replaced by any sort of graphical language. This seems completely obvious to me, and Mac fanatics who automatically attack any and all traditional approches to language issues simply haven't thought the problem through. One of the most important areas of current research in computer science is how one can best integrate these two kinds of languages to get the best of both worlds. Although MPW doesn't yet make enough use of direct manipulation, it is one of the best commercial examples to date of such a successful marriage. This has gone beyond the original MPW vs. Think C discussion. Sorry. I got tired of hacking out C code today, and decided to pontificate about one of my pet peeves. I hope you found it irritating (it was intended to be). Think C and Helix fans should direct their flames to /dev/null. John Norstad Northwestern University jln@acns.nwu.edu
bowman@reed.UUCP (Eric Bowman) (02/10/90)
I whole heartedly agree. Prepare for flames, though. Essentially, to add to what you've said, I feel as though as a mac programmer, one cannot (yet) expect the same user interface niceites in a development system that one expects in a somewhat more pedestrian program. Why is MPW like Unix? Because Unix is a damn powerful OS -- if you take the time to learn how to use it. Apple's intention is obviously power -- not simplicity -- and for this I applaud them. I only wish they would push MPW as an "alternative" to the finder, particularly in the scientific marketplace. I know a number of people who like many things about the Mac but will not use it because they feel too limited with the finder. Personally, I depend frequently on MPW's tool and scripting ability, and I can't imagine the ordeal of performing some of the same tasks I perform regularly in MPW in Think C. Further, I haven't noticed *that* big a difference in speed when headers are compiled (though linking is a little slow). ============================================================================== | The Insidious Uncle BoBo | ------------------------------------------------------------------------------ | "As I see it, my friends can access my private | | members in a public class..." | ============================================================================== | Eric Bowman -> | | ShitNet: bowman@reed.bitnet | | FarFromFreeNet: (503)234-7158 (Like I'll Really Answer) | | Disclaimer: "If my employer ever found out my opinions, well..." | /=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=
drc@claris.com (Dennis Cohen) (02/11/90)
This speed of turnaround is a little misleading, anyway. While I don't dispute that the Symantec compilers are much faster in the turnaround cycle when you are debugging something and the changes are few, I find the MPW compilers to be faster when I am creating new code. The simple reason for that is that with MPW compilers I get to see all my errors at one time and can do a mass edit to fix them, rather than having to go through multiple abortive compiles, fixing errors and typos one at a time. Isn't this just another example of differing priorities? I still maintain that anyone who is serious about developing software on the Mac should have BOTH the MPW and THINK environments. Dennis Cohen Claris Corp. **************************************************** Disclaimer: Any opinions expressed above are _MINE_! ****************************************************
bmwrkshp@watserv1.waterloo.edu ( Wrkshp Id - Sys Design ) (02/11/90)
In article <14112@reed.UUCP> bowman@reed.UUCP (Eric Bowman) writes: >I whole heartedly agree. Prepare for flames, though. > [Stuff deleted about power of Unix and MPW] > >Personally, I depend frequently on MPW's tool and scripting ability, and >I can't imagine the ordeal of performing some of the same tasks I perform >regularly in MPW in Think C. Me, too. > >Further, I haven't noticed *that* big a difference in speed when headers >are compiled (though linking is a little slow). I have. I've had modules that used to take a minute to compile, end up taking only 20 seconds to compile. With MPW that's a big difference. But I'm sure THINK C is still an order of magnitude faster. Don't know what that linker is doing. Sure takes its own sweet time even on Mac II's. I would probably use MPW 99% of the time if it weren't for the fact that the C compiler is broken. Even the updated C compiler included with the C++ package still has bugs. Real world case I can talk about: I tried compiling Nethack 3 under MPW C. The compiler couldn't even get past the header files (tested with both original 3.0 and 3.1 beta C compilers). But for text file manipulation on the Mac, you can't do much better than MPW. Johnny Lee jlee4@orchid.waterloo.edu bmwrkshp@watserv1.waterloo.edu
jln@acns.nwu.edu (John Norstad) (02/11/90)
In article <1046@watserv1.waterloo.edu> bmwrkshp@watserv1.waterloo.edu ( Wrkshp Id - Sys Design ) writes: > But I'm sure THINK C is still an order of magnitude > faster. Don't know what that linker is doing. Sure takes its own > sweet time even on Mac II's. As I understand it, one of the reasons is that MPW's linker is much smarter. For example, it lets you direct individual routines within a single module to different segments, and it eliminates dead code. I'm not sure about all this, though. > I would probably use MPW 99% of the time if it weren't for the fact > that the C compiler is broken. Even the updated C compiler > included with the C++ package still has bugs. I've heard this from other places too (e.g., the guys at Wolfram). But I'm up to 16,000 lines of pretty hairy C code in Disinfectant now, and I've yet to encounter a single compiler bug. Maybe because I'm a reformed Pascal fanatic, I don't write as ugly code as the rest of you guys :-) John Norstad Northwestern University jln@acns.nwu.edu
bowman@reed.UUCP (Eric Bowman) (02/11/90)
In response to your questions about "what the linker does," you might check out "Creating Programs with MPW" in the Winter 1990 issue of MacTech Quarterly. It also describes techniques for up to 40% speed improvements. Indeed, the MPW linker IS smarter, and in general accord with the MPW philosophy as I see it, if you don't learn the nuts and bolts, you're gonna get burned (even flamed). If there's interest or people can't find the fledgling MacTech Quarterly (hell, I've WRITTEN for them, and I have trouble finding it) (I can't afford a subscription), I could post a summary, or even an unauthorized copy (maybe not...I might like to write for them again). ============================================================================== | The Insidious Uncle BoBo | ------------------------------------------------------------------------------ | "As I see it, my friends can access my private | | members in a public class..." | ============================================================================== | Eric Bowman -> | | ShitNet: bowman@reed.bitnet | | FarFromFreeNet: (503)234-7158 (Like I'll Really Answer) | | Disclaimer: "If my employer ever found out my opinions, well..." | /=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=
murat@farcomp.UUCP (Murat Konar) (02/12/90)
My feeling on the MPW vs. THINK controversy is this: Saying MPW is powerful is like saying that somone has a great personality. :) Seriously, MPW is powerful, but it really gets in the way when I'm exploring better ways of doing things. The turnaround in MPW is so slow enough that it frequently discourages exploration. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
mxmora@unix.SRI.COM (Matt Mora) (02/13/90)
In article <3689@accuvax.nwu.edu> jln@acns.nwu.edu (John Norstad) writes: > >This has gone beyond the original MPW vs. Think C discussion. Sorry. I >got tired of hacking out C code today, and decided to pontificate about >one of my pet peeves. I hope you found it irritating (it was intended to >be). Think C and Helix fans should direct their flames to /dev/null. > >John Norstad >Northwestern University >jln@acns.nwu.edu HEY! What the heck are you doing wasting your time reading and posting to the Net. Get Back to Work on 2.0 :-) Also, A question about WDEF virus. If you stick an infected disk while disinfectant is running. Will the virus Spread. What exactly does mountvol do. Does it read the desktop File or does only the finder do that. I was wondering if a user brings a disk to my Mac plus (which doesn't have enough memory to run a bunch of detection inits) and I'm in disinfectant, will the virus spread before disinfectant can scan the Disk? Just wondering... -- ___________________________________________________________ Matthew Mora SRI International mxmora@unix.sri.com ___________________________________________________________
d88-jwa@nada.kth.se (Jon Watte) (02/13/90)
In article <3718@accuvax.nwu.edu> jln@acns.nwu.edu (John Norstad) writes: >As I understand it, one of the reasons is that MPW's linker is much >smarter. For example, it lets you direct individual routines within a >single module to different segments, and it eliminates dead code. I'm not >sure about all this, though. Xcuse me ? One of the major gripes about the MPW linker last year was "Why does it include so much dead code ? It should have a "smart link" as THINK C does" ... Maybe that has changed, as so many other things. h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
tim@hoptoad.uucp (Tim Maroney) (02/15/90)
In article <3718@accuvax.nwu.edu> jln@acns.nwu.edu (John Norstad) writes: >>As I understand it, one of the reasons is that MPW's linker is much >>smarter. For example, it lets you direct individual routines within a >>single module to different segments, and it eliminates dead code. I'm not >>sure about all this, though. In article <2931@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >Xcuse me ? One of the major gripes about the MPW linker last year was >"Why does it include so much dead code ? It should have a "smart link" >as THINK C does" ... > >Maybe that has changed, as so many other things. I've been using MPW since the beta test of version 1.0, and I'm pretty sure it's always deleted dead routines. In any case, it definitely does so now; I recently set up a test case to check. Sure enough, the unreferenced routines from my .c.o files didn't appear in the linked output. On the other hand, THINK C does *not* delete much dead code, at least not in 3.0. It includes entire source files as modules. It will only leave out routines in some libraries, and entire source code files; see the manual, page 68 for 3.0. The MPW Linker will (and I'm pretty sure always has) leave out individual unreferenced routines from source files that contain some referenced routines. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"