msw@unix.cis.pittsburgh.edu (Matt S Wartell) (08/14/89)
I have just recently begun using GNU Emacs and am very impressed. However, I am curious about a bit of philosophy that seems to be behind the emacs way of thought. In particular, emacs attempts to do everything. In some ways, this is nice; for example, the ability to reconfigure an editor to support LaTeX is useful. However, does an editor really need to know how to read mail, post news, run an Eliza session or establish a telnet connection? This seems to be counter to the Unix philosophy of ``a tool should do one job and do it well.'' Does GNU emacs do all of these `extra' tasks because it can, or is there a compelling reason to do everything from within the editor? Please, do not read this as a criticism of the support packages that come with emacs, but rather as a query regarding the Buddha nature (:-) of emacs. -- matt wartell, university of pittsburgh msw@unix.cis.pittsburgh.edu
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (08/16/89)
In article <19115@unix.cis.pittsburgh.edu> msw@unix.cis.pittsburgh.edu (Matt S Wartell) writes:
...emacs attempts to do everything... This seems to be counter to
the Unix philosophy of ``a tool should do one job and do it well.''
Perhaps you're looking at it wrong - each elisp package is a tool, and
does its single job well. Emacs is just the Lisp interpreter and user
interface veneer that provides a common way to get to them all.art@buengc.BU.EDU (A. R. Thompson) (08/17/89)
In article <19115@unix.cis.pittsburgh.edu> msw@unix.cis.pittsburgh.edu (Matt S Wartell) writes: >I have just recently begun using GNU Emacs and am very impressed. >However, I am curious about a bit of philosophy that seems to be >behind the emacs way of thought. > >In particular, emacs attempts to do everything. In some ways, this is >nice; for example, the ability to reconfigure an editor to support >LaTeX is useful. However, does an editor really need to know how to >read mail, post news, run an Eliza session or establish a telnet >connection? This seems to be counter to the Unix philosophy of ``a >tool should do one job and do it well.'' > >Does GNU emacs do all of these `extra' tasks because it can, or is there >a compelling reason to do everything from within the editor? > >Please, do not read this as a criticism of the support packages that >come with emacs, but rather as a query regarding the Buddha nature (:-) >of emacs. Because in reality emacs is a lisp system that happens to have a lot of built in editing functions.
rodney@taac.ipl.rpi.edu (Rodney Peck II) (08/18/89)
MSW> I have just recently begun using GNU Emacs and am very impressed. MSW> However, I am curious about a bit of philosophy that seems to be MSW> behind the emacs way of thought. MSW> In particular, emacs attempts to do everything. In some ways, this is MSW> nice; for example, the ability to reconfigure an editor to support MSW> LaTeX is useful. However, does an editor really need to know how to MSW> read mail, post news, run an Eliza session or establish a telnet MSW> connection? This seems to be counter to the Unix philosophy of ``a MSW> tool should do one job and do it well.'' In addition to the other things people have already said about emacs being a lisp interpreter, you should also note that emacs wasn't built around Unix originally. That's why the Unix interface can be a bit clunky at times. -- Rodney
jv@mh.nl (Johan Vromans) (08/18/89)
MSW> .. This seems to be counter to the Unix philosophy of ``a
MSW> tool should do one job and do it well.''
Right. But all tools have a different idea about what is 'well'. So a
single tool with a consistent user interface may be against this
philosophy, but feels better.
Johan
--
Johan Vromans jv@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500
------------------------ "Arms are made for hugging" -------------------------cooper@vlab.enet.dec.com (g.d.cooper in the shadowlands) (08/23/89)
Think about it this way. Do I really want to have to exit my editor to do something else? With an answer of no, shades ============================================================================ | But I that am not shaped for sport- | Geoffrey D. Cooper | | ive trick, nor formed to court an | cooper@vlab.enet.dec.com | | amorous looking glass... | business (508) 467-3678 | | | home (617) 925-1099 | ============================================================================ Note: I'm a consultant. My opinions are *MY* opinions.
fox@cs.cs.columbia.edu (David Fox) (08/23/89)
While the origional poster was quite open-minded, I am surprised at how many people are upset by the notion of an editor doing things previous editors have not done. I would have thought that in a field as new and rapidly changing as computer software people would have an understanding that the labels they give to things, such as "editor", "shell", "word-processor", "database manager" do not refer to immutable concepts but are just temporary labels we use to refer to software systems whose actual function is continuously evolving. David Fox fox@cs.columbia.edu (Am I supposed to mail this somewhere rather than post it? That information does not seem to be available to me.)
lum@armadillo.cis.ohio-state.edu (Lum Johnson) (08/29/89)
In article <BOB.89Aug15170146@tinman.cis.ohio-state.edu> Bob Sutterfield <bob@cis.ohio-state.edu> writes: >In article <19115@unix.cis.pittsburgh.edu> msw@unix.cis.pittsburgh.edu (Matt S Wartell) writes: > ...emacs attempts to do everything... This seems to be counter to > the Unix philosophy of ``a tool should do one job and do it well.'' > >Perhaps you're looking at it wrong - each elisp package is a tool, and >does its single job well. Emacs is just the Lisp interpreter and user >interface veneer that provides a common way to get to them all. A sufficent explanation of the difference in system philosophy between the UNIX operating system and the Emacs virtual operating system is, I think, inherent in the difference in system history: UNIX grew up on a very small machine, the PDP-11 EMACS grew up on a very large machine, the PDP-10 Admittedly, GNU Emacs is written in C and Lisp rather than in assembly language and TECO as ITS/TWENEX Emacs is, but it still has the habits and instincts of a program designed for a very large system. The PDP-10 implements true virtual memory, with paging as well as swapping, so the use of each page of physical memory is individually scheduled for maximum throughput, and unused pages of a program's image do not become resident in memory. A running ITS/TWENEX Emacs image typically uses only about 30 to 35 pages of physical memory - more pages are mapped but not in core. (A page is 512 36-bit words - it will store 2560 7-bit bytes or 2048 9-bit bytes.) The transitions from KI-paging (cf VAX/VMS pre-V4.0) to KL-paging (ca 1972, cf VAX/VMS circa V4.0), and from raw TECO to CTRL/R TECO (Emacs) occurred roughly simultaneously, so Emacs unsurprisingly relies upon free heavy-duty memory management. ITS/TWENEX Emacs does not in fact run on early PDP-10 processor models or under early PDP-10 operating systems (PDP-6's or KA's, or TOPS-10), which lacked this (amoung other things). It is not enough for a machine to be simply "big". Lum (Your "system paleontologist") -=- -- Lum Johnson lum@cis.ohio-state.edu lum@osu-20.ircc.ohio-state.edu "You got it kid -- the large print giveth and the small print taketh away." -------
jkh@meepmeep.pcs.com (Jordan K. Hubbard) (08/29/89)
>A sufficent explanation of the difference in system philosophy >between the UNIX operating system and the Emacs virtual operating >system is, I think, inherent in the difference in system history: > > UNIX grew up on a very small machine, the PDP-11 > > EMACS grew up on a very large machine, the PDP-10 Argh. This is taking a side effect of its design philosophy and stating it AS the design philosophy. While it's certainly true that a large part of UNIX's power and appeal lies in its ability to string a lot of well isolated tools together, it's a dangerous trap to assume that ALL tools should be similarly isolated to correctly follow the Unix "philosophy" (small, elegant and ignorant). While a good many tasks can be performed using this approach, many actually require moving along opposite lines. Seamless integration, rather that defined isolation, seems to be one of the new targets that software developers are trying to hit. The fact that people are putting down large chunks of change for packages like "Alis", despite their, er, rather poor design and implementation is a case-in-point. Calling EMACS an "Editor" is like calling Unix a "dispatcher". It's an environment, and an exceptionally powerful and extensible one at that. I can read my news, transfering any interesting articles to an MH folder, or stripping the headers off of a shell archive in-situ and unpacking it on the fly. If I decided to then compile it I could do so, tracking and fixing any errors along the way. If it all proved to be too much, I could grab the error messages and stuff them into an informative mail message to the author, all without leaving emacs! I won't even go into the value of having emacs while developing Lisp/C code. Emacs is an adjunct to Unix, not just another subordinate tool. Jordan Hubbard -- PCS Computer Systeme GmbH, Munich, West Germany UUCP: pyramid!pcsbst!jkh jkh@meepmeep.pcs.com EUNET: unido!pcsbst!jkh ARPA: jkh@violet.berkeley.edu or hubbard@decwrl.dec.com