gjc@mitech.COM (08/22/90)
Don't ever forget, Extension languages can be darned small and
still extremely powerful IF they are lisp (scheme).
Couple cases in point:
(1) PDP-10 MACLISP. A language so small many young folks today might
be ignorant enough to call it a joke. But what can be written in it?
(a) MACSYMA, (b) SCHEME (pick your flavor), (c) FORTRAN COMPILERS,
(d) LISP COMPILERS, (e) SCHEME COMPILERS, (f) FORTRAN RTL
(g) PROLOG, (h) tons of highly original AI languages and implementations
(2) GNU EMACS LISP. Another real small one. No bignums, doesn't even
have floating point numbers. No lexical scoping even.
Shudder, no character objects!
(a) a darn good text editor
(b) even a small symbolic algebra system, with bignums, floats,
display formatters, parsers, differentiation, integration,
and numerical analysis procedures.
On the other hand I agree 100% with the need for a standard Scheme
language that has enough stuff in it to be fun to use, modern looking,
and allow porting of various programs. And R^3.x doesn't have to be
big, I figure even SIOD would only need to triple in size with an
optional file to be linked in if you wanted the whole show.
Although, we have to be careful here! For one thing just the
machinery for recognizing and parsing the NUMBER SYNTAX alone
(not to mention printing it optimally) could very easily be
the size of the ENTIRE SIOD version 1.3 implementation!
And, if I was implementing something like Macsyma I would *not*
use the complex/rational and other number constructs provided
native in SCHEME R^3.x or COMMON LISP. Nice but no cigar, basically.
Just doesn't buy me much when I have to deal with extensions to
symbolic (datatypes) and other algebraic domains. Writing special
case code to utilize that functionality in special case is probably
not worth it, a lot of work to call what is probably inferior quality
code. I would probably rather write special case code to call into the
native FORTRAN runtime library, on a particular machine.
------------------------------
OK NOW: HOW TO KILL a language.
------------------------------
Change of pace. My humble observation on what properties of
implementation (driven or not driven by language specification requirements)
tend to hurt terribly the usability of a programming language in that
"larger world" we all have to deal with at some time.
(1) not being unable to take code in language X and compile it somehow into
a subroutine library that can be called by a program in language
Y, or Z.
(2) strict requirements on environment and placement in virtual memory
of datastructures. i.e. lack of relocatability. (see 1 above).
(3) requirements of its own special toplevel loop.
(4) strange and/or undocumented data structures.
(5) restrictions with respect to native interrupt and condition handling.
(6) language constructs tied to special machine models, e.g.
MEMORY/REGISTER, that might not work out so well in newer hardware
implementations optimized for languages such as C.
These all lead to basically the same thing. Example: Most commercial
lisps have what they call (killer terminology) a "foreign" procedure
call interfaces. So big deal. If you write in language C then LISP
can call YOU, but:
(1) don't expect for you to be able to call LISP outside of the
LISP enviroment. The LISP is the master language here, all others
bow down.
(2) don't expect to use your standard C-debugger in the context
of the lisp environment. only fully debugged C programs should
be called from LISP!
I would point out that fully general CALL/CC is one of those
things that flies in the face even the extremely general
VAX/VMS model of runtime-language support.
Why? One reason is that CONDITION-HANDLING, the ability to undo side-effects
while unwinding the stack, and the ability to dynamically scope the
handling of machine and software generated exception cases, including
instruction emulation, is very important to the workings of things.
If you have a call sequence like:
C->SCHEME->C->SCHEME->FORTRAN->PASCAL->SCHEME
1 2 3 4 5 6 7
you are up shits creek if you think that you can return a fully
general lexical catch construct from level 7 back up to level 2
and then expect to re-enter the damn thing.
So a good way to KILL a language is to require the implementation
to be unworkable with respect to integration with the rest of
the known universe.
But ah, then there are all the dangers and politics of language
subsetting. The problem is that the dynamic-only CALL/CC language
will allow the inclusion of useful constructs which are too confusing/dangerous
to live in the standard environment of a language with full CALL/CC.
But wait, maybe we can get all the hardware manufacturers to change
the way they ... oops I forgot, we tried that one already.
-gjcgls@THINK.COM (Guy Steele) (08/22/90)
Date: Tue, 21 Aug 90 22:25:36 EDT From: gjc@mitech.com ... So a good way to KILL a language is to require the implementation to be unworkable with respect to integration with the rest of the known universe. ... By analogy, the way to KILL a text editor is to require it to be unworkable with respect to integration with the rest of the known universe. Therefore EMACS should never have happened, because the rest of the known universe was Teletypes; and window systems should never have happened, because the rest of the known universe was 24x80 displays. I think what you are doing is great and solves a problem; what other Lisp implementors are doing is also great and solving other problems; and it's not all black and white. One reason Lisp and Scheme are not dead is that there is enough flexibility of perception that there can be a range of implementations with different strategies and purposes all of which fall under the heading of, and can be credited to, the Lisp or Scheme Way of Doing Things.
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (08/24/90)
gjc@mitech.COM writes: >Don't ever forget, Extension languages can be darned small and >still extremely powerful IF they are lisp (scheme). Extension languages can be powerful if they are not Lisp. >Couple cases in point: >(1) PDP-10 MACLISP. [...] > [...] >(2) GNU EMACS LISP. [...] One could make smaller extension languages that are even more "powerful." Take assembly code, for example (name your favorite processor). Although it is not commonly used for an extension language, it certainly could be. And a lot more stuff has likely been written in 8xx88 assembly code than has in MacLisp or Gnu Emacs Lisp. My point is that there is nothing special that makes *Lisp* a great extension language. Some might argue that it is the "simple syntax," but that same simple syntax is hated by many (myself *not* included). Actually, the best extension language would be something that is "universal" and not tied to any one application. REXX/AREXX serves this purpose very well, from what I understand. It to is a small but powerful language, although it is certainly not lisp-like. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
lgm@cbnewsc.att.com (lawrence.g.mayka) (08/27/90)
In article <1990Aug24.154118.22011@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >My point is that there is nothing special that makes *Lisp* a great >extension language. Some might argue that it is the "simple syntax," >but that same simple syntax is hated by many (myself *not* included). Simplicity is nice, but extensibility is the much more important virtue of Lisp syntax. (The two are of course related to some degree.) Lisp's other main advantage as an extension language is its dynamic typing, which greatly reduces the effort required to make small changes to a program's behavior. I have found that those who "hate" Lisp syntax almost invariably have never used a powerful Lisp development environment such as Symbolics Genera, or even Harlequin's LispWorks. Indeed, the "haters" usually have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that most of us oldsters were introduced to in undergraduate school. Opinions formed in ignorance carry little weight with me. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (08/29/90)
lgm@cbnewsc.att.com (lawrence.g.mayka) writes: >In article <1990Aug24.154118.22011@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >>My point is that there is nothing special that makes *Lisp* a great >>extension language. Some might argue that it is the "simple syntax," >>but that same simple syntax is hated by many (myself *not* included). >Simplicity is nice, but extensibility is the much more important >virtue of Lisp syntax. (The two are of course related to some >degree.) Lisp's other main advantage as an extension language is its >dynamic typing, which greatly reduces the effort required to make >small changes to a program's behavior. But other languages can be as extensible. In fact, ARexx (Rexx for the Amiga) is likely the most extensible "extension language" I have heard of. If a program has a Rexx-port, it can be used as an extension to ARexx. In the Amiga community, it is very common to hear of people custom-making editor/compiler/hot-key setups with random editors, compilers, and ARexx. Languages like shell languages (including ARexx) are incredibly extensible, because you can use other programs as language "operators". Yes, lisp is naturally extensible, but so are *many* other languages. I will agree that lisp's dynamic typing are an important point of its usefulness. >I have found that those who "hate" Lisp syntax almost invariably have >never used a powerful Lisp development environment such as Symbolics >Genera, or even Harlequin's LispWorks. Indeed, the "haters" usually >have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that >most of us oldsters were introduced to in undergraduate school. Many of the lisp-haters that I am thinking of used the Xerox InterLisp workstation environment. What got many people were the structured editors. (I didn't mind these workstations much, aside from the slowness.) Many people I have spoken to hate lisp because they are used to Pascal-like languages. Some of these people had programmed in lisp for several months (i.e. a few AI courses in school). >Opinions formed in ignorance carry little weight with me. I agree, but many of the lisp-haters I have met have gien lisp a chance, and found they just didn't like it. Be careful of assuming that lisp-haters have formed their opinions out of ignorance. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
jeff@aiai.edinburgh.ac.UK (Jeff Dalton) (08/31/90)
This is about why people hate Lisp. > lgm@cbnewsc.att.com (lawrence.g.mayka) writes: > >I have found that those who "hate" Lisp syntax almost invariably have > >never used a powerful Lisp development environment such as Symbolics > >Genera, or even Harlequin's LispWorks. Indeed, the "haters" usually > >have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that > >most of us oldsters were introduced to in undergraduate school. I hope the case for Lisp doesn't depend on such things as the Symbolics (or even LispWorks). Many people find the Symbolics quite difficult to use in its own right; and if Lisp really needs that much env just to be as good as, for example, C under Unix, I don't think the argument for Lisp is very strong. Unfortunately, many people judge Lisp without even using the sort of environment provided by such things as GNU Emacs. They have to do their own indentation and parenthesis matching, which (a) is difficult and (b) tends to produce less than readable code. (Many people do not discover a good indentation style on their own and consequently have to pay too much attention to parentheses when reading code as well as when writing it.) (It doesn't help of course that on machines such as Suns C has a better environment in many respects than that provided by most Lisps. Dbxtool is my usual example.) I have also found that some people who teach Lisp (and others, of course) make a point of criticizing its syntax, the names "car" and "cdr", the lack of strong typing, etc. (all the traditional complaints) and in general have little understanding of how good Lisp programmers use the language or of the "ways of thinking" appropriate to it. This is not just because they are used to Pascal and friends. The same people often have nothing but good to say about functional and logic programming languages (eg, ML and Prolog). In part it's because they associate Lisp with hacking, debugging, all those things a proper methodology is supposed to reduce the need for, and because the "not a police state" philosophy seems to have produced a language that is almost antithetical to (what they regard as) the needs of software engineering (or whatever). > Many of the lisp-haters that I am thinking of used the Xerox InterLisp > workstation environment. What got many people were the structured > editors. I couldn't stand DEDIT (or whatever it was called). Indeed, I'm not a big fan of structure editors in general. Lisp is my favorite language nonetheless. > >Opinions formed in ignorance carry little weight with me. > > I agree, but many of the lisp-haters I have met have given lisp a > chance, and found they just didn't like it. Be careful of assuming > that lisp-haters have formed their opinions out of ignorance. Some people do dislike Lisp despite having used some of the supposedly good Lisp environments. Generally, there is some other language (or languages) they would prefer to use instead. Just as we usually prefer Lisp, I think it is reasonable for other people to prefer other languages. Indeed, there are often good reasons to prefer another language. We may think that Lisp is better all things considered, but that is not the only reasonable conclusion to reach. And if someone does prefer language X they may be annoyed by a language Y that doesn't let them express the things they want to express. talk of hating Y is often just a way to say they wish they didn't have to (or hadn't had to) use it. -- Jeff
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/01/90)
In article <1990Aug29.153243.7567@uwslh.slh.wisc.edu>, lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: > editors, compilers, and ARexx. Languages like shell languages > (including ARexx) are incredibly extensible, because you can use other > programs as language "operators". Yes, lisp is naturally extensible, > but so are *many* other languages. Extensible shell languages often use *prefix* notation, don't they? Hmmm... > Many of the lisp-haters that I am thinking of used the Xerox InterLisp > workstation environment. What got many people were the structured > editors. (I didn't mind these workstations much, aside from the I have read of the '70s debate between syntax-sensitive text editing (a la MIT) and true structure editing (a la Xerox). I am very pleased with the former; the latter seems to be dying out, so I may never even have a chance to sample it. > slowness.) Many people I have spoken to hate lisp because they are > used to Pascal-like languages. Some of these people had programmed in > lisp for several months (i.e. a few AI courses in school). Several months may or may not be a fair test, depending on the intensity of Lisp usage, the brand of Lisp used, the degree of emotional investment in other languages and environments, the degree of resistance to change (of any kind), etc. > chance, and found they just didn't like it. Be careful of assuming > that lisp-haters have formed their opinions out of ignorance. No, not all, of course. But enough to bother me, I guess. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
expc66@castle.ed.ac.uk (Ulf Dahlen) (09/03/90)
In article <5879.9008301913@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.UK (Jeff Dalton) writes: >This is about why people hate Lisp. > >> Many of the lisp-haters that I am thinking of used the Xerox InterLisp >> workstation environment. What got many people were the structured >> editors. > >I couldn't stand DEDIT (or whatever it was called). Indeed, I'm not >a big fan of structure editors in general. Lisp is my favorite language >nonetheless. Why not? I found it much better than any Emacs-style editor when programming in Lisp. Of course, SEDIT (the successor to DEDIT) is completely different and *very* much easier to use. Try it. Since Lisp is a structured language and since much of the teaching tries to get this point across, I find structure editors very appropriate to use. Most students either don't understand Lisp or they understand it _and_ like structure editors. That's my experience anyway. --Ulf Dahlen Linkoping University, Sweden and Edinburgh University, Scotland Internet: uda@ida.liu.se
peter@ficc.ferranti.com (Peter da Silva) (09/05/90)
In article <1990Aug24.154118.22011@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: > Actually, the best extension language would be something that is > "universal" and not tied to any one application. REXX/AREXX serves > this purpose very well, from what I understand. It to is a small but > powerful language, although it is certainly not lisp-like. One thing you frequently want to do in extension languages is manipulate code as data, to do things like saving definitions you're working on. This is easy in lisp like languages (like lisp itself, or scheme, or TCL) but a pain in algol-like languages (like REXX). -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
rh@smds.UUCP (Richard Harter) (09/07/90)
In article <S=O5I9F@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > One thing you frequently want to do in extension languages is manipulate > code as data, to do things like saving definitions you're working on. > This is easy in lisp like languages (like lisp itself, or scheme, or > TCL) but a pain in algol-like languages (like REXX). Currently we are working on an extension language so this topic is dear to my heart. I would be very interested in seeing a more complete elucidation of your comment. As far as I can see at the moment the criteria for *easy* manipulation of code as data are: (a) An interpreted language (b) The ability to execute "data" as a series of commands in the form of a string. (c) The ability to build strings without cumbersome quoting and character escape problems. (d) Minimal syntax restrictions (related to (c)). I don't see procedural command language format as being a major problem. The things that we dispensed with are types (everything is a string) and in-fix operators (we use lisp format functions). We also have lists, which may be cheating :-). It seems to me that types, in fix operators, and function format in the form f(arg1,arg2) rather than (f arg1 arg2) induce the problems. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
peter@ficc.ferranti.com (Peter da Silva) (09/08/90)
In article <176@smds.UUCP> rh@smds.UUCP (Richard Harter) writes: > > One thing you frequently want to do in extension languages is manipulate > > code as data, to do things like saving definitions you're working on. > > This is easy in lisp like languages (like lisp itself, or scheme, or > > TCL) but a pain in algol-like languages (like REXX). > I don't see procedural command language format as being a major > problem. Not at all. After all, Lisp is a procedural language. > The things that we dispensed with are types (everything > is a string) and in-fix operators (we use lisp format functions). That's the bottom line. Sounds like what you have is pretty close to TCL. Have you looked at it? It looks like this: proc key_'^K' {} { browse message {Edit key } set key [get key] set func key_[get keyname $key] set file [get env HOME]/.function if { [length [info procs $func] ] != 0 } { set def [list proc $func {} [info body $func]] } else { set def [list proc $func {} { ... }] } print $def\n $file browse message !vi $file browse shell [concat vi $file] source $file } -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
rh@smds.UUCP (Richard Harter) (09/09/90)
In article <NWQ5K6F@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > > The things that we dispensed with are types (everything > > is a string) and in-fix operators (we use lisp format functions). > That's the bottom line. Sounds like what you have is pretty close to > TCL. Have you looked at it? It looks like this: There is a lot of similarity between Lakota and TCL; certainly the style is similar. Lakota looks like this: procedure change_extension file old new set_list file_fields [split . (file)] point_to_end_of file_fields if not [equal? (file_fields) (old)] return mv (file) [separate . [left_part_of file_fields]].(new) $xxx <-> (xxx) [op arg ...] <-> [op arg ...] block structure by indentation rather than {} However I was in error. Everything is a list of strings rather than a string. Lists have an associated pointer into the list to give a current value. This seems to have drifted quite a ways from Scheme. Followups probably belong in comp.lang.misc. Perhaps the relevance is that that one should know Scheme before tackling extension languages! Oh yes, who is doing TCL and where can one get information on it? -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
peter@ficc.ferranti.com (Peter da Silva) (09/10/90)
In article <180@smds.UUCP> rh@smds.UUCP (Richard Harter) writes: > There is a lot of similarity between Lakota and TCL; certainly the style > is similar. Lakota looks like this: > procedure change_extension file old new > set_list file_fields [split . (file)] > point_to_end_of file_fields > if not [equal? (file_fields) (old)] return > mv (file) [separate . [left_part_of file_fields]].(new) > $xxx <-> (xxx) > [op arg ...] <-> [op arg ...] > block structure by indentation rather than {} > However I was in error. Everything is a list of strings rather than > a string. Lists have an associated pointer into the list to give a > current value. That seems like a handy model. Strictly speaking in TCL you get the value of a variable with [set varname], with $varname being a shortcut like quote in lisp. I have an implementation of property lists (associative arrays) that save and restore to RFC-822 style files. Lists could be implemented the same way. One of the goals of TCL, and I think it's met that goal admirably, is to make it convenient to add new verbs in C. > Oh yes, who is doing TCL and where can one get information on it? John Ousterhout at Berkeley (ouster@sprite.berkeley.edu). I have a port to Xenix 286 and System V/386. Karl Lehenbauer (karl@sugar.hackercorp.com) has a port to the Amiga and a more up-to-date System V port. There is a VMS port out there somewhere. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jeff@aiai.ed.ac.uk (Jeff Dalton) (09/25/90)
In article <6073@castle.ed.ac.uk> expc66@castle.ed.ac.uk (Ulf Dahlen) writes: >In article <5879.9008301913@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.UK (Jeff Dalton) writes: >>> Many of the lisp-haters that I am thinking of used the Xerox InterLisp >>> workstation environment. What got many people were the structured >>> editors. >>I couldn't stand DEDIT (or whatever it was called). Indeed, I'm not >>a big fan of structure editors in general. Lisp is my favorite language >>nonetheless. >Why not? I found it much better than any Emacs-style editor when programming >in Lisp. Of course, SEDIT (the successor to DEDIT) is completely different >and *very* much easier to use. Try it. I suppose we ought to move this to a different newsgroup if it goes on much longer (perhaps Alt.religion.computers is the right place), but I suppose I can risk a brief reply. There's a big difference between SEDIT and DEDIT. I don't much mind SEDIT, but then it's a lot closer to the Emacs-like editors than DEDIT is. However, many (at least) of the people who prefer structure editors felt the same way when the editor was DEDIT. This suggests that there is a fairly fundamental disagreement in there somewhere. I found DEDIT cumbersome to use. Moreover, I want to use the same editor for both text and programs (especially since programs contain text). I also find that structure editors don't indent programs very well. All I have to do in GNU Emacs (when using a good Lisp mode) is make the line breaks (and, very rarely, make a small adjustment). This isn't much more work, but I find a very noticeable improvement in the results. Finally, I like text files. I can mail them to other people, they can load them into their Lisp, and they still look just like I intended. Code produced with a structure editor often looks good only when you use the same structure editor to read it. >Since Lisp is a structured language and since much of the teaching tries >to get this point across, I find structure editors very appropriate to use. >Most students either don't understand Lisp or they understand it _and_ >like structure editors. That's my experience anyway. But it's not my experience. I know quite a few people who understand Lisp, like Lisp, and dislike structure editors. Perhaps the students you know are like the ones in the Edinburgh AI Department. (I note that you're in Edinburgh now, but that's a fairly recent move, I think, so I don't really know about the students you've encountered.) Some of the Ed AI students who use Lisp use Xerox D-machines; most of the others use micro-emacs. Well, micro-emacs is a *terrible* editor for Lisp, because it doesn't have a proper Lisp mode. So I'm not surprised when *those* students either don't understand Lisp or prefer structure editors. Moreover, people who teach Lisp often assume structure editors are better, even if they haven't used a structure editor or a text editor that has a good Lisp mode. Students pick up this attitude, but not because any of the people involved have relevant experience. Of course, some people have given both kinds of editors a fair chance and happen to prefer structure editors. I don't have any quarrel with that so long as they are willing to accept the opposite decision in the same way. -- Jeff