jas@ernie.Berkeley.EDU (Jim Shankland) (03/29/89)
mcdonald@uxe.cso.uiuc.edu: "Portability" is a word seldom heard outside the academic discussions of Usenet. gwyn@smoke.brl.mil (Doug Gwyn): That's utter nonsense.[....] ejd@caen.engin.umich.edu (Edward J Driscoll): Sure, but there are also numerous developers who use all kinds of non-portable code in order to get the best performance they can. The majority of users probably only use a particular application on one particular system, so they're not going to be attracted by portability.... First, I have to take Doug Gwyn to task for insufficient constructive snottiness (as Padlipsky would say). "Utter nonsense" is a *big* understatement. Second, it's a canard that there is a direct tradeoff between portability and performance. In most cases, the performance impact is unnoticeable, and the (very) few cases where it makes a difference can be carefully isolated. Learning to code portably can take a little extra programmer time and discipline up front; even once the skill is learned, portable coding *may* take a little extra development time. It's worth it. Third, it's not the *users* who pay the price of non-portable code (at least, not directly); it's the software vendors. A particular user may (or may not) be interested in the product on only one system; but there are potential users of the product on all sorts of systems. The commercial importance of different platforms is constantly changing. Non-portable coding artificially limits the lifetime and the potential user community of a piece of software. Software vendors who can't be bothered to produce portable code finish last. Those are the facts. Flout them at your own (or your employer's) risk. Jim Shankland jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
daveb@geaclib.UUCP (David Collier-Brown) (03/30/89)
> mcdonald@uxe.cso.uiuc.edu: > "Portability" is a word seldom heard outside the academic discussions > of Usenet. > From article <28587@ucbvax.BERKELEY.EDU>, by jas@ernie.Berkeley.EDU (Jim Shankland): > Third, it's not the *users* who pay the price of non-portable code > (at least, not directly); it's the software vendors. To give a real-world example of this, consider Interleaf. We have one product that runs on Unix, MicroVax-VMS and Aegis, with slightly older versions of the product running on these plus the Mac OS and PoisonousComputer DOS. If we were in the business of writing inefficient code, we would NOT still be in business. If we wrote non-portable code we wouldn't be as big. In my last job I was writing code for a Vax 8650 and Suns, with a Sequent or a Amdahl/IBM lurking in the wings. Its **almost** easy. --dave (and I didn't even write TPS) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
ejd@caen.engin.umich.edu (Edward J Driscoll) (03/30/89)
As a disclaimer, I'll note that my original position was, and still is, that there are reasons to strive for maximum portability in some cases, but they have to be balanced against the costs. Jim Shankland (jas.Ernie.Berkeley.EDU) proposes that even if the users don't care about portability, vendors who don't are bound to finish last. I agree with you in some cases, but how would your statement apply to, say, the Macintosh family of computers? While the meat of the program could be written portably, I would think that the entire interface would necessarily be system-dependent. If you took portability to the extreme here, let's say by making the thing entirely keyboard oriented, you'd be laughed out of the market. People who own Macs PAID for the specific features of that machine, and they expect the software they use to exploit them. If you're willing to disregard a market of this size, you've got more money than I do! I certainly don't claim that people should program like hackers. I do claim that even a disciplined programmer can be justified in using machine-specific code -- potentially even large bodies of it, such as the entire user-interface mechanism -- and therefore has every right to know about the specific capabilities of his machine. -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
les@chinet.chi.il.us (Leslie Mikesell) (03/31/89)
In article <4255794d.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >I certainly don't claim that people should program like >hackers. I do claim that even a disciplined programmer >can be justified in using machine-specific code -- potentially >even large bodies of it, such as the entire user-interface >mechanism -- and therefore has every right to know about >the specific capabilities of his machine. Are you prepared to either abandon these applications when the machine becomes obsolete or be forced to purchase something that offers backwards compatibility? If you can afford to abandon it, then the application (and whatever advantage it gains from machine-specific code) must not be very important. I recently read that computers have an average life of about 5 years but the same applications are maintained for 10-15 years. Les Mikesell
ejd@caen.engin.umich.edu (Edward J Driscoll) (04/01/89)
In article <8079@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <4255794d.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: > >>[my defense of machine-dependant code, you've seen it] > >Are you prepared to either abandon these applications when the machine >becomes obsolete or be forced to purchase something that offers >backwards compatibility? If you can afford to abandon it, then the >application (and whatever advantage it gains from machine-specific >code) must not be very important. I recently read that computers >have an average life of about 5 years but the same applications >are maintained for 10-15 years. > >Les Mikesell Your point is certainly worth taking into consideration. My reply question would be: Are you willing to stick with teletype compatibility forever? In all honesty, if the application is that valuable then the odds are good that I would be willing to hold out for backward-compatible hardware. You also left out the option of changing the code to exploit the new hardware. If applications do not take advantage of the features of the hardware, then why pay for that hardware? You seem to be claiming that it is important for software to be backwards-compatible, but not for hardware. If the software outlasts the hardware by a factor of three, I would think the reverse would be true. [PS: We seem to be drifting a little from C. Should we move this over to the software engineering newsgroup?] -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
peter@ficc.uu.net (Peter da Silva) (04/02/89)
In article <425bf40d.b11a@falcon.engin.umich.edu>, ejd@caen.engin.umich.edu (Edward J Driscoll) writes: > Your point is certainly worth taking into consideration. My > reply question would be: Are you willing to stick with > teletype compatibility forever? Machine independent code does not imply teletype compatibility. There have been a range of machine-independent screen- and graphic- oriented environments (in order of increasing sophistication): Termcap. Curses. X-Windows. NeWS. 'vi' was designed and written on a PDP-11 running UNIX V7. The terminals available were ADM-3as, Heath-19s, and HP 2621a. I am using an 80286 running System III UNIX with a Televideo 955 terminal. And that's just the first level in the hierarchy... > In all honesty, if the > application is that valuable then the odds are good that I > would be willing to hold out for backward-compatible hardware. And so people build backwards-compatible hardware that cripples the NEXT generation of applications. Great thinking. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
ejd@caen.engin.umich.edu (Edward J Driscoll) (04/03/89)
In article <3653@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Machine independent code does not imply teletype compatibility. There have >been a range of machine-independent screen- and graphic- oriented >environments (in order of increasing sophistication): > > Termcap. > Curses. > X-Windows. > NeWS. > Ya. How many of those run on a Mac and compete with the built-in Mac routines for speed? How much of your system's resources do they consume? > >> In all honesty, if the >> application is that valuable then the odds are good that I >> would be willing to hold out for backward-compatible hardware. > >And so people build backwards-compatible hardware that cripples the NEXT >generation of applications. Great thinking. >-- Ooooh, thanks. I was hoping I would eventually get a snippy little reply. I was afraid this would go on for some time being a peaceful, intelligent discussion. Backwards compatibility does not imply crippling future applications. That your 80286 can run 8086 software does not seem to have crippled it from running system III Unix. Yet, you are willing to cripple current applications in the name of portability. You're right, 'vi' is an excellent example. I tried to teach a Mac programmer (with an MS from MIT) how to use it, and he thought it laughably brutal compared to even the most simple Mac editor. Do you really prefer h,j,k, and l to using a mouse? -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
hascall@atanasoff.cs.iastate.edu (John Hascall) (04/03/89)
In article <42674c5e.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >In article <3653@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>Machine independent code does not imply teletype compatibility. There have >You're right, 'vi' is an excellent example. I tried to teach a >Mac programmer (with an MS from MIT) how to use it, and he >thought it laughably brutal compared to even the most simple >Mac editor. Do you really prefer h,j,k, and l to using a mouse? Yes. I'm certainly not the worlds largest fan of vi, but using a mouse to do simple cursor positioning is ludicrous. Why take your hands off the keyboard just to move over a couple of spaces? By the way, I'm not being anti-mouse here (I have one on my workstation and it is great for things like cut&paste), but I think it's silly to try to do everything with it. John Hascall / ISU Comp Center
henry@utzoo.uucp (Henry Spencer) (04/03/89)
In article <42674c5e.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >... Backwards compatibility does not imply crippling future >applications. That your 80286 can run 8086 software does not seem >to have crippled it from running system III Unix... *All* the xxx86 processors, with the arguable exception of the 386, are crippled for reasonable programming by backward compatibility with the 8080, which was hurt by backward compatibility with the 8008. Intel are the world champions at being backward compatible with all previous mistakes. Try timing a program which uses an array bigger than 64KB if you want to see what I mean. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jms@hcx.uucp (Michael Stanley) (04/04/89)
In article <948@atanasoff.cs.iastate.edu>, hascall@atanasoff.cs.iastate.edu (John Hascall) writes: > In article <42674c5e.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: > > >You're right, 'vi' is an excellent example. I tried to teach a > >Mac programmer (with an MS from MIT) how to use it, and he > >thought it laughably brutal compared to even the most simple > >Mac editor. Do you really prefer h,j,k, and l to using a mouse? > > Yes. I'm certainly not the worlds largest fan of vi, but using a mouse > to do simple cursor positioning is ludicrous. Why take your hands off > the keyboard just to move over a couple of spaces? I have no doubt that if our future includes a world with a computer in every house, we aren't going to get there without providing an interface for the 'ordinary' user that is simple to use. The Mac is certainly a 'successful' step in that direction (of course the Mac borrowed many of its ideas from previous and, at least to me, less well known systems). HOWEVER, for those of us who are used to a system designed towards the needs of hackers (UNIX for example), the user interface is, after learning how to use it, quite acceptable. I'm firmly convinced that I can use vi MUCH faster than I could and comperable editor on the Mac. Sorry for posting this letter to comp.lang.c (it doesn't quite fit), but, I'm just responding to a note I saw. Michael Stanley (...!uunet!harris.cis.ksu.edu!jms@hcx)
peter@ficc.uu.net (Peter da Silva) (04/04/89)
In article <42674c5e.b11a@falcon.engin.umich.edu>, ejd@caen.engin.umich.edu (Edward J Driscoll) writes: > In article <3653@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Machine independent code does not imply teletype compatibility. There have > >been a range of machine-independent screen- and graphic- oriented > >environments (in order of increasing sophistication): > > Termcap. > > Curses. > > X-Windows. > > NeWS. > Ya. How many of those run on a Mac All of them under A/UX. > and compete with the built-in > Mac routines for speed? Depends. The built-in Mac routines do a fine job of handling graphics, but they're at the mercy of an abysmal "operating system". Try running a few programs under Multifinder and compare them to X or News under UNIX. > How much of your system's resources do > they consume? Not as much as you'd like to think. Unlike PC-ware, UNIX programs don't sit there busy-waiting on GetNextEvent. > Ooooh, thanks. I was hoping I would eventually get a snippy little reply. > I was afraid this would go on for some time being a peaceful, intelligent > discussion. That's up to you, mate. The only system I've used where backwards compatibility has not hurt it is UNIX. Something to do with portable design. Dismissing years of work with the phrase 'teletype compatibility' is really going to keep this discussion on an even keel. > Backwards compatibility does not imply crippling future > applications. That your 80286 can run 8086 software does not seem > to have crippled it from running system III Unix. Sure has. We can't run any number of programs that come out on the net thanks to the 64K segment limit. > Yet, you are willing > to cripple current applications in the name of portability. I don't think a program is crippled if it takes a second to repaint a full screen. But then I'm used to the real world... I used to use vi on a 110 baud terminal. > You're right, 'vi' is an excellent example. I tried to teach a > Mac programmer (with an MS from MIT) how to use it, and he > thought it laughably brutal compared to even the most simple > Mac editor. Show me a mac editor that will let me do :1,$s'for *\(.*\) *:= *\(.*\) *to *\(.*\) *do'for(\1 = \2; \1 <= \3; \1++)' and I'll accept that's a fair comparison. 'Vi' is more powerful in the text manipulation domain than any wysiwyg editor I've ever seen. If you really want to freak out your Mac friends, introduce them to Emacs. It's even more powerful, and even more confusing. > Do you really prefer h,j,k, and l to using a mouse? Yes. I use 'vi' on my Amiga. Actually, 'jkl;' would be even better, since they're the right-hand home keys. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
duane@cg-atla.UUCP (Andrew Duane) (04/04/89)
In article <948@atanasoff.cs.iastate.edu>, hascall@atanasoff.cs.iastate.edu (John Hascall) writes: > In article <42674c5e.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: > >You're right, 'vi' is an excellent example. I tried to teach a > >Mac programmer (with an MS from MIT) how to use it, and he > >thought it laughably brutal compared to even the most simple > >Mac editor. Do you really prefer h,j,k, and l to using a mouse? > > Yes. I'm certainly not the worlds largest fan of vi, but using a mouse > to do simple cursor positioning is ludicrous. Why take your hands off > the keyboard just to move over a couple of spaces? > By the way, I'm not being anti-mouse here (I have one on my workstation > and it is great for things like cut&paste), but I think it's silly to > try to do everything with it. > John Hascall / ISU Comp Center I agree. We modified EMACS here to use the mouse to position around in the buffer and between windows. After a couple of weeks of playing with it ("Boy, isn't this NEATO KEEN!") everyone stopped using it. I don't even know if the mouse code is even compiled into it any more. The moral: I don't know what. But it certainly doesn't make sense to use the mouse for everything. VI's h/j/k/l sucks big-time, yes. Is a mouse the the answer, no. Andrew L. Duane (JOT-7) w:(508)-658-5600 X5993 h:(603)-434-7934 Compugraphic Corp. decvax!cg-atla!duane 200 Ballardvale St. ulowell/ \laidback Wilmington, Mass. 01887 cbosgd!ima/ \cgeuro Mail Stop 200II-3-5S ism780c/ \wizvax Only my cat shares my opinions, and she's breaking in the new help.
Tim_CDC_Roberts@cup.portal.com (04/04/89)
In <2170@cveg.uucp>, jms@hcx.uucp Michael Stanley writes: > I'm firmly convinced that > I can use vi MUCH faster than I could and comperable editor on the Mac. Maybe so, but you are not comparing (or compering) apples to apples here (unintentional pun). I am firmly convinced that, given EQUAL EXPERIENCE with vi and with a comparable editor on the Mac, the average person will be much more productive with the Mac. Especially if that experience is limited, or occasional. Remember: "user friendly" is another term for "whatever the user is accustomed to." Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
les@chinet.chi.il.us (Leslie Mikesell) (04/05/89)
In article <425bf40d.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >Your point is certainly worth taking into consideration. My >reply question would be: Are you willing to stick with >teletype compatibility forever? I don't see how anyone who uses news can avoid understanding the generality of plain-text applications. If these messages had any particular hardware dependence, most of us wouldn't see them. That's not going to change anytime soon. >You also left out the option of changing the code to >exploit the new hardware. If you own the code and have the resources to rewrite it, then fine, but otherwise it would be foolish to bet your company that someone else is going to do it in time to keep you in business if you outgrow your current equipment. >If applications do not take >advantage of the features of the hardware, then why pay >for that hardware? For some purposes, you need state of the art equipment that goes beyond current standards - perhaps graphics or engineering work where the special features pay for themselves without regard for anything else. I certainly can't see anything about your message to indicate that it came from any special kind of machine... >You seem to be claiming that it is >important for software to be backwards-compatible, but >not for hardware. If the software outlasts the hardware >by a factor of three, I would think the reverse would be >true. I meant that software should take portability into consideration to avoid the need to make backwards-compatible hardware later. Look at the market that IBM has locked up as long as people run programs written for the 370 which the current machines still emulate - and that is just for fill-out-the-form functionality. >[PS: We seem to be drifting a little from C. Should >we move this over to the software engineering newsgroup?] Portability is one of the reasons for choosing the C language so perhaps the discussion is appropriate. Certainly any program being written now will likely be run in a very different environment within a few years. With the increasing use of networking, it is desirable to be able to run a program on one machine but display the output on another. This will obviously require paying attention to some standards. Les Mikesell
mustard@sdrc.UUCP (Sandy Mustard) (04/05/89)
Even if they were comparing apples to apples, this discussion no longer belongs in comp.lang.c. It is time to move it elsewhere!
crewman@bucsb.UUCP (JJS) (04/06/89)
In article Peter da Silva writes: >In article Edward J Driscoll writes: >> Your point is certainly worth taking into consideration. My >> reply question would be: Are you willing to stick with >> teletype compatibility forever? > >Machine independent code does not imply teletype compatibility. There have >been a range of machine-independent screen- and graphic- oriented >environments (in order of increasing sophistication): > > Termcap. > Curses. > X-Windows. > NeWS. Absolutely, especially X-Windows. X-windows servers run on the local machine, taking advantage of the machine's hardware. This way, the application never needs to worry about hardware-dependent features, and can be COMPLETELY portable. Each X-Windows server, however, must be written to take advantage of EVERY special feature of the hardware. It does seem, however, that such systems almost always result in a speed sacrifice, however slight. -- JJS
ejd@caen.engin.umich.edu (Edward J Driscoll) (04/06/89)
In article <8131@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: >I don't see how anyone who uses news can avoid understanding the >generality of plain-text applications. If these messages had >any particular hardware dependence, most of us wouldn't see them. >That's not going to change anytime soon. Actually, I haven't avoided understanding it, thank you very much. I don't claim that there is no such thing as a good plain-text application, nor that all code should be hardware dependant. What I claim is that a programmer can have valid reasons for using machine-dependant code. I claim that those reasons typically have something to do with making maximum use of the user's hardware, or using it in as efficient a manner as possible. I would call them justifiable if the user derives sufficient benefit from them, or, in a more commercial bent, if the user buys your product because of them. There have been plenty of convincing examples of things that make it possible to write such high-utilization, highly- efficient code in a reasonably portable manner, and I applaud them. Am I convinced that is is ALWAYS possible? No, not really. Even the people who provided such examples acknowledged that they have their limitations and costs (runs on such-and-such a group of machines, consumes X amount of resources, slows the thing down Y small amount, etc). The posters seem generally willing to live with such costs, and that's fine, if their users are willing to live with them too. What I've been saying is that such costs should not be blindly dismissed, they should be taken into account just in case it DOES make a difference to the consumer/end-user/whomever. As far as the particular example of the NEWS, it's just that. A particular example of a program where portability is indeed a primary concern. (Actually, it's only the data that has to come out portably -- and even NON-portable programs can produce portable data, but I'll humor you. :-)). BUT, if someone offered me a more sophisticated reader than 'rn', perhaps something that let me see a list of all the articles in the group and click on the ones I wanted to read, and use a scrollbar instead of the MORE filter -- I'd probably use it, even if it did use machine-dependant code to do it. (Is anyone going to offer me such a program? Please?) >If you own the code and have the resources to rewrite it, then fine, >but otherwise it would be foolish to bet your company that someone >else is going to do it in time to keep you in business if you outgrow >your current equipment. You would only be slightly less foolish to assume that said someone else is going to take their portable code and recompile for your new machine in time to keep you in business. Yes, it is going to take them less time, although they're probably going to run into a few glitches anyway unless they wrote a truly, perfectly portable program. But as long as we're posing the problem, I wouldn't gamble that just because the thing claims to be portable that I'll have a new version in my mailbox within two days. >For some purposes, you need state of the art equipment that goes beyond >current standards - perhaps graphics or engineering work where the >special features pay for themselves without regard for anything else. >I certainly can't see anything about your message to indicate that >it came from any special kind of machine... As I said, I don't believe in making sweeping judgements either way. I think there are plenty of cases of both types of programs. >I meant that software should take portability into consideration to >avoid the need to make backwards-compatible hardware later. Look >at the market that IBM has locked up as long as people run >programs written for the 370 which the current machines still >emulate - and that is just for fill-out-the-form functionality. Or, equivalently, make the hardware backwards-compatible to avoid the need to worry about it in the software now. They are both solutions to the problem. You are showing a preference for the software solution, and you seem to be in very good company. On the other hand, I see a lot of manufacturers making that backwards-compatible hardware. If you can get the software to do everything the user wants in a portable manner, good. But, if I have to use nasty code to get what the user wants, that's what I'll do, and I'll deal with the next generation of hardware when it gets here. The odds are probably good that both the hardware and the software people are worrying about how to take advantage of new technology while minimizing the impact on the currently existing systems. I just don't think you can claim that minimizing changes is ALWAYS *more* important than getting the most out of the current technology. Maybe you can claim it, but I don't think I'll believe you if you do. >Les Mikesell --- "Portable? Hell, I can carry it with one hand!" Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/08/89)
In article <4278ff03.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes: >I claim that those reasons typically have something to do with making >maximum use of the user's hardware, or using it in as efficient a manner >as possible. I think we need to be careful to reject such demands for enslavement to the computer. Almost anyone who has a serious need for computation will have to have a particular application or applications available, and the vast majority of the content of such an application lies in its software. From that viewpoint, the hardware supports the software, not vice-versa. One should therefore acquire the appropriate hardware to support the applications that the users require. This may include spiffy graphics interfaces or it may not. Taking the opposite approach leads to flashy software/hardware combos that don't meet user needs. For example, we acquired Silicon Graphics high-performance real-time 3-D color graphics workstations to support our interactive solid modeling system; however, the software works with a variety of hardware so we can choose whatever best fits the need. Not every application needs such high-powered (and rather expensive) hardware. For another example, the Locanthi & Pike "Blit" terminal and its commercial descendants (AT&T 5620 and 630) was developed to support an effective interface to the existing UNIX environment. The UNIX tools themselves remained blissfully unaware of the new hardware being used to maximally exploit them. By the way, I agree with the comment that this discussion doesn't belong in the C newsgroup. If I knew where it did belong, I'd direct follow-ups there..
mat@mole-end.UUCP (Mark A Terribile) (04/09/89)
This is drifting away from C, but ... > >Machine independent code does not imply teletype compatibility. ... > > Termcap. > > Curses. > > X-Windows. > > NeWS. > >> ... if the application is that valuable then the ... I would ... > >> hold out for backward-compatible hardware. > >And so people build backwards-compatible hardware that cripples the NEXT > >generation of applications. Great thinking. There was a story some years ago about a very large corporation (you've heard of it) that owned a large number of an obsolete IBM machine of the discrete transistor generation. They had a large amount of important application code written in FORTRAN with machine code represented as decimal constants in the FORTRAN DATA statements. IBM was coaxed (at considerable cost) into making several thousand 1-board bit-compatible machines to keep the applications running. I don't know if this story is true or not, but it does point to one way in which old, non-portable software can hobble hardware. > ... Backwards compatibility does not imply crippling future applications. > That your 80286 can run 8086 software does not seem to have crippled it from > running system III Unix. ... Yes in the name of remaining portable, Intel was pushed into a segmented architecture that inspired several megabytes of heated discussion. Per unit of silicon real estate (or per dollar) the Intel processors don't do as well as the Motorola chips that power the Sun 3. Memory management and segment handling are a nightmare because the machine is meant to support half-a-dozen mutually exclusing multiprogramming models. And additions to the instruction set must be squeezed into the holes in the existing instruction set, which may mean that a new instruction must be hidden behind a prefix (extra fetches) or may have only one or two addressing modes available (the compiler writer's nightmare which reduces the likelyhood that the instruction will actually be used, further reducing the payback on the costs of the instruction.) That the Intel processors incorporate the memory management on the processor chip ensures that if it runs on one Intel-based motherboard, it will run on any based on the same Intel processor--a great payback and a great way to get a market lock. This is the reason for the Intel market lock. > You're right, 'vi' is an excellent example. I tried to teach a > Mac programmer (with an MS from MIT) how to use it, and he > thought it laughably brutal compared to even the most simple > Mac editor. Do you really prefer h,j,k, and l to using a mouse? I sure do. I can keep my fingers over the keyboard, and work one heck of a lot faster than I can with a mouse. Even with a trackball, vi wins. (To spare argument, I accept the proposition that EMACS beats the mouse.) -- (This man's opinions are his own.) From mole-end Mark Terribile