joel@decwrl.dec.com (Joel McCormack) (01/08/90)
From the types of arguments offered for NeWS recently in this group, I must conclude that you guys all write ``real'' programs in Forth, yes? It's interpreted, extensible, uses RPN, etc. No, you probably all program in C, and many would defend its use technically (ugh). (I can't argue with using C for sales and lots of other reasons...but then, we're talking technical here, right?) A window system is not the place to put support for dynamic loading, concurrency, OO programming, etc. Instead, a window system should be able to use all these things if they are provided by a decent environment. Most of the points about NeWS's ``technical superiority'' are really complaints about UNIX and C in disguise. You should certainly complain that your programming language and environment doesn't give you support for the kinds of things you want to do, but don't get confused and complain that the lack of such support is a problem inherent to X. - Joel McCormack (decwrl!joel, joel@decwrl.dec.com)
mlandau@bbn.com (Matt Landau) (01/08/90)
joel@decwrl.dec.com (Joel McCormack) writes: >Most of the points about NeWS's ``technical superiority'' >are really complaints about UNIX and C in disguise. You should >certainly complain that your programming language and environment >doesn't give you support for the kinds of things you want to do, but >don't get confused and complain that the lack of such support is a >problem inherent to X. This is a crock. The basic point is this: the X11 protocol simply does not allow me, as an application writer, to decide what parts of my application belong close to the user (in the server, where they can provide fast feedback, etc.) and what parts belong in the client. The only way for me to change this is to write my own server extensions and only allow my application to run with servers that have my extensions. In effect, I have to get into the X server business if I want to be able to do certain things. NeWS allows me to decide what parts of my application belong in the server, and to download them into the server myself, at runtime. I never have to worry about whether a particular extension or facility is present, because I can *make* it present, in any NeWS server, at any time, using a well-defined protocol (which happens to be based on PostScript, with all the nice things that implies about imaging models, etc.) There's also an argument that the X11 protocol does not allow me, as a user, to change what parts of my user-interface look like and have the change apply to all applications. That argument is also true, but only partially. It relies on all NeWS applications using the same server-resident tools for the user interface (they don't as yet) and it assumes that I don't have dynamically linked toolkits on the X11 client side that I can replace with different toolkits for a different UI policy (I don't know of such a thing for X yet, but the N3 project at AT&T sounds like a good start). Now, do we all understand why NeWS is a more powerful idea than X? Because runtime extensibility is good, and it's GUARANTEED by the very definition of NeWS, and it's NOT guaranteed by the very definition of X11. -- Matt Landau The happiest cold and lonely guy mlandau@bbn.com stuck in the Yukon without a dog.
peter@ficc.uu.net (Peter da Silva) (01/08/90)
In article <2405@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes: > From the types of arguments offered for NeWS recently in this group, I > must conclude that you guys all write ``real'' programs in Forth, yes? NeWS *is* Forth. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v "Have you hugged your wolf today?" `-_-'
joel@pandora.pa.dec.com (Joel McCormack) (01/08/90)
Now, do we all understand why NeWS is a more powerful idea than X? Because runtime extensibility is good, and it's GUARANTEED by the very definition of NeWS, and it's NOT guaranteed by the very definition of X11. I agree completely runtime extensibility is good. That's why people program in LISP and other such languages and environments. What I'm trying to say is that extensibility is not a problem that every tool in the world should have to address in it own idiosyncratic way. The more various tools try to compensate for basic deficiencies in the programming environment, the more weird interpreted languages I have to learn, and the more entrenched the stupid environment becomes. You can choose, each time you build a tool that you want to be extensible, to include yet another interpreter, for yet another language, in it. Or you can complain that what you'd really like is for EVERY program to have the option of being dynamically linkable to new pieces of code. Sure, you can download PostScript code into a NeWS server. Big deal: (1) PostScript wasn't designed as a programming language that humans should write in, and (2) PostScript was designed for printer speeds, not memory speeds. (And even so, a lot of people at printer companies complain how slow it is to image complicated diagrams with PostScript, and how PostScript semantics makes this especially hard to make fast. The lower resolution of a screen helps some, but not really enough.) Wouldn't you really rather be able to link compiled code into the server dynamically? I don't care about loading mouse-tracking code into the server--today's processors give me quite adequate tracking performance across the network. I'd like to download compiled code that will run fast, like 3-D extensions and image decompression algorithms. NeWS isn't going to do a thing for me, at least not in real time. I can't do this to an X server, either, at least in any portable way. But shouldn't I be able to? Why keep compensating for poor programming environments? You'll just encourage them! - Joel McCormack (decwrl!joel, joel@decwrl.dec.com) (This message brought to you by the C and UNIX are to Computer Science what FORTRAN is to Numeric Analysis Foundation.)
sjs@spectral.ctt.bellcore.com (Stan Switzer) (01/08/90)
In article <2405@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes: > From the types of arguments offered for NeWS recently in this group, I > must conclude that you guys all write ``real'' programs in Forth, yes? > It's interpreted, extensible, uses RPN, etc. No, you probably all > program in C, and many would defend its use technically (ugh). Well not this guy, that's for sure. C is a great language for writing interpreters. That's about it. > A window system is not the place to put support for dynamic loading, > concurrency, OO programming, etc. Instead, a window system should be > able to use all these things if they are provided by a decent > environment. Most of the points about NeWS's ``technical superiority'' > are really complaints about UNIX and C in disguise. Even allowing that this is true, and I think that it just might be, a solution is a solution. My dreadful UNIX/C environment isn't going to change for many a moon, but I can use the powerful features you mention (dynamic loading, concurrency, OO programming) and a few you don't (PostScript imaging model, high level execution abstraction--I'd settle for Scheme w/ OO extensions instead of PostScript RPN, minimal UI code in windowing client, rapid prototyping, dynamic modification of environment, powerful event distribution scheme, (almost) reflective programming language, etc.). The UNIX/C world suffers from least-common-denominatorism of the worst kind. Look at the Widget implementation. I mean, sure it's brilliant, but it should never have been done in C. Maybe Andrew had the right idea: a special preprocessor. Or maybe it should have been done in C++. Or maybe Objective-C. NeWS threatens to raise the denominator. True, it doesn't solve everybody's problems, but it does help solve the problems of the UI programmer. > You should > certainly complain that your programming language and environment > doesn't give you support for the kinds of things you want to do, but > don't get confused and complain that the lack of such support is a > problem inherent to X. OK, maybe I'm confused. Let's say that I had the power of the Mach OS, plus a windowing server with a powerful imaging model, plus a reasonable programming language. Then I might just be convinced. BUT: That OS isn't UNIX. That server isn't an unextended X. And that language isn't C. Maybe I should buy a NeXT? Stan Switzer sjs@bellcore.com ``I can't see the end of me / My whole expanse is all I see I formulate infinity / And store it deep inside me.'' -- Meat Puppets
peter@ficc.uu.net (Peter da Silva) (01/09/90)
[ Postscript is too slow, want to download object modules to the server ]
Sounds like you want to be using an AT&T 5620 Blit terminal.
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>
\_.--._/
v "Have you hugged your wolf today?" `-_-'msm@src.dec.COM (Mark S. Manasse) (01/12/90)
In article <13337@granite.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > This is a crock. The basic point is this: the X11 protocol simply > does not allow me, as an application writer, to decide what parts of > my application belong close to the user (in the server, where they > can provide fast feedback, etc.) and what parts belong in the client. > The only way for me to change this is to write my own server extensions > and only allow my application to run with servers that have my extensions. > In effect, I have to get into the X server business if I want to be > able to do certain things. > Stuff and nonsense. The X11 protocol does *allow* you to do this. You, as an application writer, are free to decide what part of your application belongs close to the user. You, as an application writer, can then write two programs, communicating by whatever means you choose, one of which is generally intended to execute on the same machine as your X server, bringing it about as close as is interesting. I'm not going to defend every aspect of X as perfect, but it seems to me that your point is not that X isn't as good a window system, but that it isn't as good at providing threads, defining communication protocols, being a programming language, and supplying dynamic loading. All quite true. But I don't understand why you don't want all of these things available to the part of your client that isn't coresident with your window system server. When I'm backpacking, I eat my food with a spoon that I bring along. When I'm in more civilized environs, I use nicer utensils. Right now, the operating system environments generally force you to eat with your fingers when you use X, and with your camping spoon when you use NeWS. Once we get around to buying some nice flatware, I'll rejoice that I didn't succumb to the temptation to have a spoon epoxied to my hand. Mark
bob@MorningStar.Com (Bob Sutterfield) (01/12/90)
In article <14286@jumbo.dec.com> msm@src.dec.COM (Mark S. Manasse) writes: In article <13337@granite.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: [T]he X11 protocol simply does not allow me, as an application writer, to decide what parts of my application belong close to the user (in the server, where they can provide fast feedback, etc.) and what parts belong in the client... You, as an application writer, are free to decide what part of your application belongs close to the user. You, as an application writer, can then write two programs, communicating by whatever means you choose, one of which is generally intended to execute on the same machine as your X server, bringing it about as close as is interesting. Here we see two different ideas of "close". NeWS programmers consider "running on the same machine" not to be necessarily close enough, and consider "running in the server itself" to be interesting enough to make a difference. Proximity, in this case, can be considered in terms of address space and scheduler slots in the server host's native OS, rather than geographically or net-topologically. A PostScript lightweight process is subject to the NeWS server's scheduler and uses the server's internal inter(lightweight)process communications facilities. Everyone agrees, in this day and age, that (at least part of) a window client must be able to run in a different address space than its window server, and must be able to communicate via the inter-process communication facilities provided by the underlying OS. And so long as there's (in UNIX terms) a process division, the two might just as well be running on entirely different hosts. That's the foundation of a network-distributed window system. A difference between the X and NeWS philosophies lies in whether that separate address space is a requirement or an option.