cox@stpstn.UUCP (Brad Cox) (12/31/90)
In article <19413@yunexus.YorkU.CA> davecb@yunexus.YorkU.CA (David Collier-Brown) writes: >From <1990Dec19.102005.11830@engin.umich.edu> >by zarnuk@caen.engin.umich.edu (Paul Steven Mccarthy): >[...] The impression that I >| have gotten from most professionals in the software trade is something >| like: "Speed isn't important. The hardware will speed up and take care >| of our inefficiencies." > > Many moderately experienced people in the commercial world believe that >optimization is the work of the devil. To bring this from the general to the specific: Observation #1: Unix tools, such as vi, are remarkable (IMHO) for (a) their speed (adequate) (b) their user interface (terrible). Observation #2: Macintosh tools such as Nisus (a text editor with comparable regular expression capability) are remarkable for (a) their speed (terrible) (b) their user interface (adequate). To make these difference specific, I've just spent the weekend moving a .5M Interleaf file from Unix to Mac, using regular expressions under Nisus as I've used them countless times under vi. I've allocated 4M of memory allocated to Nisus (since it manages the entire file in memory. Note that vi does not; holding large files partially on disk). I've consistently observed that searches that would have finished in milliseconds under vi can take anywhere from many seconds to, occasionally, *hours* under Nisus. This is not to single out Nisus. The same general observation seems to hold for comparable end-user applications across the board. My question: Why does this pattern seem to recur consistently between comparable Macintosh versus Unix applications? Is it because of a technical reason (maybe file system differences; memory management, etc?)? Or is it because of something non-technical; a difference between the cultures who develop for these platforms? I'm particularly interested in hearing from anyone who has deep technical and/or cultural experiences on both machines. Opinions and/or guesses are welcome too, but the differences are sufficiently remarkable that I suspect there's a tangible reason. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
davecb@yunexus.YorkU.CA (David Collier-Brown) (01/01/91)
cox@stpstn.UUCP (Brad Cox) writes: >My question: Why does this pattern seem to recur consistently between comparable >Macintosh versus Unix applications? > >Is it because of a technical reason (maybe file system differences; memory >management, etc?)? >Or is it because of something non-technical; a difference between the >cultures who develop for these platforms? I'd suggest culture as much as any single thing. Partially because culture is more than a single thing (:-)). Because the authors of Unix were researchers, they were interested in ongoing work in the areas of string matching, for example, and carried out analyses and experiments to discover the performance of both the algorithms and their implementation(s). Because the authors of the Macintosh were marketers (in the complimentary sense!), they were interested in the acessability of the systems they designed, and carried out analyses and experiments to discover what could be understood quickly and unambiguously by new users. In one small company I had the pleasure to have been associated with, they were marketers porting a known high-performance application. **They** did analyses and conducted experiments on both acessability and speed. Acessability came first, but in the presence of competition, we found a bottleneck in the Mac Pascal compiler, and significantly improved the speed of the critical inner loop of TeX. They were quite aware of the significance of speed to their customers, but a working product came first... very much first (the then compeditor had a tendancy to stop mysteriously about 10 pages into a complex paper full of math: we didn't really mind being slower as long as we never actually stopped (:-)). You see similar ``what do we concentrate on first'' decisions elsewhere in the industry, often very closely related to either the culture the company lives in, or the one it plans to sell into. One of the obvious ones is Mips/SGI: after doing an operating system together, Mips spent time and money on BSD4.x compatability and SGI spent effort on graphics. --dave
davidm@uunet.UU.NET (David S. Masterson) (01/01/91)
>>>>> On 30 Dec 90 20:11:33 GMT, cox@stpstn.UUCP (Brad Cox) said:
Brad> Observation #1: Unix tools, such as vi, are remarkable (IMHO) for
Brad> (a) their speed (adequate)
Brad> (b) their user interface (terrible).
Brad> Observation #2: Macintosh tools such as Nisus (a text editor with
Brad> comparable regular expression capability) are remarkable for
Brad> (a) their speed (terrible)
Brad> (b) their user interface (adequate).
Brad> To make these difference specific, I've just spent the weekend moving a
Brad> .5M Interleaf file from Unix to Mac, using regular expressions under
Brad> Nisus as I've used them countless times under vi. I've allocated 4M of
Brad> memory allocated to Nisus (since it manages the entire file in memory.
Brad> Note that vi does not; holding large files partially on disk).
Brad> I've consistently observed that searches that would have finished in
Brad> milliseconds under vi can take anywhere from many seconds to,
Brad> occasionally, *hours* under Nisus.
Brad> My question: Why does this pattern seem to recur consistently between
Brad> comparable Macintosh versus Unix applications?
Just a guess, but I'll bet it has to do with the NIH (Not Invented Here)
syndrome in the industry (I'm not singling out Apple). Add to this the GIDN
(Get It Done Now!) syndrome and you have people implementing something new (or
what they think is new - NIH) as fast as possible (GIDN) and then not having
time to go back and fix it until complaints come in.
Comments?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"thom@dewey.soe.berkeley.edu (Thom Gillespie) (01/02/91)
I'm not sure I understand the question. I use a Mac at Home, IBM/Mac at school, and vi as the common element everywhere. I really don't do all that much " regular expression searching" On the Mac using scroll bars and having an idea about where my info is reduces slow searches. On vi I find the " regular expression searching" very slow because it takes me through too many intsances. I know that vi is faster than anything I use on the Mac or IBM: Word, WriteNow, and WordPerfect, but it doesn't matter. If it takes a long time I just read something. Half the time I'm running multifinder on the Mac and have a unix account running vi in one window and Word in another window. I've used vi so long that my finger nails know what to do. I guess the interface is more important now. I came to the Mac from vi and unix, it all seemed wonderful. If I was going from a Mac and Word to vi and unix I don't think I'd feel the same. My wife gets very frustrated when she is using mail and the vi editor doesn't act like a Mac editor, no mousing. --Thom
mce@tc.fluke.COM (Brian McElhinney) (01/05/91)
In article <5966@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >Observation #1: Unix tools, such as vi, are remarkable (IMHO) for > (a) their speed (adequate) > (b) their user interface (terrible). > >Observation #2: Macintosh tools such as Nisus (a text editor with comparable > regular expression capability) are remarkable for > (a) their speed (terrible) > (b) their user interface (adequate). > [...] > >My question: Why does this pattern seem to recur consistently between >comparable Macintosh versus Unix applications? First and foremost there are fundamental user interface differences (textual vs graphical). Graphical user interfaces are much harder. They take a significant percentage of your development resources (time, personnel, testing, etc). You never have infinite development resources, so something has to give. The UNIX marketplace has fewer end users, and those users tend to be very technical. In the Macintosh market this subset of users corresponds to the so-called "power" users, and is a small percentage of the total customer base. Non-technical users are less sensitive to performance, and are less likely to switch if higher-performance tools become available. They will switch if "needed" features are in your product. So what do you make the higher priority? Getting features working, or making features work fast? [This is also, incidently, what leads to the "kitchen sink" effect so often seen in Macintosh applications] There are some technical differences, and though no one of them causes a problem, they do add up. Instead of byte stream files, MacOS has structured files (data and resource forks). Things that are hard-coded in UNIX programs are often dynamically loaded resources in Macintosh programs. The Mac does not have virtual memory, instead using small heaps allocated via doubly-indirected pointers (so heap compaction is a problem). The Mac community expects binary compatibility across OS versions and new hardware platforms. The Mac does not have memory protection, which makes debugging harder. What I'm getting at is that there may be more complexity for the "same" job, leading to a problem similar to that of user interfaces: if it is hard it takes more effort, and you always have limits on your development resources. Brian McElhinney "There is no magic. There is only knowledge, mce@tc.fluke.com more or less hidden" --Gene Wolfe
melling@cs.psu.edu (Michael D Mellinger) (01/06/91)
In article <1991Jan4.225943.540@tc.fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
First and foremost there are fundamental user interface differences (textual
vs graphical). Graphical user interfaces are much harder. They take a
significant percentage of your development resources (time, personnel,
testing, etc). You never have infinite development resources, so something
has to give.
[stuff deleted]
There are some technical differences, and though no one of them causes a
problem, they do add up. Instead of byte stream files, MacOS has structured
files (data and resource forks). Things that are hard-coded in UNIX programs
are often dynamically loaded resources in Macintosh programs. The Mac does
not have virtual memory, instead using small heaps allocated via
doubly-indirected pointers (so heap compaction is a problem). The Mac
community expects binary compatibility across OS versions and new hardware
platforms. The Mac does not have memory protection, which makes debugging
harder. What I'm getting at is that there may be more complexity for the
"same" job, leading to a problem similar to that of user interfaces: if it is
hard it takes more effort, and you always have limits on your development
resources.
So, what would happen if a company built a computer that used Unix,
then added a GUI comparable to that of the Macintosh, and to top it
off, they did all the tedious user interface work for the software
developer?
I think the next few years should prove to be an interesting time for
software developers.
-Mikerar@saturn.ads.com (Bob Riemenschneider) (01/07/91)
In article <F7&0x-14@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes:
So, what would happen if a company built a computer that used Unix,
then added a GUI comparable to that of the Macintosh, and to top it
off, they did all the tedious user interface work for the software
developer?
My guess is it would start selling enough to be a threat to Apple, be
sued by Apple for violating the Mac "look and feel" copyright (even if
the GUI didn't look or feel much like the Mac's), spend millions
defending itself in court, and probably go belly up as a result.
-- rarrmartin@clear.com (Bob Martin) (01/10/91)
>In article <5966@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >>Observation #1: Unix tools, such as vi, are remarkable (IMHO) for >> (a) their speed (adequate) >> (b) their user interface (terrible). >>Observation #2: Macintosh tools such as Nisus (a text editor with comparable >> regular expression capability) are remarkable for >> (a) their speed (terrible) >> (b) their user interface (adequate). >>My question: Why does this pattern seem to recur consistently between >>comparable Macintosh versus Unix applications? I don't know about Nisus (sounds like a Larry Niven Character). And I have seen Mac programs with UIs that are merely adequate. But in general the MAC system and most of the applications support UIs that are far far superior to anything on a Unix or any other kind of system. (OK, OK, this sounds polarized and there are some good UIs for _some_ unix programs?) Take programs like More or Excel, or programming languages like Prograph. These programs have outstanding user interfaces. Many people never even have to crack the manuals (no so for Prograph). Even little things like Macwrite, Macpaint, Macdraw are extremely useful even with their (sometimes significant) limitatoins, simply because you get a whole lot of functionality accesible to the user who is not willing to spend a lot of time learning how to use it. But it would seem that your real complaint is speed. Granted some Mac programs could be faster. But for the majority of the things that you can use a Mac for, the speed is a non-issue. Furthermore, execution speed is only a tiny fraction of what can slow down a user. The UI on the Mac makes most jobs go much faster simply by virtue of its ease of use. BTW there are some pretty fast programs on the Mac. -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
rmartin@clear.com (Bob Martin) (01/10/91)
In article <F7&0x-14@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >So, what would happen if a company built a computer that used Unix, >then added a GUI comparable to that of the Macintosh, and to top it >off, they did all the tedious user interface work for the software >developer? > >I think the next few years should prove to be an interesting time for >software developers. > >-Mike I think the next few years will prove very interesting for the software industry. But I am not sure what you are getting at. Will a non-technical organization _ever_ be able to put a Unix machine on a secretaries desk. Can Unix machines be sold to housewives and high school students in relative bulk. Even if a company did what you suggest (and a few have or course) Unix remains far far to complex a management and support problem for the personal or non-technical professional user. -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
lee@quincy.cs.umass.edu (Peter Lee) (01/16/91)
In article <F7&0x-14@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: Path: dime!umvlsi!m2c!bu.edu!att!tut.cis.ohio-state.edu!cs.utexas.edu!wuarchive!psuvax1!news From: melling@cs.psu.edu (Michael D Mellinger) Newsgroups: comp.software-eng Date: 5 Jan 91 21:19:03 GMT References: <470@eiffel.UUCP> <19413@yunexus.YorkU.CA> <5966@stpstn.UUCP> <1991Jan4.225943.540@tc.fluke.COM> Sender: news@cs.psu.edu (Usenet) Organization: Penn State Computer Science Lines: 35 Nntp-Posting-Host: client6.cs.psu.edu In article <1991Jan4.225943.540@tc.fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: First and foremost there are fundamental user interface differences (textual vs graphical). Graphical user interfaces are much harder. They take a significant percentage of your development resources (time, personnel, testing, etc). You never have infinite development resources, so something has to give. [stuff deleted] There are some technical differences, and though no one of them causes a problem, they do add up. Instead of byte stream files, MacOS has structured files (data and resource forks). Things that are hard-coded in UNIX programs are often dynamically loaded resources in Macintosh programs. The Mac does not have virtual memory, instead using small heaps allocated via doubly-indirected pointers (so heap compaction is a problem). The Mac community expects binary compatibility across OS versions and new hardware platforms. The Mac does not have memory protection, which makes debugging harder. What I'm getting at is that there may be more complexity for the "same" job, leading to a problem similar to that of user interfaces: if it is hard it takes more effort, and you always have limits on your development resources. So, what would happen if a company built a computer that used Unix, then added a GUI comparable to that of the Macintosh, and to top it off, they did all the tedious user interface work for the software developer? I think the next few years should prove to be an interesting time for software developers. -Mike It strikes me that what you are describing is exactly what NeXT did -- the NeXTStep GUI runs on top of a MACH Kernel, and the Interface Builder application is supposed to greatly ease software development. Of course it's noticeably sluggish on a 68030 (largely, I'm told, from the use of Postscript as the unified imaging model). We'll see how they fare as the 68040 based models start becoming more widespread... -- |- Peter E. Lee, Staff Assistant -| | Software Development Lab at the University of Massachusetts at Amherst | | lee@cs.umass.edu or Fuligin@umass.bitnet or (413) 256-1329 | "When you expect whistles, it's flutes. When you expect flutes, it's whistles"