mayer%hplnpm@HPLABS.HPL.HP.COM (Niels P. Mayer) (01/16/90)
Ahh, the great WINTERP vs. ELK battle (from comp.windows.news) continues... net@tub.UUCP (Oliver Laumann) writes: > Since we are using Elk-Scheme as the extension language for a `real' > software package (an ODA-based document processing system), we do need to > be able to access the full power of the X toolkit, for instance, our > application must be able to open more than one display (for shared editing > of a document). A few groups at HPLabs are using WINTERP as the platform for 'real' software packages as well. The main purpose of the "Collaborative Interaction" project that I'm a member of is to make "groupware" real -- much of the published work in groupware/cscw have describred interesting ideas ontop of implementations that made the work little more than a laboratory curiosity. Such groupware is about as interesting as a standalone telephone because groupware needs to be widely distributed and used by real workgroups doing real work. Such usage is enabled by supplying an experimental deliverable for free, in a small package, without requiring the purchase of specialized hardware or software. Groupware also needs to be tailorable for use in particular workgroups, thus the need for an embedded customization language to allow interactive modification of a program's actions and interface. In order to prove that such technologies are useful we required a small freely distributable platform that can be used by groups of "early adopters" of our technologies that we have and will target at HP divisions worldwide. At the same time, we needed a good prototyping platform that will support a lifecycle of continuous rapid-prototyping --> delivery. And that's the reason why I wrote WINTERP. The things that you consider as being 'real' for your project are thus diffent from what we consider real. Opening multiple displays wasn't a top-priority because we use a lisp-based language protocol (sent through e-mail, or through TCP straight to winterp's lisp server) for communicating to winterp-based groupware applications running on other hosts. Our groupware is designed to be distributed rather than centralized. However, WINTERP will support multiple displays properly as soon as they are properly supported by Motif. Motif 1.0 was based on X11r3's intrinsics which really don't support multiple displays properly. Perhaps Motif 1.1 will do this correctly, at which point in time, I'll extend winterp to allow for multiple displays. > Of course, funtionality like opening a display and creating an > application context (the things that you called `noise') can be hidden > in an additional `layer' if desired; building abstractions is one of > the things that can be done in Scheme quite elegantly (which is one > reason why we think that Scheme is better suited as a general extension > language than, for instance, Xlisp). Say what? Yes, scheme has a few nice features not directly available to common lisp, and it's syntax could be construed as being cleaner (or at least, more sparse). However, it is a gross misstatement to say that "abstraction" cannot be elegantly accomplished in a common-lisp-like dialect such as XLISP. In fact, XLISP is excellent for building abstractions because it contains a nice (but simple) object system implemented in C, accessible from Lisp. See examples/mail-br.lsp or examples/grep-br.lsp for a simple use of the object system to create a powerful "browser" abstraction. Some of the things that I consider "noise" must be buried underneath the implementation of WINTERP in order to make the system fully interactive. Again, your goals in building Elk were obviously different from mine. I wrote WINTERP as a high-level interface to X using the Motif widgets. I prefer to do work at a completely different abstraction layer -- straight C -- when messing with low-level primitive operations in X. The majority of people using our groupware toolkit will be using WINTERP's customization language to program with much higher-level functionality than low-level Xt or Xlib calls. As a developer of the groupware toolkit, I'd rather add low-level functionality in C and make that accessible through Lisp. (I'd be very interested in hearing if you have managed to write a new widget entirely in Elk-scheme...) I claim that the features that "language people" like about scheme are also the features that will be least-understood and most confusing to people seeking to customize the system by manipulating the extension language. I get enough flak in this world-of-C-programmers for having chosen Lisp for WINTERP. Using scheme would strenghten their arguments ("Scheme, what's that??"). At least with XLISP's common-lisp compatibility, I can refer people to the large number of introductory books on common lisp now available, and I can also refer them to existing programs using lisp as a customiztion language -- GNUemacs, and AutoCAD. However, the main reason why WINTERP uses XLISP, rather than some dialect of scheme is entirely pragmatic -- I very much doubt my management would have been interested in my developing yet another interpreter, or spending lots of time trying to mold an existing interpreter to my needs. I'm supposed to work on UI's for groupware. After evaluating various existing interpreters, I chose XLISP because: (1) it is small, fast, and free; (2) XLISP is robust, tested, bug-free and extremely portable -- it's been available since 1985, has a large user-community (on unix, msdos, amiga, mac, etc), has undergone many revisions, and even has it's own newsgroup (comp.lang.lisp.x) in which bugfixes, patches, etc are discussed; (3) it had a nice object system that fit in well with my intended model of widgets-as-lisp-objects (allowing existing C-implemented Motif widget classes to be subclassed, methods to be added or substituted, all within lisp, interactuively...); (4) XLISP makes it very easy to do "hybrid programing" -- the ability to program in both interpreted lisp and compild C. Once David Betz's XSCHEME is sufficiently developed and debugged, it will be relatively easy to transform WINTERP to use that language base in order to please all the scheme-chauvinists out there. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *