lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (06/02/90)
In article <266576A7.6D17@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >And I would like to know whether anyone agrees with Mr. >Graham that "resource issues" are "short term" while >"maintenance issues" are "long term." Resources are used >as long as you run a program; maintenance is over >whenever you decide to stop maintaining it. The latter >often happens before the former. The issue that connects these is cost-to-builder. The resource issues are mostly costs inasmuch as user [un]happiness will feed back to the builder. The maintenance issues are mostly costs measured in the builder's effort spent, and in deadlines slipped. Clearly, balancing such issues is a higher-level task. I don't presume to have hard rules: tradeoffs are best taught by example. It is perhaps the essence of engineering to trade off well, and the essence of technology to readjust the balances, and to do end runs. If posters would argue for small/simple/fast/etc, by giving actual examples, I think that I for one would learn more. Many years ago, Motorola brought out an 8-bit micro which only needed +5V power. Intel could have done the same, but they decided to beat Motorola to market. And that is why the 8080 needed multiple power supply voltages - a pain to designers - and also a big part of why the 8080 was the more successful product. Time to market seems to have been the right tradeoff, at that time and place. There's a wonderful anecdote in "The Psychology of Computer Programming" (G. Weinberg) about how a program has to work before it's interesting whether it works fast. I won't repeat it: read the book: you'll be glad you did. However, I will repeat the counter example, which Bill Wulf came up with. He pointed out that he spent a lot of time waiting for Scribe to run on his VAX 780. Every release of Scribe had various trivial, obscure bugs, which the adventurous user (like Bill) would wind up discovering and hacking around. Now, suppose he was given a choice: Scribe Systems could put out a flawless release: or they could put out one that ran twice as fast. Which would Bill choose? Answer: the one which saved him the most of his own time - the fast, flawed product. -- Don D.C.Lindsay Carnegie Mellon Computer Science
henry@utzoo.uucp (Henry Spencer) (06/03/90)
In article <9494@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >Many years ago, Motorola brought out an 8-bit micro which only needed >+5V power. Intel could have done the same, but they decided to beat >Motorola to market. And that is why the 8080 needed multiple power >supply voltages - a pain to designers - and also a big part of why >the 8080 was the more successful product. Time to market seems to >have been the right tradeoff, at that time and place. Nobody is arguing that heroic efforts to keep software small are justified, barring rare special situations. The unhappiness is with people who assign smallness a value of zero, and refuse to spend five minutes thinking about how to avoid gratuitous space waste in a many-hour project. To take a concrete example, C News runs almost as well on a 16-bit-address machine as it does on bigger ones. Not because we made heroic efforts to minimize space, but simply because we cared, somewhat, about memory use. There are three places where actual effort was required, and where we might not have made the effort had we not cared specifically about portability to 16-bit systems. Elsewhere, it was basically just a matter of *thinking* for a minute on encountering the temptation to throw memory at a problem. The effect on development effort and maintenance effort is negligible. Nor has this affected performance: C News runs circa 20 times as fast as B News, despite using dynamic allocation for virtually all data structures (thus removing numerous annoying fixed size limits found in B News). -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
pjg@acsu.Buffalo.EDU (Paul Graham) (06/04/90)
henry@utzoo.uucp (Henry Spencer) writes: |Nobody is arguing that heroic efforts to keep software small are justified, |barring rare special situations. The unhappiness is with people who assign |smallness a value of zero, and refuse to spend five minutes thinking about |how to avoid gratuitous space waste in a many-hour project. [cnews is then offerred as an example of careful programming.] ok, if we're going to talk about code bumming then at least stay real. this is a perfect example. cnews was written to run on small address space machines and it does so, as well as running much faster than the competition. so we see that with some care (but not heroic effort) one can write reasonable sized programs. cnews has a job and it does it quite well with modest use of resources. now i'd like to ask what would gnu emacs look like if henry wrote it but he probably wouldn't; so a question. has someone written something comparable to gnu emacs that is significantly smaller? has someone written something comparable to x11r4 that is significantly smaller? and i do mean comparable, not something along the lines of "well i think jove is comparable to emacs" or "gee, mgr does everything i need". the larger programs do seem to offer a bit more than their smaller counterparts. there are small tools and larger ones. we seem to have a choice. programs of both types seem to be written regularly. |As a user I'll take speed over| Henry Spencer at U of Toronto Zoology |features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu i think i'll still take bourbon over ice.
peter@ficc.ferranti.com (Peter da Silva) (06/04/90)
In article <27416@eerie.acsu.Buffalo.EDU> pjg@acsu.Buffalo.EDU (Paul Graham) writes: > now i'd like to ask what would gnu emacs look like if henry wrote it > but he probably wouldn't; so a question. has someone written something > comparable to gnu emacs that is significantly smaller? There are several full-featured fully programmable (as in... they include a programming language at least as capable as Gnu-lisp) editors that run in well under the full 640K available in an IBM-PC. Just what does GNU Emacs provide over things like Jove other than that? > has someone > written something comparable to x11r4 that is significantly smaller? There are several windowing systems that provide most, if not all, of the functionality of X that are significantly smaller. NeWS itself is a large package, but it keeps that size hidden from individual programs and in the server. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
chip@tct.uucp (Chip Salzenberg) (06/04/90)
According to pjg@acsu.Buffalo.EDU (Paul Graham): >now i'd like to ask what would gnu emacs look like if henry wrote it >but he probably wouldn't [...] Though I can't speak for Henry, I would hope never to write anything comparable to GNU Emacs. The day I'm responsible for creating such a huge, monolithic text editor will be the day I hang up my keyboard. GNU Emacs runs counter, not only to "program small" tactics, but to "think small" strategy. It, and most other tools available from the FSF, show no signs of the Software Tools "do one thing well" philosophy. That doesn't make them useless, obviously. It just makes them complex and resource-hungry. I expect that the above statements will attract "Richard Stallman is God, why don't you write something instead of mouthing off" flames. Well, I have written something myself. It's called Deliver. Deliver is (surprise) a mail delivery program. It, like C News, runs on on systems from the 68K and Vax to 16-bit architectures, including the '286 and PDP-11. So I've put my code where my mouth is. Also, instead of creating Yet Another Configuration File Format, I use the Bourne shell as my configuration file reader. Besides being flexible, this tactic keeps down the size and complexity of Deliver. Deliver 2.0 PL9 is available from tut.cis.ohio-state.edu. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
ian@sibyl.eleceng.ua.OZ (Ian Dall) (06/07/90)
In article <.5X3-ZB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <27416@eerie.acsu.Buffalo.EDU> pjg@acsu.Buffalo.EDU (Paul Graham) writes: >> now i'd like to ask what would gnu emacs look like if henry wrote it >> but he probably wouldn't; so a question. has someone written something >> comparable to gnu emacs that is significantly smaller? > >There are several full-featured fully programmable (as in... they include >a programming language at least as capable as Gnu-lisp) editors that run >in well under the full 640K available in an IBM-PC. Just what does GNU Emacs >provide over things like Jove other than that? Dunno much about Jove. One feature of GNU emacs which not many of its competitors offer is online documentation. I've no doubt that GNU emacs would be a *bit* smaller if totally rewritten instead of having grown over such a long period. In a running emacs it is easier to get a process size of over 2MB. Most of this is due to the number of files visited. In some ways, emacs method of reading in all of every file visited seems wasteful, but in practice it is not too bad. One alternative is to make (allow) the user two only read in "pages" of a file at a time. That is certainly workable, but is not transparent. Another alternative is to automatically read in sections of files as necessary and, if necessary, write out data to temporary files. Surprise, surprise, that is almost exactly what a virtual memory operating system does. So why not *let* the virtual memory operating system do it? (*) Why does it matter that "ps" shows a large number for the process size? The code for emacs (including pre loaded lisp) is around 600K. This doesn't seem so bad if you stop thinking of it as a text editor, and start thinking of it as a language interpreter which runs an editor among other things. A quick check shows that there is an editor for C programs written in elisp which weighs in at 12.5k (byte compiled). Seems pretty lean and mean to me! How about a compare program in 659 bytes of elisp? * This is the architecture relevant bit of the posting in case you were wondering! -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
martyi@nubbins.Eng.Sun.COM (Marty Itzkowitz) (06/08/90)
In article <671@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: > >Dunno much about Jove. One feature of GNU emacs which not many of its >competitors offer is online documentation. I've no doubt that GNU >emacs would be a *bit* smaller if totally rewritten instead of having >grown over such a long period. In a running emacs it is easier to get >a process size of over 2MB. Most of this is due to the number of files >visited. In some ways, emacs method of reading in all of every file >visited seems wasteful, but in practice it is not too bad. One >alternative is to make (allow) the user two only read in "pages" of a >file at a time. That is certainly workable, but is not transparent. >Another alternative is to automatically read in sections of files as >necessary and, if necessary, write out data to temporary files. >Surprise, surprise, that is almost exactly what a virtual memory >operating system does. So why not *let* the virtual memory operating >system do it? (*) Why does it matter that "ps" shows a large number for >the process size? > The main argument for NOT letting the virtual memory system deal with it is that the program has a much better idea of an appropriate strategy for page replacement than the OS can infer from past behavior. When the user switches to a new file the editor can infer that the pages from the previous edit can be discarded, whereas the OS will assume that if they were recently used they ought to be kept. Marty Itzkowitz
jkrueger@dgis.dtic.dla.mil (Jon) (06/08/90)
chip@tct.uucp (Chip Salzenberg) writes: >GNU Emacs ... shows no signs of the Software Tools "do one thing well" >philosophy. Counterexample: its spell checker pipes the buffer through spell and parses the output. Counterexample: its compile mode execs the make command and parses the output. Counterexample: a general facility for piping buffer regions through other tools and returning the output in another buffer. I use this all the time for awking pieces of text. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/08/90)
In article <671@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: | The code for emacs (including pre loaded lisp) is around 600K. This | doesn't seem so bad if you stop thinking of it as a text editor, and | start thinking of it as a language interpreter which runs an editor | among other things. This is a very non-unix-like approach. I have always though of UNIX as being a system in which little programs did one thing well and worked cooperatively. GNUemacs is one huge program which tryies to do everything and be everything. It might have made sense as an operating system. This is not a criticism of the approach, just a comment on its relationship to times when everything went in one place. It's like the kernel bloat, a victim of "creeping featurism." -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
chrisp@mks.com (Chris Phillips) (06/09/90)
In article <136844@sun.Eng.Sun.COM> martyi@sun.UUCP (Marty Itzkowitz) writes: >In article <671@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >> >>operating system does. So why not *let* the virtual memory operating >>system do it? (*) Why does it matter that "ps" shows a large number for > >The main argument for NOT letting the virtual memory system deal with it >is that the program has a much better idea of an appropriate strategy >for page replacement than the OS can infer from past behavior. When the >user switches to a new file the editor can infer that the pages from the >previous edit can be discarded, whereas the OS will assume that if >they were recently used they ought to be kept. > > Marty Itzkowitz This is only an argument for better interfaces between the Virtual Memory Manager and the programmer. MMAP techniques and ideas from MACH allow use of VM features without duplicating the mechanisms. Chris Phillips chrisp@mks.com -or- chrisp@telly.on.ca
barmar@think.com (Barry Margolin) (06/10/90)
In article <136844@sun.Eng.Sun.COM>, Marty Itzkowitz writes: >The main argument for NOT letting the virtual memory system deal with it >is that the program has a much better idea of an appropriate strategy >for page replacement than the OS can infer from past behavior. When the >user switches to a new file the editor can infer that the pages from the >previous edit can be discarded, whereas the OS will assume that if >they were recently used they ought to be kept. I sure hope no one adds this "feature" to my Emacs. I frequently jump back and forth between two or three editor buffers. Flushing the previous buffer from memory would pessimize this. All that LRU assumes that if they are more recently used than some other page then they should be kept in preference to that other page. Can you think of something that is likely to have been used less recently than the pages from the current and previous buffers but that is more likely to be used soon after switching to the current buffer? It is certainly true that there are applications where LRU is not a good page replacement algorithm, but I don't think this is one of them. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
ian@sibyl.eleceng.ua.OZ (Ian Dall) (06/10/90)
In article <136844@sun.Eng.Sun.COM> martyi@sun.UUCP (Marty Itzkowitz) writes: }In article <671@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: }> }> In a running emacs it is easier to get }>a process size of over 2MB. Most of this is due to the number of files }>visited. In some ways, emacs method of reading in all of every file }>visited seems wasteful, but in practice it is not too bad. One }>alternative is to make (allow) the user two only read in "pages" of a }>file at a time. That is certainly workable, but is not transparent. }>Another alternative is to automatically read in sections of files as }>necessary and, if necessary, write out data to temporary files. }>Surprise, surprise, that is almost exactly what a virtual memory }>operating system does. So why not *let* the virtual memory operating }>system do it? (*) Why does it matter that "ps" shows a large number for }>the process size? } }The main argument for NOT letting the virtual memory system deal with it }is that the program has a much better idea of an appropriate strategy }for page replacement than the OS can infer from past behavior. When the }user switches to a new file the editor can infer that the pages from the }previous edit can be discarded, It would probably be inferring incorrectly. I very frequently hop back and forth between a foo.c file and a foo.h file (for example). The only way emacs could resonably know that you didn't want a buffer again is if you killed it. Some variant of LRU is probably about as good as emacs could do. There might be something special about editors which requires a different paging strategy than the OS, but you haven't identified it. There is the potential that you might only want to access a small part of a file, in which case emacs strategy of reading it all in is a waste (of IO bandwidth rather than memory), but in practice you find the bit of the file you want by searching or scrolling, which accesses the whole file anyway. Some improvement could be made by mmap'ing files but I wouldn't expect a *big* improvement. Note that the mmap method still results in chewing a lot of virtual memory. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
don@zl2tnm.gp.govt.nz (Don Stokes) (06/11/90)
ian@sibyl.eleceng.ua.OZ (Ian Dall) writes: > In article <136844@sun.Eng.Sun.COM> martyi@sun.UUCP (Marty Itzkowitz) writes: > } > }The main argument for NOT letting the virtual memory system deal with it > }is that the program has a much better idea of an appropriate strategy > }for page replacement than the OS can infer from past behavior. When the > }user switches to a new file the editor can infer that the pages from the > }previous edit can be discarded, > > It would probably be inferring incorrectly. I very frequently hop back > and forth between a foo.c file and a foo.h file (for example). The > only way emacs could resonably know that you didn't want a buffer > again is if you killed it. I think you (and others) are missing the point. An argument along these lines went through comp.os.vms on the subject of the EDT editor vs the EVE/VAXTPU editor on VMS, myself being one of the major protagonists, along with someone who's idea of a "test" being to get the largest machine available and use it standalone (!) 8-) First a bit of background: EDT is a fairly old text editor, developed on the pdp11 under RSX (I think -- I first met the pdp11 version under RSTS/E). One of its design goals, due to the 16 bit address space, is to allow editing of files larger than available memory by editing a small buffer within a work file; I don't know the exact details. VAXTPU is the VAX Text Processing Utility. EVE is a text editor written in on VAXTPU. I will refer to this as TPU, as it is the TPU part which does the dirty work, similarly, editing with EVE is not the only thing that TPU gets used for. From most users points of view, TPU is a *lot* faster than EDT. The only place where this is never the case is starting up. TPU reads the whole file into virtual memory. A small file (say less than 500K) tends to find its way into core and stay there; searches and editing are *fast*. EDT will tend to kick its buffering strategies into play right from square one; searches tend to be a bit slower, editing within a small area is fast since it is working within its buffer. This is fine, although on a loaded I/O system, the startup time of TPU can be a little annoying (it is a bit slow starting up, even before loading the file), whereas EDT tends to be "there when you want it". Things can change radically when big files get involved, say >20MB. A search through memory results in memory being paged in as the search proceeds, and paged out behind. The next search does exactly the same thing. All this is happenning at the expense of the rest of the memory system, and is especially nasty if a lot of modifications are being made to the file. Worse, the paging is all through the system pagefile(s); as such it comes out of the user's pagefile quota. The pagefile quota is a brick wall which marks the maximum size of a file that can be edited by TPU. (The quota is necessary IMHO -- the alternative to not getting all the virtual memory you want is blowing the page files occasionally -- this is *not* nice.) EDT, on the other hand, works with a reasonably large buffer, pages data in and out of memory in large chunks. Since it uses temporary files, only the file system limits the size of the file being edited. Performance/file size is linear. What I wish would happen is that someone at DEC would realise that trying to use virtual memory entirely is *not* a great idea, and that paging stuff in and out in a semi-intelligent fashion when core runs out really isn't a stupid idea. TPU is supposed to be a Text Processing Utility, not just an editor for composing notes or programs with. Summary: Systems that rely on virtual memory are fine when the are using physical memory. After that, temporary files would remove the pagefile quota brick wall and reduce the impact on the memory system when large files get involved. Memory might be cheap, but it ain't *that* cheap. (Now who was it who said "virtual memory is a way to sell more physical memory"?) Don Stokes, ZL2TNM / / Home: don@zl2tnm.gp.govt.nz Systems Programmer /GP/ Government Printing Office Work: don@gp.govt.nz __________________/ /__Wellington, New Zealand_____or:_PSI%(5301)47000028::DON
chip@tct.uucp (Chip Salzenberg) (06/12/90)
According to ian@sibyl.OZ (Ian Dall): >The code for emacs (including pre loaded lisp) is around 600K. This >doesn't seem so bad if you stop thinking of it as a text editor, and >start thinking of it as a language interpreter which runs an editor >among other things. From bloated editor to bloated interpreter. Sure, big improvement. -- Chip, the new t.b answer man <chip@tct.uucp>, <uunet!ateng!tct!chip>
chip@tct.uucp (Chip Salzenberg) (06/12/90)
According to jkrueger@dgis.dtic.dla.mil (Jon): >chip@tct.uucp (Chip Salzenberg) writes: >>GNU Emacs ... shows no signs of the Software Tools "do one thing well" >>philosophy. > >spell checker [..] compile mode [...] piping regions I overgeneralized. Allow me to rephrase my observation: The design of GNU Emacs shows little indication of the Software Tools "do one thing well" philosophy. It is true that various add-ons for Emacs take advantage of existing Unix tools. However, Emacs' pretention, if not to do everything, at least to be an intelligent user interface for everything, belies any claim that Emacs might have made to be a "Software Tool." Emacs is a tool in the same broad sense that sticks and Space Shuttles are tools; but it is not a Software Tool. -- Chip, the new t.b answer man <chip@tct.uucp>, <uunet!ateng!tct!chip>
wayne@dsndata.uucp (Wayne Schlitt) (06/14/90)
In article <267401BF.4148@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > > The design of GNU Emacs shows little indication of the > Software Tools "do one thing well" philosophy. It is true > that various add-ons for Emacs take advantage of existing > Unix tools. However, Emacs' pretention, if not to do > everything, at least to be an intelligent user interface > for everything, belies any claim that Emacs might have > made to be a "Software Tool." > > Emacs is a tool in the same broad sense that sticks and > Space Shuttles are tools; but it is not a Software Tool. i disagree. you are looking at emacs and saying "wow, it tries to do everything". you could also look at a sun workstation and say "wow, it tries to do everything". emacs has many different parts, and you can put those parts together in very flexible ways. i think that is the whole goal of Software Tools. it has a fairly nice ascii based window system, and a bunch of tools to manipulate those windows. it has a fairly nice set of editing commands, and a bunch of tools such as keyboard macros to use those tools. it has a fairly nice interface into the unix operating system, and a bunch of seperate tools to manage unix commands. it has a fairly nice programming language that can be used to manipulate those tools. emacs has a lot of simple tools that do one thing well. that is one of the reason why it has "thousands" of commands. unlike things like awk, grep and sed, each operation is a separate command. using the tools that emacs provides you can build a nice online help facility, a nice mail handler, a nice news reader, a nice calculator, a few games and a lot of other things. yeah, from the outside, it looks like emacs is trying to do everything, but really it has a few sets of tools and a lot of things built with those tools. -wayne
nhess@gumby.us.oracle.com (Nate Hess) (06/28/90)
In article <515@van-bc.wimsey.bc.ca>, jtc@van-bc (J.T. Conklin) writes: >In article <.X144F4@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>How do you take your fancy Emacs script and run it from cron, >>or in a Makefile? >By running emacs in batch mode. >`-batch' > Batch mode is used for running programs written in Emacs Lisp > from shell scripts, makefiles, and so on. Normally the `-l' > switch or `-f' switch will be used as well, to invoke a Lisp > program to do the batch processing. Extremely useful and *very* portable. I once wrote an Emacs lisp script to massage the output of a simulator to match the output format of a tester. I had done the coding and testing of the script on Un*x box. I ftp'ed the script to the VMS machine that the tester was hooked up to, and it worked without any modifications. Had I written it in sh, csh, sed, and/or awk, it wouldn't have ported without a major rewrite. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nhess@oracle.com or ...!uunet!oracle!nhess or (415) 598-3046