mjr@hussar.dco.dec.com (Marcus J. Ranum) (12/03/90)
pst@ir.Stanford.EDU (Paul Traina) writes: >[...] It's natural >that sofware will grow and become more complex. CPU's have done a >good job of keeping up. I never could understand this attitude. *WHY* is it natural that software will grow? *WHY* is it natural that it become more complex? *WHY* does it have to have ever more expensive processors to run on? Because the idea of eliminating old "features" has never been considered. If cars were designed the same way as software is today, they'd all have buggy-whip holders (from "Car V1.0") and starter cranks (from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. Has anyone ever attempted any kind of studies to quantify the effect (other than on size and CPU requirements, disk requirements, and cost/seat) of adding "features" to software? I'd love to see some data about the aggregate usefulness of software *within its problem area* as features are added. What I mean by *within its problem area* is to study text editors, for example, only in terms of their functionality as text editors - rather than as LISP interpreters or news readers. :) It's been my impression that only a small percentage of any given program's functinality is ever used - possibly for each new set of "features" that are added only a comparable percentage of those are used as well, so the performance cost and monetary cost of the new "features" is largely wasted. I'd love to see a study as to what the adoption rate is of new "features" among users who are familiar with the software already, and already have developed patterns of use. If someone were to double the "features" in, say, X-window, making it half again as large and half again as slow, how long would it be before 10% of those new "features" were in active use? how long would it take for 20%, 30%? - and would it ever hit 100%? My perception, which is doubtless flawed, is that once software hits a certain basic level of functionality any additional features are simply extensions of that software's functionality outside of its problem area. In other words, once the developer has sold you all the functionality you NEED in your spreadsheet, it is extended into a rendering and visualization system as well, giving pie charts, etc, ad nauseam - and, oops, you need another 2 Meg in your machine now. The fallacy here is the pursuit of the "integrated environment" - users are unwilling to have to exit their text editor to read news (for example) - but it's chicken and egg - possibly their unwillingness is a result of the incredible startup time their bloated text editor requires. :) Add to that the confusion between different command interfaces, and it seems that every significant software system tries to evolve into being its own operating system - hogging and allocating all the resources of the host hardware. I don't quite know how it happened this way. Software, being unreal, is probably better able to fit together in modular components than just about anything else - yet I can walk to the hardware store, and buy a light switch that doesn't have an integrated timer/thermostat/LISP interpreter, and I can still build simple, elegant systems with only the functionality I need - at a reasonable cost. The designers of UNIX had it right, UNIX' modularity and simplicity made it ideal for handling just about anything except commercial success. Sorry to ramble. All disclaimers apply, of course. I don't speak for Digital, my cats, or my friends. mjr. -- If your windowing system is placing undue demands on your hardware and operating system, don't ask yourself what can be done to improve the operating system or hardware - ask yourself why you are using that windowing system. [from the programming notebooks of a heretic, 1990]
avg@hq.demos.su (Vadim G. Antonov) (12/04/90)
I can't agree more with the expressive article by Marcus J. Ranum <mjr@hussar.dco.dec.com>. I like to express my attitude to software dumps - I think the cost of finding and learning of appropriate "feature" for solving a particular problem is much higher than writing the program from scratch in "modern" commercial systems. After reaching this point in complexity growth a system will collapse under load of zillions of new misfeatures. The theory I used to discuss on my lectures is: HOW TO CREATE A DEAD SYSTEM There are *three* ways "traditional" systems used to grow: 1) Packages The old, dusty approach - if you have a problem you write a program to solve *this* problem. If the problem is a bit more complex than multiplying two 10x10 matrices you'd probably write a "package" equipped with screen-oriented input, form generator, some bells and some whistles. OK, you've made a cuspy package, let's call it "A". Some other guys have done another package, "B", for a different task. OK, some time passed and now you have to pass data from A to B in order to solve "joint" problem. You can write a converter from data in format A into data in format B: A -> Conv -> B in this case Conv tends to be a separate package and often it's less trivial task than to solve the whole problem. In such case you have to design a completely new package "A+B". In both cases you have *a new* package for a minor increase in functionality. As you can see the curve complexity * | * | * | * | ** *** +------------- functionality is exponential - and the life time of usable system is really small. Examples of package-oriented systems are: IBM OS/370, Miscrosoft MS-DOS, etc. 2) Integrated Systems The second way is to incorporate various kinds of functionality into a single super-package (so called "integrated system"). This method allows a desiger to avoid duplicating functions but tends to build huge, unmanageable (and undebugable) programs. Moreover, such systems practically does not allow users to upgrade and transform their environment to their needs. As a result designers of such systems make users to follow pre-defined paths what makes such systems *useless* for solving *new* problems. Needless to say such systems could satisfy only suits. The other source of limitations is the physical resources of computers - try to imagine one which could keep the whole Unix including all utilites in RAM :-) Unfortunately I-don't-want-to-think-but- -I-want-to-use-computer user population is a very attractive target for integrated systems and I think we'll never see the death of this approach. Complexity of a single integrated system is limited by humans' stupidity. Examples: Lotus 1-2-3, EMACS, Framework, dBASE. 3) Nested Environments The way of Unix. Idea is to split functionality to small, complete units and to use these units to build the next layer of system environment: /-----------------------------\ The advantage of this approach / user utilites \ is obvious - you need not reimplement / /-------------------------\ \ functions already existing in lower / extended set of utilites \ layers. So the complexity grow with /----------------\ (appr.) the same speed as functiona- / basic system \ lity, at least in theory. / /------------\ \ | / C-compiler \ | complexity | | /------\ | | | ** | | | kernel | | | | ** | | \------/ | | | ** | \ C library / | | ** \ \------------/ / |** \ utilites / +-------------- functionality \----------------/ Practically, nobody can design a "perfect" internal layers, thus the development of Unix includes permanent changes in inner layers like changes in C library, introducing new systems calls, etc. The catch here is that if something was injected into inner circle you'll never get rid of it - or you'll have a danger of loss of compatibility. Moreover, if the system grow in several different places you'll get several different configurations of layers. Joining environments is more or less mechanical procedure and it's quite tempting to fall into it under the pressure of suits. The result of permanent mindless joining efforts is the huge dinosaurs still keeping the old name Unix. If you want to write resonably portable program you should keep yourself as far as possible from all novations; unfortunately creators of System V made it impossible to use Unix v7 as a common denominator. WHAT SHALL WE DO? Unix is surely died, it collapsed under the load of infinite improvements, it's just another victim of feature-making; and we have to begin from scratch. I'll try to observe some possible ways to avoid complexity traps. I don't think the each of listed system-rejuvenation :-) remedies is the panacea from all troubles of life, but still: 1) Objects & Reusability I don't want to discuss the advantages of object-oriented programming here, they're well-known and discussed up beyond all recognition. 2) Environment Control We should have a mean to track *all* consequences of introducing/changing/ removing things into environments. Do you know, for example, what will happen if you'd remove awk from /bin of Unix v7? I know only few people who knows that tar will fail at option "u"! Such means of environment control should be transparent and uniformed for all system parts including libraries, directories, includes, system calls etc. Merging and synchronizing of changing environments, keeping tracks of changes, etc is also a matters of the environment control. 3) Parallel Environments A system of the new generation should support co-existence of several different environments (or different versions of an environment) - it'd make introducing changes sufficiently simplier because old programs could run in the *old* environment. Of course, virtual machine is not an appropriate way to do such things; there should be a regular and simple way to communicate between different environments. Object approach could provide such a feature and environment control could help to choose the minimal environment required to run the old program. A really complicated mindset cannot be limited to one language, now it's quite obvious, so I think multiple environments could provide much more flexibility to creative programming. 4) Functional Completeness IMHO the ultimate weapon against complexity is the design of functionally complete interfaces to units of a system. If you have one you can be sure nobody will ever change it - simply because there is no need to do it. If such a unit is *really* functionally complete you simply could not invent how to improve it (aside of subjective prefernces or efficiency reasons). Of course, design of complete systems is much more complicated task than conventional programming and requires sufficient incresing of thinking/coding ratio; hm, it's not evidient to suits that the better programmer writes *less* (and lesser) programs than a bad one (you should compare results, not source code lines, megabytes, features, hours of work, what else?) Why we say "he's a hero, he wrote a 100000 lines program!" instead of "100000 lines? It could be done in dozen thousands!" Several years ago I decided I ought to try to put my theory in practice and tried to design a functionally complete set of system calls. The result was *really* amazing: the full-scale prototype of the kernel is about 4000 lines of C source code (including comments, huh). As a side result I've found a way to control non-digital machines in object-oriented style (really dunno how can it be used ;-). A description of this system was published in ACM SIGOPS Op. Sys. Review, vol 24, N 3 (July 1990), pp 22-39. Unfortunately I have to earn my family doing much boring things and had no chance to touch this project for the year. I'd be very glad if someone would use it. (Don't ask me about sources, it's a pretty raw mess and do not like idea to show it to public; my goal was not to write a program but to check my idea; and it surely have to be redesigned). Vadim Antonov DEMOS, Moscow, USSR PS. Excuse me for my poor English, huh, I'm a Russian after all.
dlw@odi.com (Dan Weinreb) (12/04/90)
In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
Because the idea of eliminating old "features" has never been
considered.
If you had customers with working programs depending on old features,
you wouldn't consider it either.dlw@odi.com (Dan Weinreb) (12/04/90)
In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
I'd love to see some data
about the aggregate usefulness of software *within its problem area*
as features are added.
It depends on what your perception of the problem area is. The new
features aren't really useless. They only seem useless because they
are not useful to you; they're useful to someone else.
Yes, it's true that software should be built so that features useful
to someone else wouldn't slow down performance for those who do not
use them. Unfortunately, it's usually harder to do this than it seems
as if it ought to be. But also many people don't try hard enough, and
could and should do a better job. Several companies have suffered
in the marketplace for doing this badly.jet@karazm.math.uh.edu (J. Eric Townsend) (12/04/90)
In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >If cars were designed the same way as software is today, >they'd all have buggy-whip holders (from "Car V1.0") and starter cranks >(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. Ahem. My state-of-the-art 1969 VW Bug is slotted for a starter crank. (Dunno about Supers, and my Karman Ghia isn't crankable.) Now where I'll *find* a crank for it is another story... :-) -- J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU Systems Mangler - UH Dept. of Mathemagics - (713) 749-2120 Skate (UNIX || AmigaDos) "This meme's for you..."
gpvos@cs.vu.nl (Gerben 'P' Vos) (12/04/90)
jet@karazm.math.uh.edu (J. Eric Townsend) writes: >In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >>If cars were designed the same way as software is today, >>they'd all have buggy-whip holders (from "Car V1.0") and starter cranks >>(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. >Ahem. My state-of-the-art 1969 VW Bug is slotted for a starter crank. >(Dunno about Supers, and my Karman Ghia isn't crankable.) >Now where I'll *find* a crank for it is another story... :-) Try the one you get with a Citroen 2CV... - Gerben. -- --- Gerben Vos - Aconet: BIGBEN!Gerben Vos - Internet: gpvos@cs.vu.nl ---- Definition of intelligence: Anything a human does better than a computer
mitchell (Bill Mitchell) (12/04/90)
In article <1990Dec4.020605.10498@lavaca.uh.edu> jet@karazm.math.uh.edu (J. Eric Townsend) writes: >In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >>If cars were designed the same way as software is today, >>they'd all have buggy-whip holders (from "Car V1.0") and starter cranks >>(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. > >Ahem. My state-of-the-art 1969 VW Bug is slotted for a starter crank. >(Dunno about Supers, and my Karman Ghia isn't crankable.) > >Now where I'll *find* a crank for it is another story... :-) > This stirred up memories of my red 196x Sunbeam Alpine, which was not only slotted for a crank but came equipped with one. I manually cranked the car over on more than one occasion (I don't think it had magnetos, so the battery had to be live enough to provide spark). Kind of like using ex commands in vi, eh? -- mitchell@mdi.com (Bill Mitchell)
apm@hpopd.HP.COM (Andrew Merritt) (12/05/90)
/ hpopd:comp.unix.internals / jet@karazm.math.uh.edu (J. Eric Townsend) / 2:06 am Dec 4, 1990 / In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >If cars were designed the same way as software is today, >they'd all have buggy-whip holders (from "Car V1.0") and starter cranks >(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. Ahem. My state-of-the-art 1969 VW Bug is slotted for a starter crank. (Dunno about Supers, and my Karman Ghia isn't crankable.) Now where I'll *find* a crank for it is another story... :-) -- Well, on my Citroen 2CV6, the wheel-nut wrench doubles as the starting handle. I have only used it once on my present car, but a few times on the one I had before that. Andrew
ronnie@mindcraft.com (Ronnie Kon) (12/05/90)
In article <1990Dec4.020605.10498@lavaca.uh.edu> jet@karazm.math.uh.edu (J. Eric Townsend) writes: >In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: Blah blah blah. This thread, which started with a tenuous enough connection to unix internals, has really pretty much moved beyond the pale. Please continue the discussion in alt.folklore.computers. Thanks. Ronnie -- ------------------------------------------------------------------------------- Ronnie B. Kon | "I don't know about your brain, but kon@groundfog.stanford.edu | mine is really bossy." ...!{decwrl,ames}!mindcrf!ronnie | -- Laurie Anderson
mau%alice.CSELT.STET.IT@icnucevm.cnuce.cnr.it (12/05/90)
On 4 Dec 90 15:03:22 GMT, Bill Mitchell ( mitchell@mdi.com ) writes: [talking about cranks...] > I manually > cranked the car over on more than one occasion (I don't think it had > magnetos, so the battery had to be live enough to provide spark). > > Kind of like using ex commands in vi, eh? why? I always use ex commands in vi, maybe because I do not know enough vi commands :-) but I never cranked a car. Let's start a committee against FORTRAN-2 features, and keep good old vi alive... .mau. #include </std/disclaimer>
greywolf@unisoft.UUCP (The Grey Wolf) (12/15/90)
In article <1990Dec2.202402.21977@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >pst@ir.Stanford.EDU (Paul Traina) writes: > >>[...] It's natural >>that sofware will grow and become more complex. CPU's have done a >>good job of keeping up. > > I never could understand this attitude. > > *WHY* is it natural that software will grow? *WHY* is it natural >that it become more complex? *WHY* does it have to have ever more >expensive processors to run on? If for no other reason, *it will run FASTER*! Eliminating the features will make it do so, but think what the response time will be if we take the stripped down version and run it on a faster processor! > > Because the idea of eliminating old "features" has never been >considered. If cars were designed the same way as software is today, >they'd all have buggy-whip holders (from "Car V1.0") and starter cranks >(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on. Or, worse yet, the idea of feeping creaturism seems to have truly per- vaded our working environment (I'm guilty -- I use my own feature-laden version of csh (which still runs faster than ksh!, but that's another soapbox)). > > What I mean by *within its problem area* is >to study text editors, for example, only in terms of their functionality >as text editors - rather than as LISP interpreters or news readers. :) Agreed! (EMACS is *way* too klunky to justify its existence, even on a fast machine.) > The fallacy here is the pursuit of the >"integrated environment" - users are unwilling to have to exit >their text editor to read news (for example) - but it's chicken >and egg - possibly their unwillingness is a result of the incredible >startup time their bloated text editor requires. :) We have a solution to this which, even on windowing workstations, works quite well. It's called "job control". (You don't have it? Implement it -- it's a great exercise in programming!) > I don't quite know how it happened this way. Software, >being unreal, is probably better able to fit together in modular >components than just about anything else - yet I can walk to >the hardware store, and buy a light switch that doesn't have an >integrated timer/thermostat/LISP interpreter, and I can still >build simple, elegant systems with only the functionality I >need - at a reasonable cost. The designers of UNIX had it right, >UNIX' modularity and simplicity made it ideal for handling just >about anything except commercial success. How about a reasonable archiver which provides a table of contents at the beginning of the tape instead of making one read through the entire tape to find out what's there, and without having to dump an entire filesystem...? (and make it tar compatible! :-) (it's in the works!) > >mjr. >-- > If your windowing system is placing undue demands on your hardware >and operating system, don't ask yourself what can be done to improve the >operating system or hardware - ask yourself why you are using that windowing >system. [from the programming notebooks of a heretic, 1990] Because all the ones that run faster don't provide a suitably flexible interface for my tastes. -- On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to invoke ninth-level magic, instead of taking the time to climb the other (quite essential) thirteen levels so they can do this properly? ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf
datri@convex.com (Anthony A. Datri) (12/15/90)
>Agreed! (EMACS is *way* too klunky to justify its existence, even on >a fast machine.) -rwxr-xr-x 1 root 122880 Aug 9 22:49 /usr/local/bin/microemacs* -rwxr-xr-x 7 root 155648 Feb 8 1990 /usr/ucb/vi* The existence of vi is therefore also unjustified. --
zap@savage.UUCP (Zap Savage) (12/16/90)
In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >Or, worse yet, the idea of feeping creaturism seems to have truly per- >vaded our working environment. As an aside, relating to "feeping creaturism", my old boss had a problem with never quite finishing a program or a repair. He'd always see some other neat thing he could do. Still does, I guess. He called it "creeping eloquence". Zap --- Zap Savage, Savage Research, Inc. "There's a fine line between fishing and standing on the shore like a fool." -Steven Wright "It'll never fly, Orville." -Wilbur Wright
ph@sparc3.ama.caltech.edu (Paul Hardy) (12/20/90)
In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > > What I mean by *within its problem area* is >to study text editors, for example, only in terms of their functionality >as text editors - rather than as LISP interpreters or news readers. :) Agreed! (EMACS is *way* too klunky to justify its existence, even on a fast machine.) and then writes > >mjr. >-- > If your windowing system is placing undue demands on your hardware >and operating system, don't ask yourself what can be done to improve the >operating system or hardware - ask yourself why you are using that windowing >system. [from the programming notebooks of a heretic, 1990] Because all the ones that run faster don't provide a suitably flexible interface for my tastes. That would be exactly my argument for emacs, with its interfaces for text, programming language sensitivity, help menus, spreadsheet, mail, news, etc., etc.! Not to mention a "windowing system" that existed before bitmapped screens became commonplace. Followups to alt.religion.computers, please! --Paul
tomr@ashtate (Tom Rombouts) (01/04/91)
In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >-- >On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to >invoke ninth-level magic, instead of taking the time to climb the other >(quite essential) thirteen levels so they can do this properly? If they are at the fourth-level, and seek the ninth-level, doesn't that leave five, and not thirteen, other levels for them to climb? :-) Sorry to be picky, but after all, this _is_ the 'Net, you know.... Tom Rombouts Torrance Techie tomr@ashtate.A-T.com V:(213)538-7108 Filler: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX( that should be enough....)XXX
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/05/91)
In article <1991Jan4.024914.12226@ashtate> tomr@ashtate (Tom Rombouts) writes: > In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > >On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to > >invoke ninth-level magic, instead of taking the time to climb the other > >(quite essential) thirteen levels so they can do this properly? > If they are at the fourth-level, and seek the ninth-level, doesn't that > leave five, and not thirteen, other levels for them to climb? :-) > Sorry to be picky, but after all, this _is_ the 'Net, you know.... Faced with the strange conjunction of ``ninth,'' ``level,'' and ``magic,'' you might guess that the poster was referring to a stylized system of organizing magical forces into numeric levels---a system with which he expected many readers to be familiar. You might also guess that the system assigns different levels to ``wizards'' (whoever they might be) and magic---perhaps in a way that an N-th level wizard could invoke magic of level at most (N+1)/2, or some similar relation so that 17-th level wizards (17 is 4 plus 13) could invoke 9-th level magic. You might also guess that the poster took the time to get his analogy correct in such a short, pointed article, so that your adjustment was not needed. ---Dan
mikes@ingres.com (Mike Schilling) (01/06/91)
From article <1991Jan4.024914.12226@ashtate>, by tomr@ashtate (Tom Rombouts): > In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >>-- >>On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to >>invoke ninth-level magic, instead of taking the time to climb the other >>(quite essential) thirteen levels so they can do this properly? > > If they are at the fourth-level, and seek the ninth-level, doesn't that > leave five, and not thirteen, other levels for them to climb? :-) They're fourth-level wizard-wannabees, i.e. level -4. This is 13 levels below 9, nicht wahr? Even a level 1 should figure that out :-) ---------------------------------------------------------------------------- mikes@rtech.com = Mike Schilling, ASK Corporation, Alameda, CA Just machines that make big decisions, Programmed by fellows with compassion and vision. -- Donald Fagen, "IGY"
mju@mudos.ann-arbor.mi.us (Marc Unangst) (01/07/91)
tomr@ashtate (Tom Rombouts) writes: > If they are at the fourth-level, and seek the ninth-level, doesn't that > leave five, and not thirteen, other levels for them to climb? :-) Nope...There are two different "levels" here. "Character" level, which is that the fourth level refers to. And "spell" level, which is what the ninth level refers two. In AD&D, magic-user characters don't get 9th-level spells until the 17th level of character advancement. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
marc@skypod.uucp (Marc Fournier) (01/08/91)
In article <1991Jan4.024914.12226@ashtate> tomr@ashtate (Tom Rombouts) writes: >In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >>-- >>On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to >>invoke ninth-level magic, instead of taking the time to climb the other >>(quite essential) thirteen levels so they can do this properly? > >If they are at the fourth-level, and seek the ninth-level, doesn't that >leave five, and not thirteen, other levels for them to climb? :-) > Sorry to sound stupid, but what game is it that these gentlemen are talking about? The subject states that it was a comment about the Jargon file, but the Jargon file looks just like a dictionary to me. Someone please help me by explaining? -- -------------------------------------------------- Marc Fournier | marc@skypod.uucp --------------------------------------------------
greywolf@unisoft.UUCP (The Grey Wolf) (01/10/91)
In article <1991Jan4.024914.12226@ashtate> tomr@ashtate (Tom Rombouts) writes: >In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >>-- >>On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to >>invoke ninth-level magic, instead of taking the time to climb the other >>(quite essential) thirteen levels so they can do this properly? > >If they are at the fourth-level, and seek the ninth-level, doesn't that >leave five, and not thirteen, other levels for them to climb? :-) No, actually. I used to play (ahem...er...) D&D, and according to the guidelines (they're too lame to be used as rules (flames > /dev/null 2>&1)) a wizard must achieve seventeenth level before one can cast a ninth-level spell. (Level of magic ability = ((level of player * 2) - 1)). > >Sorry to be picky, but after all, this _is_ the 'Net, you know.... Well, you know what they say: If you're right 90% of the time, nobody is going to quibble over the other 3%... > > >Tom Rombouts Torrance Techie tomr@ashtate.A-T.com V:(213)538-7108 >Filler: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX( that should be enough....)XXX -- On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to invoke ninth-level magic, instead of taking the time to climb the other (quite essential) thirteen levels so they can do this properly? ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf
greywolf@unisoft.UUCP (The Grey Wolf) (01/10/91)
In article <1991Jan8.001357.20849@skypod.uucp> marc@skypod.uucp (Marc Fournier) writes: #In article <1991Jan4.024914.12226@ashtate> tomr@ashtate (Tom Rombouts) writes: #>In article <3276@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: #>>-- #>>On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to #>>invoke ninth-level magic, instead of taking the time to climb the other #>>(quite essential) thirteen levels so they can do this properly? #> #>If they are at the fourth-level, and seek the ninth-level, doesn't that #>leave five, and not thirteen, other levels for them to climb? :-) #> # #Sorry to sound stupid, but what game is it that these gentlemen are #talking about? The subject states that it was a comment about #the Jargon file, but the Jargon file looks just like a dictionary #to me. Someone please help me by explaining? That (hopefully) wasn't the entire article! (I'll be very embarrassed if it is -- it's my (four-line-maximum) signature!) # # -- On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to invoke ninth-level magic, instead of taking the time to climb the other (quite essential) thirteen levels so they can do this properly? ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf