amolitor@eagle.wesleyan.edu (04/17/91)
In article <26550@adm.brl.mil>, preece@urbana.mcd.mot.com (Scott E. Preece) writes: > X is relatively > immature technology and its authors are only beginning to switch from > constructing new functionality to examining the details of the > implementation and its operating characteristics. This is hardly a > startling life-cycle. You *can't* realistically evaluate the > performance characteristics of a product like X until its functionality is > complete enough that to allow review of real applications in real use. > This is largely accurate, but philosophically flawed, IMO. Software development cycles should not proceed as: add every concievable feature, then tune. Something more like: get something minimally useful, tune, then see if something more is needed. If not, STOP. If more features are needed, add them, and re-tune. > Most of the critics have failed to suggest what they would have liked to > see as a windowing interface instead of X. Very well. I want xterms. Nothing more. I want to be able to pop open 80x24 windows that emulate vt100s correctly. If you want to get fancy, I might want to allow window dimensions to be specified at the time they are opened. I agree that being able to resize windows is nice, but I this is a fairly serious hit in terms of client complexity. At *most* I want be applications to find out window size at startup, and not have to worry about the thing changing size. Oh, the windowing system should provide backing store. I don't want to deal with exposure events and such, and in this context, there's no reason I should. I suppose, to be nice, such a windowing system should have hooks to allow it to interoperate gracefully with other systems providing graphics support and so on. I rather suspect that this windowing system could be written to be terrifyingly fast, and to consume negligable resources. I further suspect that it would provide a high percentage of the *useful* functionality of X. No, I won't be writing this any time soon, and no, I have no idea what the right way to lay out the internals is. On the other hand, if someone else writes it, and makes it 10 times as fast an 1/10 as resource hungry as X, you *bet* I'll use it. Andrew > scott > > -- > scott preece > motorola/mcg urbana design center 1101 e. university, urbana, il 61801 > uucp: uunet!uiucuxc!udc!preece, arpa: preece@urbana.mcd.mot.com > phone: 217-384-8589 fax: 217-384-8550
barmar@think.com (Barry Margolin) (04/17/91)
In article <1991Apr16.210107.41817@eagle.wesleyan.edu> amolitor@eagle.wesleyan.edu writes: >Software development cycles should not proceed as: add every concievable >feature, then tune. Something more like: get something minimally useful, >tune, then see if something more is needed. If not, STOP. If more >features are needed, add them, and re-tune. I never used anything earlier than X10 myself, but I assume the first few versions of X were minimally useful, and eventually they decided all the features of X11 were needed. The X developers were not just adding features for their own sake; they were trying to solve real problems. >> Most of the critics have failed to suggest what they would have liked to >> see as a windowing interface instead of X. > > Very well. I want xterms. Nothing more. I want to be able to pop >open 80x24 windows that emulate vt100s correctly. So get yourself a Macintosh and run NCSA Telnet. I don't think users would like to waste the power of bit-mapped workstations for such simple use, though. X was developed as a way to implement portably the kinds of applications that were already being run on Macintoshes, Suns, Lisp Machines, Xerox workstations, etc. The networking part was presumably a response to the problem that applications often need to run on computers that are a long way from the user (e.g. on a machine at some remote supercomputer center). > I rather suspect that this windowing system could be written to be >terrifyingly fast, and to consume negligable resources. I further suspect >that it would provide a high percentage of the *useful* functionality of X. I don't think our image processing and animation people would consider a bunch of 24x80 terminal emulators to be a "high percentage of the useful functionality of X." -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
byron@archone.tamu.edu (Byron Rakitzis) (04/17/91)
In article <1991Apr17.040918.12203@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Apr16.210107.41817@eagle.wesleyan.edu> amolitor@eagle.wesleyan.edu writes: >>Software development cycles should not proceed as: add every concievable >>feature, then tune. Something more like: get something minimally useful, >>tune, then see if something more is needed. If not, STOP. If more >>features are needed, add them, and re-tune. > >I never used anything earlier than X10 myself, but I assume the first few >versions of X were minimally useful, and eventually they decided all the >features of X11 were needed. The X developers were not just adding >features for their own sake; they were trying to solve real problems. > In all fairness to the designers of the X protocol, it was one of their stated principles "which guided us through the early X design: Do not add new functionality unless an implementor cannot complete a real application without it." [From Sheifler, Gettys, Newman, "X Window System C Library and Protocol Reference, p.xxi] Still, it's a pity that the X protocol itself is so terrible. >> I rather suspect that this windowing system could be written to be >>terrifyingly fast, and to consume negligable resources. I further suspect >>that it would provide a high percentage of the *useful* functionality of X. > >I don't think our image processing and animation people would consider >a bunch of 24x80 terminal emulators to be a "high percentage of the useful >functionality of X." I don't think "image processing and animation" people would consider X to be a satisfactory solution to their graphics problems either! Let's face it: X was not designed with high performance graphics in mind. Look at the colormap fiasco, and the fact that every call to the X server is effectively a context switch. You just can't make good graphics code work under such poor conditions. I think the successor to X will somehow allow dynamic reconfiguration of the server (via, say, an interpreted language) so that the network/context switch bottleneck can be reduced. -- To reveal art and conceal the artist | Byron Rakitzis, Texas A&M. is art's aim. -- Oscar Wilde. | byron@archone.tamu.edu
andy@research.canon.oz.au (Andy Newman) (04/17/91)
In article <14820@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >I think the successor to X will somehow allow dynamic reconfiguration >of the server (via, say, an interpreted language) so that the network/context >switch bottleneck can be reduced. With the advances in dynamic linking a graphics server could also allow compiled code to be used, dynamic protocol extensions with the speed of compiled code. Main disadvantage compared to an interpreted language would be the increased chances of crashing the graphics/windows server but there could be ways around that with more sophisticated memory management on a per process basis. Either way a dynamically re-configurable (i.e. extensible) server makes a lot more sense than the current X11 setup (pity NeWS uses a PostScript-like language). -- Andy Newman (andy@research.canon.oz.au) Canon Info. Systems Research Australia "X: 2. An over-sized, over-featured, over-engineered window system developed at MIT and widely used on UNIX systems." from the jargon file.
leh@atlantis.cis.ufl.edu (Les Hill) (04/17/91)
In article <1991Apr16.210107.41817@eagle.wesleyan.edu>, amolitor@eagle.wesleyan.edu writes: |> In article <26550@adm.brl.mil>, preece@urbana.mcd.mot.com (Scott E. Preece) writes: |> > Most of the critics have failed to suggest what they would have liked to |> > see as a windowing interface instead of X. |> |> Very well. I want xterms. Nothing more. I want to be able to pop |> open 80x24 windows that emulate vt100s correctly. If you want to get fancy, |> I might want to allow window dimensions to be specified at the time they |> are opened. ...blah blah blah... |> Andrew Why don't you just stack a couple of vt100s on your desk and save your inane indictments of X? Les -- Extraordinary crimes against the people and the state have to be avenged by agents extraordinary. Two such people are John Steed -- top professional, and his partner, Emma Peel -- talented amateur; otherwise known as "The Avengers." INTERNET: leh@ufl.edu UUCP: ...!gatech!uflorida!leh BITNET: vishnu@UFPINE
jb107@prism.gatech.EDU (Jim Burns) (04/17/91)
in article <1991Apr16.210107.41817@eagle.wesleyan.edu>, amolitor@eagle.wesleyan.edu says: > Very well. I want xterms. Nothing more. I want to be able to pop > open 80x24 windows that emulate vt100s correctly. If you want to get fancy, Then get screen(1). Frankly, the only time I use X is when it is the ONLY windowing system available to me. Of course if I was a graphics programmer I'd be SOOL, as X and Windows/PM/MAC are the only games in town. -- BURNS,JIM (returned student & GT Research Institute staff member) Georgia Institute of Technology, Georgia Tech Station 30178, Atlanta Georgia, 30332 | Internet: jb107@prism.gatech.edu uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jb107
mh@roger.imsd.contel.com (Mike Hoegeman) (04/18/91)
In article <14820@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: > > >I think the successor to X will somehow allow dynamic reconfiguration >of the server (via, say, an interpreted language) so that the network/context >switch bottleneck can be reduced. Gee... This sounds a lot like NeWS does'nt it? -mike hoegeman , mh@awds.imsd.contel.com
byron@archone.tamu.edu (Byron Rakitzis) (04/18/91)
In article <1991Apr17.194141.17315@wlbr.imsd.contel.com> mh@roger.imsd.contel.com (Mike Hoegeman) writes: >In article <14820@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >>I think the successor to X will somehow allow dynamic reconfiguration >>of the server (via, say, an interpreted language) so that the network/context >>switch bottleneck can be reduced. >Gee... This sounds a lot like NeWS does'nt it? NeWS actually has some good ideas in it; I would not dispose of it in a single statement like that. However, I don't think the answer to X is NeWS. But it's clear that if you nail your window protocol in stone (as X does) and that protocol operates at a very low level (as X's does) then the bottleneck for high performance graphics will be at the network/protocol level. If you do not allow dynamic reconfiguration of the window system, then every time you need to add a feature to the window system, you have to recompile the window code. This may or may not be an acceptable solution for you. I don't think it is. The interpreted language I have in mind is not PostScript. The language that is interpreted (or compiled on the fly for performance) should be "safe", i.e., it should not be possible for any single client to starve the resources of the window system, or to cause the window system to crash. If you do not use a "safe" language, then either 1) you will have to put up with the above 2 faults, or 2) you will have to write a window "kernel" that manages client processes in a protected environment with separate address spaces etc. The latter solution implies some fancy hardware, and I would like to see this window system written for all sorts of hardware, e.g., X terminals, or as user processes under Unix. -- To reveal art and conceal the artist | Byron Rakitzis, Texas A&M. is art's aim. -- Oscar Wilde. | byron@archone.tamu.edu
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/18/91)
>Gee... This sounds a lot like NeWS does'nt it?
NeWS is a pretty cool idea, but I just can't appreciate adding
PostScript to a network-based window system. Before everyone jumps on
me, let me explain:
do an "lpq" on a machine with a few PostScript printers.
PostScript can produce spiffy images, for sure, but it's just
too easy to produce 100K worth of glop to print a page. The idea of
*THAT* as the imaging model behind my window systems makes me afraid,
very afraid. *USUALLY* I realize that having PostScript in the window
system is a savings, but you have to make sure that your applications
are not stupid about doing the PostScript equivalent of bells and
whistles.
mjr.barnett@grymoire.crd.ge.com (Bruce Barnett) (04/19/91)
In article <1991Apr18.014319.8272@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > PostScript can produce spiffy images, for sure, but it's just > too easy to produce 100K worth of glop to print a page. This is one reason why most well written PostScript code downloads routines to the printer to reduce the bytes transferred. Writing efficient PostScript is not trivial. But at least you have that option. There is another advantage of the Stencil/paint model over the raster-op model: It is possible to pipeline the rendering, and even render in parallel. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
mh@roger.imsd.contel.com (Mike Hoegeman) (04/19/91)
In article <1991Apr18.014319.8272@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >>Gee... This sounds a lot like NeWS does'nt it? > NeWS is a pretty cool idea, but I just can't appreciate adding >PostScript to a network-based window system. Before everyone jumps on >me, let me explain: > do an "lpq" on a machine with a few PostScript printers. > PostScript can produce spiffy images, for sure, but it's just >too easy to produce 100K worth of glop to print a page. The idea of >*THAT* as the imaging model behind my window systems makes me afraid, >very afraid. *USUALLY* I realize that having PostScript in the window === >system is a savings, but you have to make sure that your applications >are not stupid about doing the PostScript equivalent of bells and >whistles. === This is kind of a weak argument isn't it? You can make the same assertion about any language. Frugality is a virtue I agree, but using PostScript as an imaging model does not instantly turn you into a glutton. It's really a pretty reasonable language as interpreters go. I do agree with you though that there is some pretty lame postscript code which is output by some applications.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/19/91)
In article <28063@uflorida.cis.ufl.EDU> leh@atlantis.cis.ufl.edu (Les Hill) writes:
Why don't you just stack a couple of vt100s on your desk and save your inane indictments of X?
Takes to much space. If only I could convince AAAs to share a keyboard...
<mike
--
The sun is shining slowly. Mike Meyer
The birds are flying so low. mwm@pa.dec.com
Honey, you're my one and only. decwrl!mwm
So pay me what you owe me.allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/19/91)
As quoted from <1991Apr16.210107.41817@eagle.wesleyan.edu> by amolitor@eagle.wesleyan.edu: +--------------- | Very well. I want xterms. Nothing more. I want to be able to pop | open 80x24 windows that emulate vt100s correctly. If you want to get fancy, | | I suppose, to be nice, such a windowing system should have hooks to | allow it to interoperate gracefully with other systems providing graphics | support and so on. | | I rather suspect that this windowing system could be written to be | terrifyingly fast, and to consume negligable resources. I further suspect | that it would provide a high percentage of the *useful* functionality of X. +--------------- Sounds suspiciously like MGR. (Well, MGR doesn't emulate a VT100... but it could be modified to parse ANSI escapes instead of its own.) It doesn't have all the fancy libraries and such, but it has the basic functionality needed to implement them. The MGR binary and support stuff (mainly fonts, icons, and sample applications) fits in 1/2 meg under SCO UNIX. (It's slightly larger right now, since I compiled it with -g to find the last few bugs in my port.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
greg@cheers.Bungi.COM (Greg Onufer) (04/19/91)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >>In article <28063@uflorida.cis.ufl.EDU> Les Hill writes: >> Why don't you just stack a couple of vt100s on your desk and save your >> inane indictments of X? >Takes to much space. If only I could convince AAAs to share a keyboard... At least if Les Hill used vt100's he'd most likely produce postings with less than 80 characters per line... it's only courtesy, after all. Who's forcing anyone to use X? If you don't like, don't use it. I use it not for it's technical merits, but because I hate SunView and X was easy to obtain, easy to build, and relatively easy to use. It also helps that there are some nifty (and some not-so-nifty) tools that are publicly available for it. It even almost runs acceptably fast on my Sun-2 where it is used mostly to have multiple terminal windows open.. If X is hated so much, where are the alternatives? Could someone please post a list of the alternative, "better" windowing systems? Please indicate the platforms each one runs on... Cheers!greg
wjb@cogsci.cog.jhu.eduBill Bogstad (04/19/91)
In article <28063@uflorida.cis.ufl.EDU> leh@atlantis.cis.ufl.edu (Les Hill) writes: > Why don't you just stack a couple of vt100s on your desk and save > your inane indictments of X? You can't cut and paste text between separate vt100 terminals. Bill Bogstad
chip@tct.com (Chip Salzenberg) (04/23/91)
According to leh@atlantis.cis.ufl.edu (Les Hill): >Why don't you just stack a couple of vt100s on your desk and save your >inane indictments of X? Actually, I use a '386 PC that runs a Telnet implementation with up to nine sessions, among which I select with Alt-F#. Quite friendly for my money, and loads more useful than an X terminal. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
rbj@uunet.UU.NET (Root Boy Jim) (04/23/91)
In <=V6&^Q_.19037@cheers.Bungi.COM> greg@cheers.Bungi.COM (Greg Onufer) writes: > >At least if Les Hill used vt100's he'd most likely produce postings with >less than 80 characters per line... it's only courtesy, after all. Yeah. I hate this too. >If X is hated so much, where are the alternatives? The sad thing is that there aren't many. Never having used MGR, I can't really rate it. It probably doesn't do very much, but people seem to think it does it reasonably well. NeWS seems like it uses the right model, but people say it's really too slow and big to build terminals out of. And perhaps the language is too awkward; postfix if's are hard to read. As one who threw many logs onto this fire, I suppose I should reveal my purpose. One of them was to simply carp about the trials and tribulations I experienced when I attempted to implement an X protocol session recorder and playback program. During this, I learned many nasty things about the protocol. You could argue that it was not designed for this purpose, and strictly speaking, it was not. However, truly robust software often finds uses for which it was not designed. But I suppose my real purpose in bashing X, just like my bashing on NFS, is to warn people who don't really know better against following along blindly with the crowd. What I am after is for people to examine the issues, to look beneath the surface and consider the issues. To those who have done that and still support X, well, someone has to work on it. Sure, both X and NFS are useful, even worth using. But let us tell the truth about their warts. -- [rbj@uunet 1] stty sane unknown mode: sane
peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
In article <1991Apr17.040918.12203@Think.COM> barmar@think.com (Barry Margolin) writes: > I never used anything earlier than X10 myself, but I assume the first few > versions of X were minimally useful, and eventually they decided all the > features of X11 were needed. The X developers were not just adding > features for their own sake; they were trying to solve real problems. The problem is that they were factoring the problem apart along the wrong lines. They implemented basic drawing primitives and assumed that was good enough. What they needed to be implementing was visual objects: buttons, text panes, windows, etc. Eventually they realised it and built a toolkit that let you work with those objects, but because it was in the application it put a lot of strain on the protocol, and required real-time response from an app. > >> Most of the critics have failed to suggest what they would have liked to > >> see as a windowing interface instead of X. NeWS? > > Very well. I want xterms. Nothing more. I want to be able to pop > >open 80x24 windows that emulate vt100s correctly. Now all this guy wants is text panes. > So get yourself a Macintosh and run NCSA Telnet. An Amiga and "DNET" would be cheaper. > I don't think our image processing and animation people... Animation? Under X? The good animation stuff I've seen has an X-window acting as a mask in front of proprietary high-speed graphics stuff. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
In article <1991Apr18.014319.8272@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > do an "lpq" on a machine with a few PostScript printers. Do the same on any system with the capabilities of postscript and bitmapped printers. Even nastier. And that's basically what X is to NeWS. > PostScript can produce spiffy images, for sure, but it's just > too easy to produce 100K worth of glop to print a page. Anyone have net stats on traffic generated by NeWS versus X? > system is a savings, but you have to make sure that your applications > are not stupid about doing the PostScript equivalent of bells and > whistles. Yes, you don't want to MacDink your server to death. Though pie menus *are* neat. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
In article <130080@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > NeWS seems like it uses the right model, but people say it's > really too slow and big to build terminals out of. And perhaps > the language is too awkward; postfix if's are hard to read. How much actual programming in Postscript would you expect the typical application programmer to do? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jeenglis@alcor.usc.edu (Joe English) (04/24/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >The problem is that [X's designers] were factoring the problem >apart along the wrong >lines. They implemented basic drawing primitives and assumed that was good >enough. What they needed to be implementing was visual objects: buttons, >text panes, windows, etc. I think this is one of the things X definitely does right. It allows for much greater flexibility in UI style and policy. X is still used extensively for UI research, so this flexibility is important. >Eventually they realised it and built a toolkit >that let you work with those objects, Actually, this was one of the original design decisions. "Tools, not rules" -- you can replace the toolkit if you want. You can't do that on a Mac. >[Barry Margolin wrote:] >> I don't think our image processing and animation people... > >Animation? Under X? The good animation stuff I've seen has an X-window >acting as a mask in front of proprietary high-speed graphics stuff. If I remember right, the "..." in the >>ed line originally read something like "would consider X to be a usable environment for their needs." Why did you ellipsis the quote? It makes it look like you're disagreeing with Barry. But you're right, X wasn't designed for image processing or high-power graphics. It's much more suitable for more mundane things like business, CASE, and productivity software. --Joe English jeenglis@alcor.usc.edu
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/24/91)
In article <4_XAYQ1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >And perhaps > > the language is too awkward; postfix if's are hard to read. > How much actual programming in Postscript would you expect the typical > application programmer to do? I think that depends on the toolkit and development environment. Using tNt 2.0 and DevGuide, you can develop an application interactively, and then link in the toolkit without writing any PostScript at all, I believe. If you want to modify one of the widgets, you have to get into PostScript programming, but it's Object Oriented, so that helps. I agree about the language. The problem is parsing code like foo bar blatz mumble tilderoll You have to know each operator and how many items it pops/pushes off the stack. I really wish there was some way to add parentheses, even if there were syntatic sugar. Too bad all of the bracket characters are defined. I wanted to define a set of brackets to use just to help me balance the operators... -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
leh@atlantis.cis.ufl.edu (Les Hill) (04/24/91)
In article <28131F4E.F47@tct.com>, chip@tct.com (Chip Salzenberg) writes: |> According to leh@atlantis.cis.ufl.edu (Les Hill): |> >Why don't you just stack a couple of vt100s on your desk and save your |> >inane indictments of X? |> |> Actually, I use a '386 PC that runs a Telnet implementation with up to |> nine sessions, among which I select with Alt-F#. Quite friendly for |> my money, and loads more useful than an X terminal. Great! Glad to hear it! However, I think you (and others) have missed the point of my vitriol -- if you don't need X or if you don't want to use X, then don't; on the other hand, if you need X or if you want to use X, then do so. Inane articulations about X-bloat and how it could all be solved by some "all I need is xterms" solution identify the speaker as a parochial yahoo bent on some personal vendetta (perhaps frustration due to a lack of understanding of the subject matter :) -- Extraordinary crimes against the people and the state have to be avenged by agents extraordinary. Two such people are John Steed -- top professional, and his partner, Emma Peel -- talented amateur; otherwise known as "The Avengers." INTERNET: leh@ufl.edu UUCP: ...!gatech!uflorida!leh BITNET: vishnu@UFPINE
lm@slovax.Eng.Sun.COM (Larry McVoy) (04/25/91)
jeenglis@alcor.usc.edu (Joe English) writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > > >The problem is that [X's designers] were factoring the problem > >apart along the wrong > >lines. They implemented basic drawing primitives and assumed that was good > >enough. What they needed to be implementing was visual objects: buttons, > >text panes, windows, etc. > > I think this is one of the things X definitely does right. > It allows for much greater flexibility in UI style and policy. > X is still used extensively for UI research, so this flexibility > is important. I think that this is a trap, a typical Computer "Science" sort of pitfall. All your college professors will tell you about separation of policy and mechanism like it is some sort of manna from heaven. In the area of user interface this is, in my opinion, the worst possible thing that could be done. It is worse than having a bad, but consistent, user interface. Think carefully before you flame me - think hard about the Mac. The reason that *users* like the Mac is due, in part, to the consistent look and feel of the user interface. You may not like it, but you remember how it works. X blew it by handing out all that mechanism to developers. It would have been much better if they took a little longer and came up w/ the same set of functionality that the Mac (even the early Mac) had. Then all the apps would look the same, work the same. The toolkits were only a weak attempt. What X has done is similar to providing the source for libc and telling you to write ls. Every implementation of ls has different options and a different look and feel *to implement the same function*. Most bogus. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
lance@motcsd.csd.mot.com (lance.norskog) (04/25/91)
If you don't like X or NeWS, go read sci.virtual-worlds. I just posted my window system language design there.
peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
In article <16818@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English) writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > >[X implemented] basic drawing primitives and assumed that was good > >enough. What they needed to be implementing was visual objects: buttons, > >text panes, windows, etc. > I think this is one of the things X definitely does right. > It allows for much greater flexibility in UI style and policy. > X is still used extensively for UI research, so this flexibility > is important. That's fine for research, but for people who are more interested in USING the window system it's a loss. Also, it hurts flexibility in style and policy if you're working with existing code: if the communication between the client and the server is "open a text pane yea characters high and so many characters wide" then you can have that be an Open Look, Motif, Mac, PM, or any other UI text pane simply by changing the server: and all the apps will automagically change. This is where NeWS did it right. Pity. > Actually, this was one of the original design decisions. > "Tools, not rules" -- you can replace the toolkit > if you want. You can't do that on a Mac. Meanwhile the uniform UI on the Mac has made it one of the most productive environments for the end-user despite its own godawful design flaws. > If I remember right, the "..." in the >>ed line > originally read something like "would consider X to be a > usable environment for their needs." Why did you ellipsis > the quote? It makes it look like you're disagreeing with > Barry. Because I'm disagreeing with Barry. His point was that X was faster than NeWS and so more useful for animation and image processing. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
barmar@think.com (Barry Margolin) (04/25/91)
In article <16818@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English) writes: >>[Barry Margolin wrote:] >>> I don't think our image processing and animation people... >> >>Animation? Under X? The good animation stuff I've seen has an X-window >>acting as a mask in front of proprietary high-speed graphics stuff. > >If I remember right, the "..." in the >>ed line >originally read something like "would consider X to be a >usable environment for their needs." Why did you ellipsis >the quote? It makes it look like you're disagreeing with >Barry. No, he got it right. I believe the "..." was something like, "would consider a bunch of xterm windows to be usable". Most of our real-time animation work is generally done on frame buffers directly connected to the Connection Machine system. However, the CM graphics library is generic -- it can display on a directly-connected frame buffer or a networked X display. Since CM frame buffers are not as common as X displays, the developers generally use X output during development, and use the CM display for final, realtime runs. The general point I was making is that many people who use X *need* multiwindowed graphics, so a protocol that only provides a bunch of text windows is nearly worthless to them. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
In article <BARNETT.91Apr23224711@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: > I agree about the language. The problem is parsing code like > foo bar blatz mumble tilderoll > You have to know each operator and how many items it pops/pushes off > the stack. You young kids today. You're spoiled by all this memory! Back in the old days where you were amazed when you actually had a full 64K to play with and the only language that could do the job right was Forth... in those days you learned how to program stack code. Use whitespace and comments! % babble foo bar % grubbish bubbles blatz % grubbish bubbles-x bubbles-y mumble % grubbish+deltax grubbish+deltay tilderoll % frobozz status | false -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?" dup 0 <# # # #> type bl emit over + swap do i c@ fixup emit loop cr emit
jim@segue.segue.com (Jim Balter) (04/25/91)
In article <16818@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English) writes: >peter@ficc.ferranti.com (Peter da Silva) writes: >>[Barry Margolin wrote:] >>> I don't think our image processing and animation people... >> >>Animation? Under X? The good animation stuff I've seen has an X-window >>acting as a mask in front of proprietary high-speed graphics stuff. > >If I remember right, the "..." in the >>ed line >originally read something like "would consider X to be a >usable environment for their needs." Why did you ellipsis >the quote? It makes it look like you're disagreeing with >Barry. No, you are the one who left out the critical context. Why did you leave it out? Why did you put words in Barry's mouth that are the opposite of what he said? critical context, to which Barry responded, which Peter included, but you omitted: "Very well. I want xterms. Nothing more. I want to be able to pop open 80x24 windows that emulate vt100s correctly." Barry made the obvious observation that not everyone fits into that mold. Peter made the (not so obvious) observation that X isn't enough either.
sidana@neon.Stanford.EDU (Ashmeet S Sidana) (04/25/91)
In article<558@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >jeenglis@alcor.usc.edu (Joe English) writes: >> peter@ficc.ferranti.com (Peter da Silva) writes: >> >The problem is that [X's designers] were factoring the problem >> >apart along the wrong >> >lines. They implemented basic drawing primitives and assumed that was good >> >enough. What they needed to be implementing was visual objects: buttons, >> >text panes, windows, etc. >> >> I think this is one of the things X definitely does right. >> It allows for much greater flexibility in UI style and policy. >> X is still used extensively for UI research, so this flexibility >> is important. > >I think that this is a trap, a typical Computer "Science" sort of pitfall. >All your college professors will tell you about separation of policy and >mechanism like it is some sort of manna from heaven. In the area of >user interface this is, in my opinion, the worst possible thing that >could be done. It is worse than having a bad, but consistent, user >interface. But herein lies the problem. X was NOT designed to provide a user-interface. One of the goals of the original design WAS separation of policy and mechanism. So saying "X did it wrong" is incorrect. What they set out to do they achieved. However, later, X started being used for something else - A commercial standard to build distributed application interfaces with. Why? Because of interest from the big computer vendors (HP, DEC etc.) in the mid-80's. For various reasons NeWS wasn't *commercially* acceptable, they needed something to counter it straight away and so they pushed X. Now, In the commercial world it makes sense to have consistent user interfaces etc. so the direction of X changed. I have been programming in X for a long time and I can attest to its change. Release 10 didn't even have a toolkit! Now you have too many! Will X ever be as good as something designed from the ground up now. No! But that is the penalty of retro-fitting something and the march of technology. >Think carefully before you flame me - think hard about the Mac. The reason >that *users* like the Mac is due, in part, to the consistent look and feel >of the user interface. You may not like it, but you remember how it works. Good point. > >X blew it by handing out all that mechanism to developers. It would have >been much better if they took a little longer and came up w/ the same >set of functionality that the Mac (even the early Mac) had. Then all the >apps would look the same, work the same. The toolkits were only a weak >attempt. But thats what they were trying to do! Toolkits for building interfaces were an afterthought due to "other" reasons. Oh, I've have completed a loop here. Now the computer can handle the subsequent iterations :-) ---Ashmeet Sidana sidana@cs.stanford.edu sidana@hpcc01.hp.com PS: My last comment is an attempted pun on Alan Turing's (THE turing) arguments on computable methods. Flames on that to /dev/null. Just finished reading his biography "Alan Turing: The Enigma". A wonderful book!
jeenglis@alcor.usc.edu (Joe English) (04/25/91)
lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >jeenglis@alcor.usc.edu (Joe English) writes: >> I think [separating the toolkit from the server] is one of the >> things X definitely does right. >> It allows for much greater flexibility in UI style and policy. >> X is still used extensively for UI research, so this flexibility >> is important. >I think that this is a trap, a typical Computer "Science" sort of pitfall. >All your college professors will tell you about separation of policy and >mechanism like it is some sort of manna from heaven. Well, yeah :-) I agree with them, though. It *can* be very useful: I'm working on an X application right now that makes use of two home-rolled widgets. They plug right in to the toolkit and I can use them just like any other widget; if all the UI components were implemented in the server this would be much more difficult to do. >Think carefully before you flame me - think hard about the Mac. The reason >that *users* like the Mac is due, in part, to the consistent look and feel >of the user interface. You may not like it, but you remember how it works. No flames; I think the Mac is a great piece of work. But X had different design goals -- a consistent UI was explicitly *not* a consideration. The Mac does some things better than X, but vice versa as well. >X blew it by handing out all that mechanism to developers. It would have >been much better if they took a little longer and came up w/ the same >set of functionality that the Mac (even the early Mac) had. Then all the >apps would look the same, work the same. The toolkits were only a weak >attempt. I disagree. Motif apps under X are *just* as easy to use as MS-Windows apps, and Xt programming is considerably easier than Windows programming. Given a decent toolkit (and I'm not claiming that Motif is any more than decent; "good" would probably be stretching it) you can get a consistent UI that functions well. And, perhaps more importantly, under X you're not stuck with Motif (or OL, or Xaw, or whatever.) --Joe English jeenglis@alcor.usc.edu
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/25/91)
In article <.VYA9Y1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > You young kids today. You're spoiled by all this memory! Watch it! I cut my programming teeth on a Intel 4004 microprocessor! >Use whitespace and comments! I know how to use whitespace and comments. But does everyone else? Sometimes white spaces are detrimental. Having the entire routine on a single page is better than putting each command on it's own line and making the code three times longer. There are advantages to the lisp syntax. At least you can parse the code without knowing each command and without REQUIRING comments to document the operand stack. Forth/PostScript has some nice points as an interactive language. I wonder if some special characters can be added to the NeWS/PostScript language using a different font that allows a programmer to insert special brackets that have no function but do allow vi/emacs and the programmers to balance the stack parameters. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
In article <1991Apr25.022055.27604@neon.Stanford.EDU> sidana@neon.Stanford.EDU (Ashmeet S Sidana) writes: > But herein lies the problem. X was NOT designed to provide a > user-interface. One of the goals of the original design WAS > separation of policy and mechanism. So saying "X did it wrong" is > incorrect. What they set out to do they achieved. That's right. The spec was right for a research system. It was, however, quite wrong for a commercial system. The problem isn't X, it's all the lazy manufacturers (and customers) who are using X outside its design goals. I don't care about the politics. I just want something that works without multiple megabytes of duplicated effort. Commercial X is like multiuser DOS: a horrible waste of resources. A good commercial windowing system should be able to run in a $500 box: server, apps, the whole thing. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
rberlin@birdlandEng.Sun.COM (Rich Berlin) (04/26/91)
In article <BARNETT.91Apr25102541@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: |> In article <.VYA9Y1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: |> |> > You young kids today. You're spoiled by all this memory! |> |> Watch it! I cut my programming teeth on a Intel 4004 microprocessor! |> |> >Use whitespace and comments! |> |> I know how to use whitespace and comments. But does everyone else? |> |> Sometimes white spaces are detrimental. Having the entire |> routine on a single page is better than putting each command on it's |> own line and making the code three times longer. |> There are advantages to the lisp syntax. At least you can |> parse the code without knowing each command and without REQUIRING |> comments to document the operand stack. |> |> Forth/PostScript has some nice points as an interactive language. I |> wonder if some special characters can be added to the NeWS/PostScript |> language using a different font that allows a programmer to insert |> special brackets that have no function but do allow vi/emacs and the |> programmers to balance the stack parameters. |> -- |> Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett You could always define a couple of postscript "commands" which do nothing, e.g. /|- {} def /-| {} def and then mark things like this: |- 100 50 8 [1 0 0 -1 0 900] {<00>} false 3 -| colorimage Since all of the paren and brace type characters in PostScript are self-delimiting, you can't use them and are therefore forced to go to strange 2-character combos like the ones I suggested. You mentioned in an earlier message that you'd prefer prefix notation, and I think that would be possible if you defined -| properly and used the literal name (e.g. /colorimage) rather than the executable form. Youq should probably stick to postfix notation, however; defining -| so you could put the "colorimage" behind the operands would be messy to program and pretty slow. Aside from that, redefining the language in such a fundamental way is hard on anyone who has to come along afterward and read it. -- Rich
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/26/91)
In article <12231@exodus.Eng.Sun.COM> rberlin@birdlandEng.Sun.COM (Rich Berlin) writes: > You could always define a couple of postscript "commands" which do > nothing, e.g. > > /|- {} def > /-| {} def > > and then mark things like this: > > |- 100 50 8 [1 0 0 -1 0 900] {<00>} false 3 -| colorimage Yeah - that's what I was thinking of. But would everyone use it? There would need to be a large number of tools to make this popular. Like - positioning the mouse on the first bracket and hitting a command key that executes the commands within the bracket. (Like lisp). And having double/triple clicks expand fill the brackets. Then drag, copy and drop the code from one routine into another, call up a parser to check for the proper number of parameters. (e.g. selected text takes two parameters as input and generates 3 items on the stack.) You would also need some code to read a PostScript/NeWS program and generate the proper nesting of brackets. Now there's an interesting idea! This would tell you which commands consumed data, and which ones generated data. It would indicate nesting depth, and might go a long way to making NeWS easier to use. Let's extend the syntax a little. Maybe |- is a bracket indicating there is the same number of operates on the stack as the matching -|. If you have a procedure that takes three parameters, and consumes them all, use a different character. Perhaps |+++ to go with -|? > You mentioned in an earlier message that you'd prefer prefix notation, I wouldn't say it's the prefix part that is important. It's the clear indication of data flow that I like so much, and vanilla PostScript lacks. If NeWS was extended to have this sort of "syntactic sugar" without penalty, and the tools were added to make this usage desirable, it might be easier for people to pick up a random piece of code and follow it without memorizing AHEAD OF TIME the input/output of every procedure/command used. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
richard@aiai.ed.ac.uk (Richard Tobin) (04/26/91)
In article <558@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >Think carefully before you flame me - think hard about the Mac. The reason >that *users* like the Mac is due, in part, to the consistent look and feel >of the user interface. You may not like it, but you remember how it works. Sorry, I'm going to flame you. Of course *users* like the mac - that's why they're users. Those of us who tried it and found the interface completely non-intuitive went elsewhere. Remember how it works? I couldn't even find out how it worked... -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
stripes@eng.umd.edu (Joshua Osborne) (04/27/91)
In article <.VXAREE@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > The problem is that they were factoring the problem apart along the wrong > lines. They implemented basic drawing primitives and assumed that was good > enough. What they needed to be implementing was visual objects: buttons, > text panes, windows, etc. Eventually they realised it and built a toolkit > that let you work with those objects, but because it was in the application > it put a lot of strain on the protocol, and required real-time response > from an app. No they didn't "eventually realise" the need for the server to understand menus, text editors, and buttons. That would have forced a Look & Feel onto applications, which is what they wanted the server NOT to do. Now users can choose between 3D and 2D menus, round and square. Lots of diffrent editors, and a handful of menus. Who knows, mabie somone will make pie menus for X. (You can do most of the button work in the server, likewise for menus once they are posetd, but that requires a fair amt of memmory in the server) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
schwartz@groucho.cs.psu.edu (Scott Schwartz) (04/27/91)
stripes@eng.umd.edu (Joshua Osborne) writes:
No they didn't "eventually realise" the need for the server to
understand menus, text editors, and buttons. That would have
forced a Look & Feel onto applications, which is what they wanted
the server NOT to do.
If the server supports an extension language, then no one is locked
into anything. They just download their look and feel to where it
properly belongs.
but that requires a fair amt of memmory in the server
What are workstations for :-)monardo@cshl.org (Pat Monardo) (04/28/91)
In article <BARNETT.91Apr23224711@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >In article <4_XAYQ1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I agree about the language. The problem is parsing code like > foo bar blatz mumble tilderoll >You have to know each operator and how many items it pops/pushes off >the stack. I really wish there was some way to add parentheses, true. i also notice that i tend to stop reading the postscript and only read the comments after awhile. which is probably what you are supposed to do.
mike@bria.UUCP (Michael Stefanik) (04/28/91)
In an article, lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >Think carefully before you flame me - think hard about the Mac. The reason >that *users* like the Mac is due, in part, to the consistent look and feel >of the user interface. This is the old double-edged sword of user versus programmer usability. With the Mac, you had a machine that people loved to *use* but programmers *despised* programming. Obviously this didn't (and will not ever) work. User friendless at the expense of programmability (or perceived said programmabilty) is not going to do it. -- Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- If MS-DOS didn't exist, who would UNIX programmers have to make fun of?
xtdn@levels.sait.edu.au (04/28/91)
jeenglis@alcor.usc.edu (Joe English) writes: >>Eventually they realised it and built a toolkit >>that let you work with those objects, > > Actually, this was one of the original design decisions. > "Tools, not rules" -- you can replace the toolkit > if you want. You can't do that on a Mac. I'm not a Mac programmer so what I'm about to say is hearsay. I have heard it said (by someone who *is* a Mac programmer) that you can replace pieces of the Mac toolkit; and that it's not hard to do that. (Apparently you replace the appropriate trap vector.) Don't beat on the Mac, people, it's a fine attempt at a GUI and quite possibly it's done more to popularise the concept than has any other (related) product. Sure it might have some warts but those guys were forging relatively new ground. David Newall, 16:32:56.04, Tuesday, 1991 Phone: +61 8 344 2008 "Life is uncertain: Eat dessert first" E-mail: xtdn@lux.sait.edu.au
gaynor@yoko.rutgers.edu (Silver) (04/28/91)
[What follows is a little jumbled because I'm in something of a rush. Also, I had to nuke the References: line, my modem ate it and I didn't feel like regenerating it. Since this discussion does not pertain to unix internals or NeWS per se, I've directed followups to comp.lang.misc.] > Sometimes white spaces are detrimental. Hear, hear!, or Here, here!, or something! White space can be cheap, but it's rarely free. Horizontal whitespace is typically cheaper than vertical whitespace because almost all fonts are taller than they are wide. That is, there are more units of space available across the page than down. The use of whitespace must be weighed against the amount of code visible at one time, because scrolling around is as much a detriment to readability as too much or too little whitespace. Code is only written once. After that, it's a matter of staring it down to find out what/how to modify it. So, after the initial heavy editing, give it a beautifying pass. Eliminate a lot of unnecessary whitespace. Comments kind of fall in the same category. Never comment in-line that which is obvious or self-documenting. It's a fairly common practice to put atomic operations on seperate lines without even considering the operations surrounding it. I think it's better to put an single _semantic_ operation on a single line if it's reasonably short. I could spout more blather here, but I'll hold off for now. Here's a few things I usually do: 1. Within expressions, I like to use whitespace to indicate operator precedence. For example, I'll write "1 + 2*3" instead of "1 + 2 * 3", or "1 2 3 * +" instead of "1 2 3 * +". 2. Rarely will I devote an entire line to a mere grouping operator. For instance, I'll take the left over the right any day. /foo /foo {add} { define add } define 3. An example of putting a semantic operation on a single line: ... /* `cat' F to stdout */ { int c; while ((c = getc(F)) != EOF) putchar(c); } ... as opposed to ... /* `cat' F to stdout */ {int c; while ((c = getc(F)) != EOF) putchar(c);} ... I concede that less-compressed versions of the second form are easier to read. But this is such a trivial operation that the lack of whitespace does not impair its readability enough to justify adding more. Flamers: Try playing the devil's advocate before you send your followups. Regards, [Ag] gaynor@paul.rutgers.edu
mike@bria.UUCP (Michael Stefanik) (04/28/91)
In an article, xtdn@levels.sait.edu.au writes: |Don't beat on the Mac, people, it's a fine attempt at a GUI and quite |possibly it's done more to popularise the concept than has any other |(related) product. Sure it might have some warts but those guys were |forging relatively new ground. Bahh. XEROX did the groundbreaking; all Apple did was ride the coattails. -- Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- If MS-DOS didn't exist, who would UNIX programmers have to make fun of?
rli@buster.stafford.tx.us (Buster Irby) (04/29/91)
gaynor@yoko.rutgers.edu (Silver) writes: >[white space tirade deleted] What does this have to do with unix internals? Your thoughts are as fragmented as your code! Take it back to the discussion group comp.lang.c where it belongs! According to the charter, the purpose of this group is: Discussions, bug reports, and fixes on and for UNIX.
jeffl@NCoast.ORG (Jeff Leyser) (04/30/91)
In post <226@bria.UUCP>, uunet!bria!mike says:
!!In an article, lm@slovax.Eng.Sun.COM (Larry McVoy) writes:
!!>Think carefully before you flame me - think hard about the Mac. The reason
!!>that *users* like the Mac is due, in part, to the consistent look and feel
!!>of the user interface.
!!
!!This is the old double-edged sword of user versus programmer usability.
!!With the Mac, you had a machine that people loved to *use* but programmers
!!*despised* programming.
Bull. Lots and lots of very talented folks enjoy programming AND using
the Mac. If all "programmers *despised* [programming]" the Mac, there
wouldn't be a whole hell of a lot for other people to "[love] to *use*".
This has absolutely nothing to do with internals (and hasn't for about 2
weeks now). Follow-up to alt.religion.computers.
--
Jeff Leyser jeffl@NCoast.ORGxtdn@levels.sait.edu.au (05/01/91)
mike@bria.UUCP (Michael Stefanik) writes: > In an article, xtdn@levels.sait.edu.au writes: > |Don't beat on the Mac, people, it's a fine attempt at a GUI and quite > |possibly it's done more to popularise the concept than has any other > |(related) product. Sure it might have some warts but those guys were > |forging relatively new ground. > > Bahh. XEROX did the groundbreaking; all Apple did was ride the > coattails. I agree. And please note that I never claimed that Apple invented the stuff. However I stand behind my comment -- I assume that it was this that you disagree with -- that Apple were forging relatively new ground. David Newall, 16:32:56.04, Tuesday, 1991 Phone: +61 8 344 2008 "Life is uncertain: Eat dessert first" E-mail: xtdn@lux.sait.edu.au
peter@ficc.ferranti.com (Peter da Silva) (05/03/91)
In article <226@bria.UUCP> uunet!bria!mike writes: > In an article, lm@slovax.Eng.Sun.COM (Larry McVoy) writes: > >Think carefully before you flame me - think hard about the Mac. The reason > >that *users* like the Mac is due, in part, to the consistent look and feel > >of the user interface. > This is the old double-edged sword of user versus programmer usability. > With the Mac, you had a machine that people loved to *use* but programmers > *despised* programming. Obviously this didn't (and will not ever) work. Obviously. It worked so poorly that the Mac is the #1 selling computer in the world. > User friendless at the expense of programmability (or perceived said > programmabilty) is not going to do it. Of course, X is just as bad, if not worse. All the same restrictions forcing applications programmers to do real-time work. It might be a double-edged sword, but if so X badly needs sharpening: it doesn't even manage one edge. > If MS-DOS didn't exist, who would UNIX programmers have to make fun of? X Windows. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"