ari@eleazar.dartmouth.edu (Ari Halberstadt) (08/04/89)
>In article <14780@dartvax.Dartmouth.EDU>, ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: >> Now, for the flame part. The apple interface is truly lousy for certain >> things. > >Could we please have a little more scientific method here? I'm getting >sick and tired of unsubstantiated opinions. Ok, ok. I can explain, but first let me note: I was tired when I sent the message out, and about 2 minutes later realized parts of it were somewhat inapropriate. Sadly, my system could not locate 'inews' in order to cancel my posting. I have tried contacting my operator, but haven't received a reply. So, the message went out in a not-quite-finished state. Still, the claims I made are valid, and I can substantiate them. Unfortunately, I can not bring to bear scientific studies of the effectiveness of one interface over the other. I'm sure some are available, but I'm really talking about my perspective as a computer programmer. First, the apple interface is very nice for a number of reasons. It is simple, it's consistent from application to application, and it handles some tasks adequately. In addition, I was truly impressed when I first started learning the Mac OS from Inside Macintosh. Apple did a very good job documenting the 1000 or so ToolBox calls, except for the file manager in vol IV...very confusing chapter. This last chapter is really more complicated than it need be: UNIX, a far more involved system than the mac, with many more devices and directories, manages to use just a small number of commands to do file IO, and even directory structures are simpler than those in Inside Mac. There are certain tasks where a symbolic language, or a command line interface, is more powerful and more efficient. For instance, who would prefer programming with a mouse than with C? Furthermore, just any symbolic language is not enough. The language should be extendible, flexible, and allow easy integration of many tools. This is where my UNIX experience comes in handy. UNIX offers a superb combination of tools, which can all be stringed together to form even more powerful tools, either by using pipes, or by using the shell. Another bonus in UNIX is the uniformity of the file types: nearly all files are text only. This means that you can run a program such as grep, and send its output directly to a sort, or to awk, or what have you. Files can be instantly viewed on the screen with only one program. There is no need to start up MacWrite, find out the file is in the wrong format, quit, wait for the finder to start up [ok, no startup time with multifinder], find some file conversion utility which hopefully will convert whatever the file is into something MacWrite can read, quit, start up macrwrite...etc. Why not just type "more file"? And, UNIX programs are written to be easilly integrated with other programs; mac programs are written to be standalone, and try to do everything in the world, but usually end up doing a few things well, and wasting a lot of space for other things, instead of sticking them in a general purpose utility (consider MS Word...) A major blunder of the Macintosh designers was to run the mac in supervisor mode all the time. This means that any silly program can do anything it wants to the rest of the system. Today, this creates horrible problems when working under multi-finder, since the smallest bug in a program can cause the whole system to bomb, causing you to lose tons of work. This would never happen on UNIX. UNIX is also more robust in the structure of its file system, which means system crashes will be less harmful [see "The Design and Implementation of the 4.3bsd UNIX Operating System"]. I could go on, but I don't have the time right now. I think my point is obvious. Besides, I realize menus and dialogs are easier to learn, but once you get past them, and really want to integrate your system, how do you do it? On the mac it's difficult to impossible. >> So, now I've got this big chunk of code, but, being a single hacker, >> I can't possibly compete with apple's resources, and whoever makes >> MPW. Besides, I wrote my program as a private project, not for >> someone who was paying me. Working now with MPW, I'm amazed at the >> design and implementation errors that its creators made! I'm amassing >> a list of complaints which I shall eventually mail off to its creators. >> Besides, version 3 is damn full of BUGS! It's hanging for no good >> reason, quite often too. I've even found one completely reproducible >> bug, which I shall also mail to MPW's creators [hey, you guys reading this?] >> >I get a little torqued when I hear people describe software like MPW, which >thousands of people are using with great success, described as "damn full >of BUGS!" by someone who the moment before seemed to be apologizing for the >sorry state of his own code. I know that reasonable people in netland >(including me, I like to think) read statements like "it's hanging for no >good reason" and just mentally translate that to "I don't know what I'm >doing, much less what I'm talking about." But, nonetheless, in my opinion >this newsgroup should not tolerate such irresponsible posting. >If you have a specific user interface criticism, Mr. Halberstadt, please >state your case and be prepared for rebuttal. If you have discovered a >bug, describe it and be ready for someone to explain what you did wrong. Ok, perhaps the bug I found is due to my ignorance. But what happens is that all the commands and nearly all the menu items on MPW v 3.0 stop functioning! Since I can't send a kill signal to the process, I have to reboot my mac. I've discovered I can save changes if I click on the close box of unsaved files. Anyone got a sollution? I've saved a shell script which seems to cause the bug consistently, but the bug also appears at random times during my work. Now to the design errors. It is obvious to anyone who has used UNIX that MPW is simply a take off on it. The commands make, search, reg-expressions, etc. But, unfortunately, MPW was too lazy to implement these features fully. I would like to tell you that MAKE and RCS and GREP and SED and AWK and PERL and...are much more powerful than their counterparts in MPW. It would have taken MPW little more effort to fully implement these programs. Also, they seem to have decided to modify these programs just enough, so that they are not quite like their UNIX counterparts. They've invented a whole new set of regular expression characters, yet another shell language, new options and names for standard commands, etc. My question is, since there are so many UNIX users out there, and since most UNIX tools have been proven effective after numerous years, why did MPW have to tinker with a good design? Ok, so they wanted to take advantage of the extended character set of the mac. Fine. But they should have provided the standard metacharacters as well, for the benefit of the thousands (hundreds of thousands?) of users who are already familiar with them. The same applies to the command names: admitadly, UNIX command names can be cryptic, and it's probably a good idea to provide things such as search instead of grep; well, at least MPW didn't screw this last thing up: they did remember to provide an alias mechanism. Now, to the command line interface of MPW. Very very annoying. I think a prompt based system like the csh would have been much better. My main gripe is that I'm a lefty, and I always have to reach way-yonder to get to the "enter" key just to execute the simplest command. Geesh! Now, it is nice to be able to select text and then execute it, but they still could have done that with a command line interface. Another problem with the MPW command entry is that I'm always going back and selecting a command inorder to execute it, but in the meantime the output from the command keeps placing my cursor further and further away from the command. Finding the command in a morrass of output gets quite tedious. In the csh, I can simply type '!c' or whatever, and the command is reexecuted. There is more, and as I said, I am still collecting data. But the above should give the reader a general idea of the types of complaints I have. -- Ari Halberstadt '91, "Long live succinct signatures" E-mail: ari@eleazar.dartmouth.edu Telephone: (603)640-5687 Mailing address: HB1128, Dartmouth College, Hanover NH 03755
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (08/04/89)
ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: >UNIX experience comes in handy. UNIX offers a superb combination of >tools, which can all be stringed together to form even more powerful >tools, either by using pipes, or by using the shell. so does any "older" system. IMHO you are confusing a large and well established software base with an operating system. I can do those same things with MPW, or any decent development system. UNIX is not required for doing pipes. You are confusing the shell's "user interface" and believeing it to be the operating system. But if you run X-Windows/Sun View or any other windowing system on top of a unix system and don't open up a shell window you now have the same limitations of the Macintosh. From your arguments you don't like Unix, you like it's shell. >Another bonus in UNIX is the uniformity of the file types: nearly all files >are text only. This means that you can run a program such as grep, and >send its output directly to a sort, or to awk, or what have you. Files You are assuming that the only thing worth while is text. Granted text processing of various kinds make up many of the chores of a computer science person. Unix was designed around text only systems. I can do many of the things that you list on an Atari 800, or MS Dos machine. The Mac was designed with a bitmap screen and graphical interface. It's primary purpose is not to let programmers pipe software, it's to let people use computers. Take the mythical magical average business/home/personal user. What would that person do with piping, grep and awk. The piping metaphor works quite well for "batch" processing but falls apart quite rapidly when you move into interactive enviroments. That average mac user doesn't understand unix or want to, so Unix like features aren't important. Again if you want Unix like features I've been quite happy with MPW as a CLI, and if you restrict yourself to text only files, all mac text editors allow you to use those files. Even on Unix with all of it's wonderful stuff when you start using some of the end user software your in the same boat as you are on a Macintosh. The files are no longer text only, and you can't use the standard tools to "manipulate" them. Again you're confusing your use of unix text editors & the shell for an operating system. There are lots of Unix programs that put stuff other than text in a file. If all I did on the mac was text only editors and such I could do many of those same wonderful "features" of unix, but I don't do text only processing, so I can't. >A major blunder of the Macintosh designers was to run the mac in supervisor >mode all the time. This means that any silly program can do anything it wants >to the rest of the system. Today, this creates horrible problems when working >under multi-finder, since the smallest bug in a program can cause the whole >system to bomb, causing you to lose tons of work. This would never happen >on UNIX. UNIX is also more robust in the structure of its file system, >which means system crashes will be less harmful [see "The Design and >Implementation of the 4.3bsd UNIX Operating System"]. See the design and hardware requirements of a Unix Operating System. The resources that Unix requires to implement all of that fancy stuff add cost to the machine that you run it on. That mac isn't a Unix machine, it was designed with other goals in mind. Unix eats up a ton or resources, disk space, memory, processor time etc. Unix may have started out small, but these days how many people would be willing to run a Unix system off of a 20 meg hard disk, 1 meg of RAM, and an internal 800k floppy. Lots and lots of people use this exact configuration everyday, and it is perfectly sufficient for their needs. I LOVE Unix, but for gods sake my father doesn't need unix for him to type a letter, or add up a column of #'s. The Mac/Amiga/ MS-Dos {ugh} computers are ideal for people to use as, follow me closely here, personal computers. What a concept, you mean someone can have their own computer, with out a network, or system administrator, or 200 megs of hard disk just for the operating system, gosh now isn't that a novel idea. Unix is good, but don't try and make the Mac work like a Unix machine, if you use the Mac for what it's good for you'll be much happier. >I could go on, but I don't have the time right now. I think my point >is obvious. Besides, I realize menus and dialogs are easier to learn, but >once you get past them, and really want to integrate your system, how do >you do it? On the mac it's difficult to impossible. Ya know theres a lot of people who don't ever get past menus and dialogs. I've had lots of experience with people, and most people CAN'T MEMORIZE commands, and even if they could they DON'T WANT TO, it's not their job. The computer to them is a tool, not a quest. Use it to get the info in and out in the shortest amount of time/effort possible. Then go home and FORGET about it. Computer Science types are a minority, we still are, and probably will be for many years to come. We need to help humanize computers so that others can use them, and what we consider a useful metaphor might not be the best way to make others use our tools. If you look beyond your own personal needs I think you'll see the Mac as a unique tool that has the potential to keeps all kinds of people happy. But please don't try and use a Macintosh like a unix machine, unix machines are better than the mac at unix, and macintosh's are better than unix in some ways. > [goes on with complaints that MPW isn't really unix, and it should be] Then go buy a Unix machine. If you bought the Mac to run Unix, or do Unix type things then I can understand your disappointment. And if you can't afford a Unix machine, I wonder why that is??? :-) Oh well just another $0.02 worth. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | God doesn't know, he would have never designed it like that in the first | |_ place. ____________________________________________________________________|
isle@eleazar.dartmouth.edu (Ken Hancock) (08/04/89)
>In article <1478dartvax.Dartmou.EDU>, ari@eleazar.dartmouth.edu (Ari Halber stadt) writes: [Lots of stuff about why MPW isn't as good as UNIX] Funny, but I've never seen Apple tote MPW as a UNIX replacement. One of the reasons it's called Macintosh Programmers Workshop instead of MPUnix. I really wasn't convinced by any of your arguments. Sure, it may have some bugs. Sure, some of their tools aren't as powerful as UNIX. Sure it doesn't have have of the nice features of c-shell. But, no one ever claimed that they did. There are hundreds of people (I wish I was, but I don't have the $$$) who use MPW every day and are quite happy with it. I'm sure that almost all of them could make some suggestions on how to improve it, but I think your earth-shaking flames really didn't shed much more light than a match... Then again, these are only my opinions. Ken Ken Hancock '90 | E-mail: (BITNET/UUCP/INTERNET) Computer Resource Center Consultant | isle@eleazar.dartmouth.edu ------------------------------------+--------------------------------------- DISCLAIMER? I don't get paid enough to worry about disclaimers.
levin@bbn.com (Joel B Levin) (08/04/89)
Does anyone have a guess what MPW would cost if it were sufficiently
Unix-like to require a Unix license?
/JBL
=
UUCP: levin@bbn.com (new) or {backbone}!bbn!levin (old)
INTERNET: levin@bbn.com POTS: (617) 873-3463
"The night was"ericsc@microsoft.UUCP (Eric Schlegel) (08/04/89)
In article<14834@dartvax.Dartmouth.EDU>ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: >Ok, perhaps the bug I found is due to my ignorance. But what happens is >that all the commands and nearly all the menu items on MPW v 3.0 stop >functioning! Since I can't send a kill signal to the process, I have to >reboot my mac. I've discovered I can save changes if I click on the >close box of unsaved files. Anyone got a sollution? I've saved a shell >script which seems to cause the bug consistently, but the bug also >appears at random times during my work. >... >Now, to the command line interface of MPW. Very very annoying. I think >a prompt based system like the csh would have been much better. My main >gripe is that I'm a lefty, and I always have to reach way-yonder to get >to the "enter" key just to execute the simplest command. Geesh! Now, it Two quick comments: your bug sounds like you've got a tool running that's reading from stdin. For example, if you type 'C' without any arguments and execute it, the c compiler will read its input from stdin and compile whatever you type. (Very handy for quick tests of code!) If you have a tool reading from stdin, most of the menus _are_ disabled as you describe. You should be able to kill a tool by typing cmd-Enter, which signifies end of input (ctl-D in unix) or by typing cmd-. which MPW intercepts and simply terminates the tool. If you would post your problem shell script we could probably determine if this is what's happening. Also, instead of pressing Enter to execute a command, you can also press cmd-Return (I've gotten so used to typing cmd-return that I find myself doing it in csh) or for the mouse-happy among us : ) you can click in the status box in the lower left-hand corner. These points are all documented in the shell reference. eric schlegel dartmouth '90, currently an intern low-life at Microsoft These opinions are MINE, ALL MINE!!!
leipold@eplrx7.UUCP (leipold) (08/07/89)
Speaking as a programmer of both Mac and Unix, I'd like to toss one question into this discussion: Back in the dark ages, we used to run a timesharing Unix system with lots of users (well, at least 15) on a teeny little PDP-11/70 with 64K or so of RAM. How come it takes 4M RAM, 80M disk, and a top-end Mac to get file redirection, multitasking, and all those nice Unix tools for just _one_ user? Hmmmm?
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (08/08/89)
leipold@eplrx7.UUCP (Walt Leipold) writes: >64K or so of RAM. How come it takes 4M RAM, 80M disk, and a top-end >Mac to get file redirection, multitasking, and all those nice Unix >tools for just _one_ user? Hmmmm? MPW runs on a 1 meg system, you just can't use some of the more complicated tools, but MPW 2.0 runs a 1 meg system. Also those unix applications your running where text based which demands a lot less resouces in terms of CPU and memory, also Unix has virtual memory, so even though you only had 64K, I think your real memory requirements might surprise you. Also I run MPW just fine with 2 megs a 40 meg HD, and if I wanted to give up my application's disk space a 20 meg HD would do just fine. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | God doesn't know, he would have never designed it like that in the first | |_ place. ____________________________________________________________________|
ari@eleazar.dartmouth.edu (Ari Halberstadt) (08/08/89)
Seeing as the topic of unix running on tiny machines has come up, I thought I may as well add my own history to the pot. The following is also one more reason I don't think the mac is so great [but it sure is good for writing papers for college, especially when you can use fonts to make an 8.5 page paper into a 10pg paper :=)] I first learned unix on a Fortune 32:16 micro-computer, running a slightly scaled down version of BSD4.2. We purchased it in 1983, but I think it had been around for a year before that. Our first configuration was: 1 terminal, 1 dot matrix printer, a 5meg Seagate or Rodime drive, a 700K double sided-double density 5-1/4 inch floppy disk, 500K RAM, Multiplan, FortuneWord, C, and some basic unix tools. The Fortune Computer used a Motorola 68000 CPU, the same as the mac. We could run just about any number of processes without really hurting performance too much, unless I was compiling. But what really proved this system so good was its excellent word processor, which was better than *any* WP available on microcomputers at the time. It is still better than Microsoft Word, at least for version 3.1; the only thing MS-Word beats it at is WYSIWYG for any font, but that is really due to the macintosh's graphics screen, something that was *not* popularly available when the Fortune computer came out. I would also like to praise the implementation of Multiplan, which was an excellent spreadsheet. The computer came with a very well laid out menu system which shielded the user from UNIX, unless the person chose to enter the shell, which was very simple to do from any location. The interface was, of course, based on a 24x80 screen, but also included an ergonomic keyboard with over 16 function keys, numeric keypad, and arrow keys. Calling programs and selecting commands was done with a menu system, where selections were made either by using the cursor keys, entering a 'yes/no' type response, or, one could have shortcuts, and cut out about 3 layers of menus for frequently used commands. Both software packages we had -- Fortune Word and Multiplan -- were excelent tools for their time, and if the company had been a better marketer, should have evolved into major products. They both used unix tools to their fullest, splitting the word processor, for instance, into about 10 programs; these included: mail merge, the editor itself, spelling checker, printing program, etc. And all this ran on a small drive and with little RAM. Eventually, we expanded, and got a 20meg drive [wow :-)], and 256K more RAM [gee whiz...]. One problem we had had with a 5meg disk was that whenever I wanted to program I had to removed the wordprocessor, and install C; this was no longer necessary. We also purchased the full set of UNIX tools, which allowed us to do some very nice automated typesetting. Both the spreadsheet and word processor allowed splitting the screen into several independent windows. This was facilitated by the special terminal, which had some graphics characters. The WP was fully programmable, with a C-like language syntax, allowing me to implement a data-base entry system directly in the editor! There were quite a few more good features, such as columns and a glossary. The best feature of these programs was the combination of a very user friendly environment with powerful, extendable, and modular, programs. A final note about Fortune Word: the designers of this program realized that by using a text-only format for the files, it would allow people to use all the standard unix utilities on them. They solved the problem by: 1. Splitting each file into three files: the text itself; statistical info, such as number of hours worked on document and by whom; and formatting specs, such as printing preferences, line spacing, etc. 2. Embeding codes in the text, such as: \B\ to start bold, \b\ to end bold text; \I\ to mark a hanging indent, etc. I have many fond memories about that computer. Unfortunately, the CEO's of the company don't seem to have been as smart as its engineers, and the computer has faded into the background. Sadly, we also had serious trouble getting adequate service for our computer [we lived overseas]. Today, just add a mouse, some fonts, and a graphical display, and I think this system would be up there competing with the best of them. -- Ari Halberstadt '91, "Long live succinct signatures" E-mail: ari@eleazar.dartmouth.edu Telephone: (603)640-5687 Mailing address: HB1128, Dartmouth College, Hanover NH 03755
pepke@loligo.cc.fsu.edu (Eric Pepke) (08/09/89)
Let's see if I shed a little darkness on this discussion: There is NO reason to believe that graphical interfaces are inherently less powerful, flexible, or synchronistic than command-line interfaces. Paul Haeberli* describes a visual system that is inherently considerably more powerful than Unix. Useful though redirection and pipes may be, the Unix command line is still limited by the fact that it is basically a one-dimensional construct, and each tool only has one input port. Haeberli's _ConMan_ allows many and links them in a two-dimensional graphical interface. With regard to the idea that nobody would ever program with a mouse, well, there are several software project management systems that use dataflow concepts and a visual metaphor. Some of them are very good, far better, in fact, than giving every member of the software development team a copy of EMACS and turning them all loose. These are no longer the days of the lone hacker heroically kludging away; good software must be designed, and some of the best tools are inherently graphical. Constructing a powerful visual metaphor is harder than throwing together a powerful but arcane command line interface (I hope this isn't news to anybody), but this does not mean that it is impossible, just that more work needs to be done. Remember that in 1984 people were saying that nobody would ever use a Macintosh for word processing because they would have to take their hands off the keyboard to move the cursor. Well, there were other overriding advantages that the visionaries saw that we now think are old hat, and it's not easy to remember the time when it was different. There couldn't possibly be any such advantages lurking waiting to be discovered in graphical development systems, could there? :-) Reference: *_ConMan: A Visual Programming Language for Interactive Graphics_ Paul E. Haeberli Siggraph '88 conference proceedings. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
rmh@apple.com (Rick Holzgrafe) (08/10/89)
In article <14895@dartvax.Dartmouth.EDU> ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: > Seeing as the topic of unix running on tiny machines has come up, > I thought I may as well add my own history to the pot. Well, me too. I started my career on a PDP-11/60 running Unix version 6. Not "System" 6, if there is such a thing: *version* 6, pre-Berkeley and everything. No vi or emacs, not even "more"; just "ed" for editing and reading text files. The PDP had (I think) 256K of "core" (I don't know what the medium really was) and I remember the excitement when we upgraded it to half a Meg. I shared this machine with about two dozen other users (at a time!) for editing, compiling, and assembling. Sometimes it took great patience, but there were benefits: Friday afternoons when the deadlines were upon us and the machine load was highest, it would invariably crash from sheer overwork, and we'd all get an hour or two to sit around and BS while the gurus repaired the file systems by hand. :-) Years of Unix taught me what a good user interface wasn't. I must have built a half-dozen different gadgets intended simply to speed up productivity by streamlining the user interface. One was a "Finder" for Unix, called "vf". People called it a "visual shell" (which it wasn't, really) and nobody called it a Finder since the Mac was not yet even a gleam in Steve Jobs' eye. (And before you ask: no, I'm not claiming to have invented the Finder! It was a *little* like the Mac Finder, without a mouse or graphics, but not much.) And say - any of you Unix hax out there ever use "scan" for reading text files? I wrote it, lavished years of love and creativity on it, made it powerful and robust, made it so that people who used it suddenly found Unix unusable without it - my magnum opus, it was. You know what? Resizable windows with scroll bars made it instantly obsolete. Long live the Mac! ...well, thanks for letting me rock on your porch, suck my teeth, and tell how we traipsed to work through the snow in the good ol' days. I'll shut up and go away now... :-) ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 27-O | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."