Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hplabsz!mayer From: mayer@hplabsz.HPL.HP.COM (Niels Mayer) Newsgroups: comp.windows.x Subject: Re: WinTERP with other windowing systems? Message-ID: <5626@hplabsz.HPL.HP.COM> Date: 19 Jul 90 22:06:29 GMT References: <7557@gollum.twg.com> Reply-To: mayer@hplabs.hp.com (Niels Mayer) Organization: Hewlett-Packard Labs, Software & Systems Lab, Palo Alto, CA. Lines: 79 Summary: Expires: Sender: Followup-To: In article peter@ficc.ferranti.com (Peter da Silva) writes: >Xlisp is a fairly sizable chunk to start building into window programs. I don't see David Betz's xlisp as being that sizeable a chunk, given the amount of functionality it gives. The xlisp binary used by winterp is not that big: -rwxr-xr-x 1 root other 159744 Jun 20 19:49 /usr/local/bin/xlisp (Especially when you compare it to the whopping size of X11/Xt/Motif) >How >about something a little simpler... like Postscript? There is precedent, >after all, and at least two sets of Postscript source code running around. I think the biggest problem in making NeWS acceptable was its use of postcript as the interpreter. Postscript is fine and dandy, a really neat language, etc. But it is a total pain in the ass to program in. Afterall, is SUN expecting developers to program in postscript or in tNt?? Lisp variants have shown themselves to be extremely successful customization languages, setting a much stronger precedent than postscript. A few successful lisp customizable systems off the top of my head: Gnu Emacs, Gosling Emacs, AutoCAD, Interleaf (??), The Interlisp-D programming environment, Symbolics programming environment, Personal Composer (or is it professional composer, i can't remember), etc. You want more than just a simple customization language -- anybody can write a simple customization language in N lines of code... I mean how hard is it to come up with a language that handles some assignment and control flow? Along with the customization language, some baggage needs to be incorporated in order to make the system useful and useable, eg. debugging support. Unless you like the tedium of making a customization and reloading/rerunning the program for each change, you'll probably want a language that supports interactive and incremental changes. And then there's symbol manipulation, datastructures, lists, arrays, strings, an object system, ... Oh yeah: whatabout memory management -- I'll be damned if I expect system customizers to want to worry about memory allocation and deallocation. You can easily come up with an arbitrarily minimal language that will force people to add/hack on the necessities. Why not use a language with proven clean semantics, a proven track record as a powerful customization and programming language. With lisp systems, you can go too far in forcing excess baggage to appear with the deliverable -- Common Lisp is afterall the excess baggage poster child. With WINTERP and Xlisp, I hoped to gain some of the features of a Lisp-customizable system but without the excess baggage, slow execution, and huge memory consumption that plagues Common Lisp. Scheme is more of a minimal system -- too minimal for my tastes. But I'd better stop before this turns into a language war... >Then there's John Ousterhout's TCL. We've already got it running as a shared >library under AmigaOS. TCL is certainly inrteresting, and smaller than XLISP. How does it fare against some of the criteria mentioned above? TCL's one big advantage is political -- everybody "out there" is a C programmer, so at least people will be working with a familiar syntax... When introducing new languages, there is the big problem that you can't teach old dogs new tricks.... But of course, you can get old dogs to roll over, play dead, and jump through arbitrarily hairy hoops by introducing brand new "languages" with familiar syntax but convoluted semantics -- just use those curly brackets, use semicolons as separators, and make sure the parentheses come after the function and they'll think they're using a C like language. (Note, this paragraph is not in reference to TCL -- at least TCL is a real language, unlike , which is the "language" i'm thinking about.) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *