binder@eniac.seas.upenn.edu (Tim Binder) (11/17/88)
With all this talk about Mac interface improvement, I remember reading
somewhere (InfoWorld?) about Xerox's next step (:-) in user interfaces:
Rooms, where each "room" is dedicated to a particular project you might
be working on. Each room seemed to be the equivalent to a Mac MultiFinder
desktop. Does any have more details or better yet, comments on this
interface? Could this be the next step in interfaces?
On a slightly different note: One thing that really annoys me about the Mac
is that it has taken Apple over 4 years to get the Mac to where the Lisa
was when it was first introduced! The Lisa had only 512K of memory, yet
supported a desktop much like MULTIFINDER now. Now, however, if you have
1 MEG of RAM or less, don't even think about it. The same is becoming true
for many applications. Are people just getting "sloppy" about memory usage,
or is there something I'm missing? Admittedly, the Lisa had a limited base
of programs, but then again, no development environment existed for it.
Tim
__
/\ \ Timothy M. Binder | "He's dead honey
/ \ \ binder@eniac.seas.upenn.edu | 'cause Mommy
/ /\ \ \ CI$ 71106,1124 [but VERY rarely] | killed him."
/ / /\ \ \ |
/ / /__\_\ \ known in the SCA as |
/ / /________\ Gwydion Rhys ap Rhianwen |
\/___________/ bob@eecs.nwu.edu (Bob Hablutzel) (11/17/88)
> On a slightly different note: One thing that really annoys me about the Mac > is that it has taken Apple over 4 years to get the Mac to where the Lisa > was when it was first introduced! The Lisa had only 512K of memory, yet > supported a desktop much like MULTIFINDER now. Now, however, if you have > 1 MEG of RAM or less, don't even think about it. The same is becoming true > for many applications. Are people just getting "sloppy" about memory usage, > or is there something I'm missing? Admittedly, the Lisa had a limited base > of programs, but then again, no development environment existed for it. Personally, I think there are several reasons for memory use increasing: Programs are more complex: Consider FullWrite, XPress, etc. Nothing of this complexity exists for the Lisa. Obviously, the more a program does, the more code is needed to implement this complexity. Programs are sloppier about memory: With the complexity of programs increasing, it is getting harder and harder to watch every piece of memory. Especially with the (unique?) error reporting on the Mac. Finally, and I'm going to get flamed right and left for this, but here we go: Most applications are written in high level languages these days, by teams of programmers. I'm sorry, and you can disagree, but there is _no way_ that high level code can match the size and speed compactness of assembly language programming. This has nothing to do with using tricks of the chip, or black magic, but because high level languages require support routines and the like which assembly language code can avoid. (For example: I just stopped work on a mail project - it communicated between VAX Mail and a Macintosh, with a true Mac interface, printing, cut/paste (no undo), graphic interface, etc, etc. It was written completely in assembler, both on the VAX and the Mac. Consider it to be 85% done. Final code size: 26K on the VAX, and 40K on the Mac. Needless to say, it worked just fine with MultiFinder). Oops. Didn't quite mean to go on like that. Well, the above is my opinion, and I tend to get overworked about it sometimes. Sorry about that. Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU
rick@Jessica.stanford.edu (Rick Wong) (11/18/88)
In article <6217@netnews.upenn.edu> binder@eniac.seas.upenn.edu.UUCP (Tim Binder) writes: >With all this talk about Mac interface improvement, I remember reading >somewhere (InfoWorld?) about Xerox's next step (:-) in user interfaces: >Rooms, where each "room" is dedicated to a particular project you might >be working on. Each room seemed to be the equivalent to a Mac MultiFinder >desktop. Does any have more details or better yet, comments on this >interface? Could this be the next step in interfaces? I've seen it, and I was very impressed. It allows you to build rooms oriented toward particular tasks that you perform often. For instance, you can have: a publishing room that contains tools for word-processing, drawing, and page layout; a mail room that contains telecommunications and text-processing tools; a filing room for your Finder; etc. You can create "doors" between rooms, so that you can easily switch between related tasks (imagine several instances of MultiFinder running under Switcher . . .). One of my big complaints with MultiFinder is the window cluttering it creates. Because of the small screen space, the application I want to switch to is often buried under some other application's windows. To get to the application I want usually takes several clicks (I almost never use the Apple menu, because of the extra work of having to drag all the way to the bottom of the menu, and then having to think about which application I want to choose). NeXT gets around the window-cluttering problem somewhat by allowing you to "iconize" an application. Although this reduces window-clutter, it doesn't really eliminate the rigamarole you have to go through when switching tasks (i.e., find current tasks's main menu; choose "iconize", or "hide", or whatever it's called; find icon for desired task; where is that darned icon?; etc.). By the way, Rooms was developed at Xerox AI Systems, not PARC (just setting the record straight). Rick "Wild Twinkie Surprise" Wong Courseware Authoring Tools Project, Stanford University rick@jessica.stanford.edu "Ask not what your country can do for you; ask what you can do for George Bush"
lsr@Apple.COM (Larry Rosenstein) (11/18/88)
In article <6217@netnews.upenn.edu> binder@eniac.seas.upenn.edu.UUCP (Tim Binder) writes: > >is that it has taken Apple over 4 years to get the Mac to where the Lisa >was when it was first introduced! The Lisa had only 512K of memory, yet >supported a desktop much like MULTIFINDER now. Now, however, if you have >1 MEG of RAM or less, don't even think about it. The same is becoming true The Lisa came with 1Mb; we never quite got the system to run with 512K of RAM. More importantly, the Lisa has an MMU and used virtual memory. Also, there was a development environment for the Lisa (called the Lisa Workshop), and there was an application framework called the Lisa ToolKit, which was the predecessor of MacApp. (There was also a way to write character-based applications that ran on the Lisa.) A couple of 3rd parties did write applications for the Lisa. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
levin@bbn.com (Joel B Levin) (11/18/88)
In article <4151@Portia.Stanford.EDU> rick@Jessica.stanford.edu (Rick Wong) writes:)
] . . . To
]get to the application I want usually takes several clicks (I almost
]never use the Apple menu, because of the extra work of having to drag
]all the way to the bottom of the menu, and then having to think about
]which application I want to choose).
Check out Larry Rosenstein's INIT/cdev ApplicationMenu. It lets you
click at either end of the menu bar to get a menu of all application
layers (and the DA layer if you have any going), or with modifier keys
(e.g. command key) anywhere on the menu bar. Also, Suitcase users can
hold Option while mousing the Apple menu and all the DAs will be
omitted, thus presenting the application list near the top.
/JBL
UUCP: {backbone}!bbn!levin POTS: (617) 873-3463
INTERNET: levin@bbn.comblm@cxsea.UUCP (Brian Matthews) (11/19/88)
Tim Binder (binder@eniac.seas.upenn.edu.UUCP) writes: |On a slightly different note: One thing that really annoys me about the Mac |is that it has taken Apple over 4 years to get the Mac to where the Lisa |was when it was first introduced! The Lisa had only 512K of memory, yet |supported a desktop much like MULTIFINDER now. Now, however, if you have |1 MEG of RAM or less, don't even think about it. The same is becoming true |for many applications. Are people just getting "sloppy" about memory usage, |or is there something I'm missing? Yes, badly. The Lisa was a virtual memory machine. Each application had it's own 16Meg chunk of "memory", and the underlying OS paged things to hard disk. -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
mdixon@arisia.Xerox.COM (Mike Dixon) (11/19/88)
In article <4151@Portia.Stanford.EDU> rick@Jessica.stanford.edu (Rick Wong) writes: > .... >By the way, Rooms was developed at Xerox AI Systems, not PARC (just >setting the record straight). Just to set the record a little straighter, Rooms *was* developed at PARC, by Stu Card and Austin Henderson. It was later reimplemented (primarily by Doug Cutting, I believe) and marketed by Xerox AI Systems. .mike. -- .mike.
mce@tc.fluke.COM (Brian McElhinney) (11/24/88)
In article <10330083@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes: >Most applications are written in high level languages these days, by teams of >programmers. I'm sorry, and you can disagree, but there is _no way_ that >high level code can match the size and speed compactness of assembly language >programming. This has nothing to do with using tricks of the chip, or black >magic, but because high level languages require support routines and the >like which assembly language code can avoid. True enough, if you have an infinite amount of time; there is also _no way_ that a team of programmers can develop and test code in the same amount of time using low-level tools (assembly language). You just can't manage a large amount of arbitrary complexity without high level tools. Best put by the (so far as I know) anonymous quote: "Newton said that if he had seen further than others it was because he was standing on the shoulders of giants. The problem with software engineering is that we're all standing on each other's toes." Obviously, we still have a long way to go yet, even with high level languages. Assembly language is useful in it's place, but only there. I would wager that most of the speed and compactness improvements are due to better work habits forced on you by the lack of type checking, etc., of assembly language. The same skills would serve you just as well in any software environment. Brian McElhinney mce@tc.fluke.com
pcolby@robbie.prime.com (Peter Colby) (11/28/88)
In article <6105@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <10330083@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes: >> ... I'm sorry, and you can disagree, but there is _no way_ that >>high level code can match the size and speed compactness of assembly language >>programming. This has nothing to do with using tricks of the chip, or black >>magic, but because high level languages require support routines and the >>like which assembly language code can avoid. > >True enough, if you have an infinite amount of time; there is also _no way_ >that a team of programmers can develop and test code in the same amount of >time using low-level tools (assembly language). You just can't manage a large >amount of arbitrary complexity without high level tools. ... > >Assembly language is useful in it's place, but only there. I would wager that >most of the speed and compactness improvements are due to better work habits >forced on you by the lack of type checking, etc., of assembly language. The >same skills would serve you just as well in any software environment. > Several comments. 1) OS 360 was written in assembly language. Even today there are not a whole lot of programs equivalent in either size or complexity. Remember, we're talking somewhere around 1965-1968. Read "The Mythical Man Month" by ?? Brooks. The issue isn't complexity, it's lines of code. In most cases you get more work per line of HOL code than you do per line of assembly. The only reason HOLs are considered an advantage is because most programmers are really coders Automate coding from design specs and you lose all advantage of HOLs. (Of course the "design language" now becomes the HOL and languages like C, LISP, SMALLTALK etc become "assembly languages" and are inefficient low level tools.) 2) One of the major savings in using assembly language IS due to "tricks of the chip". I remember doing assembly programming on a CDC 6600 (1975). Two techniques in particular were used to speed up programs; First, we coded inner loops to keep the entire intruction stream in the instruction cache - no memory access (for instructions) - major gain; second, we interleaved instructions to take advantage of mutually independant asynchronous functional units - the units only synchronized to access common registers - depending upon the task, this could gain little to a lot. 3) The other major saving in using assembly language is "optimization". Yes, having to include support code and other general library routines from the compiler cuts down on code efficiency, but the major problem is that most commercial compilers generate horrible code. Hand coding in assembly makes up for the stupidity of compilers. Of course, good compilers can be written but I suspect that the R&D effort involved would push the potential selling price out of the reach of most buyers. However, take a look at the IBM FORTRAN H (optimizing) compiler or the original PASCAL compiler written specifically for the CDC 6600. 4) It's still a truism that appropriate algorithms buy you far more than hand optimization. However, once you have a working program you can substantially improve it's speed by analysing the bottlenecks and recoding the critical procedures (or loops) in assembly language. As an aside, the latest MacTutor has an interesting article on optimizing an assembly language routine. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = UUCP: {sun,decvax,linus}!cvbnet!pcolby ||| "We has met the enemy and he is us." UUCP: pcolby@robbie.prime.com ||| Pogo CSNET: pcolby@robbie.prime.com |||