The Subject line is a bit of an overstatement. He's proposing use of
s-expressions for data files, but not for representing programs themselves.
This actually has some precedents. If anyone remembers WAIS, take a look
at the format of its "source" records (the developers of WAIS were mainly
Lisp folks at Thinking Machines). And even Sun has used s-expressions
internally -- take a look at the files in /var/spool/calendar, which are
used by their OpenWindows Calendar Manager application.
S-expression is probably one of the simplest ways to represent nestable
data structures in text. I applaud the article.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
In article <··············@burlma1-snr1.gtei.net>, Barry Margolin <······@bbnplanet.com> wrote:
> The Subject line is a bit of an overstatement.
See the smiley in the body of the posting.
--
http://www.lavielle.com/~joswig
From: Erik Naggum
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3127870484360721@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| See the smiley in the body of the posting.
maybe these smileys destroy communication? maybe they detract from the
effort of being good at sarcasm, jokes, irony, or plain old lunacy.
at one point in my life, I became acquainted with the habit of thinking
that lying was OK if you held two fingers crossed behind your back. I
couldn't figure out why this was important to people. if I lied, it was
to protect something much more important than whoever I lied to, not to
play stupid tricks on people. I could play much better tricks on people
by making them believe something that would hurt them without my actually
telling them anything for which they could directly fault me. it has
since been a puzzling experience to see people fool _themselves_ so
thoroughly that if you told them the truth, they think you're lying.
"I have never had a sexual relationship with that women, Miss Lewinsky."
did you see his hands? could he have crossed his fingers or made some
other secret gesture by which he meant "the laugh's on you, buster"? and
then it got out of hand because "I was only kidding" didn't work with the
kid-me-not Kenneth Starr. maybe all the Democrats were in on it and the
moralistic Republicans will be laughed out of politics? that'd be cool.
meanwhile, there's not a single smiley on Kenneth Starr's pornographic
report, either, not even the smirk you'd expect from someone digging up
so much personal dirt about others. I think he forgot to include it:
"There is Substantial and Credible Information that President Clinton
Committed Acts that May Constitute Grounds for an Impeachment :>"
#:Erik
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* ······@lavielle.com (Rainer Joswig)
>| See the smiley in the body of the posting.
>
> maybe these smileys destroy communication? maybe they detract from the
> effort of being good at sarcasm, jokes, irony, or plain old lunacy.
I think I assumed that the smiley in that posting was just expressing
happiness, like a true smile. I didn't realize it was a "tongue in cheek"
smiley.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
From: Per Bothner
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7a2b86$13h$1@rtl.cygnus.com>
In article <··············@burlma1-snr1.gtei.net>,
Barry Margolin <······@bbnplanet.com> wrote:
>He's proposing use of
>s-expressions for data files, but not for representing programs themselves.
I was surprised he didn't mentioned XML, since this is largely what XML
is all about. (And, yes, they are also writing programming languages
based on XML. See XSL <http://www.w3.org/Style/XSL/> and contrast with
the Scheme-based DSSSL for doing the same task.)
XML is basically S-expressions with some bells and whistles
(as McCarthy pointed out at the Lisp User's conference).
It has a more verbose but easier checkable syntax.
As such, any proposal to use S-expressions *for Java* as Detlefs
proposes is both DOA and wrong-headed. People should be using
XML instead, because more tools will be able to handle it, and
because it will be more familiar to more people.
--
--Per Bothner
Cygnus Solutions ·······@cygnus.com http://www.cygnus.com/~bothner
From: Simon Leinen
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <aavhh2yqun.fsf@limmat.switch.ch>
> The Subject line is a bit of an overstatement. He's proposing use of
> s-expressions for data files, but not for representing programs themselves.
> This actually has some precedents. If anyone remembers WAIS, take a look
> at the format of its "source" records (the developers of WAIS were mainly
> Lisp folks at Thinking Machines). And even Sun has used s-expressions
> internally -- take a look at the files in /var/spool/calendar, which are
> used by their OpenWindows Calendar Manager application.
Yeah, I'm always pleased when I see Lispy syntax hidden in
"mainstream" applications.
Checkpoint Firewall-1 uses S-expressions to store the firewall
configuration that you (are supposed to :-) generate using a
relatively nice GUI.
I think Confluent's "Visual Thought" drawing package also uses a Lispy
representation of its drawings.
> S-expression is probably one of the simplest ways to represent nestable
> data structures in text. I applaud the article.
--
Simon.
From: Raymond Toy
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4n1zjqvv4z.fsf@rtp.ericsson.se>
>>>>> "Simon" == Simon Leinen <·····@limmat.switch.ch> writes:
Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
Simon> "mainstream" applications.
Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
Simon> configuration that you (are supposed to :-) generate using a
Simon> relatively nice GUI.
Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
Simon> representation of its drawings.
Add to that Rational Rose. It looks like the entire UML model is
stored in some Lispy representation, including window position
information.
Ray
From: David J. Cooper Jr.
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36CA1DB5.3DF37507@genworks.com>
Raymond Toy wrote:
> >>>>> "Simon" == Simon Leinen <·····@limmat.switch.ch> writes:
>
> Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
> Simon> "mainstream" applications.
>
> Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
> Simon> configuration that you (are supposed to :-) generate using a
> Simon> relatively nice GUI.
>
> Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
> Simon> representation of its drawings.
>
> Add to that Rational Rose. It looks like the entire UML model is
> stored in some Lispy representation, including window position
> information.
>
> Ray
Visula is an electronic CAD system which stores its database in a Lisp
(S-expression) format. Ironically they only use it internally and it is not
supported or documented - you have to use their (licensed, C-based) API functions to
gain access to their database.
So when I once wrote an ICAD App for circuit board design rule checking of circuits
designed in Visula, a C programmer on the project kindly offered to write some
C routines for me -- to generate the circuit board database into a Lispy syntax
again, that I could easily read into the ICAD app! But at least we were able to
document and support that format!
From: Christopher R. Barry
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87emnpfqvj.fsf@2xtreme.net>
"David J. Cooper Jr." <·······@genworks.com> writes:
> Raymond Toy wrote:
>
> > >>>>> "Simon" == Simon Leinen <·····@limmat.switch.ch> writes:
> >
> > Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
> > Simon> "mainstream" applications.
> >
> > Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
> > Simon> configuration that you (are supposed to :-) generate using a
> > Simon> relatively nice GUI.
> >
> > Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
> > Simon> representation of its drawings.
> >
> > Add to that Rational Rose. It looks like the entire UML model is
> > stored in some Lispy representation, including window position
> > information.
> >
> > Ray
>
> Visula is an electronic CAD system which stores its database in a Lisp
> (S-expression) format.
While we're naming everything that uses Lispy representations we can
think of, let's not forget RTL, the intermediary representation of GNU
compilers.
Christopher
On 16 Feb 1999 22:35:12 +0100, Simon Leinen <·····@limmat.switch.ch>
wrote:
>
>Checkpoint Firewall-1 uses S-expressions to store the firewall
>configuration that you (are supposed to :-) generate using a
>relatively nice GUI.
>
>I think Confluent's "Visual Thought" drawing package also uses a Lispy
>representation of its drawings.
>
I just downloaded a demo of a UML design and reverse engineering
package called Pragmatica. Very nice. Uses lisp as a scripting
language to handle code generation.
Ian
From: Kelly Murray
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36C4A10F.164FC49F@IntelliMarket.Com>
Rainer Joswig wrote:
> http://www.performancecomputing.com/columns/java/9903.shtml
With Sun/Netscape hiring up all the ex-lispers, maybe I can
stop trying to make Lisp better, Java will soon be good enough?
BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
Seems most people laughed at the name. Having Netscape/Sun use it
perhaps makes it not so funny anymore?
My language is now called NiCLOS(tm), the name is funny,
but is the language?
-Kelly Murray ···@niclos.com
From: David Bakhash
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <cxjpv7fmczm.fsf@engc.bu.edu>
Kelly Murray <···@IntelliMarket.Com> writes:
> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
> Seems most people laughed at the name. Having Netscape/Sun use it
> perhaps makes it not so funny anymore?
> My language is now called NiCLOS(tm), the name is funny,
> but is the language?
So what's Lisp-like and what's Java-like in your language? Does your
langage compile down to Java VM code? Do you have a uniform way to
use Java classes via CLOS? I can't see how this is even remotely
possible, considering that:
1) Java has no multiple inheritance
2) Java's class definitions are lexical with respect to methods, if
you consider a class file as a lexical entity.
3) Java has no multimethods, and dispatch depends only on the class of
a single object.
I am surely no expert, but I work closely with Java and Lisp
development, and I really don't see how this would work. Where can
one read about this?
dave
From: Bradley Yearwood
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7aattr$8e6@crl3.crl.com>
In article <···············@engc.bu.edu>, David Bakhash <·····@bu.edu> wrote:
>Kelly Murray <···@IntelliMarket.Com> writes:
>
>> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
>> Seems most people laughed at the name. Having Netscape/Sun use it
>> perhaps makes it not so funny anymore?
>> My language is now called NiCLOS(tm), the name is funny,
>> but is the language?
>
>So what's Lisp-like and what's Java-like in your language? Does your
>langage compile down to Java VM code? Do you have a uniform way to
>use Java classes via CLOS? I can't see how this is even remotely
>possible, considering that:
>
>1) Java has no multiple inheritance
>2) Java's class definitions are lexical with respect to methods, if
> you consider a class file as a lexical entity.
>3) Java has no multimethods, and dispatch depends only on the class of
> a single object.
Could someone please remind me of what exactly we gain by abandoning
Lisp and moving to Java?
Here is all I am able to come up with:
1) Unprecedented momentum of hype
2) Infix notation to avoid frightening dogs and small children
2.5) Reduced wear on parentheses keys on keyboards
3) Some slightly challenging concepts like macros are made to vanish
4) Some slightly suspicious hand-waving claims that useful integrity
checks can be performed on portable bytecode before running it
5) An opportunity for yet another generation of enthusiasts to reinvent
compilers, operating systems, utilities, interactive development
environments, and special purpose hardware for the nth time in ever slower
and bulkier forms
6) An opportunity to slip some sizable loads of ignorance of prior art past
snoozing patent examiners, and thus lay down potentially lucrative legal
minefields
Brad Yearwood ···@crl.com
Cotati, CA
From: Christopher R. Barry
Subject: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <873e46hfyo.fsf_-_@2xtreme.net>
···@crl3.crl.com (Bradley Yearwood) writes:
> Could someone please remind me of what exactly we gain by abandoning
> Lisp and moving to Java?
Well...
* You can download a full, uncrippled Java implementation + IDE for
any major platform absolutely free, and in the case of the JDK even
get the source code. AFAIK you can only do this with the Unix
platform for Common Lisp.
* Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
* True keyboard and mouse control (you can distinguish between a
keyboard down-press and release, so you can give your text fields
Emacs-like incremental searching and bindings or do sophisticated
word completions or any other cool thing you could think up. And of
course, completely standard and cross-platform.
* On Linux (and probably other platforms), you can choose if you want
the threads in a single process (Allegro CL style), or if you want
OS-level threads. It doesn't get any better than that (as if one
standard, cross-platform interface to threads wasn't convenient
enough).
* Graphics, low-level networking, applets in browsers, sound,
look-and-feel support, the kitchen sink.... It actually seems to be
a larger language than Common Lisp, and it gives you all the access
to the primitive hardware, windowing-system and networking
functionality that you really want but in a way that will work on
Unix, Windows, Mac or whatever without even needing to recompile for
that platform. ANSI Common Lisp gives you little more primitive
hardware control and system access than ANSI C (not including CLIM,
but IMO that doesn't really count).
It's funny, my Java instructor at the college was talking about how it
took them 6-8 years or so to start offering C++ classes, but only 3
months to offer Java classes. He said a big factor in this was that
you can download everything for free to all the computers in the
lab. Lisp has yet to be offered, and probably will never be (I think
they teach a little AutoLisp though in the CAD classes).
I think every ounce of hype Java has recieved is deserved. As a
language itself, I think it's better than C, C++, Eiffel, ADA,
etc... and just about any other non logical/functional programming
language out there. But none of the logical/functional languages can
compete with it's level of standardization and the platform
independent system control it gives you. And Common Lisp sure can't
compete with its real cost in most situations (all things considered).
It would be nice if Common Lisp could at least standardise some of the
networking, threads and i/o functionality you get in Java, and if it
had a standard, accessible and reasonably priced GUI toolkit.
In a fantasy world, you could even have Common Lisp compile to Java
byte-code and run wherever the Java Runtime Environment runs and do
all the system-level stuff that Java does (yes, I've heard of Kawa
scheme).
Christopher
From: Marco Antoniotti
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <lwww1i7m0p.fsf@copernico.parades.rm.cnr.it>
······@2xtreme.net (Christopher R. Barry) writes:
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
I am no expert, but I'd almost think that compiling Common Lisp could
be easier than Scheme. The lack of CALL/CC might be a facilitating
factor. Anybody care to comment?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87vhh2f9im.fsf@2xtreme.net>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > It would be nice if Common Lisp could at least standardise some of the
> > networking, threads and i/o functionality you get in Java, and if it
> > had a standard, accessible and reasonably priced GUI toolkit.
>
> I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
At least Mark Kantrowitz's defsystem runs on just about every CL out
there. The Allegro one is kinda nicer, but I think Mark's has all the
functionality you really need to get the job done. Standardization
would not hurt though.
Christopher
From: Marco Antoniotti
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <lwvhh0ou4q.fsf@copernico.parades.rm.cnr.it>
······@2xtreme.net (Christopher R. Barry) writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > ······@2xtreme.net (Christopher R. Barry) writes:
> >
> > > It would be nice if Common Lisp could at least standardise some of the
> > > networking, threads and i/o functionality you get in Java, and if it
> > > had a standard, accessible and reasonably priced GUI toolkit.
> >
> > I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
>
> At least Mark Kantrowitz's defsystem runs on just about every CL out
> there. The Allegro one is kinda nicer, but I think Mark's has all the
> functionality you really need to get the job done. Standardization
> would not hurt though.
MK Defsystem is what I use. I know that it runs on *all* the major CL
implementations. Unfortunately, Mark Kantrowitz disappeared from the
face of the ... well at least this newsgroup.
Franz's is a little nicer, but nut that much. I personally find that
(aparto from a couple of "semantic" glitches) MK:DEFSYSTEM is a very
elegant program.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> MK Defsystem is what I use. I know that it runs on *all* the major CL
> implementations. Unfortunately, Mark Kantrowitz disappeared from the
> face of the ... well at least this newsgroup.
Hum. I did a little searching a while back, and came up with
something that appears to be a recent and valid address for Mark
Kantrowitz. See http://www.ptf.com/ptf/staff/P/kantrowitz.shtml
--
Raymond Wiker, Orion Systems AS
+47 370 61150
From: Felix Winkelmann
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36CB7251.7700@anu.ie>
Marco Antoniotti wrote:
>
> I am no expert, but I'd almost think that compiling Common Lisp could
> be easier than Scheme. The lack of CALL/CC might be a facilitating
> factor. Anybody care to comment?
>
There still is the thing about function-invocation (dynamically), where
you must wrap every procedure into its own class and call some
'apply'-method then. This looks very expensive to me.
Actually, how fast are Scheme-implementations like KAWA ?
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128146248229145@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| * You can download a full, uncrippled Java implementation + IDE for
| any major platform absolutely free, and in the case of the JDK even
| get the source code. AFAIK you can only do this with the Unix
| platform for Common Lisp.
www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
(but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
| * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
none of the CLIM providers charge you money for trying it out before you
decide to buy it or not.
| I think every ounce of hype Java has recieved is deserved.
???
| As a language itself, I think it's better than C, C++, Eiffel, ADA,
"Ada" is named after Ada Lovelace. it's a proper name, not an acronym.
(I helped start the "Ada in Norway" user group in 1985. it's my "other"
language, and my company logo still carries symbols from the Ada world.
that people write ADA, like they write LISP, is a pet peeve.)
| And Common Lisp sure can't compete with its real cost in most situations
| (all things considered).
I don't think you are a competent judge of that, _especially_ not the
parenthetical remark.
| It would be nice if Common Lisp could at least standardise some of the
| networking, threads and i/o functionality you get in Java, and if it had
| a standard, accessible and reasonably priced GUI toolkit.
I'm still confused as to this standardization issue. yes, it would be
nice if it were standardized, but why can't you use something today?
Common Lisp is a standard _because_ it was used and gaining solid support
for a number of really complex things. if people who do not understand
how these things work refuse to use something _until_ it's standard, it
will likely never become a standard, and if, against all odds, it should,
you guys will complain and not use it, anyway.
some of us prefer languages that don't change a lot, that aren't in the
middle of the fight between good and evil, and on which long-term
investments may actually be made with solid profit expectations. Common
Lisp has a problem in that only mature people use it _after_ they have
become disgusted with other languages and their hype.
#:Erik
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87yalyf9q6.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> * ······@2xtreme.net (Christopher R. Barry)
> | * You can download a full, uncrippled Java implementation + IDE for
> | any major platform absolutely free, and in the case of the JDK even
> | get the source code. AFAIK you can only do this with the Unix
> | platform for Common Lisp.
>
> www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
> (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
It's crippled, and you must pay if you want to use it commercially.
> | * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
>
> none of the CLIM providers charge you money for trying it out before you
> decide to buy it or not.
I would feel dishonest if I contacted Franz about getting an
evaluation copy of CLIM. I know that no matter how much I liked it, I
could not at this point in my life afford it.
It would be nice if it could be obtained under the same terms as the
Allegro CL Linux Trial Edition, where you can use it as long as you
like, and not feel obligated to purchase it. After having been able to
use Allegro CL so extensively, I know that at some point in the future
I would definately buy it if using Common Lisp for a big project.
> | It would be nice if Common Lisp could at least standardise some of the
> | networking, threads and i/o functionality you get in Java, and if it had
> | a standard, accessible and reasonably priced GUI toolkit.
>
> I'm still confused as to this standardization issue. yes, it would be
> nice if it were standardized, but why can't you use something today?
I am. When it comes down to it, I still _definitely_ do not prefer
Java over CL. You know, _interpreted_ Garnet gui code seems smoother
and GCs much less than Java (though the pauses are longer - scrollbars
can really suck, gotta take care of this...). There are a number of
things that Java gets right though, like knowing how to actually get a
little mind share.
> Common Lisp has a problem in that only mature people use it _after_
> they have become disgusted with other languages and their hype.
Well, certainly not disgusted yet....
Christopher
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128199041539784@naggum.no>
* Erik Naggum <····@naggum.no>
| www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
| (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
* ······@2xtreme.net (Christopher R. Barry)
| It's crippled, and you must pay if you want to use it commercially.
sigh. what _are_ the other crippled features of this version? that you
can't use it for a full-fledged commercial projects? why do you expect
to be able to do that? the Java freebies are _marketing_ stunts, not
technical arguments. do you have any idea how much money has been sunk
into Java and when the break-even time is expected to be? do you not
realize that it is an instrument of mass market destruction to reduce
Microsoft's hegemony and that Common Lisp doesn't fight that kind of wars?
and I find it slightly amusing that you, too, keep adding conditions that
make you not choose Common Lisp, no matter how people answer your gripes.
| I would feel dishonest if I contacted Franz about getting an evaluation
| copy of CLIM. I know that no matter how much I liked it, I could not at
| this point in my life afford it.
yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
doesn't cost $4000-$7000 to even try out on Unix." which was an outright
lie, so now you would feel dishonest if you asked for a demo version, but
you didn't feel dishonest when you lied to begin with?
| It would be nice if it could be obtained under the same terms as the
| Allegro CL Linux Trial Edition, where you can use it as long as you like,
| and not feel obligated to purchase it.
you can't use it as long as you like. can't you even read licenses?
(yeah, I'm expecting another silly gripe, now.)
you clearly confused what "would be nice" with what people think they
might one day be able to profit from providing you. there ain't no such
thing as a free lunch, remember?
| After having been able to use Allegro CL so extensively, I know that at
| some point in the future I would definately buy it if using Common Lisp
| for a big project.
good for you. I won't hold my breath.
| When it comes down to it, I still _definitely_ do not prefer Java over CL.
are you desperate for reasons to use Common Lisp? is that why you bitch
and moan and invent "flaw" after "flaw" as your previous "flaws" have
proven not to be flaws? it sure doesn't look constructive to me.
| There are a number of things that Java gets right though, like knowing
| how to actually get a little mind share.
yes, by lying, overstating, hyping, misrepresenting the facts, etc.
somehow, I prefer to buy from Common Lisp sales people, not used car
sales people who jumped on the Java bandwagon.
| Well, certainly not disgusted yet....
you will, and the company that'll bring you to it: AT&T.�
#:Erik
-------
� sorry if the ad spoofed on is a little old.
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87hfslfr1p.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> * ······@2xtreme.net (Christopher R. Barry)
> | It's crippled, and you must pay if you want to use it commercially.
>
> sigh. what _are_ the other crippled features of this version?
Can you develop GUIs with it? The whole Java experience has been very
refreshing for me. I downloaded the JDK, Swing, an Emacs IDE and an
8MB tutorial + 3MB of API documentation (and there's still many more
docs to download) all for free and very conveniently and it included a
number of cool demo GUI apps and everything I needed to do anything.
Just like that. It felt *nice*. It's so *easy* to learn as well. It's
like I have 15 million classes to choose from I can just strap
together a neat little app in 10 minutes that I could also probably do
without difficulty in CL but I'd have to write like 10 different
classes first.
> and I find it slightly amusing that you, too, keep adding conditions that
> make you not choose Common Lisp, no matter how people answer your gripes.
I never _chose_ anything. Someone flamed Java and I said what I
thought Java did right. I like my Lisp systems a lot more than my JDK,
but Java has made me aware of stuff I'd like to be able to do in Lisp.
> | I would feel dishonest if I contacted Franz about getting an evaluation
> | copy of CLIM. I know that no matter how much I liked it, I could not at
> | this point in my life afford it.
>
> yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
> doesn't cost $4000-$7000 to even try out on Unix." which was an outright
> lie, so now you would feel dishonest if you asked for a demo version, but
> you didn't feel dishonest when you lied to begin with?
Come on Erik, be fair. If you look at the history of this thread
you'll see that I said that before being informed otherwise. Now tell
me, do you think it would be okay if I asked to evaluate it for free
when I know I can't afford it right now?
> | It would be nice if it could be obtained under the same terms as the
> | Allegro CL Linux Trial Edition, where you can use it as long as you like,
> | and not feel obligated to purchase it.
>
> you can't use it as long as you like. can't you even read licenses?
> (yeah, I'm expecting another silly gripe, now.)
Hmm... sigh. Another assumption on my part. I'll have to get around to
reading that license. Sometime.
> you clearly confused what "would be nice" with what people think they
> might one day be able to profit from providing you. there ain't no such
> thing as a free lunch, remember?
They've got to get us using their products while we're young and still
in school so we know to tell our managers that we want to use CL for a
project once we're hired instead of thinking only in terms of how to
implement a solution using C++, Perl or Java.
All the other people in my Java class have pretty much only seen C,
VB, C++ or whatever and they're probably liking Java a lot more than
even I am.... They'll never learn to think Lisp.
> | After having been able to use Allegro CL so extensively, I know that at
> | some point in the future I would definately buy it if using Common Lisp
> | for a big project.
>
> good for you. I won't hold my breath.
Thanks. I love you to. :-)
> | There are a number of things that Java gets right though, like knowing
> | how to actually get a little mind share.
>
> yes, by lying, overstating, hyping, misrepresenting the facts, etc.
Or by letting me download everything at once and overwhelming me with
all its features and functionality and cool demonstration programs and
documentation and making suddenly aware of some things I'd really like
to be doing in Lisp....
> | Well, certainly not disgusted yet....
>
> you will, and the company that'll bring you to it: AT&T.�
:-)
Christopher
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128224612301670@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| Can you develop GUIs with [Allegro CL 5.0 Lite]?
AFAIK, that was the whole idea, but since I don't use GUIs, I'm not
entirely sure what it can do. but why not try to read what Franz Inc
writes about this and ask them directly? on the Net, people argue about
whether year 2000 is a leap year or not, so it's not as if you can rely
on the answers you get.
| Hmm... sigh. Another assumption on my part. I'll have to get around to
| reading that license. Sometime.
before your next gripe about it would be a good value of "sometime".
| They've got to get us using their products while we're young and still in
| school so we know to tell our managers that we want to use CL for a
| project once we're hired instead of thinking only in terms of how to
| implement a solution using C++, Perl or Java.
does the medical profession provide kids with scalpels and syringes while
still in school so they get used to using them by the time some of them
will enter medical school? if not, why not?
seriously, I wonder where this wacky idea of yours comes from. lots of
people think that you have to accomodate kids, novices, and idiots in
order to _succeed_. that isn't quite true -- you need to do that to make
a mass market with millions of users. this always has enormous costs in
what you have to do to attract them. e.g., you think in terms of
"unnecessary inconveniences" instead of understanding that programming is
all about removing inconveniences that arise in your particular
application, and you want people to give you things instead of creating
them. that's lazy in the wrong way.
| All the other people in my Java class have pretty much only seen C, VB,
| C++ or whatever and they're probably liking Java a lot more than even I
| am.... They'll never learn to think Lisp.
oh, they will, in time. people come to Lisp for reasons of their own.
you can't push Lisp on people -- you can't push good taste on people.
#:Erik
From: John Morrison
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36ced522.482765059@news.tiac.net>
Hello All;
I have been gritting my teeth during this exchange, and I finally
succumbed to the urge to make a few points:
Erik Naggum <····@naggum.no> wrote:
>* ······@2xtreme.net (Christopher R. Barry)
>| Can you develop GUIs with [Allegro CL 5.0 Lite]?
>
> AFAIK, that was the whole idea, but since I don't use GUIs, I'm not
(1) Based upon my experience, most of us must implement GUI-based
applications because our target customers will not consider
command-line-based applications (this seems to become increasingly
true as either vendors' competition increases, or the solutions in the
problem domain "mature"). Considering that GUIs tend to be
code-intensive, the ease with which we can implement them is of
paramount importance.
>
>| They've got to get us using their products while we're young and still in
>| school so we know to tell our managers that we want to use CL for a
>| project once we're hired instead of thinking only in terms of how to
>| implement a solution using C++, Perl or Java.
>
> does the medical profession provide kids with scalpels and syringes while
> still in school so they get used to using them by the time some of them
> will enter medical school? if not, why not?
>
> seriously, I wonder where this wacky idea of yours comes from. lots of
> people think that you have to accomodate kids, novices, and idiots in
> order to _succeed_. that isn't quite true -- you need to do that to make
> a mass market with millions of users. this always has enormous costs in
> what you have to do to attract them. e.g., you think in terms of
> "unnecessary inconveniences" instead of understanding that programming is
> all about removing inconveniences that arise in your particular
> application, and you want people to give you things instead of creating
> them. that's lazy in the wrong way.
(2) When I try to float either Linux-based or LISP-based solutions
within my company, my job is made harder because the people I'm trying
to convince have been witness to flames both from Linux zealots who,
by and large, are seriously out of touch with the constraints of
commercial enterprises, and from LISPers who use ad hominem attacks
(e.g., "wacky," "idiots"), who spout non-sequiturs (responding with
inaccurate metaphors to the very real problem of new hires'
unfamiliarity with Lisp-ish ways of thinking), and who don't get the
Big Picture (if "programming is all about" a single thing, that thing
is making money, not removing "inconveniences" -- whether money is an
issue for you personally or not is irrelevant by trivial inspection).
So, these people react in kind (e.g., "idiots," "wacky") when I try to
get them to adopt LISP and/or Linux technology. I, for one, would
appreciate it if people did not make it unnecessarily difficult for
their (and my) pet technologies to gain acceptance py pissing off the
people I have to convince.
>| All the other people in my Java class have pretty much only seen C, VB,
>| C++ or whatever and they're probably liking Java a lot more than even I
>| am.... They'll never learn to think Lisp.
>
> oh, they will, in time. people come to Lisp for reasons of their own.
> you can't push Lisp on people -- you can't push good taste on people.
Clearly, one can push neither good taste nor good manners nor good
sense upon people. More's the pity.
(3) And, this is probably the most important point -- people will NOT
come to Lisp despite its superiority (I trust I do not have to defend
the superiority assertion in this forum).
The Law of Increasing Returns will assure that languages like Lisp,
and Smalltalk, and Ada (even with billions of US DoD backing) will
become increasingly marginalized. Anybody who reads this newsgroup
and/or worked at one of the Lisp hardware/software companies will
attest to this phenomenon.
Market share is everything. There is a positive feedback thing going
with languages (and with browsers and with desktop OSes), and Lisp is
most definitely NOT the beneficiary. This manifests itself as: FUD
about Lisp from experienced programmers, lack of Lisp-aware new grads,
lack of tools, and resultant exorbitant cost of commitment to Lisp
technology. So, Lisp adoption rate continues to fall ever behind
C++/Java adoption rate. I feel that I would have more luck pushing
NeXT hardware on our staff and customers than I would Lisp software
(at least no-one in the dwindling NeXT community calls them "idiots").
-jm
==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
From: Kent M Pitman
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <sfwogmp1199.fsf@world.std.com>
··@nospam.mak.com (John Morrison) writes:
> ... So, these people react in kind (e.g., "idiots," "wacky") when I try to
> get them to adopt LISP and/or Linux technology. I, for one, would
> appreciate it if people did not make it unnecessarily difficult for
> their (and my) pet technologies to gain acceptance py pissing off the
> people I have to convince. ...
I didn't really have any problem with your analysis, but it did seem
to omit the "positive" ... and I don't mean tone--I don't much care
about your tone--it's fine by me (albeit sad) if you're sounding upset
or even angry with present affairs--I wish that weren't so but I
understand it. Still, I'm curious: You went on about what you see
that you don't like. What would you LIKE to see to help you make LISP
adoption easier?
From: John Morrison
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36d02325.568272963@news.tiac.net>
Hello Kent (et al);
Kent M Pitman <······@world.std.com> wrote:
>··@nospam.mak.com (John Morrison) writes:
>
>> ... So, these people react in kind (e.g., "idiots," "wacky") when I try to
>> get them to adopt LISP and/or Linux technology. I, for one, would
>> appreciate it if people did not make it unnecessarily difficult for
>> their (and my) pet technologies to gain acceptance py pissing off the
>> people I have to convince. ...
>
>I didn't really have any problem with your analysis, but it did seem
>to omit the "positive" ... and I don't mean tone--I don't much care
>about your tone--it's fine by me (albeit sad) if you're sounding upset
>or even angry with present affairs--I wish that weren't so but I
>understand it. Still, I'm curious: You went on about what you see
>that you don't like. What would you LIKE to see to help you make LISP
>adoption easier?
For brevity's sake, I'm just going to assert that Lisp is better for
implementing solutions to my problem domain (networked virtual
environments, and, in particular, the large amount of knowledge that
must be represented, particular to support the "AI" that is required)
than are the alternatives (C, C++, Java, Ada, etc.).
I run into a couple things that make it harder to implement Lisp-based
solutions:
(1) The complete unfamiliarity with Lisp by both new graduates and
experienced programmers. They all know C/C++/Java, and do not
understand either Lisp or the real benefits offered by code=data, etc.
Even if they were willing to be trained, it would take several months
(say 3, for argument's sake), and (at fully loaded labor rates for an
average salary around here) this will run me around $60,000 US per
engineer. That's Real Money. That would hammer my cost structure.
Obviously, it will also hold up schedule as people get trained.
(2) Those engineers for whom salary and/or "career development" are
important are often unwilling to be trained in Lisp, because the real
demand in the marketplace is for MFC C++ types. A lengthy stint
writing Lisp may not be as undesirable as one writing either Ada or
Jovial, but it's pretty close. (Contrast this with the eagerness of
staff to learn Java, for which there is building demand.)
(3) Those that *are* familiar with Lisp, especially those with more
"passing" exposure, think it's Big, Bloated, and Slow (and there's a
kernel of truth in this depending upon which implementation you're
talking about).
(4) It is my understanding that the cost of commercial-grade Lisp
tools exceeds those of C/C++/Java. And, as we are learning in our
pricing of our commercial products, it is tough to sell software at a
price point above that of the hardware (and the hardware price is
constantly falling).
(5) The fact that the tools one needs to solve the "other" parts of
the given problem (e.g., for me: 3D out-the-window rendering,
networking protocol stacks, 2D GUIs, etc.) drags the "core" effort in
the C++/Java direction. If one were to link in a Lisp subsystem, this
means one has to incur the overhead of *both* runtime support packages
(not a Good Thing for a real-time, memory-constrained application such
as a computer game, which we also produce) and write yet more foreign
function interface code to ship data/results back and forth across the
boundary (not a good thing when one is trying to deliver under a
fixed-price contract, which we also do, and also bad for memory
footprint).
On to the "positive." I think, for Lisp to Win Big (I believe this is
the Politically Correct term), we need to:
(A) Make available a freely-available, high-volume, high-quality,
Lisp-native development platform which would run on ubiquitous
hardware. I believe this must be a grass roots effort in the same way
commercial UNIX companies were unable to blunt the NT juggernaut, but
a grass roots effort (i.e., Linux) seems to be able.
I believe such a system would be useful in education, helping to
produce new hires who understand Lisp. I believe such a system would
enable established programmers to become Lisp-aware in the same way
that Linux has helped the UNIX cause (there are a lot of dual-boot
Linux boxes in programmers' homes). I believe such a system, should
it be delivered in sufficient volume, would help alleviate the effects
of problems (1) through (4) (and maybe eventually (5)) above.
I, personally, would prefer an entire Lisp-native OS on vanilla x86 PC
hardware ("Poor Man's Lisp Machine") to a Lisp implementation on
Linux. As a former LispMer, and a former Lisp-under-UNIXer, the
qualitative difference in the experience seems significant to me.
Having Linux teaches you C, C++, Python, PERL, sh, elisp, script-fu,
etc., but it sure as hell doesn't show you the potential of a
Lisp-native environment.
To this end, and with an eye to being "positive," I am trying to
piggy-back support for a Lisp-ish OS on my efforts to produce a
freeware JavaOS clone (I plan to replace the JVM with a Lisp VM). If
anybody is interested in the status of the effort, I can either point
you at a public mail reflector, or send a summary.
(B) Stop generating ill-will toward and within our community through
our impolitic choice of words in communications forums such as this
one. The ill-will generated makes it tougher for us to both
collectively and individually overcome these problems.
-jm
==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
From: David B. Lamkins
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <l0%z2.39634$202.19125089@news1.teleport.com>
In article <··················@news.tiac.net> , ··@nospam.mak.com (John
Morrison) wrote:
[snip]
>
> For brevity's sake, I'm just going to assert that Lisp is better for
> implementing solutions to my problem domain (networked virtual
> environments, and, in particular, the large amount of knowledge that
> must be represented, particular to support the "AI" that is required)
> than are the alternatives (C, C++, Java, Ada, etc.).
This is an important qualification. There are things that Lisp is good for,
and other things that it doesn't do as well. The key to being successful
with Lisp -- or with any other tool -- is matching it to an appropriate
task.
Unfortunately, too many people ignore good tools for inappropriate reasons.
You've done a good job of listing the common arguments to stick with tools
and techniques that are widely used. I'd like to provide a brief
counterpoint to each:
>
> I run into a couple things that make it harder to implement Lisp-based
> solutions:
>
> (1) The complete unfamiliarity with Lisp by both new graduates and
> experienced programmers. They all know C/C++/Java, and do not
> understand either Lisp or the real benefits offered by code=data, etc.
> Even if they were willing to be trained, it would take several months
> (say 3, for argument's sake), and (at fully loaded labor rates for an
> average salary around here) this will run me around $60,000 US per
> engineer. That's Real Money. That would hammer my cost structure.
> Obviously, it will also hold up schedule as people get trained.
I graduated from college in the late 1970s. At that time (and I don't know
whether this was universal or whether I was just fortunate) a computer
science education not only stressed concepts, but also gave us an
opportunity to produce implementations of these concepts using a wide range
of languages and operating systems.
Over the years I've kept abreast of trends in computer science education
through discussions with friends, coworkers, and job applicants. Based upon
this input, I've formed the impression that universities are (especially at
the undergraduate level) increasingly teaching their students about
particular computer _technologies_, and hoping (vainly, I might add) that
the students will discover the underlying foundations on their own.
That universities aren't teaching students about Lisp is a symptom of a
larger problem. Lisp is omitted from curricula because it doesn't neatly
fit into any of the technology areas being taught in lieu of computer
science.
Your point about training and startup costs is a good one. But it's
certainly easier to account for pure training costs than it is to account
for low productivity and low quality that results from using a tool or
technique that is not appropriate for each part of the system you're trying
to build. If you want to estimate potential failure costs, take the
probability that your project will fail (I've seen estimates in the 0.5 to
0.75 range for the software industry, whatever that is) and multiply by the
total outlay for your projected project budget. Then estimate how much it
will cost you to support the product if you do ship it; use the incremental
costs for past products as a guide. Now how expensive does your $60K figure
look? Of course, you have to estimate your productivity, success
probability, and support costs for "doing the right thing". But the point
is, training is not a pure expense.
Finally, and this is not related to the main point of this section: My rule
of thumb for a fully loaded labor rate is about two time salary. Maybe you
have incredibly high overhead, relative to my expectations. If not, then
I'll infer that you're paying your _average_ engineer US$30K per quarter, or
US$120K per year.
>
> (2) Those engineers for whom salary and/or "career development" are
> important are often unwilling to be trained in Lisp, because the real
> demand in the marketplace is for MFC C++ types. A lengthy stint
> writing Lisp may not be as undesirable as one writing either Ada or
> Jovial, but it's pretty close. (Contrast this with the eagerness of
> staff to learn Java, for which there is building demand.)
You're absolutely right. I see this every day, everywhere I look in the
industry. And it puzzles me. Why are employers willing to let their
employees subvert the goals of the organization to favor their own career
development? Or, look at it another way: Why are employers willing to offer
on-the-job-training for the future employees of their competitors?
(I have some thoughts on the reasons behind this, although they're not
really relevant to this discussion. If you want a pithy preview, how about
this: "The fish rots from the head.")
>
> (3) Those that *are* familiar with Lisp, especially those with more
> "passing" exposure, think it's Big, Bloated, and Slow (and there's a
> kernel of truth in this depending upon which implementation you're
> talking about).
Big and Slow: Again, this gets back to the universities, I think. They
don't invest in commercial-quality Lisp systems, and don't have staff
capable of properly teaching Lisp. So the student uses a hobbyist Lisp
implementation and learns that Lisp has the list as its only data structure.
Oh, and they _have_ to do everything using recursive functions. Interesting
though this may be as a pedagogical exercise, it isn't Lisp in the
commercial sense.
Bloated: I'm not sure what you mean by this. But have you looked at the
disk and memory footprint of a modern C++ IDE and compared it to that of a
modern Common Lisp IDE?
>
> (4) It is my understanding that the cost of commercial-grade Lisp
> tools exceeds those of C/C++/Java. And, as we are learning in our
> pricing of our commercial products, it is tough to sell software at a
> price point above that of the hardware (and the hardware price is
> constantly falling).
Sure it does. The market is significantly smaller for Lisp development
tools. I'm amazed at the fact that the typical price differential (ignoring
the promotional pricing that applies, say, to Java) is about a factor of two
or three.
As for the impact on selling price, I think you're overstating the effect of
the cost of your tools. Particularly if your labor rates are as high as you
claim.
And if you're talking about royalties rather than development costs, what is
the per-copy royalty rate that you would incur if you had to pay for a Lisp
runtime license? When you develop in C++, do you ever license any
third-party components, or do you develop everything from scratch?
>
> (5) The fact that the tools one needs to solve the "other" parts of
> the given problem (e.g., for me: 3D out-the-window rendering,
> networking protocol stacks, 2D GUIs, etc.) drags the "core" effort in
> the C++/Java direction. If one were to link in a Lisp subsystem, this
> means one has to incur the overhead of *both* runtime support packages
> (not a Good Thing for a real-time, memory-constrained application such
> as a computer game, which we also produce) and write yet more foreign
> function interface code to ship data/results back and forth across the
> boundary (not a good thing when one is trying to deliver under a
> fixed-price contract, which we also do, and also bad for memory
> footprint).
You may be making the right choice for your situation. I'm not arguing
against your personal choice, just against some of the arguments you've
presented in the general case.
>
> On to the "positive." I think, for Lisp to Win Big (I believe this is
> the Politically Correct term), we need to:
>
> (A) Make available a freely-available, high-volume, high-quality,
> Lisp-native development platform which would run on ubiquitous
> hardware. I believe this must be a grass roots effort in the same way
> commercial UNIX companies were unable to blunt the NT juggernaut, but
> a grass roots effort (i.e., Linux) seems to be able.
Yeah, this would be nice, but I'm not holding my breath. There are a lot of
freely available implementations of Common Lisp and Scheme. Most of them
are not suitable for hard use. Most of the people who are capable of
producing a quality implementation are already so doing as part of their
livelihood.
Don't underestimate the amount of deep knowledge that's required to do a
good Common Lisp implementation. There has already been one failed attempt
at producing a Lisp OS using a bazarre-style organization; it failed for
lack of qualified contributors.
>
> I believe such a system would be useful in education, helping to
> produce new hires who understand Lisp. I believe such a system would
> enable established programmers to become Lisp-aware in the same way
> that Linux has helped the UNIX cause (there are a lot of dual-boot
> Linux boxes in programmers' homes). I believe such a system, should
> it be delivered in sufficient volume, would help alleviate the effects
> of problems (1) through (4) (and maybe eventually (5)) above.
I think you're overestimating the desire of universities to teach Lisp, and
the effect that Linux has had on the development of commercial software.
But that's just my belief as compared to yours.
>
> I, personally, would prefer an entire Lisp-native OS on vanilla x86 PC
> hardware ("Poor Man's Lisp Machine") to a Lisp implementation on
> Linux. As a former LispMer, and a former Lisp-under-UNIXer, the
> qualitative difference in the experience seems significant to me.
> Having Linux teaches you C, C++, Python, PERL, sh, elisp, script-fu,
> etc., but it sure as hell doesn't show you the potential of a
> Lisp-native environment.
>
> To this end, and with an eye to being "positive," I am trying to
> piggy-back support for a Lisp-ish OS on my efforts to produce a
> freeware JavaOS clone (I plan to replace the JVM with a Lisp VM). If
> anybody is interested in the status of the effort, I can either point
> you at a public mail reflector, or send a summary.
Well, I hope you succeed. Unfortunately for me, your plans are incompatible
with the instruction-set-architecture of my platform of choice. <g>
>
> (B) Stop generating ill-will toward and within our community through
> our impolitic choice of words in communications forums such as this
> one. The ill-will generated makes it tougher for us to both
> collectively and individually overcome these problems.
Yes. Words have specific connotations and can be chosen to deliver a
message at multiple levels, conveying both text and subtext. But given the
wide range of interests, abilities, and personal agendas found in a public
forum such as this, I think we're doing quite well. I personally don't find
anything offensive in the tone of postings to this group, even when they
become heated. My only regret is that the dozen or so students who pass
through here each semester don't come back as regulars; I'm sure it's not
because they are treated poorly or see comp.lang.lisp as a hostile
enviroment.
>
> -jm
>
>
> ==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
> ==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
> ==== vox:617-876-8085 x115
> ==== fax:617-876-9208
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
There are many ways to abbreviate something, but only one way not to.
From: Kent M Pitman
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <sfwww1b9uns.fsf@world.std.com>
··@nospam.mak.com (John Morrison) writes:
> I run into a couple things that make it harder to implement Lisp-based
> solutions:
>
> (1) The complete unfamiliarity with Lisp by both new graduates and
> experienced programmers. They all know C/C++/Java, and do not
> understand either Lisp or the real benefits offered by code=data, etc.
> Even if they were willing to be trained, it would take several months
> (say 3, for argument's sake), and (at fully loaded labor rates for an
> average salary around here) this will run me around $60,000 US per
> engineer. That's Real Money. That would hammer my cost structure.
> Obviously, it will also hold up schedule as people get trained.
I agree this is a serious problem.
Personally, I'm so dismayed that people aren't getting taught Lisp
that I'm looking seriously into writing a textbook myself. I've
started making lists of what I think belongs in it, what the book
design will look like, etc.
If any high school or college instructors are on this newsgroup who
might use a book I wrote and would like to tell me what they consider
essential or useful to cover in terms of content, they should send me
private e-mail and we can talk about it. (······@world.std.com)
> (2) Those engineers for whom salary and/or "career development" are
> important are often unwilling to be trained in Lisp, because the real
> demand in the marketplace is for MFC C++ types. A lengthy stint
> writing Lisp may not be as undesirable as one writing either Ada or
> Jovial, but it's pretty close. (Contrast this with the eagerness of
> staff to learn Java, for which there is building demand.)
I agree this is an issue.
The very best way this can be solved is for each and every person who
thinks this is a critical issue to get in the habit of regularly identifying
to their sales person these three things:
1. What I need tomorrow and would be willing to pay a premium for.
Vendors can't create stuff instantly. If you don't tell them what you
will need. Don't be surprised when it's not ready on time. A regular
dialog with your sales person so that they will know in a timely way
where the dollars can be made is very important. This is the duty of
every individual. If you fail in your duty, you lose your right to say
that vendors are not responsive.
2. What I need today, cannot get anywhere, and would pay premium for.
You should be willing to pay a premium for this, and should be honest
about that fact to your vendor. I think one of the biggest obstacles
to good license fees from vendors on some products is the concern that
they won't have money to support them overall. People have reacted
well to the many free and near-free offerings from vendors, but those
are "entry to market" vehicles to let you get interested at a fair price.
If you are being successful, the vendors must be able to be successful,
and they can't do that if you are not paying them something. The best
thing is for you to identify ways they can stay ahead of the curve and
that is about identifying things that will offer you new leverage and
new reasons to use Lisp in the future.
If you do not identify anything for which you would pay a premium
now or in the future, a vendor has every right not to listen to
you. Also, if you regularly identify things for which you would
pay a vendor premium and then you fail to follow through, you're
hurting the vendors by sending them down the wrong path and should
also expect not to be listened to at some point. I think the
community as a whole has been guilty of both of these things, by
the way. It hasn't always been politic of me to say so while in
the employ of vendors but while I am not, I want to make sure to
get it on the record.
3. What I need today, can get elsewhere (be specific) and therefore do not
expect to pay a premium for.
Be realistic but honest about this. Vendors have only finite resources
so can't give you everything for free, nor is it easy for them to be
continually surveying the market to find out what "equivalent
functionality" is crowding them out. They need to know that things
they are providing or working on have become "commodities" both so they
can lower their price expectations and so that they can consider
licensing rather than reinventing such technology. (Though, note:
licensing will cost them money and you should understand this doesn't
mean it wil also be free.)
Vendors often have marketeers who don't use this stuff themsleves,
so may not be able to tell what's equivalent. Asking them to talk to
the people at their companies who do know in order to do a
product-by-product competitive analysis may keep the technical people
so busy that they don't produce the product you want. So you, the
customer, have to be prepared to help the sales and marketing folks
by offering clear and concise information about what you're comparing
to and why you expect a certain price point.
Vendors are caught in a bind, though, so help them where you can
and be wiling to make reasonable compromises yourself. They can't
expect to remain attractive to people from other languages without
providing competitive prices.
4. What you need in the way of price accomodations, personal support,
or whatever to personally expand the number of paying Lisp users.
There's no point in talking to a vendor about expanding just the
number of users if they're not going to pay. Talk to maintainers
of free systems about that, and if you're confused by the fact that
some vendors have graciously offered free systems as a way of expanding
their base of paying users, don't say it too loud because I'm sure at
the point that vendors think you're not ever planning to pay, they'll
have a lot less reason to continue with free offerings. Vendors have
to stay in business. They have to eventually make money. But if
they can make "slightly less money now" in exchange for more money
down the road, as long as they're not losing money in the interim,
they may accomodate you. (I don't have any agreements with vendors
that this is true; it's just predicted by economics.) But it's up
to you to make a credible case for why they should accomodate you,
since accomodating you is often a risk. Mostly, I think, vendors
accomodate this by eval copies and the free editions they offer.
But maybe you have another idea. Share it. Or don't be surprised
if they aren't as smart as you in thinking it up.
(Having written this list, I find myself wishing the Association of
Lisp Users (ALU) had some membership card with a contract that required
its members to engage in this kind of dialog on a routine basis. I don't
know if it would really help... but it's a thought. Maybe something to
talk about at the next meeting.)
If vendors can't properly separate "premium" offerings (ones they
can make money on) from "commodity offerings, ask yourself: How can
they make money? They have to charge a total amount that lets them
break even at the end of the day, and hopefully grow.
Sure, it would be great if they did the kind of volume that C++ does so
they could have a lower profit margin per seat and make it up on numbers
of seats. But that's not something they can do overnight. And so they
have to stay in business in the interim, or else they have to take a big
chance and risk for both them and for us that they won't be in business
the next day. Reasonably identifying how much cash you have to spend
and what value you need from them in exchange for that cash to justify
having spent it is ultimately the core of everything else I've said above.
> (3) Those that *are* familiar with Lisp, especially those with more
> "passing" exposure, think it's Big, Bloated, and Slow (and there's a
> kernel of truth in this depending upon which implementation you're
> talking about).
Actually, it's getting smaller (relatively speaking) every day.
But I know what you mean.
This divides up into several specifics...
Size of Spec. This can be offset by smaller teaching texts.
I hope to write one such, sort of in pennance for having produced
the ANSI CL spec. I think that needed to be big, but I don't think
everyone has to learn from something that size.
Size of Implementation. The advent of DLL-structured Lisps has been
around for a long time, but is finally making commercial headway.
We are now somewhat armed with tools to counter this.
Bloat. This is something to take up with vendors on a case-by-case
basis because it suggests an application containing stuff it couldn't.
I suspect most tree-shaken Lisp apps really aren't that out-of-line
these days with equivalent apps written in other languages.
Speed. For many kinds of things, you can't even write them in other
languages and there's no basis for comparison. People often mean this
to say "If I could have figured this out in C++, I'm sure it would
have been faster". We have to confront that head on. There are some
cases where people did do implementations in other languages, and they
are faster. The MD5 stuff discussed recently, and GIF stuff if you've
ever tried to decode LZW, are examples of things where the memory
management is legitimately hard to write in Lisp because the pattern
of memory use it calls for is very at-odds with Lisp's. But these are
not what most programs are made out of, and it's better in these rare
cases just to call out to a foreign library if they turn out to be
problems. Most people who like Lisp don't worry that other languages
should never be used--they just want Lisp available when it is needed.
> (4) It is my understanding that the cost of commercial-grade Lisp
> tools exceeds those of C/C++/Java. And, as we are learning in our
> pricing of our commercial products, it is tough to sell software at a
> price point above that of the hardware (and the hardware price is
> constantly falling).
I agree completely. I addressed this above.
The phrase I'm using is the "commodity baseline". Lisp vendors must
know where that line is and price products consistently with it. This
is the single biggest danger to Lisp sales that I, as now just an
outsider, perceive because it is the way all customers I know go about
pricing solutions to problems...
> (5) The fact that the tools one needs to solve the "other" parts of
> the given problem (e.g., for me: 3D out-the-window rendering,
> networking protocol stacks, 2D GUIs, etc.) drags the "core" effort in
> the C++/Java direction. If one were to link in a Lisp subsystem, this
> means one has to incur the overhead of *both* runtime support packages
> (not a Good Thing for a real-time, memory-constrained application such
> as a computer game, which we also produce) and write yet more foreign
> function interface code to ship data/results back and forth across the
> boundary (not a good thing when one is trying to deliver under a
> fixed-price contract, which we also do, and also bad for memory
> footprint).
Coming up with native runtimes in these other languages might be a way
to fix this. I would welcome feedback about places where Lisp should
accomodate this in the actual language design. But it's also a vendor
level activity. Especially for Java, since for a long time C has been
the "platform-independent platform" and in fact Lisp vendors are pretty
used to having the C library there to take advantage of, but Java is becoming
now the "platform-independent platform" (at least, among people who don't
mind its present loss of speed). Worrying about this problem you cite
is necessary anyway if you are also worried that you may one day find a
Java machine you want to run on and want to have a set of support libraries
handy so that you don't have to start from scratch.
> On to the "positive." I think, for Lisp to Win Big (I believe this is
> the Politically Correct term), we need to:
>
> (A) Make available a freely-available, high-volume, high-quality,
> Lisp-native development platform which would run on ubiquitous
> hardware. I believe this must be a grass roots effort in the same way
> commercial UNIX companies were unable to blunt the NT juggernaut, but
> a grass roots effort (i.e., Linux) seems to be able.
This would be fun, but I'm not sure it would work. I'll be happy to watch
you try.
> I believe such a system would be useful in education, helping to
> produce new hires who understand Lisp. I believe such a system would
> enable established programmers to become Lisp-aware in the same way
> that Linux has helped the UNIX cause (there are a lot of dual-boot
> Linux boxes in programmers' homes). I believe such a system, should
> it be delivered in sufficient volume, would help alleviate the effects
> of problems (1) through (4) (and maybe eventually (5)) above.
>
> I, personally, would prefer an entire Lisp-native OS on vanilla x86 PC
> hardware ("Poor Man's Lisp Machine") to a Lisp implementation on
> Linux. As a former LispMer, and a former Lisp-under-UNIXer, the
> qualitative difference in the experience seems significant to me.
> Having Linux teaches you C, C++, Python, PERL, sh, elisp, script-fu,
> etc., but it sure as hell doesn't show you the potential of a
> Lisp-native environment.
All this is true.
> To this end, and with an eye to being "positive," I am trying to
> piggy-back support for a Lisp-ish OS on my efforts to produce a
> freeware JavaOS clone (I plan to replace the JVM with a Lisp VM). If
> anybody is interested in the status of the effort, I can either point
> you at a public mail reflector, or send a summary.
>
> (B) Stop generating ill-will toward and within our community through
> our impolitic choice of words in communications forums such as this
> one. The ill-will generated makes it tougher for us to both
> collectively and individually overcome these problems.
A good note to close on.
From: Marco Antoniotti
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <lwbtilw76s.fsf@copernico.parades.rm.cnr.it>
Kent M Pitman <······@world.std.com> writes:
> 1. What I need tomorrow and would be willing to pay a premium for.
>
> Vendors can't create stuff instantly. If you don't tell them what you
> will need. Don't be surprised when it's not ready on time. A regular
> dialog with your sales person so that they will know in a timely way
> where the dollars can be made is very important. This is the duty of
> every individual. If you fail in your duty, you lose your right to say
> that vendors are not responsive.
>
> 2. What I need today, cannot get anywhere, and would pay premium for.
>
....
>
> 3. What I need today, can get elsewhere (be specific) and therefore do not
> expect to pay a premium for.
>
...
> 4. What you need in the way of price accomodations, personal support,
> or whatever to personally expand the number of paying Lisp users.
>
> There's no point in talking to a vendor about expanding just the
> number of users if they're not going to pay.
....
There are many truths in what you write, yet, as I said many, many
times over here, I am puzzled. I apologize for the boring repetition,
but I personally do not see any reason whatsoever, why the vendors
(all of them) should not dump their *incompatible* DEFSYS and start
ship MK:DEFSYSTEM as a standard. Of course this is just one example.
If the vendors do not see the advantages of economics "network
effects", too bad.
And now... back to Java programming.....
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjg17wkpq3.fsf@tfeb.org>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> There are many truths in what you write, yet, as I said many, many
> times over here, I am puzzled. I apologize for the boring repetition,
> but I personally do not see any reason whatsoever, why the vendors
> (all of them) should not dump their *incompatible* DEFSYS and start
> ship MK:DEFSYSTEM as a standard. Of course this is just one example.
Well mk:defsystem isn't *that* great. But more to the point they
probably have large commitments to their own defsystems which they use
to build their lisps. Changing that may be crippling when you have
other stuff to do, especially as it may involve changing where files
live &c which can be a real pain if you're using some config
management system (it shouldn't be, but it often is). Even apart from
internal considerations like these, they may have supported customers
who *also* have commitments to the old one, so they have to support
both for at least some time. And are there licensing issues?
--tim
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128662231198281@naggum.no>
[ I fail to see the difference between this and previous pointless gripes
about Lisp's future, except that this one is a little more intelligent
than the previous ones. I predict we will get nowhere, and John Morrison
will be exactly as unhappy with Lisp when all is said and done, his point
being, as so often before, to legitimize his being unhappy with Lisp. ]
* ··@nospam.mak.com (John Morrison)
| I run into a couple things that make it harder to implement Lisp-based
| solutions:
|
| (1) The complete unfamiliarity with Lisp by both new graduates and
| experienced programmers.
"complete" is one of those pointless exaggerations that hint at the lack
of a constructive element to this discourse. some people don't like
words like "idiot" and blame them for everything, while I tend to regard
people who talk in absolutes and completeness and other obvious nonsense
to be a much more serious problem, because they _don't_ use words that
make people react unless they _really_ know the territory. in other
words, someone might _believe_ John Morrison, while I take it that when I
talk about the mass market as needing to address idiots, not a single
person among you fail to understand that I'm _not_ talking about the
people John Morrison claim I do, namely managers, but the likes of Jerry
Springer's interview objects and perhaps audience, that the mass market
needs to address. "idiot" connotes disdain for such a mass market.
"complete" _denotes_ lack of honesty and rational, constructive purpose.
| (2) Those engineers for whom salary and/or "career development" are
| important are often unwilling to be trained in Lisp, because the real
| demand in the marketplace is for MFC C++ types.
lots of people find Common Lisp on their own. e.g., the two moderately
high profile Common Lisp projects in Oslo at the moment both attract
programmers who want to work with Common Lisp. obviously, these people
want something for their own lives and well-being, and cannot be assumed
to want to sacrifice their carreers the way the people John Morrison has
chosen to focus on would if they had Lisp forced on them.
while I'm sure that "willingness to be trained" is an issue, I have
seldom seen people exert any willingness to be trained in _anything_ they
don't believe in. those who discover something on their own are those
who _matter_. you can't _make_ people appreciate something, especially
not something as elegant as Lisp. in time, they will discover it. the
clue to any successful convincing is to care about the people who
respond, and _completely_ ignore the people who don't. if you start
focusing on the nearly 6 billion people who do _not_ respond to anything
you say about Common Lisp, you are headed for a depression.
| (3) Those that *are* familiar with Lisp, especially those with more
| "passing" exposure, think it's Big, Bloated, and Slow (and there's a
| kernel of truth in this depending upon which implementation you're
| talking about).
this nonsense is another strong hint that this is just an effort to
"help" John legitimize his negative emotions.
those who are _familiar_ with Lisp, think none of those things, as has
been evident for a very long time. those who are _not_ familiar with
Lisp, but who have heard of it from people like John Morrison, believe
it's big, bloaded, and slow, for these are prejudicial emotions, and are
as such antithetical to "familiarity".
| (4) It is my understanding that the cost of commercial-grade Lisp tools
| exceeds those of C/C++/Java. And, as we are learning in our pricing of
| our commercial products, it is tough to sell software at a price point
| above that of the hardware (and the hardware price is constantly falling).
this puzzles me. if you buy a moderately fast and large machines these
days and stuff it with the hot Microsoft products, you will end up paying
much less than 1/4 of the total package for the hardware. also, most
bean-counters have _two_ budgets: acquisitions and operations. while it
is evident from the market that acquisition costs are disproportionally
underweighted, operational expenditures do tell people something, once
experienced, and if they can back away from them, they do.
however, the operating words here are "our pricing". John Morrison is
clearly working for a company that has _requirements_ that he is unhappy
that the Common Lisp vendors do not address, and he's taking it out on
Lisp in general, instead of getting along with reality and adjusting his
own expectations so they don't result in frustration. again, this has
very little do with Lisp, and a lot to do with John Morrison being unappy
that he cannot use Lisp. this is a recurring theme on this newsgroup,
and I predict that no matter what any one of us or all of us collectively
do to help John Morrison, he will come out of this unhappy about Lisp.
| (5) The fact that the tools one needs to solve the "other" parts of the
| given problem ... drags the "core" effort in the C++/Java direction.
| [the memory/resource argument]
so your problem is going to be solved in C++ and/or Java. so what? what
the <beep> does this have to do with Lisp? why is _Lisp_ to be blamed
for yet another failure of managers and other people to think straight?
people fail to get the point and they waste resources _everywhere_ at
_all_ times and for all sorts of reasons, some of them irrational and
rational only according to highly personal premises. to single out _one_
of the contenders in such a situation and blaming it for everything is
itself irrational and unlikely to be more than consequences of highly
personal premises.
| (A) Make available a freely-available, high-volume, high-quality,
| Lisp-native development platform which would run on ubiquitous hardware.
another instance of "if you think big enough, you never have to do it."
| (B) Stop generating ill-will toward and within our community through our
| impolitic choice of words in communications forums such as this one. The
| ill-will generated makes it tougher for us to both collectively and
| individually overcome these problems.
sigh. more stupid blame-shifting away from his own personal problems,
and after having been "positive" in the sense of "if the sky was always
blue, the sun always shining, and we had peace on earth, then Lisp would
Win Big", it is obvious that nothing whatsoever will make John Morrison
happy enough about Lisp to have any consequence for anything anywhere.
let's just _end_ this stupid process of legitmizing yet another fool who
wants an excuse to dislike Lisp, and who will come away disliking Lisp or
at least not using it no matter _what_ happens or anybody does.
#:Erik
From: John Morrison
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36d76aed.121983002@news.tiac.net>
Erik Naggum <····@naggum.no> wrote:
> sigh. more stupid blame-shifting away from his own personal problems,
> and after having been "positive" in the sense of "if the sky was always
> blue, the sun always shining, and we had peace on earth, then Lisp would
> Win Big", it is obvious that nothing whatsoever will make John Morrison
> happy enough about Lisp to have any consequence for anything anywhere.
>
> let's just _end_ this stupid process of legitmizing yet another fool who
> wants an excuse to dislike Lisp, and who will come away disliking Lisp or
> at least not using it no matter _what_ happens or anybody does.
>
>#:Erik
Oh, my. An invitation to a flame-fest! Geez, I haven't done this in
*years*. Wonder if I still remember how? Hmm... Maybe it's like
riding a bicycle. Let's give it a whirl, shall we?
[sound of knuckles cracking ]
[sound of someone blowing dust off the "CAPS LOCK" key]
Hmm... Let's try the Minimalist Approach -- in how few words can I
respond, yet still make my point? "Troll." Hmm... No, "troll" is a
Linux-associated term -- Bad Form in a LISP forum.
Wait, wait! I'm just warming up -- it's been a while!
Hmm... Let's try the Computational Metaphor Approach. "attempt to
write device ···@naggum.no" failed -- read-only device." Hmm... While
it *does* make *a* point, people might think it's simply a permission
problem, and draw the wrong lesson.
Hmm... Let's try the Dismissive Approach with a Scatalogical Chaser.
"Gee, Erik. You ought to get more fiber in your diet. More fruits,
vegetables, and whole grains. It'll keep you regular, you know?
There are also several fine products, all available over the counter,
and without presciption, that can really help. It's important,
because if you keep all that stuff bottled up inside, it'll eventually
come out of your mouth." Hmm... While it *is* more insulting, and it
*does* make a point about what issues from Erik's keyboard, it is
still a little too content-free.
What to do? What to do?
Let's try the juvenile, time-honored, Mine Is Bigger Than Yours
Approach, with a novel Dismissive Twist. "As co-founder, President,
and CTO of one of the fastest-growing technology companies in New
England
(http://www.us.deloitte.com/fast500/usfast50/98regions/neweng_list97.htm),
I could rush in and announce to the other senior staff: 'Hey Guys!
I've found the Secret! It's been handed to me on a silver platter!
Even if we've managed to grow our revenues from zero to over $5M
without the benefit of venture capital, we're fools, FOOLS, I tell
you! We could be so much MORE! The Secret was Revealed to me by a
Lone Voice in the Wilderness! The Prophet, the Oracle, the Fount of
Knowledge, the Wizard Erik Naggum! ... Huh? I mean, uh, no, sure his
growth has been ZERO for over 12 YEARS so he doesn't have to deal with
DISTRACTIONS like MANAGING GROWTH or FINDING qualified staff, but,
but, this means he's got TIME to THINK DEEPLY about these problems
he's neither faced nor solved, because he's not DISTRACTED by the
PROBLEMS THEMSELVES! It's like being a Buddhist Monk -- you must be
DETACHED to SEE CLEARLY! ... Huh? I mean, uh, no, he doesn't get
nearly the per-hour labor rates we manage to get as a measure of value
for services, but, but, this is because he can leverage LOW COST as a
COMPETITIVE WEAPON to SLAY the non-LISP competition! ... Huh? I mean,
uh, no he doesn't sell products like we do, so sure, he doesn't have
to deal with pesky things like customers with filthy LUCRE who want
value for their money, or management of long-term SUPPORT COSTS for
products, or determining whether customers actually WANT SOMETHING
enough to PAY for it, but, but, this enables a CLARITY OF THOUGHT so
he can focus on the PROBLEM and DISPENSE KNOWLEDGE without having to
ACTUALLY SOLVE THE PROBLEM IN PRACTISE! It's very, very, uh, very
MANAGEMENT CONSULTANT! People pay Big Money for that, and we're
getting it FREE! ... Huh? I mean, uh, no, sure he works mostly out of
his house, so he doesn't have to deal with lots of people issues like
organizing dozens of co-workers, or serving hundreds of customers, or
supporting tens of thousands of people expecting VALUE for the
PURCHASE of his SOFTWARE like WE do, but, but, this enabled him to, in
SECLUSION, divine the ESSENTIAL HOLISTIC CENTRALITY of the SECRET for
SUCCESS and ULTIMATE VICTORY -- you must FLAME OTHERS and BEAT THEM
INTO ACCEPTANCE so they eventually either SUBMIT or GO AWAY! ... Huh?
Guys? Guys? Where are you going? Guys? Come back!"
Hmmm... Guess I *have* lost it. How *distressing*.
==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3129100669535781@naggum.no>
* ··@nospam.mak.com (John Morrison)
| Oh, my. An invitation to a flame-fest!
you're quite mistaken. it was an invitation for you to refocus, away
from the stupidity that you get reprimanded for. some people see that,
others are hopelessly lost on a track of increasing hostilities and will
forever fight back no matter what you tell them if they see or imagine
hostilities or a need to save face or some other stupidities. I see that
you are of the latter kind. it was necessary to know this and now we all
do. sorry about not reading your flame.
#:Erik
From: John Morrison
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36d83362.173299571@news.tiac.net>
Apologies if this is posted twice -- I got a delivery error the first
time.
Erik Naggum <····@naggum.no> wrote:
>* ··@nospam.mak.com (John Morrison)
>| Oh, my. An invitation to a flame-fest!
>
> you're quite mistaken. it was an invitation for you to refocus, away
> from the stupidity that you get reprimanded for. some people see that,
> others are hopelessly lost on a track of increasing hostilities and will
> forever fight back no matter what you tell them if they see or imagine
> hostilities or a need to save face or some other stupidities. I see that
> you are of the latter kind. it was necessary to know this and now we all
> do. sorry about not reading your flame.
>
>#:Erik
You're quite mistaken. Yes, I expressed frustration about the
"barriers to acceptance" (I believe that is the trendy term here)
against Lisp. I shared with the group the economically-based causes
of those "barriers to acceptance" that I personally have encountered
in building a successful multi-million dollar per annum software
consulting and product business, in which I wish it were economically
rational for me to use more Lisp than I currently do. As seems to be
your habit, you engaged in ad hominem attacks which betrayed a
profound ignorance of the economic considerations involved in
determining "acceptance" of technology.
History is littered both with the corpses of companies who failed to
achieve "acceptance" of superior technology (e.g., Symbolics, et al)
and with the monopolies that, in stark contrast, successfully achieved
"acceptance" of grossly inferior competing technologies (e.g., the
WIntel duopoly).
The over-riding lesson you should "refocus" upon is this: given that
software, unlike other industries, enjoys almost infinite marginal
return upon investment after Unit Zero is produced, and that the "sunk
costs" of customers who must *invest* to use such products (e.g.,
learning C++, win32s, WindowsXX) is extremely high, then volume of
delivery (a.k.a., "market share") will be the single most important
determinant of "acceptance" because it drives recurring costs down to
zero and it avails itself of the Law of Increasing Returns in a
positive-feedback loop.
In plain English, "grow or die."
Netscape knows it. The Open Source community knows it. Microsoft
knows it (dumping IE to combat Netscape, and FUDing and
"de-commoditizing" SMB protocols to combat Linux). I know it. I
presume "some people" in this group know it.
If you don't know it, too, even after it has been brought to your
attention, it must be either: because you choose to remain willfully
ignorant (and believe somehow, in spite of your ignorance, and the
utter lack of a demonstrable track record to support your views, that
*you* have the right to "reprimand" people with differing views into
silence), or because you are too stupid to learn. It was necessary to
know that either of these were true, and now we all do. Sorry about
not being successful in helping you understand this.
-jm
==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128520463609367@naggum.no>
* ··@nospam.mak.com (John Morrison)
| I have been gritting my teeth during this exchange, and I finally
| succumbed to the urge to make a few points:
I'm sure it helps you get over your failures and frustrations to be able
to point to someone else and confidently say "it's his fault, everything
is his fault, because he said "whacky", so now I'm off the hook, and you
can't blame me for anything, anymore", but could you _please_ try to
discuss your real agenda, instead of furthering your hidden agenda by
posting a bunch of negative nonsense that is clearly completely unrelated
to your _real_ problems?
if you want to know why Lisp doesn't win around you, find a mirror.
#:Erik
From: Duane Rettig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4678xx99j.fsf@beta.franz.com>
··@nospam.mak.com (John Morrison) writes:
(1) [GUI stuff]
I am not a GUI expert, so will not attempt to answer this.
My Company recognizes the need for GUI orientation, and I agree,
but I am a low-level man and am thus not qualified to answer
this question.
> (2) When I try to float either Linux-based or LISP-based solutions
> within my company, my job is made harder because the people I'm trying
> to convince have been witness to flames both from Linux zealots who,
> by and large, are seriously out of touch with the constraints of
> commercial enterprises, and from LISPers who use ad hominem attacks
> (e.g., "wacky," "idiots"), who spout non-sequiturs (responding with
> inaccurate metaphors to the very real problem of new hires'
> unfamiliarity with Lisp-ish ways of thinking), and who don't get the
> Big Picture (if "programming is all about" a single thing, that thing
> is making money, not removing "inconveniences" -- whether money is an
> issue for you personally or not is irrelevant by trivial inspection).
I will also not argue this point; you alone know your standing within
your Company, and whether or not you can argue lisp to the decision-
makers. But I do have a meta-comment: Do you realize that by calling
some people "zealots", you are succumbing to the same name-calling
to which you are accusing others? Which is worse: wacky, idiot, or
zealot? It probably depend on the context. If you want to make an
anti-name-calling argument, you make your point more strongly by not
yourself calling names.
> (3) And, this is probably the most important point -- people will NOT
> come to Lisp despite its superiority (I trust I do not have to defend
> the superiority assertion in this forum).
Sometimes you do have to defend it here, but at least not to me.
But, in fact, I disagree that people will not come to Lisp... my
statement is "People continue to come to Lisp despite its lack of
popularity."
> The Law of Increasing Returns will assure that languages like Lisp,
> and Smalltalk, and Ada (even with billions of US DoD backing) will
> become increasingly marginalized. Anybody who reads this newsgroup
> and/or worked at one of the Lisp hardware/software companies will
> attest to this phenomenon.
I read this newsgroup, and I work at a Lisp software company, and I
do _not_ attest to this phenomenon. It may be true that lisp
programmers get tired of the hype and tend to go underground, and
in fact that may make it seem like they "disappear", but they are
there. We even have customers who have left lisp to do their app
in a "better" (i.e. more mainstream) language, and then come back
to lisp after a year or two and a failed C++ project. Some go to
a hybrid approach, using Lisp for the decision-making and some
more popular language for the toolkits they have to offer. Do you
call these people lispers or non-lispers? (I call them smart, to
use all of the tools available to them).
> Market share is everything.
If you believe that, then you probably wrote off Apple, who had less
than 5% of personal-computer market share last year, and who now has
over 10% and climbing.
Instead, I would say that a good idea that works is everything.
> There is a positive feedback thing going
> with languages (and with browsers and with desktop OSes), and Lisp is
> most definitely NOT the beneficiary. This manifests itself as: FUD
> about Lisp from experienced programmers, lack of Lisp-aware new grads,
> lack of tools, and resultant exorbitant cost of commitment to Lisp
> technology. So, Lisp adoption rate continues to fall ever behind
> C++/Java adoption rate.
I do not share this point of view. Many people are disgusted with
C++, and I would venture to say that many people use C++ compilers,
the majority of programming efforts are not in C++, but in C.
Java has supplanted C++ as "the language to use", and it does do many
things that C++ was not able to do, but because it is hyped beyond
its current ability, I am afraid for its future; it may fall hard,
depending on how distant the promises are from the actual delivery
(I make the personal observation that how hard any language or concept
falls seems to be proportional to the difference between how much it
promises and how much it delivers, i.e. the hype factor). Currently,
Java's hype factor is large, because of it huge fast rise and thus
the expectations people place on it. Perhaps its technology will
catch up, but perhaps not. We are working to position ourselves to
catch some of this fallout, if and when it happens.
If you look only at market forerunners for languages to use, you will
never see the stable languages like Lisp and Smalltalk, both of which
are successful, both to vendors and to users of the languages.
> I feel that I would have more luck pushing
> NeXT hardware on our staff and customers than I would Lisp software
> (at least no-one in the dwindling NeXT community calls them "idiots").
Are NeXT boxes even manufactured anymore? If not, then it would be
a serious mistake to suggest using them to your company. On the other
hand, Lisp is still being improved upon and supported, and is available
in more forms and on more platforms than has ever been. You could make
your most convincing argument to your company, not by telling them of
pros and cons, but by actually building a small app in lisp and showing
them technically how easy it is to build, maintain, and improve.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: John Morrison
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36d03589.572980822@news.tiac.net>
Hello Duane;
Duane Rettig <·····@franz.com> wrote:
>··@nospam.mak.com (John Morrison) writes:
>I will also not argue this point; you alone know your standing within
>your Company, and whether or not you can argue lisp to the decision-
>makers. But I do have a meta-comment: Do you realize that by calling
>some people "zealots", you are succumbing to the same name-calling
>to which you are accusing others? Which is worse: wacky, idiot, or
>zealot? It probably depend on the context. If you want to make an
>anti-name-calling argument, you make your point more strongly by not
>yourself calling names.
Not to be polemical, but I thought I was using the word accurately
(you should check out www.slashdot.org postings if you think the
following definition is inappropriate):
Zeal"ot (?), n. [F. z�lote, L. zelotes, Gr. . See Zeal.] One who is
zealous; one who engages warmly in any cause, and pursues his object
with earnestness and ardor; especially, one who is overzealous, or
carried away by his zeal; one absorbed in devotion to anything; an
enthusiast; a fanatical partisan.
However, your point is taken, and I shall, uh, unilaterally disarm. I
hope that subsequent events/messages/follow-ups show that this was a
rational thing to do.
>Sometimes you do have to defend it here, but at least not to me.
>But, in fact, I disagree that people will not come to Lisp... my
>statement is "People continue to come to Lisp despite its lack of
>popularity."
Well, I sure hope you're right, although my direct personal experience
runs counter to your statement. Most of the "AI" work in my company's
problem domain used to be done in Lisp, and the whole industry segment
(approx $1.5 Billion US) has pretty much abandoned Lisp. We used to
have LispMs galore. Boy, those were the days. (I guess it could be
worse -- we could have to go back to working in Ada again. Geez, the
mere thought makes we want to take a shower.)
>I read this newsgroup, and I work at a Lisp software company, and I
>do _not_ attest to this phenomenon. It may be true that lisp
>programmers get tired of the hype and tend to go underground, and
>in fact that may make it seem like they "disappear", but they are
>there. We even have customers who have left lisp to do their app
>in a "better" (i.e. more mainstream) language, and then come back
>to lisp after a year or two and a failed C++ project. Some go to
>a hybrid approach, using Lisp for the decision-making and some
>more popular language for the toolkits they have to offer. Do you
>call these people lispers or non-lispers? (I call them smart, to
>use all of the tools available to them).
Well, I sure hope you're right, here, too. However, somehow I had the
impression that the Lisp market's growth rate was not, uh, exceeding
industry average. I was thinking of Symbolics, LMI, TI's Lisp
efforts, and I read something about other local (MA, US) companies
having RIFs.
>If you believe that, then you probably wrote off Apple, who had less
>than 5% of personal-computer market share last year, and who now has
>over 10% and climbing.
The enemy of my enemy is my friend, so I'll wish them Godspeed.
However, I won't place any money on them (e.g., I won't buy their
stock) -- it seems a little early to be declaring victory for those
guys. Especially with the rise of sub $500 WIntel boxes.
>Java has supplanted C++ as "the language to use", and it does do many
>things that C++ was not able to do, but because it is hyped beyond
>its current ability, I am afraid for its future; it may fall hard,
>depending on how distant the promises are from the actual delivery
>(I make the personal observation that how hard any language or concept
>falls seems to be proportional to the difference between how much it
>promises and how much it delivers, i.e. the hype factor). Currently,
>Java's hype factor is large, because of it huge fast rise and thus
>the expectations people place on it. Perhaps its technology will
>catch up, but perhaps not. We are working to position ourselves to
>catch some of this fallout, if and when it happens.
Well, this will certainly be an interesting couple of years, eh?
You've got competition for that -- I'm sure you've been tracking
Microsoft's Java competitor, "Cool?" (Hmm... what do you think their
marketing pitch is, eh?)
>If you look only at market forerunners for languages to use, you will
>never see the stable languages like Lisp and Smalltalk, both of which
>are successful, both to vendors and to users of the languages.
Sorry, but I had trouble both parsing this and drawing the conclusion
you meant me to draw. Do you mean "never see" as in "never see sales
figures," or "never see growth," or "never see market share," or
something else entirely?
>> I feel that I would have more luck pushing
>> NeXT hardware on our staff and customers than I would Lisp software
>> (at least no-one in the dwindling NeXT community calls them "idiots").
>
>Are NeXT boxes even manufactured anymore? If not, then it would be
>a serious mistake to suggest using them to your company. On the other
I was using hyperbole to make my point, and, obviously, I failed
miserably. I just meant to say, metaphorically, that Lisp was deader
to the people I work with than was an obviously dead hardware company.
>hand, Lisp is still being improved upon and supported, and is available
>in more forms and on more platforms than has ever been. You could make
>your most convincing argument to your company, not by telling them of
>pros and cons, but by actually building a small app in lisp and showing
>them technically how easy it is to build, maintain, and improve.
Actually, I did that. At some personal investment in time, I wrote a
Scheme subsystem for our numerous configuration files (so that we
could use one syntax for them all instead of having different file
formats for each of them, in addition to all the other Lisp benefits).
However, the other programmers still don't know Lisp, those that do
have had a hard time interfacing Lisp to C/C++ in the past and are
disinclined to repeat the experience, and newer development efforts
have gone back to writing their own purpose-built config files with
yacc and lex, etc.
Perhaps, if I'd had a real budget instead of just spare time, I'd have
bought a commercial-grade Lisp implementation, but I'm not sure lack
of quality of the implementation was the problem...
-jm
==== John Morrison ==== ··@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
From: Duane Rettig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4emnivmsu.fsf@beta.franz.com>
··@nospam.mak.com (John Morrison) writes:
> >But, in fact, I disagree that people will not come to Lisp... my
> >statement is "People continue to come to Lisp despite its lack of
> >popularity."
>
> Well, I sure hope you're right, although my direct personal experience
> runs counter to your statement. Most of the "AI" work in my company's
> problem domain used to be done in Lisp, and the whole industry segment
> (approx $1.5 Billion US) has pretty much abandoned Lisp. We used to
> have LispMs galore. Boy, those were the days. (I guess it could be
> worse -- we could have to go back to working in Ada again. Geez, the
> mere thought makes we want to take a shower.)
It sounds like you and your Company went through both the AI summer
and winter. But could you enlighten me as to exactly what this
industry segment is that you are in? I would be interested to know,
if noone else.
> >I read this newsgroup, and I work at a Lisp software company, and I
> >do _not_ attest to this phenomenon. It may be true that lisp
> >programmers get tired of the hype and tend to go underground, and
> >in fact that may make it seem like they "disappear", but they are
> >there. We even have customers who have left lisp to do their app
> >in a "better" (i.e. more mainstream) language, and then come back
> >to lisp after a year or two and a failed C++ project. Some go to
> >a hybrid approach, using Lisp for the decision-making and some
> >more popular language for the toolkits they have to offer. Do you
> >call these people lispers or non-lispers? (I call them smart, to
> >use all of the tools available to them).
>
> Well, I sure hope you're right, here, too. However, somehow I had the
> impression that the Lisp market's growth rate was not, uh, exceeding
> industry average. I was thinking of Symbolics, LMI, TI's Lisp
> efforts, and I read something about other local (MA, US) companies
> having RIFs.
Coming from a hardware background myself, I interpret the demise of
the Lisp-specific-hardware industry as being one of sheer numbers;
orders of magnitude more manpower were spent over the last 20 years
speeding up General-Purpose computers than could possibly be spent
on lisp-specific hardware. And this phenomenon is not limited to
Lisp-specific-hardware; the GP hardware industry has overtaken and
subsumed the vector-hardware industry as well as other special-purpose
hardware. That is why the current Lisp providers tend to remain on
(or at least connect to) GP hardware.
> >If you believe that, then you probably wrote off Apple, who had less
> >than 5% of personal-computer market share last year, and who now has
> >over 10% and climbing.
>
> The enemy of my enemy is my friend, so I'll wish them Godspeed.
> However, I won't place any money on them (e.g., I won't buy their
> stock) -- it seems a little early to be declaring victory for those
> guys. Especially with the rise of sub $500 WIntel boxes.
I certainly would not claim victory for Apple (though perhaps the victory
is in being alive and not dead). But, as usual, the wars continue,
and each side gains and loses ground at various times.
> >Java has supplanted C++ as "the language to use", and it does do many
> >things that C++ was not able to do, but because it is hyped beyond
> >its current ability, I am afraid for its future; it may fall hard,
> >depending on how distant the promises are from the actual delivery
> >(I make the personal observation that how hard any language or concept
> >falls seems to be proportional to the difference between how much it
> >promises and how much it delivers, i.e. the hype factor). Currently,
> >Java's hype factor is large, because of it huge fast rise and thus
> >the expectations people place on it. Perhaps its technology will
> >catch up, but perhaps not. We are working to position ourselves to
> >catch some of this fallout, if and when it happens.
>
> Well, this will certainly be an interesting couple of years, eh?
The previous few years have already been interesting as we catch some
of the fallout from C++ failures.
> You've got competition for that -- I'm sure you've been tracking
> Microsoft's Java competitor, "Cool?" (Hmm... what do you think their
> marketing pitch is, eh?)
I don't, but my Company does. Whatever Microsoft does will become popular,
because it comes from Microsoft. Interesting, though, that this little
tussle blows away the compatibility and universality argument for Java?
> >If you look only at market forerunners for languages to use, you will
> >never see the stable languages like Lisp and Smalltalk, both of which
> >are successful, both to vendors and to users of the languages.
>
> Sorry, but I had trouble both parsing this and drawing the conclusion
> you meant me to draw. Do you mean "never see" as in "never see sales
> figures," or "never see growth," or "never see market share," or
> something else entirely?
Yes, it was pretty badly worded. Let me try again:
Some people focus only on the top dog in any particular industry, and
it's as if the others don't exist. Many even measure success in this
black-and-white dichotomy. However, there are many industry players
that are still successful even while never achieving the #1 spot, and
if you are one of those people that focus only on #1, you will never
notice these other successes; it will be as if they don't exist.
Whether this statement applies to you, only you know.
> >> I feel that I would have more luck pushing
> >> NeXT hardware on our staff and customers than I would Lisp software
> >> (at least no-one in the dwindling NeXT community calls them "idiots").
> >
> >Are NeXT boxes even manufactured anymore? If not, then it would be
> >a serious mistake to suggest using them to your company. On the other
>
> I was using hyperbole to make my point, and, obviously, I failed
> miserably. I just meant to say, metaphorically, that Lisp was deader
> to the people I work with than was an obviously dead hardware company.
Ah, I see now. It's just that I hadn't heard the "lisp is dead" argument
for a couple of years, now, and the hyperbole escaped me.
The "lisp is dead" argument used to come across my email many times
during the late 80s and early 90s; the dead of the AI winter. Now that
Spring is back, I hardly ever hear it anymore, so I wasn't prepared for it.
> >hand, Lisp is still being improved upon and supported, and is available
> >in more forms and on more platforms than has ever been. You could make
> >your most convincing argument to your company, not by telling them of
> >pros and cons, but by actually building a small app in lisp and showing
> >them technically how easy it is to build, maintain, and improve.
>
> Actually, I did that. At some personal investment in time, I wrote a
> Scheme subsystem for our numerous configuration files (so that we
> could use one syntax for them all instead of having different file
> formats for each of them, in addition to all the other Lisp benefits).
> However, the other programmers still don't know Lisp, those that do
> have had a hard time interfacing Lisp to C/C++ in the past and are
> disinclined to repeat the experience, and newer development efforts
> have gone back to writing their own purpose-built config files with
> yacc and lex, etc.
Perhaps the problems you were trying to solve wasn't as real or as
important in the minds of the other programmers as it was in your mind.
> Perhaps, if I'd had a real budget instead of just spare time, I'd have
> bought a commercial-grade Lisp implementation, but I'm not sure lack
> of quality of the implementation was the problem...
The availability of the lisp should also not be a problem. Check out
the free implementations from the commercial vendors.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Kelly Murray
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36D1C7F2.381AA09C@IntelliMarket.Com>
> ··@nospam.mak.com (John Morrison) writes:
..(approx $1.5 Billion US) has pretty much abandoned Lisp. We used to
> > have LispMs galore. Boy, those were the days.
Many people believe Lisp's road to recovery is
better integratation with the existing non-lisp applications.
But in my view Lisp stopped becoming something special
when it no longer was an integrated whole as the operating system,
and had to integrate with the hostile foreign C world of DOS/Unix.
Its advantages were no longer as compelling and instead it
become more a disadvantage.
So my approach is to return to the glory days by going back
what created the glory, but clearly not just repeating the
mistakes and technology of the past, as SymbolicsIII(or IV?) is doing.
The good news is that in todays world integrating with non-lisp
applications doesn't require integrating with other OS, but
using standard network protocols.
Moreover, the web has enabled web-based Lisp applications to be
indistinguishable from non-Lisp applications, and there can
be NO non-lisp integration at all in many cases.
As they say, "On the internet, nobody knows your a dog".
Nobody knows if you're a sly fox either.
Should I (or we) shutup, and keep this "business plan" quiet
and not tip-off the competition? That's pretty silly.
Maybe if we had mega-millions of dollars and a chance in hell to
overtake the "bigboys" in the software industry.
Frankly, if Sun releases a robust, extensible, more advanced
and integrated JavaOS for Java, that would be fantastic.
If the Lisp Community doesn't see the opportunity and do it,
why shouldn't someone else?
Kelly Murray ···@niclos.com
In an article recently published at a free software conference,
http://www.tunes.org/~fare/articles/ll99/index.en.html
I argue that the fate of languages such as LISP,
that integrate metaprogramming, is tied to that of free software:
metaprogramming allows arbitrary gains in software productivity
and reliability, in as much as it is used to cover a larger software
community in space and time. Proprietary software partitioning
prevents such communities from growing past intellectual property barriers;
only free software allows to take full advantage of metaprogramming.
I give explanations why proprietary software leads to bad quality
low-level languages, and excludes integrated high-level environments,
and why the metaprogramming style of LISP becomes a disadvantage,
not an advantage, when the infrastructure is proprietary.
This suggests that people who wish LISP to succeed, instead of
seeing the advent of ad-hoc metaprogramming kluges as done in Perl,
should participate in free LISP software and implementation projects.
If LISP vendors want to win big, they should publish as free software
at least the system infrastructure,
and sell service and possibly peripheral software.
My article concludes that systems such a Free LISP systems
*shall* eventually overcome the market;
it only depends on us how fast and how well.
Kelly Murray <···@IntelliMarket.Com> writes:
> The good news is that in todays world integrating with non-lisp
> applications doesn't require integrating with other OS, but
> using standard network protocols.
> Moreover, the web has enabled web-based Lisp applications to be
> indistinguishable from non-Lisp applications, and there can
> be NO non-lisp integration at all in many cases.
> As they say, "On the internet, nobody knows your a dog".
> Nobody knows if you're a sly fox either.
Right. Hardware is becoming cheap and interconnectable,
with standard low-level communication protocols.
This gives opportunity for great software to provide high-level services
without being tied to underlying platform.
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
The last good thing written in C was Franz Schubert's Symphony number 9.
-- Erwin Dieterich <·····@cvt12.verfahrenstechnik.uni-stuttgart.de>
Francois-Rene Rideau <····@ZhengHe.augustin.thierry> wrote:
: In an article recently published at a free software conference,
: http://www.tunes.org/~fare/articles/ll99/index.en.html
: I argue that the fate of languages such as LISP,
: that integrate metaprogramming, is tied to that of free software:
: metaprogramming allows arbitrary gains in software productivity
: and reliability, in as much as it is used to cover a larger software
: community in space and time. Proprietary software partitioning
: prevents such communities from growing past intellectual property barriers;
: only free software allows to take full advantage of metaprogramming.
hmm, autolisp won BIG and is proprietary vendor controlled software, not
enhanced (the language) since its ancient beginnings.
it's not free at all, it's even more expensive than most of the commercial
lisps. nevertheless is AutoLISP the worldwide most used lisp type language
and an incredible success, dispite all of its flaws.
it is indeed a low-level, bad quality language.
VB is another proprietary, low-level, bad quality language which won big.
the next paragraph is still true, but the last sentence not.
: I give explanations why proprietary software leads to bad quality
: low-level languages, and excludes integrated high-level environments,
: and why the metaprogramming style of LISP becomes a disadvantage,
: not an advantage, when the infrastructure is proprietary.
: This suggests that people who wish LISP to succeed, instead of
: seeing the advent of ad-hoc metaprogramming kluges as done in Perl,
: should participate in free LISP software and implementation projects.
: If LISP vendors want to win big, they should publish as free software
: at least the system infrastructure, and sell service and possibly
: peripheral software.
lisp vendors should better attract more commercially successful users and
markets. dssl will not make it, guile will not make it, lisp will not win
big. it will win big if someone could persuade bill gates that a lisp like
language will be better than vb. java had had the potential and strong
supporters.
or lisp vendors (or anyone else) should invest in expensive lisp machine
or ai type of stuff.
: My article concludes that systems such a Free LISP systems
: *shall* eventually overcome the market;
: it only depends on us how fast and how well.
we can just hope... :)
but it's not that realistic.
---
Reini Urban
AutoLISP FAQ http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Reini Urban <······@xarch.tu-graz.ac.at> writes:
> or lisp vendors (or anyone else) should invest in expensive lisp machine
> or ai type of stuff.
i think lisp is *more* than AI. sure it's good for AI, but you can
use it for so much more. lisp is stuck in an AI perception rut.
people think that's all it's good for -- not true. i'd like to see
the non-AI applications of lisp receive more emphasis.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
In article <··············@sophia.axel.nom>, Johan Kullstam
<········@ne.mediaone.net> wrote:
>i think lisp is *more* than AI. sure it's good for AI, but you can
>use it for so much more. lisp is stuck in an AI perception rut.
>people think that's all it's good for -- not true. i'd like to see
>the non-AI applications of lisp receive more emphasis.
I couldn't agree more. For example, with suitable libraries for basic
numerical operations, Lisp is fantastic for data analysis. I do all my
neurophysiology research analysis with Lisp.
ej
--
E.J. Chichilnisky
Nospam: to send me mail, please remove the X characters from my email address.
From: Kent M Pitman
Subject: Re: Why LISP shall overcome (was Re: Java...)
Date:
Message-ID: <sfwemmy43c5.fsf@world.std.com>
Johan Kullstam <········@ne.mediaone.net> writes:
> Reini Urban <······@xarch.tu-graz.ac.at> writes:
>
> > or lisp vendors (or anyone else) should invest in expensive lisp machine
> > or ai type of stuff.
>
> i think lisp is *more* than AI. sure it's good for AI, but you can
> use it for so much more. lisp is stuck in an AI perception rut.
> people think that's all it's good for -- not true. i'd like to see
> the non-AI applications of lisp receive more emphasis.
Agreed. The quote goes "a mind once stretchd by a new idea never
regains its original shape". Lisp's mind has been stretched by AI to
embrace the hardest of the world's prblems. Many other languages
haven't been thus stretched, in many cases because they would snap
under the stress. Other languages are often good for what they are
good with because people have learned not to stress them much and have
adjusted their goals to be doable with the existing technology. Lisp
had traditionally been about actually going after your real goals, not
about going after goals you make up by dumbing down what you wish you
could do... There are many hard problems in the world for which Lisp
is well-suited. The key is getting people to use Lisp to do them.
(Note: I do think there are some superficial obstacles to such
acceptance. But the fact that there are such superficial obstacles is
not itself a triviality. Lisp needs to confront them head on, not
pretend they are not there. If you're dying of thirst in a desert and
someone approaches carrying water, your problem may seem trivially
solved. But if that person doesn't like you and isn't inclined to
give you the water, the ordinary sense in which etiquette or
persuasion may seem a superficial matter may be elevated to an extreme
importance. Lisp is somewhat in this position right now. The details
matter, and must be addressed, I think... it may seem obvious to us
what the world should do, but the world doesn't see it as obvious.
The problem may be contrived, but the need to solve it is not.)
Johan Kullstam wrote in message ...
>Reini Urban <······@xarch.tu-graz.ac.at> writes:
>
>> or lisp vendors (or anyone else) should invest in expensive lisp
machine
>> or ai type of stuff.
>
>i think lisp is *more* than AI. sure it's good for AI, but you can
>use it for so much more. lisp is stuck in an AI perception rut.
>people think that's all it's good for -- not true. i'd like to see
>the non-AI applications of lisp receive more emphasis.
Well, it certainly is a matter of perception since the reality is that
LISP is used on more machines for AutoCAD and emacs than any another
application. The perception most likely derives from the fact that most
people who are interested in LISP per se are involved in academia rather
than the more prosaic popular commercial domains. Moreover, in the
applications where LISP is used to just get the job done because it is
the best way to do it, people are naturally not going to be interested
in religous language campaigns or pr.
jim
"Jim White" <···@pagesmiths.com> writes:
> Johan Kullstam wrote in message ...
> >Reini Urban <······@xarch.tu-graz.ac.at> writes:
> >
> >> or lisp vendors (or anyone else) should invest in expensive lisp
> machine
> >> or ai type of stuff.
> >
> >i think lisp is *more* than AI. sure it's good for AI, but you can
> >use it for so much more. lisp is stuck in an AI perception rut.
> >people think that's all it's good for -- not true. i'd like to see
> >the non-AI applications of lisp receive more emphasis.
>
>
> Well, it certainly is a matter of perception since the reality is that
> LISP is used on more machines for AutoCAD and emacs than any another
> application. The perception most likely derives from the fact that most
> people who are interested in LISP per se are involved in academia rather
> than the more prosaic popular commercial domains. Moreover, in the
> applications where LISP is used to just get the job done because it is
> the best way to do it, people are naturally not going to be interested
> in religous language campaigns or pr.
i don't want to start a religious campaign. my only point was that
the non-AI applications of lisp seem to take a back seat in people's
conciousness.
there are a plethora of `lisp for AI' books (someone even suggested on
this newsgroup writing yet another one).
AI being clearly not the only application of lisp, and, as you point
out, arguably not the most successful application of lisp. there are
a few general lisp books (like graham's duo).
i'd like to see more of `lisp for numerical methods' (which is my
need) or general `lisp for getting the job done' (where job is
whatever you would use any other language to do).
--
Johan Kullstam
········@ne.mediaone.net
Johan Kullstam <········@ne.mediaone.net> writes:
> AI being clearly not the only application of lisp, and, as you point
> out, arguably not the most successful application of lisp. there are
> a few general lisp books (like graham's duo).
>
>
> i'd like to see more of `lisp for numerical methods' (which is my
> need) or general `lisp for getting the job done' (where job is
> whatever you would use any other language to do).
Well said! I'm in AI, and I now need books on how to do other things in
lisp. Because AI is starting to rely on an ever larger set of techniques
and competencies. A short while back it looked like I'd be writing an
interface to LAPACK, but that did not turn out to be necessary. For now at
least. I'm sure some time in the future the need will crop up again and I
will have to do this.
I had also found some software to do basic multi-variate spectral analysis
but I simply do not know enough about the subject.
Sunil
From: Fernando D. Mato Mira
Subject: Re: Why LISP shall overcome (was Re: Java...)
Date:
Message-ID: <36E947C4.10756ECF@iname.com>
Johan Kullstam wrote:
> i don't want to start a religious campaign. my only point was that
> the non-AI applications of lisp seem to take a back seat in people's
> conciousness.
Including some vendors :-(
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Reini Urban wrote:
>
> Francois-Rene Rideau <····@ZhengHe.augustin.thierry> wrote:
> : In an article recently published at a free software conference,
> : http://www.tunes.org/~fare/articles/ll99/index.en.html
> : I argue that the fate of languages such as LISP,
> : that integrate metaprogramming, is tied to that of free software:
> : metaprogramming allows arbitrary gains in software productivity
> : and reliability, in as much as it is used to cover a larger software
> : community in space and time. Proprietary software partitioning
> : prevents such communities from growing past intellectual property barriers;
> : only free software allows to take full advantage of metaprogramming.
>
> hmm, autolisp won BIG and is proprietary vendor controlled software, not
> enhanced (the language) since its ancient beginnings.
> it's not free at all, it's even more expensive than most of the commercial
> lisps. nevertheless is AutoLISP the worldwide most used lisp type language
> and an incredible success, dispite all of its flaws.
> it is indeed a low-level, bad quality language.
>
> VB is another proprietary, low-level, bad quality language which won big.
> the next paragraph is still true, but the last sentence not.
Certainly. Free software "success" is rare, it's funny to claim
that it will be the worlds savior. Russia has always had free software.
Doesn't seem like they've done much innovation.
What is the motivation to do something better?
"Society" at large wants you to work on fixing the old stuff,
not create something new and incompatible.
In fact, you'll be ridiculed and outcast for your efforts.
Let's say you fail to make something better.
Then you get the same treatment, but are also considered stupid too.
Let's say you do something clearly and obviously better which
the old guard can't ignore. Then they just claim it was their idea
and incorporate it into their offering, and still call you stupid.
Fundamentally, there is no upside to innovation
in a public ownership world. You end up with an establishment
in control that doesn't want change.
The nature of private ownership free-market competition
is that the "old guard" isn't in control,
the buying customers are in charge and they decide what is the best
because they pay for their decisions.
If you create something truly better, then
customers are free to choose that over the old stuff.
And the old guard can't just take it over.
That's not to say "better" means incompatible.
Indeed, in the software business, compatible is of high value.
>
> : I give explanations why proprietary software leads to bad quality
> : low-level languages, and excludes integrated high-level environments,
> : and why the metaprogramming style of LISP becomes a disadvantage,
> : not an advantage, when the infrastructure is proprietary.
> : This suggests that people who wish LISP to succeed, instead of
> : seeing the advent of ad-hoc metaprogramming kluges as done in Perl,
> : should participate in free LISP software and implementation projects.
>
> : If LISP vendors want to win big, they should publish as free software
> : at least the system infrastructure, and sell service and possibly
> : peripheral software.
>
> lisp vendors should better attract more commercially successful users and
> markets. dssl will not make it, guile will not make it, lisp will not win
> big. it will win big if someone could persuade bill gates that a lisp like
> language will be better than vb. java had had the potential and strong
> supporters.
Agreed. But I add two points:
1) The "big players" may in fact buy into a Lisp language
under some circumstances.
I most definitely think it won't be "Common Lisp, The Standard."
2) Lisp doesn't have to win "big". It only has to win "small".
>
> or lisp vendors (or anyone else) should invest in expensive lisp machine
> or ai type of stuff.
I don't understand this comment.
In my opinion, the world is crying out for a better operating system,
they just don't know they can get it until they see something better.
The growing popularity of Linux will just make it clear how that need
remains unfulfilled.
I saw a sound bite from mr. gates the other day saying how
so far there hasn't been any real innovation that solves the
software-is-too-hard-to-write problem. Java certainly doesn't
solve it.
"Common Lisp, The Standard" is not the answer to the problem either.
And NiCLOS may be no better. At least I'm trying.
>
> : My article concludes that systems such a Free LISP systems
> : *shall* eventually overcome the market;
> : it only depends on us how fast and how well.
>
> we can just hope... :)
> but it's not that realistic.
Yeah, "Management by Hope", as Andy Groves, ex-CEO of Intel
said regarding Intel's failed memory-chip business.
We all make mistakes. The smart people learn from them.
--Kelly "lisp pundit" Murray ···@niclos.com
Francois-Rene Rideau wrote:
> This suggests that people who wish LISP to succeed, instead of
> seeing the advent of ad-hoc metaprogramming kluges as done in Perl,
> should participate in free LISP software and implementation projects.
> If LISP vendors want to win big, they should publish as free software
> at least the system infrastructure,
> and sell service and possibly peripheral software.
>
I think the worst thing that could happen to the Lisp community right now would be
to fall into the trap that the Smalltalk community has fallen into with Squeak.
Smalltalk vendors are withering on the vine while the community rallies around a
free implementation that will probably never achieve commercial quality.
Bruce Tobin <······@columbus.rr.com> writes:
> I think the worst thing that could happen to the Lisp community
> right now would be to fall into the trap that the Smalltalk
> community has fallen into with Squeak. Smalltalk vendors are
> withering on the vine while the community rallies around a free
> implementation that will probably never achieve commercial quality.
I do not see this happening. CMUCL is an extremely good public domain
implementation, but that does not seem to be taking away business from
vendors.
It may be that "relatively free" implementations of Common Lisp (and
Scheme) have always been available (KCL was available in 1985, I
believe), while the lack of a decent and gratis Smalltalk
implementation that make the "Squeak" effect seem bad for vendors.
What about Ada95 then? Did the appearance of GNAT made Ada vendors
wither away?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17,
fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it
Bruce Tobin:
Smalltalk vendors are withering on the vine while the community rallies
around a free implementation that will probably never achieve commercial
quality.
Marco Antoniotti:
I do not see this happening. CMUCL is an extremely good public domain
implementation, but that does not seem to be taking away business from
vendors.
The fact that there are free demo/linux versions available from the major
vendors suggests that the vendors don't think that even really good free
implementations are bad. Attracting good young & broke students,
programmers, developers, etc. is clearly important for the future success of
the language, and MIT 6.001 can't do all that work. Besides, even they are
teaching a bit of Java now (see http://www-swiss.ai.mit.edu/~u6001/FT98/).
The financial barriers to entry into the LISP world have to be low enough so
that we can compete on the merits.
However, I'd like to point out that it is equally important (or perhaps even
more so) that *someone* be paid, and paid well, to make "industrial
strength" versions of the language. Top notch programming language people
are expensive, and I want as many as we can collectively afford to be
working on LISP. Moving the language into the future, and even just keeping
up with the onslaught of new platforms, standards, functions, etc., that we
hardcore users need is not something that is likely to happen for free.
Lisp is NOT Linux -- there isn't nearly the motivation nor the broad need
driving Lisp development.
I am fortunate enough to have a good size computational budget for my
research. I make damn sure that a decent chunk of it goes to LISP vendors
because it is important to me that there be LISP vendors. Furthermore, I
feel like I get my money's worth, because, unlike with, e.g. CMUCL, I get
great help when I run into problems on my slightly out of the mainstream SGI
platform, which I stress pretty hard.
Larry
--
Lawrence Hunter, PhD.
National Library of Medicine phone: +1 (301) 496-9303
Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673
Bethesda. MD 20894 USA email: ······@nlm.nih.gov
From: Mike McDonald
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7attgq$fpm$2@spitting-spider.aracnet.com>
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> writes:
> ··@nospam.mak.com (John Morrison) writes:
> Coming from a hardware background myself, I interpret the demise of
> the Lisp-specific-hardware industry as being one of sheer numbers;
> orders of magnitude more manpower were spent over the last 20 years
> speeding up General-Purpose computers than could possibly be spent
> on lisp-specific hardware. And this phenomenon is not limited to
> Lisp-specific-hardware; the GP hardware industry has overtaken and
> subsumed the vector-hardware industry as well as other special-purpose
> hardware. That is why the current Lisp providers tend to remain on
> (or at least connect to) GP hardware.
Doesn't this hardware phenomenon also apply to software?
Mike McDonald
·······@mikemac.com
From: Johan Kullstam
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m290do4jmx.fsf@sophia.axel.nom>
·······@mikemac.com (Mike McDonald) writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> writes:
> > ··@nospam.mak.com (John Morrison) writes:
>
> > Coming from a hardware background myself, I interpret the demise of
> > the Lisp-specific-hardware industry as being one of sheer numbers;
> > orders of magnitude more manpower were spent over the last 20 years
> > speeding up General-Purpose computers than could possibly be spent
> > on lisp-specific hardware. And this phenomenon is not limited to
> > Lisp-specific-hardware; the GP hardware industry has overtaken and
> > subsumed the vector-hardware industry as well as other special-purpose
> > hardware. That is why the current Lisp providers tend to remain on
> > (or at least connect to) GP hardware.
>
> Doesn't this hardware phenomenon also apply to software?
not really. there might be 1000 C++ people for each lisper but that
doesn't make C++ any less painful to use.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Duane Rettig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4678rwkpf.fsf@beta.franz.com>
·······@mikemac.com (Mike McDonald) writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> writes:
>
> > Coming from a hardware background myself, I interpret the demise of
> > the Lisp-specific-hardware industry as being one of sheer numbers;
> > orders of magnitude more manpower were spent over the last 20 years
> > speeding up General-Purpose computers than could possibly be spent
> > on lisp-specific hardware. And this phenomenon is not limited to
> > Lisp-specific-hardware; the GP hardware industry has overtaken and
> > subsumed the vector-hardware industry as well as other special-purpose
> > hardware. That is why the current Lisp providers tend to remain on
> > (or at least connect to) GP hardware.
>
> Doesn't this hardware phenomenon also apply to software?
No, the econonies-of-scale are different for the two disciplines.
Lisp hardware (as any special-purpose hardware) is still made up of
gates and transistors. These come in many different packages, but
there is little difference between special-purpose and general-purpose
hardware in the way they are actually designed, prototyped, or
manufactured. The advantages that Lisp hardware has to offer are based
on the designs themselves. The cost (to the vendor) is still the
same; startup, development, tooling, manufacturing, sales/marketing
are all the same as for GP hardware manuacturers (although some of the
costs can be mitigated by writing the software portions of these
disciplines in lisp).
Lisp software systems, being themselves programs, are subject to the
same efficiency considerations as other software. I've heard on this
newsgroup people quoting being anywhere from 4x to 20x more productive
developing/maintaining software in lisp as other lanugages, and I've
seen both ranges (I myself tend to be more productive based on how
"lispy" I program - though please don't ask me to quantify that -).
Based on the fact that most of our lisp is written in itself, it is
a breeze to maintain and enhance, and to stay competitive. The
manufacturing costs are similar to non-lisp products, but the scale
of software manufacturing is vastly smaller than for hardware.
But there are two more points that figure into this:
1. The goals of hardware and software in a marketplace are
different; the top priority for pure hardware is the
performance-to-price ratio; there are others, but this is
usually the selling point. Contrast this with software
tools, whose number 1 priority is not speed but productivity.
2. Any hardware is only as good as its interface to the user,
which more and more exclusively is implemented in software.
I believe that it is the lisp machines' software that has
old users nostalgic over them, not the special powers of the
hardware.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <8790dnjlkh.fsf@2xtreme.net>
Duane Rettig <·····@franz.com> writes:
> 2. Any hardware is only as good as its interface to the user,
> which more and more exclusively is implemented in software.
> I believe that it is the lisp machines' software that has
> old users nostalgic over them, not the special powers of the
> hardware.
I've heard the keyboards were pretty cool (I'm not speaking from
experience). They are supposed to have enough modifiers that you can
conveniently type something like 8000 characters, like lowercase and
capital lambdas.
Christopher
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjvhgqveuo.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> I've heard the keyboards were pretty cool (I'm not speaking from
> experience). They are supposed to have enough modifiers that you can
> conveniently type something like 8000 characters, like lowercase and
> capital lambdas.
I think they are. They have a reasonable number of shift keys
(control shift meta hyper super + some others) but I don't think
that's really the issue, because modern keyboards have enough shift
keys really. They do have a coupe of useful things like a (locking)
`mode-lock' key which you can use to make things like profiling or
tracing happen only when it's pressed.
The reason I really like the keyboard is because it's nice to type on
in a way that no modern keyboards are -- the feel is very like that of
a Sun type 2 or 3 keyboard, or a very early real-IBM PC keyboard.
Also it doesn't have these vast encrustations of useless keys that
cause modern keyboards to require special long desks and surgical
extensions to your right arm. I mean, what are all those keys *for*?
When was the last time that anyone used a keyboard which didn't have
keys that they didn't know what they do (if anything) on them, and
were apparently made out of sponge rubber.
--tim
From: Phil Stubblefield
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36D62EB2.9F757089@rpal.rockwell.com>
Tim Bradshaw <···@tfeb.org> wrote:
>
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > I've heard the keyboards were pretty cool (I'm not speaking from
> > experience). They are supposed to have enough modifiers that you
> > can conveniently type something like 8000 characters, like
> > lowercase and capital lambdas.
>
> I think they are. They have a reasonable number of shift keys
> (control shift meta hyper super + some others) but I don't think
> that's really the issue, because modern keyboards have enough shift
> keys really. They do have a coupe of useful things like a (locking)
> `mode-lock' key which you can use to make things like profiling or
> tracing happen only when it's pressed.
>
> The reason I really like the keyboard is because it's nice to type on
> in a way that no modern keyboards are -- the feel is very like that of
> a Sun type 2 or 3 keyboard, or a very early real-IBM PC keyboard.
> Also it doesn't have these vast encrustations of useless keys that
> cause modern keyboards to require special long desks and surgical
> extensions to your right arm. I mean, what are all those keys *for*?
> When was the last time that anyone used a keyboard which didn't have
> keys that they didn't know what they do (if anything) on them, and
> were apparently made out of sponge rubber.
Motivated by these comments -- and by the fact that I was bored by
work :) -- I created an ASCII picture of a Symbolics keyboard for the
benefit of those who have never seen one. This is a later-generation
keyboard that came with a MacIvory III, not the orginal keyboards
from the 36xx series. We sold our 36xx's some time ago, but I think
the key layout is very similar, perhaps identical.
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
| | | | | | | | | | |
| Function | Escape | Return | Square | Circle | Triangle | Clr Input | Suspend | Resume | Abort |
+-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----------+
| | | ! | @ | # | $ | % | ^ | & | * | ( | ) | _ | + | ~ | { | } | |
| Network | : | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | = | ` | \ | | | Help |
+-----------+-----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-----+-----------+
| | | | | | | | | | | | | [ | ] | | | |
| Local | Tab | Q | W | E | R | T | Y | U | I | O | P | ( | ) | BS | Page | Complete |
+-----------+--------++----++----++----++----++----++----++----++----++----++----++----++----+-----++-------+-----------+
| | | | | | | | | | | | : | " | | | |
| Select | Rubout | A | S | D | F | G | H | J | K | L | ; | ' | Return | Line | End |
+------+----+-+-------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-------+---+---+---+---+-------+
| Caps | | | | | | | | | | < | > | ? | | | | Mode |
| Lock | Sym | Shift | Z | X | C | V | B | N | M | , | . | / | Shift | Sym | Rpt | Lock |
+-----++----+-+---+------+--+--+-----+-----+-----+-----+-----+-----+-----+-----+---+-+-------+--+--+----++-----++-------+
| | | | | | | | | | |
| Hyp | Sup | Met | Control | | Control | Met | Sup | Hyp | Scroll |
+-----+-----+-----+---------+------------------------------------------------------+---------+-----+-----+-----+--------+
Clarifications:
1. Lowercase letters are omitted to reduce clutter.
2. The Square, Circle, and Triangle keys are actually labelled by
the named shapes.
3. The following key names are abbreviated:
Clr Input == Clear Input
BS == Back Space [one word above the other]
Sym == Symbol
Rpt == Repeat
Hyp == Hyper
Sup == Super
Met == Meta
4. The Caps Lock and Mode Lock keys contain embedded status lights.
Interesting features:
1. Instead of the 12 to 15 F-keys of today's typical keyboard, this
keyboard has named keys associated with semantic actions. Some are
fairly obvious: "Clear Input", "Suspend", "Resume", "Abort", "Help",
and "Complete". The rest are easy to remember once you understand
their purpose: "Local", to control local terminal functions (audio
volume, monitor brightness, etc.); "Select", to switch between
applications; and so on.
2. Note the extra colon key in the upper-left corner. Also note that
parentheses appear in two places: above the "9" and "0", as on a
typical keyboard, and also to the right of the "P" key, which are
brackets on a typical keyboard. Since Lisp makes heavy use of
parentheses and colons, the Symbolics keyboard provides them
without the need to use the Shift key.
3. Note that, in addition to the Shift key, there are four modifier
keys: Control, Meta, Super, and Hyper. I've never seen a command
that used all of them, but try typing C-M-S-H-Sh-Abort on a typical
keyboard!
Any comments from other Symbolics users?
Phil Stubblefield
Rockwell Palo Alto Laboratory 650/325-7165
http://www.rpal.rockwell.com/~phil ····@rpal.rockwell.com
From: Christopher J. Vogt
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36D6E194.EA6F9D8F@computer.org>
Phil Stubblefield wrote:
>[...]
> 2. Note the extra colon key in the upper-left corner. Also note that
> parentheses appear in two places: above the "9" and "0", as on a
> typical keyboard, and also to the right of the "P" key, which are
> brackets on a typical keyboard. Since Lisp makes heavy use of
> parentheses and colons, the Symbolics keyboard provides them
> without the need to use the Shift key.
To this day, the first thing I do when I start work on a new operating system is to find out how to remap keys so that
the parens are like they are on the symbolics keyboard, and I put the square brackets up above 9,0.
> [...]
From: Aaron Crane
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <djlnhkd7x1.fsf@planet.praeclarus.demon.co.uk>
In article <·················@rpal.rockwell.com>,
Phil Stubblefield <····@rpal.rockwell.com> writes:
> 3. Note that, in addition to the Shift key, there are four modifier
> keys: Control, Meta, Super, and Hyper. I've never seen a command
> that used all of them, but try typing C-M-S-H-Sh-Abort on a typical
> keyboard!
Well, I don't have an Abort key, and I use Alt instead of Hyper, but if I
type C-M-S-A-Sh-home, then Emacs tells me `C-M-S-A-Sh-home not defined.' Of
course, actually I wouldn't actually want to bind a command to it, but
typing it isn't really *that* hard. I have Control next to the `A' key,
Shift below it, Meta either side of the space bar, Alt next to each Meta,
Super to the right of right-Alt, and Home sits way up above Backspace.
Certainly C-M-A, C-A-S and C-M-S are quite easy combinations.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
From: Kelly Murray
Subject: Re: Keyboards (was Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36D5B442.36ED1049@IntelliMarket.Com>
PC Keyboards are programmable, and very easily under X using xmodmap,
so you can modify them however you want.
I've always redefined my keyboards, which is a real problem if you
ever have to use someone else's. In fact, I modified my TI Explorer
LispM keyboard to be the same as the Symbolics.
I also hate those long keyboards, which makes reaching for the
mouse a much longer distance. I have a BTC-??? keyboard at home
that is very compact, like a notebook keyboard. It was $50,
and I've had a hard time finding another one for sale, though BTC
still has the part number listed.
I've bought a couple smaller "IBM Typewriter" type keyboards
that don't have the keypad and thus are shorter, but not as compact
as my one at home, they were only $15,
and that's what I'm typing at now. And of course, the keys
are all remapped, in particular the Crl and Alt keys are swapped.
-Kelly
Tim Bradshaw wrote:
>
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > I've heard the keyboards were pretty cool (I'm not speaking from
> > experience). They are supposed to have enough modifiers that you can
> > conveniently type something like 8000 characters, like lowercase and
> > capital lambdas.
>
> I think they are. They have a reasonable number of shift keys
> (control shift meta hyper super + some others) but I don't think
> that's really the issue, because modern keyboards have enough shift
> keys really. They do have a coupe of useful things like a (locking)
> `mode-lock' key which you can use to make things like profiling or
> tracing happen only when it's pressed.
>
> The reason I really like the keyboard is because it's nice to type on
> in a way that no modern keyboards are -- the feel is very like that of
> a Sun type 2 or 3 keyboard, or a very early real-IBM PC keyboard.
> Also it doesn't have these vast encrustations of useless keys that
> cause modern keyboards to require special long desks and surgical
> extensions to your right arm. I mean, what are all those keys *for*?
> When was the last time that anyone used a keyboard which didn't have
> keys that they didn't know what they do (if anything) on them, and
> were apparently made out of sponge rubber.
>
> --tim
From: ···········@alcoa.com
Subject: Re: Keyboards (was Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7b66dv$2o9$1@nnrp1.dejanews.com>
Kelly Murray <···@IntelliMarket.Com> wrote:
> I also hate those long keyboards, which makes reaching for the
> mouse a much longer distance. I have a BTC-??? keyboard at home
> that is very compact, like a notebook keyboard. It was $50,
> and I've had a hard time finding another one for sale, though BTC
> still has the part number listed.
> I've bought a couple smaller "IBM Typewriter" type keyboards
> that don't have the keypad and thus are shorter, but not as compact
> as my one at home, they were only $15,
> and that's what I'm typing at now. And of course, the keys
> are all remapped, in particular the Crl and Alt keys are swapped.
You might want to try a left handed keyboard. They have the keypad and arrow
keys, etc. on the left leaving a closer reach for the mouse (assuming you
mouse with your right hand).
John Watton
Alcoa Inc.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Mike McDonald
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7att2h$fpm$1@spitting-spider.aracnet.com>
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> writes:
> You could make
> your most convincing argument to your company, not by telling them of
> pros and cons, but by actually building a small app in lisp and showing
> them technically how easy it is to build, maintain, and improve.
Unfortunately, not all managers and companies are easily persuaded by facts,
no matter how compelling. When I worked at SGI, I was given the task of
writing a system for collecting and analyzing traces of the operating system.
The analysis portion was ideally suited for Common Lisp and CLIM. So I
contacted Franz and got an evaluation copy so I could prototype the app. After
completing the demo and presenting the advantages of using Lisp over C/C++,
management decided that Lisp could not be used for the implementation of the
project. Management had three major concerns with using Lisp:
- royalties
- support
- culture
The paying of royalties for the runtime system was an annoying, although not
fatal, problem. The system being designed was not intended to be sold as a
separate product, but to be bundled with another. The standard terms of the
Franz license was confusing with respect to what the actual costs of
deployment would have been. Although I believe this could have been worked out
with Franz, it did add to the unease of management.
Management was also concerned about the level and duration of support that
Franz could provide. SGI essentially had no track record of working with
Franz. The combination of a small company and a non mainstream language
increased their apprehension.
SGI has a very free wheeling, C based culture. Very few engineers at SGI
have much experience, if any, in using Lisp for engineering problems. (Hi
Rob!) There were no other individuals in my group who knew Lisp. Silicon
Valley also did not have an extensive Lisp culture. As a result, management
was concerned about being able to staff the developement and maintainence of a
Lisp based product. This fear of finding qualified engineers ultimately proved
to be the undoing of the idea of using Lisp for the project. (I found it
extremely ironic that management decided it was OK for me to make up an
extention language! I guess they felt they could find lots of experienced
engineers in whatever I made up.)
Ultimately, SGI decided that Lisp could not be used and that C++ should be
used despite having to reinvent large portions of CLIM. It was conservatively
estimated that the C++ version would take three times as long to implement
than the Lisp version. Due to this extended schedule, the project was
canceled. SGI eventually used a third party tool as substitute for the one we
had envisioned. Ironicly, it was also produced by a small company (but in C++)
and it cost more than the initial royalties that Franz was asking for.
As much as it frustrates me, my experience with SGI with respect to using
Lisp has been more the rule than the exception. (At my current company, I also
wasn't allowed to use Lisp for a well suited project. So I implemented a small
lisp interpreter for it. But since my boss has no idea what my product does, I
have been able to get away with it.)
Mike McDonald
·······@mikemac.com
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128753203540626@naggum.no>
* ·······@mikemac.com (Mike McDonald)
| (I found it extremely ironic that management decided it was OK for me to
| make up an extention language! I guess they felt they could find lots of
| experienced engineers in whatever I made up.)
this is a point worth latching on to, actually. you can often get a
foot-hold on management (or perhaps just a foot in the door) by pointing
out that you don't _need_ a new custom-built extension language, it's all
well-defined and standard and you can even write actual applications in
it. sometimes, management will accept any sort of "scripting", but will
balk on actual programming in "odd" languages. the way to exploit this
sillitude is to abuse the management vocabulary and just refer to Lisp
as a scripting language until it is sufficiently entrenched, such as by
pretending that CL in "Allegro CL" is a Roman numeral and that the 150th
version is pretty darn stable.
#:Erik
From: David Gadbois
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <w0kww18hqio.fsf@lagavulin.cyc.com>
Erik Naggum <····@naggum.no> writes:
> [...] CL in "Allegro CL" is a Roman numeral and that the 150th
> version is pretty darn stable.
Hah! I don't know when I will get to work on a new Common Lisp
project or what it will do, but I now know that it will be called
"Sesquicentennial."
--David Gadbois
Erik Naggum <····@naggum.no> wrote in message
·····················@naggum.no...
>* ·······@mikemac.com (Mike McDonald)
>| (I found it extremely ironic that management decided it was OK for me to
>| make up an extention language! I guess they felt they could find lots of
>| experienced engineers in whatever I made up.)
>
> this is a point worth latching on to, actually. you can often get a
> foot-hold on management (or perhaps just a foot in the door) by pointing
> out that you don't _need_ a new custom-built extension language, it's all
> well-defined and standard and you can even write actual applications in
> it. sometimes, management will accept any sort of "scripting", but will
> balk on actual programming in "odd" languages. the way to exploit this
> sillitude is to abuse the management vocabulary and just refer to Lisp
> as a scripting language until it is sufficiently entrenched, such as by
> pretending that CL in "Allegro CL" is a Roman numeral and that the 150th
> version is pretty darn stable.
>
>#:Erik
150th !! Very Good!
Another way to insert lisp in a C/C++(++C?) world is to make all in lisp and
deliver it in a DLL called by a very thin C/C++ layer.
Marc Battyani
·······@mikemac.com (Mike McDonald) writes:
> Management had three major concerns with using Lisp: [...]
I found Mike's "case study" very interesting and it made me curious for some
more "statistical" (ok, "anecdotal") information: does everyone else see
these same barriers to Lisp's acceptance in your work (or school)
environment? No, don't go look at his list of issues to decide. Don't even
read other answers to this query before you respond. Make up your own
answers first. THEN go back and see if they're the same as what others
wrote. Better science that way. (Sigh... comp.lang.lisp is to science like
C++ is to object-oriented programming; but we're sometimes forced to work
with tools we might not wish to...)
Anyway, I'm interested in doing a reality check on my present perceptions of
how Lisp is presently hampered in acceptance.
What barriers have people recently seen first-hand to Lisp's acceptance in
their own working experience at their present or some recent organization?
How would you prioritize those in terms of how "fatal" they are (to use
Mike's term)? Any obvious things the vendors could/should be doing to fix
them? If you have had success getting past them, what strategies have you
used? If you could change just one thing about Lisp itself or about some
Lisp vendor's implementation or packaging, what would it be? I don't mean
this to be a checklist of questions to answer but rather a way of getting
you started on an essay about the general topic. I fear a set of crisp
questions would lose some important truth between the lines.
In addition to feeling this would be useful to sales people and maybe to the
ALU (Association of Lisp Users; sigh... I wish I didn't have to worry that
if I don't spell that out, some people won't know what it is), I'm also
interested because I'm trying to put together some books on Lisp and I'm
looking to this kind of information as one influence toward how to frame the
book--what obvious questions to anwer, what pitfalls to avoid.
Even if your experience duplicates someone else's--perhaps especially if it
does since that adds statistical weight--I'd find it very interesting to see
what we're up against right now and where we as a community and each as
indivisual customers, vendors, and advocates should be working to improve
things. Maybe there's a lot of commonality, maybe there's not. I don't
know how to find that out without asking...
I hope I'm not influencing the form of the reply too much by suggesting
there might be still at least some slight barrier to the acceptance of
Lisp. ;-) Beyond that, I've tried to leave this open-ended. Please focus on
what seems important to you in this issue, not on what you perceive I want
you to think is important.
Thanks in advance to anyone who's willing to take the time to respond. (If
you don't feel comfortable responding publicly and want to launder the reply
through me, send me e-mail (······@world.std.com) and I'll try to summarize
whatever I get that way back to the group later on without 'fessing up your
name.)
In article <··················@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> Anyway, I'm interested in doing a reality check on my present perceptions of
> how Lisp is presently hampered in acceptance.
I'll give two more stories from my experience. One from a 10-12 years ago
and one from the last year. I hope my sharing of my experience doesn't bias
your "statistics" too much.
Years ago, I worked in the Advanced Technology Department of Harris Corp.
I was working on an integrated VLSI design system that used Symbolics LispMs
extensively. Harris also had a large VLSI design and fab sector. We were never
able to get the Semiconductor Sector to seriously evaluate Schema because it
used Symbolics machines and they couldn't count on such a small company being
around in the long term to support their needs. Instead, they were heavily
investing in another small company, Sun MicroSystems. (Sun and Symbolics were
the same size at the time.)
Another incident at Harris was quite frustrating. Harris used to do a lot of
"one-of" designs for the US government. In particular, Harris was pretty good
at designing space deployable antennas. A couple of the crack antenna
designers were tasked with finding new tools and techniques for designing
these antennas inorder to become more competitive and flexible. Anyway, the
designers got a hold of some copies of ICAD and ran it on our LispMs. After a
while of coming up to speed with ICAD, they were visited by one of their
regular customers. After spending the day getting the customer's requirements,
one of the engineers decided to see what he could come up with using ICAD that
night. He investigated 7 different potential designsand presented 5 of them
the next day to the customer. The customer wanted to know where to send the
check! Of course, Harris didn't know how to take the guy's money. A couple of
weeks later, the designer's management decide to drop ICAD because they didn't
feel they could handle the risk of relying on ICAD and Symbolics. The fact
that a customer wanted to write a 100 million dollar check on the spot
evidently didn't matter much.
At my current company, I was given the task of writing a application that
would distribute copies of our group's main product onto idle workstations and
compute servers inorder to increase the thruput of the system. Due to some of
the constraints and flexibility they wanted, Common Lisp would have been my
choice for implementing the app. Unfortunately, no one else in our group had
been exposed to real Lisp. The couple who had any exposure to Lisp at all was
from the "Intro to AI" class in college. They didn't even know Lisp had arrays
let alone all of those other wonderful features! Lisp was just too different
from their experience that they didn't feel comfortable using it. (They've
gone off the C++ deep end in a BIG way and are starting to pay the price. So
maybe in a couple of years they'll be more receptive to Lisp, although I'd
place my bets that they'll go off the Java deep end next. But there's hope.)
Risk seems to be a reoccuring theme when it comes to trying to use Lisp.
Lisp is different enough from "conventional" thinking and languages that it
scares people. (The reputation of being an AI language doesn't help any!) In
some sense, I think Lisp is too advanced for its own good. I have noticed that
Franz hardly mentions Lisp in their literature. Instead they keep refering to
dynamic object technology. (I think that's the right term.) Maybe they're
having better luck not mentioning the L word until after they have 'em hooked
with all of the nifty features.
Mike McDonald
·······@mikemac.com
From: David Combs
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <dkcombsF7oKMn.2nF@netcom.com>
In article <············@spitting-spider.aracnet.com>,
Mike McDonald <·······@mikemac.com> wrote:
<snip>
>
> Risk seems to be a reoccuring theme when it comes to trying to use Lisp.
>Lisp is different enough from "conventional" thinking and languages that it
>scares people. (The reputation of being an AI language doesn't help any!) In
>some sense, I think Lisp is too advanced for its own good. I have noticed that
>Franz hardly mentions Lisp in their literature. Instead they keep refering to
>dynamic object technology. (I think that's the right term.) Maybe they're
>having better luck not mentioning the L word until after they have 'em hooked
>with all of the nifty features.
>
> Mike McDonald
> ·······@mikemac.com
I myself use the language "mainsail", "sail" being the old
Stanford AI Language (lost out to mit lisp).
Sail looked like algol, had dynamic strings, etc, gc.
MAINsail is the result of a phd thesis there, the main
meaning Machine INdependent.
(cross compiled from dec20 to vax to sun; for a while
they did vm/cms too. Now they have nt; haven't tried
it yet. Usually one huge cross-compile, and it works!)
Since 1982 I've been using (only) it. Super language -- as
long as you don't program for gui.
Anyway -- when I saw c++, man, I couldn't believe all this
destructor stuff. Layer upon layer, hack upon hack,
design pattern upon design pattern, SOLELY BECAUSE OF NO GC.
How in the world one gets anything done without gc is
a mystery to me.
---
Now we get java with gc, but java also as a religion of
no macros. How in the world does one program without
macros? Especially for i/o statements, rather write
statements, for debugging.
Like, a macro zhvi(myint) (I use zh from old fortran
hollerith) that produces
"the value of myint is: <valOfMyint>",
where you show the NAME of the variable as well as the VALUE --
how in the world can you do that EASILY and CONCISELY without
macros?
A religion of "no macros!". Too bad for the users!
End of rant.
David Combs
On Tue, 23 Feb 1999, Mike McDonald wrote:
>In article <··················@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
>
>> Anyway, I'm interested in doing a reality check on my present perceptions of
>> how Lisp is presently hampered in acceptance.
>
>> Management had three major concerns with using Lisp: [...]
>
>I found Mike's "case study" very interesting and it made me curious
>for some more "statistical" (ok, "anecdotal") information: does
>everyone else see these same barriers to Lisp's acceptance in your
>work (or school) environment?
Anyway, I'm interested in doing a reality check on my present perceptions of
>how Lisp is presently hampered in acceptance.
Hello Kent. I'm afraid I missed Mike's "case study", but perhaps
that's a good thing as my thoughts won't be influenced by other
opinion.
I have just recently returned to Lisp after a nine-year hiatus, during
which time I wrote OO software systems using C++ and, for the last two
years, Java. My initial experience with Lisp was on a Symbolics 3600
(a "state-of-the-art" development environment even by today's
standards); at that time I was a co-op working for DoD, and while I
enjoyed building Lisp software I did not have sufficient exposure to
other languages/platforms to fully appreciate what good Lisp
environments truly offer.
I would like to offer you opinions from the perspective of one who
has, for the last several years, been developing complex simulation
software with Java on UNIX platforms. I am approaching Lisp from the
"large system development" fence; this concept includes in its
definition requirements for multi-threading, distributed
communication, knowledge-based systems, build environment,
etc. Currently, I am building prototypes of a knowledge-based system
for use within the telecom industry, using Allegro Common Lisp.
First, I believe Lisp still unjustly suffers from various stereotypes
previously assigned to the language (rightly or wrongly). You know the
ones -- "Lisp is slow", "Lisp is only for AI", "Lisp only runs well on
expensive Lisp machines", "There are no tools for building Lisp
software"... I encounter these misconceptions even from engineers in
my organization that I generally respect, so I imagine other folks
hear them as well. Another comment I occasionally hear is "Lisp has a
high learning curve". I'm not sure I understand this one, as my
experience has been quite the opposite, but I *have* seen things in
the Common Lisp specification that might justify this statement, so
I'll give it merit.
Now, as rebuttal I would like to say that my recent experience with
Common Lisp contradicts these criticisms I've mentioned. For example,
Franz, Inc.'s current Lisp offering (Allegro Common Lisp 5.0) runs
exceptionally well on stock hardware; CLOS brings OO capabilities to
the table; and ACL's tight coupling with Emacs, along with Lisp's
built-in mechanisms for dynamic linking, inspection, debugging,
etc. make for a powerful development environment.
What about support for some of the current trends in application
software development, particularly since the advent of Java? Here I
speak of "distributed" and multi-threaded systems; can Lisp handle
these types of applications? Both Franz and Harlequin offer CORBA
bindings for their Lisp implementations, along with language
extensions to support multi-threaded programming. I can't speak to the
quality of the CORBA bindings (having not used them), but it's at
least evident that two leading Lisp vendors are keeping pace with
software engineering trends.
So, problems. From a "language standard" perspective, I believe a
significant shortcoming with Lisp is the omission of basic
inter-process communication facilities ("sockets") and a standard
threading ("process") interface. Java provides both, to its credit,
making that platform attractive to folks building server-class
software. In my opinion, it simply isn't any longer acceptable to fill
a system with platform-specific, conditionally evaluated code. I don't
have to do this in Java, and I don't want to do this in Lisp.
Now, language standards being what they are (i.e. difficult to augment
in a timely fashion), I would suggest the major Lisp vendors get
together and devise a nice, platform-neutral, CLOS-based API for
threads and sockets. Quickly. While there's still time. [while they're
at it, a standard FFI would be nice too, but perhaps that's asking too
much right now]. This would allow the rest of us to build clean,
portable CLtL2-compliant software (thanks to Lisp's ANSI
standardization), and add weight to our push for Lisp acceptance. I
guess this is the "one thing I'd change about Lisp".
And what about "Lisp acceptance strategies"? My tactic has been,
"produce something, reflecting project or corporate need, that proves
Lisp is capable and superior to the alternatives". I adopted this
approach two years ago with Java, and am doing it now with
Lisp. Whether I'm successful this time remains to be seen.
There's certainly more I could say, but perhaps this is enough for a
news group forum. Good luck to you Kent, and please keep us apprised.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···········@fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87ww12uqjh.fsf@2xtreme.net>
David E. Young <········@computer.org> writes:
> So, problems. From a "language standard" perspective, I believe a
> significant shortcoming with Lisp is the omission of basic
> inter-process communication facilities ("sockets") and a standard
> threading ("process") interface. Java provides both, to its credit,
> making that platform attractive to folks building server-class
> software. In my opinion, it simply isn't any longer acceptable to fill
> a system with platform-specific, conditionally evaluated code. I don't
> have to do this in Java, and I don't want to do this in Lisp.
I don't think we can ever realistically compete with Java in this
regard. I just the other day discovered that Java gives you a standard
API to serial ports. Geez. It seems that in time there will be
absolutely nothing you can't do in pure Java without native methods.
> Now, language standards being what they are (i.e. difficult to augment
> in a timely fashion), I would suggest the major Lisp vendors get
> together and devise a nice, platform-neutral, CLOS-based API for
> threads and sockets. Quickly. While there's still time. [while they're
> at it, a standard FFI would be nice too, but perhaps that's asking too
> much right now]. This would allow the rest of us to build clean,
> portable CLtL2-compliant software (thanks to Lisp's ANSI
> standardization), and add weight to our push for Lisp acceptance. I
> guess this is the "one thing I'd change about Lisp".
There are two primary things I see that make this unattractive from a
vendor's standpoint.
1. As Erik said, standardizing this stuff means going from "Do you
support the feature of Foo?" to "Do you conform to the specification of
Foo?"
2. I haven't heard anyone bring this up yet, but standardizing this
stuff drastically lowers your commitment to a specific vendor. If all
your Allegro sockets and FFI code suddenly compiles cleanly under
Harlequin or even CMU Common Lisp, and it appears to be performing
just as well for your specific application, you may suddenly find
rethinking the renewal of your Allegro license or the runtime
royalties in favor of another product to be not an impossibility....
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
...
>
> There are two primary things I see that make this unattractive from a
> vendor's standpoint.
>
> 1. As Erik said, standardizing this stuff means going from "Do you
> support the feature of Foo?" to "Do you conform to the specification of
> Foo?"
>
> 2. I haven't heard anyone bring this up yet, but standardizing this
> stuff drastically lowers your commitment to a specific vendor. If all
> your Allegro sockets and FFI code suddenly compiles cleanly under
> Harlequin or even CMU Common Lisp, and it appears to be performing
> just as well for your specific application, you may suddenly find
> rethinking the renewal of your Allegro license or the runtime
> royalties in favor of another product to be not an impossibility....
You are perfectly right! The vendor must swallow this toad (in
Italian: devono ingoiare il rospo) if they want to be "language
sellers" and get their revenues from an expanded user base.
Of course they can choose a different path and hope that the Lisp
market stays stable or re-invent themselves as something else.
In this case, the lisp community (i.e. those who keep the faith :) )
will eventually loose.
And now... back to Java programming.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
On Sun, 28 Feb 1999, Christopher R. Barry wrote:
>David E. Young <········@computer.org> writes:
>
>> So, problems. From a "language standard" perspective, I believe a
>> significant shortcoming with Lisp is the omission of basic
>> inter-process communication facilities ("sockets") and a standard
>> threading ("process") interface. Java provides both...
>I don't think we can ever realistically compete with Java in this
>regard.
Hello Christopher. I don't think we need compete "feature-for-feature" with
Java; however, omitting standardized functionality that would allow Lisp to be
seen with the proper perspective, particularly by management, only hurts us.
>2. I haven't heard anyone bring this up yet, but standardizing this
>stuff drastically lowers your commitment to a specific vendor...
Indeed, and from many perspectives this is a Good Thing. However, there are
plenty of ways for vendors to make their particular Lisp platforms more
attractive than the competition's. For example, Harlequin offers KnowledgeWorks,
a nice rule-based expert system shell for those of us building knowledge-based
systems. Some other vendor might decide to offer a tool suite that would
facilitate the development of Lisp-based distributed systems (something like
ObjectSpace's "Voyager" product for Java).
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···········@fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfw678k7ljy.fsf@world.std.com>
David E. Young <········@computer.org> writes:
> On Sun, 28 Feb 1999, Christopher R. Barry wrote:
> >David E. Young <········@computer.org> writes:
> >
> >> So, problems. From a "language standard" perspective, I believe a
> >> significant shortcoming with Lisp is the omission of basic
> >> inter-process communication facilities ("sockets") and a standard
> >> threading ("process") interface. Java provides both...
>
> >I don't think we can ever realistically compete with Java in this
> >regard.
>
> Hello Christopher. I don't think we need compete "feature-for-feature" with
> Java; however, omitting standardized functionality that would allow Lisp to be
> seen with the proper perspective, particularly by management, only hurts us.
Yes, and in particular any omission that cripples Lisp's ability to
piggy-back on what others have done in other languages puts Lisp in
the position of having to compete with what others have done in other
languages. The specific things I'm harping on--sockets, corba,
etc. (someone mentioned odbc) are all connective tissue. If we could
connect to other systems it wouldn't matter that we didn't have
certain subroutines or packages, since we can call out to them. Until
we get that connectivity in place, we're behind the curve by
definition. My strong belief is that vendor insistance on charging
for connectivity elements of their systems is what's assuring Lisp is
an outcast. In some cases because other languages don't charge; in
other cases because even though other languages do charge, this is an
opportunity for Lisp to have a market edge and gain some ground that
appears to me to be being squandered.
>
> >2. I haven't heard anyone bring this up yet, but standardizing this
> >stuff drastically lowers your commitment to a specific vendor...
>
> Indeed, and from many perspectives this is a Good Thing. However,
> there are plenty of ways for vendors to make their particular Lisp
> platforms more attractive than the competition's. For example,
> Harlequin offers KnowledgeWorks [...]
Also, of course, just having a quality implementation, a good compiler,
robustness, or a good support organization is a good way for any vendor
to compete, even if all of their components are standard.
Additionally, if more than one vendor is standards compliant--and they
are, btw---then a vendor A can write their own layered products on
vendor B's platform and vice versa. This kind of cross-use is good
for both vendors and the user. It allows end-user flexibility about
which platform to use underneath and which to use atop, while
providing income to both. KnowledgeWorks for Allegro or MCL makes
conceptual sense, for example. So Harlequin could benefit from
standards by offering them and then using them (and so could Franz or
Digitool).
Another thing about standards is that some customers get nervous about
not being able to "second source" their platform. ANSI Common Lisp
was largely a functional step down from Symbolics Common Lisp, but
Symbolics benefited greatly from implementing ANSI CL not because
people needed it but becuase otherwise customers would have had to jump
ship for a more "secure" platform. Since they always knew they could
later do it once they were in standards, the presence of the standard
left them comfortable continuing to use Symbolics hardware even when the
company was in bad financial shape since they really wanted the quality
for as long as they could get it. Use of standards is a good insurance
policy for a vendor against public financial problems because you can tell
customers they don't have to care that you might get into worse trouble
later.
I think the vendors know these things. I mention them just for the
sake of others who might doubt that vendors had a reason to cater to
standards. They do have reasons, and I think they know. That's why they
support them.
Let me add a question to this thread.
What is the name (and nicknames) of the multiprocessing packages in
LispWorks, ACL and MCL?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
In article <··············@copernico.parades.rm.cnr.it> , Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:
>
> Let me add a question to this thread.
>
> What is the name (and nicknames) of the multiprocessing packages in
> LispWorks, ACL and MCL?
>
> Cheers
See <http://www.cyc.com/users/gadbois/processes.lisp>.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
"David B. Lamkins" <········@teleport.com> writes:
> See <http://www.cyc.com/users/gadbois/processes.lisp>.
Recent (1999-03-03 11:20:00) CST updates:
o The code compiles out of the box into the CL-USER package.
o There is a CMU CL port.
o There is an explicit notice that it is in the public domain.
--David Gadbois
From: Kelly Murray
Subject: Lisp Processes (was Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36DD93ED.EC89E3@IntelliMarket.Com>
David Gadbois wrote:
>
> "David B. Lamkins" <········@teleport.com> writes:
> > See <http://www.cyc.com/users/gadbois/processes.lisp>.
>
> Recent (1999-03-03 11:20:00) CST updates:
> o The code compiles out of the box into the CL-USER package.
> o There is a CMU CL port.
> o There is an explicit notice that it is in the public domain.
>
> --David Gadbois
Looks good. I notice the elimination of run and arrest reasons
quantum and priority, and other "internal" type stuff.
Just not supported by all lisps, or is this a judgement on their
value to the user?
Would it makes sense to collapse
PROCESS-WAIT and PROCESS-WAIT-WITH-TIMEOUT into one method,
where timeout of nil means no timeout.
Also, I think it's useful to have process-wait return the
non-nil value of the wait function, or nil if it timed out.
A fairly common need is to poll multiple streams, i.e. select.
One could write this as
(process-wait (function (streams)
(loop for stream in streams
do
(if (listen stream) then (return stream)
))
(list stream1 stream2 ..))
As a general style question, does it make sense to put this stuff
in another package?
One often sees the naming convention of <type>-<method> for
a function, and it ALSO gets in another package,
so you'd get process:process-wait.
In my view, why isn't the method called WAIT, in the process package,
such that
(class process ()
...)
(method wait ((p process) timeout function [args]*)
...)
One can just call process:wait or decide to use just wait by
importing process:wait.
-Kelly Murray
From: David Gadbois
Subject: Re: Lisp Processes (was Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <w0k7lsyl271.fsf@lagavulin.cyc.com>
Kelly Murray <···@IntelliMarket.Com> writes:
> I notice the elimination of run and arrest reasons quantum and
> priority, and other "internal" type stuff. Just not supported by
> all lisps, or is this a judgement on their value to the user?
Not supported. Those features depend a lot on the scheduler
implementation.
> Would it makes sense to collapse PROCESS-WAIT and
> PROCESS-WAIT-WITH-TIMEOUT into one method, where timeout of nil
> means no timeout.
If I were doing it over again, I'd just have PROCESS-WAIT and
SET-TIMEOUT.
> As a general style question, does it make sense to put this stuff
> in another package?
Sure. Once the Lisp "substandards" stuff gets organized, it will make
sense to have a standard place for all this to live.
Speaking of the substandards, is there any action on that front?
Cycorp will put the rest of its porting layer (locking, sockets, and
lexical environment access) in the public domain, though I'll have to
spiff it up a bit first. Does anyone have a defsystem or foreign
function interface to donate?
> One often sees the naming convention of <type>-<method> for a
> function, and it ALSO gets in another package, so you'd get
> process:process-wait. In my view, why isn't the method called WAIT,
> in the process package,
Partly historical and partly so as to avoid naming conflicts when a
package wants to import multiple symbols named WAIT from different
packages.
I'll be happy to merge in any additions that folks want to write.
--David Gadbois
\
From: Bill Janssen
Subject: Re: Lisp Processes (was Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <y1a90dec71a.fsf@watson.parc.xerox.com>
ILU contains source for a process abstraction (including locking)
system, and a defsystem module.
See ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.
Bill
--
Bill Janssen <·······@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
·······@parc.xerox.com (Bill Janssen) writes:
> ILU contains source for a process abstraction (including locking)
> system, and a defsystem module.
Which - allow me to be extremely annoying :) - brings up the question:
why don't you switch to MK:DEFSYSTEM?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4d82sfe93.fsf@beta.franz.com>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> Let me add a question to this thread.
================================^^^^^^
A pun, right?
:-)
> What is the name (and nicknames) of the multiprocessing packages in
> LispWorks, ACL and MCL?
In ACL 5.0:
USER(1): (describe (find-package :multiprocessing))
#<The MULTIPROCESSING package> is the package named MULTIPROCESSING.
It has nickname: MP.
It uses packages: COMMON-LISP, EXCL, SYSTEM.
USER(2):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > Let me add a question to this thread.
> ================================^^^^^^
>
> A pun, right?
>
Well, it looks like we are processing are news files concurrently :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Duane Rettig <·····@franz.com> writes:
> In ACL 5.0:
>
> USER(1): (describe (find-package :multiprocessing))
> #<The MULTIPROCESSING package> is the package named MULTIPROCESSING.
> It has nickname: MP.
> It uses packages: COMMON-LISP, EXCL, SYSTEM.
> USER(2):
The same for lispworks.
Sunil
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u7k8x0nfxa.fsf@ebi.ac.uk>
On Tue, 2 Mar 1999 01:00:17 GMT,
"Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> The specific things I'm harping on--sockets, corba, etc. (someone
Kent> mentioned odbc) are all connective tissue. If we could connect to
Kent> other systems
On the CORBA front, there is definitely movement. Franz has recently proposed
a (new) lisp language mapping for IDL (OMG document number
orbos/98-10-16.pdf).
If there is a CORBA language mapping, a foreign function interface
essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
function interface. Imagine SmallTalk, Cobol, C, Python and Lisp programs all
talking to each other; all possible in CORBA.
Likewise, you don't really *want* sockets if you've got CORBA.
I imagine that the idl->Lisp language mapping is a very important development
(and could actually be the first lisp-related standard since a long time).
In summary, I would argue that CORBA support (a standard IDL->Lisp mapping
and at least one ORB) is the only thing really needed to counter the
lack-of-connectivity arguments.
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Philip Lijnzaad <········@ebi.ac.uk> writes:
> Likewise, you don't really *want* sockets if you've got CORBA.
OK, I'm not sure exactly what CORBA does. Does it support communication
over a network? If not, sockets are still necessary. Besides, not all
systems and programs support corba, and not everyone knows how to program
with it.
Sunil
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwiucjn7gm.fsf@world.std.com>
Sunil Mishra <·······@cleon.cc.gatech.edu> writes:
> Philip Lijnzaad <········@ebi.ac.uk> writes:
>
> > Likewise, you don't really *want* sockets if you've got CORBA.
>
> OK, I'm not sure exactly what CORBA does. Does it support communication
> over a network? If not, sockets are still necessary. Besides, not all
> systems and programs support corba, and not everyone knows how to program
> with it.
CORBA is, as I see it, a language-independent way of doing two things:
(1) Providing a firewall between interface and implementation, much as
CLOS provides a layer that DEFSTRUCT does not, so that if you
reimplement the internals, you don't have to reimplement the callers.
For example, when you talk to a CORBA object, you don't know if it's
really on your machine or if it's just a little communication station
that every time you talk to it calls out over the network to its home
base and finds out what to respond. (Of course, you probably find out
by latency or net protection errors, but no equivalent system not based
on CORBA does any better.)
(2) Providing (some) flexibility of hosting your object anywhere on the
net. It does have a model of being able to address a particular object
owned by a particular (actual or virtual) process on a particular machine.
CORBA was designed by people (some with a Lisp background) who did
understand object-oriented programming and who had a serious intent to
do a multi-language binding without leaving some languages out. It
does a credible job of creating a system that is at least capable of
being cast into many languages and hiding a reasonable amount of messy
details so you don't have to know the location (sort of), language, or
low-level data format details (wordsize, byte order, endianness, etc.)
of the other objects you're working with. The fact that it hides the
language and other details is a plus for Lisp since clients don't have
to know how you got them the answers, just that you did.
I have taken a course in CORBA but not to date programmed it, so my
knowledge is from having heard it explained and seeing demonstrations
done. If I'm in error on any of this, someone should correct me.
CORBA *is* communication over a network. Whether it also offers such
communication as a first class service a different matter, sort of
like how Lisp doesn't offer pointers as a datatype even though it's
all pointers, or how a database isn't about file access even though
all it does is access files. My impression is that to the extent
CORBA offers network access other than itself, it's as a layered
service someone put atop it, not by virtue of its intended nature.
But, nevertheless, just as someone could reasonably make the claim
that applications don't need files for a great many applications if
they have databasees, I suspect CORBA people could reasonably make the
claim that you don't need the raw net for many things if you have
CORBA. CORBA is one structured piece of a network puzzle, and it
would be the entire piece if everyone used it exclusively. To the
extent that they don't, of course, you need other things or layered
CORBA componentware. (And I suppose if someone left out the
componentware you could offer the service of connecting to the net
from your machine via a CORBA program that accessed your machine via
the net... :-)
Anyway, it's all about packaging. As far as I know, all of the
systems we're talking about not having socket libraries do have
foreign function call and that, I assume, implicitly supports
sockets--so it's really just about the raw power. Just about the
packaging.
Hope this helps frame the CORBA discussion for you.
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129400264626689@naggum.no>
* Kent M Pitman <······@world.std.com>
| (Of course, you probably find out by latency or net protection errors,
| but no equivalent system not based on CORBA does any better.)
dealing with networking problems is so complex that an application really
cannot afford to trust a pre-packaged solution that does not give very
good access to the error conditions. I've spent hundreds of hours giving
Allegro CL's socket package and my protocol on top of it graceful failure
modes. it's really hard work. judging from what I see from people who
just use some random pre-packaged library, this is not an area that
people tend to worry about, hence we get very dangerous solutions that
work in a perfect world, but not in the hostile world we actually live
in. what little I know about CORBA has not shown me a condition system
that is capable of what I need from a basically unreliable universe where
your application no longers dies when the machine dies, it may get wedged
in some zombie state when some machine you didn't know about dies, like a
router, a firewall, or simply someone messing up routing tables, etc.
stuff like happens all the more often the more you are interconnected,
and a distributed object system is no good if it doesn't deal with such
problems gracefully, in my opinion.
#:Erik
From: Paolo Amoroso
Subject: Dealing with network failures [Was: Re: Barriers to Lisp acceptance - a "survey" question]
Date:
Message-ID: <36dd376a.2384950@news.mclink.it>
On 02 Mar 1999 21:51:04 +0000, Erik Naggum <····@naggum.no> wrote:
> dealing with networking problems is so complex that an application really
> cannot afford to trust a pre-packaged solution that does not give very
> good access to the error conditions. I've spent hundreds of hours giving
> Allegro CL's socket package and my protocol on top of it graceful failure
> modes. it's really hard work. judging from what I see from people who
It would be very interesting to know how you deal with such problems. Do
you map the existing failure modes provided by ACL's socket package to some
sort of higher level error reporting/recovery layer? Or maybe you extend
the socket library to provide more--or possibly more useful--failure modes
reported by lower-level software? Or, of course, something completely
different?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Kelly Murray
Subject: Re: Dealing with network failures [Was: Re: Barriers to Lisp acceptance - a "survey" question]
Date:
Message-ID: <36DD97C7.239F18F5@IntelliMarket.Com>
I agree completely that its the error handling which is
the hard problem, and is HIGHLY unportable to both OS
and Lisp implementation. Just yesterday I debugged a ACL
socket problem that returned error code "22", which
was in fact, running out of available sockets.
And I also deal with error -14 when I/O into memory buffer areas
that don't exist yet (because they haven't been paged in from the DB..)
The problem is usually because that's all the OS gives you.
This is a great example of the value of a
Lisp-based operating system as opposed to running on top
of whatever C-based garbage is underneath...
Paolo Amoroso wrote:
>
> On 02 Mar 1999 21:51:04 +0000, Erik Naggum <····@naggum.no> wrote:
>
> > dealing with networking problems is so complex that an application really
> > cannot afford to trust a pre-packaged solution that does not give very
> > good access to the error conditions. I've spent hundreds of hours giving
> > Allegro CL's socket package and my protocol on top of it graceful failure
> > modes. it's really hard work. judging from what I see from people who
>
> It would be very interesting to know how you deal with such problems. Do
> you map the existing failure modes provided by ACL's socket package to some
> sort of higher level error reporting/recovery layer? Or maybe you extend
> the socket library to provide more--or possibly more useful--failure modes
> reported by lower-level software? Or, of course, something completely
> different?
>
> Paolo
> --
> Paolo Amoroso <·······@mclink.it>
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u77lsy28dh.fsf@ebi.ac.uk>
On 02 Mar 1999 21:51:04 +0000,
"Erik" == Erik Naggum <····@naggum.no> writes:
Erik> * Kent M Pitman <······@world.std.com>
Erik> | (Of course, you probably find out by latency or net protection errors,
Erik> | but no equivalent system not based on CORBA does any better.)
Erik> dealing with networking problems is so complex that an application really
Erik> cannot afford to trust a pre-packaged solution that does not give very
Erik> good access to the error conditions.
mm ... not everybody will (have to) go to that level. The networking part of
CORBA is provided by the ORB (Object Request Broker), and if the ORB gets
things wrong (which is sadly not too uncommon), you raise hell with the ORB
vendor. Depending on the ORB, you have more or less access to error
conditions and the like. From what I have seen, all this is at a higher
abstraction level than socket libraries.
Erik> what little I know about CORBA has not shown me a condition system
Erik> that is capable of what I need from a basically unreliable universe where
Erik> your application no longers dies when the machine dies, it may get wedged
Erik> in some zombie state when some machine you didn't know about dies, like a
Erik> router, a firewall, or simply someone messing up routing tables, etc.
Erik> stuff like happens all the more often the more you are interconnected,
Erik> and a distributed object system is no good if it doesn't deal with such
Erik> problems gracefully, in my opinion.
yes, absolutely. CORBA provides some of this functionality: a client will
simply get an exception (which it can and should handle) if the server cannot
be reached for whatever reason; it needn't die or zombify or anything. In
addition, IDL (the lingua franca) allows user-defined exceptions on any
user-defined methods.
Apart from this I think CORBA is the right kind of framework and abstraction
for doing distributed objects (even if imperfectly/incompletely
implemented).
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjyaleetvz.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
> Anyway, it's all about packaging. As far as I know, all of the
> systems we're talking about not having socket libraries do have
> foreign function call and that, I assume, implicitly supports
> sockets--so it's really just about the raw power. Just about the
> packaging.
>
I think that's not really clear. Of course it depends what you mean
by `have soickets', but if you want things to work such that the Unix
(or whatever) file descriptors get suitably wrapped up in Lisp
streams, such that CLOSE & so on work right for them, and so that once
you've done the initial startup stuff you don't have to know if
there's a socket there or a file, then I think that is asking rather
more than foreign functions, unfortunately. And that *is* how sockets
look from the C point of view, so you want at least that.
I only realised this when I was talking to someone the other day and
rashly said that sockets are obviously not hard in CL, when what I
meant was they're not hard to do in a portable way if you already have
some support for them...
Of course a CLOSified stream system would make this much easier (:-).
--tim
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfw4so2qxx2.fsf@world.std.com>
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Anyway, it's all about packaging. As far as I know, all of the
> > systems we're talking about not having socket libraries do have
> > foreign function call and that, I assume, implicitly supports
> > sockets--so it's really just about the raw power. Just about the
> > packaging.
> >
>
> I think that's not really clear. Of course it depends what you mean
> by `have soickets', but if you want things to work such that the Unix
> (or whatever) file descriptors get suitably wrapped up in Lisp
> streams, such that CLOSE & so on work right for them, and so that once
> you've done the initial startup stuff you don't have to know if
> there's a socket there or a file, then I think that is asking rather
> more than foreign functions, unfortunately. And that *is* how sockets
> look from the C point of view, so you want at least that.
Right, but in most modern Lisp implementations there is an FFI and there
is "Gray Streams" (david gray's protocol for writing user-defined streams
that do all the things you expect with streams). And that's enough to
for users to write what you want.
> I only realised this when I was talking to someone the other day and
> rashly said that sockets are obviously not hard in CL, when what I
> meant was they're not hard to do in a portable way if you already have
> some support for them...
Yeah, the underlying support isn't portable. But it is mostly
universally available, I think, just in slightly different form in each
implementation.
Tim Bradshaw wrote:
>
> I only realised this when I was talking to someone the other day and
> rashly said that sockets are obviously not hard in CL, when what I
> meant was they're not hard to do in a portable way if you already have
> some support for them...
>
> Of course a CLOSified stream system would make this much easier (:-).
>
Yeah, that's the real underlying problem, that CommonLisp is not
really an object-oriented language, but has CLOS tacked on the side...
And just to add fuel to the fire, notice that ACL uses low-level
hacks that don't really use CLOS for their streams because
CLOS was too slow...
Without stream objects and methods,
sockets are just another hacked C interface,
which has been implemented upteen times by upteen people in upteen
ways. I have my own too for the web server,
which doesn't even use a Stream API to avoid the overhead.
-kelly
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjbti9y29q.fsf@tfeb.org>
Kelly Murray <···@IntelliMarket.Com> writes:
> Yeah, that's the real underlying problem, that CommonLisp is not
> really an object-oriented language, but has CLOS tacked on the side...
> And just to add fuel to the fire, notice that ACL uses low-level
> hacks that don't really use CLOS for their streams because
> CLOS was too slow...
>
CL may not be OO compared to smalltalk, but it's a lot more OO than
Java, say. I think it's historically unfortunate that streams & other
stuff aren't CLOS objects, but there's no reason why they shouldn't
become so. (Actually, is there any major omission other than streams?)
I'm worried that people say CLOS was too slow for streams. Genera did
streams as flavors objects, and I don't see any inherent reason why
CLOS should be slower than flavors.
--tim
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfw3e3lxqbu.fsf@world.std.com>
Tim Bradshaw <···@tfeb.org> writes:
> Kelly Murray <···@IntelliMarket.Com> writes:
> > Yeah, that's the real underlying problem, that CommonLisp is not
> > really an object-oriented language, but has CLOS tacked on the side...
> > And just to add fuel to the fire, notice that ACL uses low-level
> > hacks that don't really use CLOS for their streams because
> > CLOS was too slow...
>
> CL may not be OO compared to smalltalk, but it's a lot more OO than
> Java, say. I think it's historically unfortunate that streams & other
> stuff aren't CLOS objects, but there's no reason why they shouldn't
> become so. (Actually, is there any major omission other than streams?)
>
> I'm worried that people say CLOS was too slow for streams. Genera did
> streams as flavors objects, and I don't see any inherent reason why
> CLOS should be slower than flavors.
I agree with Tim. CLOS is not just OO tacked on the side. CLOS
codifies a belief that Smalltalk was what was off-track. If CLOS had
been known at the time the language started, I think the designers
still would not have done something Smalltalkish exactly for the
reason Tim cites: fear that it would be too slow in some cases.
CLOS and metaclasses were a way of saying "sometimes you need less
accessible implementations in order to gain efficiency". Dylan
sacrifices metaclasses in hopes the compiler will somehow compile
back in the efficiency given the knowledge that something is sealed,
but it remains to see if that's "enough" to do that. It would have
been risky. CLOS, by contrast, even without the MOP admits the MO
part of the MOP--that is, there may not be a way to make things that
are subclasses of metaclass built-in-class in standard CL, but CL does
at least contain a recognition that there can and should be things
that are not of standard class.
In that light, streams *are* CLOS, and it always perturbs me when people
say they are not. Because to say they are not is to say that all there
is to CLOS is STANDARD-CLASS, which is not so. If you think object-oriented
is about standard-class, then indeed CLOS is not object-oriented. But
personally, perhaps just because of an accident of the history I grew
up with, I think object-oriented is about how you "call" an object, and
about the fact that it has identity and integrity (i.e., that you can't
see inside it) and not about how you "represent" an object. Sealing
a class (as in Dylan) means you can't get inside it--it might as well
be a different metaclass at that point since it isn't something you can
subclass. (Will I be repeating myself if I say "you don't ever get a
benefit for free--you always tarde it for something"?) Getting rid of
metaclasses doesn't make the problem go away, it just gets rid of the
terminology for expressing the problem succinctly. And being "object-oriented"
in the way some people want CL to be would not assure that streams would
be possible to subclass; only "requiring that streams can be subclassed"
means that "streams can be subclassed".
It would be a good thing for there to be a stream extension protocol,
but there is nothing about CLOS that is in the way of that.
*Maclisp* (on the PDP10) had extensible streams. They (SFAs, or
Software File Arrays, to distinguish them from "File Arrays" which is
what we called "streams" at the time since they were open to files
and since they were typep ARRAY for historical reasons)
were the historical precursor to flavors. Howard Cannon first
built SFAs and then having that experience went on to design Flavors
for the Lisp Machine. I'll recap that in case it went by too fast:
extensible streams led to flavors led to clos led to a wish that
we had known about clos early enough that we'd designed our streams
extensibly. Hmmm. The Lisp Machine had extensible streams. There
were at least 3 different ways to extend streams on the lisp machine,
maybe 4. (Only the stupidest and slowest of them was ever documented,
probably because it was so easy to document.) When CL was designed,
it was seen as very enormous and every time anyone suggested yet
another thing from the Lisp Machine it was given a "let's take half of
that" answer as if somehow "moderation" was the answer, and that's almost
surely the reason extensible streams didn't make it into CL.
SFA's didn't make it in because they were seen as baroque and idiosyncratic
in their design and most people wouldn't have thought them a serious
candidate, so Maclisp had nothing to contribute to make things better.
I personally loved SFAs and used them for all kinds of things, many of
which were not I/O--some that were just intra-program dataflow. I used
to wonder if I was "abusing" the concept. But so it goes. The point
is to say that the obstacles are, inevitably, political. We had the
ideas long ago. What stood in our way was a commitment to deploying
them. CL did the best it could to move the industry forward by
providing a great many standard things. It needs to move ahead again.
But technology (having CLOS) doesn't substitute for a will to solve
the real political problem (willingness to tolerate more pages in
the manual). It's painful to understand that size of spec--even of
ANSI CL--was seen as such a barrier when you look at some of these
3-inch "intro" books you can get now. The Java class library is in two
3-inch thick volumes and all it does is make money for the author.
If they could make 3 volumes, they'd probably make 50% more money.
Back to the point, though, history is not the enemy. CLOS is not the
enemy. The enemy of having extensible streams is having no agreed
protocol to extend streams. Simple as that. To fix it we need only
two things: a protocol, and an agreement to use it. We have david
gray' stream extension protocol ("gray streams") and it's widely
available. We should just agree to standardize it, fixing any problems
people perceive with efficiency as they come up.
From: Howard R. Stearns
Subject: CLOS-streams and OO CL (Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <36E02134.1BC81DCA@elwood.com>
I missed all this Gray Streams stuff here because I was busy addressing
it over in another thread (Re: Binary file io in standard common lisp).
See my comments there, which include a request for interested parties to
contact me regarding extending CLOS-streams and a standardizable
manner. Please don't respond on this thread because it's getting too
thick over here for me to follow all the threads.
By the way, with respect to CL being OO:
1. There are some comment on this at
http://www.elwood.com/alu/table/objects.htm. I welcome any
suggestions for changes/enchancements.
2. For my money, the big win with CLOS is often not in clases, but in
generic-functions, and this is what sets it apart from other "OOLs."
Given that structure-class and builtin-class are, in fact, classes that
can participate in dispatch, the trick with developing a MOP for
something like streams is in coming up with the generic function
protocol that can be extended by the user. The actual metaclass of the
user-defined classes which can participate in the protocol is less
important. In fact, I could imagine a streams protocol which defined
the generic functions and the classes involved, but left it up to the
implementation to choose and document the metaclasses of these classes
--- or even the metaclasses of the generic-functions!!!
3. Tim asked what else should be closified. Based on my comments
above, I'll take this to mean "what else is deserving of a
user-extensible MOP". One answer is pathnames, and this is part of my
comments on the other thread. See you there.
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4ogm9ck11.fsf@beta.franz.com>
Kelly Murray <···@IntelliMarket.Com> writes:
> Tim Bradshaw wrote:
> > Of course a CLOSified stream system would make this much easier (:-).
Allegro CL implements the "gray" streams proposal (the X3J13 issue
called "STREAM-DEFINITION-BY-USER, Version 1, 22-Mar-89"), with minor
adjustments.
> Yeah, that's the real underlying problem, that CommonLisp is not
> really an object-oriented language, but has CLOS tacked on the side...
This is exactly the way I like it. I suppose you could get some
OO purists to grunt, but I think the "hybrid" approach is a very
nice balance.
> And just to add fuel to the fire,
What fire?
> notice that ACL uses low-level
> hacks that don't really use CLOS for their streams because
> CLOS was too slow...
Looks like CLOS to me:
USER(1): (class-of *standard-output*)
#<STANDARD-CLASS BIDIRECTIONAL-TERMINAL-STREAM>
USER(2): (inspect *)
STANDARD-CLASS @ #x3002cc7a = #<STANDARD-CLASS BIDIRECTIONAL-TERMINAL-STREAM>
0 Class --------> #<STANDARD-CLASS STANDARD-CLASS>
1 PLIST --------> (CLOS::DEFAULT-INITARGS ...), a proper list with 6 elements
2 FLAGS --------> fixnum 0 [#x00000000]
3 DIRECT-METHODS -> (NIL), a proper list with 1 element
4 NAME ---------> The symbol BIDIRECTIONAL-TERMINAL-STREAM
5 CONSTRUCTORS -> The symbol NIL
6 AUTOCONSTRUCTOR -> The symbol NIL
7 MAGIC-CONSTRUCTOR -> The symbol T
8 DIRECT-SUPERCLASSES -> (# #), a proper list with 2 elements
9 DIRECT-SUBCLASSES -> (# #), a proper list with 2 elements
10 CLASS-PRECEDENCE-LIST -> (# # # # # # # # # # ...), a proper list with 15 elements
11 WRAPPER ------> simple T vector (7) = #(28502531 T ...)
12 DIRECT-SLOTS -> The symbol NIL
13 SLOTS --------> (# # # # # # # # # # ...), a proper list with 31 elements
14 PROTOTYPE ----> The symbol NIL
[1i] USER(3):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129645479482032@naggum.no>
* Kelly Murray <···@IntelliMarket.Com>
| Looks can be deceptive. One can't define their own stream class and
| standard stream methods that will be called by the lisp when it does
| I/O. Of particular grief is that #'format can't be called with such a
| stream. Or am I just confused and haven't read the manual?
yes, you are seriously confused and you spread lies and confusion to
others, as well. what you're doing should be illegal. it may well be.
I do what you say is impossible in a production system.
| How about this simple CLOS test to add another slot to an existing
| stream. It generates an infinite loop, and quickly kills off the lisp
| entirely. Should I file a bug report, or
|
| USER(2): (defclass mystream (BIDIRECTIONAL-TERMINAL-STREAM)
| ((myslot)))
| #<STANDARD-CLASS MYSTREAM>
| USER(6): (setf x (change-class *standard-output* 'mystream))
| #<MYSTREAM [initial terminal io] fd 0/1 @ #x200061d2>gc: done
| gc: done
| <<<lisp dies>>>>
I just tried this in both 4.3.1 on SPARC and 5.0 on Intel/Linux, and
_nothing_ unexpected happened.
I sincerely think you should stop doing something that clearly creates so
many problems for yourself. instead of being fun and profitable, Common
Lisp is hurtful to you. go do something else and make yourself happy.
#:Erik
From: Pirayeh Long
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36F2D9B9.3E6C@isomedia.com>
Erik Naggum wrote:
>
> * Kelly Murray <···@IntelliMarket.Com>
> | Looks can be deceptive. One can't define their own stream class and
> | standard stream methods that will be called by the lisp when it does
> | I/O. Of particular grief is that #'format can't be called with such a
> | stream. Or am I just confused and haven't read the manual?
>
> yes, you are seriously confused and you spread lies and confusion to
> others, as well. what you're doing should be illegal. it may well be.
>
> I do what you say is impossible in a production system.
>
> | How about this simple CLOS test to add another slot to an existing
> | stream. It generates an infinite loop, and quickly kills off the lisp
> | entirely. Should I file a bug report, or
> |
> | USER(2): (defclass mystream (BIDIRECTIONAL-TERMINAL-STREAM)
> | ((myslot)))
> | #<STANDARD-CLASS MYSTREAM>
> | USER(6): (setf x (change-class *standard-output* 'mystream))
> | #<MYSTREAM [initial terminal io] fd 0/1 @ #x200061d2>gc: done
> | gc: done
> | <<<lisp dies>>>>
>
> I just tried this in both 4.3.1 on SPARC and 5.0 on Intel/Linux, and
> _nothing_ unexpected happened.
>
> I sincerely think you should stop doing something that clearly creates so
> many problems for yourself. instead of being fun and profitable, Common
> Lisp is hurtful to you. go do something else and make yourself happy.
>
> #:Erik
What a retort. The perfect blend of viciousness and humor.
,@steve
From: Robert Monfera
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36F44B7D.225E3666@fisec.com>
Pirayeh Long wrote:
>
> Erik Naggum wrote:
...
> > I sincerely think you should stop doing something that clearly creates so
> > many problems for yourself. instead of being fun and profitable, Common
> > Lisp is hurtful to you. go do something else and make yourself happy.
> >
> > #:Erik
>
> What a retort. The perfect blend of viciousness and humor.
You helped me understand how Kent's surprise criterion is more general
than Naggum's optimal electronic communication theory.
> > One can't define their own stream
> > class and standard stream methods
> > that will be called by the lisp when it does I/O.
> > Of particular grief is
> > that #'format can't be called with such a stream.
> > Or am I just confused and haven't read the manual?
>
> You must be confused; read the manual. Or, if you like, try
> http://www.franz.com/support/docs/5.0/doc/cl/streams.htm
>
I stand corrected. It is possible using ACL extensions supporting
the "Gray" streams. Which looks pretty much like
CLOS tacked onto the side of Common Lisp.
-Kelly Murray
From: Jason Trenouth
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <37480829.971428203@newshost>
On 02 Mar 1999 14:07:29 +0000, Philip Lijnzaad <········@ebi.ac.uk> wrote:
> On Tue, 2 Mar 1999 01:00:17 GMT,
> "Kent" == Kent M Pitman <······@world.std.com> writes:
>
> Kent> The specific things I'm harping on--sockets, corba, etc. (someone
> Kent> mentioned odbc) are all connective tissue. If we could connect to
> Kent> other systems
>
> On the CORBA front, there is definitely movement. Franz has recently proposed
> a (new) lisp language mapping for IDL (OMG document number
> orbos/98-10-16.pdf).
>
> If there is a CORBA language mapping, a foreign function interface
> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
> function interface. Imagine SmallTalk, Cobol, C, Python and Lisp programs all
> talking to each other; all possible in CORBA.
>
> Likewise, you don't really *want* sockets if you've got CORBA.
>
> I imagine that the idl->Lisp language mapping is a very important development
> (and could actually be the first lisp-related standard since a long time).
>
> In summary, I would argue that CORBA support (a standard IDL->Lisp mapping
> and at least one ORB) is the only thing really needed to counter the
> lack-of-connectivity arguments.
Then consider them countered because two implementations of that draft
standard are already on sale from Harlequin and Franz.
__Jason
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwk8wzn8ff.fsf@world.std.com>
Philip Lijnzaad <········@ebi.ac.uk> writes:
> On Tue, 2 Mar 1999 01:00:17 GMT,
> "Kent" == Kent M Pitman <······@world.std.com> writes:
>
> Kent> The specific things I'm harping on--sockets, corba, etc. (someone
> Kent> mentioned odbc) are all connective tissue. If we could connect to
> Kent> other systems
>
> On the CORBA front, there is definitely movement. Franz has recently proposed
> a (new) lisp language mapping for IDL (OMG document number
> orbos/98-10-16.pdf).
You cut out the part of my discussion where I mentioned if it's not free
it doesn't really address the issue.
Saying you have to pay for CORBA is saying you have to pay for
anything CORBA gives you access to. If you're trying to compete
against Java because Java comes with a FOO for free, it doesn't
suffice to say that CORBA gives you access to Java and hence to FOO
for "free", since if you have to pay for the connectivity step, it's
the same as having to pay for the FOO.
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129402021067482@naggum.no>
* Kent M Pitman <······@world.std.com>
| You cut out the part of my discussion where I mentioned if it's not free
| it doesn't really address the issue.
while I'm sure consumers want anything for free if they could get it, I'm
a little concerned that people think there's business sense in providing
all of these "necessities" for free. you could argue increased sales and
make such freebies into marketing vehicles, but you really can't argue
that it's part of the standard and that vendors have to provide it. in
all this concern for user's needs, I frankly see much too little concern
for whoever is _actually_ going to pay for them, given that the users are
not even remotely interested in doing so.
I'm probably among the old school of "free software" in that I respect
that people will want to get paid for their efforts, that one has to
expect to pay real money to develop software, and that it should cost
money to have it supported, but that the _freedom_ of access to the
source code should not therefore necessarily be reduced. I do not think
the drive for "free as in gratis software" is healthy, and I actually
think that the more people demand from the vendors without giving them
any sort of incentive to do fulfill their demands, the less willing they
will be in fulfilling them. catering to thankless, non-paying demanders
is not good business.
besides, it's not as if this is rocket science. if you want it for free,
I say: drum up the people who are willing to do it for free, license it
so people can actually use it, and _chip_in_, don't just _demand_ that
others do stuff for you. programming is, after all, about bringing new
stuff into existence that you see a need for.
of course, I'm so happy that I don't _have_ to do a lot of work myself
that I'm fully willing to pay for access to it. I guess this makes me a
heretic, because the people I tell this to have these weird ideas that
I'm opposed to free software and "summarize" my position as "make, buy,
or shut up". apparently, the concept of creating something yourself to
give it away is _completely_ foreign to these whining losers, and then I
have even more reason to believe that they have no concept of how to make
the vendors do what they think is a smart thing to do, namely create
something they need and just give it to them.
how hard _can_ it be to write, say, a de facto standard socket interface
for Common Lisp and make implementations for all Common Lisps available
to the Lisp community for free? those who want it the most sound like
it's an insult _not_ to provide them with something that trivial.
in brief: if you think free software is so great, make sure it wins by
actually making the effort to make it available to everybody. meanwhile,
I want to get paid well for my work. my give-it-away-to-thankless-losers
time is history, but I'm sure there's business sense to _some_ people to
do all this stuff for free or you wouldn't demand it of others, right?
nobody can be so egoistic and self-centered as to completely ignore what
it takes to create something they want, can they?
BTW, I think free software is wonderful, as long as it doesn't mean that
people demand to get what I'm doing for them without compensating me, and
I cannot in good conscience demand anything like that from others, either.
yeah, I'd love to get everything for free, too, like great food, a socket
interface, great new hardware, CORBA support, fast Internet connectivity,
and of course entire Common Lisp systems, but I'm a little more realistic
than to expect to be able to _demand_ it. if somebody goes ahead and
makes any of this stuff available for free, I'll be looking for attached
strings and then I'll be happy if it's _actually_ free. in practice,
however, nothing is ever truly devoid of costs, and I sometimes prefer to
pay money and get off the hook. but that's just me, I guess.
however, I seem to recall several important speeches on copyright issues
for contributed stories to a "Lisp Lore Library" or something, and I fail
to see how software doesn't incur the same conditions and concerns.
#:Erik
Erik Naggum <····@naggum.no> writes:
> * Kent M Pitman <······@world.std.com>
> | You cut out the part of my discussion where I mentioned if it's not free
> | it doesn't really address the issue.
>
> while I'm sure consumers want anything for free if they could get it, I'm
> a little concerned that people think there's business sense in providing
> all of these "necessities" for free. you could argue increased sales and
> make such freebies into marketing vehicles, but you really can't argue
> that it's part of the standard and that vendors have to provide it. in
> all this concern for user's needs, I frankly see much too little concern
> for whoever is _actually_ going to pay for them, given that the users are
> not even remotely interested in doing so.
At this point in time, I believe that the vendors have some pieces of
software well developed, which they actually charge premiums for
distribution. This is a repackaging cost. I do not buy the argument
that there are still develepment costs to include CORBA support (or
MK:DEFSYSTEM) in the standard distributions (i.e. those affordable by
the individual - i.e. in the 456.85 Euro range) of Lispworks and MCL
and ACL.
Not doing so is short-sighted, as KMP has correctly pointed out with
very good arguments.
Note also that at this point, giving away these freebies is *not* (or
it shouldn't be) a marketing gimmick. It is the only way to expand
your user base. Assuming that that is what you want to do.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129456541194192@naggum.no>
* Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
| At this point in time, I believe that the vendors have some pieces of
| software well developed, which they actually charge premiums for
| distribution. This is a repackaging cost.
I wish these anti-vendor arguments could be a little more rational. of
course they have some pieces of software well developed, like the entire
Common Lisp system, the compiler, basically _everything_, right? the
_purpose_ of charging for stuff that has paid for its development is to
make it possible to respond to changes, continue to support customer
needs, develop _new_ things, and/or to ensure financial independence for
the founders or whatever. you don't appear to like this very much, but
as soon as you come out saying that you don't believe in profits or in
making money or in financial security or independence, business people
_should_ turn deaf to your concerns and your suggested "solutions".
prices are set in the market based on what people want to give for what
they get, and if this has worked well, it's really hard to argue against
the success. believe it or not, what you see today actually _works_, all
the misgivings to the contrary notwithstanding. people make money and
make good money doing what they are doing. you'll have to entice them
with _more_ money now or even higher future earnings at reasonably low
risk if you want to change their behavior.
| I do not buy the argument that there are still development costs to
| include CORBA support (or MK:DEFSYSTEM) in the standard distributions
| (...) of Lispworks and MCL and ACL.
it doesn't really matter that _you_ don't buy it. while it may change
marketing impressions and cause loss of goodwill if you ignore somebody
else's reality and try to force losses on them through the moral
equivalent of strikes and boycotts, the rational way to deal with this is
to convince whoever footed the development bill of your views, and then
you show them enough respect to listen when they answer your claims.
I'm in the business of selling software and my services to other people.
I have done so for 15 years. in these years, I have donated thousands of
hours of work to various causes that I believed in, some as a form of
marketing, some as more important than personal gain, i.e., I wanted to
create a better environment to work in rather than first reap the
profits. over these years, what I have seen as the most astonishingly
lacking in the demands and claims towards whoever should give people
something is respect for their motivation. I can only surmise that the
reason is that people don't ever stop to consider why _they_ are doing
what they are doing, either. (and maybe that's good for them. :)
| Not doing so is short-sighted, as KMP has correctly pointed out with
| very good arguments.
but who is he trying to convince? it doesn't matter that you agree with
him, as long as _you_ are not the person making the decision to repackage
or provide something for free. unlike what politicians believe, public
sentiment doesn't actually and by itself change reality, it only changes
how people will need to adapt to and change their experienced reality.
if you deny them the right to affect their own reality, you engage in use
of force, and you will therefore have to be treated as a hostile partner
at best. a lot of people find such tactics to be uninspiring, to put it
mildly. history is rife with people who stop doing whatever they were
doing when somebody tried to force them to do stupid things, but usually,
this happens to small businesses that just close shop when politicians
try to force them into doing something that doesn't make sense to them.
it actually doesn't help people change their ways into something more
constructive to tell them that what they are doing is short-sighted or
stupid. the best you can achieve with that tactic is that they stop
doing whatever they are doing and go away to regroup or do something
else. if you have a specific new behavior in mind, you have to motivate
it inside the core premises of their existing behavior. punishment does
not work constructively, has never worked constructively, and will never
work constructively. you punish to destroy, and the only hope is that
people have something else to do that is more constructive, but if you
punish, that's none of your business.
| Note also that at this point, giving away these freebies is *not* (or it
| shouldn't be) a marketing gimmick. It is the only way to expand your
| user base. Assuming that that is what you want to do.
this is what marketing is all about. you seriously underestimate
marketing if you think about their decisions and tools as "gimmicks".
I suggest you guys make a solid business case for what you believe in,
complete with market research and solid statistical groundwork, and I can
promise you that you will be surprised by the reaction. if you don't,
you're basically asking people to take your word for it and risk money on
sentiments that are openly hostile to making money the way they do now.
note that I'm not saying that I disagree with any of your issues, but I'm
_not_ whining about it on a newsgroup with a user-only "I need, so gimme"
focus when I want a vendor to change his ways. I also think your anti-
business whining could make my own efforts fail or make them harder, and
since I get everything I want, anyway, the question "why should I help
whiners who make things harder for me?" may soon require an answer.
#:Erik
Erik Naggum <····@naggum.no> writes:
> * Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
> | At this point in time, I believe that the vendors have some pieces of
> | software well developed, which they actually charge premiums for
> | distribution. This is a repackaging cost.
>
> I wish these anti-vendor arguments could be a little more rational. of
....
>
> I suggest you guys make a solid business case for what you believe in,
> complete with market research and solid statistical groundwork, and I can
> promise you that you will be surprised by the reaction. if you don't,
> you're basically asking people to take your word for it and risk money on
> sentiments that are openly hostile to making money the way they do now.
>
> note that I'm not saying that I disagree with any of your issues, but I'm
> _not_ whining about it on a newsgroup with a user-only "I need, so gimme"
> focus when I want a vendor to change his ways. I also think your anti-
> business whining could make my own efforts fail or make them harder, and
> since I get everything I want, anyway, the question "why should I help
> whiners who make things harder for me?" may soon require an answer.
>
Erik. I think I understand your points. But allow me to say, that I am
not 'anti-business' and 'anti-vendor'. I am very much in favor of
commercial activities and I am willing to buy software when this is
warranted. As an example, we are considering now to buy a copy of
Macsyma (http://www.macsyma.com). Which is extremely well priced wrt
the competition - despite the fact that it is basically a Lisp (ACL)
system :).
Franz, Allegro and the superb MCL are products which should be bought
on their own merit. Always provided that your work requires
them. However, there is a snag right now, in this historical
moment. People can get very good programming language systems for free
which provide more tools than the usual CL implementation. Java is the
example: they learned very well the Lisp lesson about having
standardized "language libraries" and applied with success. I do not
know if anybody noticed who is one of the co-authors of the Sun
Community License agreement.
There is no real business plan to make. You may not like my argument,
but it is all in economic theory regarding "network effects". The
first owner of a fax machine did not really have any "value" (not the
correct terminology - please bear with me) at hand. Then a second fax
machine got bought and suddendly the "value" of *both* fax machines
increased. Why did a third guy decided to buy a fax machine? Hey those
two guys were sending faxes to each other like crazy. Maybe he should
join the crowd.
And here comes the irking point. The third guy had to buy into a
certain technology. Otherwise he would not have been able
communicate. A second vendor decides to start building faxes. In order
to convince a fourth guy to buy his fax he must do two things (unless
he is so strong and daring to invent something different - let's say
the Mac - and try to impose a new standard; which will inevitably more
or less fail if he is not capable of understanding these rules):
her/his fax machine must comply with the "standard" and his costs must
be "better" in the marketplace. However it goes, the second guy must
bet on an increasing market. If he does that the "network effect" is
reinforced and the number of fax users may grow more or less
exponentially for some time.
KMP makes the point that "connectivity" is the fax machine of todays
for Lisp vendors. I make the point that MK:DEFSYSTEM is a much humbler
'fax machine'. Note that I do not care about the overall quality of
MK:DEFSYSTEM. Mark Kantrowitz comes from CMU. He may have met Herbert
Simon there and know the meaning of "satisfactory".
Now, does shipping MK:DEFSYSTEM make sense for a vendor? No, if you are
in a very strong market position and your market is wide. But this is
not the case of the Lisp market. I am willing to be contradicted by
numbers. But I believe that we need one, ten, a hundred, a thousand
fax machines.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
From: Rob Warnock
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7blnuj$ai56v@fido.engr.sgi.com>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
+---------------
| ... it is all in economic theory regarding "network effects". The
| first owner of a fax machine did not really have any "value" (not the
| correct terminology - please bear with me) at hand. Then a second fax
| machine got bought and suddendly the "value" of *both* fax machines
| increased. Why did a third guy decided to buy a fax machine? Hey those
| two guys were sending faxes to each other like crazy. Maybe he should
| join the crowd.
+---------------
This has recently come to be known as "Metcalfe's Law": The value of an
open/shared/interconnected product or technology increases as the square
of the number of users/nodes/connections.
"Unleashing the Killer App: Digital Strategies for Market Dominance", by Larry
Downes & Chunka Mui <URL:http://www.amazon.com/exec/obidos/ASIN/087584801X>
claims that the driving forces for all the "downsizing" & "outsourcing"
lately are Moore's Law, Metcalfe's Law, and Coames theory on the relation
between transaction costs and the optimal size of the firm. [Hint: Which
direction are Moore's Law & Metcalfe's Law driving transaction costs?]
If anyone is serious about trying to make a business out of Lisp (or almost
anything else), I strongly recommend reading this book. [Yeah, it's got
a hokey title, but just ignore it. There's some solid economics inside...]
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
> This has recently come to be known as "Metcalfe's Law": The value of an
> open/shared/interconnected product or technology increases as the square
> of the number of users/nodes/connections. [...]
> <URL:http://www.amazon.com/exec/obidos/ASIN/087584801X> [...]
> If anyone is serious about trying to make a business out of Lisp (or almost
> anything else), I strongly recommend reading this book. [Yeah, it's got
> a hokey title, but just ignore it. There's some solid economics inside...]
Which leads to the question:
why don't LISP vendors, particularly Harlequin,
that seems to be slowly moving away from being an active vendor,
publish their implementations as free software,
and sell branding and other services, like RedHat people do?
http://www.press.umich.edu/jep/04-03/young.html
Just because that model was discovered by UNIX guys
doesn't mean it can't benefit to LISP.
Actually, should LISP not follow this lesson, it will slowly disappear
as being irrelevant.
[I'd add that LISP, as a high-level language, is doubly disadvantaged
by the proprietary software model, as I've argued in
http://www.tunes.org/~fare/articles/ll99/index.en.html
]
I hope that people at Harlequin, Franz, etc, will heed this message,
or their LISP division might well end like Symbolics, Lucid, etc.
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
Francois-Rene Rideau <····@ZhengHe.augustin.thierry> writes:
> Which leads to the question:
> why don't LISP vendors, particularly Harlequin,
> that seems to be slowly moving away from being an active vendor,
> publish their implementations as free software,
> and sell branding and other services, like RedHat people do?
> http://www.press.umich.edu/jep/04-03/young.html
Although this is a conceivable outcome. I would not go that far. As a
matter of fact I simply claim that pushing toward more
"standardization" (quotes mandatory) without charging too steep a
premium price is necessary right now to expand the user base. That's
all.
I am happy to pay for a good product.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
On 04 Mar 1999 19:30:01 -0500, Raymond Toy wrote:
>>>>>> "Christopher" == Christopher R Barry <······@2xtreme.net> writes:
>
> Christopher> CMU Common Lisp is an industrial-strength free implementation and it
> Christopher> is barely maintained. I doubt a flood of volunteer bug-fixers and
> Christopher> feature-implementors would flood Harlequin's or Franz's product if it
> Christopher> were placed under a free license, when so little is done for CMU.
>
>[snip]
>
> Christopher> unthinkable. But CMU Common Lisp isn't the greatest example of the
> Christopher> open-development-model in action. It could use some major work in a
> Christopher> few areas where the commercial competition is doing better.
>
>While I agree that CMUCL may not be developing as fast as some may
>want, I think it's not because people don't want lisp. It's because
>modifying CMUCL can be extremely hard, even for things that are
>conceptually easy.
While I'm agreeing with the Raymond's statements, I feel that I must add
that also non-"kernel" related contributions would be nice. A partial
list of things that should be done, and can be done without recompiling
CMUCL:
- getting a free[1], working, portable DEFSYSTEM.
- adding extensions to CLX. At least big-request and shape extensions
should go in.
- working on _any_ of the GUI's: CLUE, Garnet. I don't care which one,
at the moment I'm trying to package up Garnet, but I wonder why, as I
don't see a community that uses it. I would like that a uniform GUI
based environment would suddenly appear. Get Hemlock to work with CLUE
for instance, and get CLUE to _finally_ use normal windows. <rant>The CLX
default windows have no place anymore on a modern desktop.</rant>
- Writing better bignum routines. You don't have to hack CMUCL for this,
just define your own bignum-tng type and write and debug all the code.
Integrating debugged, working code is not so difficult. (I hope) And
this is a better use of the few people who can integrate this into
CMUCL.
- Updating and integrating some of the PD code that is "out there". A
lot of this stuff just needs minimal cleaning up, or better
documentation. (e.g. Chess In Lisp. It works, it's nice and useful as
an example)
- Updating the documentation.
- Reporting bugs (no kidding, people sometimes complain to me that CMUCL
stinks, but they don't report it!)
Only recently I heard that there is a lisp-based web-browser "out
there". Don't you think a browser would look better as an example
program than a program that only uses "format" and "read" (and most of
the time even SHOUTS BACK :-))
Groetjes, Peter
[1]: See http://www.debian.org.
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
Kent M Pitman <······@world.std.com> writes:
> My recommendation about lowering the price on certain items is NOT
> based on a belief that people are ENTITLED to free stuff
You seem to imply that free software advocate all start
from an A PRIORI dogma of "entitlement" or "right". This is not the case.
Rather, free software (much like every other liberties, I may add)
are never better justified than A POSTERIORI:
they give us a happier and wealthier world, such that in the long run,
everyone wins, even those who have to sacrifice their priviledges.
On the contrary, it seems to me that those who claim an entitlement are
the hoarders who will sue people on the grounds of copyrights and patents.
Note that keeping source code secret (not publishing) is indeed a right,
but that it is not quite the same as forbidding anyone to arbitrarily use
software they have as they please (including running it, copying it,
redistributing it, reverse-engineering it, and modifying it).
You may well disagree with arguments in favor of free software, but please
admit that there is more to it than just A PRIORI ideological belief.
> but RATHER is
> based on a notion that Lisp isn't competing [...]
At the risk of being redundant, I'll again recommend
my previously mentionned article as an explanation
that not only is hoarding a form of protectionism,
but information hoarding is meta-protectionism,
software hording is meta-meta-protectionism,
and hoarding of development software is meta^3-protectionism.
Economic equilibria will naturally avoid all these forms of protectionism
in as much as possible.
Lisp has just no chance of beating the enemy if is meta^3-protectionist,
while they are only meta^2-protectionist,
even though it (currently) be technically superior.
On the *very* long run, of course, barriers will fall,
just because it is the common interest,
and then, the technically superior solutions may prevail
(whether it is still LISP, or something else).
But it is our responsibility to contribute to good things happening
within our life-time.
Again, I will gladly accept criticism on my article.
"Metaprogramming and Free Availability of Sources"
http://www.tunes.org/~fare/articles/ll99/index.en.html
Please help me understand better if I'm mistaken.
Respectfully,
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
Free Market is not the end of every large-scale economical problem;
but it's the beginning to any long-term solution to anyone of them.
Free Software is not the end of every large-scale software problem;
but it's the beginning to any long-term solution to anyone of them.
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwww0vc2aw.fsf@world.std.com>
I'll try to keep my reply brief on this since I see an infinitely deep
pit here I could fall into and I'd rather not let go of my rope.
Francois-Rene Rideau <····@ZhengHe.augustin.thierry> writes:
> Kent M Pitman <······@world.std.com> writes:
> > My recommendation about lowering the price on certain items is NOT
> > based on a belief that people are ENTITLED to free stuff
> You seem to imply that free software advocate all start
> from an A PRIORI dogma of "entitlement" or "right".
You inserted the word "all". If you remove the word all from your
statement, and infer instead the implied word "some" which is the
default usage, I do mean to imply THAT. Some do have the appearance
of thinking it a right or entitlement.
This is a general problem of thoughtful movements. After the founder
dies people lose track of why it started and a "good and thoughtful idea"
becomes "dogma". Choice is replaced with non-choice, and the ability to
respond to changing circumstance is removed. This is the problem with
organized religion today, for example. It started out well-intentioned
and has drifted because it has lost track of the problems it was trying to
solve or even the fact that it was a problem-solving device.
You have obviously though hard about this issue and I won't try to
dissuade you from your personal theory. But it seems to me it remains
a theory. It is possible to disagree. I have also thought hard about
this and I am trying to stake out a right to a counterposition in the
same space.
My position is based on the classical construction of copyright law in the
first place, which is that it exists to assure people will share. The
fundamental non-legislatable right is the right not to speak. Weak copyright
law is not about sharing ideas freely, it's about "sharing freely those ideas
spoken by people who understand that speaking is equivalent to `giving away'
or by people who don't understand the effect of speaking". That set of
people does not exhaust the space of possible speakers, and the fact is that
under weak copyright law, some would not speak, and that would be a loss.
Strong copyright law is clearly correct in the trivial sense that
using it you can implement weak copyright law. Anyone who wants to
give away their ideas can do so. It is the right to control
information that allows one person to implement powerful systems like
GPL. I choose not to subscribe to GPL as a creation vehicle for my
own thoughts, but strongly copyright law gives me the ability to
implement an alternative. Weak copyright law just gives big companies
the ability to roll over me because they can take what I use and produce
product and compete with me on marketing, which I can't afford and they can.
Weak copyright law if it ever comes will be the death of the "little guy".
I do think it's an error that patent law protects against independent creation.
That seems nutty and requires ESP to know you're not duplicating someone
else's process. I won't discuss patent and copyright in the same discussion.
I also think code copyright is too long. Three years seems adequate.
And I think ownership should revert to the people who did the actual work
in the case of disuse (the legal doctrine of "abandonment", I believe).
But I think text copyright being a fair fraction of the life of the author
is appropriate for the case of books and it will be a disaster if that
ever changes.
I can tell you for a fact that I would never post to this newsgroup or the
web at the rate that I do if posting meant giving up my rights. You would
have the right to receive my writings privately at great cost under specific
contract not to reveal my writings and that would be it. An elite subculture
that never spread. Too bad. It is exactly strong copyright that leaves
me free to post first and think about whether to formally publish what I
write second because my posting is not an automatic grant of license to
someone else to use my words. I post to share my ideas, not my words.
Ideas are not subject to copyright.
Copyright is an incentive to do great works and share them with the public
because it separates the notion of "sharing" from the notion of "giving
up right". "free software" is a step backward because it ties up the two
concepts and assures that anything one doesn't want to give up rights to
will also not be shared.
My purpose in my remarks before was not to rehash this old tired
issue, but to say that for SOME (not ALL) people there is a reasonable
concern that SOME (not ALL) other people want "free software" just
because they see it as an entitlement and they are insensitive to the
need of specific extant companies to stay in business while they
migrate to a future path. I am not a person who is insensitive to
these issues. I think there are such people, though I could be wrong.
I do not think all people are of that kind. I do think that those
people who think it's generally good to give away free software have
not done their duty to explain in dollar-for-dollar spreadsheet form
why Harlequin and Franz should just give away software they are now
selling. Absent such an explanation, I completely understand a
hesitation to proceed. It looks dicey to me. An interesting claim,
nothing more. And nearly all good ideas in business risk accidentally
crossing the $0 working capital line, so you can't just blunder forward.
My remarks were/are intended to provide a sense of my feeling of where
there might be a compromise between free(er) software and continued cash
flow that might help navigate that delicate line. I also don't have
spreadsheets. But then, I'm not advocating quite as extreme a point of
view.
You're welcome to reply. I may or may not follow up. This is very
off-topic and is more pain than I'm willing to do. I really feel like
I wasted the last hour talking about something I had no interest in
talking about because someone pinned me on a remark I had not made and
I was compelled to correct that. The whole point of my original
remarks had been to disassociate myself from presuppositions, not to
associate myself with othes, and all you did was attach a new set of
suppositions. I have necessarily advanced some suppositions here but only
defensively--I ask that you do not take my remarks as advocacy and that
you do not respond by escalating. I don't want to do another round of that
and will be very sad and annoyed if it happens. This is my day off, and
I could have spent the last hour working on my scifi novel instead of
correcting fallacies made specifically about me.
FRR> Francois-Rene Rideau <····@tunes.org>
KMP> Kent M Pitman <······@world.std.com>
FRR> You seem to imply that free software advocate all start
FRR> from an A PRIORI dogma of "entitlement" or "right".
KMP> You inserted the word "all". If you remove the word all from your
KMP> statement, and infer instead the implied word "some" which is the
KMP> default usage, I do mean to imply THAT.
Yes but then it's a more of straw man argument, and in as much as it holds,
it could very well be used one way as well as the other,
since as far as I can tell, tenants of proprietary software
are no less no more religious than tenants of free software.
Hum. Looks like I re-launched a discussion for a petty argumentation detail.
Oops. Sorry. I certainly didn't want to accuse you of fallacy.
After re-reading the posts, I admit that I have reacted inappropriately.
I will try refrain from posting on such subjects on comp.lang.lisp anymore.
The problem at stake is not with the opinions held by anyone,
but only with the fact that these opinions be held A PRIORI vs A POSTERIORI.
I *might* claim that freedom to FOO or not to FOO is a right,
yet not pretend it's a god-given right of which I had a revelation,
but rather than it finds its justification A POSTERIORI
in the global nuisance associated with refusing that right,
and the global welfare associated with acknowledging it.
KMP> You have obviously though hard about this issue
I thank you a lot for acknowledging it.
KMP> and I won't try to dissuade you from your personal theory.
Although I appreciate that,
I think this proposition should be quite independent from the former.
The latter should follow only
from our having found *where* to agree to disagree,
from my theories not being dangerous,
or from our mutual enlightenment otherwise not being worth its cost.
What the fact that we both have thought hard on the subject implies
is that we likely have internally consistent point of views,
and that it should be easier to find where they match not.
KMP> My position is based on the classical construction of copyright law in the
KMP> first place, which is that it exists to assure people will share.
And I admit my thoughts have led me to question this very construction,
that I had long before taken for granted, unquestionned.
Since we already found a fundamental divergence,
we can but acknowledge the further divergences.
But we can still explore and compare our conclusions
and let each other decide whether they reveal some contradiction
in one's own explicit and implicit assumptions.
We can also understand each other better.
KMP> under weak copyright law, some would not speak, and that would be a loss.
There are also people who won't speak under strong copyright law.
So the whole problem is:
"which law encourages most publication of useful information?"
KMP> Strong copyright law is clearly correct in the trivial sense that
KMP> using it you can implement weak copyright law.
While this of course isn't enough to break the conclusion of it,
I refuse this argument.
It's as if you said "right to government subsidies is clearly correct
in the trivial sense that you can implement lack thereof (by refusing them)".
Copyrights ARE a privilege granted by government
(which even the US constitution acknowledges),
and the indirect subsidies induced by this privilege
is the very encouragement to publishing done by copyright law.
These subsidies are paid directly and indirectly by all the citizens,
and that even if they don't want it; just because a citizen
doesn't claim privileges for himself won't discharge him
from having to pay for the privileges claimed by others.
KMP> I also think code copyright is too long. Three years seems adequate.
Indeed, the duration of the copyright is the price paid by State.
The amount of this price is not an eternal truth,
but has to be decided so as to optimize publication of useful information.
In particular, the amount should adapt to technological environment,
but this seems too difficult for legists to do.
My opinion is that there shouldn't be such thing as
automatic granting of privileges by the government,
for price should be decided by the market:
if people want an idea to be published rather than kept secret,
they can organize in private groups who'd buy *access* to the information
and republish it (or not). There is no need of forcibly slowly-adaptating
state law for that, only of competing private infrastructures.
A free market means that information will be paid a balanced price:
worthless information won't be paid
(instead of being given a systematic premium as is the case now),
while worthwhile information will be paid as high as can get
(instead of being systematically undervalued as it is now).
Maybe the state itself, as an economical actor among others,
may participate in bids, offer prizes, etc, for particular information;
it needn't systematically enforce "egalitarian" price to all information.
This is an elementary free market argument to me.
I understand that it might not be compelling to you, though.
KMP> I can tell you for a fact that I would never post to this newsgroup or the
KMP> web at the rate that I do if posting meant giving up my rights.
What rights exactly do you want to keep? And whence do they come?
Are they natural rights, or State-given privileges?
Is that protection against copy, or against misuse and liability?
There is no A PRIORI reason why you should be liable
for people copying your work, or why their activity
be not subject to prosecution for libel, perjury,
misrepresentation, and crookery, independently of any copyright.
I'm not convinced that Copyright as it exists protects the Right Things (TM).
It is great that on usenet,
we may find people capable of civilized discussion;
I will try harder to be among of them.
Thank you, Kent, for your living lesson,
and sorry for wasting your precious time.
And now, back to LISP!
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
I do agree that I have to pay for the *opportunity* to read a book or to use
a program; I do not agree that I have to pay for the *right* to do so.
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87d82ne791.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
[...]
> I could have spent the last hour working on my scifi novel instead of
> correcting fallacies made specifically about me.
I remember you mentioning this before. Have you picked a title for it
yet? How will you be publishing it? I hope you keep us informed of its
progress from time to time.
Christopher
On Sat, 06 Mar 1999 01:19:45 GMT, Christopher R. Barry
<······@2xtreme.net> posted:
>Kent M Pitman <······@world.std.com> writes:
>[...]
>> I could have spent the last hour working on my scifi novel instead of
>> correcting fallacies made specifically about me.
>
>I remember you mentioning this before. Have you picked a title for it
>yet? How will you be publishing it? I hope you keep us informed of its
>progress from time to time.
"When will it be done! When will it be done! When will it be done!"
(And memory goes back to a Spider Robinson short story where two
foolish burglars make the mistake of thinking a house is empty. When
they regain consciousness, they realize that they have made the severe
mistake of provoking an author, who cyranoacrylated them together, and
now that they are no longer disturbing him, has gone back to his den
and forgotten that they exist... "Help! Police! WE GIVE UP!")
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
········@hex.net - "What have you contributed to free software today?..."
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwn21p6h76.fsf@world.std.com>
······@2xtreme.net (Christopher R. Barry) writes:
> Kent M Pitman <······@world.std.com> writes:
> > ... scifi novel ...
> I remember you mentioning this before. Have you picked a title for it
> yet? How will you be publishing it? I hope you keep us informed of its
> progress from time to time.
It has a working title, but it's a secret for various reasons--at
least one of which is not pure superstition. I'll be sure to mention
if it gets close. I'll be counting on lispers to buy a copy... Lisp
is kind of like scifi, after all... fanciful technology you wish you
had all around you ... not to mention a catalyst/stage for great
social drama.
From: Raymond Toy
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4nww0vkgcx.fsf@rtp.ericsson.se>
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> My recommendation about lowering the price on certain items is NOT
Kent> based on a belief that people are ENTITLED to free stuff but RATHER is
Kent> based on a notion that Lisp isn't competing and a strategic belief
Kent> that the strength of the "enemy" (C++/Java/etc) can be leveraged
Kent> against them by annexing their work. In so doing, one sacrifices some
I've always felt that Borland way back when had the right approach.
They were selling nice fast Pascal compilers for $50 when everyone
else was selling theirs for $500. After a while, I didn't know anyone
without Borland Pascal. I think this also greatly reduced losses due
to piracy. I was certainly willing to pay $50 for the disks and
manuals. If I had pirated it, then I'd have to go out and get one of
the How-To books for $50 anyway.
But perhaps this won't work for Lisp? I have no idea of the cost
structure. I also note that it's pretty hard to find tools that cheap
anymore. Things that cost more the $100 require more thought.
Ray
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129644482406982@naggum.no>
* Francois-Rene Rideau <····@ZhengHe.augustin.thierry>
| AFAIK, I don't preach doomsday. Actually, there *cannot* be a doomsday,
| since the end of all LISP vendors are such would only mean that all
| (remaining) LISP are free, which would be regeneration day!
I think you just made anybody interested in providing professional Common
Lisp systems anxious and less willing to help you reach your goals,
because your goals clearly include the elimination of a livelihood for
Common Lisp vendors. this is not smart of you. in fact, it may cause
what source access we have today to be retracted because people like you
are likely to steal it and violate license agreements as you see fit.
| That there would be a tall wall between the lucky ones who can access
| LISP for their work, and those who mostly can't.
the existence of all life forms is based on whether they can get what
they need to thrive and survive. there is nothing in the human condition
that invalidates this. "have vs have not" is a fact of life as such, and
as unchangeable as the earth orbiting the sun. humans, however, tend to
worry about it and want to change it, and this is perhaps good for some
of us, but we can't get rid of the fundamental principle of life: there
will _always_ be a "tall wall" between the "lucky" ones and the rest.
moreover, "luck" is not what you think it is. success is exploiting
timing. luck is _only_ timing. luck is like winning the lottery.
success is seeing and taking advantage of any break you can get. that
both have to do with timing is a mere coincidence of timing (luck :).
however, what you are doing is actually _depriving_ people of what they
need to thrive and survive: if writing something in Common Lisp means it
can only be given away, people with financial responsibilities will flee
in panic as all they can see is non-recoverable expenses, and everybody
_but_ the people who do the real work will be rewarded, in much worse
ways than "capitalists" are supposed to exploit "workers" today.
in my view, Common Lisp provides _values_ that far exceed what other
languages do, but I fully realize that people won't understand this until
they have actually experienced the problems that it solves for them.
now, what's _really_ sad is that those who want free Common Lisp systems
have _not_ seen what the commercial systems provide in just this way, and
they will go on to make free Common Lisp systems that just _don't_ offer
the serious advantages that solid Common Lisp systems do that people
can't _afford_ to provide for free.
| That's the disappearance in irrelevance that I fear.
one man's niche market is another man's irrelevance.
| This would be (and this actually is) an enormous waste or human
| resources: people (LISPers and non-LISPers) who do things independently,
| and ever restart from scratch, instead of building on each other's code.
geez. welcome to planet earth.
| So much human resources spent for no progress!
you _really_ have to be new here.
| Granted, nature lives on infinitesimal yields.
yes, this is a _fundamental_ premise.
| Still, unless I am proven that this is a inevitable doom, I won't be
| quite satisfied.
some people will never be satisfied no matter what you give them or do
with them. it is important to know who those people are, so we don't
waste any time or other resources on them.
doom is inevitable, BTW. mankind will die out, planet earth will be
vaporized when Sol goes nova, if not sooner, and then Common Lisp will
have to acknowledge defeat to the unwavering hostility of the universe.
for those of us who plan to become immortal, this is a serious concern.
| Well, maybe I'm just unlucky, and not introduced in the right places, but
| here in France
depression is all about focusing on the negative things you observe,
about expanding the impression of being "unlucky" to some kind of cosmic
condition and from then on doing the opposite of what normal people do,
which is to ignore the negative and the hardships because they _expect_
every ounce of positive experience to have a pound of cost, and they
_know_ that errare humanum est, and that errors have costs, too. on top
of this, the depressed tend not even to _see_ anything positive.
instead of blowing your own dismal experiences out of proportion, look at
what made people change their minds to use clearly inferior languages in
somehow superior _tools_. see if you can do something about this and
make a couple franc on it. instead of doing the stupid "if everything
were free, we'd never be hungry and there'd be peace on earth" routine,
think about what _you_ need to _supply_ a Common Lisp environment to
people, what you would need to do to make people _buy_ from you to keep
you alive, and what your _customers_ would want to do. think business.
"free" works very well for the hobbyist market. it works not at all for
the professional market. now, you might argue that all programmers are
hobbyists, but I'd argue that that's about as relevant as your experience
with Lisp "dying" in France.
| While I'm happy for you, and convinced that the positive activity of
| people like you will only increase the number of people using CommonLISP,
| I fear that, thanks to your own value, the world around you is much
| better than it is elsewhere, and I'm still worried about the future of
| LISP.
this _really_ sounds like clinical depression.
| Feats of exceptional individuals are not enough to make prosper large
| economies; economies work as the result of a network of normal people,
| with a normal bell-curve distribution of proficiencies.
I'll take that as a compliment, but I think you exaggerate my abilities
and what I have done so you don't have to consider me as part of "normal
people". this is not new: if normal people do something exceptional or
out of the ordinary, they somehow have to be exceptional individuals, and
whatever remains as "normal people" can feel better about not doing
anything exceptional. I think this is fundamentally false. first, this
delusion gives normal people a psychological barrier to break out of the
pattern. instead of facing hardships and surviving them, they meet
hardships with "am I sufficiently exceptional to _ever_ win?", and go on
to lose, which only serves to prove their point. second, it makes it
much harder for normal people do to a _few_ exceptional things, because
they then have to defend why they, as exceptional individuals, do _only_
normal stuff the rest of the time. these are fundamentally _dangerous_
psychological issues and make individual success into a serious hazard
for people who _aren't_ able to take the expectations well. (you need
look no further than to the many musical artists who turn to drugs to
deal with the pressure.)
| And if there's any reason to worry about LISP being more widely used
| (which you seem to do, since you're affirming gladly that the Lisp market
| is growing), we need understand the phenomena at work, and not just blame
| people for not being virtuous enough.
that didn't quite parse, but I don't blame people for not being virtuous
enough. nobody does that as far as I can see. I'm saying that you need
to mature to appreciate the value of Common Lisp. being immature is just
another fact of life, but maturing doesn't happen to people who expect to
have reached their goals and set no further goals for themselves. add to
this that reaching your goals sometimes means abandoning what cannot be
reached -- going on and on forever is also immature.
| To prosper does not only mean survive, but also grow.
survival is easy to measure. so is decline. growth, however, is hard to
measure, since in order to do so, you need to know the goal and see the
small steps on the way (and why certain setbacks are _not_ decline), and
absent such often secret information, you can't see growth because you
don't know what to look for. this is why whiners will point to the
decline of Lisp (which they think they can measure by any form of failure
to live up to _their_ expectations) and ignore the growth because they
have some pretty bizarre ideas about what growth means in the first place.
| I can very well imagine Perl 7 having just every semantic feature from
| LISP ...
I'm sorry, I can't. people said the same about GUILE a few years ago,
and what we have today is a hopeless mess that's only getting worse.
| If LISP is to prosper, it must drop proprietary software barriers; it
| must enter the free software model.
yeah, if Lisp is to grow in _your_ mind-set, it has to do that.
however, your mind-set is a recipe for economy-wide disaster, as the free
software world will find out the very hard way when they have succeeded
in defeating Microsoft, which is the _real_ purpose and driving factor
behind Open Source. Free Software has a higher goal, but it appears that
the success of Open Source projects are jeopardizing the goals of Free
Software, which I think is quite clear if you watch what RMS is saying
and doing lately. if you _understood_ his reaction to Linux a few years
ago (instead of just ridiculing it), you will appreciate that his concept
of Free Software is in jeopardy. Open Source is much _more_ in jeopardy
than Free Software is, because its success is defined in terms that do
not stand up against a maturing public.
another interesting legal issue that proponents tend to ignore completely
is that the licenses that people have to agree to to get "free" access to
software are binding in ways that people are willing to accept in the
short term, but whose long-term consequences are extremely unlikely to be
honored. no _commercial_ license would be valid if it were to place
similar demands on people. California has laws that make any license or
contract that excludes people from entering reasonable livelihoods
unenforceable. what you can agree to for perpetuity is very strictly
limited in commercial contracts and licenses. it is not when no money is
being exchanged. people will eventually wake up in panic and angst when
they fully realize what they have agreed to.
| Harlequin (and maybe Franz) already earns most money from services;
| maintaining their LISP implementations is part of their cost structure,
| not of their benefit structure.
this looks like a statement of fact, but it is mere opinion. stuff like
that is not something a company would tell anyone without also swearing
them to keep it secret. therefore, there is no way you could make an
informed opinion about this. therefore, since you present it as fact,
you are lying. this is completely orthogonal to whether it is true or
not: it is pretending to know what you _cannot_ know that is the lie.
| By publishing their core software under a free software license, they
| would gain a lot by outsourcing part of this maintenance, yet they could
| make BIG BUCKS by selling branding, support, ports, development,
| applications, etc.
again, this is mere opinion, and if they don't do it the way you think
they should do it, it is not because they want to lose money, but because
you are wrong, at least as far as they see things. if you can't make
them see things your way, buy them up with your own money and make them
do what you think they should. perhaps you look at things differently
when you own the companies you want to kill, perhaps not, but at least it
won't be anyone else's money you lose.
| Their IP barriers only protect them from each other, leaving them on a
| small market. Dropping these barriers will allow them to attack the real
| enemy, and grow a mass market.
so "growth" coincides with "mass market" in your view. my view is that
it is the mass market that has destroyed the field of programming, as it
destroys almost everything else that has any form of creativity to it.
here's a scenario that you should consider: remove intellectual property
from broadcast sports shows. explain how it does not kill the sports
industry.
there are no _enemies_ in the market. you gotta lose the paranoia.
(well, Microsoft _is_ an enemy, but they are an enemy of everything and
will be destroyed through or by their own tactics. ignore them and focus
on what a company that intends to hang around for a while needs to do,
not what a company that intends to defraud the most people before they
are caught would do.)
| It's a war.
no, it isn't. this is just paranoid delusions.
| The high-level LISPers against the low-level C-ish world.
no. this is also a paranoid delusion.
| The latter has a quasi-monopoly on people's minds.
this is not just a paranoid delusion, anymore. this is _insane_.
| You can't fight a monopoly with protection barriers.
| You can only succeed by being more open than it is.
you support my conclusion that Open Source is only a means of fighting
Microsoft. I'm interested in what happens _after_ Microsoft. you can
succeed in defeating Microsoft by undermining their market with free
stuff so they can't sell anything, anymore, but what do you do _after_
you defeated them? how do _you_ intend to make money?
Common Lisp is _not_ a mass-marketable commodity. Java has yet to make
any form of profit anywhere. in fact, the whole Internet has yet to make
a global profit. the stuff that makes loads of money on the Net is sex
and trading in Internet company stocks. if you are hell-bent on the fast
buck, start another pornographic site. if you want a little less dirty
money, hype your company on the Internet so people will buy your stock
like crazy (which they are). if you want to make long-term money, sit
tight, do good work, and don't for a minute believe the short-sighted
morons who want only fast bucks and regard financial robustness as stupid.
Java was created to fight Microsoft, and since Microsoft "made" the C++
market, it was necessary both to attack C++ and the desktop through the
browser. Open Source was created to fight Microsoft. when Microsoft
falls, these things will also go away, like used weapons. I think Linux
will prevail and that other _sincere_ Free Software will prevail. I
don't think wapons of mass market destruction will survive what they were
instrumented to destroy.
| Well, before someone may become mature, they are kids. If you don't
| breed them as kids, don't expect them to be gentlemen when grown up.
I think something got lost in some translation, here.
| If you prevent the kids from using LISP until they're already grown up,
| it's too late afterwards.
so not making something free is "preventing" people? this is paranoid.
| Maybe I'm plain wrong.
you have argued that people who make money on Common Lisp should stop
doing it and instead give all their values and investments and work away
so "Lisp" can prosper. how could anyone argue against this? it's insane.
"Lisp" is not some abstraction devoid of materialization. it's not like
you can make any form of _idea_ win without actual implementations and
solid vendors.
you can't make anything prosper by removing every incentive for people to
_make_ it prosper, i.e., you can't make something prosper by making some
people _pay_ to make it prosper. _all_ parties involved must profit. if
you don't understand this, you will succeed only in making it fail.
incidentally, you appear not to know that when you purchase an Allegro CL
license, you get a whole bunch of source code with it. you can't share
it with others, but you can obviously do everything you otherwise would
do with free source code, like fixing bugs, changing system behavior,
etc. hell, that's what I have done. you're under no obligation to ship
code back to Franz, either, and you get to keep your own modifications
and include them in your products. this is _better_ than Open Source for
people who do _business_ and not just hobbyist projects.
#:Erik
From: Greg Menke
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <wkemn3aede.fsf@erols.com>
You make some compelling arguments, Erik. I think I agree that the
rise of Open Source owes much of its strength to anti-Microsoft
sentiment. However, I think the movement is somewhat more complex.
Given the assumption that Open Source hasn't proved itself yet, I
think it does offer longer term benefit. For example, the company I
work for (www.homedome.com) sells fiberglass observatories to amateur
(and pro) astronomers. I work on the remote computer control systems
for them. These systems include client software for the PC and an
embedded controller which goes in the dome. (Please pardon my use of
VB on the PC- it was convienent, but I do use Emacs for the embedded
stuff). As soon as its viable (and I learn enough), we will write a
Linux client.
We release the source code for the PC client software along with the
binaries under the Open Source model, and although we haven't put it
on the web site yet, we will do so when the code becomes more stable.
Its evolving so rapidly that its hard enough to manage the version
control alone. We have 2 control systems and have shipped 15 of one
and over 20 of the other.
We regard the PC client software as something of a lost leader. In
our opinion, the more people who write programs for our dome
controllers the better so releasing the source might help spur
purchases of our control system. If someone chooses to reverse
engineer the embedded controller, and maybe use our protocol then we
must compete on technical grounds- but thats what people do in a
competitive market. If we cannot compete on technical grounds, then
we loose. I guess the "natural" tendency is to put all sorts of
license restrictions in place and keep a bunch of lawyers chained up
and fed with raw steak, but we're a small company and can't afford it-
and I think our customers would be better served in an open
enviornment with competition (or at least the opportunity for
competition).
I can't comment on the other Open Source models, but I think if
companies positioned to do something like this do so, it will make
many systems of various kinds more available and interoperable -
simply because the interfaces are opened and documented.
Having said the above, we do not plan on releasing the embedded code-
we want the systems to be open for people to use how they choose, but
in the end we must protect our technology investment.
Its possible that "pollutes" me with respect to Open Source, but I
think the ultimate significance and form of Open Source is not yet
clear. It may be that Open Source is only effective for particular
classes of software, if so, I think thats to everyones benefit because
I think the computer related industry is far too complex for a single
business model.
Gregm
FR> Francois-Rene Rideau <····@tunes.org>
EN> Erik Naggum <····@naggum.no>
Dear Erik, dear Howard, dear comp.lang.lisp readers,
I would prefer to resume my work rather than post yet another article
on the topic, but there are many misconceptions about free software
that seem to creep in your posts, that I'd like to dispell,
even though odds are low that will suffice to convince anyone.
As I do, I'll try to draw the sketch of a business plan
for a LISP vendor producing free software LISP systems,
as suggested by Howard R. Stearns in another message.
Other topics addressed in another message.
First, I want to clarify that I do NOT want the death of LISP companies.
It's all the contrary. I only wish them success and prosperity.
Only I'm convinced that the proprietary software model is flawed,
and that we'll only see LISP flourish
when there is a solid free software infrastructure to back it,
be it based on current LISP vendor capital, or on new capital
(I have no doubt that the people doing the underlying technical work
will be mostly the same in any cases).
Under the free software model that I'm convinced is economically sound
(and much sounder than the proprietary software model),
LISP development companies make money by selling *services*, not licenses.
Services include:
* trust (availability, reliability, branding, of code),
* support (correction of bugs in the customer's code or the core system),
* development (ports and extensions to the system),
* customization (development and deployment of customer-specific solutions),
* education (training and documentation).
Companies that already prosper thanks to free (non-LISP) language software
include Cygnus (www.cygnus.com) and AdaCore Technology (www.gnat.com).
The real, worthy, asset of these companies
is NOT their "intellectual property",
it is their *human capital*.
They prosper because they value *people* rather than software.
To them, non-licenseed users are growing their overall market,
and the opportunity for future services being sold,
not "thieves stealing important company asset".
So the marketing is: advertise solutions, advertise support,
give away as many copies of the software as possible (including by FTP),
to create an ever growing market for *services*.
I invite you to read the AdaCore site to see that these guys mean business.
Of course you may disagree that this model is sound,
but at least I'd like you to acknowledge that even if they be mistaken,
free software advocates are NOT against business.
I am deeply convinced of the essential morality of free market economy;
now if you read classic texts (Turgot, Bastiat) you'll see
that market economy is free exchange of *services*
and elimination of *priviledges*.
I rank any Lisp related *work* (see above) as a *service*,
and licenses as *priviledges*.
FR> Harlequin (and maybe Franz) already earns most money from services;
FR> maintaining their LISP implementations is part of their cost structure,
FR> not of their benefit structure.
EN> this looks like a statement of fact, but it is mere opinion.
Yes, I'm sorry, and I apologize.
Although I'm as convinced of it as can be without seeing actual figures,
this was only an extrapolation,
and I shouldn't have made it appear that factual. MEA CULPA.
However, I'm not extrapolating from nothing,
and since you pinpoint the above fact,
I feel compelled to explain my reasoning:
* commercial licenses from LISP vendors include support,
a support that you've demonstrated was highly valued.
This I count as a service, even if in its current form,
its sale is tied to a licensing agreement.
I'm convinced that people who purchase licenses with support
would equally buy that same support that they appreciate,
even though the bare license was free of cost.
In other words, the monopoly value of the license seems little to me
before the service value of the support.
Even though the sources be free software, the vendor,
as principal author and maintainer of it, would still have
a competitive advantage over competing providers for support service.
* It is the announced policy of Harlequin to move
from the language vendor industry as such into the service industry;
it looks like they already have quite a business in that field,
and are only expanding more into it,
because they (at least) feel that the big bucks is definitely there.
In such a setting, the software is useful as a tool,
but it's a burden as "intellectual property",
since it enters the cost structure and becomes a burden to market entry;
making it free software both allows outsourcing of part of the development
and removes fear from potential customers of being tied with proprietary
tools that however technically good are guaranteed anti-perennial.
All in all: the market, even the current one, is mostly in services,
and the monopoly value of proprietary licensing does not look to me
like it benefits much to the vendors, all the less in a niche market,
while it prevents market growth.
Can someone at a LISP vendor tell me how right or wrong I am,
even without giving any figure?
FR> Their IP barriers only protect them from each other, leaving them on a
FR> small market. Dropping these barriers will allow them to attack the real
FR> enemy, and grow a mass market.
EN> so "growth" coincides with "mass market" in your view.
Well, since we're talking about a programming language,
that'll more be "mass of average developers"
than "mass of average consumers".
But yes, I'm convinced that growing the LISP market
means attracting more developers to LISP.
It'll benefit vendors by lowering the customer's cost of entry
in a LISP system, and lowering average wages of LISP programmers.
It'll benefit good LISP programmers by giving them the opportunity
to rise in a market of LISP programmers.
It'll benefit (currently) non-LISP programmers by giving them
the opportunity to find a decent job where to program with a decent language.
It'll benefit end users, because LISP will yield
better cheaper more reliable software.
Everyone wins. Only C++ and Java crooks lose. Unless they become LISP crooks.
If you stay a niche market, invert those benefits.
I am deeply convinced that the interest of LISP vendors
is to make their core system free software,
so as to gain as many developers as possible, and sell services.
So as to get a stable hold on the heart of developers,
they should also encourage the development of a large developer community,
by creating a body of software that covers their need
(i.e. removing any possible "need" for tools like make, perl, and
all the unix infrastructure, yet allowing unix tools to seamlessly
interface the LISP system so as to incrementally penetrate the market;
having a native Emacs port).
That's the kind of developer-directed marketing I'd do.
Once developers are hooked on a technically superior system,
they won't leave it, and will become the seeds that grow
into demand of more services from their employers.
> [Erik about ACL handing sources to customers]
I have a sad story to tell (please anyone correct me if I'm wrong):
satisfied customers of ILOG Talk have developed a lot of software for it,
and contributed infrastructure back to ILOG, who incorporated it in
the main source. All in all, it's been a happy story for 7 years.
But one day, ILOG decided it was not making money in the LISP business,
and announced Talk would no more be maintained. Good bye, bug fixes,
good bye ports, good bye ILOG Talk.
Remaining customers promptly decided to migrate
all their development to C++, Java, Smalltalk, or whatever they could.
All their code base was technically lost.
Even though they could negociate the use of sources for Talk as customers,
and even though their maintenance contract will last a few more years,
they would have to do all maintenance in-house afterwards,
and not be able to reuse the resulting code for other projects
or share it with others. Economically, their code is DEAD,
and it will soon be in every other meanings of the term.
Even the healthiest vendor can die or change its business plan
(should I cite names of LISP/LISPM companies?).
Even the wealthiest software company on earth eventually ceases to maintain
its development platforms (my employer knows that *very* well!).
With proprietary software, the consumer is at mercy.
His development software is not perennial.
When it's a lame low-level language like C/C++/Java (because of JVM),
that's fine with him, because the abstraction level required
for compatibility is low (like the whole of the software),
and he can easily switch vendor.
When it's a high-level language like LISP that has special dependencies
on a large proprietary runtime, he's stuck, and too bad for him.
By making code free software,
you give customer the guarantee of perenniality.
Customers are beginning to understand that, and the more they do,
the hardest time vendors will have at not publishing free software,
unless they are die-hard big-time monopolies.
Moving into a free software service company means you don't rely
so much on the artificial monopoly value of licensing your software,
but rather on the natural workforce value of your employees.
That's what I imagine as a sane industry,
due to generate sane revenues for a long time.
The more your customers understand that, the more you explain it to them,
the more they come to you rather than to proprietary rivals.
That would be a good marketing plan towards general management:
not only are these technically SUPERIOR solutions
that work NOW for EFFECTIVE development COST,
but they are solutions that will last FOREVER,
and that even if the vendor's archives are nuked,
and all its developers poisoned by eating rotten meat at a company lunch.
Again, I may be wrong, but it sounds quite consistent to me,
and I'd like to be *proved* wrong if I am wrong
(together with all the many serious free software advocates I know).
Sorry for this long post.
I hope we're soon ended expliciting all our arguments,
so that, convinced or unconvinced, we may go back to work.
Best regards,
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
Because people confuse information and information-related services
(which include searching, creating, processing, transforming, selecting,
teaching, making available, guaranteeing, supporting, etc), they are afraid
that Free (libre) Information mean free (gratis) information-related services,
which would indeed kill the industry of said services. On the contrary,
Free Information would create a Free Market in these services, instead of
current monopolies, which means they will be available at a fair price,
so the result would be a flourishment of that industry! -- Far�
From: Erik Naggum
Subject: Re: A draft business plan for free software LISP vendors
Date:
Message-ID: <3129759496251093@naggum.no>
a business plan is something you can take to an investor (bank) and say
"this is how I think X amount of money can become Y amount of money with
Z number of people in T amount of time and you have X amount of money, I
know how to get Z number of people, so how about you and I make Z amount
of money?"
what you have posted, Francois-Rene Rideau, is basically on par with
going to an investor and saying "I am deeply convinced that it is in your
interest to give me X amount of money, so how about it?"
the more insane drivel I read from proponents of Free Software and Open
Source, the more convinced I am that this once noble movement will go
away and not even become a footnote in the history of mankind when their
real goal has been achieved: the destruction of Microsoft.
in my view, Microsoft has never been particularly relevant. they are
very good at defrauding people who don't know what to look for every time
they part with a small amount of money, but if I were to be fazed by such
people, I'd be seriously bothered by any and all politicians, commodity
advertising, televised propaganda, etc, and I'm not. I'm bothered by the
fact that stupid people don't spontaneously combust, which they should.
no, seriously, I'm fighting the view that Microsoft is relevant to anyone
and want people to look over yonder knoll when Bill Gates is in jail or
in a mental institution and none of the mindless droids in Redmond know
what to do with their lives when fraud is no longer a viable option.
Free Software is a protest movement. Open Source is a weapon. I can see
a significant constructive element to Free Software, but I can't see any
with Open Source. Linux is _not_ a success to be repeated, just like
Microsoft is the last of its kind. in both cases, however, men in suits
with their ties so tight blood supply to the brain is cut off believe
they know what caused these successes and attempt to emulate them through
some incidental quality that has nothing to do with the success. some
other fanatics also crawl out of the woodwork to predict doom and
disaster if everything doesn't follow the Grand Business Model de jour.
* Francois-Rene Rideau <····@ZhengHe.augustin.thierry>
| I would prefer to resume my work rather than post yet another article on
| the topic, but there are many misconceptions about free software that
| seem to creep in your posts, that I'd like to dispell, even though odds
| are low that will suffice to convince anyone.
some day, I hope you will start to listen to people who have worked with
Free Software for the better part of a decade and have wondered (1) why
people get much enthused but then leave disappointed and disgruntled, (2)
why free software programs gain a very high quality as long as the goal
is very clear, and (3) why it then goes on to accrete crappy features
nobody needs but are fun to add by the less competent people who are
unable to accept that an idea has fully matured. (watch GNU ls acquire
"human" sizes, for instance: multiples of 1000, instead of 1024.)
Free Software or Open Source is _not_ a panacea, nor a religion, and it
should be possible to argue against it without someone who is still wet
behind his ears coming out to "dispell misconceptions" because he fails
to understand what people are talking about.
as I have said previously, immaturity is a fact of life, which it is not
smart to deny or ignore, but which also should not be catered to. people
who think they are already mature _enough_ are unlikely to mature _more_,
but part of the process is to realize that some of one's core beliefs may
be wrong or have underlying goals that are reached only in part or not at
all, but which it does not make sense to pursue further.
unencumbered access to other people's intellectual property is one such
_immature_ goal. the same argument could be made for other property, yet
isn't, because the glaring insanity of such requests cannot be ignored.
the very first step on the way to convince anyone is to accept that they
may be right, and you have to figure out how to talk to them in terms
they can understand and relate to to make them change their ways. people
do whatever they do because it has worked better for them than the other
stuff they have tried, but at some point, they gave up looking for better
ways and were "satisfied". your second step on the way to convince
anyone of your own views is to make them _want_ to continue to look for a
better way and _maybe_ that is your way. if they don't want to continue
to look for a better way, they should be ignored completely as a waste of
space and human potential. since the third and following steps are by
now completely irrelevant to Francois-Rene Rideau, who has found the
solution to all the world's problems, I'll save myself the effort of
writing them down. this has gotten long enough already.
#:Erik
From: Fernando D. Mato Mira
Subject: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E39284.E7D332D7@iname.com>
This is a multi-part message in MIME format.
--------------00ED0B54FE2DF503DAE83F37
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> I have a sad story to tell (please anyone correct me if I'm wrong):
> satisfied customers of ILOG Talk have developed a lot of software for it,
> and contributed infrastructure back to ILOG, who incorporated it in
> the main source. All in all, it's been a happy story for 7 years.
> But one day, ILOG decided it was not making money in the LISP business,
> and announced Talk would no more be maintained. Good bye, bug fixes,
> good bye ports, good bye ILOG Talk.
>
> Remaining customers promptly decided to migrate
> all their development to C++, Java, Smalltalk, or whatever they could.
> All their code base was technically lost.
> Even though they could negociate the use of sources for Talk as customers,
> and even though their maintenance contract will last a few more years,
> they would have to do all maintenance in-house afterwards,
> and not be able to reuse the resulting code for other projects
> or share it with others. Economically, their code is DEAD,
> and it will soon be in every other meanings of the term.
>
I suddenly realized that the current model where when a company goes
bankrupt or decides to kill a product and the source is not released is WRONG.
Maybe if some people get bitten like this in the States or countries with similar
legal systems, they should file a class action lawsuit in the hope of establishing
a precedent so that things like that cannot happen anymore. Besides that, people
should start asking for such kind of thing when negotiating a purchase. Management
of the living company should not have much trouble giving in, as they are supposed
to be in "the company will live forever and our products will be a success". Saying
no
implies they are uncertain about their future and sends out a "you'd better look
somewhere else"
message.
--------------00ED0B54FE2DF503DAE83F37
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------00ED0B54FE2DF503DAE83F37--
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3129896583995790@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| I suddenly realized that the current model where when a company goes
| bankrupt or decides to kill a product and the source is not released is
| WRONG.
no, it isn't wrong. from a customer perspective, it may be undesirable,
the creator and owner of something has every right to what he sees fit,
and you have no business at all telling him or anyone else that what he's
doing is wrong. first, respect the inalienable right to property and the
fruits of one's labor. only _then_ can you suggest ways to _entice_ the
owner to do what you think would be desirable for _both_ parties.
as long as you guys who want something from others do not recognize that
you, as users, have _no_ right to demand aything from those who create
it, you will cause your own downfall as soon as you create something that
others might want. if you don't think that will ever happen, you _still_
have no right to demand anything at all of those who bring something into
existence. if you do, the next step is to _demand_ that those who can
bring something into existence do so under threat of various penalties.
having been on the receiving end of such demands, in my case from the
Norwegian government, which for a few years decided to tax me based on
what I should have been _able_ to earn, and therefore _probably_ earned
without reporting to them, so I should pay taxes on it, plus penalties
for lying to them, I am very strongly opposed to anyone who makes the
sort of claims you do. I consider the claims you make to be truly evil,
just like the Norwegian tax system is truly evil.
| Maybe if some people get bitten like this in the States or countries with
| similar legal systems, they should file a class action lawsuit in the
| hope of establishing a precedent so that things like that cannot happen
| anymore.
so you're seriously proposing to _sue_ people because they didn't want to
give you what you wanted from them? why would _anyone_ want to give the
slightest bit of evidence of what they were capable of under your system?
the only guarantee not to be sued by you would be if you didn't know what
people had that you could want. think about it.
I don't think you know bankruptcy law, which would not be particularly
surprising, since so few people care about the law. well, I do, so I
know that when a company goes into Chapter 11 (Reorganization), anyone
can basically come up and say "I'll help keep you alive if I get X, Y,
and Z if still can't make it", or you could even offer to buy X, Y, and Z
right there. if a company goes into Chapter 7 (Liquidation), you get to
offer a ridiculously low amount of money for something that turned out
not to sustain the creator. all that matters to the managers of the
bankruptcy is that they recover the outstanding debt. (this the best
approximation to garbage collection the business world knows about.)
so believe it or not, you _already_ have the opportunity to buy the
source code when a company folds, and the creditors are not even
_allowed_ to demand more for the company assets than to cover their debt,
because then the requirements of Chapter 7 bankruptcy proceedings have
been violated: upon opening Chapter 7 proceedings, the owners have _lost_
all rights to the assets, and the real owners are now the creditors.
should they come out with a _profit_, a lot of companies would have to
fight off Chapter 7 proceedings from greedy competitors, so it's illegal
to make a profit after Chapter 7, and a court will force the creditors to
go back to Chapter 11. when in Chapter 11, the company is deemed able to
continue operation provided that some of the debts are consolidated, and
that, too, includes _selling_ assets to various bidders. the managers of
the process, elected by the creditors, aim to "restart" the business and
to make more money than they would if they simply waited and liquidated
the assets.
I wish people would get more interested in _knowing_ the world they want
to change. I can't keep lecturing obnoxious morons forever just because
they have these wild-eyed desires that they think can be accomodated if
they start a revolution or something.
| Besides that, people should start asking for such kind of thing when
| negotiating a purchase. Management of the living company should not have
| much trouble giving in, as they are supposed to be in "the company will
| live forever and our products will be a success". Saying no implies they
| are uncertain about their future and sends out a "you'd better look
| somewhere else" message.
so if your employer asks you if you would like to donate your liver upon
your timely or untimely demise, you fully expect that if you decline,
your employer should consider your liver to be damaged goods and fire you
because you _might_ be an alcoholic? and you do not consider such a
request to be slightly suspicious, such as allowing your employer to
force you to leave your liver when you get fired? (insert Monty Python
sketch for best effect.)
here's a lithmus test on "good ideas": if it were applied to you, would
you still think it's a good idea? in other words: if you can't imagine
yourself as the vendor, maybe it's time to drop the good idea stuff, too?
#:Erik
From: Fernando D. Mato Mira
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E400F2.24D19A85@iname.com>
This is a multi-part message in MIME format.
--------------2D0D7824BDB06D2091FBAAF9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Erik Naggum wrote:
> * "Fernando D. Mato Mira" <········@iname.com>
> | I suddenly realized that the current model where when a company goes
> | bankrupt or decides to kill a product and the source is not released is
> | WRONG.
>
> no, it isn't wrong. from a customer perspective, it may be undesirable,
> the creator and owner of something has every right to what he sees fit,
I am just asking for a better WARRANTY.
> I don't think you know bankruptcy law, which would not be particularly
> surprising, since so few people care about the law. well, I do, so I
> know that when a company goes into Chapter 11 (Reorganization), anyone
I meant bankrupt as definitely dead. Not Chapter 11 (living dead). A
customerhas invested (in the broad sense of the word) in the company, so it
would be very honest
that he has some rights at liquidation time, including
1. That the liquidation process does not take too long to accomplish
2. That he can oppose (like in Switzerland any neighbour can start a procedure
against some
new construction) to selling of the technology to a particular party because
(for example):
- The party's interest is in burying the product
- The party plans on raising the maintenance fees by an order of magnitude
- You just don't want to have anything to do with the party.
> so if your employer asks you if you would like to donate your liver upon
> your timely or untimely demise, you fully expect that if you decline,
> your employer should consider your liver to be damaged goods and fire you
> because you _might_ be an alcoholic? and you do not consider such a
> request to be slightly suspicious, such as allowing your employer to
> force you to leave your liver when you get fired? (insert Monty Python
> sketch for best effect.)
You're getting into Naggum hyperbole here. My employer has nothing to do with
my liver.
However, it might be argued that they want a warrantly that I did not write
some undocumented,
unmaintainable code somewhere, asking for the brain cells in charge would not
be unreasonable.
But then I could say 'sorry, no waranty'. Just like they can.
But there's something different between the two: in one case you're talking
about a person's rights,
and in the other a corporation. They are different kind of entities for law,
fortunately, so I expect
a Constitution to forbid an employer to ask for my body parts, and the
non-existence of any laws
forbidding companies to give me such the kind of warranty I'd like. If I might
push it, some laws taking care of
points 1 and 2 above would not be bad, either.
--------------2D0D7824BDB06D2091FBAAF9
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------2D0D7824BDB06D2091FBAAF9--
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3129977246072659@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| I meant bankrupt as definitely dead. Not Chapter 11 (living dead). A
| customerhas invested (in the broad sense of the word) in the company, so
| it would be very honest that he has some rights at liquidation time,
| including
what? a customer of a product has _invested_ in the company?! this is
too fucking nuts to bother discussing.
| My employer has nothing to do with my liver.
so why doesn't the customer of your services invest in you?
#:Erik
From: Fernando D. Mato Mira
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E53662.FA3A81F1@iname.com>
Erik Naggum wrote:
> * "Fernando D. Mato Mira" <········@iname.com>
> | I meant bankrupt as definitely dead. Not Chapter 11 (living dead). A
> | customerhas invested (in the broad sense of the word) in the company, so
> | it would be very honest that he has some rights at liquidation time,
> | including
>
> what? a customer of a product has _invested_ in the company?! this is
> too fucking nuts to bother discussing.
Why do I bother inserting parenthesized anti-Naggum countermeasures?
> | My employer has nothing to do with my liver.
>
> so why doesn't the customer of your services invest in you?
>
They have invested their trust the day they hired me. Different kind
of `investment' [let's see if quotes work] give you moral entitlement to
different things
(Yes , I said _moral_. The raw material behind legal systems).
Have you ever heard the phrase `The Customer is King"? You can have all the
INVESTMENT (money for equity, that kind of thing, got it?) you want, but w/o
customers, the company won't be around for long. What's the first thing VCs
ask? "Who are your customers?" Tech/originality is not the main issue.
So it's not only `no capital -> no company' and `no customers -> no company'
but even `no customers -> no capital -> no company'
Well enough. My first sentence should have sufficed, but maybe it's time
_you_ get The Treatment (you've got way too violent in the time I've been
out. I suggest you spend your government/media-induced hostility elsewhere,
say comp.lang.c++, or even better, some bad people in The Real World (TM)).
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3130012786265490@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| Why do I bother inserting parenthesized anti-Naggum countermeasures?
because you are too stupid to stop thinking in terms of "anti-Naggum".
also, because you think you'll get away with idiocy and lunacy if you can
be sufficiently vague. that may work with others of your kind, but it
doesn't work with me. I don't allow you to misuse a term like "invest"
and then treat it as if it wasn't misused. this is called "equivocation"
and you may succeed in leading others down the garden path, but don't be
such an idiot that you get mad when somebody doesn't accept your tricks.
if you have a case, you can make it without equivocation. show us.
#:Erik
From: Fernando D. Mato Mira
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E63962.97AA58DA@iname.com>
Erik Naggum wrote:
> * "Fernando D. Mato Mira" <········@iname.com>
> | Why do I bother inserting parenthesized anti-Naggum countermeasures?
>
> because you are too stupid to stop thinking in terms of "anti-Naggum".
>
I never needed to think `anti-Haggum' before. I guess that either:
a. I got stupid.
b. You got `wire disease'.
c. I never exchanged opininions with you during winter before.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Hartmann Schaffer
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <f1FF2.12281$134.119595@tor-nn1.netcom.ca>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * "Fernando D. Mato Mira" <········@iname.com>
>| I meant bankrupt as definitely dead. Not Chapter 11 (living dead). A
>| customerhas invested (in the broad sense of the word) in the company, so
>| it would be very honest that he has some rights at liquidation time,
>| including
>
> what? a customer of a product has _invested_ in the company?! this is
> too fucking nuts to bother discussing.
Bad wording. The customer certainly has invested in whatever products he
bought from the company. The attitude that has been expressed in this
thread (bad luck if you are so stupid to buy from a company that went
under) certainly helps to encourage th buy-microsoft mindset.
Hartmann Schaffer
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3130136242952298@naggum.no>
* ········@netcom.ca (Hartmann Schaffer)
| Bad wording. The customer certainly has invested in whatever products he
| bought from the company.
no, that's something entirely different, and if you say that, you can't
leap to the conclusion that the customer has rights at the same level as
the real investors in a liquidation or bankruptcy.
| The attitude that has been expressed in this thread (bad luck if you are
| so stupid to buy from a company that went under) certainly helps to
| encourage th buy-microsoft mindset.
perhaps it encourages you that way, but I think you'd say that no matter
what what the attitude was.
#:Erik
From: Hartmann Schaffer
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <gy2G2.12594$134.122971@tor-nn1.netcom.ca>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * ········@netcom.ca (Hartmann Schaffer)
> ...
>| The attitude that has been expressed in this thread (bad luck if you are
>| so stupid to buy from a company that went under) certainly helps to
>| encourage th buy-microsoft mindset.
>
> perhaps it encourages you that way, but I think you'd say that no matter
> what what the attitude was.
Are you always jumping this fast to idiotic conclusions?
Hartmann Schaffer
········@netcom.ca
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3130227394253394@naggum.no>
* ········@netcom.ca (Hartmann Schaffer)
| The attitude that has been expressed in this thread (bad luck if you are
| so stupid to buy from a company that went under) certainly helps to
| encourage th buy-microsoft mindset.
* Erik Naggum
| perhaps it encourages you that way, but I think you'd say that no matter
| what what the attitude was.
* ··@inferno.nirvananet (Hartmann Schaffer)
| Are you always jumping this fast to idiotic conclusions?
so I hit a hot button with you. big deal.
#:Erik
From: Brent A Ellingson
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <7c8ppb$n5g$1@node2.nodak.edu>
Hartmann Schaffer (········@netcom.ca) wrote:
: In article <················@naggum.no>,
: Erik Naggum <····@naggum.no> writes:
: > * "Fernando D. Mato Mira" <········@iname.com>
: >| I meant bankrupt as definitely dead. Not Chapter 11 (living dead). A
: >| customerhas invested (in the broad sense of the word) in the company, so
: >| it would be very honest that he has some rights at liquidation time,
: >| including
: >
: > what? a customer of a product has _invested_ in the company?! this is
: > too fucking nuts to bother discussing.
: Bad wording. The customer certainly has invested in whatever products he
: bought from the company. The attitude that has been expressed in this
: thread (bad luck if you are so stupid to buy from a company that went
: under) certainly helps to encourage the buy-microsoft mindset.
I'm still in school -- I know little about the real world. Do
managers often inform themselves on the goals of a purchase,
examine the avialable options, determine each vendors ability to
fulfill those goals, and then buy exactly the opposite of what
they wanted?
If a customer truly believes it is investing in the products it
buys from a vendor, then the customer should make every effort to
treat a purchase as an investment. If a piece of software is
important for how you do business, then everyone -- the buyer and
the seller -- should be treating this software as important for your
business. If continued support for that software from the vendor is
important, then forming an agreeable partnership with the vendor
to continue supporting that software is imperative. In particular,
you should be very, very disatisfied if the only contract you can
extract from any seller beforehand is an envelope that states "by
opening this envelope, you have agreed to the license printed
here-on..."
The point is not "bad luck if you are so stupid to buy from a
company that went under". Instead, it is "shame on you if you
should be forming a long term partnership with a vendor, but
instead you are stupid enough to be satisfied purchasing important
business tools from vendors with `licenses' that treat your
purchase as a nuisance to the seller."
Everyone will agree that it is bad luck if you form a partnership
with a vendor which later finds itself unable to support that
partnership. It is foolishness if you try to form a partnership
with a vendor which has clearly demonstrated it has no interest in
supporting any kind of partnership. There should be little doubt
that this attitude helps to discourage the buy-Microsoft mindset.
--
Brent Ellingson (········@badlands.NoDak.edu)
"It is amazing how complete is the delusion that beauty is goodness."
-- Leo Tolstoy
From: Craig Brozefsky
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <87n21nsuvd.fsf@piracy.red-bean.com>
Erik Naggum <····@naggum.no> writes:
> no, it isn't wrong. from a customer perspective, it may be undesirable,
> the creator and owner of something has every right to what he sees fit,
> and you have no business at all telling him or anyone else that what he's
> doing is wrong. first, respect the inalienable right to property and the
> fruits of one's labor. only _then_ can you suggest ways to _entice_ the
> owner to do what you think would be desirable for _both_ parties.
The inalienable right to property... That means, do not bother
responding to Erik unless you are ready to get an earful from a
tireless poster who will not rest until everyone respects the
ludicrous libertarian credo of inalienable property rights.
> here's a lithmus test on "good ideas": if it were applied to you, would
> you still think it's a good idea? in other words: if you can't imagine
> yourself as the vendor, maybe it's time to drop the good idea stuff, too?
Yah, well, most people on the planet are able to distinguish between
their liver, and a peice of software.
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
From: Christopher Browne
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <tE_E2.20239$YV6.10375@news2.giganews.com>
On Mon, 08 Mar 1999 18:03:35 GMT, Craig Brozefsky <·····@red-bean.com> wrote:
>Erik Naggum <····@naggum.no> writes:
>
>> no, it isn't wrong. from a customer perspective, it may be undesirable,
>> the creator and owner of something has every right to what he sees fit,
>> and you have no business at all telling him or anyone else that what he's
>> doing is wrong. first, respect the inalienable right to property and the
>> fruits of one's labor. only _then_ can you suggest ways to _entice_ the
>> owner to do what you think would be desirable for _both_ parties.
>
>The inalienable right to property... That means, do not bother
>responding to Erik unless you are ready to get an earful from a
>tireless poster who will not rest until everyone respects the
>ludicrous libertarian credo of inalienable property rights.
From the customer's perspective, you have no business at all telling him
or anyone else that what they're asking for is wrong.
The customer has the unalienable right to property and to the fruits of
their labours. If someone tries to deny this via going out of business
or otherwise trying to stop supporting a piece of software, this takes
away from the customer the use of software that they have paid good
money for.
Open Source *does* mean never having to worry about a system becoming
unmaintainable simply because a company goes out of business. There may
be other reasons for software becoming diminishingly maintainable; if
the source code is at least available, this makes the task less
difficult...
--
"Just because the code is intended to cause flaming death is no reason
to get sloppy and leave off the casts." - Tim Smith, regarding sample
(F0 0F C7 C8) Pentium Death code on comp.os.linux.advocacy
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Frank A. Adrian
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <7c3oqc$c1h$1@client2.news.psi.net>
Christopher Browne wrote in message ...
>On Mon, 08 Mar 1999 18:03:35 GMT, Craig Brozefsky <·····@red-bean.com>
wrote:
>>The inalienable right to property... That means, do not bother
>>responding to Erik unless you are ready to get an earful from a
>>tireless poster who will not rest until everyone respects the
>>ludicrous libertarian credo of inalienable property rights.
>
>From the customer's perspective, you have no business at all telling him
>or anyone else that what they're asking for is wrong.
This is true. They may want to say, "No way in hell am I going to sell you
that," to the request, but they shouldn't say that you have no right to ask.
>The customer has the unalienable right to property and to the fruits of
>their labours. If someone tries to deny this via going out of business
>or otherwise trying to stop supporting a piece of software, this takes
>away from the customer the use of software that they have paid good
>money for.
You should not use the software if you are so concerned about having the
source. You can negotiate the source rights or use other software instead
or (GASP) write your own. Plus - youc an still "use" the software you have
on the systems for which it is licensed. If the hardware goes obsolete,
well, YOU've made a mistake on assuming stability of the software and
hardware market.
Many software manufacturers will also sell you "subscription" based software
where they contract for periodic upgrades of the software for a specific
period. If you are stupid enough to depend on upgrades by using a system
for which you have no guarantee of upgrades, I'd expect the problem is with
YOUR sense of risk.
Not that I WANT to defend the libertarian PoV. It's wrongheaded in many
ways. But your arguments are fallacious.
>Open Source *does* mean never having to worry about a system becoming
>unmaintainable simply because a company goes out of business. There may
>be other reasons for software becoming diminishingly maintainable; if
>the source code is at least available, this makes the task less
>difficult...
And those who wish to work under this model are allowed to. You can get
their software and use it. If you can't get the software that you want to
use on the terms you want, write it yourself, distribute it as freeware, and
put the other guy out of business.
From: Christopher Browne
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <mluF2.24841$YV6.12402@news2.giganews.com>
On Tue, 9 Mar 1999 10:23:15 -0800, Frank A. Adrian
<············@firstdatabank.com> wrote:
>Christopher Browne wrote in message ...
>>On Mon, 08 Mar 1999 18:03:35 GMT, Craig Brozefsky <·····@red-bean.com>
>wrote:
>>>The inalienable right to property... That means, do not bother
>>>responding to Erik unless you are ready to get an earful from a
>>>tireless poster who will not rest until everyone respects the
>>>ludicrous libertarian credo of inalienable property rights.
>>
>>From the customer's perspective, you have no business at all telling him
>>or anyone else that what they're asking for is wrong.
>
>This is true. They may want to say, "No way in hell am I going to sell you
>that," to the request, but they shouldn't say that you have no right to ask.
>
>>The customer has the unalienable right to property and to the fruits of
>>their labours. If someone tries to deny this via going out of business
>>or otherwise trying to stop supporting a piece of software, this takes
>>away from the customer the use of software that they have paid good
>>money for.
>
>You should not use the software if you are so concerned about having the
>source. You can negotiate the source rights or use other software instead
>or (GASP) write your own. Plus - youc an still "use" the software you have
>on the systems for which it is licensed. If the hardware goes obsolete,
>well, YOU've made a mistake on assuming stability of the software and
>hardware market.
>
>Many software manufacturers will also sell you "subscription" based software
>where they contract for periodic upgrades of the software for a specific
>period. If you are stupid enough to depend on upgrades by using a system
>for which you have no guarantee of upgrades, I'd expect the problem is with
>YOUR sense of risk.
>
>Not that I WANT to defend the libertarian PoV. It's wrongheaded in many
>ways. But your arguments are fallacious.
Equally as fallacious as they were when the wording was slightly
different, I'd suggest...
I don't disagree that what's above is wrong; perhaps I should have
pseudo-tagged it using <fallacious-analogy pro=customer>
</fallacious-analogy> to make it clearer...
>>Open Source *does* mean never having to worry about a system becoming
>>unmaintainable simply because a company goes out of business. There may
>>be other reasons for software becoming diminishingly maintainable; if
>>the source code is at least available, this makes the task less
>>difficult...
>
>And those who wish to work under this model are allowed to. You can get
>their software and use it. If you can't get the software that you want to
>use on the terms you want, write it yourself, distribute it as freeware, and
>put the other guy out of business.
Perhaps surprisingly, despite the widespread availability and high
levels of adoption of Apache, Netscape is still making money off of
sales of Netscape Commerce Server.
In the right sectors, the world is large enough to admit multiple
competitors...
--
Linux is obsolete
(Andrew Tanenbaum)
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3130013362309596@naggum.no>
* Craig Brozefsky <·····@red-bean.com>
| The inalienable right to property... That means, do not bother
| responding to Erik unless you are ready to get an earful from a tireless
| poster who will not rest until everyone respects the ludicrous
| libertarian credo of inalienable property rights.
it doesn't mean that at all, of course, but I'm actually happy we know
that your brain short-circuits whenever you have to respect ownership.
also, I'm always curious about one thing: when people attack this line,
they _always_ forget half of it: you forget "the fruits of one's labor",
while others forget "property". the fruits of one's labor argument is
not something you hear from libertarian quarters. it might be taken to
be purebred communism by the same kind of morons who take the other line
for libertarian, but just with a different kind of bad childhood. it's
mighty fun to watch people latch onto only one of these -- it offers very
valuable insight into how people can't read stuff that doesn't already
match their _very_ prejudicious, one-dimensional concepts.
if you look very carefully, 90% of my articles contain traps for morons,
stuff that only deranged or retarded people latch onto and get upset
about, and I gotta admit that I get a kick out of learning such things.
the best way to make somebody tell you his secrets is to offend those
secrets. most people aren't smart enough to shut up at that point.
| Yah, well, most people on the planet are able to distinguish between
| their liver, and a peice of software.
sure, but I'm adressing the rest, which are smart enough to "get"
analogies and not get hung up in particulars.
thank you for your interjection, Craigh. go play on the highway, now.
#:Erik
From: Craig Brozefsky
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <877lsqqgsd.fsf@piracy.red-bean.com>
Erik Naggum <····@naggum.no> writes:
> * Craig Brozefsky <·····@red-bean.com>
> | The inalienable right to property... That means, do not bother
> | responding to Erik unless you are ready to get an earful from a tireless
> | poster who will not rest until everyone respects the ludicrous
> | libertarian credo of inalienable property rights.
>
> it doesn't mean that at all, of course, but I'm actually happy we know
> that your brain short-circuits whenever you have to respect ownership.
I have no problem with ownership, Erik.
Inalienable \In*al"ien*a*ble\, a. [Pref. in- not + alienable:
cf. F. inali['e]nable.]
Incapable of being alienated, surrendered, or transferred to
another; not alienable; as, in inalienable birthright.
I just have a problem with the concept of "inalienable" rights being
used as the basis for intellectual property. Not that I think that
there are not good arguments for inalienable rights, even with regards
to posessions. But note that inalienable means they cannot be
surrendered, or transfered. That makes it difficult to use them as
the basis for intellectual property as it exists in the marketplace;
patents, copyrights and licensing deals. IP is all about transfer,
and exchange, so the concept of "inalienable" property rights is just
ludicrous. The phrase "inalienable" as you use it makes no sense and
is most likely just a semiotic place marker for "you are not allowed
to disagree".
Talk about triggers for idiots, I've already been called a communist
twice for that post, as if anyone who disagrees with *inalienable*
property rights is a commie bastard with no respect for possessions or
the fruits of one's labor.
But anyways who am I to correct you Erik, I disagree you with so I'm
obviously already a moron in your book. Just as the previous poster
is obviously an imbecile because they posted something which triggered
yet another of your tirades. So go ahead and flip the bozo bit on me
and anyone else who disagrees with you, we won't mind.
> | Yah, well, most people on the planet are able to distinguish between
> | their liver, and a peice of software.
>
> sure, but I'm adressing the rest, which are smart enough to "get"
> analogies and not get hung up in particulars.
The devil is in the details.
Back to Pop-11 hacking...
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
From: Erik Naggum
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <3130020854936769@naggum.no>
* Craig Brozefsky <·····@red-bean.com>
| But anyways who am I to correct you Erik, I disagree you with so I'm
| obviously already a moron in your book.
disagreement has nothing to do with it. concluding that disagreement is
the key is _probably_ cause for deciding you _are_ a moron, however.
it's fascinating to watch people believe in agreement. some people truly
respect only those who agree with them on issues, and worse yet, their
agreement is usually measured in words, not in meaning or in principles.
for such limited people, respect for methodology and due process is much
too complex to handle. like lawyers who defend the guilty according to a
complex set of rules to ensure they get a fair trial, I also get a lot of
_stupid_ accusations based on some trivial and superficial issue compared
to the core principles of due process and sound methodology. probable
morons like Craig Brozefsky, who have to trivialize this into a simple,
one-dimensional agree-disagree axis are probably also completely unable
to appreciate that an argument whose underlying methodology is broken is
neither right nor wrong -- it's just noise, not even worthy of arguing,
but it _is_ important to point out that it's so much noise so others
don't go the route of actually trying to argue the points that appear to
be there if you completely ignore the genesis of the argument.
what you see from me is disrespect for people who are unable to deal with
information contrary to their existing beliefs, no matter whether I agree
or disagree with it, particularly if they reject information that has
been obtained with the _same_ methodology used to obtain the information
they "agree" with. I also have a very low tolerance for people who think
that there is a difference in _who_ does something, particularly if it
manifests itself in the belief that there should be one law for them and
one law for everybody else. or worse, one law for those they agree with,
and one law for those they disagree with, which is, amazingly, quite
common among the _really_ retarded people who post their stupid opinions
on USENET, and, incidentally, who are often "activists" for some stupid
cause or another and who usually know nothing of importance about their
"enemy" save what their propaganda ministers have told them. I have zero
respect for such people and I think it is very valuable to smoke them out.
so, yeah, Craig, you are probably a moron, but you would be whether you
agreed with me or not, and I would probably feel impelled to tell you
exactly the same thing if you did voice agreement, because it would hurt
my case to have such people on my "side". more precisely, the less smart
the people who favor your cause is, the more you have to work behind the
scenes, and I don't like to do that. by exposing the morons who favor
some other cause, that people who share that cause have to regroup and
find ways to express themselves better, and differently. this happens
surprisingly often: whenever you see a bunch of lunatics take to the
streets to fight some evil or another symbolically, the people who
actually do something about it keep a clear distance to the "activists"
and sometimes have to antagonize them with "compromises" to make sure
that they are not seen as representatives of the activists, because that
would cause them to lose credibility in general and be seen as equally
shallow and one-dimensional as the activists are, qua activists for a
single cause. note, however, that only the representatives of activists
are assumed to have one-dimensional views.
it actually amazes me how little some people understand of these things,
while I'm sometimes amazed by how much others do grasp of what's going on
and what I'm actually doing. this has led me to believe that if I can
find one person every now and then who gets the point, it's worth all the
stupid abuse from morons who don't get it, but the Craig Brozefskies of
the world are _very_ tiring to deal with, which is why I'm trying to make
this a little more explicit than I used to.
#:Erik
Craig Brozefsky wrote in message <··············@piracy.red-bean.com>...
>Erik Naggum <····@naggum.no> writes:
>
>> * Craig Brozefsky <·····@red-bean.com>
>> | The inalienable right to property... That means, do not bother
>> | responding to Erik unless you are ready to get an earful from a
tireless
>> | poster who will not rest until everyone respects the ludicrous
>> | libertarian credo of inalienable property rights.
>>
>> it doesn't mean that at all, of course, but I'm actually happy we
know
>> that your brain short-circuits whenever you have to respect
ownership.
>
>I have no problem with ownership, Erik.
>
>Inalienable \In*al"ien*a*ble\, a. [Pref. in- not + alienable:
> cf. F. inali['e]nable.]
> Incapable of being alienated, surrendered, or transferred to
> another; not alienable; as, in inalienable birthright.
>
>I just have a problem with the concept of "inalienable" rights being
>used as the basis for intellectual property. Not that I think that
>there are not good arguments for inalienable rights, even with regards
>to posessions. But note that inalienable means they cannot be
>surrendered, or transfered. That makes it difficult to use them as
>the basis for intellectual property as it exists in the marketplace;
>patents, copyrights and licensing deals. IP is all about transfer,
>and exchange, so the concept of "inalienable" property rights is just
>ludicrous. The phrase "inalienable" as you use it makes no sense and
>is most likely just a semiotic place marker for "you are not allowed
>to disagree".
>...
It is obvious that there is an enormous gap between you two in the
common knowledge and/or common purpose required for mutual
understanding. Those who are even vaguely familiar with the United
States' Declaration of Independence[1] recognized Erik's use of the term
'inalienable'[2] in connection with 'rights'.
Craig is clearly being obtuse by claiming to be uncomprehending of the
fact that Erik's assertion was that one has an inalienable right to
decide for themselves the disposition of their own intellectual
property. I suspect Craig spent too much time listening to Microsoft
witnesses get examined by the DOJ. Yet here I am lured into rebutting
his straw man which clearly indicates I am not making good use of my
time...
jim
[1] <http://lcweb2.loc.gov/const/declar.html>
[2] Although the Declaration used the term 'unalienable', it is a
synonym of 'inalienable' which makes it easy to see the relationship.
From: Craig Brozefsky
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <87bthz1nmm.fsf@piracy.red-bean.com>
"Jim White" <···@pagesmiths.com> writes:
> It is obvious that there is an enormous gap between you two in the
> common knowledge and/or common purpose required for mutual
> understanding. Those who are even vaguely familiar with the United
> States' Declaration of Independence[1] recognized Erik's use of the term
> 'inalienable'[2] in connection with 'rights'.
Oops, I didn't associate his usage with the US DoI cause he isn't from
the U.S. Not that I thought he would be unfamiliar with it, just that
it didn't occur to me. I sorta used the definition I knew from
discussions of human rights, and the dictionary.
> Craig is clearly being obtuse by claiming to be uncomprehending of the
> fact that Erik's assertion was that one has an inalienable right to
> decide for themselves the disposition of their own intellectual
> property. I suspect Craig spent too much time listening to Microsoft
> witnesses get examined by the DOJ. Yet here I am lured into rebutting
> his straw man which clearly indicates I am not making good use of my
> time...
And regardless of the wether his statement was ludicrous or not,
perhaps I should have not cluttered up c.l.l without yet more
discussion of property and the like.
Nazi Nazi Nazi -- there, the thread is dead.
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
From: Kent M Pitman
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <sfw1zizlfo2.fsf@world.std.com>
Erik Naggum <····@naggum.no> writes:
> so you're seriously proposing to _sue_ people because they didn't want to
> give you what you wanted from them? why would _anyone_ want to give the
> slightest bit of evidence of what they were capable of under your system?
This is probably just a disconnect between US and Norwegian law, Erik.
In the US, we are encouraged to sue people for any reason any time we
feel like they have something we want. I often have to sue someone
just to get attention at a fast-food place. It's a way of life for us
that is often not appreciated by foreigners, perhaps because they're
not as facile with the required paperwork. It's fun once you get used
to it, though... and it's ESPECIALLY fun to do meta. For example,
suing people who are ahead of you in the line to sue people...
--Kent
p.s. people don't mind telling you what they're capable of under this system
because they can get sued for not providing it whether or not they were
capable... telling you doesn't increase their liability.
;-) just trying
to keep the
conversation
light...
From: Ian Wild
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E4DE8D.58E6DE40@cfmu.eurocontrol.be>
Kent M Pitman wrote:
>
> In the US, we are encouraged to sue people for any reason any time we
> feel like they have something we want.
And the "liver clause" is a pretty standard part of
employment contracts here in the EU.
From: Tim Bradshaw
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <nkju2vwj5sv.fsf@tfeb.org>
"Fernando D. Mato Mira" <········@iname.com> writes:
> I suddenly realized that the current model where when a company goes
> bankrupt or decides to kill a product and the source is not released
> is WRONG.
It's not wrong of course, it's just one way of doing things. The
classic solution is for the source to be put in escrow, which
effectively means that if the company goes under, or something
happens, the source gets released to the client. Large companies
dealing with small ones often seem to insist on this.
--tim
From: Tim Bradshaw
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <nkjr9qzkjh1.fsf@tfeb.org>
Tim Bradshaw <···@tfeb.org> writes:
> It's not wrong of course, it's just one way of doing things. The
> classic solution is for the source to be put in escrow, which
> effectively means that if the company goes under, or something
> happens, the source gets released to the client. Large companies
> dealing with small ones often seem to insist on this.
But I hit the send key to early.
What I should have added was that putting stuff into escrow may add a
burden to small companies which they may not be able to afford. It's
more than just putting dunp tapes in a safe somewhere, because it
requires you to factor out the stuff that should be in escrow from
that which shouldn't be, and that's all work. So a client should
expect to pay extra for this.
--tim
From: Fernando D. Mato Mira
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <36E40890.EBE1A5D0@iname.com>
This is a multi-part message in MIME format.
--------------02E0757D602031A6BAF7B11E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tim Bradshaw wrote:
> What I should have added was that putting stuff into escrow may add a
> burden to small companies which they may not be able to afford. It's
> more than just putting dunp tapes in a safe somewhere, because it
> requires you to factor out the stuff that should be in escrow from
> that which shouldn't be, and that's all work. So a client should
> expect to pay extra for this.
I think that's fair. What is not is that a shoestring operation which
shelled
out 5K$, invested time and effort, and put their trust in a good
alternative offering
(by a company in good shape!) is suddenly informed that they have pulled
the plug,
and _with luck_ they are offered the sources for, say, 10K$ (when even
coming up with 2K$ is a big deal).
--------------02E0757D602031A6BAF7B11E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------02E0757D602031A6BAF7B11E--
From: Frank A. Adrian
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <7c0v33$ltq$1@client2.news.psi.net>
Fernando D. Mato Mira wrote in message <·················@iname.com>...
>I suddenly realized that the current model where when a company goes
>bankrupt or decides to kill a product and the source is not released is
WRONG.
>Maybe if some people get bitten like this in the States or countries with
similar
>legal systems, they should file a class action lawsuit in the hope of
establishing
>a precedent so that things like that cannot happen anymore. Besides that,
people
>should start asking for such kind of thing when negotiating a purchase.
Management
>of the living company should not have much trouble giving in, as they are
supposed
>to be in "the company will live forever and our products will be a
success". Saying
>no
>implies they are uncertain about their future and sends out a "you'd better
look
>somewhere else"
>message.
In general, if you are worried about this sort of thing, you require source
code escrow in your contract for the software. Of course, this only applies
to companies with which you write an actual contract (i.e., shrink-wrapped
software you use will usually not have such). Also note that the
willingness for the software supplier to sign such a contract with you will
vary in proportion to the amount of the sale you're willing to give him...
From: Harley Davis
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <7c1fsc$4tg$1@ffx2nh3.news.uu.net>
>> I have a sad story to tell (please anyone correct me if I'm wrong):
>> satisfied customers of ILOG Talk have developed a lot of software for it,
>> and contributed infrastructure back to ILOG, who incorporated it in
>> the main source. All in all, it's been a happy story for 7 years.
>> But one day, ILOG decided it was not making money in the LISP business,
>> and announced Talk would no more be maintained. Good bye, bug fixes,
>> good bye ports, good bye ILOG Talk.
>>
>I suddenly realized that the current model where when a company goes
>bankrupt or decides to kill a product and the source is not released is
WRONG.
>Maybe if some people get bitten like this in the States or countries with
similar
>legal systems, they should file a class action lawsuit in the hope of
establishing
>a precedent so that things like that cannot happen anymore. Besides that,
people
>should start asking for such kind of thing when negotiating a purchase.
Management
>of the living company should not have much trouble giving in, as they are
supposed
>to be in "the company will live forever and our products will be a
success". Saying
>no implies they are uncertain about their future and sends out a "you'd
better look
>somewhere else" message.
Although Erik already replied concerning the moral aspects of this idea, I
do want to correct any possible false impression that ILOG does not offer
source code escrow services to its clients. It does, and many companies
take advantage of this offer.
It was indeed too bad that we had to cancel the Talk project as I still
believe it offered several advanced and useful features that Lisp systems
still do not have, but we did try to do all we could to ease the pain of
customers, including providing continued maintenance well beyond the end of
the product's life and including continuing to provide a free Linux version
of the product. It might have been a good idea to provide the source code
as well, but upper management decided against it to keep the IP within ILOG
in case of future need.
Yours,
-- Harley
From: Hartmann Schaffer
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <U5%E2.11797$134.114766@tor-nn1.netcom.ca>
In article <············@ffx2nh3.news.uu.net>,
"Harley Davis" <··············@spamless_ilog.com> writes:
>>> ...
> It was indeed too bad that we had to cancel the Talk project as I still
> believe it offered several advanced and useful features that Lisp systems
> still do not have, but we did try to do all we could to ease the pain of
> customers, including providing continued maintenance well beyond the end of
> the product's life and including continuing to provide a free Linux version
> of the product. It might have been a good idea to provide the source code
> as well, but upper management decided against it to keep the IP within ILOG
> in case of future need.
Aren't there licenses thast let you release source code and still retain
the IP rights?
> Yours,
>
> -- Harley
>
>
From: Kent M Pitman
Subject: Re: Dead software (was: A draft business plan for free software LISP vendors)
Date:
Message-ID: <sfwhfrvxtpl.fsf@world.std.com>
··@inferno.nirvananet (Hartmann Schaffer) writes:
> Aren't there licenses thast let you release source code and still retain
> the IP rights?
Certainly. Contract law permits this. Two people can basically agree
to do anything [legal] between the two of them and make it binding.
Of course, if one violates the contract and tells others, getting the
genie back in the bottle is tricky. I think this is what Trade Secret
law is about, although I confess I've not run across a formal explanation
of trade secrets in my informal study of the law, so I can't tell you
the mechanics of it.
From: Fernando D. Mato Mira
Subject: Free Talk! (was: Dead software (was: A draft business plan for free software LISP vendors))
Date:
Message-ID: <36E50973.B606F01D@iname.com>
Harley Davis wrote:
> Although Erik already replied concerning the moral aspects of this idea, I
> do want to correct any possible false impression that ILOG does not offer
> source code escrow services to its clients. It does, and many companies
> take advantage of this offer.
We didn't know about all this stuff. I guess we were still too inexperienced.
> It was indeed too bad that we had to cancel the Talk project as I still
> believe it offered several advanced and useful features that Lisp systems
> still do not have, but we did try to do all we could to ease the pain of
> customers, including providing continued maintenance well beyond the end of
> the product's life and including continuing to provide a free Linux version
> of the product. It might have been a good idea to provide the source code
> as well, but upper management decided against it to keep the IP within ILOG
> in case of future need.
>
Yes. ILOG was honest when they cancelled Talk. However, I think
that even if you got a source license for free that might not help you really
(imagine if the thing is like the CMUCL compiler, what newcomer can fully
understand that?, and then, if you're a single developer, that will suck the
time
and money for your _application_).
I think that if the software is not sold so some company that actively develops
it (just `maintenance' was not enough for us in the case of Talk, e.g. while
negotiating
the purchase we got a verbal commitment that thread friendliness would be
improved),
the only way for many customers to be able to continue using the thing
is for the software to be released under some Open Source license that attracts
developers.
I think that in these days of slashdot effervescence, ILOG management should
consider freeing Talk. You'd be buying a lot of ILOG awareness in a heavily
C(++) oriented developer community (your core business), good PR with the
Open Source/Linux masses, good PR with lispers (many of them now doing C++!),
as well as probably making many in the Talk ex-teamsters glad to see the fruit
of their hard work alive.
Of course, you might fear that some of your employees would leave to become
full-time ILOG maintainers, but maybe you can arrange that internally.
Regarding myself, well, we moved from ILOG to MzScheme a long time ago,
and VRAI is is suspended animation until VC is found, so it's not like I _need_
this to happen (although I might consider switching back if the time comes).
It would just be a Good Thing.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
FR> Francois-Rene Rideau <····@tunes.org>
EN> Erik Naggum <····@naggum.no>
Dear Erik,
EN> depression is all about focusing on the negative things you observe,
Well, I can see *lots* of positive things around me,
and particularly things happening in the software industry.
I regret to say none of these positive things are related LISP,
whereas I have see lots of distress about people having to not use LISP.
Again, it's only my own limited experience (although I've been in contact
with developers from a variety of different backgrounds,
it's still a limited experience).
As for focusing on the negative things people observe, it seems that
you have a talent for doing just that on comp.lang.lisp posts:
in your replies, you tend to inflate the (actual) defects
of other people's postings, and ignore their positive content.
Of course, this all may have to do with your only replying to what you
want to correct, and not with what you agree with :)
Now, the same phenomenon is perhaps present in most usenetters.
FR> [...]
EN> I'll take that as a compliment,
It is. And it isn't meant to bribe your @{%[#! opinion.
EN> but I think you exaggerate my abilities
It's not about anyone's unique outstanding abilities,
but I believe that, to simplify,
there are combinations of various positive factors
independently developed in everyone;
hence the notion of a normal bell-curve distribution of people
with more or less positive combinations of factors.
I otherwise agree with most of what you say
and welcome your advice about maturing,
but I don't feel that my fundamental arguments
are contradicted by your post.
EN> [about Open Source vs Free Software]
Open Source(TM) is but Free Software in a business suit;
it may use a different language from a different point of view,
but despite the different form evaluated from within a different package,
it has the same semantics (well, as far as I and many understand it).
EN> if you can't make [LISP vendors] see things your way,
EN> buy them up with your own money and make them
EN> do what you think they should.
Well, I do intend to build a free software reflective LISP operating system
(CommonLISP or not), allowing for orthogonally persistent distributed
programming, and make money out of *services around it*,
as soon as I finish my PhD. If would sure be glad to raise capital
from LISP vendors, since it would give me the opportunity of working
with elite programmers, but I'm pretty sure I'll find capital and programmers
somewhere else if they are not convinced.
EN> here's a scenario that you should consider: remove intellectual property
EN> from broadcast sports shows. explain how it does not kill the sports
EN> industry.
Oh, it may kill the sports industry *as it is*,
but will greatly benefit a reorganized sports industry.
Instead of a corrupted industry where plays
a little elite of players on steroids,
it would be a sane industry where many people earn honest money
by having more population do sport instead of watching it on TV,
so that sport becomes a lively activity as it should have always been.
And I'm convinced that if you wait 20 years,
you'll see that the *sports* industry itself
(I don't mean the parasitic show-business around it)
will have grown, and be much more prosperous than it is now,
while the population will be more sportslike and healthier.
A few people gain much less money (they are still quite decently paid),
but a lot of people live honestly doing a useful job.
There will still be shows, but they won't be as much
of a mediatic event as they are now.
Of course, if you only remove intellectual property *from the sports shows*,
then the show business will move somewhere else,
and sports will greatly suffer at first.
But if you also remove intellectual property from everywhere else,
then it will be a general world-wide regeneration of all industries and arts.
Instead of have bribed arts that are worth mostly nothing,
with a premium being given to information in as much as it is new
and unattached to previous work (hence not building up richer structures),
and with technical and ethical criteria coming last,
artists would be paid for their actual work, not their face value:
creating, performing, composing, designing, recording, etc.
There won't likely be as many multi-billion dollar superstars
as there now are, but instead the serious, working, talentuous, artists,
will be recognized for their real work, and live decently;
the really good may even become rich,
though most likely not as much as can be seen today.
I could also talk about property of information inducing a producer-driven
economy, whereas license-Free Information means a consumer-driven economy.
Of course, this is only me considering your scenario.
EN> you support my conclusion that Open Source is only a means of fighting
EN> Microsoft.
Well, I know a lot of people from free software associations,
and I have contact with developers in many different sites,
who all support the idea of free software. I can tell you
their involvement in free software is *quite* independent
from Microsoft or any particular vendor (criticisms include LISP vendors,
though they are appreciated for their technical merits).
Best regards,
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
There cannot be Ethics without Models of possible behaviors,
and Imagination to explore them.
From: Howard R. Stearns
Subject: A challenge to the pundits (Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <36E0279E.3E9F5EDB@elwood.com>
Here's a challenge to anyone who takes issue with how they perceive all
or some Lisp vendors to operate:
Come up with a business plan you like that you are willing to bet real
money on.
Anyone who is serious -- and by that I mean that they are willing to
devote real resources (e.g., cash) -- should go ahead and contact a
vendor with their proposal. Do so by contacting them directly with at
least a summary of your specific proposal. (I do not recommend just
leaving message on c.l.l saying "why don't you guys do XXX".) If you
don't know how to write up a business plan, there are resources on the
net.
I'm sure that all the vendors would be glad to hear from you, but
speaking for Elwood, you can contact me through ······@elwood.com.
Francois-Rene Rideau wrote:
>
> ····@rigden.engr.sgi.com (Rob Warnock) writes:
> > This has recently come to be known as "Metcalfe's Law": The value of an
> > open/shared/interconnected product or technology increases as the square
> > of the number of users/nodes/connections. [...]
> > <URL:http://www.amazon.com/exec/obidos/ASIN/087584801X> [...]
> > If anyone is serious about trying to make a business out of Lisp (or almost
> > anything else), I strongly recommend reading this book. [Yeah, it's got
> > a hokey title, but just ignore it. There's some solid economics inside...]
> Which leads to the question:
> why don't LISP vendors, particularly Harlequin,
> that seems to be slowly moving away from being an active vendor,
> publish their implementations as free software,
> and sell branding and other services, like RedHat people do?
> http://www.press.umich.edu/jep/04-03/young.html
>
> Just because that model was discovered by UNIX guys
> doesn't mean it can't benefit to LISP.
> Actually, should LISP not follow this lesson, it will slowly disappear
> as being irrelevant.
> [I'd add that LISP, as a high-level language, is doubly disadvantaged
> by the proprietary software model, as I've argued in
> http://www.tunes.org/~fare/articles/ll99/index.en.html
> ]
>
> I hope that people at Harlequin, Franz, etc, will heed this message,
> or their LISP division might well end like Symbolics, Lucid, etc.
>
> [ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
> [ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
> [ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
> "Don't worry about people stealing your ideas. If your ideas are any
> good, you'll have to ram them down people's throats."
> -- Howard Aiken
From: Francois-Rene Rideau
Subject: Re: A challenge to the pundits (Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <lzpv6mr2i6.fsf@ZhengHe.augustin.thierry>
Dear Howard,
"Howard R. Stearns" <······@elwood.com> writes:
> Here's a challenge to anyone who takes issue with how they perceive all
> or some Lisp vendors to operate:
>
> Come up with a business plan you like that you are willing to bet real
> money on.
While I'm giving away my ideas about a general free software business model
because I'm personally convinced they might make a better world,
I'm will not be giving away my work time, because I value it much;
and making up a precise business plan IS lengthy and valuable work.
I'm for free information, as of free from "rights".
I'm NOT for free information-related services, as in free from retribution.
If you want me to undertake a precise business plan,
I'm willing to do it, but I require to be paid accordingly,
and since I'll need help from an accountant or other business consultant,
this means you'll have to pay the consultant, too.
And so as to build this business plan, I'll need access
to your company's business records, too, and likely to
consulting relative to your country's national business legislation.
If you're interested in hiring my services for this matter (or another),
you may contact my employing laboratory [1].
We have experience in the design, development and deployment
of very-large long-lasting high-reliability real-time information systems,
for which we're more and more convinced that proprietary software products
are part of the problem set as much as of the solution set.
Although defining business plans for foreign companies
is not our primary activity (again, we'll require external consultancy),
we are always looking for diversification of financial resources,
as opposed to reserving our expertise our mother-company.
Your offer, if firm, will be considered seriously.
Now, if you want me to undertake such work on my own spare time,
for a company in which I'd invest personal capital, I even might.
But only when my current contract is over,
and then, I'm afraid it will be for my own company,
not for a foreign company I only know from Internet hearsay.
[1] DTL/ASR - CNET - France Telecom
38-40 rue du G�n�ral-Leclerc
92794 Issy-les-Moulineaux Cedex 9 FRANCE
Phone: (+33) (0)1 45 29 54 91
Fax: (+33) (0)1 45 29 66 04
e-mail: ···················@cnet.francetelecom.fr
Best regards,
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
Because people confuse information and information-related services
(which include searching, creating, processing, transforming, selecting,
teaching, making available, guaranteeing, supporting, etc), they are afraid
that Free (libre) Information mean free (gratis) information-related services,
which would indeed kill the industry of said services. On the contrary,
Free Information would create a Free Market in these services, instead of
current monopolies, which means they will be available at a fair price,
so the result would be a flourishment of that industry! -- Far�
From: Christopher R. Barry
Subject: Re: A challenge to the pundits (Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <87zp5qcnxn.fsf@2xtreme.net>
Francois-Rene Rideau <····@ZhengHe.augustin.thierry> writes:
> Dear Howard,
>
> "Howard R. Stearns" <······@elwood.com> writes:
> > Here's a challenge to anyone who takes issue with how they perceive all
> > or some Lisp vendors to operate:
> >
> > Come up with a business plan you like that you are willing to bet real
> > money on.
>
> While I'm giving away my ideas about a general free software business model
> because I'm personally convinced they might make a better world,
> I'm will not be giving away my work time, because I value it much;
> and making up a precise business plan IS lengthy and valuable work.
> I'm for free information, as of free from "rights".
> I'm NOT for free information-related services, as in free from retribution.
[...]
> If you want me to undertake a precise business plan,
> I'm willing to do it, but I require to be paid accordingly,
How noble. You probably spent 10 hours planning and typing all that
crap you wrote to this group. Frankly, I feel you are unqualified to
draft a real-world business plan[1].
Talk is cheap - particularely in your case it's all you ever do, be it
the LispOS list, the Tunes list, comp.lang.lisp, whatever.
For all your philosophical spewing about morality and ethics and
"Regeneration day when all Lisps are free again", this post to me is
the pinnacle of hypocrisy.
Franz has been extraordinarily generous to the Lisp community in
providing the Allegro CL Linux Trial Edition, which is virtually their
Enterprise edition (at least thinks it is), for $0 for non-commercial
use.
Harlequin, with Kent Pitman, provided us with the HyperSpec, a
document that clearly took an extraordinary ammount of time and effort
to produce, and as far as I can tell never directly planned to or did
in fact make any money from doing this.
I have a feeling you aspire to become one of these people like Eric
Raymond, that like to talk a lot but shouldn't be mistaken for anyone
that actually writes a whole lot of code[2]. Eric Raymond though has
spent a lot of time consulting with corporations and vendors and the
media laying out how they could profit and succeed with an Open Source
model, without charging for his time. Whether he does this for his own
ego or not is not so important as the fact that good results are being
made.
Have fun writing your little papers,
Christopher
[1] If your bizarre Curriculum Vitae is any indication
http://www2.tunes.org/~fare/cv.html
[2] He "maintains" fetchmail.
From: Erik Naggum
Subject: Re: A challenge to the pundits (Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <3129795882856771@naggum.no>
* "Howard R. Stearns" <······@elwood.com>
| Here's a challenge to anyone who takes issue with how they perceive all
| or some Lisp vendors to operate:
|
| Come up with a business plan you like that you are willing to bet real
| money on.
* Francois-Rene Rideau <····@ZhengHe.augustin.thierry>
| While I'm giving away my ideas about a general free software business
| model because I'm personally convinced they might make a better world,
| I'm will not be giving away my work time, because I value it much;
so you value your "work time" more than actually _doing_ something to
make a better world? geez. this translates into "I don't believe what
I'm saying, but it would be nice if some other people did".
| If you want me to undertake a precise business plan, I'm willing to do
| it, but I require to be paid accordingly, and since I'll need help from
| an accountant or other business consultant, this means you'll have to pay
| the consultant, too. And so as to build this business plan, I'll need
| access to your company's business records, too, and likely to consulting
| relative to your country's national business legislation.
let me get this straight. you are unwilling even to invest enough of
your own time and money to create a business plan that might help reach
your goals if doing so could help other people believed in it?
| If you're interested in hiring my services for this matter (or another),
| you may contact my employing laboratory [1].
not bloody likely. after the above stunt, I cannot even assume you know
how to do the job you are paid to do and I certainly would _not_ employ
you in a business that planned to make money.
| We have experience in the design, development and deployment of
| very-large long-lasting high-reliability real-time information systems,
| for which we're more and more convinced that proprietary software
| products are part of the problem set as much as of the solution set.
so get better people. that probably means firing you, so I can see why
you argue in favor of giving sources away so others can do your work for
your for free if you just give them the sources.
| Your offer, if firm, will be considered seriously.
except that you will not fund it yourself, which is what "seriously"
_means_ in a discussion of business issues elsewhere. I'll bet the
saying "put your money where your mouth is" sounds really alien to you,
but it's a very common saying towards people who are suspected of
spouting hot air and not actually _wanting_ anything.
| Now, if you want me to undertake such work on my own spare time, for a
| company in which I'd invest personal capital, I even might. But only
| when my current contract is over, and then, I'm afraid it will be for my
| own company, not for a foreign company I only know from Internet hearsay.
so you now admit to know nothing at all about either Harlequin or Franz
or Digitool or Elwood or any of the other players in the Lisp field.
I'm glad my suspicions about you were not disproven.
you'll note that I ignored the Followup-To to gnu.misc.discuss, which is
just another of your despicable cop-out tactics. you're just a nutball
like the majority of the proponents of stealing other people's work, and
when you can't talk your way out of it, you certainly will not _work_.
and this is the commonality of people on gnu.misc.discuss, too, so thank
you for telling us where you really belong.
I hope Free Software and Open Source are considered less viable means of
doing business after this, and that anyone who considers using their
licenses to publish software in source form (which I still think is a
good idea, but not for any of the reasons the shallow morons think, and
most definitely _not_ to the general public), will think twice and talk
to a good intellectual property lawyer about how to secure the rights of
the _creators_ of intellectual property, not just those of its _users_.
I'd like to get back to the future of Lisp now that we have shown what
kind of people are likely to argue in favor of unencumbered access to
other people's investments.
#:Erik
--
in an information society, misinformation is as serious as murder
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u7678i2829.fsf@ebi.ac.uk>
On Tue, 2 Mar 1999 16:49:24 GMT,
"Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> You cut out the part of my discussion where I mentioned if it's not free
Kent> it doesn't really address the issue.
no, i sort of latched on to the CORBA word. But anyway, there are very many
free ORBs out there (see http://adams.patriot.net/~tvalesky/freecorba.html) ,
most of them only dealing with C++ and Java, but there is at least one that
can do Common Lisp (ILU, see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html) (I
have no experience with this, though).
I think this is not too bad, and wouldn't be surprised if it gets better.
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Philip Lijnzaad <········@ebi.ac.uk> writes:
> If there is a CORBA language mapping, a foreign function interface
> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
> function interface. Imagine SmallTalk, Cobol, C, Python and Lisp programs all
> talking to each other; all possible in CORBA.
Hardly. What your talking about is an ideation of CORBA that is quite
a bit removed from it's actuality, or even possibility. I prefer my
ALIEN interface in CMUCL immensly to CORBA and the IDL bullshit when I
want to talk to a C or other language Library. I would not want to
talk to my FFT library via CORBA. I would rather use RMI with all of
it's problems, if I wanna ship Java classes around, rather than wait
for some molasses like RFP approval proccess from the OMG to decide
how they wanna pack them up.
> Likewise, you don't really *want* sockets if you've got CORBA.
CORBA does not eclipse other forms of communications between processes,
not by a long shot.
> In summary, I would argue that CORBA support (a standard IDL->Lisp mapping
> and at least one ORB) is the only thing really needed to counter the
> lack-of-connectivity arguments.
I would argue that you have CORBA on the brain. It's ok, I did too once.
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u73e3m26yg.fsf@ebi.ac.uk>
On Tue, 02 Mar 1999 17:27:04 GMT,
"Craig" == Craig Brozefsky <·····@red-bean.com> writes:
Craig> Philip Lijnzaad <········@ebi.ac.uk> writes:
>> If there is a CORBA language mapping, a foreign function interface
>> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
>> function interface. Imagine SmallTalk, Cobol, C, Python and Lisp programs all
>> talking to each other; all possible in CORBA.
Craig> Hardly. What your talking about is an ideation of CORBA that is quite
Craig> a bit removed from it's actuality, or even possibility.
yes, I was trolling a bit here. This is currently far removed from reality,
but the principle holds: in an ideal world CORBA, could theoretically do
this. No other technology can make this claim.
Craig> I prefer my
Craig> ALIEN interface in CMUCL immensly to CORBA and the IDL bullshit when I
Craig> want to talk to a C or other language Library. I would not
Craig> want to talk to my FFT library via CORBA. I would rather use RMI with
Craig> all of it's problems,
This is another java compatibility thread I'm afraid ...
Craig> if I wanna ship Java classes around,
instances or classes? Currently, CORBA only provides access to remote
instances; it doesn't ship them around by default. But you can implement you
objects such that they can be shipped off-site (using the LifeCycle
specification). There's a new spec called objects-by-value which offers
the shipping of object state by default, too. Not implemented yet, of
course.
Craig> rather than wait for some molasses like RFP approval proccess from the
Craig> OMG to decide how they wanna pack them up.
OK, the standardization process can be a bit tedious, but it is very open,
not too slow, and seems to have enough momentum. It certainly didn't
stop the KDE and Gnome folks to use CORBA as their infrastructure.
>> Likewise, you don't really *want* sockets if you've got CORBA.
Craig> CORBA does not eclipse other forms of communications between processes,
Craig> not by a long shot.
I don't talk about eclipsing, but maintain IF you can use CORBA, THEN sockets
are not overly necessary anymore. I know of no one who actually mixes the
two. But I concede that CORBA would be lost without, e.g. http. Still
interesting to note that Java's RMI now uses CORBA's iiop protocol. This
unifies rmi/corba against DCOM, usoft's version of distributed computing.
Craig> I would argue that you have CORBA on the brain. It's ok, I did too once.
I'm not married to CORBA, but thought that it could be illuminating to
mention CORBA as an alternative in the foreign function interface debate.
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
In article <··············@ebi.ac.uk> , Philip Lijnzaad <········@ebi.ac.uk>
wrote:
> On Tue, 2 Mar 1999 01:00:17 GMT,
> "Kent" == Kent M Pitman <······@world.std.com> writes:
>
> Kent> The specific things I'm harping on--sockets, corba, etc. (someone
> Kent> mentioned odbc) are all connective tissue. If we could connect to
> Kent> other systems
>
> On the CORBA front, there is definitely movement. Franz has recently proposed
> a (new) lisp language mapping for IDL (OMG document number
> orbos/98-10-16.pdf).
>
> If there is a CORBA language mapping, a foreign function interface
> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
> function interface. Imagine SmallTalk, Cobol, C, Python and Lisp programs all
> talking to each other; all possible in CORBA.
CORBA and FFI address two different problems. CORBA will not replace FFI
capability. What are you going to do when you want to call an entry point
in a library? Wrap the library so you can make a CORBA call? The last time
I looked (about a year and a half ago) a CORBA method invocation cost a
_lot_ more than a simple function call.
>
> Likewise, you don't really *want* sockets if you've got CORBA.
Maybe I've overlooked some context to this discussion that makes your
assertion seem less hyperbolic. But what about the existing protocols that
are already implemented via the facilities (ports, addresses, and
transports) provided by a simpler network layer? Will CORBA subsume these,
as well?
>
> I imagine that the idl->Lisp language mapping is a very important development
> (and could actually be the first lisp-related standard since a long time).
>
> In summary, I would argue that CORBA support (a standard IDL->Lisp mapping
> and at least one ORB) is the only thing really needed to counter the
> lack-of-connectivity arguments.
>
> Philip
Not the _only_ thing, but it will certainly be a useful tool. BTW, ILU is
already available: <ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
There are many ways to abbreviate something, but only one way not to.
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u71zj626l2.fsf@ebi.ac.uk>
On Tue, 02 Mar 1999 09:17:13 -0800,
"David" == David B Lamkins <········@teleport.com> writes:
David> CORBA and FFI address two different problems. CORBA will not replace
David> FFI capability. What are you going to do when you want to call an
David> entry point in a library? Wrap the library so you can make a CORBA
David> call?
yes, that would be the idea.
David> The last time I looked (about a year and a half ago) a CORBA
David> method invocation cost a _lot_ more than a simple function call.
yes, that's still the case. For many purposes, this would be good enough.
>>
>> Likewise, you don't really *want* sockets if you've got CORBA.
David> Maybe I've overlooked some context to this discussion that makes your
David> assertion seem less hyperbolic. But what about the existing protocols
David> that are already implemented via the facilities (ports, addresses, and
David> transports) provided by a simpler network layer? Will CORBA subsume
David> these, as well?
not subsume, but use them (iiop is based on tcp/ip, so it uses IP addresses,
ports and tcp transport). Turns out many people prefer the higher abstraction
layer of CORBA over sockets, and I would argue that this is a Good
Thing. Based on numerous posts in comp.object.corba, people who have used
CORBA and sockets vastly prefer CORBA over sockets. This includes myself,
although I have no great experience with sockets.
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
In article <··············@ebi.ac.uk> , Philip Lijnzaad <········@ebi.ac.uk>
wrote:
> On Tue, 02 Mar 1999 09:17:13 -0800,
> "David" == David B Lamkins <········@teleport.com> writes:
>
> David> CORBA and FFI address two different problems. CORBA will not replace
> David> FFI capability. What are you going to do when you want to call an
> David> entry point in a library? Wrap the library so you can make a CORBA
> David> call?
>
> yes, that would be the idea.
>
> David> The last time I looked (about a year and a half ago) a CORBA
> David> method invocation cost a _lot_ more than a simple function call.
>
> yes, that's still the case. For many purposes, this would be good enough.
Ahh, the joys of selective quoting...
In article <··············@ebi.ac.uk> you wrote:
> If there is a CORBA language mapping, a foreign function interface
> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
> function interface.
The last time I used a commercial-quality CORBA implementation (about a year
and a half ago), the latency it introduced was in the range of 10 to 15
milliseconds. Do you believe that this is an acceptable amount of overhead
for calling a function outside of Lisp? Remember, you said that with CORBA,
an FFI "becomes unnecessary." Should I take this to mean that, having
CORBA, I should have no need of an FFI? Or did you have something else in
mind when you wrote that?
>
>
>>>
>>> Likewise, you don't really *want* sockets if you've got CORBA.
>
> David> Maybe I've overlooked some context to this discussion that makes your
> David> assertion seem less hyperbolic. But what about the existing protocols
> David> that are already implemented via the facilities (ports, addresses, and
> David> transports) provided by a simpler network layer? Will CORBA subsume
> David> these, as well?
>
> not subsume, but use them (iiop is based on tcp/ip, so it uses IP addresses,
> ports and tcp transport). Turns out many people prefer the higher abstraction
> layer of CORBA over sockets, and I would argue that this is a Good
> Thing. Based on numerous posts in comp.object.corba, people who have used
> CORBA and sockets vastly prefer CORBA over sockets. This includes myself,
> although I have no great experience with sockets.
They solve different problems, and are both useful in their own domains.
CORBA can not completely subsume socket-like interfaces, which will remain
useful as the layer upon which people build traditional protocols (HTTP,
DNS, FTP, TELNET, DHCP, ...).
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
From: Philip Lijnzaad
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <u7emn62m3j.fsf@ebi.ac.uk>
On Wed, 03 Mar 1999 08:52:34 -0800,
"David" == David B Lamkins <········@teleport.com> writes:
David> In article <··············@ebi.ac.uk> , Philip Lijnzaad <········@ebi.ac.uk>
David> wrote:
>> On Tue, 02 Mar 1999 09:17:13 -0800,
>> "David" == David B Lamkins <········@teleport.com> writes:
>>
David> CORBA and FFI address two different problems. CORBA will not replace
David> FFI capability. What are you going to do when you want to call an
David> entry point in a library? Wrap the library so you can make a CORBA
David> call?
>>
>> yes, that would be the idea.
>>
David> The last time I looked (about a year and a half ago) a CORBA
David> method invocation cost a _lot_ more than a simple function call.
>>
>> yes, that's still the case. For many purposes, this would be good enough.
David> Ahh, the joys of selective quoting...
ehr ... this was lifted out of the following paragraph:
David> CORBA and FFI address two different problems. CORBA will not replace FFI
David> capability. What are you going to do when you want to call an entry point
David> in a library? Wrap the library so you can make a CORBA call? The last time
David> I looked (about a year and a half ago) a CORBA method invocation cost a
David> method invocation cost a _lot_ more than a simple function call.
Is this quoting selectively ? Moreover, I am basically agreeing with you.
David> In article <··············@ebi.ac.uk> you wrote:
>> If there is a CORBA language mapping, a foreign function interface
>> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign
>> function interface.
David> The last time I used a commercial-quality CORBA implementation (about a year
David> and a half ago), the latency it introduced was in the range of 10 to 15
David> milliseconds.
yes that is a lot, and depends on primarily the ORB. I don't want to go into
this debate; suffice it to say that some ORBS (notably Orbix) are notoriously
slow.
David> Do you believe that this is an acceptable amount of overhead
David> for calling a function outside of Lisp?
I would imagine that in some cases this is acceptable, and it also depends on
how long the foreign call itselfs typically takes to return. What is the
latency of your average cgi-bin perl script? They may not be routinely called
from lisp programs, but I've seen people do stranger things. Of course, in
practice, you do a foreign call to do some number crunching or so, and for
that I agree CORBA is less well suited.
However, an ORB can be clever, and could put different clients and servers in
one process, resulting in vastly improved throughput. Current orbs only do
this within one language, but I don't think it is a priori impossible to
co-locate, in one process, clients and servers in different languages.
Internally, an FFI would be needed; externally, everything would be specified
in IDL. But this scenario is mere phantasy.
David> Remember, you said that with CORBA,
David> an FFI "becomes unnecessary."
the real quote is "essentially unnecessary."
David> Should I take this to mean that, having CORBA, I should have no need
David> of an FFI?
ehrm, no, that is too strong. But I think CORBA can address some of the needs
traditionally addressed by FFI's. In one fell swoop, it provides a mechanism
for interoperability with Java, C++ and an increasing number of less common
languages (of course provided the ORB works, is fast, does your language,
etc. etc.) This is something that I have not seen in FFI's. Even if the
current CORBA pratice is far from ideal, I think the framework is right. The
fact that things are meticulously (if imperfectly) standardized isn't
bad either.
To get to the bottom of this: I think that an FFI would only really be
crucial where speed matters. But I'd love to hear counter arguments (other
than that it might be termed a tautology :-).
David> They solve different problems, and are both useful in their own
David> domains. CORBA can not completely subsume socket-like interfaces,
David> which will remain useful as the layer upon which people build
David> traditional protocols (HTTP, DNS, FTP, TELNET, DHCP, ...).
Agreed.
Philip
--
No electrons were harmed during the composition or transfer of this message
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
In article <····················@news.mindspring.com>, David E. Young wrote:
> Currently, I am building prototypes of a knowledge-based system
> for use within the telecom industry, using Allegro Common Lisp.
[...]
> Both Franz and Harlequin offer CORBA
> bindings for their Lisp implementations, along with language
> extensions to support multi-threaded programming. I can't speak to the
> quality of the CORBA bindings (having not used them), but it's at
> least evident that two leading Lisp vendors are keeping pace with
> software engineering trends.
[...]
> So, problems. From a "language standard" perspective, I believe a
> significant shortcoming with Lisp is the omission of basic
> inter-process communication facilities ("sockets") and a standard
> threading ("process") interface. Java provides both, to its credit,
> making that platform attractive to folks building server-class
> software. In my opinion, it simply isn't any longer acceptable to fill
> a system with platform-specific, conditionally evaluated code.
Perhaps you think it's the same level of "ugly", but all you need is
vendor-specific code. If you adopt Franz's Allegro CL, for example, as you
appear to have done, you can easily use their cross-platform modules for
sockets, threads, and FFI.
It's not quite as good as being the language definition (like for Java), but
still it isn't "platform-specific, conditionally evaluated code" either.
-- Don
--
Don Geddis ······@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwemnafmem.fsf@world.std.com>
I waited to chime in on this discussion in answer of my own question, but
now that enough people have spoken that my voice will just be one of many
and won't bias the outcome (I hope), I want to take a moment to leap on a
particular statement (sorry Don, nothing personal--I thank you for the nice
setup) to give my own thoughts on what the problem is. If anyone thinks I'm
way off base in any of this, I'd be very interested to hear it.
Also, these remarks might at points seem to be somewhat critical of vendors
but are meant with all constructive intent. I want Lisp to succeed and I
think the only way I know to make that happen is to make sure the issues are
out on the table with no "pulling of punches". If there is something wrong,
vendors need to know it or how else will they be able to plan a fix?
Sorry also for the myriad typos I probably made in here. My PC keyboard
bounces a lot and I tire of fixing it. (I got a suggestion from someone
about a dynamic spell corrector I might try, but I haven't yet had time.)
······@meta.Tesserae.COM (Don Geddis) writes:
> Perhaps you think it's the same level of "ugly", but all you need is
> vendor-specific code. If you adopt Franz's Allegro CL, for example, as you
> appear to have done, you can easily use their cross-platform modules for
> sockets, threads, and FFI.
To my knowledge, the sockets stuff is not part of the Allegro personal
edition and not sold separately. Last I checked one has to move from about
a $600 product offering to a $3000 product offering to get them. As such,
this is not a technical barrier but is an economic barrier. At the company
I'm working for right now, which is not a Lisp shop, this is a barrier to
acceptance because I don't yet have enough management buy-in to get the
larger product offering and I can't get from here to there because them
believing it is a good tool involves them believing I can get it at
commodity prices. Franz makes the case to me that If I'm deriving benefit I
should be willing to pay, but as it is I am stuck in a permanent ghetto in
that office because I simply can't demonstrate the goodness of Lisp without
the certainty of competitive pricing. This immediately cues management to
confirm their worst suspicions about Lisp which is that everything about it
is higher overhead than things like Java which come net-ready fromt he
get-go, and which everyone else uses. I could go with Harlequin but they
don't have Franz's cool non-CLIM IDE. I'm sure Franz thinks I'm getting a
bargain on the IDE compared to Harlequin, and if that were the competition,
I would be. But the fact is that the competition is visual basic or Java
for UI, and is certainly Java or C++ for programming. A quick glance at a
catalog says I can buy either of these for $1200 complete (enterprise
edition) and for $1500 I could buy the Enterprise Edition of Microsoft
Visual Studio which comes with everything I need to program Visual Basic,
Visual C++, Visual FoxPro, Visual InterDev, and Visual J++. And even if I
don't think J++ is really Java, I can afford to buy Symantec Visual Cafe on
top of that and STILL not be up to the $3000 line franz wants for its
professional edition to get sockets (and admittedly other stuff, but stuff
I don't presently need and can't elect not to buy).
I personally think it's fine to charge extra for the non-commodity things
that Lisp offers that are different--such as a run-time-accessible compiler
or the MOP, as a way of emphasizing their value over and above commodity
things (to the extent that they can be packaged that way). But I think
certain things are specifically needed in order to make the claim "Lisp is
better":
(1) You have to hold the price constant when you compare.
It isn't a compelling sales argument to take a $500 offering from one
company and a $3000 offering from another and claim the $3000 is
better. People will assume the "better" comes from the price and not
the technology. If you don't offer something that people can see is
the same price but better quality, people won't get it. I don't see
any commercial Lisp offering like this today; I haven't checked Digitool
lately so can't speak for that, but of course one could make the sad
claim that being on a Mac is enough to make it "not equivalent". Pity.
(I hope the IMac changes that.)
(2) You have to track what I've come to call the "commodity baseline".
Like it or not, these other languages define what is standard.
Going to a $3000 offering for a sockets library just doesn't cut it.
Monopolists can get away with this--my cable company makes it so that
certain single channels can only be bought if you buy some huge
package you don't want, but that's going to fall because it's enough
to drive me to the competition. And Lisp is driving people to the
competition when it fails to meet reasonable requests not only for
value per package (because maybe the $3000 package from Franz has
that much good stuff in it) but also making packages that are
composed and priced to meet user needs.
My standard example of the commodity baseline is the memory (M) button
on a calculator. Maybe they don't even have them these days, but when
calculators first came out they did. And if you wanted a calculator
that had just arithmetic it was $20 but if you wanted M, M+, and M-, it
was $40. After a time, though, calculators BOTH got cheaper AND
included this memory stuff in as a standard feature. No one charged
extra because it was understood to be the commodity part. Extra money
was made up by larger volumes (accomodating lower margins) and by
cheaper production costs (because they got better at what they did) and
by continuing to add new features that made it worth paying high
dollars again. (I've not checked recently, but nowadays I imagine the
commodity is 5 gigs of flash memory but if you need 10 gigs you have to
pay the extra $20... times change, and not only the price has to
change, but what you get in the "standard offering" has to change.)
Tired of the standard cable TV company (MediaOne) in my town,
I investigated alternatives. Everything the alternative company (RCN)
offered sounded better AND chaper. Everything. I still hesitated.
Change is disruptive. It costs and I know it. They promised me
they'd make the installation free and that if I didn't like it they would
switch me back for free. I still hesitated. Finally, I just decided to
try it but the first thing I did to protect myself from their cable
modem (which I feared) was to buy another computer to be an in-house
firewall. Their "free trial" has so far cost me $600 (the cost of
the firewall). Maybe it will be good. I hope so. I always wanted a
firewall. But I hated being forced to bear the expense at a time not
correlated with a perceived need. If the Lisp vendors come to grips
with why my reasoning is typical of the modern marketplace, where we
all know that free things are not free and that risk-free doesn't mean
it and that purported features may not really turn out to be actual
features and where the truth or honest intent of the seller is not
what necessarily wins the day, I think they will be a long way
toward understanding how to expand the market...
One last item is licenses, specially but not exclusively runtime
licenses. Normal languages don't expire their license--they expect
to sell you something next year because it'll be better or contain
new features you'll need. And they don't charge you for deliverables.
In Lisp, we have to worry a "deliverable" will be the whole system
and will compete with the original. But that's a burden we've elected.
It should be possible to build a deliverable that doesn't have that
character and that isn't charged for at all, so that at least some
applications can be delivered free, or else again Lisp can't compete
with this "commodity property" of standard languages.
I've focused on sockets mostly as an example of a problem. I added
mention of runtime licenses to show it's not unique. But I'm sure there
are others I'm not mentioning--maybe others will contribute things
they think are commodities but not being treated as such.
(3) You have to sell to new users, understanding that they have to be
convinced gradually of the need for Lisp.
We turn away people that aren't yet ready for Lisp and they never
return. They complain that our "hello world" is too big in megabytes.
Lisp isn't optimized for little problems. So they use something else.
And then they never come back. That's a hard problem to fix, and I
won't address it here because I'm sticking to market issues and this
really a technical issue.
But we also have traditionally turned students away by making the
price too high. Nowadays, there are some free offerings that help a
lot, but they will not help if they don't contain that all-important
commodity baseline of software. Students get taught about networks.
If you make them pay $3000 for network sockets libraries, Lisp will
not be used in networks classes. Poof. Lost. Students need high-end
tools, not low-end ones.
We also fail to recognize that Lisp sales in companies are often
made by lone individuals trying to show power. They can't get budget
without a demonstration and they can't demonstrate without power.
Eval copies help a little, but what would help more is a pricing that
was more cafeteria style, I think--where you could get a low-price
vehicle to start and incrementally add features at small prices that
were easy to get approvals for. The place "enterprise edition sales"
ought to kick in is when people have found that the pay as you go stuff
is adding up to too much. And if you don't have enough stuff in your
enterprise edition that this would ever happen, then we know where
your dollars need to go.
(4) You have to relate what you do to a standard paradigm.
Saying that Lisp is different is almost itself fatal now. There
has been a qualitative shift in the market for "connectivity" and
there is now a burden on vendors to show they can connect. Lisp
must line up its connect points very prominently and show how "the
same" it is before it can pronounce the power of its difference.
That's a burden, but the burden of looking incompatible (like the
VHS/Betamax fiasco for video tape) must be avoided. This isn't about
parens because they are not "connective". This is about sockets,
CORBA, COM and all the others. Yes, they are there but they are hidden.
One concrete suggestion for the vendors to ponder:
It has occurred to me of late that the best thing that Lisp could do is to
just make CORBA and COM and ODBC and other stuff they presently charge
premiums for be part of the standard offering and say "Lisp is the language
for connectivity". It seems to me almost senseless to talk about Lisp as
having these things when it doesn't come with the product. That's what made
ANSI CL such a win in its day--C defined standard libraries but there was no
expectation that you actually GOT those libraries, so in practice all C
implementations were different. Lisp was like getting standard libraries
and the assurance you really had them as part of the language, which is why
the language is so big. What we need to do is raise the bar and say that
you really get all of that stuff in the language and put the pressure on
other languages to bring down the cost of their stuff. If CORBA is to be
ubiquitous, it must be affordable. Lisp has a chance to get ahead of the
game and be the place that affordability is most easily had. In a few
years, after the other community has extorted money out of everyone who will
pay high CORBA costs, the price will fall and Lisp people will have to
charge less for CORBA too, but it will no longer be a reason for people to
prefer Lisp over other things. These are gambles that vendors might take,
but if you take no gambles, you mostly do not win. The trick is to manage
the gambles as well as you can, making them into sciences, not to avoid them
as if they were the plauge.)
If Lisp were the vehicle of choice to get flexible and powerful connectivity
at a cheap price, it would be a force to be reckoned with. If instead for
every such thing that it's gone to the trouble to make, it makes it the same
price or higher as the "commodity languages", where is the incentive to use
Lisp over a commodity. If you re-read my story about RCN above, you'll see
that people fear change, and that if you offer them the same functionality
at same or higher price, they'll have no incentive to switch because in the
end fear of risk, of differentness, of change, etc. will win the day and
inertia will leave people in the commodity languages.
This proposal of mine is a sort of compromise between the present situation
and the proposal by some that one go to free software. Free software won't
support any of these companies, but lower margins and higher volumes will.
Yes, done wrong, it could drive vendors out of business, but unless the
vendors are working on becoming "solution sellers" and not "language
sellers" they are already on track to become out of business ... because
simple math will tell you that you can't keep up with the investment of the
competition as the competition gets larger and larger resources for
development and more and more sales into places allowing smaller margins to
keep them afloat. The choice isn't whether to take a risk, since things are
at risk now, it's only how. And any vendor who thinks they are not now at
risk because cash flow worked this quarter should take a page out of the
Symbolics history book-- good cash flow is often just an excuse to deviate
from what the market is telling you clearly it's going to need. And by the
time you feel the pain, it may be to late to act. Times of cash flow is
when you want to accomodate risk.
Kent M Pitman <······@world.std.com> writes:
> But we also have traditionally turned students away by making the
> price too high. Nowadays, there are some free offerings that help a
> lot, but they will not help if they don't contain that all-important
> commodity baseline of software. Students get taught about networks.
> If you make them pay $3000 for network sockets libraries, Lisp will
> not be used in networks classes. Poof. Lost. Students need high-end
> tools, not low-end ones.
I think Lisp vendors have to go beyond providing what exists today. They
have to be able to offer lisp as the means to study the Next Big Thing
effectively.
Most (all?) schools keep in mind what is happening in industry and the
wider world when deciding their curriculum. The better ones along the way
try to make sure students learn the major concepts along the way. Consider
what a typical OS class might try to teach students. Such classes typically
deal with subjects including synchronization, memory management, file
system access, etc., with the more advanced courses moving on to networked
file systems, RPC, and so on. Consider a class that attempts to teach the
workings of RPC. In Lisp the issues are simpler, because the data is
naturally tagged. If most of the world is using C, a student that has
learned about RPC in the Lisp context is going to miss out on some of the
crucial complications that C introduces. In other words, the student in the
context of the larger world is going to end up deficient.
Add to that how well entrenched C is in the OS and networking community,
and you will be hard pressed to convince a school to switch to Lisp for
teaching these subjects, no matter how good the environments get.
Computing is not a static subject though. New topics appear and redefine
aspects of computing. The web over the last few years, for instance, has
produced a significant shift in computing. What Lisp needs to do is to make
itself suitable for these new areas of computing. If Lisp can handle a new
problem better than another language, a professor would have a stronger
incentive to use it for teaching a class.
New paradigms in computing emerge on top of old ones though. The web is in
some ways an abstracted networking interface dealing with the flow of
information. Lisp has to have features for dealing with both of these
elements readily available (though not necessarily standardized) to make it
attractive for web programming. Database access often also turns out to be
critical.
As far as I am concerned, Lisp appears to have missed the web bandwagon. I
hope the next opportunity is not lost this easily.
Traditionally, for Lisp, AI had been its strength. As a graduate student in
AI, I continue to use lisp. But AI is changing. AI here has been
assimilated into the larger discipline of Intelligent Systems, and the
variety of subjects we deal with, along with the techniques we use, has
risen significantly. We now have to interface with vision, numerical
methods, and so on. As a result, justifying the use of Lisp to do AI is
also becoming more difficult. So, not only is Lisp not adapting to new
techniques, it appears to be losing ground in some of its traditional
strengths.
In short, from my perspective Lisp has lost a lot of ground in education. I
don't really see what vendors can do about it. They can't predict what the
Next Big Thing will be. The best they can do is provide tools and match the
current commodity products. They can't convince a school or faculty to
consider Lisp for teaching a class. But if Lisp is to have long term
viability, it is absolutely essential that it be more than a bad memory
that students come out of school with. This most definitely will be a long
slow process.
It seems right now that Lisp is mostly driven by those that have fond
memories of the lisp machines. As impractical as they might have been (in
terms of size and cost) they appear to have included a variety of cool
concepts that inspired a lot of hackers. I didn't grow up with lisp
machines. My impression of lisp is entirely from current environments, and
the impression I have is that they are impenetrable black boxes that
provide some really nice abstractions. Even as a believer I have trouble
locating material to learn more about the environment I use and about lisp
in general. This too must change.
I don't know where we can go from here. I don't have a vision. The vendors
certainly have their work cut out for them. But as a community I feel we
have failed to keep lisp attractive, and have not been able to advance it
sufficiently.
Sunil
In article <···············@whizzy.cc.gatech.edu> , Sunil Mishra
<·······@whizzy.cc.gatech.edu> wrote:
> Kent M Pitman <······@world.std.com> writes:
>
>> But we also have traditionally turned students away by making the
>> price too high. Nowadays, there are some free offerings that help a
>> lot, but they will not help if they don't contain that all-important
>> commodity baseline of software. Students get taught about networks.
>> If you make them pay $3000 for network sockets libraries, Lisp will
>> not be used in networks classes. Poof. Lost. Students need high-end
>> tools, not low-end ones.
>
> I think Lisp vendors have to go beyond providing what exists today. They
> have to be able to offer lisp as the means to study the Next Big Thing
> effectively.
IMO, there's little, if any, connection between the Next Big Thing and any
particular technology. The Next Big This is defined by marketing and
supported by consumer behavior.
OTOH, Lisp has a very low profile in both marketing and market share. This
is itself not necessarily bad. I don't believe that Lisp has to be a
commodity in the software development community in order to remain viable.
So long as it continues to address problems ignored by the "mainstream",
Lisp will have a place.
>
> Most (all?) schools keep in mind what is happening in industry and the
> wider world when deciding their curriculum. The better ones along the way
> try to make sure students learn the major concepts along the way. Consider
> what a typical OS class might try to teach students. Such classes typically
> deal with subjects including synchronization, memory management, file
> system access, etc., with the more advanced courses moving on to networked
> file systems, RPC, and so on. Consider a class that attempts to teach the
> workings of RPC. In Lisp the issues are simpler, because the data is
> naturally tagged. If most of the world is using C, a student that has
> learned about RPC in the Lisp context is going to miss out on some of the
> crucial complications that C introduces. In other words, the student in the
> context of the larger world is going to end up deficient.
This is a good point. A quality educational institution will address the
fundamentals, _and_ make a clear distinction between concept and
implementation. Unfortunately, the institutions the ability to present a
multiplicity of implementations as first- and second-generation computer
companies merged or died in the 1970's. Later, Unix had the effect of
homogenizing OS education because it was freely available to universities,
who adopted it partly because of source availability, and partly because of
budget considerations.
But there's a flip side to this issue. What concepts are _not_ being taught
because Lisp is inaccessible to universities? Why isn't there a reference
implementation of Lisp that could be used to teach the concepts of dynamic
programming environments in the same way that Unix served as a reference
implementation for operating systems?
>
> Add to that how well entrenched C is in the OS and networking community,
> and you will be hard pressed to convince a school to switch to Lisp for
> teaching these subjects, no matter how good the environments get.
>
Again, I don't think there's a win-lose situation here. Lisp should be
taught alongside other technologies for the things that it most clearly
demonstrates. (A tentative list: automatic storage allocation, lexical and
dynamic environments, macros, compilation vs. interpretation, concepts of
identity and equality, abstractions of fundamental types -- like numbers,
incremental compilation and dynamic linking, binding vs. assignment, object
systems, dynamic redefinition, MOPs, ...)
> Computing is not a static subject though. New topics appear and redefine
> aspects of computing. The web over the last few years, for instance, has
> produced a significant shift in computing. What Lisp needs to do is to make
> itself suitable for these new areas of computing. If Lisp can handle a new
> problem better than another language, a professor would have a stronger
> incentive to use it for teaching a class.
Um, I fail to see that the web should have produced any significant change
in computer science education. There are no fundamental new concepts that
come into play. OTOH, I wouldn't be surprised to learn that web technology
is a subject in many university curricula. P.T. Barnum would be _so_ proud.
>
> New paradigms in computing emerge on top of old ones though. The web is in
> some ways an abstracted networking interface dealing with the flow of
> information. Lisp has to have features for dealing with both of these
> elements readily available (though not necessarily standardized) to make it
> attractive for web programming. Database access often also turns out to be
> critical.
So, are you talking about education or industry?
>
> As far as I am concerned, Lisp appears to have missed the web bandwagon. I
> hope the next opportunity is not lost this easily.
Irrelevant. This is like saying that FORTRAN missed the OS implementation
bandwagon. (A side note: One of my colleagues recently pointed out to me
that a COBOL company has jumped on the web bandwagon.)
>
> Traditionally, for Lisp, AI had been its strength. As a graduate student in
> AI, I continue to use lisp. But AI is changing. AI here has been
> assimilated into the larger discipline of Intelligent Systems, and the
> variety of subjects we deal with, along with the techniques we use, has
> risen significantly. We now have to interface with vision, numerical
> methods, and so on. As a result, justifying the use of Lisp to do AI is
> also becoming more difficult. So, not only is Lisp not adapting to new
> techniques, it appears to be losing ground in some of its traditional
> strengths.
Are you omitting some important distinctions among levels of processing, or
maybe among areas of AI research? How can you make a blanket assertion that
Lisp is losing ground because researchers are choosing (presumably) a tool
that's matched to the task at hand? Twenty years ago, vision researchers
coded their systems in a variety of languages. No one predicted the death
of Lisp in the 1970s because image processing kernels were written in
assembly language.
>
> In short, from my perspective Lisp has lost a lot of ground in education. I
> don't really see what vendors can do about it. They can't predict what the
> Next Big Thing will be. The best they can do is provide tools and match the
> current commodity products. They can't convince a school or faculty to
> consider Lisp for teaching a class. But if Lisp is to have long term
> viability, it is absolutely essential that it be more than a bad memory
> that students come out of school with. This most definitely will be a long
> slow process.
Education may be broken... I see -- from the perspective of having
completed the formal portion of my education some twenty years ago -- a
trend away from teaching concepts in favor of teaching technologies and
skills.
Thanks to newer technologies, common tasks are becoming somewhat easier to
do. But the hard problems remain hard, and no visual- or domain specific-
language is going to make the hard problems any easier. More simply: a shiny
new tool is a joy to behold, but there's no substitute for knowledge.
The industry is getting more arcane, if anything. With the explosive
commercial growth of the industry, vendors are falling over each other to
get mindshare among programmers. By assigning new names to conventional,
well-established concepts, vendors cripple the ability of new programmers to
think in the more general terms. As a result, programmers often don't
understand the technology they're using except in the terms of the vendor's
private lexicon, and can't recognize either similarities or alternatives in
other approaches. They are, quite literally, unable to think outside of the
(vendor's) box.
>
> It seems right now that Lisp is mostly driven by those that have fond
> memories of the lisp machines. As impractical as they might have been (in
> terms of size and cost) they appear to have included a variety of cool
> concepts that inspired a lot of hackers. I didn't grow up with lisp
> machines. My impression of lisp is entirely from current environments, and
> the impression I have is that they are impenetrable black boxes that
> provide some really nice abstractions. Even as a believer I have trouble
> locating material to learn more about the environment I use and about lisp
> in general. This too must change.
>
> I don't know where we can go from here. I don't have a vision. The vendors
> certainly have their work cut out for them. But as a community I feel we
> have failed to keep lisp attractive, and have not been able to advance it
> sufficiently.
Consider the current state of the software industry. Development starts are
increasing in frequency, while project duration is decreasing. (Companies
believe that they must deliver new product at least once or twice a year to
remain in business.) New technologies are being announced at an increasing
rate by corporations and consortiums who believe it is in their best
business interest to establish standards. (Note: Standards, IMO, have
nothing to do with standardization and everything to do with market share.
Otherwise, standards would be much more carefully specified, there would be
far fewer of them, and the standards themselves would anticipate future
directions.)
Against this background, programmers toil to deliver products. My guess for
a project's chance of success, based upon personal experience and anectdotal
evidence, is in the range of 1:5 to 1:20, affected mostly by the corporate
culture. Knowing the odds of introducing a successful new project,
programmers will overwhelmingly choose to adopt a popular unproven
technology as the basis of any project, thereby _decreasing_ the project's
chance of success. Stupid? No, smart: even though the company fails, the
programmer is better positioned -- by virtue of experience with the newest
technology -- for the next job with a different employer.
If you take a socialist view of this situation, you can argue that
corporations have created this environment and are now paying the price for
their indifference to the workforce's collective desire for stability and
continuity. But this corporate screw-up, and the resulting impact on
profitability, is precisely what has created a market void.
Implementors have had thirty years to refine Lisp's core competencies. What
are they? Convenient abstractions for the programmer's use, good compilers,
best-in-class GC, integrated environment for development _and_ delivery,
etc. For applications which require these qualities to successfully deliver
a product, nothing else comes close.
It's easy to knock down straw men. You can always find some technology du
jour that Lisp doesn't support. So what? Pick the right combination of
tools and materials, and integrate. We should be building cathedrals, not
laying bricks.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
There are many ways to abbreviate something, but only one way not to.
Reading over what I had written, and the response I have received, I have
realized that my view is probably tainted by being at this one institution,
and that there are probably others where problems are not quite as acute.
With that said...
"David B. Lamkins" <········@teleport.com> writes:
> In article <···············@whizzy.cc.gatech.edu> , Sunil Mishra
> <·······@whizzy.cc.gatech.edu> wrote:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> >> But we also have traditionally turned students away by making the
> >> price too high. Nowadays, there are some free offerings that help a
> >> lot, but they will not help if they don't contain that all-important
> >> commodity baseline of software. Students get taught about networks.
> >> If you make them pay $3000 for network sockets libraries, Lisp will
> >> not be used in networks classes. Poof. Lost. Students need high-end
> >> tools, not low-end ones.
> >
> > I think Lisp vendors have to go beyond providing what exists today. They
> > have to be able to offer lisp as the means to study the Next Big Thing
> > effectively.
>
> IMO, there's little, if any, connection between the Next Big Thing and any
> particular technology. The Next Big This is defined by marketing and
> supported by consumer behavior.
Well, I was thinking of it in this way. New technologies and paradigms
build upon existing ones. I'm not talking about the Next Big Thing in terms
of marketing. I'm talking about it in terms of the type of problems that
can be solved, and the manner in which they are attacked. From that
perspective, the web is more than a gimmick, since it embodies a new way of
solving problems, and brings many more to the foreground. These include
sharing distributed documents, electronic commerce, security, privacy,
etc. As far as I can see, Lisp seems to have relatively little to say in
any of these areas. And without being in the fore, Lisp is going to remain
in a shrinking part of the software world.
> OTOH, Lisp has a very low profile in both marketing and market share. This
> is itself not necessarily bad. I don't believe that Lisp has to be a
> commodity in the software development community in order to remain viable.
> So long as it continues to address problems ignored by the "mainstream",
> Lisp will have a place.
Yes, Lisp has its niches. But do you find it acceptable that Lisp exist in
such a niche? I'd like to take some of Lisp's abilities and apply it to
some hard problems in domains I find interesting. Say I'm trying to figure
out what a person in front of a camera is doing. At some level I have to
have a vocabulary for describing the actions of my subject, and modifying
my beliefs about the person. Standard AI in some ways, but with many new
twists. This is a task I think Lisp is *very* well suited for.
But then I look at the tools I have available in Lisp for doing this kind
of processing. I don't think Lisp has all that much. So my choices are:
1. Construct an FFI.
2. Move to C or some other language that is more "acceptable".
So far I have been trying to do the former, because I fear memory
management in C/C++. Most people that have relatively little experience
with Lisp will probably not even *know* that lisp has an FFI, so Lisp will
not even be used for those problems for which it is so suitable. Moving to
C has another advantage, because I have no idea how to debug foreign code
when it is linked to Lisp.
This problem is particularly acute in school/research. All students work
independently, so there is little opportunity to spread the word to others
and show them what I can do in Lisp that is next to impossible in other
languages. In research it is far easier to move on to another problem that
is more tractable in a familiar language, and wait for another day for the
hard problems to become more tractable in the same language. There are
plenty of other interesting problems to work on in the mean time.
From my perspective, as is (or had been) happening with the Macintosh, Lisp
is becoming marginalized even in those areas where its core competencies
lie. As Kent has pointed out, I believe it is absolutely essential that
more attention be given to connectivity, and this feature be heavily
advertised.
> This is a good point. A quality educational institution will address the
> fundamentals, _and_ make a clear distinction between concept and
> implementation. Unfortunately, the institutions the ability to present a
> multiplicity of implementations as first- and second-generation computer
> companies merged or died in the 1970's. Later, Unix had the effect of
> homogenizing OS education because it was freely available to universities,
> who adopted it partly because of source availability, and partly because of
> budget considerations.
>
> But there's a flip side to this issue. What concepts are _not_ being taught
> because Lisp is inaccessible to universities? Why isn't there a reference
> implementation of Lisp that could be used to teach the concepts of dynamic
> programming environments in the same way that Unix served as a reference
> implementation for operating systems?
Yes, you are right. But I have to ask: How can we convince them (students
and faculty) that these topics are important? Most school curricula present
student with perhaps one opportunity to write a large program. Othewise
they hack through their classes writing small toy programs to solve small,
well understood problems. C works well enough in such situations. They will
never comprehend the power that Lisp provides if they stay within these
restricted domains.
My claim is that the most effective way to bring Lisp to the fore is to
make it an indispensable tool for solving some class of *emerging*
problems. It will take a long time for these problems to get distilled down
to some core ideas in computing and filter down to a graduate or
undergraduate class. But this is exactly what needs to happen to ensure
that Lisp continues to get exposure, in both "old" disciplines such as AI
and newer emerging areas. Lisp has to *appear* to be alive and well, not
just be alive and well.
> > Add to that how well entrenched C is in the OS and networking community,
> > and you will be hard pressed to convince a school to switch to Lisp for
> > teaching these subjects, no matter how good the environments get.
> >
>
> Again, I don't think there's a win-lose situation here. Lisp should be
> taught alongside other technologies for the things that it most clearly
> demonstrates. (A tentative list: automatic storage allocation, lexical and
> dynamic environments, macros, compilation vs. interpretation, concepts of
> identity and equality, abstractions of fundamental types -- like numbers,
> incremental compilation and dynamic linking, binding vs. assignment, object
> systems, dynamic redefinition, MOPs, ...)
Agreed. But, I have yet to see a class that deals with these subjects. Our
graduate level class for programming languages did not touch on most of
these issues. They are not yet in the fore. To take an extreme position,
they are solutions looking for a good problem.
Also, Lisp has these things. What if you wanted to teach them? Does Lisp
automatically also provide tools to teach these topics? I have no idea. I
would imagine this is where a free reference implementation with source
code would be most useful.
> Um, I fail to see that the web should have produced any significant change
> in computer science education. There are no fundamental new concepts that
> come into play. OTOH, I wouldn't be surprised to learn that web technology
> is a subject in many university curricula. P.T. Barnum would be _so_
> proud.
> > New paradigms in computing emerge on top of old ones though. The web is in
> > some ways an abstracted networking interface dealing with the flow of
> > information. Lisp has to have features for dealing with both of these
> > elements readily available (though not necessarily standardized) to make it
> > attractive for web programming. Database access often also turns out to be
> > critical.
>
> So, are you talking about education or industry?
Web technology is, thankfully, not a subject. But as I have pointed out
earlier, there are many issues that have come to the fore because of the
growth of the web. Without an appropriate set of tools Lisp is not going to
be an acceptable environment to study these issues. This is from the point
of view of research. In industry one has to be much more wary of licenses
and the like, which might change the picture a bit. I'm not going to say
any more, given my lack of industrial experience.
> > Traditionally, for Lisp, AI had been its strength. As a graduate student in
> > AI, I continue to use lisp. But AI is changing. AI here has been
> > assimilated into the larger discipline of Intelligent Systems, and the
> > variety of subjects we deal with, along with the techniques we use, has
> > risen significantly. We now have to interface with vision, numerical
> > methods, and so on. As a result, justifying the use of Lisp to do AI is
> > also becoming more difficult. So, not only is Lisp not adapting to new
> > techniques, it appears to be losing ground in some of its traditional
> > strengths.
>
> Are you omitting some important distinctions among levels of processing, or
> maybe among areas of AI research? How can you make a blanket assertion that
> Lisp is losing ground because researchers are choosing (presumably) a tool
> that's matched to the task at hand? Twenty years ago, vision researchers
> coded their systems in a variety of languages. No one predicted the death
> of Lisp in the 1970s because image processing kernels were written in
> assembly language.
Most of the folks here that I work with are not interested in levels of
processing. They are interested in construcing intelligent, interactive
environments, and the like. (There are some interested in planning and
design and other more traditional AI problems, but they remain relatively
hidden from the limelight.) I decided a while back that there cannot be any
"high level" AI without low level competencies. Now I'm digressing. I've
already pointed out earlier that if someone builds all their low level
infrastructure in one environment, they will probably not even pause to
think about switching environments when trying to work on a new set of
competencies.
The net effect, from my perspective, is that Lisp has relatively little
role in studying intelligent environments, even though it is probably a far
more suitable than C or C++ or Java beyond the low level processing. Even
one of the professors here studying design considered switching to Java
because he wanted to make an application net worthy. Lisp cannot afford
this kind of drain.
There is of course another way to look at this. I might simply have found
myself in an environment where low level hackers were trying to apply their
skills to building complex environments. I hope there are others out there
going in the other direction. That will make for a nice balance :-)
> > In short, from my perspective Lisp has lost a lot of ground in education. I
> > don't really see what vendors can do about it. They can't predict what the
> > Next Big Thing will be. The best they can do is provide tools and match the
> > current commodity products. They can't convince a school or faculty to
> > consider Lisp for teaching a class. But if Lisp is to have long term
> > viability, it is absolutely essential that it be more than a bad memory
> > that students come out of school with. This most definitely will be a long
> > slow process.
>
> Education may be broken... I see -- from the perspective of having
> completed the formal portion of my education some twenty years ago -- a
> trend away from teaching concepts in favor of teaching technologies and
> skills.
I would not go that far. There is still a strong desire to teach skills
here. At issue is what skills are considered important, and the tools used
to teach those skills. Lisp never comes up.
I just remembered a book I had seen in Barnes and Nobles. Written by some
professor, it pretended to cover the major trends in object oriented
languages, and variations within it. CLOS was absent.
> Thanks to newer technologies, common tasks are becoming somewhat easier to
> do. But the hard problems remain hard, and no visual- or domain specific-
> language is going to make the hard problems any easier. More simply: a shiny
> new tool is a joy to behold, but there's no substitute for knowledge.
I've seen that *a lot*. I would never give up the nice command line
debugger that Lisp has in exchange for a graphical debugger coming from the
C community. Graphics are, of course, useful at times.
> > I don't know where we can go from here. I don't have a vision. The vendors
> > certainly have their work cut out for them. But as a community I feel we
> > have failed to keep lisp attractive, and have not been able to advance it
> > sufficiently.
>
[ stuff deleted ]
> Implementors have had thirty years to refine Lisp's core competencies. What
> are they? Convenient abstractions for the programmer's use, good compilers,
> best-in-class GC, integrated environment for development _and_ delivery,
> etc. For applications which require these qualities to successfully deliver
> a product, nothing else comes close.
Schools don't require product delivery :-(
> It's easy to knock down straw men. You can always find some technology du
> jour that Lisp doesn't support. So what? Pick the right combination of
> tools and materials, and integrate. We should be building cathedrals, not
> laying bricks.
Agreed. Now, where do I start? :-)
Sunil
In article <···············@whizzy.cc.gatech.edu> , Sunil Mishra
<·······@whizzy.cc.gatech.edu> wrote:
[snip]
Sunil, thanks for the additional perspective on the educational process.
I'm trimming out most of that discussion simply because I have nothing to
add.
After reading through your reply a second time, two of your points struck me
as being important to this thread because (IMO) they get to the crux of the
matter; we should be thinking in terms of "Lisp must do" rather than "Lisp
must have":
> Well, I was thinking of it in this way. New technologies and paradigms
> build upon existing ones. I'm not talking about the Next Big Thing in terms
> of marketing. I'm talking about it in terms of the type of problems that
> can be solved, and the manner in which they are attacked.
and
> My claim is that the most effective way to bring Lisp to the fore is to
> make it an indispensable tool for solving some class of *emerging*
> problems. It will take a long time for these problems to get distilled down
> to some core ideas in computing and filter down to a graduate or
> undergraduate class. But this is exactly what needs to happen to ensure
> that Lisp continues to get exposure, in both "old" disciplines such as AI
> and newer emerging areas. Lisp has to *appear* to be alive and well, not
> just be alive and well.
The key phrases: "types of problems that can be solved" and "*emerging*
problems". I've been reading other postings on this thread that talk about
the technologies people would like to see added on to Lisp. What I don't
see is much (if any) discussion of the benefits of these technologies when
added to Lisp. (Perhaps "bolted onto Lisp" is a more accurate phrase, given
the amount of thought that appears to be going into some of these
requirements.)
I don't intend to offend anyone with that previous remark. But we really do
need to move away from the "bread and circus" mentality that tends to cause
discussions like this to degenerate into a never-ending list of wish lists.
A number of people have stated something like: "I wouldn't, or couldn't,
propose doing a project in Lisp unless Lisp had features X, Y, and Z _out of
the box_." I realize that certain political perceptions fuel this kind of
thinking. So I'm going to put on my "manager's hat" (note: I'm not really a
manager, but I occasionally play one on c.l.l. :) and ask an obvious
question: If Lisp makes you so productive, why can't you put together a
proof-of-principle prototype which either provides or works around the
missing features X, Y, and Z?
In other words, invest some of your _own_ time in the hope that you'll make
a convincing case in order to be able to champion a Lisp-based project
within your organization. After all, (still wearing that manager's hat) why
should I believe the undemonstrated assertions of one Lisp programmer in my
organization when I have vast hordes of Java and C++ programmers flooding my
desk with resumes? [Note: I _don't_ agree with this line of reasoning, but
I know that it happens. Which is part of the reason why I prefer not to be
a manager IRL.]
That's one approach. It will work best if you're good at reading between
the lines of a product's requirements (in other words, the lines that don't
say "must use technologies X, Y and Z"), or if you're fortunate enough -- as
very few engineers are -- to receive uninterpreted customer input regarding
a proposed product.
If you spend some time looking around, you'll find a plethora of libraries
and tools scattered all over the net; properly applied, these can make your
job easy. Yes, they are _not_ standardized. Yes, you may have to invest a
small amount of effort to make them useful for your particular purpose. But
then, how well have the implementations of the "popular" standards (C++,
Java, CORBA, ODBC, and all the MS pseudo-standards) withstood the test of
time? Call these standard if you like; they still look to me like moving
targets, and I have to redo a certain amount of "standards-based" code at an
alarmingly frequent interval. It would be nice if "standard" and "stable"
were somehow related...
My personal area of interest is network design and analysis. In that space,
there's code available to do most of the grunt work (e.g. SNMP monitoring,
database access, visual graph layout, various flavors of reasoning engines,
...). Not part of any standard library, not supported by any vendor, but
indispensable nonetheless.
Personally, I've learned to be very wary of tools that have come with toy
examples that look _almost_ like a product right out of the box. These tend
to overpromise and underdeliver. "Hey, Joe! Look at this cool web page I
made with VisualCruftMagic. Now all we have to do is write a little bit of
code and we'll have that warehouse inventory system running by next
Thursday."
Anyhow, getting back to the subject, what are the *emerging* problems that
can best be solved by Lisp? My personal favorite is knowledge-based
systems; these seem to be getting press coverage with increasing frequency.
Fraud detection, workflow analysis, design assistance, ... (Proponents of
knowledge-based systems are still _very_ careful not to mention AI.)
Another "emerging problem" is system integration -- as in operational
integration of legacy systems. For some examples of this kind of work, take
a look at what KTI (formerly BBTech) is doing with blackboard systems.
One more thing that comes to mind is rapid product -- not prototype --
delivery. Paul Graham's presentation at the conference talked about the
implementation and commercial success of the Yahoo! store (sorry, I forget
the original name of his company, before the acquisition) using CLISP. Yes,
this is a web application. But more importantly, IMO, the whole business
was put together by three guys in a walk-up _because_ they used Lisp. (I
imagine that if they had chosen C++ instead, they might have invented some
elegant design patterns and would still be hanging out in the walk-up,
lamenting the lack of investor interest. :)
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
There are many ways to abbreviate something, but only one way not to.
In article <·····················@news1.teleport.com>,
"David B. Lamkins" <········@teleport.com> writes:
> A number of people have stated something like: "I wouldn't, or couldn't,
> propose doing a project in Lisp unless Lisp had features X, Y, and Z _out of
> the box_." I realize that certain political perceptions fuel this kind of
> thinking. So I'm going to put on my "manager's hat" (note: I'm not really a
> manager, but I occasionally play one on c.l.l. :) and ask an obvious
> question: If Lisp makes you so productive, why can't you put together a
> proof-of-principle prototype which either provides or works around the
> missing features X, Y, and Z?
>
I think you've missed the point of Ken's posting. (Well, at least my
interpretation of it.) What's expected as a core minimum functionality is
being raised by things like Java. When you have to resort to things "scattered
all over the net" for this basic functionality, it really undercuts your claim
of how advanced Lisp is. "Wait a minute. Your telling me how great lisp is but
it doesn't come with X and Y and I have to pay extra for Z? And I have to pay
royalties for every product I ship? And you're the only one in my groupwho
knows lisp?" If you have your manager's hat on straight, the answer is "Are
you crazy?"
> If you spend some time looking around, you'll find a plethora of libraries
> and tools scattered all over the net; properly applied, these can make your
> job easy. Yes, they are _not_ standardized. Yes, you may have to invest a
> small amount of effort to make them useful for your particular purpose. But
> then, how well have the implementations of the "popular" standards (C++,
> Java, CORBA, ODBC, and all the MS pseudo-standards) withstood the test of
> time? Call these standard if you like; they still look to me like moving
> targets, and I have to redo a certain amount of "standards-based" code at an
> alarmingly frequent interval. It would be nice if "standard" and "stable"
> were somehow related...
I think your manager's hat slipped off. To managers, "standard" and "stable"
are independant variables with the more important one being "standard". Being
standard is about risk avoidance. If something doesn't work but it's a
standard, it's not the manager's fault, it's the standard's. Having someone or
something to place the blame on is a very important consideration. It's the
same force that makes management reluctant to use "libraries and tools
scattered all over the net". Who can they pass the blame onto when things
don't work out? Some anonymous person that you can't even find anymore? No,
the blame would fall upon him and his group for using unsupported software. It
doesn't matter if it might help solve his problems, the downside if it doesn't
work out is too great tobe risked.
Mike McDonald
·······@mikemac.com
From: Christopher R. Barry
Subject: Commercial software liability. (was Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <87zp5vlmqz.fsf_-_@2xtreme.net>
·······@mikemac.com (Mike McDonald) writes:
> Being standard is about risk avoidance. If something doesn't work
> but it's a standard, it's not the manager's fault, it's the
> standard's. Having someone or something to place the blame on is a
> very important consideration. It's the same force that makes
> management reluctant to use "libraries and tools scattered all over
> the net". Who can they pass the blame onto when things don't work
> out? Some anonymous person that you can't even find anymore? No, the
> blame would fall upon him and his group for using unsupported
> software. It doesn't matter if it might help solve his problems, the
> downside if it doesn't work out is too great tobe risked.
Just about any Microsoft license (and certainly others) disclaim just
as much liability as any free software license I've seen. There was a
thing on Slashdot about this a few months back. Some Microsoft
database thing had a serious bug that could cause data to be corrupted
in not-too-out-of-the-ordinary usage. The licensing terms prevented
companies from taking legal action (and there were significant
clean-up costs in some cases).
A number of lawyers jumped in to the discussion saying just how much
of the crap in those licenses was really enforcable. But still, the
point remains.
Christopher
[OT: By the way, it was recently posted in another group that
Microsoft is dumping your hardware ethernet address encoded in Unicode
into every Word .DOC file you save. I sent a thing to Slashdot about
it a few minutes ago. It will probably get posted (A lot of this
Pentium III ID number stuff is getting posted, and Microsoft has been
at it a lot longer apparently).]
From: Frank A. Adrian
Subject: Re: Commercial software liability. (was Re: Barriers to Lisp acceptance - a "survey" question)
Date:
Message-ID: <VK_C2.32183$rs2.9481550@client.news.psi.net>
We're not talking legal liability here, but career CYA type of liability.
Legal liability is difficult to ascertain (and enforce) almost anywhere in
software. But, in almost all organizations, an excuse of "It's those damn
Microsoft (or standard technology) tools," is much less likely to be met
with a response of "Then why did you use them?" than the statement "It's
those damn XXX tools." (where XXX can be filled in with any other vendor's -
or technology's - name). I don't like or condone this fact. It makes using
"non-standard" tools and tools by smaller vendors much more difficult than
it should be. Microsoft's tools' quality is not that great so as to make my
life easy by choosing them - in fact, I can safely say that there are many
better alternatives. Nonetheless, Microsoft has done a great job of
marketing where it counts - the level where people can break an underling's
career for NOT using their tools. That's why Adrian's first rule of
alternative tool use is: "Don't screw up."
faa
Christopher R. Barry wrote in message <·················@2xtreme.net>...
>·······@mikemac.com (Mike McDonald) writes:
>
>> Being standard is about risk avoidance. If something doesn't work
>> but it's a standard, it's not the manager's fault, it's the
>> standard's. Having someone or something to place the blame on is a
>> very important consideration. It's the same force that makes
>> management reluctant to use "libraries and tools scattered all over
>> the net". Who can they pass the blame onto when things don't work
>> out? Some anonymous person that you can't even find anymore? No, the
>> blame would fall upon him and his group for using unsupported
>> software. It doesn't matter if it might help solve his problems, the
>> downside if it doesn't work out is too great tobe risked.
>
>Just about any Microsoft license (and certainly others) disclaim just
>as much liability as any free software license I've seen. There was a
>thing on Slashdot about this a few months back. Some Microsoft
>database thing had a serious bug that could cause data to be corrupted
>in not-too-out-of-the-ordinary usage. The licensing terms prevented
>companies from taking legal action (and there were significant
>clean-up costs in some cases).
>
>A number of lawyers jumped in to the discussion saying just how much
>of the crap in those licenses was really enforcable. But still, the
>point remains.
>
>Christopher
>
>[OT: By the way, it was recently posted in another group that
>Microsoft is dumping your hardware ethernet address encoded in Unicode
>into every Word .DOC file you save. I sent a thing to Slashdot about
>it a few minutes ago. It will probably get posted (A lot of this
>Pentium III ID number stuff is getting posted, and Microsoft has been
>at it a lot longer apparently).]
In article <············@spitting-spider.aracnet.com> , ·······@mikemac.com
(Mike McDonald) wrote:
> In article <·····················@news1.teleport.com>,
> "David B. Lamkins" <········@teleport.com> writes:
>
>> A number of people have stated something like: "I wouldn't, or couldn't,
>> propose doing a project in Lisp unless Lisp had features X, Y, and Z _out of
>> the box_." I realize that certain political perceptions fuel this kind of
>> thinking. So I'm going to put on my "manager's hat" (note: I'm not really a
>> manager, but I occasionally play one on c.l.l. :) and ask an obvious
>> question: If Lisp makes you so productive, why can't you put together a
>> proof-of-principle prototype which either provides or works around the
>> missing features X, Y, and Z?
>>
>
> I think you've missed the point of Ken's posting. (Well, at least my
> interpretation of it.) What's expected as a core minimum functionality is
> being raised by things like Java. When you have to resort to things "scattered
> all over the net" for this basic functionality, it really undercuts your claim
> of how advanced Lisp is. "Wait a minute. Your telling me how great lisp is but
> it doesn't come with X and Y and I have to pay extra for Z? And I have to pay
> royalties for every product I ship? And you're the only one in my groupwho
> knows lisp?" If you have your manager's hat on straight, the answer is "Are
> you crazy?"
No, I understand the point. And I disagree.
You're arguing that a manager will prefer to optimize relatively small
recurring expenses for software acquisitions, upgrades and support. And
what if in so doing, (s)he increases the larger -- but less tangible --
costs of development salaries, lost time to market, customer support costs,
etc? Commercial development practices virtually guarantee that a manager
will behave in such a manner. The rush to market guarantees that no one
will keep track of life-cycle expenses. So the manager focuses on the
things that are controllable, like cost items that are down in the noise
dollar-wise, but can be tracked just by pulling an invoice. Can you say
"micro-management?"
I certainly agree with you that most managers behave in this manner. But I
don't approve of the behavior, and don't agree that the industry should
(continue to) cater to this style of management.
>
>> If you spend some time looking around, you'll find a plethora of libraries
>> and tools scattered all over the net; properly applied, these can make your
>> job easy. Yes, they are _not_ standardized. Yes, you may have to invest a
>> small amount of effort to make them useful for your particular purpose. But
>> then, how well have the implementations of the "popular" standards (C++,
>> Java, CORBA, ODBC, and all the MS pseudo-standards) withstood the test of
>> time? Call these standard if you like; they still look to me like moving
>> targets, and I have to redo a certain amount of "standards-based" code at an
>> alarmingly frequent interval. It would be nice if "standard" and "stable"
>> were somehow related...
>
> I think your manager's hat slipped off. To managers, "standard" and "stable"
> are independant variables with the more important one being "standard". Being
> standard is about risk avoidance. If something doesn't work but it's a
> standard, it's not the manager's fault, it's the standard's. Having someone or
> something to place the blame on is a very important consideration. It's the
> same force that makes management reluctant to use "libraries and tools
> scattered all over the net". Who can they pass the blame onto when things
> don't work out? Some anonymous person that you can't even find anymore? No,
> the blame would fall upon him and his group for using unsupported software. It
> doesn't matter if it might help solve his problems, the downside if it doesn't
> work out is too great tobe risked.
Just as there are different styles of programming, there are different
styles of management.
One -- the more common -- minimizes personal risk in the way you've
described. My cynical summary of this approach is this: "Don't think too
much about solving the real problem, because you probably won't succeed.
Instead, choose the approach that any 'reasonable' person in your position
would choose. That way you are blameless if you fail, because anyone else
would have failed the same way." I think that that this is the management
style to which you refer.
The other management approach -- thought by many in this industry to be the
stuff of myth -- accepts a challenge with the desire to succeed. These
managers evaluate everything that could help them achieve the desired
result. Sometimes they go with "standard", and with "stable" at other
times. They educate both their staff and their superiors as to what they
are attempting to accomplish by choosing a particular approach. If they
succeed, they usually succeed in a big way. And if they fail, they rarely
fail worse than their "keep a scapegoat handy" counterparts.
(BTW, in twenty years, working for six companies, reporting to more managers
than I can keep track of, I've had exactly two managers that used the latter
style.)
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Recently undead Isabelle to the archangel Gabriel in "The Prophecy II":
"So, you're keeping me alive because you don't know DOS?"
In article <·····················@news1.teleport.com>,
"David B. Lamkins" <········@teleport.com> writes:
> In article <············@spitting-spider.aracnet.com> , ·······@mikemac.com
> (Mike McDonald) wrote:
> I certainly agree with you that most managers behave in this manner. But I
> don't approve of the behavior, and don't agree that the industry should
> (continue to) cater to this style of management.
Ahh, you're describing what should be, not what is. I agree with this by the
way. Unfortunately, I have a very small influence on my manager's behavior. So
until I get appointed Benevolent Dictator, I'm probably going to have to deal
with this type of manager.
> Just as there are different styles of programming, there are different
> styles of management.
Didn't mean to imply there weren't others. Just that this seems to be the
most prevelant, in my experience.
> The other management approach -- thought by many in this industry to be the
> stuff of myth -- accepts a challenge with the desire to succeed. These
> managers evaluate everything that could help them achieve the desired
> result. Sometimes they go with "standard", and with "stable" at other
> times. They educate both their staff and their superiors as to what they
> are attempting to accomplish by choosing a particular approach. If they
> succeed, they usually succeed in a big way. And if they fail, they rarely
> fail worse than their "keep a scapegoat handy" counterparts.
>
> (BTW, in twenty years, working for six companies, reporting to more managers
> than I can keep track of, I've had exactly two managers that used the latter
> style.)
In my 25 years, I've had one. I think that's what the refer to as
"statistically insignificant". :-)
Mike McDonald
·······@mikemac.com
From: David Combs
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <dkcombsF7y9Bu.DnG@netcom.com>
Re "important concepts maybe missed without lisp".
What about "matching", in general.
How do schools teach this concept without something
like lisp?
From: Robert Monfera
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36D9A539.D125FC52@fisec.com>
Kent wrote:
ODBC connectivity, which is absent in LWW 4.1 Professional, but is
available as part of the Enterprise package (which is reasonably priced,
_provided_ I also need CORBA, Prolog and KnowledgeWorks).
ODBC was part of the LWW 4.0.1 Professional edition, which was a MAJOR
factor when I selected the tool.
> I've focused on sockets mostly as an example of a problem. I added
> mention of runtime licenses to show it's not unique. But I'm sure there
> are others I'm not mentioning--maybe others will contribute things
> they think are commodities but not being treated as such.
Two comments and a half to KMP's post.
1 - it is music for my ears. 1/2 Why can't I be so articulate?
2 - What makes you thinks that the vendors will accept to release
compatible socket packages and CORBA packages?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Will Fitzgerald
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7be3je$pu3@news.net-link.net>
Kent M Pitman wrote in message ...
>
> (4) You have to relate what you do to a standard paradigm.
>
> Saying that Lisp is different is almost itself fatal now. There
> has been a qualitative shift in the market for "connectivity" and
> there is now a burden on vendors to show they can connect. Lisp
> must line up its connect points very prominently and show how "the
> same" it is before it can pronounce the power of its difference.
> That's a burden, but the burden of looking incompatible (like the
> VHS/Betamax fiasco for video tape) must be avoided. This isn't about
> parens because they are not "connective". This is about sockets,
> CORBA, COM and all the others. Yes, they are there but they are
hidden.
>
>
>One concrete suggestion for the vendors to ponder:
>
>It has occurred to me of late that the best thing that Lisp could do is to
>just make CORBA and COM and ODBC and other stuff they presently charge
>premiums for be part of the standard offering and say "Lisp is the language
>for connectivity". It seems to me almost senseless to talk about Lisp as
>having these things when it doesn't come with the product. That's what
made
>ANSI CL such a win in its day--C defined standard libraries but there was
no
>expectation that you actually GOT those libraries, so in practice all C
>implementations were different. Lisp was like getting standard libraries
>and the assurance you really had them as part of the language, which is why
>the language is so big. What we need to do is raise the bar and say that
>you really get all of that stuff in the language and put the pressure on
>other languages to bring down the cost of their stuff. If CORBA is to be
>ubiquitous, it must be affordable. Lisp has a chance to get ahead of the
>game and be the place that affordability is most easily had. In a few
>years, after the other community has extorted money out of everyone who
will
>pay high CORBA costs, the price will fall and Lisp people will have to
>charge less for CORBA too, but it will no longer be a reason for people to
>prefer Lisp over other things. These are gambles that vendors might take,
>but if you take no gambles, you mostly do not win. The trick is to manage
>the gambles as well as you can, making them into sciences, not to avoid
them
>as if they were the plauge.)
>
>If Lisp were the vehicle of choice to get flexible and powerful
connectivity
>at a cheap price, it would be a force to be reckoned with. If instead for
>every such thing that it's gone to the trouble to make, it makes it the
same
>price or higher as the "commodity languages", where is the incentive to use
>Lisp over a commodity. If you re-read my story about RCN above, you'll see
>that people fear change, and that if you offer them the same functionality
>at same or higher price, they'll have no incentive to switch because in the
>end fear of risk, of differentness, of change, etc. will win the day and
>inertia will leave people in the commodity languages.
>
In my recent experience, it is just these connectivity issues that have
caused me the most headaches. I wanted to write Lisp that standardly
supported sockets and threading; I also could really use a Lisp that
standardly supported the object standards like CORBA and COM. For other
projects, I've wanted ODBC.
Java has all of these things, of course, pretty much in a standard way.
But I'm also excited about things happening in the Scheme world. First,
there are lots of good quality Scheme implementations, many freely
licensable. Second (related to the first), is that Scheme is small enough to
be embedded into other applications. Third, various providers are working on
socket, threading, object support, ODBC support, etc. Fourth, there's a new
"SRFI" (Scheme Request for Implementation) process that provides one way for
standard ways of doing things to be supported outside of the 'official'
pathways; see: <http://srfi.schemers.org/>.
For example, the MzScheme project at Rice University
<http://www.cs.rice.edu/CS/PLT/packages/mzscheme/>, provides a very nice
multi-platform (Unix, Windows, Mac) Scheme implementation which includes
some basic Scheme extensions (e.g., structures and exceptions) as well as a
very nice thread implementation and TCP/IP support. It can call or be called
by C/C++ applications. COM support, I hear, is coming soon. Debugging is
hard (I actually use a subset of Scheme in Lisp to write code under MCL),
but that's apparently changing, too.
On Sun, 28 Feb 1999, Kent M Pitman wrote:
>
>To my knowledge, the sockets stuff is not part of the Allegro personal
>edition and not sold separately... And even if I don't think J++ is really
Java, I can afford to buy Symantec Visual Cafe on >top of that and STILL not be
up to the $3000 line franz wants for its >professional edition to get sockets
(and admittedly other stuff, but stuff >I don't presently need and can't elect
not to buy).
I think we should recognize that, to its great credit, Franz has made
freely available on the Linux platform uncrippled versions of ACL 4.3, 5.0
(which include both socket and MP libraries). I am endeavoring to produce a
tangible prototype before making the "case for Lisp" to management; my work
would be near impossible without ACL on Linux (we're a UNIX shop), due to the
costs you've mentioned.
I'm not disputing your reasoning, just want to give credit where credit is due.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···········@fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
On Sat, 27 Feb 1999, Don Geddis wrote:
>In article <····················@news.mindspring.com>, David E. Young wrote:
>
>> So, problems. From a "language standard" perspective, I believe a
>> significant shortcoming with Lisp is the omission of basic
>> inter-process communication facilities ("sockets") and a standard
>> threading ("process") interface. Java provides both, to its credit,
>> making that platform attractive to folks building server-class
>> software. In my opinion, it simply isn't any longer acceptable to fill
>> a system with platform-specific, conditionally evaluated code.
>
>Perhaps you think it's the same level of "ugly", but all you need is
>vendor-specific code. If you adopt Franz's Allegro CL, for example, as you
>appear to have done, you can easily use their cross-platform modules for
>sockets, threads, and FFI.
>
>It's not quite as good as being the language definition (like for Java), but
>still it isn't "platform-specific, conditionally evaluated code" either.
Hello Don. You're correct, of course; I can (and do) use vendor-specific code
for both IPC and threads. However, having these features as part of the
language would allow engineers (and managers) to hedge their bets in the event
their favorite Lisp vendor meets an untimely end.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···········@fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3129294462194158@naggum.no>
* David E. Young <········@computer.org>
| Hello Don. You're correct, of course; I can (and do) use vendor-specific
| code for both IPC and threads. However, having these features as part of
| the language would allow engineers (and managers) to hedge their bets in
| the event their favorite Lisp vendor meets an untimely end.
but note that this untimely end is more likely to occur the more people
reject to buy because of a fear of it, the more people bitch and moan
about not getting everything for free, and the more people remove the
incentive to help people who aren't going to pay for it immediately.
in all this clamor for free stuff, I don't see any answers to the very
timely question "why would _I_ want to do that?" that people who might
want to give away stuffer others want would have to get a good answer to.
I get a little depressed when so few people are ready to _contribute_
free stuff before they _want_ things. if you want a standard socket
interface and it doesn't exist, go ahead and _write_ it, damnit.
[ this has not specifically been directed at David. ]
#:Erik
Erik Naggum <····@naggum.no> writes:
> * David E. Young <········@computer.org>
> | Hello Don. You're correct, of course; I can (and do) use vendor-specific
> | code for both IPC and threads. However, having these features as part of
> | the language would allow engineers (and managers) to hedge their bets in
> | the event their favorite Lisp vendor meets an untimely end.
>
> I get a little depressed when so few people are ready to _contribute_
> free stuff before they _want_ things. if you want a standard socket
> interface and it doesn't exist, go ahead and _write_ it, damnit.
Hello Erik. In principle, I agree with you. However, perhaps you'll
concede that standardized thread and IPC libraries are less a desire
for "free stuff" and more an enhancement that will make Lisp more
attractive to a larger community of developers.
Sigh. I make these comments only because I love Lisp -- for its power,
elegance and tremendous productivity increase -- and want to see it
thrive. Building software in Lisp simply makes my job *fun*.
>
> [ this has not specifically been directed at David. ]
Thanks.
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···········@fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> I get a little depressed when so few people are ready to _contribute_
> free stuff before they _want_ things. if you want a standard socket
> interface and it doesn't exist, go ahead and _write_ it, damnit.
I did. http://www-aig.jpl.nasa.gov/home/gat/ftp/sockets.tar.gz
contains socket code that works under Allegro CL for both Solaris
and Linux. It's free.
E.
From: Paolo Amoroso
Subject: CL Request for Implementation? [Was: Re: Barriers to Lisp acceptance - a "survey" question]
Date:
Message-ID: <36da4b51.4026275@news.mclink.it>
On Sat, 27 Feb 1999 14:26:10 -0500, David E. Young <········@computer.org>
wrote:
> Now, language standards being what they are (i.e. difficult to augment
> in a timely fashion), I would suggest the major Lisp vendors get
> together and devise a nice, platform-neutral, CLOS-based API for
> threads and sockets. Quickly. While there's still time. [while they're
> at it, a standard FFI would be nice too, but perhaps that's asking too
> much right now]. This would allow the rest of us to build clean,
The Scheme community has devised the Scheme Request for Implementation
(SRFI; http://srfi.schemers.org/) process to quickly evolve the language
for practical uses. If I get things right, this strategy is orthogonal to
traditional standardization efforts.
Would a similar "CLRFI" be useful and appropriate for Common Lisp? Would it
make sense from the technical and market points of view? Are vendors likely
to support it?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Christian Nyb�
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4yogmlgg14.fsf@smtp.nhh.no>
Kent M Pitman <······@world.std.com> writes:
> Anyway, I'm interested in doing a reality check on my present perceptions of
> how Lisp is presently hampered in acceptance.
What's the aim, or nature, of this `acceptance'?
--
chr
In article <··············@smtp.nhh.no>,
"Christian Nyb�" <·······@stud.nhh.no> writes:
> Kent M Pitman <······@world.std.com> writes:
>
>> Anyway, I'm interested in doing a reality check on my present perceptions of
>> how Lisp is presently hampered in acceptance.
>
> What's the aim, or nature, of this `acceptance'?
For me, the goal of wider acceptance of Lisp is to make it easier for me to
use Lisp in the systems I create, thereby increasing my enjoyment of my work.
When I got to use LispMs, we weren't coding, we were solving problems. With
C/C++, we seldom solve problems because were too busy tracking down malloc()
errors in Motif. Writing the same old code in the same old way for so long is
just plain boring and a waste of one's life.
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkj3e3uww95.fsf@tfeb.org>
"Christian Nyb�" <·······@stud.nhh.no> writes:
> What's the aim, or nature, of this `acceptance'?
To make there be enough Lisp jobs that I can be paid to do Lisp stuff
rather than what I do now, and also not have worry that having done
Lisp stuff is going to look bad on my CV in future.
Well, that's what *I* want, anyway.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> "Christian Nybø" <·······@stud.nhh.no> writes:
>
> > What's the aim, or nature, of this `acceptance'?
>
> To make there be enough Lisp jobs that I can be paid to do Lisp stuff
> rather than what I do now, and also not have worry that having done
> Lisp stuff is going to look bad on my CV in future.
Get out of the software industry.
Find a problem that you want solved. Not only will you be allowed to
solve it in Lisp, but you won't have to deal with all the brain damage
that is the software industry, no "software engineers", no managers.
You might even do something useful besides propogate the upgrade cycle
of some product line.
Do it as a startup that you own, or do it by day and be a waiter at
night. Construction work pays pretty well, and manual labor definetly
clears the mental pallate.
Or you could be a "white russian" hanging out on c.l.l all day,
complaining about how noone recognizes your legacy, collecting a
couple of ulcers, and stroking your apathy pet.
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
Craig Brozefsky <·····@red-bean.com> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> >
> > To make there be enough Lisp jobs that I can be paid to do Lisp stuff
> > rather than what I do now, and also not have worry that having done
> > Lisp stuff is going to look bad on my CV in future.
>
<some stuff I wrote>
>
> Or you could be a "white russian" hanging out on c.l.l all day,
> complaining about how noone recognizes your legacy, collecting a
> couple of ulcers, and stroking your apathy pet.
I would like to just clarify that I did not mean to imply that Tim was
sitting here stroking his apathy pet and collecting ulcers like
baseball cards. That comment was not directed at any person in
particular.
--
Craig Brozefsky <·····@red-bean.com>
Less matter, more form! - Bruno Schulz
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjaexty0ir.fsf@tfeb.org>
Craig Brozefsky <·····@red-bean.com> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > "Christian Nyb=F8" <·······@stud.nhh.no> writes:
> >
> > > What's the aim, or nature, of this `acceptance'?
> >
> > To make there be enough Lisp jobs that I can be paid to do Lisp stuff
> > rather than what I do now, and also not have worry that having done
> > Lisp stuff is going to look bad on my CV in future.
>
> Get out of the software industry.
That's OK, I'm not in it.
> Do it as a startup that you own, or do it by day and be a waiter at
> night. Construction work pays pretty well, and manual labor definetly
> clears the mental pallate.
>
So does system admin, and it pays better. And I can say with some
confidence that TFEB.ORG Ltd's preferred language is Lisp.
Seriously, what I meant was that I would like it to be the case that I
could do Lisp stuff *without* having to go off and do it on my own.
I'd kind of like to get incredibly rich founding some company, but I
probably haven't got what it takes, and a lot of the time I would like
just to have a job which I enjoy reasonably much so I can do other
(non computer related) stuff the rest of the time. Of course the
software industry may be a bad one to choose if that's the kind of
life I'd like, and not being able to do Lisp is far from the only
problem with it. I just hope that if people became able to make
rational decisions about languages then perhaps other things would
become less insane too.
--tim
What barriers have people recently seen first-hand to Lisp's
acceptance in
their own working experience at their present or some recent
organization?
How would you prioritize those in terms of how "fatal" they are (to
use
Mike's term)? Any obvious things the vendors could/should be doing
to fix
them? If you have had success getting past them, what strategies
have you
used? If you could change just one thing about Lisp itself or about
some
Lisp vendor's implementation or packaging, what would it be? I
don't mean
this to be a checklist of questions to answer but rather a way of
getting
you started on an essay about the general topic. I fear a set of
crisp
questions would lose some important truth between the lines.
Hi Kent! My story is not too exciting, but it is applicable. I work
for a division of Texas A&M University located at the UT Dallas campus.
We have a copy of Harlequin LispWorks for Windows (unfortunately, all of
our systems are Windows-based) that we use primarily to run our web
server, under CL-HTTP (http://nanofab.utdallas.edu). The boss agreed to
the CL-HTTP idea, with only minor fussing, but since then has been
colder to the idea of extending our use of Lisp to more complex things
(though we do also have a primarily web-based cleanroom security system
going as well); he doesn't really seem to like the idea of using it for
direct equipment-control operations (preferring that we use stuff like
HP VEE). His primary concerns seem to be as follows:
1/ He sees Lisp as being a rather large hammer for the job, I guess.
I talk to
him about how powerful Lisp is, and what all these people around
the world are
using Lisp for in sophisticated projects; he responds with "well,
we don't
really need a really sophisticated tool like that around here, all
of our stuff
can be adequately handled by C++ or HP VEE".
2/ He is worried about getting stuck with a bunch of code that he
can't do
anything with because noone besides me knows Lisp (in his
perception).
I have explained to him that there are plenty of Lisp people
around, even in
the Dallas area, if he just knows where to look. The problem is,
very few
of them would work for him at public-university wages the way I do.
For web-based stuff, he is basically willing to use Lisp out of respect
for my
computer skills, as long as he doesn't feel threatened by the
possibility that I might get hit by a bus or something. I guess he
feels that most of the web-based stuff he could get easily re-written in
Java or whatever if needed.
So at least in my case, I think what would help most is if Lisp
programmers were more of a commodity item; of course, that's pretty much
impossible the way things are currently going.
As far as changes to Lisp itself that I'd like to see, I think they were
mostly covered by the discussion at the Lisp conference. The only thing
that noone brought up at the conference that I'd really like to see is
some sort of constraints-based programming system (such as Jeffrey Mark
Siskind's Screamer system, or the system described in Steele's doctoral
thesis -- I don't know where to get an implementation for that though,
so Screamer is probably the best choice for a place to start). I think
that constraint-based programming is a key technology for the future of
programming languages. We need to have those kind of capabilities
integrated into the language. Of course, on the other hand, all of that
is currently (as far as I know) way too experimental to be considered
for standardization.
As far as particular implementations: CMUCL needs a real GC and a better
debugger. Harlequin for Windows needs better integration with Windows
and an easy way to get a listener even when it is running as a service
(you cannot use the Podium when it is running as a service). Franz
needs to drop some of the more ridiculous aspects of their license (like
the 15% royalty requirement). Symbolics needs to build new hardware and
blow everyone else away...again.
Also, we need some sort of free Netsrape/Internet Exploiter plug-in that
runs Common Lisp, and some cool "applets" written using it. If we have
a serious competitor to Java among the "applet" crowd, then that could
get Common Lisp a lot more good exposure.
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87iucsk9a9.fsf@2xtreme.net>
Daniel Finster <··@nanofab.utdallas.edu> writes:
> As far as particular implementations: CMUCL needs a real GC and a better
> debugger.
The GC ain't too bad... what _really_ needs work is
PCL/CLOS/MOP....
What are your complaints specifically about the debugger? It does a
superb job of letting you step through and debug compiled code. Have
you read all the documentation for its commands and the compiler
options? Or are you refering to the Motif debugger interface? Yeah,
that has a few issues....
> Symbolics needs to build new hardware and blow everyone else
> away...again.
Fat chance. It would be nicer if Intel and major processor vendors
would some time in the future aknowledge Lisp and put better support
for type-tagging and checking in hardware. This would certainly help
out Smalltalk and some other languages and even Java.
> Also, we need some sort of free Netsrape/Internet Exploiter plug-in
> that runs Common Lisp, and some cool "applets" written using it. If
> we have a serious competitor to Java among the "applet" crowd, then
> that could get Common Lisp a lot more good exposure.
Writing a CL plugin for Netscape means:
1. A kinda large Lisp runtime dumped with compiler that will be too
big to ever make it into the main Netscape distribution, and will mean
a large, inconvenient download to many which will leave web developers
reluctant to use it.
2. The Netscape PluginSDK gives you an almost standard API for
Windows, Unix and Mac, though you are writing completely
platform-dependant code to load into Netscape. And if your Lisp does
Green threads instead of OS native, it is much more tedious to
properly implement the plugin. And currently none of Unix Lisps I know
of do OS native threads.
3. You have to copy rather large CL source files over the network
first and then compile them on the plugin client, and they may then
execute with absolutely no security. If you compile them first then
you have to provide binaries for every platform you plan to have your
plugin run on.
4. If your plugin uses any kind of GUI, well, there is no standard way
to do a GUI in ANSI CL so you must also write/port a GUI library to
all of the platforms unless you only want your plugin to only run
under one specific vendor's Lisp.
It would be much better to compile to Java byte code, but this is a
pretty involved task and I don't think there are any takers.
I short while back I download ACL for Windows Lite to try out their
plugin thingy but it didn't include this damned "lnkacl.dll" file I
needed to run the sucker. Bummer.
Christopher
From: Steve Gonedes
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <m2g17wqogn.fsf@KludgeUnix.com>
······@2xtreme.net (Christopher R. Barry) writes:
< Fat chance. It would be nicer if Intel and major processor vendors
< would some time in the future aknowledge Lisp and put better support
< for type-tagging and checking in hardware. This would certainly help
< out Smalltalk and some other languages and even Java.
I think I read on Intel's web sight that the P6 and some versions of
the pentium have support for a 36 bit addressing mode or some such. I
didn't look into it because the software to enable it was for windows
NT only (I think). I believe it was trying to address the 4 gig
limitation (gettin' ready for the terraserver probably?) that PCs
currently have.
There is the `jo' instruction, which is very nice (jump on overflow)
and some other neat things with Intel processors. They're just damned
with backward compatibility.
< > Also, we need some sort of free Netsrape/Internet Exploiter plug-in
< > that runs Common Lisp, and some cool "applets" written using it. If
< > we have a serious competitor to Java among the "applet" crowd, then
< > that could get Common Lisp a lot more good exposure.
<
< Writing a CL plugin for Netscape means:
<
< 1. A kinda large Lisp runtime dumped with compiler that will be too
< big to ever make it into the main Netscape distribution, and will mean
< a large, inconvenient download to many which will leave web developers
< reluctant to use it.
Who would download an entire compiler to run a web applet? Why does
the lisp compiler need to be transfered? Can't it be used to generate
some active-x or something? I mean, I seriously doubt that all these
scripting languages are really sending the interpreter and all. What
kind of web applets are popular? What do they do? Animated jpegs and
forms processing? I don't think many people use the internet for
read-radio yet (could be wrong though)? Just curious - don't know much
about web programming (just sockets and a little http).
< 2. The Netscape PluginSDK gives you an almost standard API for
< Windows, Unix and Mac, though you are writing completely
< platform-dependant code to load into Netscape. And if your Lisp does
< Green threads instead of OS native, it is much more tedious to
< properly implement the plugin.
Why is it more difficult to use threads that the operating system
schedules than threads that the lisp schedules?
< And currently none of Unix Lisps I know of do OS native threads.
With OS level threads you lose the ability to use coroutines, or maybe
more specifically, you lose the ability to control the process from
withing the lisp (hence os threads). What do os threads enable you to
do with Lisp that can't be done without them? I would think that
having multi-processes inside the lisp is very important; what can the
operating system do with your lisp code that the compiler can't
though? Just curious, as I've never used os threads and don't know
much about them.
< 3. You have to copy rather large CL source files over the network
< first and then compile them on the plugin client, and they may then
< execute with absolutely no security. If you compile them first then
< you have to provide binaries for every platform you plan to have your
< plugin run on.
Isn't security an operating system issue? Why would you use a general
purpose programming language for something like this anyway? What does
active-x and COMM do? They must have found a solution. Don't know what
that is though, I dunno much about this stuff, just curious now that
you mentioned it.
< 4. If your plugin uses any kind of GUI, well, there is no standard way
< to do a GUI in ANSI CL so you must also write/port a GUI library to
< all of the platforms unless you only want your plugin to only run
< under one specific vendor's Lisp.
This is annoying. I don't care for the current available GUIs though.
The windows looks neat, but it's supposed to be a bitch to program
with (dunno for sure, never tried). I have found X to be somewhat
involved as well. There is no way to ensure a consistent look and/or
feel in X, I would guess that this doesn't alleviate any of the
complications of user interface design.
< It would be much better to compile to Java byte code, but this is a
< pretty involved task and I don't think there are any takers.
Why not just send text-files? They're supposedly easier to read.
[That was a joke, just thought I would mention it in case I was the
only one to find it funny.]
< I short while back I download ACL for Windows Lite to try out their
< plugin thingy but it didn't include this damned "lnkacl.dll" file I
< needed to run the sucker. Bummer.
The gui builder is certainly neat though. Took me a while to get used
to it; just loved the inspector though.
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87emngji67.fsf@2xtreme.net>
Steve Gonedes <········@worldnet.att.net> writes:
> Who would download an entire compiler to run a web applet?
> Why does the lisp compiler need to be transfered?
> Can't it be used to generate some active-x or something?
> What kind of web applets are popular? What do they do? Animated
> jpegs and forms processing?
> Why is it more difficult to use threads that the operating system
> schedules than threads that the lisp schedules?
> What do os threads enable you to do with Lisp that can't be done
> without them?
> what can the operating system do with your lisp code that the
> compiler can't though?
> Isn't security an operating system issue?
> Why would you use a general purpose programming language for
> something like this anyway?
> What does active-x and COMM do?
[...]
"Daddy, why do sleep?"
"Because our minds and bodies get tired, and we need to rest."
"Why?"
"Because we run around all day doing work, and thinking."
"Why?"
"So daddy can pay the bills, and feed you and put you through
school"
"Why?"
"So that you have an education, and don't die from starvation."
"Why?"
"Because daddy loves you."
"Why?"
"Because your daddy's child."
"Why?"
"Because mommy and daddy and God made you."
"Why?"
"Daddy doesn't know why."
"Why?"
...
Christopher
From: Raymond Toy
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4niucsaqvw.fsf@rtp.ericsson.se>
>>>>> "Steve" == Steve Gonedes <········@worldnet.att.net> writes:
Steve> I think I read on Intel's web sight that the P6 and some
Steve> versions of the pentium have support for a 36 bit addressing
Steve> mode or some such. I didn't look into it because the software
Steve> to enable it was for windows NT only (I think). I believe it
Steve> was trying to address the 4 gig limitation (gettin' ready for
Steve> the terraserver probably?) that PCs currently have.
I'm not exactly sure what this "36-bit addressing" is, but 386's
and up have always had 48-bit addressing capability. Remember the
segment registers on the 8086, '186, and '286? They're still there.
I don't think anyone uses them anymore.
Ray
In article <··············@KludgeUnix.com> , Steve Gonedes
<········@worldnet.att.net> wrote:
[snip: processor ISA stuff]
>
> < > Also, we need some sort of free Netsrape/Internet Exploiter plug-in
> < > that runs Common Lisp, and some cool "applets" written using it. If
> < > we have a serious competitor to Java among the "applet" crowd, then
> < > that could get Common Lisp a lot more good exposure.
> <
> < Writing a CL plugin for Netscape means:
> <
> < 1. A kinda large Lisp runtime dumped with compiler that will be too
> < big to ever make it into the main Netscape distribution, and will mean
> < a large, inconvenient download to many which will leave web developers
> < reluctant to use it.
>
> Who would download an entire compiler to run a web applet? Why does
> the lisp compiler need to be transfered? Can't it be used to generate
> some active-x or something? I mean, I seriously doubt that all these
> scripting languages are really sending the interpreter and all. What
> kind of web applets are popular? What do they do? Animated jpegs and
> forms processing? I don't think many people use the internet for
> read-radio yet (could be wrong though)? Just curious - don't know much
> about web programming (just sockets and a little http).
Nowadays, interpreters come with the OS and/or the browser. There's no need
to download anything. Oh, wait, every time I visit a web site that uses
*yet another multimedia format*, the browser invites me to download an
executable plugin. Hmm, I guess there's a solution to _that_ problem.
[snip: threads stuff]
>
> < 3. You have to copy rather large CL source files over the network
> < first and then compile them on the plugin client, and they may then
> < execute with absolutely no security. If you compile them first then
> < you have to provide binaries for every platform you plan to have your
> < plugin run on.
>
> Isn't security an operating system issue? Why would you use a general
> purpose programming language for something like this anyway? What does
> active-x and COMM do? They must have found a solution. Don't know what
> that is though, I dunno much about this stuff, just curious now that
> you mentioned it.
This kind of begs the question, doesn't it? You assume that because
Active-X and COM exist, they must have solved the security problem,
otherwise they wouldn't exist? What's you IP address (hee hee)?
[snip: GUI stuff]
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
((lambda (x) (list x (list 'quote x)))
'(lambda (x) (list x (list 'quote x))))
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjzp62vg0z.fsf@tfeb.org>
Steve Gonedes <········@worldnet.att.net> writes:
> With OS level threads you lose the ability to use coroutines, or maybe
> more specifically, you lose the ability to control the process from
> withing the lisp (hence os threads). What do os threads enable you to
> do with Lisp that can't be done without them? I would think that
> having multi-processes inside the lisp is very important; what can the
> operating system do with your lisp code that the compiler can't
> though? Just curious, as I've never used os threads and don't know
> much about them.
Multiprocessor support, in a nutshell.
And, I think that's my answer to Kent too. I want a multiprocessing
API for CL that it is clearly possible to make run on the kind of
commodity SMP machines that exist now, and that I'm sure will continue
to exist for a good number of years since the big database people want
them. At LUGM98 one of the vendor people argued forcefully that this
was too hard to do, and I just reject that out of hand. There are
obvious issues with locking for things like INTERN, and I'm sure many
other places too, but those need to be overcome. I'd be happy for
them to be overcome in a fairly low-level way -- it doesn't have to be
a complete `do the right thing' solution, it just needs to be enough
to build one on top of if you want to (after all, Lisp is good at
that).
(And I'm not asking that all the vendors support SMP machines, just
that the multiprocessing support doesn't *rule out* support for SMP
machines. I hope that the market will deal with the rest ...)
And I think it's a barrier to acceptance because an obvious place for
Lisp is behind web servers, and big web servers need SMP machines so
they can scale.
Network stuff is a smaller barrier, because everyone has it, and it's
usually just sockets wrapped up a little, so it's not such a big deal
to put a standard layer on top of it.
--tim
PS SMP = shared memory processor, which may not be clear in this
context, sorry.
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4iucqz94p.fsf@beta.franz.com>
[ I rearranged the order of presentation slightly ]
Tim Bradshaw <···@tfeb.org> writes:
> PS SMP = shared memory processor, which may not be clear in this
> context, sorry.
In my experiences, SMP has stood for "Symmetric MultiProcessor" instead.
This is a form of shared-memory mutiprocessor architecture, but it is
not the only one; it is actually harder than those setups which have
symmetry (like a master/slave combination) because memory modifications
come from any machine at any time, and thus must be properly serialized.
> Steve Gonedes <········@worldnet.att.net> writes:
>
>
> > With OS level threads you lose the ability to use coroutines, or maybe
> > more specifically, you lose the ability to control the process from
> > withing the lisp (hence os threads).
We agonized over this for a long time, and I think our solution gives
adequate control. In fact, our stringent requirements on the os-threads
is one of the reasons why we are finding so many bugs in many threads
implementations.
> > What do os threads enable you to
> > do with Lisp that can't be done without them? I would think that
> > having multi-processes inside the lisp is very important; what can the
> > operating system do with your lisp code that the compiler can't
> > though? Just curious, as I've never used os threads and don't know
> > much about them.
>
> Multiprocessor support, in a nutshell.
This is true, but also os-threads allows you to run non-lisp
processes without blocking lisp, and vice-versa. And those non-lisp
threads can run on any number of processors.
[I have to admit at this point that in our x86 product I introduced a
bug due to the non-atomic nature of the way the interrupt flag is
tested, which caused multiple processor usage attempts to sometimes
hang. This has been fixed for version 5.0.1]
> And, I think that's my answer to Kent too. I want a multiprocessing
> API for CL that it is clearly possible to make run on the kind of
> commodity SMP machines that exist now, and that I'm sure will continue
> to exist for a good number of years since the big database people want
> them. At LUGM98 one of the vendor people argued forcefully that this
> was too hard to do, and I just reject that out of hand. There are
> obvious issues with locking for things like INTERN, and I'm sure many
> other places too, but those need to be overcome.
The problem here is that the "many other places" turns out to be the
entire lisp heap! The only other place in memory which is safe is the
thread's stack. Whenever you have the possibility of two different
lisp processes modifying any lisp memory at the same time, there must
be some interlocking of those reads and writes. Note that this is
different than two different lisp threads running on the same machine;
in such a case there is no physical way that they both could modify the
same memory at the _same_ time, because of course only one thread can
run on a single processor at a time, whether or not it is a lisp thread
or an os-thread.
> I'd be happy for
> them to be overcome in a fairly low-level way -- it doesn't have to be
> a complete `do the right thing' solution, it just needs to be enough
> to build one on top of if you want to (after all, Lisp is good at
> that).
>
> (And I'm not asking that all the vendors support SMP machines, just
> that the multiprocessing support doesn't *rule out* support for SMP
> machines. I hope that the market will deal with the rest ...)
What we've done is just such a low-level initial solution; barring
the aforementioned bug, any number of threads can run on any number of
machines, provided that only one thread at a time has access to the
lisp heap. This certainly does not preclude running in an SMP
environment.
> And I think it's a barrier to acceptance because an obvious place for
> Lisp is behind web servers, and big web servers need SMP machines so
> they can scale.
I think we all agree here, and we vendors are working on solutions to
approach the goal.
> Network stuff is a smaller barrier, because everyone has it, and it's
> usually just sockets wrapped up a little, so it's not such a big deal
> to put a standard layer on top of it.
>
> --tim
>
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4hfsaz7j5.fsf@beta.franz.com>
Duane Rettig <·····@franz.com> writes:
> > PS SMP = shared memory processor, which may not be clear in this
> > context, sorry.
>
> In my experiences, SMP has stood for "Symmetric MultiProcessor" instead.
> This is a form of shared-memory mutiprocessor architecture, but it is
> not the only one; it is actually harder than those setups which have
> symmetry (like a master/slave combination) because memory modifications
==^^^^^^^^
> come from any machine at any time, and thus must be properly serialized.
Typo alert: I had meant "asymmetry". Sorry.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 25 Feb 1999 09:27:34 -0800, Duane Rettig <·····@franz.com> wrote:
>This has been fixed for version 5.0.1]
Will this "version 5.0.1" include the missing documentation? (I'm
talking about the appendix listing the ACL Common Lisp non-compliances
and limitations...)
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNtWD1v4C0a0jUw5YEQLVtACdGlrBoiKr6ymr0pEk+6PNGapz8okAoJKG
h8v3ymHRhfRjS9kgPDhECIYG
=zs+s
-----END PGP SIGNATURE-----
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4g17uz2or.fsf@beta.franz.com>
···········@laley-actualidad.es (Juanma Barranquero) writes:
> On 25 Feb 1999 09:27:34 -0800, Duane Rettig <·····@franz.com> wrote:
>
> >This has been fixed for version 5.0.1]
>
> Will this "version 5.0.1" include the missing documentation? (I'm
> talking about the appendix listing the ACL Common Lisp non-compliances
> and limitations...)
That's the intention.
The appendix to which you are referring, which is Appendix A in the
4.3 user guide, is intended to specifically address non-compliances
with the Ansi Spec only.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
> > Multiprocessor support, in a nutshell.
>
> This is true, but also os-threads allows you to run non-lisp
> processes without blocking lisp, and vice-versa. And those non-lisp
> threads can run on any number of processors.
I really don't want to say it, but what a friggin crock!
As long as you don't use Lisp, you can exploit multiprocessors!
What a great marketing message and technical solution!
> > them. At LUGM98 one of the vendor people argued forcefully that this
> > was too hard to do, and I just reject that out of hand. There are
> > obvious issues with locking for things like INTERN, and I'm sure many
> > other places too, but those need to be overcome.
>
> The problem here is that the "many other places" turns out to be the
> entire lisp heap!
>
As someone who implemented a true shared-memory multiprocessor Common
Lisp system ported to serveral platforms in 1990, almost 10 years ago,
not to mention Franz itself has a related system CLIP, about the
same time, I find it pretty sad that 10 years later Franz still
is just coming up with excuses for not having this capability.
It isn't a trivial thing to do, like serializing lisp execution,
but it isn't that hard either.
> > And I think it's a barrier to acceptance because an obvious place for
> > Lisp is behind web servers, and big web servers need SMP machines so
> > they can scale.
>
> I think we all agree here, and we vendors are working on solutions to
> approach the goal.
>
That's good news. What is the multiprocessing API?
In my view, Distributed memory multiprocessors, i.e. networked
computers, are a more scalable solution for a web server
that doesn't necessarily need any low-level support
from the Lisp implementation.
-Kelly Murray ···@niclos.com
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjd82yf6uq.fsf@tfeb.org>
Kelly Murray <···@IntelliMarket.Com> writes:
> In my view, Distributed memory multiprocessors, i.e. networked
> computers, are a more scalable solution for a web server
> that doesn't necessarily need any low-level support
> from the Lisp implementation.
How true this is depends on what you want to do I think. If you
really want a shared-image system, then you need a shared-memory
machine (even if it is not actually shared, it could be NUMA). So if
you want shared access & update to a large data structure, it's really
easier to do that way -- otherwise you end up with message passing,
which is even worse than locks.
Also in a lot of markets, shared-memory machines have their prices
dragged down by what the database people want (and of course big
database type apps is just what I'm thinking of...). If you want to
go *really* big you need networks, but 4 cpu machines are pretty cheap
now, and people like Sun sell n cpu machines for n being ~64. How
that compares with n cheap single-cpu machines depends on how heavily
you stress the network and how you cost admin time vs initial cost.
--tim
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjemnef7d3.fsf@tfeb.org>
(Rereading this it looks kind of agressive, it's not meant to be --
I'm just tired.)
Duane Rettig <·····@franz.com> writes:
>
> The problem here is that the "many other places" turns out to be the
> entire lisp heap! The only other place in memory which is safe is the
> thread's stack. Whenever you have the possibility of two different
> lisp processes modifying any lisp memory at the same time, there must
> be some interlocking of those reads and writes. Note that this is
> different than two different lisp threads running on the same machine;
> in such a case there is no physical way that they both could modify the
> same memory at the _same_ time, because of course only one thread can
> run on a single processor at a time, whether or not it is a lisp thread
> or an os-thread.
Right. And the only person who needs to know about this is the memory
allocator & garbage collector. Apart from those two, if I modify
memory, I would expect to either ensure that I'm not smashing anyone
else's, or have suitable locking. That's how everyone else does it,
so I see no reason why Lisp cannot do it the same way.
What I meant by `many places' were places where you really want to
have locking be automatic. INTERN is probably one such, and I'd argue
that INTERN should probably made an atomic operation by having an
implicit lock (as should other operations which might change
packages). Hashtables probably want an option to cause them to lock
too. I expect there are other places -- almost certainly DEF* wants
to be atomic.
The allocator & GC need to know in depth about the way things work of
course. I think there is some work on distributed GC of just this
sort.
> What we've done is just such a low-level initial solution; barring
> the aforementioned bug, any number of threads can run on any number of
> machines, provided that only one thread at a time has access to the
> lisp heap. This certainly does not preclude running in an SMP
> environment.
Well, only if you don't want to have more than one Lisp thread do
anything useuful at once!
I realise that this `let me smash memory if I want to' is not The Lisp
Way, which would be to have it all be very safe, but I am reasonably
convinced that having it all be very safe and running on SMPs (with
more than one active Lisp thread) are mutually exclusive goals,
possibly even theoretically so. The Lisp Way somehow presupposes that
programming on pll machines can be made painless, and I think that
that just turns out to be wrong, although many people have tried to
make it so. (It's just *because* many people have tried & failed that
I think it's not painless!)
Really I think there is a choice between waiting for a long time --
possibly forever -- for a `right thing' solution, with the result that
people like me who would like to do server-type stuff which might have
to scale to really big machines end up using C, or implementing a
low-level solution. Remember that you can build a high-level one on
the low-level one, or just keep using the same solution but redefine
it to be safe.
And finally note that I'm not saying `you must do this' (as if I
could!) -- I'm really just asking for a multiprocessing interface
which doesn't rule it out in some way, like the old symbolics one did
I think (because it implied polling at various points I think). I
don't have access to the ACL documentation any more, so it may be that
the ACL API is fine.
Of course, I'd really like to see a proper mutithreaded Lisp on a
commodity pll box!
--tim
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4zp61zf4q.fsf@beta.franz.com>
Tim Bradshaw <···@tfeb.org> writes:
> (Rereading this it looks kind of agressive, it's not meant to be --
> I'm just tired.)
Seems fine to me; it certainly isn't the most aggressive posting I've
read today...
> Duane Rettig <·····@franz.com> writes:
> >
> > The problem here is that the "many other places" turns out to be the
> > entire lisp heap! The only other place in memory which is safe is the
> > thread's stack. Whenever you have the possibility of two different
> > lisp processes modifying any lisp memory at the same time, there must
> > be some interlocking of those reads and writes. Note that this is
> > different than two different lisp threads running on the same machine;
> > in such a case there is no physical way that they both could modify the
> > same memory at the _same_ time, because of course only one thread can
> > run on a single processor at a time, whether or not it is a lisp thread
> > or an os-thread.
>
> Right. And the only person who needs to know about this is the memory
> allocator & garbage collector. Apart from those two, if I modify
> memory, I would expect to either ensure that I'm not smashing anyone
> else's, or have suitable locking. That's how everyone else does it,
> so I see no reason why Lisp cannot do it the same way.
>
> What I meant by `many places' were places where you really want to
> have locking be automatic. INTERN is probably one such, and I'd argue
> that INTERN should probably made an atomic operation by having an
> implicit lock (as should other operations which might change
> packages). Hashtables probably want an option to cause them to lock
> too. I expect there are other places -- almost certainly DEF* wants
> to be atomic.
Another area which we would need to deal with is special bindings.
The legacy of the shallow-binding decision by many implementors (which
I believe is a legitimate design tradeoff) is exactly the opposite of
what one wants for multiprocessing; deep binding is the better approach
for this set of design constraints. We experimented with a hybrid
approach years ago, and perhaps we will come back to it or something
similar again.
> The allocator & GC need to know in depth about the way things work of
> course. I think there is some work on distributed GC of just this
> sort.
A distributed GC is certainly an important aspect of distributed
processing. You don't want to get all of your lisp threads up and running
simultaneously, only to have them all grind to a halt periodically so
that a stop-and-copy gc (no matter how ephemeral) can do its thing.
> > What we've done is just such a low-level initial solution; barring
> > the aforementioned bug, any number of threads can run on any number of
> > machines, provided that only one thread at a time has access to the
> > lisp heap. This certainly does not preclude running in an SMP
> > environment.
>
> Well, only if you don't want to have more than one Lisp thread do
> anything useuful at once!
Correct, but it turns out that many of the lisp customers that would
otherwise foot the bill for such a project are using our product in
just that way: bringing many C, C++, and Java pieces together with
the lisp being the "glue" that puts them together. When you add to
that the fact that many of the things that can be done with multiple
processors can also fairly easily be done with multiple processes
(separate and autonomous), communicating via sockets or other ipc
styles, and even explicitly allocated shared memory, the extra
expense of trying to make things work within a single process simply
doesn't make business sense to either those customers or us (I know
some will disagree, but we have to focus on our entire customer base,
and tend to cater to those that pay us more money :-) So we do what
we can on our own nickel, edging things closer to what we think people
want. Are we there yet? Of course not. Are we moving toward the
goal? Yes.
> I realise that this `let me smash memory if I want to' is not The Lisp
> Way, which would be to have it all be very safe, but I am reasonably
> convinced that having it all be very safe and running on SMPs (with
> more than one active Lisp thread) are mutually exclusive goals,
> possibly even theoretically so. The Lisp Way somehow presupposes that
> programming on pll machines can be made painless, and I think that
> that just turns out to be wrong, although many people have tried to
> make it so. (It's just *because* many people have tried & failed that
> I think it's not painless!)
In my opinion, my Company's pain stems from the experiences we had with
our multiprocessor product: Allegro CLIP. It ran on a sequent, used
"futures", and a hybrid deep-binding approach that implemented bindstacks
with hash-tables, and ran about 20% slower as compared to an equivalent
single-processor lisp. I do believe that we could have taken care of
the speed problem, if there had been any corporate will to do so, but
our biggest problem was with sales - very few bought the lisp.
> Really I think there is a choice between waiting for a long time --
> possibly forever -- for a `right thing' solution, with the result that
> people like me who would like to do server-type stuff which might have
> to scale to really big machines end up using C, or implementing a
> low-level solution. Remember that you can build a high-level one on
> the low-level one, or just keep using the same solution but redefine
> it to be safe.
There's no shame in writing C code. In a perfect world, every problem
would be solvable with a lisp-only solution. And some are able to
work their solutions entirely in lisp. However, the majority of our
customers settle on a hybrid effort, and this guides us as to where
we go next; it is no accident that we added CORBA and OLE products
last year, and are still working strongly on connectivity.
> And finally note that I'm not saying `you must do this' (as if I
> could!) -- I'm really just asking for a multiprocessing interface
> which doesn't rule it out in some way, like the old symbolics one did
> I think (because it implied polling at various points I think). I
> don't have access to the ACL documentation any more, so it may be that
> the ACL API is fine.
I don't know about polling requirements on Symbolics, but I can't
think of any such requirement in ACL.
> Of course, I'd really like to see a proper mutithreaded Lisp on a
> commodity pll box!
I agree.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjd82vgxtn.fsf@tfeb.org>
Duane Rettig <·····@franz.com> writes:
> Correct, but it turns out that many of the lisp customers that would
> otherwise foot the bill for such a project are using our product in
> just that way: bringing many C, C++, and Java pieces together with
> the lisp being the "glue" that puts them together. When you add to
> that the fact that many of the things that can be done with multiple
> processors can also fairly easily be done with multiple processes
> (separate and autonomous), communicating via sockets or other ipc
> styles, and even explicitly allocated shared memory, the extra
> expense of trying to make things work within a single process simply
> doesn't make business sense to either those customers or us (I know
> some will disagree, but we have to focus on our entire customer base,
> and tend to cater to those that pay us more money :-) So we do what
> we can on our own nickel, edging things closer to what we think people
> want. Are we there yet? Of course not. Are we moving toward the
> goal? Yes.
I take your point about not being able to afford to do it, although I
do think it's very sad.
> In my opinion, my Company's pain stems from the experiences we had with
> our multiprocessor product: Allegro CLIP. It ran on a sequent, used
> "futures", and a hybrid deep-binding approach that implemented bindstacks
> with hash-tables, and ran about 20% slower as compared to an equivalent
> single-processor lisp. I do believe that we could have taken care of
> the speed problem, if there had been any corporate will to do so, but
> our biggest problem was with sales - very few bought the lisp.
Do you mean 20% slower on a uniprocessor, or 20% slower even on a
multiprocessor? Scaling behaviour should be a good deal more
important than performance on a single CPU -- if you can get
near-linear speedup for some reasonably pllizable problem, then you're
ahead on a 2cpu box, already. OTOH I don't know what `futures' implies,
but if it's a clever technique for making multiprocessor systems look
easy to program I suspect it's doomed. I've seen too many systems that
claimed to make parallel programming easy lying forgotten in the corners
of machine rooms...
> There's no shame in writing C code. In a perfect world, every problem
> would be solvable with a lisp-only solution. And some are able to
> work their solutions entirely in lisp. However, the majority of our
> customers settle on a hybrid effort, and this guides us as to where
> we go next; it is no accident that we added CORBA and OLE products
> last year, and are still working strongly on connectivity.
Again, I can see your commercial point, though I think it is a sad
one. Half the the reason I like programming in Lisp is because it's a
wonderful language to think in, compared with C where I spend most of
my life fighting the language. If I was going to write programs on a
parallel machine, I'm already going to be fighting the fact that this
is a very hard thing to do: I could do without having to fight C as
well.
--tim
Actually, a technical correction, Allegro CLIP did not use FUTURES,
they just claimed they did, but they didn't know what a FUTURE was,
just that people seemed to want it so they said they had it.
In fact, when I went to see the Franz CLIP demo, I pointed out
the reason they could only get a 2-times speedup in their example
was precisely becuase they didn't have futures. Oh well,
maybe that had something to do with nobody buying it,
or perhaps that it only ran on a big-dollar Sequent, or it
was incompatible with the "normal" lisp?
As a related business model comment, only doing what your customers
pay you to do is a good way to stay in business doing what your
customers will pay you to do. That's a different business than
selling software.
In particular, as with Allegro CLIP, Franz did what Sequent paid
them to do, deliver a multiprocessor lisp. No matter if it was
actually useful to anyone or attracted more customers,
it was still a good short-term business deal that made a profit.
Finally, I don't mean to beat up on my friend Duane.
(actually I don't mean to beat up on anyone, but Duane in particular)
Duane is the reason we have ACL under Linux --
all my arguments had little effect on Franz managment,
it was Duane who "just did it" on his own time..
Like I imagine he will do for multiprocessing.
Thanks Duane!
Tim Bradshaw wrote:
>
> Duane Rettig <·····@franz.com> writes:
>
> > Correct, but it turns out that many of the lisp customers that would
> > otherwise foot the bill for such a project are using our product in
> > just that way: bringing many C, C++, and Java pieces together with
> > the lisp being the "glue" that puts them together. When you add to
> > that the fact that many of the things that can be done with multiple
> > processors can also fairly easily be done with multiple processes
> > (separate and autonomous), communicating via sockets or other ipc
> > styles, and even explicitly allocated shared memory, the extra
> > expense of trying to make things work within a single process simply
> > doesn't make business sense to either those customers or us (I know
> > some will disagree, but we have to focus on our entire customer base,
> > and tend to cater to those that pay us more money :-) So we do what
> > we can on our own nickel, edging things closer to what we think people
> > want. Are we there yet? Of course not. Are we moving toward the
> > goal? Yes.
>
> I take your point about not being able to afford to do it, although I
> do think it's very sad.
>
> > In my opinion, my Company's pain stems from the experiences we had with
> > our multiprocessor product: Allegro CLIP. It ran on a sequent, used
> > "futures", and a hybrid deep-binding approach that implemented bindstacks
> > with hash-tables, and ran about 20% slower as compared to an equivalent
> > single-processor lisp. I do believe that we could have taken care of
> > the speed problem, if there had been any corporate will to do so, but
> > our biggest problem was with sales - very few bought the lisp.
>
> Do you mean 20% slower on a uniprocessor, or 20% slower even on a
> multiprocessor? Scaling behaviour should be a good deal more
> important than performance on a single CPU -- if you can get
> near-linear speedup for some reasonably pllizable problem, then you're
> ahead on a 2cpu box, already. OTOH I don't know what `futures' implies,
> but if it's a clever technique for making multiprocessor systems look
> easy to program I suspect it's doomed. I've seen too many systems that
> claimed to make parallel programming easy lying forgotten in the corners
> of machine rooms...
>
> > There's no shame in writing C code. In a perfect world, every problem
> > would be solvable with a lisp-only solution. And some are able to
> > work their solutions entirely in lisp. However, the majority of our
> > customers settle on a hybrid effort, and this guides us as to where
> > we go next; it is no accident that we added CORBA and OLE products
> > last year, and are still working strongly on connectivity.
>
> Again, I can see your commercial point, though I think it is a sad
> one. Half the the reason I like programming in Lisp is because it's a
> wonderful language to think in, compared with C where I spend most of
> my life fighting the language. If I was going to write programs on a
> parallel machine, I'm already going to be fighting the fact that this
> is a very hard thing to do: I could do without having to fight C as
> well.
>
> --tim
From: Duane Rettig
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4n21tcj92.fsf@beta.franz.com>
Kelly Murray <···@IntelliMarket.Com> writes:
> Finally, I don't mean to beat up on my friend Duane.
> (actually I don't mean to beat up on anyone, but Duane in particular)
> Duane is the reason we have ACL under Linux --
> all my arguments had little effect on Franz managment,
> it was Duane who "just did it" on his own time..
> Like I imagine he will do for multiprocessing.
> Thanks Duane!
Well, thanks for the compliment, but it is misplaced. It is true that
I do work on my own time, but not the linux port. And it is true that
I did the linux port (it's part of my job) but it was Franz management
that decided to make it available for no charge. It is even true that
I approached management with the idea to make the linux port easily
available, but I wasn't the only developer to do so, and my idea had
been to charge some reasonable price for it (like maybe $100 or $200 USD).
Instead management decided to make it $0. Aren't you glad that they
didn't listen to me? :-)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Christopher R. Barry" wrote:
>
> Daniel Finster <··@nanofab.utdallas.edu> writes:
>
> > As far as particular implementations: CMUCL needs a real GC and a better
> > debugger.
>
> The GC ain't too bad... what _really_ needs work is
> PCL/CLOS/MOP....
>
> What are your complaints specifically about the debugger? It does a
> superb job of letting you step through and debug compiled code. Have
> you read all the documentation for its commands and the compiler
> options? Or are you refering to the Motif debugger interface? Yeah,
> that has a few issues....
Actually, I've never used it for debugging anything real. I just got
the impression that it was too limited by looking at the available
commands. Also I've heard other people that do use it say that it is
pretty limiting. The fact that it has so few debugging commands
reinforces my willingness to believe them.
>
> > Symbolics needs to build new hardware and blow everyone else
> > away...again.
>
> Fat chance. It would be nicer if Intel and major processor vendors
> would some time in the future aknowledge Lisp and put better support
> for type-tagging and checking in hardware. This would certainly help
> out Smalltalk and some other languages and even Java.
Not a fat chance at all. 8 year old Lisp hardware still compares quite
favorably with todays systems. New Lisp hardware would blow stock
hardware away. The only problem is that Symbolics currently doesn't
have enough money to develop new hardware. However, I think it is way
to early still to write them off completely.
>
> > Also, we need some sort of free Netsrape/Internet Exploiter plug-in
> > that runs Common Lisp, and some cool "applets" written using it. If
> > we have a serious competitor to Java among the "applet" crowd, then
> > that could get Common Lisp a lot more good exposure.
>
> Writing a CL plugin for Netscape means:
>
> 1. A kinda large Lisp runtime dumped with compiler that will be too
> big to ever make it into the main Netscape distribution, and will mean
> a large, inconvenient download to many which will leave web developers
> reluctant to use it.
I disagree here. In an era of 20MB web browsers, a 2MB Common Lisp
system (looked at Corman Lisp?) doesn't sound like too big of a burden.
Particularly when you go get the JDK and its a whopping 14MB...
>
> 2. The Netscape PluginSDK gives you an almost standard API for
> Windows, Unix and Mac, though you are writing completely
> platform-dependant code to load into Netscape. And if your Lisp does
> Green threads instead of OS native, it is much more tedious to
> properly implement the plugin. And currently none of Unix Lisps I know
> of do OS native threads.
Well, since Java doesn't run properly on every platform, who says we
have to?
Even if it only works on Windows to start with, that'd be a win.
>
> 3. You have to copy rather large CL source files over the network
> first and then compile them on the plugin client, and they may then
> execute with absolutely no security. If you compile them first then
> you have to provide binaries for every platform you plan to have your
> plugin run on.
You could use a byte-complied system such as CLisp, alleviating both
problems.
As far as security, I see that as a trivial problem to fix. If the Java
language designers can come up with a half-assed solution, surely we
can.
> 4. If your plugin uses any kind of GUI, well, there is no standard way
> to do a GUI in ANSI CL so you must also write/port a GUI library to
> all of the platforms unless you only want your plugin to only run
> under one specific vendor's Lisp.
Well, as I said above, running in only one specific Lisp system is still
a bin win compared to not running at all. It doesn't have to support
all platforms at the beginning. And also as I said above, Java's GUI
sucks, so obviously people don't care too much.
Java has proved that no matter how big, slow, nonfunctional, broken, and
noninteroperable your code is, as long as its "cool" you'll still Get
Rich Quick.
What the Lisp community really needs is a good marketing team.
I hate this; I really wish that success in the marketplace had something
to do with the quality of the system, but it doesn't. The entire
computer industry is all marketing and service; technology has -nothing-
to do with it. We can sit around all day and tell the world all about
Lisp's earth-shattering capabilities, and they just won't care, because
it's not being mass-marketed. Meanwhile everybody is perfectly happy
with Microsoft and Sun CRAP--not only happy, but demanding more--all
because they have superior marketing teams.
From: Steve Gonedes
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <m2pv6zlipe.fsf@KludgeUnix.com>
Daniel Finster <··@nanofab.utdallas.edu> writes:
< I hate this; I really wish that success in the marketplace had something
< to do with the quality of the system, but it doesn't. The entire
< computer industry is all marketing and service; technology has -nothing-
< to do with it. We can sit around all day and tell the world all about
< Lisp's earth-shattering capabilities, and they just won't care, because
< it's not being mass-marketed. Meanwhile everybody is perfectly happy
< with Microsoft and Sun CRAP--not only happy, but demanding more--all
< because they have superior marketing teams.
I think that the quality of the product has much to do with it's
failure in the market place. It seems to me that a high quality
product binds the marketing campaign to reality; hence its
undesirability. I mean, what can you really say about something that
works well? "It works well." No, it won't solve _your_ problems, but
the macros kick ass.
The whole idea of marketing crap software seems to be based on selling
limitations as benefits. Lisp just can't compete very well on this
level I don't think.
It's like checking to see if a system call failed in the C programming
language (unix and other innovative operatings systems of the day).
People have to invest so much time, energy, and emotion in justifying
this tedious behavior that they get offended when told that what
they're doing is not the best method.
If I spent 3 or 4 years of my life tracking down malloc bugs, I would
be very upset if someone pointed me to a method which would have saved
me from having to deal with it entirely. This happened to me with TeX.
I spent _lots_ of emotion and time trying to understand it. I found
myself trying to justify it's idiotic behavior. Instead of accepting,
these limitations I freaked out and now I take every oppertunity to
notify people that TeX is nothing but a useless time sync and should
be destroyed like all the rest of the shit-ware I find myself using
all too often. People who spent years writing LaTeX don't want to hear
this though.
What I get upset with is when people invest _so_ much that their
brains warp or something and they think that the original limitations
are actually _desirable features_! Don't understand how this happens,
but this seems to be a reaction of fear in losing on their investment.
How many business people would invest lots of money, lose their
investment, and continue to invest more money? Why do people do this
with software? Writing programs is so difficult. Sigh.
On 24 Feb 1999 19:04:39 GMT, Steve Gonedes <········@worldnet.att.net> wrote:
>If I spent 3 or 4 years of my life tracking down malloc bugs, I would
>be very upset if someone pointed me to a method which would have saved
>me from having to deal with it entirely. This happened to me with TeX.
>I spent _lots_ of emotion and time trying to understand it. I found
>myself trying to justify it's idiotic behavior. Instead of accepting,
>these limitations I freaked out and now I take every oppertunity to
>notify people that TeX is nothing but a useless time sync and should
>be destroyed like all the rest of the shit-ware I find myself using
>all too often. People who spent years writing LaTeX don't want to hear
>this though.
>
Maybe an off topic question, but what do you use as an alternative text
formater for TEX ?
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
From: charliew
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7b6r1a$f65$1@news.hal-pc.org>
see.signature wrote in message ...
>On 24 Feb 1999 19:04:39 GMT, Steve Gonedes <········@worldnet.att.net>
wrote:
>
>>If I spent 3 or 4 years of my life tracking down malloc bugs, I would
>>be very upset if someone pointed me to a method which would have saved
>>me from having to deal with it entirely. This happened to me with TeX.
>>I spent _lots_ of emotion and time trying to understand it. I found
>>myself trying to justify it's idiotic behavior. Instead of accepting,
>>these limitations I freaked out and now I take every oppertunity to
>>notify people that TeX is nothing but a useless time sync and should
>>be destroyed like all the rest of the shit-ware I find myself using
>>all too often. People who spent years writing LaTeX don't want to hear
>>this though.
>>
So, should you write LaTeX in a rubber room? ; - )
From: David Combs
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <dkcombsF7yA4y.En0@netcom.com>
What text processor other than Tex.
Well, I myself use "Scribe", originally from CMU,
but now you have to pay for it (but not much).
Never used tex, latex, etc.
But I sure don't like the idea of some
huge pipeline of programs my source has
to run through -- how in the world do you find your
errors?
Scribe is one big monolithic program. Like
tex and nroff, the source document is ascii, marked
up. Has macros. Is really nice -- developed by a
computer scientist who evidently had a lisp background.
I think they sell it for $500 or so for a PC (only they
say that it will be hard to make it work on NT, something
about 32 bits or something, vs 16. Works fine on my
sparcstation, which is all I care about!)
One nice thing is that they can also produce ascii
output (or "line printer"), not just postscript, making
it usable for complex email, faqs, etc.
Anyway, I like it a lot.
David
From: Erik Naggum
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <3128923412064097@naggum.no>
* Steve Gonedes <········@worldnet.att.net>
| The whole idea of marketing crap software seems to be based on selling
| limitations as benefits. Lisp just can't compete very well on this level
| I don't think.
well, marketing crap software is more about selling a better tomorrow
than anything else. the whole "new version" drive is about having people
believe that the next version will somehow improve things. as long as
they have a next version dangled in front of them, they keep working with
their present tools, _expecting_ the pain to end with the next version,
or the next version after that.
if you can make people _believe_ in tomorrow, they'll accept _whatever_
today has to offer. many religions may well be based on this principle.
however, if what you have today is basically the top of the line, the
opportunity for a belief in tomorrow as the relief of today's pain is
gone: if it's painful today, it is likely to be painful tomorrow, too,
and thus we have people bitching and moaning about FFI's and DEFSYSTEM
and sockets and runtime licensing and "Lisp is dead" and all those
extremely useless things compared to what other languages go through.
I have also come to believe that the desire to see thing "standardized"
comes from this lack of a belief in a better tomorrow. if there is no
better tomorrow, let's at least create a perfect _past_, instead, and
that's what proper standards do.
| What I get upset with is when people invest _so_ much that their brains
| warp or something and they think that the original limitations are
| actually _desirable features_! Don't understand how this happens, but
| this seems to be a reaction of fear in losing on their investment. How
| many business people would invest lots of money, lose their investment,
| and continue to invest more money? Why do people do this with software?
| Writing programs is so difficult. Sigh.
well, if you do something good and get rewarded for it every time, you'll
get disappointed the first time you don't get rewarded, as if it were an
actual signal that you were doing something wrong, and you try something
different right away or maybe after ensuring through one or two attempts
that you don't get rewarded, anymore: the world has changed, and what you
do now has changed from good to indifferent or bad. (if you can figure
out why, a sense of efficacy reinforces your "do good - get rewarded"
behavioral pattern.) however, if you do something good and you get
rewarded for it randomly and you very seldom get reprimanded for any bad
things you do, lack of reward is a _reinforcer_ to keep doing the same
thing over and over because you will _eventually_ get a reward, and then
it'll all be worth it. prayers work this way: if you pray for something
and nothing happens like a million times, but then something close enough
does, it wasn't coincidence -- your prayers were actually heard, and now
you can pray for other things, and they'll eventually come true, too, if
you pray sincerely enough or do whatever you can be duped into doing by
some manipulative, evil person who exploits your lack of understanding of
statistics.
in other words, if you get what you deserve every time, your reaction
pattern will be extremely well adjusted to whoever rewards or punishes
you, but if you get random signals or no signals at all, you have to
generate your own feedback, and this is how all psychological problems
start if the feedback loop is out of tune with what's really out there.
since programming is basically devoid of feedback from anything but the
computer, a programming environment with random feedback will attract
more users than one with consistent feedback. another psychological
aspect to programming is the time distance between action and reward.
the reward or punishment may be consistently delivered, but after a
random time, like a very frustrating random crash or bug.
the clue to whether an environment succeeds, I think, is whether it
manages to make people believe that they will get rewarded for doing the
right thing, however, with sufficient randomness in delivering the reward
that the users think that the system isn't always responding without that
being their fault. when it works, it's like a prayer come true, and
people will refer to the stuff that works in religious terms like
"incantations" instead of simply "commands" or "code".
Common Lisp environments fail this test. in safe mode, every error is
reported, so you get punished consistently, you get a value (reward) from
almost everything you do and you can predict when you won't get it, so
the entire Common Lisp world is one that appeals to a certain type of
people who, I believe, thrive with competent colleagues who demand and
respect a consistent quality from their performance. in contrast, C++
and Perl and Windows and the other useful crap out there attract people
who have non-caring bosses and incompetent colleagues from whom accurate
feedback is a very rare thing, indeed. I also believe that these tools
_create_ that kind of working environment and that the introduction of
Common Lisp to such environment poses a very significant threat to the
prevailing belief systems, not because of any actual investments, but
more like it would be to convince very religious people that their God is
a figment of their own imagination.
#:Erik Covenant, the non-believer
Erik Naggum wrote:
>
> I have also come to believe that the desire to see thing "standardized"
> comes from this lack of a belief in a better tomorrow. if there is no
> better tomorrow, let's at least create a perfect _past_, instead, and
> that's what proper standards do.
>
Agree. Standardization means freezing a situation. If that's the proper
word. I was on my first (and last) standard-committee 25 years ago, and
that was a boring experience.
But you should establish a viewing point when looking at standardization
issues. Take my company (Ericsson). We're in the race of TTT, Time to
Technology, as well as TTM - Time to Market and TTC - Time to Customer.
So we strive at standardization in technology to be, as well. And we
direct our designers to go for standards as much possible - we have to
make a profit as well as being technically competent.
A few Lisper's are at the Lisp Technology end of the scale, but most are
probably at the Consumer's end. Would you be content if we talk about
Lisp 'standardization' in the sense of 'establishing a next, clearly
specified Lisp environment', or some such?
> Common Lisp environments fail this test. in safe mode, every error is
> reported, so you get punished consistently, you get a value (reward) from
> almost everything you do and you can predict when you won't get it, so
> the entire Common Lisp world is one that appeals to a certain type of
> people who, I believe, thrive with competent colleagues who demand and
> respect a consistent quality from their performance.
Again, yes, the Lisp world attracts a certain type of people. But
companies have to make do with the rest of us too, since those people
are scarce. Shall we say that the problem is neither Lisp as a language,
or Lisp as inferior in performance or development environment, but a
fundamental difficulty in slicing Lisp-based solutions into pieces that
this external world can manage?
I can see a long list of systems and tools that ought to be implemented
in Lisp, but then reality knocks on the door. Dammit, people bear
witness here, that Lisp isn't even mentioned in education. We do keep
away from the spotlight, that's for sure.
So a bit of uniformity, and some specified minimum GUI environment and
networking capabilities won't hurt.
Lars Lundback
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87btijk2zb.fsf@2xtreme.net>
Daniel Finster <··@nanofab.utdallas.edu> writes:
> > What are your complaints specifically about the debugger? It does a
> > superb job of letting you step through and debug compiled code. Have
> > you read all the documentation for its commands and the compiler
> > options? Or are you refering to the Motif debugger interface? Yeah,
> > that has a few issues....
>
> Actually, I've never used it for debugging anything real. I just got
> the impression that it was too limited by looking at the available
> commands.
Uh, then what commands should be there that there aren't? Let me
guess, you're not sure....
> Also I've heard other people that do use it say that it is
> pretty limiting. The fact that it has so few debugging commands
> reinforces my willingness to believe them.
Well whatever you do, don't actually think for yourself.
> > > Symbolics needs to build new hardware and blow everyone else
> > > away...again.
> >
> > Fat chance. It would be nicer if Intel and major processor vendors
> > would some time in the future aknowledge Lisp and put better support
> > for type-tagging and checking in hardware. This would certainly help
> > out Smalltalk and some other languages and even Java.
>
> Not a fat chance at all. 8 year old Lisp hardware still compares quite
> favorably with todays systems.
8 year old+ Lisp _software_ compares quite favorably with today's
systems. A 20MHz XL1200 has execution speed that is several orders of
magnitude less than that of MCL or Allegro CL on a PowerPC or Pentium
II. From what I hear, the software functionality makes you not notice
this limitation too often, but the're still dog slow.
> The only problem is that Symbolics currently doesn't have enough
> money to develop new hardware. However, I think it is way to early
> still to write them off completely.
You just go on believing whatever you want to.
> > 1. A kinda large Lisp runtime dumped with compiler that will be too
> > big to ever make it into the main Netscape distribution, and will mean
> > a large, inconvenient download to many which will leave web developers
> > reluctant to use it.
>
> I disagree here. In an era of 20MB web browsers, a 2MB Common Lisp
> system (looked at Corman Lisp?) doesn't sound like too big of a burden.
> Particularly when you go get the JDK and its a whopping 14MB...
Uh, the entire Netscape Communicator Professional Edition download is
around 15MB. That obviously includes its JVM. The JDK includes the JRE
_and_ the stuff you need to compile applications for the JRE.
Starting with version 5 of Navigator (Mozilla), the're gonna let you
plug in whatever JVM you want to use to instead of forcing their own
JVM on you, which is about the crappiest one you'll find on any
platform.
> > 2. The Netscape PluginSDK gives you an almost standard API for
> > Windows, Unix and Mac, though you are writing completely
> > platform-dependant code to load into Netscape. And if your Lisp does
> > Green threads instead of OS native, it is much more tedious to
> > properly implement the plugin. And currently none of Unix Lisps I know
> > of do OS native threads.
>
> Well, since Java doesn't run properly on every platform, who says we
> have to?
If that's how you want to reason, fine.
> Even if it only works on Windows to start with, that'd be a win.
It does work on Windows right now with Allegro CL. Apparently you
hadn't heard of this _win_ though. What a surprise.
> > 3. You have to copy rather large CL source files over the network
> > first and then compile them on the plugin client, and they may then
> > execute with absolutely no security. If you compile them first then
> > you have to provide binaries for every platform you plan to have your
> > plugin run on.
>
> You could use a byte-complied system such as CLisp, alleviating both
> problems.
Or compile to Java byte-code, and leverage all of the investing and
effort and technology and existing market penetration of Java VMs.
> As far as security, I see that as a trivial problem to fix. If the
> Java language designers can come up with a half-assed solution,
> surely we can.
Security is not a feature of the Java _language_ (other than some of
the benefits strong-typing kinda gives you in this specific respect).
If you feel this is so trivial, then I'm looking forward to detailed
technical explaination of why. But I have feeling you don't have one.
> > 4. If your plugin uses any kind of GUI, well, there is no standard way
> > to do a GUI in ANSI CL so you must also write/port a GUI library to
> > all of the platforms unless you only want your plugin to only run
> > under one specific vendor's Lisp.
>
> Well, as I said above, running in only one specific Lisp system is still
> a bin win compared to not running at all.
Then grab ACL for Windows and knock yourself out. Have fun.
> It doesn't have to support all platforms at the beginning. And also
> as I said above, Java's GUI sucks, so obviously people don't care
> too much.
Sigh. I've only been on Usenet since 1998 or so. Maybe that's why I'm
so gentle. I'm finding it so easy to sympathize with Erik these days.
[Rest not worth my time.]
Christopher
"Christopher R. Barry" wrote:
>
> Daniel Finster <··@nanofab.utdallas.edu> writes:
>
> > > What are your complaints specifically about the debugger? It does a
> > > superb job of letting you step through and debug compiled code. Have
> > > you read all the documentation for its commands and the compiler
> > > options? Or are you refering to the Motif debugger interface? Yeah,
> > > that has a few issues....
> >
> > Actually, I've never used it for debugging anything real. I just got
> > the impression that it was too limited by looking at the available
> > commands.
>
> Uh, then what commands should be there that there aren't? Let me
> guess, you're not sure....
Hmm, well, upon furthur investigation (remember: always speak loudly
first, then check the facts), it appears that when I originally looked
at the list of the debugging commands, I only got the first page. So
after having read the full list, I can't think of anything crucial that
is missing. Apologies for my lossage.
>
> > Also I've heard other people that do use it say that it is
> > pretty limiting. The fact that it has so few debugging commands
> > reinforces my willingness to believe them.
>
> Well whatever you do, don't actually think for yourself.
I'll try not to, I promise!
>
> > > > Symbolics needs to build new hardware and blow everyone else
> > > > away...again.
> > >
> > > Fat chance. It would be nicer if Intel and major processor vendors
> > > would some time in the future aknowledge Lisp and put better support
> > > for type-tagging and checking in hardware. This would certainly help
> > > out Smalltalk and some other languages and even Java.
> >
> > Not a fat chance at all. 8 year old Lisp hardware still compares quite
> > favorably with todays systems.
>
> 8 year old+ Lisp _software_ compares quite favorably with today's
> systems. A 20MHz XL1200 has execution speed that is several orders of
> magnitude less than that of MCL or Allegro CL on a PowerPC or Pentium
> II. From what I hear, the software functionality makes you not notice
> this limitation too often, but the're still dog slow.
What I meant was, 8 year old Lisp hardware running the 8+ year old Lisp
software still compares quite favorably. Obviously the raw speeds of
any of todays processors totally blows the Ivory away. But when the
Ivory was made, it really blew away the competition. A new Lisp
processor made with modern technology would blow away any Alpha, I'm
sure.
Personally, raw processor speeds aside, I'm still about 100 times
happier with my 3640 than I am with Harlequin LispWorks for Windows on a
200MHz Pentium (my work environment). And I'm still convinced that my
3640 pages faster (anyone else notice how chunky and funky NT paging
is?).
>
> > The only problem is that Symbolics currently doesn't have enough
> > money to develop new hardware. However, I think it is way to early
> > still to write them off completely.
>
> You just go on believing whatever you want to.
Anytime, baby. Your place or mine?
>
> > > 1. A kinda large Lisp runtime dumped with compiler that will be too
> > > big to ever make it into the main Netscape distribution, and will mean
> > > a large, inconvenient download to many which will leave web developers
> > > reluctant to use it.
> >
> > I disagree here. In an era of 20MB web browsers, a 2MB Common Lisp
> > system (looked at Corman Lisp?) doesn't sound like too big of a burden.
> > Particularly when you go get the JDK and its a whopping 14MB...
>
> Uh, the entire Netscape Communicator Professional Edition download is
> around 15MB. That obviously includes its JVM. The JDK includes the JRE
> _and_ the stuff you need to compile applications for the JRE.
Compared to a 2 or 3MB CL system, which includes the runtime _and_ the
stuff you need to compile the applications.
>
> Starting with version 5 of Navigator (Mozilla), the're gonna let you
> plug in whatever JVM you want to use to instead of forcing their own
> JVM on you, which is about the crappiest one you'll find on any
> platform.
>
> > > 2. The Netscape PluginSDK gives you an almost standard API for
> > > Windows, Unix and Mac, though you are writing completely
> > > platform-dependant code to load into Netscape. And if your Lisp does
> > > Green threads instead of OS native, it is much more tedious to
> > > properly implement the plugin. And currently none of Unix Lisps I know
> > > of do OS native threads.
> >
> > Well, since Java doesn't run properly on every platform, who says we
> > have to?
>
> If that's how you want to reason, fine.
I don't like reasoning that way, actually. I'd prefer that everything
run properly on every platform. But I was just making the case that
since Java has proved that none of that is necessary, we look kind of
silly using that as an excuse to not produce our own offering. Yeah,
it'd be a sucky, lame Lisp system, but still about 10 times better than
anything Java does... Now if we did it the RIGHT way, on the other hand,
we would really win big.
Please don't get the idea that I like the idea of making crap software.
I just kind of figure that if the other guys do it, obviously the market
won't care if we do it too. So maybe if we got something lame out, we'd
be in a slightly better position than where we are now.
>
> > Even if it only works on Windows to start with, that'd be a win.
>
> It does work on Windows right now with Allegro CL. Apparently you
> hadn't heard of this _win_ though. What a surprise.
Yeah, I've heard of it. I've also heard the complaint that it is
missing a crucial DLL. I also understand that to really use it in the
long term, you have to buy a very expensive ACL license (correct me if
I'm wrong). I meant that we need something free.
>
> > > 3. You have to copy rather large CL source files over the network
> > > first and then compile them on the plugin client, and they may then
> > > execute with absolutely no security. If you compile them first then
> > > you have to provide binaries for every platform you plan to have your
> > > plugin run on.
> >
> > You could use a byte-complied system such as CLisp, alleviating both
> > problems.
>
> Or compile to Java byte-code, and leverage all of the investing and
> effort and technology and existing market penetration of Java VMs.
Well, whoever writes this thing (if anyone) will decide on what they
like best. I prefer being an isolationist and just doing everything in
Lisp (what I'd -really- prefer is to have the entire browser written in
Lisp). But since I'm not actually writing such a system, maybe I should
just shut up, since my feelings don't matter anyway.
So fine, even if it just compiled to JVM, we'd still win somewhat.
>
> > As far as security, I see that as a trivial problem to fix. If the
> > Java language designers can come up with a half-assed solution,
> > surely we can.
>
> Security is not a feature of the Java _language_ (other than some of
> the benefits strong-typing kinda gives you in this specific respect).
>
> If you feel this is so trivial, then I'm looking forward to detailed
> technical explaination of why. But I have feeling you don't have one.
Because security doesn't seem like a real hard problem. I've toyed
around with a package-based security system for CL before (I think it's
kindof kludgy to base it on the package system, but it works. A better
system would be one based on control of environments (I've seen a Scheme
paper on this before somewhere, can't remember the title)).
What do you feel makes security so hard? Maybe I'm missing something.
My prior toying with security was based around the idea of securing a
Lisp system that multiple people are using simultaneously, sharing
memory. Maybe securing a Lisp system that is running in a web browser
requires something different?
From: Christopher R. Barry
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <87678rjg3f.fsf@2xtreme.net>
Daniel Finster <··@nanofab.utdallas.edu> writes:
> > > Not a fat chance at all. 8 year old Lisp hardware still compares quite
> > > favorably with todays systems.
> >
> > 8 year old+ Lisp _software_ compares quite favorably with today's
> > systems. A 20MHz XL1200 has execution speed that is several orders of
> > magnitude less than that of MCL or Allegro CL on a PowerPC or Pentium
> > II. From what I hear, the software functionality makes you not notice
> > this limitation too often, but the're still dog slow.
>
> What I meant was, 8 year old Lisp hardware running the 8+ year old Lisp
> software still compares quite favorably.
Then say what you mean.
> > > I disagree here. In an era of 20MB web browsers, a 2MB Common Lisp
> > > system (looked at Corman Lisp?) doesn't sound like too big of a burden.
> > > Particularly when you go get the JDK and its a whopping 14MB...
> >
> > Uh, the entire Netscape Communicator Professional Edition download is
> > around 15MB. That obviously includes its JVM. The JDK includes the JRE
> > _and_ the stuff you need to compile applications for the JRE.
>
> Compared to a 2 or 3MB CL system, which includes the runtime _and_ the
> stuff you need to compile the applications.
The Allegro CL Linux Trial Edition zip file is 11MB. The
self-extracting Windows version is 21.5MB. The CMUCL .deb archive file
is 13.5MB. Full CL systems in 3MB are the exception, not the rule.
3MB is 3MB too large anyways. There are far more used plugins and
features the Netscape people could bundle if they wanted to make the
base download even more of an inconvenience.
> > > Well, since Java doesn't run properly on every platform, who says we
> > > have to?
> >
> > If that's how you want to reason, fine.
>
> I don't like reasoning that way, actually. I'd prefer that everything
> run properly on every platform. But I was just making the case that
> since Java has proved that none of that is necessary, we look kind of
> silly using that as an excuse to not produce our own offering. Yeah,
> it'd be a sucky, lame Lisp system, but still about 10 times better than
> anything Java does... Now if we did it the RIGHT way, on the other hand,
> we would really win big.
[...]
> Please don't get the idea that I like the idea of making crap software.
> I just kind of figure that if the other guys do it, obviously the market
> won't care if we do it too. So maybe if we got something lame out, we'd
> be in a slightly better position than where we are now.
I think you and I have fundamentally _very_ different views of
reality, and that furthur conversation with you could not serve much
purpose.
> > > Even if it only works on Windows to start with, that'd be a win.
> >
> > It does work on Windows right now with Allegro CL. Apparently you
> > hadn't heard of this _win_ though. What a surprise.
>
> Yeah, I've heard of it.
Well a thread or two ago you were talking about what a "big win" it
would be to have a plugin that only runs one particular vendor's Lisp.
> I've also heard the complaint that it is missing a crucial DLL. I
> also understand that to really use it in the long term, you have to
> buy a very expensive ACL license (correct me if I'm wrong). I meant
> that we need something free.
Yeah, non-freeness is what is stopping Allegro's ultra-cool Windows
Netscape CL plugin from dominating the world. If only those hoarders
would Open Source[TM] it.
[Actually, they do give you the source code for the plugin.]
> > > > 3. You have to copy rather large CL source files over the network
> > > > first and then compile them on the plugin client, and they may then
> > > > execute with absolutely no security. If you compile them first then
> > > > you have to provide binaries for every platform you plan to have your
> > > > plugin run on.
> > >
> > > You could use a byte-complied system such as CLisp, alleviating both
> > > problems.
> >
> > Or compile to Java byte-code, and leverage all of the investing and
> > effort and technology and existing market penetration of Java VMs.
>
> Well, whoever writes this thing (if anyone) will decide on what they
> like best. I prefer being an isolationist and just doing everything in
> Lisp
There's no reason you couldn't do the compiler 100% fully in ANSI
CL. The only system access you really need is character file-io for
the source input and binary file-io for the byte-code output. The JVM
docs from java.sun.com and a Lisp are all you need to make the thing.
(And a _lot_ of time and intelligence....)
> > > As far as security, I see that as a trivial problem to fix. If the
> > > Java language designers can come up with a half-assed solution,
> > > surely we can.
> >
> > Security is not a feature of the Java _language_ (other than some of
> > the benefits strong-typing kinda gives you in this specific respect).
> >
> > If you feel this is so trivial, then I'm looking forward to detailed
> > technical explaination of why. But I have feeling you don't have one.
>
> Because security doesn't seem like a real hard problem.
[Rest of empty reply snipped]
Your reply is not the "detailed technical explaination" of why
security is so trivial that I was hoping for. It is apparent from your
reply though that you didn't understand what was meant by
"security".
Say you do an Altavista search and you click on one of the links your
query returned and had your browser open a page that loads some code
that formats your Windows or Macintosh hard drives, or deletes every
file in your personal Unix /home directory and wherever else it had
permissions to do so. Or say it searched through your disk for
specific types of information and then retransmitted this back to some
host on the internet. You would not be happy.
To give another example, many (all?) executables that you use have a
data segment and a code segment. The code segment is the part that is
executed and the data segment is, well, guess. If this executable,
when run, takes input, it probably reads its input into a buffer. If
it does not take measures to prevent the buffer from being overrun
from its input, such as using the ANSI C gets() function, the program
is likely easily crashable, and quite possibly insecure. The reason
for insecurity is that when the buffer is overun, the data that
overruns the buffer could overwrite some of the data in the code
segment, and this data could then be executed. Several popular Unix
mail agents have been compromised in the past using this
technique. This is only one small example.
With the JVM and with the browser they have taken many measures to
prevent these kinds of things from happening. Supposedly a great
ammount of the start-up time expense of Java programs is the
security-checking related stuff.
Christopher
From: Bulent Murtezaoglu
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <871zjfavhw.fsf@kapi.internal>
>>>>> "CRB" == Christopher R Barry <······@2xtreme.net> writes:
[...]
CRB> To give another example, many (all?) executables that you use
CRB> have a data segment and a code segment. The code segment is
CRB> the part that is executed and the data segment is, well,
CRB> guess. If this executable, when run, takes input, it probably
CRB> reads its input into a buffer. If it does not take measures
CRB> to prevent the buffer from being overrun from its input, such
CRB> as using the ANSI C gets() function, the program is likely
CRB> easily crashable, and quite possibly insecure. The reason for
CRB> insecurity is that when the buffer is overun, the data that
CRB> overruns the buffer could overwrite some of the data in the
CRB> code segment, and this data could then be executed. [...]
AFAIK, it would be a very hard to grow the data segment into the
code segment AND have the your code execute. The buffer overflow exploits
you are describing work by corrupting the stack. This is easier
because the stack frame has a structure known to the exploit author
and is created fresh with that known structure when the buggy function
gets called. This is not so for heap objects as the programs running
history has to be taken into account.
Just nit picking,
BM
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkjww0yetfi.fsf@tfeb.org>
Daniel Finster <··@nanofab.utdallas.edu> writes:
>
> What I meant was, 8 year old Lisp hardware running the 8+ year old Lisp
> software still compares quite favorably. Obviously the raw speeds of
> any of todays processors totally blows the Ivory away. But when the
> Ivory was made, it really blew away the competition. A new Lisp
> processor made with modern technology would blow away any Alpha, I'm
> sure.
No, it really didn't. I don't know the full history of relative
performance, but I remember when the people who made the machines I
used (risc based minis) sent us blurb in 86 or 87 showing their
machines, with kcl, outperforming the current symbolics offering
(which wouldn't have been ivory then, but I'm pretty sure that they
were never really competitive after 87 or so).
Anyway, Alpha *is* a new lisp processor made with modern technology!
Lots of tag bits on a 64bit machine, and you can probably get really
good parallel tag checking given multiple execution units.
Really, I think yearning after the magic hardware fix is a huge
mistake. The interesting thing about LispM's was always the software
I think (well, unless you collect odd microcoded machines, like
me...).
--tim
From: Tim Bradshaw
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <nkj1zjewv67.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> Fat chance. It would be nicer if Intel and major processor vendors
> would some time in the future aknowledge Lisp and put better support
> for type-tagging and checking in hardware. This would certainly help
> out Smalltalk and some other languages and even Java.
I think there's fairly good evidence that tagged hardware is really
not worth it. Ken Anderson (?) has a paper which describes some
preformance testing of a decently optimizing compiler for some very
dynamic language on some RISC platform, and the things that would help
aren't tag bits, but something boring like more registers.
In any case we know that good Lisp compilers can already get within a
small multiple of C (like, less than 2 or something), so the best case
speedup for these things is really small, and probably less than if
you used all those transistors for something else.
> 3. You have to copy rather large CL source files over the network
> first and then compile them on the plugin client, and they may then
> execute with absolutely no security. If you compile them first then
> you have to provide binaries for every platform you plan to have your
> plugin run on.
It's actually easy to write a safe lisp system. You just need to make
sure that READ can do nothing bad (by using a known readtable, setting
*READ-EVAL* nil, and scrupulously trapping errors at read time), and
then walk the resulting form to check it meets some definition of
`safe' -- typically that it only contains symbols from a known set.
You also need to clean up after the form is compiled & evaluated,
typically by nuking any symbols that have got interned in your
protected package. You have to be careful that what you allow is safe
of course.
I wrote a very simple implementation of this in an afternoon once,
which I think would let you run a subset of CL that had LAMBDA, IF,
CONS, CAR, CDR, or some such, as a little demonstration to myself that
we could safely use CL as an extension to a system we had which ran on
the web (in a CL image which spoke HTTP to the client). I don't know
if a CL extension was ever deployed, and if it was it wasn't mine, but
it convinced me that it could be done. (The system was oplan, a
planner, which lives at aiai.ed.ac.uk.)
I could post this or put it up on the web if anyone cared (only, not
this week, because I'm waiting for a scsi card so I can read all my
tapes with this stuff on as well as the rest of my life, an experience
which is proving very frustrating indeed).
So really, that isn't a huge problem I think. Some of the other
things you mention may be.
--tim
From: David J. Cooper
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36D30FFC.AD0955B3@genworks.com>
Kent M Pitman wrote:
>
> ·······@mikemac.com (Mike McDonald) writes:
>
> > Management had three major concerns with using Lisp: [...]
>
> I found Mike's "case study" very interesting and it made me curious for some
> more "statistical" (ok, "anecdotal") information: does everyone else see
> these same barriers to Lisp's acceptance in your work (or school)
> environment?
The bottom line is: Lisp is a high-stakes game, and a lot of people
(e.g. managers) just don't have the stomach for it.
It comes down to a matter of self-confidence and intestinal fortitude.
--
The NIKE approach to LISP:
No Excuses. No Apologies. Just Do It. (-- Erik Naggum)
=======================================================
From: Raymond Toy
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <4nlnhobsrs.fsf@rtp.ericsson.se>
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> Anyway, I'm interested in doing a reality check on my present
Kent> perceptions of how Lisp is presently hampered in acceptance.
I've used lisp several times in my job and there hasn't been any real
major barriers. However, I've also used only free lisp (and scheme)
systems for non-critical (except for one) applications. If I had to
pay a lot, then they might not have been done. In addition, these
things were done for our research group which is much looser on what
tools are used.
1. For the document server for the research group, we used STk for a
GUI for people to submit documents to a database. They retrieved
the documents via the web and a small STk CGI talks to the
database and returns the desired document. This went pretty well,
but no one even knows that Scheme runs the whole system, except
for the web server and database.
2. For a research project on cellular systems, I implemented a system
in Lisp (CMUCL) that, for certain large problems, ran
significantly faster than the equivalent Matlab version. This was
mostly because the vectorized Matlab version wanted to use 100's
of MB of memory that we didn't have, but the Lisp version only
used 20-30 MB. This also worked well, except that I had to work
with other people, so Lisp was definitely out. The final result
was done in Matlab. Results were Ok, but you had to very
carefully design the parameters to scale correctly since we
couldn't simulate the real system parameters because of lack of
memory. Even then the results had to be carefully interpreted
because some of the parameters couldn't really be scaled. I think
Lisp could have done it very well, even for the real parameters.
3. For an authentication system, I used Lisp to generate the desired
random keys. I picked Lisp because it has bignums built in and
because it's interactive so I could explore things easily. This
worked well and is still in use. Of course, besides me, there's
only one other person in the company who would be able to use this
software to generate keys. People have wanted to convert it to C,
but I don't think that's been done yet. :-)
In my current work, I think a Lisp solution would be very nice for
simulating the messaging protocol for a base station and mobile
station, and even implementation would be nice.. I never brought it
up because we have pretty stringent real-time requirements and memory
requirements. I don't know if any lisp could meet these, but I'd like
to know if there are. :-) Besides, I don't think any of the CPU SW
engineers would listen to a DSP SW engineer recommend Lisp for their
platform. ;-) I'd laugh at them if they suggested use Java for our
DSP code.
Not bad for Lisp, but these projects were not mainstream, critical
apps.
Ray
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <w4o4socprni.fsf@nemesis.irtnog.org>
I haven't read the responses to Kent's question yet, but I assume most
of you have been in the business of Lisp for some time. Here's a
different perspective, that of a recent college graduate. I apologize
in advance for the length.
----
I've recently graduated (with a BS in Computer Science) from a 4-year
private engineering school. This school is ranked second or third in
the nation (amongst other highly acclaimed private engineering
institutions such as Harvey Mudd and Cooper's Union). While I myself
am no great scholar (my marks were average, and I tend to Slack Off a
lot), most of my classmates in school are tremendously intelligent and
highly talented (not to mention diligent and hard-working).
The Computer Science curriculum at this private engineering school
(which does three 10-week terms a year, and still manages to cover a
semester's worth of material) is pretty standard. First- and
second-year students learn the basics of algorithm construction and
analysis, basic data and file structures, and simple digital logic.
In the third year, systems programming, programming language theory,
database theory, computational theory, and software engineering. The
fourth year finishes up with electives (e.g. a course in AI or
parallel processing) and a two-term (22-week) engineering project,
usually in cooperation with a local business.
As a student, I learned approximately one new programming language
each quarter: Pascal, Ada, MIPS assembly, Perl, Scheme, Lisp, SQL, C,
C++, Objective-C, Java & JVM byte-codes, etc. The CS department is
very careful not to advocate "One True Language," but instead teaches
"The Right Tool For The Right Job".
Executive summary: Think "lots of very smart, hard working students"
and "challenging curriculum".
----
The student is first exposed to the Lisp family in the third year,
when he takes CS-304, Programming Language Concepts. The course is
taught using _Essentials of Programming Languages_ by Friedman, Wand,
and Haynes. The course covers the lambda calculus, continuations and
CPS, lexical and dynamic scope, object oriented languages, etc. The
EOPL builds interpreters (in Scheme) for an Algol-like functional
language, but the teacher, in an effort to simplify parsing, has
modified the course to have students write a Scheme interpreter (in
Scheme) instead. So much of Scheme gets implemented by the end of the
10-week course that some students are able to interpret their
interpreter.
Programming Language Concepts, along with Theory of Computation, has
traditionally been one of the most difficult CS courses at this
college. (In fact, I flunked the class the first time I took it.)
Students' initial reactions to seeing Scheme for the first time are
confusion and shock. Few students actually master Scheme, and very
few students enjoy it. The first source of confusion is Lisp's prefix
notation. Math courses since first grade have taught students
"1 + 2", or even "(1 + 2)". Functional notation in algebra courses is
always shown "f(x)". Programming languages taught in high school are
usually Algol derivatives (such as BASIC, C, or Pascal) or FORTRAN,
both of which reinforce infix notation. Rarely do math courses teach
students that mathematic notation is arbitrary and flexible, so
students have a hard time understanding "(+ 1 2)" or "(f x)".
Languages in the Algol family look alike, so going from language to
language isn't too difficult. A FOR loop looks like a FOR loop,
whether you're programming in BASIC, Pascal, Ada, or C. It is like
the Indo-European language family: Sure, French, English, German,
Latin, and Greek are all very different languages, they have a lot in
common (common alphabets, or common words, similar grammars, etc.), so
learning a new Indo-European language when you've mastered two others
isn't too difficult.
In this analogy, FORTRAN is like Polish. ;)
The Lisp family looks wildly different than anything in the Algol
family. I'm convinced that if Programming Language Concepts was
taught using ML or Dylan (or something Algol-like), students' wouldn't
have such a hard time with the course. To stretch the analogy
further, I'd say going from Algol to Lisp is like going from English
to Chinese. Chinese has no common structure with any of the
Indo-European languages, although it expresses the same kinds of
things that any human language expresses.
(Personally, I find Lisp's prefix notation to be very clean and easy
to understand. I never have to worry about operator precedence, as I
often must in C.)
----
Lisp's powerful language extension facilities (Common Lisp's DEFMACRO
and Scheme's DEFINE-SYNTAX) are "hard" to use and difficult to master.
Even the simple macro facilities provided by C/C++ give students a
hard time, and to my (admittedly incomplete) knowledge, no other
programming languages provide any such macro facility. Macros are
very powerful---Lisp just wouldn't be Lisp without them---but for some
reason, macros cause students a lot of trouble.
----
There's also a tremendous bias against Lisp, reinforced, in part, by
its unusual notation and interactive nature. Lisp is seen as being
esoteric---it's "only for artificial intelligence," or "something only
researchers or academics use". The myth of Lisp being only an
"interpreted" language prevails, invoking many comparisons with
(horror of horrors!) BASIC.
(In fact, one of the reasons I've asked so many questions about batch
compiling Lisp is because that's how almost EVERYBODY interacts with a
programming language.)
----
Lisp is very old, the second oldest language still in active use.
When I mentioned to an older colleague that I was working on a batch
compiler for Lisp, he stared at me in surprise. "You're writing a Lisp
compiler?" he exclaimed. "Good God, whatever for! Lisp was old when
*I* was in college [in the early seventies]." In a field where
technologies change at an increasingly rapid pace, old languages such
as Lisp, FORTRAN, and COBOL <spit> are seen as being antiquated,
useless for "real world [i.e. modern] problems".
And they're right, except in the case of Lisp. ;)
A related aside:
As a naive freshman, I came to this world-class (not to mention
EXPENSIVE) engineering institution to learn how to use the tools and
technologies of the day. I thought I would be taught all the latest
buzzwords...object oriented programming languages like C++ or
Objective-C (NeXT was still in vogue in 1994, and my school had
several labs full of NeXT pizza boxes and cubes)...languages for
"serious hacking" like C or assembler...etc.
So I walked into my first programming class of my college career, all
of these expectations in my head, paying a tuition only slightly less
astronomical than Jupiter, and they started talking about Pascal!
But Pascal was incredibly ancient! No one used Pascal for anything in
the Real World! What a worthless, useless language! Everyone used C
or C++, both of which were certainly a whole lot newer than Pascal.
Why, all the UNIX hackers used C...keep in mind, Linux was just coming
into its own around 1994, when I started college. I wanted nothing
more than to become a UNIX hacker, a C demigod, etc, etc. I was a
wannabe back when BBSes were still popular, and I desperately wanted
some kind of "37337 haxor" status.
It took me less than two hours to master most of Pascal. It took me
two minutes more to start to hate it.
I ranted. I raved. I told my profs what a worthless language Pascal
was. "Why," I said, "even BASIC is better than Pascal" (mostly
because Pascal string manipulation is heavily brain-damaged). My
profs were very good. They put up with me, and eventually it began to
sink through my thick skull that it wasn't the language that they were
teaching me, it was the IDEAS...ideas like recursion, or algorithmic
analysis, or how to create useful data types, or any of the other
stuff that a CS curriculum worth its salt tries to teach its students.
If I hadn't become a pretty heavy EMACS user by the time I was exposed
to Lisp (my second year of college), my initial reaction to Scheme
would have been much the same as my initial reactions to Lisp and Ada:
"This isn't a real-world language", "it's incredibly crufty and
useless", and "why aren't you teaching me a Real Language like C?"
Instead, I'd already seen Lisp in action and was on my way to
appreciating its hackish nature.
----
In summary, the barriers to Lisp's acceptance by the college crowd are
manifold:
1) Lisp's functional semantics and prefix-form syntax is unlike
anything J. Random Freshman has ever seen.
1a) Lisp's syntactical mutability (e.g. DEFMACRO), while
powerful, can be confusing to the neophyte.
1b) Closures, the lambda calculus, and automatic memory
management are also initially confusing/surprising.
2) Lisp's interactive nature reinforces the "interpreted-only" and
"slower than C" myths.
2a) It is way too easy to write code that performs poorly in
Lisp.
2b) According to urban legend, even compiled Lisp code doesn't
perform as well as compiled C.
2c) Systems hackers don't use Lisp or Scheme, choosing C or
assembler instead.
3) Lisp's lack of popularity for applications and systems programming,
along with its age, conspire to form a kind of negative feedback loop
that dissuades programmers from investigating its powerful facilities.
3a) I have yet to hear of a CIS curricula that teaches Lisp,
although every CIS curriculum I know of teaches FORTRAN and
COBOL <spit>.
3b) Few CS curricula use Lisp in non-AI course work or
research.
Hope this helps, Kent.
--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b
"When I was a kid, I used to think that Dammit was God's last name, just like
Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
From: Johan Kullstam
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <m2btik4jx9.fsf@sophia.axel.nom>
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <········@irtnog.org> writes:
> The first source of confusion is Lisp's prefix
> notation. Math courses since first grade have taught students
> "1 + 2", or even "(1 + 2)". Functional notation in algebra courses is
> always shown "f(x)".
<gratuitously pedantic mode>
not true.
functional notation in *algebra* courses is almost always shown "xf".
this is so that "f o g" is first apply "f" then "g" as in "xfg". in
group theory (especially looking at it as permutations) you don't care
so much about the "x" part and fixate on group product "fg".
you get "f(x)" from *calculus*.
</gratuitously pedantic mode>
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Harvey J. Stein
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <m2emngdtxg.fsf@blinky.bfr.co.il>
Johan Kullstam <········@ne.mediaone.net> writes:
> "His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <········@irtnog.org> writes:
>
> > The first source of confusion is Lisp's prefix
> > notation. Math courses since first grade have taught students
> > "1 + 2", or even "(1 + 2)". Functional notation in algebra courses is
> > always shown "f(x)".
>
> <gratuitously pedantic mode>
>
> not true.
>
> functional notation in *algebra* courses is almost always shown "xf".
>
> this is so that "f o g" is first apply "f" then "g" as in "xfg". in
> group theory (especially looking at it as permutations) you don't care
> so much about the "x" part and fixate on group product "fg".
>
> you get "f(x)" from *calculus*.
>
> </gratuitously pedantic mode>
Ok. If we're going to get pedantic about it, that's just how
Herstein's 'Topics in Algebra' does it. Most other texts reverse the order.
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
From: David Combs
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <dkcombsF7oL5s.3GF@netcom.com>
Without lisp, how do you teach the powerful idea
of "matching"?
I'm just an undergraduate and don't have any industrial experience but
Lisp is not very well known at my college as far as I can see. I don't
think it is used for any courses and I'm not sure that many of the
academics have any great knowledge of it. I think I've benefited from
the lack of knowledge sometimes though: when submitting coursework in
Lisp I think that I've been given the benefit of the doubt even when
I've done something wrong.
When I asked if Common Lisp or Scheme interpreters were available on
the computing department's system I was told that you could only get
compilers for CL(!) (they didn't have any installed and my quota
didn't stretch to CMUCL) and was pointed to "lists" for the
Z-Machine[0] for Scheme. The only references to Lisp in courses that
I've noticed were
i) in a compilers course after dynamic binding had been introduced we
were told that no major language used it except Lisp,
ii) in an AI course (offered by the EE department) the choices for
logic programming were presented as Prolog or "Lisp (spit!)".
UMB-Scheme is installed now but I think it may simply be a standard
Red-hat package. The only exposure most people have to Lisp is from
Emacs (the mechanical engineering students don't always seem to know
about AutoLisp). The computing library has 1 copy of CLTL2, 1 of an
introduction to CLOS (I cannot remember the exact title but it is the
standard one), 1 of _Lisp_, 1 of _The Art of the MOP_, references for
Interlisp and Maclisp and several on Lisp v1.5. With this background
it is no wonder that Lisp is unpopular in the big wide world.
[0] The Z-Machine was Infocom's virtual machine for their text
adventure games. Andrew Plotkin has implemented a Scheme interpreter
on them.
--
Gareth Jones
From: David Combs
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <dkcombsF7oKxD.32M@netcom.com>
In article <··············@gdjones.demon.co.uk>,
<snip>
>i) in a compilers course after dynamic binding had been introduced we
>were told that no major language used it except Lisp,
What about perl, via (stupidly named) "local"?
·······@netcom.com (David Combs) writes:
> In article <··············@gdjones.demon.co.uk>,
> <snip>
>> i) in a compilers course after dynamic binding had been introduced we
>> were told that no major language used it except Lisp,
>
> What about perl, via (stupidly named) "local"?
I didn't say the lecturer was right; I was just indicating that his
knowledge was either out of date (he implied that Lisp only used
dynamic binding) or second-hand. The point is that Lisp is only ever
referred to in passing, if at all, and never as a useful language. I
would imagine that an academic in a computer science department would
have somewhat less exposure to Perl than he would to Lisp anyway.
--
Gareth Jones
From: Kent M Pitman
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <sfwvhgndg05.fsf@world.std.com>
General rambling on the goodness/badness of special variables and
languages containing them follows. Press "delete" now if you don't
have any patience for such...
····@gdjones.demon.co.uk (Gareth Jones) writes:
>
> ·······@netcom.com (David Combs) writes:
>
> > In article <··············@gdjones.demon.co.uk>,
> > <snip>
> >> i) in a compilers course after dynamic binding had been introduced we
> >> were told that no major language used it except Lisp,
There was a time when no major language used functional abstraction or
variable structure definition or strong typing. Statements like this
are suspect without a metric of when they can be usefully applied to
head off bad things and when they cannot be usefully applied because
they will head off good things. If this is a useful metric of goodness,
it must be applied uniformly; since it's not, it must be incomplete in
a material way.
I could make an analogy to heads of state, lying under oath, the question
of whether politicians lying must be removed from office, the question
of whether all politiicans lie, the issue of selective prosecution, and
the general issue of how "hypocrisy" is implemented in political systems.
But I understand we're in a "time of healing" now and we're supposed to
talk about other matters for a while, so I'll endeavor to comply by
picking different analogies (see below).
> > What about perl, via (stupidly named) "local"?
>
> I didn't say the lecturer was right; I was just indicating that his
> knowledge was either out of date (he implied that Lisp only used
> dynamic binding) or second-hand. The point is that Lisp is only ever
> referred to in passing, if at all, and never as a useful language. I
> would imagine that an academic in a computer science department would
> have somewhat less exposure to Perl than he would to Lisp anyway.
Scheme has an on-and-off thing about specials. People keep trying to
remove them because they are problematic. My analysis is that this is
foolish because they are an artifact of the world and to ignore them is
to ignore the physics of the world--that some things are dependent on
world state and not usefully reduced to lexical closures and explicit
arguments as a matter of practice. A programming language might as well
mirror reasonable and anticipatable characteristics of the world, or else
expect that when people try to simulate them they will do a clumsy job
that the compiler will fail to understand and will not compile well.
Dynamic variables and global state are a pratical reflection of an
inescapable reality that are there to make programming easier to by not
making you work so hard to get the behavior you know is there.
Straightforwardly modeling an automobile toll booth, for example, is
not usefully done by making it a function of a car and a toll
collector. No one cares who the toll collector is 99% of the time and
it would be horrible to make every abstraction of a queueing model
take two arguments to simulate going through the booth. Yet once in a
while if a booth isn't working, you do need to be able to check who is
there and ask why one booth is going slowly and if you don't know who
the person in it is, you might not get the answer. Modeling the booth
as a closure is similiarly problematic because you must replace the whole
object which is the toll booth, destroying its "object identity", when
you change the toll collector. Something like special variables (or its
generalization through dynamic-wind in Scheme) is what gets you the power
to describe systems like that succinctly. (Even with dynamic-wind, which
you might argue is more general, you eventually realize that you're working
in idiomatic ways and end up with something like dynamic-let [eulisp]
or letf [lisp machine].)
Ideas that deny reality never quite work and the road leads back to
the truth, even if by a somewhat overly long path. The reason Lispers
complain so much about the alternatives isn't that they fear a
language with equivalent expressive power, it's that they secretly
know somewhere in their hearts that by some metric other languages
aren't equivalently expressive. (I'm not Turing power here, but
something I call personally call "expressive power" which is not about
computability but which instead measures a language's power to make
typical programs perspicuous by supporting constructs that map neatly
onto typical real-world problem spaces--for the information theorists,
lest they think I am conjuring this benefit out of nowhere without
conserving something, I think this attribute comes at the expense of
such languages probably being painful to use on problems people don't
have a serious need to compute. And I think the world is asymmetric
in that there are such things that are not as interesting to compute
as others. My feeling is that by sacrificing some things that I don't
care about computing, I can get a better handle on things I do. In
some sense, I think C-only programmers do the same thing when they
choose not to use Lisp. The choice of what things you want to compute
is subjective at some level. But languages are more interestingly
compared and something interesting is learned about the people using them
if you focus on a metric that allows programs to be seen as different
instead of, as computer people have done for ages, making the useless
and boring claims of "Turing power" implying equivalent expressiveness.)
I guess what I'm saying is that I'll be ready to remove special
variables from Lisp the day someone says that they're not used by the
people who have and like the language. It's very uninteresting to say
that people who don't have the tool don't use it--people never had the
world wide web and did fine without it. Surely it's unreasonable to
claim that people not having the web are proof it's not useful. You have
to go ask the people who do have it. Many people having special variables
do use them. I never begin with the assumption I will use them in any
given program, but they do end up getting used in a large number of my
programs for one or another reason.
A discussion that tries to kill a useful feature is not a "practical"
discussion but a "religious" one. People can assert the world was better
without TV or the WWW but not on the basis of use, expressivity, progress,
etc. One has to stop and say "The world was better when all we did was
garden." That's a valid statement and I don't mean to rail against it.
But it is pretty much incompatible with the notion of "science" and
"progress" and "free market society" since those things are not about
stability and not about "whether everyone is fed tomorrow".
From: Rob Warnock
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7bbdah$9hqgf@fido.engr.sgi.com>
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Scheme has an on-and-off thing about specials. People keep trying to
| remove them because they are problematic. My analysis is that this is
| foolish because they are an artifact of the world and to ignore them is
| to ignore the physics of the world--that some things are dependent on
| world state and not usefully reduced to lexical closures and explicit
| arguments as a matter of practice. A programming language might as well
| mirror reasonable and anticipatable characteristics of the world, or else
| expect that when people try to simulate them they will do a clumsy job
| that the compiler will fail to understand and will not compile well.
| Dynamic variables and global state are a pratical reflection of an
| inescapable reality that are there to make programming easier to by not
| making you work so hard to get the behavior you know is there.
+---------------
Most Schemes I've used have "fluid-let" or equivalent, which gets you
*that* style of dynamic usage of globals. And any Scheme can implement
a "mutable closure" for a slightly different style:
> (define (make-param remembered-value)
(lambda new
(if (null? new)
remembered-value
(set! remembered-value (car new)))))
> (define foo (make-param 'this))
> foo
#<procedure>
> (foo)
this
> (foo 'that)
> (foo)
that
>
Then (as you noted) you can use dynamic-wind [well, in an R5RS Scheme]
to set/restore the value of the closed-over variable:
> (let ((old (foo))
(new 'something-else))
(dynamic-wind
(lambda () (foo new))
(lambda () (display (foo)) (newline))
(lambda () (foo old))))
something-else
> (foo)
that
>
MzScheme formalizes this even further with the notion of a "parameter" type:
http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node99.htm
A parameter is a procedure that stores and retrieves the state of
some value. For example, the "current-output-port" parameter stores
a port value that is used by display when a specific output port
is not provided. The current value of a parameter is obtained by
applying the parameter procedure to zero arguments. The value of
a parameter is set by applying the parameter procedure to a value.
[The result of a parameter-setting application is void.] For example,
(current-output-port) returns the current default output port, while
(current-output-port p) sets the default output port to "p".
http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node116.htm
make-parameter v [guard]) returns a new parameter procedure. The
value of the parameter is initialized to v in all parameterizations.
...
The "parameterize" syntactic form temporarily sets the value of a
parameter while evaluating a body expression, and then restores
the parameter value before returning the result of the body. The
syntax of "parameterize" is:
(parameterize ((parameter value)...) body-expr...)
The result of a parameterize expression is the result of the last
body-expr. During the evaluation of the body-exprs, each parameter
is set in the current parameterization to the corresponding value.
Once the body-exprs are evaluated, each parameter is restored to
its value from before evaluating the parameterize expression.
[I left out a lot more having to do with "parameterizations", which are
related to MzScheme's system of multiple namespaces & threads.]
So my above example using MzScheme "parameters" would be:
> (define foo (make-parameter 'this))
> foo
#<primitive:parameter-procedure>
> (foo)
this
> (foo 'that)
> (foo)
that
> (parameterize ((foo 'something-else))
(display (foo))
(newline))
something-else
> (foo)
that
>
The main things MzScheme "parameters" give you over hand-crafting the
same thing with a macro around dynamic wind are (1) some error checking
[since a "parameter-procedure" is a different type than plain "procedure"],
and (2) its notion of "parameterizations", which supports having selected
sets of parameters change automatically when you switch between threads
[if you have threads avaiable to worry about, that is].
The somewhat-long-winded point being: I think most of the current active
implementors of Scheme(s) would agree that dynamic variables -- or something
that looks like them [such as the above] -- *are* occasionally "just the
right thing"...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Dorai Sitaram
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7bbo3a$ehe$1@news.gte.com>
In article <············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>Kent M Pitman <······@world.std.com> wrote:
>| Scheme has an on-and-off thing about specials. People keep trying to
>| remove them because they are problematic. My analysis is that this is
>| foolish because they are an artifact of the world and to ignore them is
>| to ignore the physics of the world--that some things are dependent on
>| world state and not usefully reduced to lexical closures and explicit
>| arguments as a matter of practice.
>
>Most Schemes I've used have "fluid-let" or equivalent, which gets you
>*that* style of dynamic usage of globals.
Indeed. However, I've always thought that a
Scheme-like fluid-let may be more problematic for
Scheme than it would be for Common Lisp, because it
frustrates our take-it-for-granted expectation of
tail-call optimization. (Common Lisp doesn't hold out
this expectation, and so doesn't have the problem of
having to cater to it.)
Example:
(define *x* 0)
(let loop ()
(fluid-let ((*x* (+ *x* 1)))
(display *x*)
(newline)
(loop)))
--d
From: Rob Warnock
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7bdtge$9nc9t@fido.engr.sgi.com>
Dorai Sitaram <····@bunny.gte.com> wrote:
+---------------
| Rob Warnock <····@rigden.engr.sgi.com> wrote:
| >Most Schemes I've used have "fluid-let" or equivalent, which gets you
| >*that* style of dynamic usage of globals.
|
| Indeed. However, I've always thought that a Scheme-like fluid-let may be
| more problematic for Scheme than it would be for Common Lisp, because it
| frustrates our take-it-for-granted expectation of tail-call optimization.
| (Common Lisp doesn't hold out this expectation, and so doesn't have the
| problem of having to cater to it.)
| Example: [deleted]
+---------------
Yes, uh, well, umm... "It hurts when I do this." "Well, don't..." ;-}
Seriously, though, the "fluid-let" style [or anything similar, based on
dynamic-wind, say] *implies* a non-tail call, yes? 'Cause you want the
value to be set *back*, yes? So failing to preserve tail-call optimization
shouldn't come as a surprise.
If you want to mix "dynamic variables" with tail calls, I suggest that
the other style I mentioned, "parameters", might work better:
(define *x* (make-parameter 0)) ; built into MzScheme but can be
; written with closures
(let loop ()
(*x* (+ (*x*) 1))
(display (*x*))
(newline)
(loop))
On MzScheme this version ran for over 100K loops (when I got tired watching)
with no evidence of increased memory usage, while the fluid-let version
started paging noticably at ~15K and crashed at ~40K:
...
40036
40037
40038
40039
Out of Memory! Returning NIL!
Segmentation fault (core dumped)
%
-Rob
p.s. I suspect I wouldn't use the CL "*foo*" naming style for "parameter"
closures, since invoking them (*foo*) looks too much like a Pascal comment!
On the other hand, just a leading "*" makes it look somewhat like a C function
pointer, (*foo (1+ (*foo))). [Hmmm... A good thing or a bad thing? ;-} ]
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: cdm
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <7benbj$cf$1@remarQ.com>
Rob Warnock <····@rigden.engr.sgi.com> wrote in message
·················@fido.engr.sgi.com...
>
>Seriously, though, the "fluid-let" style [or anything similar, based on
>dynamic-wind, say] *implies* a non-tail call, yes? 'Cause you want the
>value to be set *back*, yes? So failing to preserve tail-call optimization
>shouldn't come as a surprise.
Not exactly. The top-level binding must, of course, be restored, but the
intermediate bindings you make each time around the loop need not
be restored. So, if the implementation is clever enough, a fluid-let
could be tail-recursive. It is probably unreasonable to expect this if
fluid-let is implemented in terms of dynamic-wind (maybe not, though.
If the dynamic-wind were tail-called, and it's entry and exit thunks
satisfied certain properties, perhaps....)
~jrm
[Subject was ``Re: Barriers to Lisp acceptance - a "survey" question''
in comp.lang.lisp, but this sub-thread has drifted *way* off-topic
and off-group, even. So followups to comp.lang.scheme...]
cdm <···@pacific.net> wrote:
+---------------
| Rob Warnock <····@rigden.engr.sgi.com> wrote:
| >Seriously, though, the "fluid-let" style [or anything similar, based on
| >dynamic-wind, say] *implies* a non-tail call, yes? 'Cause you want the
| >value to be set *back*, yes? So failing to preserve tail-call optimization
| >shouldn't come as a surprise.
|
| Not exactly. The top-level binding must, of course, be restored, but
| the intermediate bindings you make each time around the loop need not
| be restored. So, if the implementation is clever enough, a fluid-let
| could be tail-recursive.
+---------------
Yes, while replying to a similar side message from Dorai Sitaram, I
finally realized that both of you are correct. My apologies for not
seeing it sooner.
One way might be for the fluid-let to look at its own continuation,
and if that continuation is some sort of magic "fluid-let frame" that
contains a "restore" of the variable it's about to change, just pass
that continuation on to the body of the fluid-let without building a
new "restore" frame. And by hanging a *set* of variables on the magic
continuation, you could even handle things like the following with a
small stack (though there are some subtleties to worry about in case
one of those intermediate functions, like "perverse-func" below, captures
*its* continuation):
(define *x* 0)
(define *y* 1)
(define *z* 2)
(let loop ((n 0))
(fluid-let ((*x* (1+ *x*)))
(some-func)
(nuther-func)
(fluid-let ((*y* (* *y* 2)))
(perverse-func)
(stuff-other)
(fluid-let ((*z* (expt *y* *x*)))
(format #t "~s ~s ~s~%" *x* *y* *z*)
(if (> *x* 10000000)
(list *x* *y* *z*)
(loop (1+ n)))))))
+---------------
| It is probably unreasonable to expect this if fluid-let is implemented
| in terms of dynamic-wind (maybe not, though. If the dynamic-wind were
| tail-called, and it's entry and exit thunks satisfied certain properties,
| perhaps....)
+---------------
Well, I haven't thought that part completely through, but those "certain
properties" would have to be *awfully* restrictive if you're going to be
able guarantee that you can "fold" multiple logical invocations of the
"after" thunks into *one* invocation. [Folding multiple "restore"s of
a variable is *trivial*, by comparison...]
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
In article <··················@world.std.com>, Kent M Pitman wrote:
> does everyone else see these same barriers to Lisp's acceptance in your work
> environment?
[...]
> What barriers have people recently seen first-hand to Lisp's acceptance in
> their own working experience at their present or some recent organization?
Yes, I've seen a very strong barrier: simple market penetration.
I work for a software startup. One constraint was: produce high-quality
software quickly. This suggested Lisp. But the real downside that we
experienced was:
1. Much harder to find additional (experienced!) programming staff to add to
software team.
2. Loss of customer confidence: A standard practice in dealing with a startup
is to put the source code in escrow. That way if they rely on our products,
but then we go bankrupt, they can take over and maintain the code
themselves. Only, NOBODY wanted the burden of trying to deal with Lisp
source code, so this typical escrow option was not able to address their
startup concerns.
3. Barrier to acquisition: A company taking over our startup looks at the
intellectual property, and imagines plugging it in to their existing
organization (and, presumably, expanding the use of the technology/IP).
Their existing organizations were basically never Lisp-capable.
FYI: The decision we eventually followed was to write the initial core of the
software in Lisp using a very small team. All further engineering hires were
Java programmers, and most of additional work on the product now takes place
on the Java side. The two processes (Lisp & Java) communicate with each other
through TCP channels using an internal language, and it appears to be a single
product to our customers.
> If you could change just one thing about Lisp itself or about some
> Lisp vendor's implementation or packaging, what would it be?
I don't know of anything a Lisp vendor could do that would have helped us out,
other than being more successful in the marketplace. Lisp itself is a fine
and well-designed language, as I'm sure most of us already know.
-- Don
--
Don Geddis ······@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
From: Jason Trenouth
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <370d8183.543742187@newshost>
On 24 Feb 1999 23:49:37 GMT, ······@meta.Tesserae.COM (Don Geddis) wrote:
...
> FYI: The decision we eventually followed was to write the initial core of the
> software in Lisp using a very small team. All further engineering hires were
> Java programmers, and most of additional work on the product now takes place
> on the Java side. The two processes (Lisp & Java) communicate with each other
> through TCP channels using an internal language, and it appears to be a single
> product to our customers.
>
> > If you could change just one thing about Lisp itself or about some
> > Lisp vendor's implementation or packaging, what would it be?
>
> I don't know of anything a Lisp vendor could do that would have helped us out,
> other than being more successful in the marketplace. Lisp itself is a fine
> and well-designed language, as I'm sure most of us already know.
Maybe one thing we can help with now is a CORBA solution for Java/Common Lisp
communications. Both Harlequin and Franz have commercial CORBA ORB's for
Common Lisp. There's no need to build your own comms infrastructure for Common
Lisp these days, unless you have very specific constraints.
__Jason
I wrote:
> > The two processes (Lisp & Java) communicate with each other through TCP
> > channels using an internal language, and it appears to be a single product
> > to our customers.
In article <··················@newshost>, Jason Trenouth wrote:
> Maybe one thing we can help with now is a CORBA solution for Java/Common Lisp
> communications. Both Harlequin and Franz have commercial CORBA ORB's for
> Common Lisp. There's no need to build your own comms infrastructure for
> Common Lisp these days, unless you have very specific constraints.
Excellent point. When I was looking into this issue a year ago, the CORBA
implementations seemed to be very new (beta quality?), and I decided not to
rely on them out of fear of bugs and possible performance problems.
Revisiting the decision today, I might well adopt Corba for the Lisp/Java
connection.
-- Don
--
Don Geddis ······@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
From: Kristoffer Kvello
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36dd8232.5455404@news1.telia.com>
On Tue, 23 Feb 1999 14:03:07 GMT, Kent M Pitman <······@world.std.com>
wrote:
>Anyway, I'm interested in doing a reality check on my present perceptions of
>how Lisp is presently hampered in acceptance.
>
>What barriers have people recently seen first-hand to Lisp's acceptance in
>their own working experience at their present or some recent organization?
I tried to get people at my former employer interested when we bought
a copy of LWW, since the company was originally a lisp based one (they
switched to Smalltalk when the lisp machines disappeared and now do
C++ and Java in addition to ST), and many of the old-timers are still
there. But from what I could tell, most were quite indifferent, if
polite.
I don't have much experience with non-lisp languages (I programmed in
Turbo Pascal for one year when I was a student and a little in Visual
Basic) and I am simply not able to explain to anyone why lisp is
significantly better than say Java or Smalltalk. From what I read on
this newsgroup, it seems clear that lisp is enough better to be worth
examining for a serious programming shop (but if Smalltalk had
multiple inheritance, what would the difference between the power of
the two languages be?). However, the lisp environments must be about
equally pleasant to use as the competition, and that means a pretty
IDE and a source code stepper. The lack of these things is a serious
barrier, I think.
I don't think the parentheses and prefix syntax is an issue. Maybe on
the contrary: it touches some kind of "real programmers can read
unreadable code" attitude (and it only takes about 2 weeks to get used
to anyway).
From: Arthur Lemmens
Subject: Re: Barriers to Lisp acceptance - a "survey" question
Date:
Message-ID: <36E39568.1B31173D@simplex.nl>
Kent M Pitman asked:
> What barriers have people recently seen first-hand to Lisp's
> acceptance in their own working experience at their present or some
> recent organization?
For me, the biggest 'barrier to Lisp acceptance' has always been
the fact that it needed more memory than the competition (C or C++)
for the rather small programs I'm usually asked to write. Until
about two years ago, this was a critical barrier for my standard
target platform (yesteryear's Wintel PC's).
Fortunately, the situation has changed a lot in the last few years.
Many of my clients now have machines with at least 32 MB RAM.
And on the Internet, it doesn't matter how much memory the users
have as long as they can run a browser.
So I bought Harlequin Lispworks in April 1998. Since then
I've finished three small (but paying) projects with Lispworks
and I'm close to finishing a fourth one. I am very happy that
I can earn (part of) my living using the language that I fell
in love with 14 years ago. For me, Lisp is not dead, dying or
doomed. On the contrary: it's finally starting to bear fruit
after a 14 year germination period.
Getting back to Kent's question, in my current situation
the most important barriers are:
1. Users still need more than 16 MB for running a GUI program in
Harlequin Lispworks on Windows 95.
2. Some of my clients still require Windows 3.1.
3. Lack of libaries for stuff like HTML generation/parsing, regular
expressions, TCP/IP, POP, SMTP, different character sets,
graphics formats like GIF or JPEG, etc.
> How would you prioritize those in terms of how "fatal" they are?
Right now, none of these barriers are fatal for me.
I've probably missed a few projects because of barrier [1] and [2],
but I can survive without them. Both barriers will become less and
less relevant in the future. Barrier [3] is not really a problem for
me. When I need something badly enough, I'm happy to invest some
time and hack a workable solution in Lisp.
> Any obvious things the vendors could/should be doing to fix
> them?
For me personally, the most obvious improvement would be for
Franz to lower their prices and get rid of their runtime license
fees. That way, I would have a choice between Harlequin and Franz.
At the moment, my only realistic option is Harlequin's Lispworks.
> If you have had success getting past them, what strategies have you
> used?
One of the projects I'm currently working on is, in the words of
my client, "an Internet interface to a bibliographic database".
The system manager of the server on which this would have to run
told me he would only accept Perl scripts on his server and
nothing else.
That sounded like a pretty big 'barrier to Lisp acceptance'.
So I had almost resigned myself to the prospect of spending part
of my Christmas holidays on learning yet another scripting language,
when it dawned on me that there was a better way: I could write
a Lisp program to analyze the database and generate the necessary
HTML-files plus some very simple Javascript-stuff for the search
interface. That way, the server wouldn't have to run any scripts
at all.
The general strategy is: if you can't write it in Lisp,
generate it with Lisp. Do as much of the processing as possible
at compile time instead of run time. That way, you have a good
chance of using Lisp for the interesting stuff at compile time.
The requirements ("you can only use C, or Perl, or ...") on the
run time part are much more acceptable this way. First, there's
less of it. Second, when you're lucky, you can actually generate
it in Lisp.
This strategy works quite well for me.
The software world is a very complicated system with lots
of different niches. I think I'm slowly growing into a niche
where I'll be able to use Lisp for almost all my work and
I'm very happy with that prospect. It would be interesting
to hear more about Lisp niches that other people have found.
Arthur Lemmens
From: Rob Warnock
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7avncg$86007@fido.engr.sgi.com>
Mike McDonald <·······@mikemac.com> wrote:
+---------------
| ... When I worked at SGI, I was given the task of writing a system for
| collecting and analyzing traces of the operating system. The analysis
| portion was ideally suited for Common Lisp and CLIM. So I contacted Franz
| and got an evaluation copy so I could prototype the app. After completing
| the demo and presenting the advantages of using Lisp over C/C++ ...
+---------------
Wow! I never knew anything in Lisp had even gotten *that* far at SGI!! ;-}
+---------------
| ... management decided that Lisp could not be used for the implementation
+---------------
Bummer.
+---------------
| ...C based culture. Very few engineers at SGI have much experience,
| if any, in using Lisp for engineering problems. (Hi Rob!)
+---------------
Yes, I'm still here. And still occasionally hacking in Lisp
(well, mostly in Scheme). But only on personal or non-critical
"internal tools", never "products"...
I have one tool written in Scheme that gets used by others (a sort of
"peek/poke" tool to help bring up new hardware), but even to get *that*
accepted I had to glue an infix front-end on it. So to (say) increment
to contents of a memory-mapped register, instead of saying:
> (w32! reg-addr (+ (r32 reg-addr) 1))
you say [somewhat reminiscent of Tcl]:
> w32 reg_addr [r32 reg_addr]
And instead of:
> (define incr-mem! (lambda (addr) (w32! addr (+ (r32 addr) 1))))
> (incr-mem! #x80001234)
>
You say:
> def incr_mem = fn addr in w32 reg_addr [r32 reg_addr]
> incr_mem 0x80001234
>
[Yes (*sigh*), I had to make the "0x" form of hex numbers work,
so they could cut&paste from C header files!!]
+---------------
| (At my current company, I also wasn't allowed to use Lisp for a well suited
| project. So I implemented a small lisp interpreter for it. But since my boss
| has no idea what my product does, I have been able to get away with it.)
+---------------
Yes, as always, "forgiveness is easier to obtain than permission". ;-} ;-}
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
John Morrison <··@nospam.mak.com> wrote in message
·······················@news.tiac.net...
...
>(1) Based upon my experience, most of us must implement GUI-based
>applications because our target customers will not consider
>command-line-based applications (this seems to become increasingly
>true as either vendors' competition increases, or the solutions in the
>problem domain "mature"). Considering that GUIs tend to be
>code-intensive, the ease with which we can implement them is of
>paramount importance.
Nobody prevents you to do GUI in LISP.
If you want to implement a pure Micro$oft's Windows UI, all the commercial
lisps allow you to call the Win32 API directly. It's then easy to design a
fully "designed for NT/98" Windows application.
...
>The Law of Increasing Returns will assure that languages like Lisp,
>and Smalltalk, and Ada (even with billions of US DoD backing) will
>become increasingly marginalized. Anybody who reads this newsgroup
>and/or worked at one of the Lisp hardware/software companies will
>attest to this phenomenon.
I don't attest this phenomenon.
...
>technology. So, Lisp adoption rate continues to fall ever behind
>C++/Java adoption rate. I feel that I would have more luck pushing
...
For us the only limiting factor for using lisp was the memory cost and it's
not the case anymore.
AFAIK lisp is even gaining new markets in the industrial field because more
and more people are fed up with C++ applications that blow up every now and
then and they want software that works 24h/day and 7 days/week.
Marc Battyani
From: David B. Lamkins
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <qCgy2.33648$202.16076943@news1.teleport.com>
In article <·················@2xtreme.net> , ······@2xtreme.net (Christopher
R. Barry) wrote:
> ···@crl3.crl.com (Bradley Yearwood) writes:
>
>> Could someone please remind me of what exactly we gain by abandoning
>> Lisp and moving to Java?
>
> Well...
>
> * You can download a full, uncrippled Java implementation + IDE for
> any major platform absolutely free, and in the case of the JDK even
> get the source code. AFAIK you can only do this with the Unix
> platform for Common Lisp.
There are downloadable versions for Mac (Digitool trial version, and Roger
Corman's $50 shareware), PC (both Franz and Harlequin), and Linux (Franz
full version). Digitool will give you a 30-day evaluation key for the
asking. Franz's Linux version is for noncommercial use.
OTOH, if you're developing a commercial application, Lisp vendors require
that you pay for a supported version of the product (and sometimes, even for
a distribution license).
If you're building a product that can't reasonably be done except in Lisp --
and there _are_ products in that space -- then the extra cost is
justifiable. Face it, you're going to pay one way or another. Hidden costs
that I've seen with "low-cost and popular" IDEs are: lost time to market,
extra programmers, tracking down vendor bugs, being blocked 3 to 9 months
for a release that fixes a problem in the compiler, etc.
>
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
Have the Lisp vendors denied your request for an evaluation copy? Have you
even asked?
>
> * True keyboard and mouse control (you can distinguish between a
> keyboard down-press and release, so you can give your text fields
> Emacs-like incremental searching and bindings or do sophisticated
> word completions or any other cool thing you could think up. And of
> course, completely standard and cross-platform.
Of course, completely standard and cross-platform... Hmm, didn't Microsoft
make an argument that it had to break from the Pure Java fold because Sun
didn't want to support 3-button mice?
>
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
So, aside from having a choice, what are the benefits? Can you do OS-native
threads in a platform-independent manner?
>
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
> a larger language than Common Lisp, and it gives you all the access
> to the primitive hardware, windowing-system and networking
> functionality that you really want but in a way that will work on
> Unix, Windows, Mac or whatever without even needing to recompile for
> that platform. ANSI Common Lisp gives you little more primitive
> hardware control and system access than ANSI C (not including CLIM,
> but IMO that doesn't really count).
Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
on the Sun platforms. But their portability claims are _vastly_ oversold.
I tried their Java-based browser (HotJava?) on a Sun workstation and was
very pleased. Later the same day, I tried it on my Mac; I threw it away
after counting some two dozen cosmetic, usability, and functional flaws in
five minutes. (Note: Given all of the hype about Java's portability, you
might ask why Sun has different HotJava versions for different platforms.)
You might be surprised to know that Common Lisp implementations also give
you access to low-level OS and hardware functionality via their FFI. Not
portable, but then neither are Mac OS APIs portable to Win32.
And of course Java doesn't have to be recompiled because it's transferred in
a platform-neutral format: byte code. Did you know that some Lisp systems
(CLISP, CMUCL) have the same capability? Do you understand that Common Lisp
source code is _highly_ portable because it doesn't encode issues of
machine-level data representation? (Yes, Java gets this half-right by
specifying fixed representations for data types. I wonder what Sun will do
when 128-bit machines hit the market. How many times has the Java
"standard" already changed?)
>
> It's funny, my Java instructor at the college was talking about how it
> took them 6-8 years or so to start offering C++ classes, but only 3
> months to offer Java classes. He said a big factor in this was that
> you can download everything for free to all the computers in the
> lab. Lisp has yet to be offered, and probably will never be (I think
> they teach a little AutoLisp though in the CAD classes).
Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
>
> I think every ounce of hype Java has recieved is deserved. As a
> language itself, I think it's better than C, C++, Eiffel, ADA,
> etc... and just about any other non logical/functional programming
> language out there. But none of the logical/functional languages can
> compete with it's level of standardization and the platform
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things considered).
Every ounce of hype Java has received is still just hype. I have observed
early adopters foundering and failing with Sun's
not-quite-ready-for-primetime "free" products, and with not-free derivatives
thereof. Since these folks were actually trying to bring something to
market, there's a real cost involved. (Three or four programmers for six
months is going to cost a company about $200K to $250K in the US. That's a
lot of time and money to throw away on the basis of favorable hype,
particularly when the actual outcome doesn't meet expectations. In this
context, the expenditure of a couple tens of thousands of dollars for mature
tools and training isn't such a big deal.)
>
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
Yeah, standards would be nice. OTOH, I can already get all of this
functionality in a platform-dependent manner and write (if needed) thin
abstraction layers around it. Frankly, I don't mind "rolling my own" while
waiting for a standard to emerge based upon actual experience. One of Sun's
own wrote a "dissenting opinion" on the perils of premature
standardization...
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
And _why_ would I want to run interpreted or JIT-compiled bytecode when I
can run native code? (Remember, mobile code is handled quite nicely in Lisp
by transporting and compiling the source.)
>
> Christopher
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
From: Steve Gonedes
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2emnqdztf.fsf@KludgeUnix.com>
"David B. Lamkins" <········@teleport.com> writes:
< Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
< of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
< on the Sun platforms. But their portability claims are _vastly_ oversold.
< I tried their Java-based browser (HotJava?) on a Sun workstation and was
< very pleased. Later the same day, I tried it on my Mac; I threw it away
< after counting some two dozen cosmetic, usability, and functional flaws in
< five minutes. (Note: Given all of the hype about Java's portability, you
< might ask why Sun has different HotJava versions for different platforms.)
^^^^^^^^^^^^^^^^^^^
This is due to the fact that Java is portable. Portable, being an
undesirable, non-existant situation which requires work to make it go
away. All software is portable, unless it just works of course.
Unix software is portable.
< And _why_ would I want to run interpreted or JIT-compiled bytecode when I
< can run native code? (Remember, mobile code is handled quite nicely in Lisp
< by transporting and compiling the source.)
I wonder why they call it `Just in Time' compiler. Sounds like some
kind of marketing savior.
Don't get me wrong, I love Java and it's cross platform OO
capabilities. Plus it makes writing mission critical easy.
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkj3e46qlv0.fsf@tfeb.org>
Steve Gonedes <········@worldnet.att.net> writes:
>
> I wonder why they call it `Just in Time' compiler. Sounds like some
> kind of marketing savior.
>
Isn't computing & compiling code `just in time' one of the things that
people have been whining at Lisp -- specifically CLOS with things like
lazily computed effective methods -- about for years? I mean, it
means you have to have the compiler in memory all the time, and we
can't have that, can we? Oh, well, we can *now*.
It's just like GC: for years, `Lisp was crippled because it had GC'
now Java has it, why GC is suddenly fine. (It's really amusing
teaching Lisp to people now, suddenly they don't go all funny when you
talk about GC).
There was recently some work on class redefinition in C++, so that's
probably OK now too.
I guess we need to invent some new and outragous features for people
to complain about. (Well, there's already the CLOS MOP, but it's not
quite universal enough to be a real target for derision.)
--tim
From: Barry Margolin
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <yoiy2.38$QE2.13186@burlma1-snr1.gtei.net>
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>I guess we need to invent some new and outragous features for people
>to complain about. (Well, there's already the CLOS MOP, but it's not
>quite universal enough to be a real target for derision.)
We still have the corner on the market for parentheses. The one new
language that was going to adopt our syntax (Dylan) gave in and switched to
algebraic/imperative notation. Even the article that started this thread
only suggested using S-secpressions for data files, not programs.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87soc6f7xn.fsf@2xtreme.net>
"David B. Lamkins" <········@teleport.com> writes:
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Maybe some time in the future.... You can't choose from within the
Java API itself if you want OS or in-process threads. I'm sure you're
familiar with the benefits of using one over the other in different
situations.
> > * Graphics, low-level networking, applets in browsers, sound,
> > look-and-feel support, the kitchen sink.... It actually seems to be
> > a larger language than Common Lisp, and it gives you all the access
> > to the primitive hardware, windowing-system and networking
> > functionality that you really want but in a way that will work on
> > Unix, Windows, Mac or whatever without even needing to recompile for
> > that platform. ANSI Common Lisp gives you little more primitive
> > hardware control and system access than ANSI C (not including CLIM,
> > but IMO that doesn't really count).
>
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms.
Actually, it seems that Windows is the finest Java platform these days
and the most supported. All the fastest JVMs/JITs are for Windows, and
when Java 1.2 came out, the Windows version was the final one while
the Solaris one was supposed to still be beta or evaluatory or
something.
> But their portability claims are _vastly_ oversold. I tried their
> Java-based browser (HotJava?) on a Sun workstation and was very
> pleased. Later the same day, I tried it on my Mac; I threw it away
> after counting some two dozen cosmetic, usability, and functional
> flaws in five minutes.
I've never heard of any bad things about the Metroworks Java tools for
the Mac.
> You might be surprised to know that Common Lisp implementations also
> give you access to low-level OS and hardware functionality via their
> FFI. Not portable, but then neither are Mac OS APIs portable to
> Win32.
Probably because there's so little interest in such a thing. I'm sure
there are Win32 API layers that sit atop of the MacOS API though. But
Java gives you everything you really need from the platform specific
API without needing to use it.
> And of course Java doesn't have to be recompiled because it's transferred in
> a platform-neutral format: byte code. Did you know that some Lisp systems
> (CLISP, CMUCL) have the same capability?
Not quite in the same league.
> Do you understand that Common Lisp source code is _highly_ portable
> because it doesn't encode issues of machine-level data
> representation?
I understand that ANSI Common Lisp is highly portable. ANSI C also
will never, ever break when moving from 32 to 64 bits if you code
properly. It's just way easier to screw up.
> (Yes, Java gets this half-right by specifying fixed representations
> for data types. I wonder what Sun will do when 128-bit machines hit
> the market.
Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
about 64-bit platforms? What will it do when we've got 128-bit ones?
> How many times has the Java "standard" already changed?)
It's been updated twice, and the runtime environment and browsers all
still have to run the 1.0 code and 1.1 code too.
> Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
> busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
Why can't Lisp become more popular? What's stopping it? Do you think
that the reasons outlined in "The Rise of Worse Is Better" are the
_real_ reasons?
> And _why_ would I want to run interpreted or JIT-compiled bytecode when I
> can run native code? (Remember, mobile code is handled quite nicely in Lisp
> by transporting and compiling the source.)
You could write applets in CL and basically gain all the advantages
and cross-platform functionality Java has. You can't do sockets or
threads in CL without a hell of a lot of #+ and #- and have it work in
any CL providing access to these features. And many are reluctant to
ship source code.
Christopher
From: Rainer Joswig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <joswig-1602992212090001@194.163.195.67>
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> Common Lisp has a kinda oddball size for FIXNUMs.
Which size? In MCL:
? MOST-POSITIVE-FIXNUM
536870911
On a MacIvory:
Command: most-positive-fixnum
2147483647
--
http://www.lavielle.com/~joswig
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87n22ef0dw.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > Common Lisp has a kinda oddball size for FIXNUMs.
>
> Which size? In MCL:
>
> ? MOST-POSITIVE-FIXNUM
> 536870911
>
> On a MacIvory:
>
> Command: most-positive-fixnum
> 2147483647
I'll retract my statement. I believed in error that the standard
required fixnums to be 30 bits, but it says that they must be at least
16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
requirement as the ANSI C "int" type.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> I'll retract my statement. I believed in error that the standard
> required fixnums to be 30 bits, but it says that they must be at least
> 16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
> requirement as the ANSI C "int" type.
Yes, and no. The important difference to C is:
a) Unless you actively prohibit this, FIXNUM arithmetic will overflow
correctly and automatically into BIGNUMs, so that a wrong estimate
on your part on the size of FIXNUMs will only cause performance
degradation and not wrong results.
b) There are additional type-specifiers that allow you to clearly
specify types based on your range and/or bit bestimates, so that
none of that "long int is 32bit, long int is 64bit, ..." guessing
is needed.
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128197088724992@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
| about 64-bit platforms? What will it do when we've got 128-bit ones?
geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
implementations do. C and C++, however, _do_ have sizes of such things.
C/C++ have the problem you allude to. Common Lisp just runs with a
little less consing on a machine with bigger machine integers.
| Why can't Lisp become more popular?
why can't opera be more popular? why can't football be less popular?
| What's stopping it?
people like you.
| You can't do sockets or threads in CL without a hell of a lot of #+ and
| #- and have it work in any CL providing access to these features.
just because you can't doesn't many other people can't. the simplest way
to do this is to write a thin veneer, perhaps using compiler macros, to
present a uniform, standard interface to the underlying implementation
(which, by the way, differs between _socket_ implementations, too), stuff
this in a file that is loaded only on the platform it applies to.
porting your system is a matter of making a new copy of this file. this,
by the way, is how intelligent people _implement_ real portability. only
if the differences are very small and very localized does it make sense
to use #- and #+. personally, I use #- and #+ only in configuration
files and in DEFSYSTEMs.
feel free to complain that this veneer isn't standardized. I fully
expect you to, but also that you will complain about whatever you get,
the same way people complain about the pathname abstraction prohibiting
them from running the whole gamut of file system options and operations
on their particular implementation.
#:Erik
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87k8xhg92e.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> * ······@2xtreme.net (Christopher R. Barry)
> | Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> | about 64-bit platforms? What will it do when we've got 128-bit ones?
>
> geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> implementations do. C and C++, however, _do_ have sizes of such things.
> C/C++ have the problem you allude to. Common Lisp just runs with a
> little less consing on a machine with bigger machine integers.
The specification for C's "int" and CL's "FIXNUM" are virtually
identical.
> | Why can't Lisp become more popular?
>
> why can't opera be more popular? why can't football be less popular?
I think your analogy is not the most suitable one. I think using Lisp
over C or Java boils down to more than just personal taste and factors
analogous to your analogy.
> | What's stopping it?
>
> people like you.
Okay, what can I realistically do to make it more popular?
> | You can't do sockets or threads in CL without a hell of a lot of #+ and
> | #- and have it work in any CL providing access to these features.
>
> just because you can't doesn't many other people can't. the simplest way
> to do this is to write a thin veneer, perhaps using compiler macros, to
> present a uniform, standard interface to the underlying implementation
> (which, by the way, differs between _socket_ implementations, too), stuff
> this in a file that is loaded only on the platform it applies to.
> porting your system is a matter of making a new copy of this file. this,
> by the way, is how intelligent people _implement_ real portability. only
> if the differences are very small and very localized does it make sense
> to use #- and #+. personally, I use #- and #+ only in configuration
> files and in DEFSYSTEMs.
Has anyone done this already? Can I download a pre-done layer of
documented macro definitions from somewhere that will at least work
across CMUCL and Allegro CL? If I have to do it myself, not a huge
deal as long as I only do it for functions I use and not everything,
but standardization just makes it *that* much easier.
> feel free to complain that this veneer isn't standardized. I fully
> expect you to, but also that you will complain about whatever you get,
> the same way people complain about the pathname abstraction prohibiting
> them from running the whole gamut of file system options and operations
> on their particular implementation.
A little while back before my homework caught up with me I actually
kinda started to work on making a uniform interface between the ext:
and excl: file operation functions of Allegro and CMU Common Lisp
which provide a lot of the same functionality so that I could write
some intelligent Debian package management utilities for my personal
use to make up for where Apt and dpkg don't get it right for my
purposes. I don't want to commit to using only CMUCL or Allegro CL for
this or anything else just yet. CL-HTTP has been helpful though....
It's just *that* much more of an (IMO) unnecessary inconvenience.
Wasn't the whole point of Common Lisp that a lot of implementations
were providing largely equivalent functionality with a slightly
different interface? Everyone does sockets and threads these days and
a lot of the extension functions across implementations do almost the
exact same stuff. Are there any large, sophisticated, real-world apps
that are written these days in CL that don't do threads?
I should mention that CL-HTTP includes a lot of functions and macros
that unite some of the extension features found in all the CLs and
I've found it very useful and it's saved me a lot of time already. It
was obviously a lot of work to put all of that together and it would
be nice if this stuff could just always be relied upon to be there.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> > geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> > implementations do. C and C++, however, _do_ have sizes of such things.
> > C/C++ have the problem you allude to. Common Lisp just runs with a
> > little less consing on a machine with bigger machine integers.
>
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
No, they are not, since, as Kent Pitman has said here many times, you
cannot evaluate language features and their specs in isolation, but
must always consider the whole ecosystem provided by their standards,
environments etc. Your thinking that since both C and CL standards
require int/fixnum to be 16bit or more is any kind of counter argument
to Erik's statement, just very nicely demonstrates the dangers of not
doing this.
For more details on why C's int and CL's FIXNUM are not in any way
comparable, see my previous postings.
> Wasn't the whole point of Common Lisp that a lot of implementations
> were providing largely equivalent functionality with a slightly
> different interface? Everyone does sockets and threads these days and
> a lot of the extension functions across implementations do almost the
> exact same stuff. Are there any large, sophisticated, real-world apps
> that are written these days in CL that don't do threads?
So get your CL vendor to raise the point at the next meeting of the
standards comittee, should it be decided that the standard should be
revised, rather than reapproved.
If it is so, that all available threading and socket-based networking
APIs differ only in minor details, then taking this area into the
standard might be possible and sensible. Otherwise, the other vendors
and members of the comittee will surely object ;)
> I should mention that CL-HTTP includes a lot of functions and macros
> that unite some of the extension features found in all the CLs and
> I've found it very useful and it's saved me a lot of time already. It
> was obviously a lot of work to put all of that together and it would
> be nice if this stuff could just always be relied upon to be there.
So you got all of your functionality, for all the plattforms you care?
So you can actually do everything you want, don't you? You just want
the standards body to bless this, so you can sleep better at nights?
Well, sure this would be _nice_. But nice is not important, is it?
There are so many things that would be nice. The art of engineering
is dividing up the nice from the essential and then providing the
essential. If any resources are left over, you provide as much of the
nice as seems reasonable.
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128223210845958@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| The specification for C's "int" and CL's "FIXNUM" are virtually identical.
I'm baffled. have you _read_ the specifications? a fixnum is simply a
more efficient integer, and some implementation-defined limits are less
than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler
real well before (+ fixnum fixnum) does not cause a bignum when needed.
what, precisely, is you gripe with the size of FIXNUM, anyway? methinks
you just have a fixation that you're trying blame Common Lisp for.
| > | Why can't Lisp become more popular?
| >
| > why can't opera be more popular? why can't football be less popular?
|
| I think your analogy is not the most suitable one. I think using Lisp
| over C or Java boils down to more than just personal taste and factors
| analogous to your analogy.
my point was that you ask a useless question that has no useful answer.
it is rare that you can explain why something is popular at any given
time. (and "marketing" begets the question "why did it work?", which all
marketing people will tell you is not something you sit down and predict.)
| > | What's stopping it?
| >
| > people like you.
|
| Okay, what can I realistically do to make it more popular?
you can stop posting drivel and actually go read the specification and
ask questions instead of posting wrong answers to questions people don't
ask. you see, people are _detracted_ from a gravitation towards Lisp as
they gain experience in their field and want self-improvement. this is
not at all the path you get if you ask about or measure popularity.
| Has anyone done this already? Can I download a pre-done layer of
| documented macro definitions from somewhere that will at least work
| across CMUCL and Allegro CL? If I have to do it myself, not a huge deal
| as long as I only do it for functions I use and not everything, but
| standardization just makes it *that* much easier.
I think your doing it yourself is a valuable exercise in understanding
(1) how this stuff should have been implemented, (2) the effort that goes
into standardization, and (3) the effort that goes into sharing quality
code with other people. maybe then you will realize what you're asking
for when you want everything for free.
| A little while back before my homework caught up with me I actually kinda
| started to work on making a uniform interface between the ext: and excl:
| file operation functions of Allegro and CMU Common Lisp which provide a
| lot of the same functionality so that I could write some intelligent
| Debian package management utilities for my personal use to make up for
| where Apt and dpkg don't get it right for my purposes. I don't want to
| commit to using only CMUCL or Allegro CL for this or anything else just
| yet.
this at least explains your problems. what you're doing is a waste of
time, although the purpose and goal is clear, so consider this: what you
sit down and design because CMUCL and Allegro CL do not agree on some
interface design is something you barely know how works and what you will
actually need from it once it does work. once it works well enough for
you to build something on top of, you will need to redesign it after you
have started to build something. only if you chose one implementation
and got enough stuff working to start feeding data back into the design
process can you hope to get the design right. what you're doign is
premature abstraction without an actual purpose or goal. "to make it
work in both Allegro CL and CMUCL" should not be a goal, it should fall
out your efforts as a result.
| It's just *that* much more of an (IMO) unnecessary inconvenience.
programming is all _about_ "unnecessary inconveniences", and every step
of progress tries to reduce their number. that's why good programmers
choose languages that have less unnecessary inconveniences than other
languages, but if you think you can avoid unnecessary inconveniences, I
think you should consider death and taxation first.
| Wasn't the whole point of Common Lisp that a lot of implementations were
| providing largely equivalent functionality with a slightly different
| interface?
yes, historically, this was the motivation for the standardization, as it
is with most good standardization, incidentally.
| Everyone does sockets and threads these days and a lot of the extension
| functions across implementations do almost the exact same stuff.
also true, but standards are basically removing functionality from the
market. the issue changes from "do you support FOO" to "do you conform
to the specification of FOO". the former is a feature if true, but
otherwise draws a blank. the latter draws a blank if true, and is
otherwise a reportable bug. to make standards work, all vendors must
agree to stop considering their features features, and start viewing them
as requirements. incidentally, this process parallels your Java vs CL
attitude: you argue against CL because you regard features in Java as
requirements of CL. this is, to put it mildly, hopelessly naive.
| Are there any large, sophisticated, real-world apps that are written
| these days in CL that don't do threads?
I cannot imagine otherwise. why do you?
| I should mention that CL-HTTP includes a lot of functions and macros that
| unite some of the extension features found in all the CLs and I've found
| it very useful and it's saved me a lot of time already. It was obviously
| a lot of work to put all of that together and it would be nice if this
| stuff could just always be relied upon to be there.
well, you have the CL-HTTP sources, and it is apparently not a problem
for you that you cannot use it commercially (which was a gripe you had
with Common Lisp implementations, so I have a minor problem understanding
what your actual and real concerns are).
#:Erik
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87btitfpgw.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> | A little while back before my homework caught up with me I actually kinda
> | started to work on making a uniform interface between the ext: and excl:
> | file operation functions of Allegro and CMU Common Lisp which provide a
> | lot of the same functionality so that I could write some intelligent
> | Debian package management utilities for my personal use to make up for
> | where Apt and dpkg don't get it right for my purposes. I don't want to
> | commit to using only CMUCL or Allegro CL for this or anything else just
> | yet.
>
> this at least explains your problems. what you're doing is a waste of
> time, although the purpose and goal is clear, so consider this: what you
> sit down and design because CMUCL and Allegro CL do not agree on some
> interface design is something you barely know how works and what you will
> actually need from it once it does work. once it works well enough for
> you to build something on top of, you will need to redesign it after you
> have started to build something.
Isn't this kinda like prototyping or "throwing the first one away", a
practice that as far as I know you do not believe in? But, I'm really
liking your advice so far.
> only if you chose one implementation and got enough stuff working to
> start feeding data back into the design process can you hope to get
> the design right. what you're doign is premature abstraction
> without an actual purpose or goal. "to make it work in both Allegro
> CL and CMUCL" should not be a goal, it should fall out your efforts
> as a result.
So far I've been using both CMUCL and Allegro about equally as much. I
often run both of them at the same time in a split Emacs frame, and
send each the same input when I'm trying new stuff from the
HyperSpec. It's interesting to observe all the differences in error
handling and formatting and compiler messages and GC time and
frequency and other things. I've been trying very hard to avoid using
one dominantly, and have been focusing heavily with portability
between the 2. But I guess I have to make a choice now of the one I'm
going to commit to writing a full application in first before looking
into portability to the other. I guess this isn't as bad as I've been
thinking it is and I'll have to accept this as just the way it is.
> | It's just *that* much more of an (IMO) unnecessary inconvenience.
>
> programming is all _about_ "unnecessary inconveniences", and every step
> of progress tries to reduce their number. that's why good programmers
> choose languages that have less unnecessary inconveniences than other
> languages, but if you think you can avoid unnecessary inconveniences, I
> think you should consider death and taxation first.
That puts some interesting perspective on it.
> | Everyone does sockets and threads these days and a lot of the extension
> | functions across implementations do almost the exact same stuff.
>
> also true, but standards are basically removing functionality from the
> market. the issue changes from "do you support FOO" to "do you conform
> to the specification of FOO". the former is a feature if true, but
> otherwise draws a blank. the latter draws a blank if true, and is
> otherwise a reportable bug. to make standards work, all vendors must
> agree to stop considering their features features, and start viewing them
> as requirements. incidentally, this process parallels your Java vs CL
> attitude: you argue against CL because you regard features in Java as
> requirements of CL. this is, to put it mildly, hopelessly naive.
Okay, I'll get over it.
> | Are there any large, sophisticated, real-world apps that are written
> | these days in CL that don't do threads?
>
> I cannot imagine otherwise. why do you?
I was imagining being able to do this in an CL though kinda like with
Java, "imagining" being the operative word. Sigh.
Christopher
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128233559196892@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| Isn't this kinda like prototyping or "throwing the first one away", a
| practice that as far as I know you do not believe in? But, I'm really
| liking your advice so far.
there's a nuance here that seems to get lost all the time. first, some
people _believe_ in prototyping (in another language), i.e., they do it
whether it makes sense or not. sometimes, it makes sense to do it.
second, "throwing the first version away" is something you do if you need
to, not something you should out to do, because then you'll end up maybe
having to throw the second version away, too.
my argument against what you're doing is that you involve yourself in
low-level stuff long before you know how to do either low-level or
high-level stuff. you will learn the wrong thing from this experiment
and will retain whatever was reasonably simple to implement, not what is
good design. simplifying the design is sometimes necessary when the cost
of implementing it proves too costly. if you implement it in one of the
environments at a time, you may call it prototyping. if you implement it
in both, you're trying to evolve production code. this will fail.
| I was imagining being able to do this in an CL though kinda like with
| Java, "imagining" being the operative word. Sigh.
well, maybe Java has a place in the grand order of things, but to make
Java really work, I want serious protocol engine support, since the Java
applet is going to talk to a server, and it'd be nice if that was using a
reasonably standard protocol. as far as I know, CORBA support is not
"standard" in Java, and despite it's cost and the introduction of yet
another language (IDL) is the most promising way to deal with this mess.
#:Erik
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <877ltgg6um.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> as far as I know, CORBA support is not "standard" in Java, and
> despite it's cost and the introduction of yet another language
> (IDL) is the most promising way to deal with this mess.
CORBA is now "standard" in Java 1.2. <http://java.sum.com> links to
some good documentation of it.
Christopher
From: Rainer Joswig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <joswig-1802990013440001@194.163.195.67>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> well, you have the CL-HTTP sources, and it is apparently not a problem
> for you that you cannot use it commercially (which was a gripe you had
> with Common Lisp implementations, so I have a minor problem understanding
> what your actual and real concerns are).
People are using CL-HTTP in commercial products.
--
http://www.lavielle.com/~joswig
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128303429526038@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| People are using CL-HTTP in commercial products.
so people keep telling me, but it is not quite what I asked. people are
using Microsoft source code in commercial products, too, but that doesn't
mean it is something you can just go and buy. so, what kind of license
are the people you refer to using? whose is the actual signature on the
license agreement? why can I not find something that allows _everybody_
to use it commercially? (yes, I have looked. the license agreeements
that come with CL-HTTPD is worse than the GPL in its restricions.)
#:Erik
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkj7ltgrruw.fsf@tfeb.org>
Erik Naggum <····@naggum.no> writes:
>
> so people keep telling me, but it is not quite what I asked. people are
> using Microsoft source code in commercial products, too, but that doesn't
> mean it is something you can just go and buy. so, what kind of license
> are the people you refer to using? whose is the actual signature on the
> license agreement? why can I not find something that allows _everybody_
> to use it commercially? (yes, I have looked. the license agreeements
> that come with CL-HTTPD is worse than the GPL in its restricions.)
>
I guess this should be on the CL-HTTP list, but I agree with this
strongly. The license was unusable, and also very unclear as to what
it actually meant, about 2 years ago, and I got no response at all
when I asked about a more liberal & clear one (say BSD/X11-style).
Right now if I had to do serious work using a Lisp web server, I'd
probably have to write one, which is a tragedy. If the CL-HTTP people
are listening, please clarify this stuff!
(And can we avoid a huge argument about the GPL? At least on this group.)
--tim
From: Peter Van Eynde
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <slrn7co97h.phq.pvaneynd@mail.inthan.be>
On 18 Feb 1999 09:19:51 +0000, Tim Bradshaw wrote:
>Erik Naggum <····@naggum.no> writes:
>
>>
>> so people keep telling me, but it is not quite what I asked. people are
>> using Microsoft source code in commercial products, too, but that doesn't
>> mean it is something you can just go and buy. so, what kind of license
>> are the people you refer to using? whose is the actual signature on the
>> license agreement? why can I not find something that allows _everybody_
>> to use it commercially? (yes, I have looked. the license agreeements
>> that come with CL-HTTPD is worse than the GPL in its restricions.)
>>
>
>I guess this should be on the CL-HTTP list, but I agree with this
>strongly. The license was unusable, and also very unclear as to what
<AOL>Me too</AOL>
I actually went out and asked the Debian mentors about the license
and the responses went from "strange" to "you're not even allowed to
copy this code, let alone compile and use it!".
>it actually meant, about 2 years ago, and I got no response at all
>when I asked about a more liberal & clear one (say BSD/X11-style).
I pleaded that inclusion in Debian would result in a larger penetration and
therefore would get it more users/developers (the Debian CMUCL release
is aimed at beginners/students). The response was "cl-http has enough
users already". :-(
>(And can we avoid a huge argument about the GPL? At least on this group.)
I don't care what license it has, as long as I can understand it!
(even if the license is "forbidden to copy, compile, distribute or
use" I would know that I should be looking elsewhere... now...)
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Rainer Joswig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <joswig-1802991705060001@pbg3.lavielle.com>
In article <·······················@mail.inthan.be>, ········@inthan.be wrote:
> I actually went out and asked the Debian mentors about the license
> and the responses went from "strange" to "you're not even allowed to
> copy this code, let alone compile and use it!".
I don't know what part of the license would be the reason for that.
Maybe somebody can explain it to me.
The license:
> License Agreement for
> The Common Lisp Hypermedia Server (CL-HTTP)
>
>
> CL-HTTP is Copyright (c) John C. Mallery, 1994-1998. All rights reserved.
> Some files carry copyrights by other parties, which should be respected.
>
> CL-HTTP is distributed in the hope that it will be useful but WITHOUT ANY
> WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
> A PARTICULAR PURPOSE.
>
> By using the server or retaining a copy of the distribution, you acknowledge
> that you accept the terms and limitations of this license.
>
> Personal, educational, and commercial uses are allowed and may incorporate
> CL-HTTP into applications provided that:
>
> a. The licensee preserves all original copyrights in the CL-HTTP
> files;
>
> b. The licensee clearly separates their own code from the distributed
> sources;
>
> c. The licensee submits any extensions or improvements to CL-HTTP to
> the developers at ···········@ai.mit.edu;
>
> d. The licensee prominently displays the fact that your application
> uses CL-HTTP;
>
> e. The licensee prominently indicates that CL-HTTP was developed by
> and is owned by John C. Mallery;
>
> f. The licensee advises their users that they may obtain the latest
> release of CL-HTTP from ftp://ftp.ai.mit.edu/pub/users/jcma/cl-http/
>
> g. The licensee advises their users that that the homepage for the
> server is located at
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
>
> h. The licensee informs the CL-HTTP user community of any novel or
> significant uses in a timely manner by submitting a short description
> of the server to ······@ai.mit.edu
>
> However, all academic or commercial publication rights for CL-HTTP server in
> any form are hereby reserved.
>
> Additionally, all rights are reserved to any derivative works based on the
> Lisp source code in the CL-HTTP distribution, in particular but not limited to
> any automatic or manual translation of the source code into other computer
> languages or executables.
>
> Any rights not explicitly waived are retained.
>
> Subsequent versions of CL-HTTP may have different copyright statements and
> license requirements once it becomes clear precisely what arrangements best
> serve the Lisp community.
>
> In the meantime, the right to change this license for CL-HTTP in anyway at
> anytime is hereby reserved, any prior clauses notwithstanding.
>
> If any of elements of this agreement are found to be unenforceable, the others
> will remain in effect.
>
> This license agreement is governed by the laws of the Commonwealth of
> Massachusetts and the United States of America.
>
> The author can be contacted at:
>
(Address not posted).
To me it sums up to following:
- I can use the code
- I have to tell that I use the code and I have to submit
extensions/improvements back to the developers
If some people cannot live with that, their problem. But, for example
telling that it generally is not usable in a commercial way
is plain wrong.
Sorry, but this whining about CL-HTTP really pisses me off. People
have contributed a lot of time and effort that it runs
on a variety of platforms and they try to keep track
of standards (read the HTTP 1.1 standard and you might get an idea).
I'm not really sure if other people really appreciate how
much work and knowledge has gone into this stuff
(for example just to make TCP/IP actually work in some Lisp
implementations). I really don't like CL-HTTP to go the route
of some other "closed" or "open" Lisp packages -> "dead end".
Lisp users have the luck to have access to a system that
incorporates some real cool stuff and a large library of
networking code. Some users have built even more cool
applications on top of that. Actually CL-HTTP is thought
as an enabler to develop these cool applications and
to make Lisp usable for web applications - whereas most people
think you can't write a web server in Lisp.
If people have real problems with the license and they have a real
need for a web server in Lisp: write your own. There are more
web servers out there - some of them even written in Lisp/Scheme/...
--
http://www.lavielle.com/~joswig
From: Peter Van Eynde
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <slrn7cokvi.26t.pvaneynd@mail.inthan.be>
This won't get sent until 4:00, but anyway...
On Thu, 18 Feb 1999 17:05:06 +0100, Rainer Joswig wrote:
>> I actually went out and asked the Debian mentors about the license
>> and the responses went from "strange" to "you're not even allowed to
>> copy this code, let alone compile and use it!".
>
>I don't know what part of the license would be the reason for that.
>Maybe somebody can explain it to me.
>
>The license:
>
..
[In an email I got:]
From: ····@xs4all.nl (Richard Braakman)
Subject: Re: Licences ok?
To: ··············@lists.debian.org
Date: Fri, 10 Apr 1998 14:30:25 +0200 (CEST)
Message-Id: <···············@night>
..
> Additionally, all rights are reserved to any derivative works based on the
> Lisp source code in the CL-HTTP distribution, in particular but not limited to
> any automatic or manual translation of the source code into other computer
> languages or executables.
This makes the Lisp code non-free.
I have no idea why they want to forbid compilation of their code.
> In the meantime, the right to change this license for CL-HTTP in anyway at
> anytime is hereby reserved, any prior clauses notwithstanding.
This also makes it non-free in my book, but the DFSG is not clear about it.
As far as I'm concerned it makes the entire license meaningless; there's
nothing you can do with the code that they cannot revoke whenever they
feel like it.
[end of email. The DFSG are the Debian Free Software Guidelines. A mutant of
this is now used as the Open Source(TM :-) definition]
As far as I'm concerned, I simply _do_ _not_ _understand_ the license.
All this talk of "all rights reserved" has a very restrictive tone to
me, but I don't understand it. I understand the GPL, LGPL, Artistic License,
BSD license, even the Microsoft licenses, but I don't understand _this_.
So I ask the experts... The result is pretty depressing.
I emailed professor Mallery and asked him to explain the license for me. I
got as reply was that "the license is what it says" and the possibility
of a commercial license. I then thought I had explained my case badly and
I tried to get a more definite answer. I got it:
|We presently have enough users and do not need
|any more at this time.
[I might add that he also expressed that this was software-in-development
and that a newer version might be better. But 1 year and 2 months later I
still see people complaining about ACL support...]
>Sorry, but this whining about CL-HTTP really pisses me off. People
>have contributed a lot of time and effort that it runs
>on a variety of platforms and they try to keep track
>of standards (read the HTTP 1.1 standard and you might get an idea).
>I'm not really sure if other people really appreciate how
>much work and knowledge has gone into this stuff
>(for example just to make TCP/IP actually work in some Lisp
>implementations). I really don't like CL-HTTP to go the route
>of some other "closed" or "open" Lisp packages -> "dead end".
You're talking to the guy who wanted to package it up for Debian...
More users -> more bugs found -> more developers.
What I wanted was to package up CMUCL+CL-HTTP and give them
to the people at university doing lisp course with a few
simple examples. Just so that they could use a web-interface
for their project instead of format and read-line... People talk about
the lack of interest in Lisp but when I tried it several years
ago on an ST I got a window with:
?
That's it. No documentation, no nothing. With CMUCL you get:
CMU Common Lisp 18a+ release x86-linux 2.4.7 6 November 1998 cvs,
running on slartibartfast
Send bug reports and questions to your local CMU CL maintainer,
or to ········@debian.org
or to ··········@XXXX (prefered) [email censored]
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (help)
Welcome to CMUCL for Linux.
.. [lot's of help deleted]
Ok. I admit, the docs need updating ;-)
>Lisp users have the luck to have access to a system that
>incorporates some real cool stuff and a large library of
>networking code. Some users have built even more cool
>applications on top of that. Actually CL-HTTP is thought
>as an enabler to develop these cool applications and
>to make Lisp usable for web applications - whereas most people
>think you can't write a web server in Lisp.
The truly, truly sad thing is: I totally agree with you. Utterly.
But I can't use CL-HTTP, because the license isn't clear. Now is this
not sad? If you think you are annoyed because people whine about
CL-HTTP, just imagine how annoyed I must be...
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Rainer Joswig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <joswig-1802992020190001@pbg3.lavielle.com>
In article <·······················@mail.inthan.be>, ········@inthan.be wrote:
> > Additionally, all rights are reserved to any derivative works based on the
> > Lisp source code in the CL-HTTP distribution, in particular but not limited to
> > any automatic or manual translation of the source code into other computer
> > languages or executables.
>
> This makes the Lisp code non-free.
> I have no idea why they want to forbid compilation of their code.
I don't see how it forbids compilation of the code.
> |We presently have enough users and do not need
> |any more at this time.
Sounds like the mail is authentic. ;-)
> [I might add that he also expressed that this was software-in-development
> and that a newer version might be better. But 1 year and 2 months later I
> still see people complaining about ACL support...]
Support for ACL has to come from users. Franz does not support CL-HTTP, AFAIK.
> You're talking to the guy who wanted to package it up for Debian...
> More users -> more bugs found -> more developers.
Yep.
> What I wanted was to package up CMUCL+CL-HTTP and give them
> to the people at university doing lisp course with a few
> simple examples.
I really don't get it. ;-) CL-HTTP has been used in several projects
at Universities. I'm using it myself in a joint project with
the AI lab of the University of Hamburg. What do they do that others can't?
> Welcome to CMUCL for Linux.
> .. [lot's of help deleted]
>
> Ok. I admit, the docs need updating ;-)
Good work.
--
http://www.lavielle.com/~joswig
From: Christopher R. Barry
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87pv77o4k1.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> > Additionally, all rights are reserved to any derivative works
> > based on the Lisp source code in the CL-HTTP distribution, in
> > particular but not limited to any automatic or manual translation of
> > the source code into other computer languages or executables.
> > This makes the Lisp code non-free.
> > I have no idea why they want to forbid compilation of their code.
>
> I don't see how it forbids compilation of the code.
Indeed, in this respect it only seems to indicate that all rights are
reserved on compiled files generated from the CL-HTTP source. It
doesn't say that you are forbidden to make derivative works from the
automatic translation of source to machine-code.
Christopher
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128366783994723@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| I don't see how it forbids compilation of the code.
are you a lawyer trained in intellectual property? who cares what some
layman sees or doesn't see?
| What do they do that others can't?
they ignore the consequences of vague and meaningless licenses.
#:Erik
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjiuczfi53.fsf@tfeb.org>
······@lavielle.com (Rainer Joswig) writes:
> >
> > This makes the Lisp code non-free.
> > I have no idea why they want to forbid compilation of their code.
>
> I don't see how it forbids compilation of the code.
Object files are `a derived work'.
--tim
From: Christopher R. Barry
Subject: Garnet packaged for Debian? Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87yalvo5w4.fsf_-_@2xtreme.net>
········@mail.inthan.be (Peter Van Eynde) writes:
> You're talking to the guy who wanted to package it up for Debian...
> More users -> more bugs found -> more developers.
Will Garnet ever be packaged for Debian?
Christopher
From: ········@totient.demon.co.uk
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7ajqos$ion$1@nnrp1.dejanews.com>
>
> I emailed professor Mallery and asked him to explain the license for me. I
> got as reply was that "the license is what it says" and the possibility
> of a commercial license. I then thought I had explained my case badly and
> I tried to get a more definite answer. I got it:
>
> |We presently have enough users and do not need
> |any more at this time.
>
Obviously, the expectation for the number of users is rather low.
http://www.netcraft.com/Survey/Reports/9902/
Shows 16 CL-HTTP servers on the internet, as of 1999-02-01
CL-HTTP sites by top-level domain
Domain Number Percentage
com 6 37.50%
Other 10 62.50%
Sites in .COM running CL-HTTP
web2.keokukia.com
als-demo.lavielle.com
stony-brook.scrc.symbolics.com
www.symbolics.com
164.zami.com
cambridge.zami.com
Jon
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128366273860523@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| Sorry, but this whining about CL-HTTP really pisses me off.
some of us are sufficiently legally trained or experienced to see danger
signs in legal material. I don't know that it pisses anyone off, but it
sure says "no go". some of us believe in the sanctity of contract, and
sometimes a very legitimate reaction is "I can't honor that contract".
some of us work very hard to ensure that everything we do is according to
all applicable laws, not because we're afraid of punishment, but because
by breaking some laws, we would also lose its protection. if we broke a
contract or were even challenged for it, our own contracts would lose
legal force in the minds of very many people.
like, does anyone _really_ respect Microsoft's license agreements? I
sure don't, but this is one of my best arguments against ever installing
anything owned by Microsoft on my computers -- people who do actually and
usually unwittingly allow Microsoft officials or anyone acting on their
behalf to search their entire computing environment for illegal copies of
unrelated software, except that you _cannot_ agree to this in any country
on earth and still be held legally responsible for it, but Microsoft will
try and crush you regardless of your legal standing and rights. as long
as their opponents go away, Microsoft is happy, and if the law come into
play, so much the better. threats and force actually work. that's why
most countries have severe penalties for fraud and make fraud a crime,
instead of just a matter of agreements.
yes, the issue is this big if you actually take agreements seriously.
| I'm not really sure if other people really appreciate ...
now you're being destructive and paranoid. drop it.
| I really don't like CL-HTTP to go the route of some other "closed" or
| "open" Lisp packages -> "dead end".
I don't think you appreciate that others may have the same goal.
| Lisp users have the luck to have access to a system that incorporates
| some real cool stuff and a large library of networking code. Some users
| have built even more cool applications on top of that. Actually CL-HTTP
| is thought as an enabler to develop these cool applications and to make
| Lisp usable for web applications - whereas most people think you can't
| write a web server in Lisp.
all of this is true. all of this is extremely irrelevant to the terms of
the license agreement.
| If people have real problems with the license and they have a real need
| for a web server in Lisp: write your own.
well, that _is_ the problem with the license. thank you for agreeing.
Rainer, let me be blunt: that license is a toy license, written by a
legal incompetent. e.g., "by retaining a copy of the distribution, you
acknowledge that you accept the terms and limitations of this license",
which means that just picking up the distribution is an encumbrance upon
the user. in most countries, this clause is unenforceable -- I don't
know that it is unenforceable in the Commonwealth of Massachussetts, but
I would be greatly surprised if it weren't. and the right to produce an
"executable" is reserved. what does that mean? does it mean compiling
it? does it mean dumping it with your Lisp image? but what if there is
no executable mentioning, only various loadable files? and what _is_ the
actual _license_? "personal, educational, and commercial uses are
allowed", it says. this is freaking _meaningless_ in the precise legal
terms required for licensees to know _exactly_ what they are allowed to
do -- I have no idea whether what I'd like to do is considered a
"commercial use" or not. _real_ legal documents define all these things.
finally, and this is really a fundamental issue; where is MIT's grant to
John Mallery that he can claim ownership of this in the first place? my
understanding is that it has been developed over a long time while he has
been a graduate student at MIT. in case you didn't know, MIT retains a
number of interesting rights to _anything_ students or employees do, but
they routinely waive them -- they idea is simply to default to MIT
ownership. therefore, I expect to see a waiver and grant from MIT to
John Mallery. I haven't found it, and since I'm not a legal doofus who
can reasonly claim ignorance of the law, as if that were even a valid
excuse, or having acted in good faith, the whole thing is in danger of
being invalid and someone might come along and claim it, including
anything I might want to retain rights to. this may not be a real issue,
but it sure is a hell of danger sign.
my own endeavors to publish software other people can use, have faltered
on the legal work to do it right, which alone would set me back tens of
thousands of dollars, which I have a very hard time defending, so I don't.
I'm sure CL-HTTP is great, but the license agreement is useless, and so
it is _irrelevant_ to me whether the product is great or not. it would
not cross my mind to argue against the quality of the code based on the
lack of quality of the license agreement. although programming is a lot
like legal matters, few programmers think it's worth the effort, and thus
the computer industry, and especially the amateur scene, is littered with
unenforceable licenses that would make a lot of people _really_ unhappy
if they were broken. I'm unhappy that they are breakable without peril
of legal consequence, because it means those who think nothing of such
issues can have a field day if they want it.
#:Erik
From: Will Fitzgerald
Subject: RE: CL-HTTP License (Was: Re: Java is really convenient. ...)
Date:
Message-ID: <7ajr0d$f2h@news.net-link.net>
Erik Naggum wrote in message <················@naggum.no>...
> [snip]
>
> I'm sure CL-HTTP is great, but the license agreement is useless, and so
> it is _irrelevant_ to me whether the product is great or not. it would
> not cross my mind to argue against the quality of the code based on the
> lack of quality of the license agreement. although programming is a lot
> like legal matters, few programmers think it's worth the effort, and thus
> the computer industry, and especially the amateur scene, is littered with
> unenforceable licenses that would make a lot of people _really_ unhappy
> if they were broken. I'm unhappy that they are breakable without peril
> of legal consequence, because it means those who think nothing of such
> issues can have a field day if they want it.
>
>#:Erik
Here's my experience, with a commercial point of view.
We were exploring the use of CL-HTTP for an AI-ish question answering system
a couple of years ago. Our prime customer was very concerned about licenses
for components of the software we were building (and rightly so). It was
clear to me that the CL-HTTP license was vague and confusing enough that it
was going to raise a number of questions, so we basically dropped it, moved
to a "servlet" approach, and basically interacted with the AI-ish part via a
TCP/IP interface.
It's been clear to me for some time that the CL-HTTP folks are simply not
interested in wide-spread use of CL-HTTP. That's OK; nobody says you have to
share your intellectual property. It's confusing that so much effort has
gone into making it platform and Lisp implementation independent and have it
not be marketed. My impression is that the CL-HTTP people really like to
write great software (and it is really good software in general) but don't
really care whether it gets used. I could be wrong; maybe there will be a
future push. But Erik's warnings are important to heed, and I would be very
hesitant to build anything commercially or not that depended on the CL-HTTP
code.
On the other hand, a basic HTTP server is relatively easy to build. Franz
has had a number of Tech Notes on this (with an Allegro-centric view, of
course), starting with:
<http://www.franz.com/tech/technotes/unixserver.main.html>
(By the way, they also have a tech note for getting CL-HTTP running under
ACL at hyperserver.main.html in the list above).
Also, there's a Scheme-based (Scheme 48/scsh Scheme) of an HTTP 1.0 server
available at:
<ftp://ftp-swiss.ai.mit.edu/pub/scsh/contrib/net/su-httpd.html>
Most of it is under Olin Shiver's copyright.
--
Will Fitzgerald
VP, R&D
Neodesic Corporation
From: Espen Vestre
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <w6vhh1770b.fsf@wallace.nextel.no>
······@2xtreme.net (Christopher R. Barry) writes:
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
others have pointed out that you're wrong.
I'd just like to point out that I think it's a good motto to
stay away from fixnum declarations until your profiler suggests you
to consider using them. CLs general integers has saved lisp programmers
from a *lot* of problems, and will still do (-> the 2038 problem).
--
(espen)
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjd839v24t.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
Erm, no. If you overflow an int in C you die horribly, if yu overflow
a fixnum things just get a bit slow. What happens in C when your nice
32bit int time type overflows? What happens in CL when the time
overflows a fixnum (hint: it already has for any implementation I know
of).
> I should mention that CL-HTTP includes a lot of functions and macros
> that unite some of the extension features found in all the CLs and
> I've found it very useful and it's saved me a lot of time already. It
> was obviously a lot of work to put all of that together and it would
> be nice if this stuff could just always be relied upon to be there.
Well, better than complaining would be to put some work into a
proposed standard <x> interface for CL and post it for comments.
--tim
From: Johan Kullstam
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2k8xhxjjb.fsf@sophia.axel.nom>
Tim Bradshaw <···@tfeb.org> writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
>
> > The specification for C's "int" and CL's "FIXNUM" are virtually
> > identical.
>
> Erm, no. If you overflow an int in C you die horribly, if yu overflow
> a fixnum things just get a bit slow. What happens in C when your nice
> 32bit int time type overflows? What happens in CL when the time
> overflows a fixnum (hint: it already has for any implementation I know
> of).
nod.
however, what if i actually *want* a wrap around. i do not want an
integer but a number from the ring Z_n.
this is not an idle question. i could actually use this. for
example, i am measuring angles on a satellite dish pedestal and my
sensor equipment maps the angle to a number from 0 to 65535. it'd be
nice to wrap around automatically, since the concept i am trying to
handle - angles - do this.
i.e., (+ angle1 angle2) should return a new angle in the canonical
angle format 0 to 65535.
other times it'd be nice to have a wrapping integer type is for
periodic time-varying filter operations in a modem.
the books i have seen are a little weak on the number crunching, bit
banging side of the house. i hear that lisp can be as fast as fortran
on numeric problems. i have come to lisp out of disgust with C++ and
i am finding that i like lisp. but is they any information on how to
solve those problems which are traditionally done in fortran or C?
--
Johan Kullstam [········@ne.mediaone.net] Don't Fear the Penguin!
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkj67913wjt.fsf@tfeb.org>
Johan Kullstam <········@ne.mediaone.net> writes:
> however, what if i actually *want* a wrap around. i do not want an
> integer but a number from the ring Z_n.
You can use MOD &c to get this. You might either define some new type
(which would probably be slow because you'll have to wrap the
numerical value in something), or you can do mod-n arithmetic on
ordinary numerical types. If you really want `+' &c. to do mod-n
arithmetic you can manipulate the package system so that it does (or
rather, the symbol named "+" in the current packages does). You can
choose what n you want, though declaring it a constant might (?) help
the compiler at the cost of flexibility.
If your numbers are close to being bignums you might have to be clever
about avoiding doing (MOD (+ .... lots of numbers ...) n), but that
would really depend on what code actually got generated I guess.
It ought to be the case that, if the numbers are fixnums and if you
can tell the system they are, that you get pretty good performance
from this.
--tim
From: Duane Rettig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4aeydx988.fsf@beta.franz.com>
Johan Kullstam <········@ne.mediaone.net> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > ······@2xtreme.net (Christopher R. Barry) writes:
> >
> >
> > > The specification for C's "int" and CL's "FIXNUM" are virtually
> > > identical.
> >
> > Erm, no. If you overflow an int in C you die horribly, if yu overflow
> > a fixnum things just get a bit slow. What happens in C when your nice
> > 32bit int time type overflows? What happens in CL when the time
> > overflows a fixnum (hint: it already has for any implementation I know
> > of).
>
> nod.
All this talk of fixnums gives one a headache. Fixnums are the wrong
way to think in CL; even seasoned CL programmers get into the bad
habit of thinking in terms of fixnums instead of ranged integers.
They (we) tend to fall back on our knowledge of the size of our lisp's
fixnum out of laziness. What we tend to mean when we say "fixnum" is
really "some small intgeger that will not get slow in calculations".
The canonical form of the fixnum type specification is
'(integer #.most-negative-fixnum #.most-positive-fixnum)
which at least one CL I know of converts to at its first chance:
USER(1): (excl::type-canonicalize 'fixnum)
(INTEGER -536870912 536870911)
USER(2):
> however, what if i actually *want* a wrap around. i do not want an
> integer but a number from the ring Z_n.
Tim Bradshaw goes on to give you the correct answer for this, using
MOD. However, saying that you do not want an integer is not quite
correct; you really do want an integer, restricted in range.
> this is1 not an idle question. i could actually use this. for
> example, i am measuring angles on a satellite dish pedestal and my
> sensor equipment maps the angle to a number from 0 to 65535. it'd be
> nice to wrap around automatically, since the concept i am trying to
> handle - angles - do this.
>
> i.e., (+ angle1 angle2) should return a new angle in the canonical
> angle format 0 to 65535.
If you want to provide declarations for the intgeer range to match
this hardware, you would specify '(integer 0 65535). Better would
be to use a deftype:
USER(14): (deftype dish-angle () '(integer 0 65535))
DISH-ANGLE
USER(15): (subtypep 'dish-angle 'fixnum)
T
T
USER(16): (subtypep 'bit 'dish-angle)
T
T
USER(17):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Johan Kullstam
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2hfsky7fu.fsf@sophia.axel.nom>
Duane Rettig <·····@franz.com> writes:
> Johan Kullstam <········@ne.mediaone.net> writes:
> > however, what if i actually *want* a wrap around. i do not want an
> > integer but a number from the group Z_n.
>
> Tim Bradshaw goes on to give you the correct answer for this, using
> MOD. However, saying that you do not want an integer is not quite
> correct; you really do want an integer, restricted in range.
no, i do *not* want an integer (at least in the mathematical sense).
i want elements of Z_n = Z - <n> which is not the integers Z but
equivalence classes on Z, i.e., Z modulo multiples of n. the math in
Z - <n> is different from integer math. mapping elements of Z - <n>
into a subset of fixnum or bignum would be a particular
representation. operations on the group elements do not follow the
`conventional' integer operations.
eg in Z_2 let the elements be denoted z2_0 and z2_1. define the `+'
operation to do
z2_0 + z2_0 = z2_1 + z2_1 = 0 and z2_0 + z2_1 = z2_1 + z2_0 = z2_1.
integers do not work this way. they follow different rules.
modern algebra such as groups rings and fields has not only variable
values, but the operations like `+' are also a `variable'. however the
operations follow some rules (eg associative commutative &c) and
deductions can be based on that.
it'd be interesting to see if lisp can set up eg functions which
depend upon group operations. the particular group (its elements,
their representation and how the operation acts) would be specified
later.
--
Johan Kullstam [········@ne.mediaone.net] Don't Fear the Penguin!
From: Duane Rettig
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4pv77o5va.fsf@beta.franz.com>
Johan Kullstam <········@ne.mediaone.net> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Johan Kullstam <········@ne.mediaone.net> writes:
>
> > > however, what if i actually *want* a wrap around. i do not want an
> > > integer but a number from the group Z_n.
> >
> > Tim Bradshaw goes on to give you the correct answer for this, using
> > MOD. However, saying that you do not want an integer is not quite
> > correct; you really do want an integer, restricted in range.
>
> no, i do *not* want an integer (at least in the mathematical sense).
But since you're trying to implement a mathematical concept in a
computer language, I resubmit that you really want integers (in
the computer-language sense), plus some way to restrict them so as to
model the math concept you desire.
I wouldn't have answered this with an argument if I didn't also have
what I think is useful information to add, so read on...
> i want elements of Z_n = Z - <n> which is not the integers Z but
> equivalence classes on Z, i.e., Z modulo multiples of n. the math in
> Z - <n> is different from integer math. mapping elements of Z - <n>
> into a subset of fixnum or bignum would be a particular
> representation. operations on the group elements do not follow the
> `conventional' integer operations.
>
> eg in Z_2 let the elements be denoted z2_0 and z2_1. define the `+'
> operation to do
>
> z2_0 + z2_0 = z2_1 + z2_1 = 0 and z2_0 + z2_1 = z2_1 + z2_0 = z2_1.
>
> integers do not work this way. they follow different rules.
>
> modern algebra such as groups rings and fields has not only variable
> values, but the operations like `+' are also a `variable'. however the
> operations follow some rules (eg associative commutative &c) and
> deductions can be based on that.
>
> it'd be interesting to see if lisp can set up eg functions which
> depend upon group operations. the particular group (its elements,
> their representation and how the operation acts) would be specified
> later.
Try the following - this should work for any ring size, and could be
expanded to check arguments for validity (although any reasonably
small integer should be properly incorporated into the result with
the proper modulus). The macro is a Zn_+ constructor, asking for n
and creating the desired Z<n>_+ operator. The resulting operator
is simplistic, but it does what you ask, and could easily be
enhanced to take on more features.
On an x86:
USER(1): (defmacro make-Zn_+ (n)
(let ((name (intern (format nil "Z~d_+" n)))
(n-type `(integer 0 ,(1- n))))
`(defun ,name (x y)
(declare (optimize speed (safety 0))
(type ,n-type x y))
(the ,n-type (mod (+ x y) ,n)))))
MAKE-ZN_+
USER(2): (make-zn_+ 2)
Z2_+
USER(3): (z2_+ 0 0)
0
USER(4): (z2_+ 1 1)
0
USER(5): (z2_+ 0 1)
1
USER(6): (z2_+ 1 0)
1
USER(7): (compile 'z2_+)
Z2_+
NIL
NIL
USER(8): (disassemble 'z2_+)
;; disassembly of #<Function Z2_+>
;; formals: X Y
;; code start: #x204d4944:
0: 55 pushl ebp
1: 8b ec movl ebp,esp
3: 56 pushl esi
4: 83 ec 24 subl esp,$36
7: 03 d0 addl edx,eax
9: 33 db xorl ebx,ebx
11: b3 08 movb bl,$8
13: 8b c2 movl eax,edx
15: 99 cdq
16: f7 fb idivl ebx
18: 8b c2 movl eax,edx
20: f8 clc
21: c9 leave
22: 8b 75 fc movl esi,[ebp-4]
25: c3 ret
USER(9):
I was surprised at first to see that this function forced the stack
to be linked in (as opposed to creating a leaf function) but then
I remembered that the mod/rem primitive requires specific registers
to be certain places in order to work, and it was easier at the time
to just force the linkin; I'll probably revisit that issue in the
near future. Meanwhile, here is the same function disassembled on
an rs/6000, which does not place extra requirements on primitive
rem/mod operations, and which thus compiles into a leaf function:
USER(4): (disassemble *)
;; disassembly of #<Function Z2_+>
;; formals: X Y
;; code start: #x30513234:
0: 7c832014 a r4,r3,r4
4: 3a600008 [cal] lil r19,8
8: 7c649ad6 divs r3,r4,r19
12: 7c6002a6 [mfspr] mfmq r3
16: 3a000001 [cal] lil r16,1
20: 81a1000c l r13,12(r1)
24: 4e800020 br
USER(5):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Johan Kullstam
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2g183t6pk.fsf@sophia.axel.nom>
Duane Rettig <·····@franz.com> writes:
thanks duane!
sorry to have gotten snippy on you.
i have saved your functions and will work on understanding and
implementing this. it will also help me on my to manipulating GF(256)
in my quest to produce a reed-solomon codec.
once again, i was thinking the wrong way for lisp. the C++
brain-damage is slowly getting undone...
--
Johan Kullstam [········@ne.mediaone.net] Don't Fear the Penguin!
From: Raymond Toy
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4nogmqv8fc.fsf@rtp.ericsson.se>
>>>>> "Johan" == Johan Kullstam <········@ne.mediaone.net> writes:
Johan> i have saved your functions and will work on understanding and
Johan> implementing this. it will also help me on my to manipulating GF(256)
Johan> in my quest to produce a reed-solomon codec.
Doing GF(2) arithmetic is easy as Duane's code shows. In fact rather
than doing the mods, you could just use logxor and logand to implement
+ and *.
GF(256) arithmetic is quite a bit different. You can't use modulo
arithmetic on integers. You have to manipulate polynomials whose
coefficients are from GF(2). You can, represent the polynomials as
bit-vectors or integers, however.
Oblisp: I had written a lisp package for GF(p) (prime p) long ago in
the hope of doing BCH (and Reed-Solomon) codes over any field, but
never quite completed it. Bummer.
Ray
From: Rob Warnock
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7ambi2$76js4@fido.engr.sgi.com>
Raymond Toy <···@rtp.ericsson.se> wrote:
+---------------
| Doing GF(2) arithmetic is easy as Duane's code shows. In fact rather
| than doing the mods, you could just use logxor and logand to implement
| + and *.
|
| GF(256) arithmetic is quite a bit different. You can't use modulo
| arithmetic on integers. You have to manipulate polynomials whose
| coefficients are from GF(2). You can, represent the polynomials as
| bit-vectors or integers, however.
+---------------
If you represent them as integers, then you can use table-lookups for
multiplication & division [to multiply, look up the "logs" of the numbers,
add them mod 256, then look up the anti-log of the sum -- and you can even
avoid the "mod 256" if you make the anti-log table be 512 entries long],
and addition/subtraction is still just XOR.
So GF(256) can be done reasonably fast, even without 64 KB lookup tables...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Johan Kullstam
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2aey9hwvy.fsf@sophia.axel.nom>
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Raymond Toy <···@rtp.ericsson.se> wrote:
> +---------------
> | Doing GF(2) arithmetic is easy as Duane's code shows. In fact rather
> | than doing the mods, you could just use logxor and logand to implement
> | + and *.
yes.
> | GF(256) arithmetic is quite a bit different. You can't use modulo
> | arithmetic on integers. You have to manipulate polynomials whose
> | coefficients are from GF(2). You can, represent the polynomials as
> | bit-vectors or integers, however.
> +---------------
>
> If you represent them as integers, then you can use table-lookups for
> multiplication & division [to multiply, look up the "logs" of the numbers,
> add them mod 256, then look up the anti-log of the sum -- and you can even
> avoid the "mod 256" if you make the anti-log table be 512 entries long],
> and addition/subtraction is still just XOR.
the logtable is good. however, you need to mod by 255 since GF(256)
without 0 under multiplication is isomorphic to Z_255 and not Z_256.
to multiply two non-zero elements of GF(256), it's probably easiest
and fastest to take logs, add them, subtract 255 if the sum exceeds
254 and then do anti-log. the simple integer subtraction is very
cheap. of course, using the div/mod instruction is horribly slow if
it needs to be done often.
for multiplying many non-zero elements of GF(256), take log on the lot
(gotta love mapcar!), add them, run a while-loop subtraction of 255
until you get something in the range 0-254 then antilog.
> So GF(256) can be done reasonably fast, even without 64 KB lookup
> tables...
yes.
GF(p^k) with p prime but not equal to 2 is another can of worms...
--
Johan Kullstam [········@ne.mediaone.net] Don't Fear the Paretheses!
From: Rob Warnock
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7ap587$7ir45@fido.engr.sgi.com>
Johan Kullstam <········@ne.mediaone.net> wrote:
+---------------
| ····@rigden.engr.sgi.com (Rob Warnock) writes:
| > to multiply, look up the "logs" of the numbers, > add them mod 256...
|
| the logtable is good. however, you need to mod by 255 since GF(256)
| without 0 under multiplication is isomorphic to Z_255 and not Z_256.
+---------------
Oops! Yes, of course! (*blush*)
And you need to special-case check if either of the args are zero, too,
since that log won't be in the (presumably finite) table. ;-}
+---------------
| fastest to take logs, add them, subtract 255 if the sum exceeds 254...
+---------------
Yes, *lots* faster than "mod 255".
+---------------
| for multiplying many non-zero elements of GF(256), take log on the lot
| (gotta love mapcar!), add them, run a while-loop subtraction of 255
| until you get something in the range 0-254 then antilog.
+---------------
And this will, of course, cost *at most* one subtraction per element
being multiplied (less one).
-Rob
p.s. Which reminds me of the way people often do IP checksums
(which are a 16-bit *1's*-complement sum) on 2's-complement machines...
Accumulate 16-bit elements into a 32-bit sum (which accumulates
into the upper half all of the "end-around-carries" that would
have occured with a 16-bit 1's-complement adder), then:
(loop
while (> sum 65535)
do (setf sum (+ (ldb (byte 16 16) sum) (ldb (byte 16 0) sum))))
or in C [assuming "u_int32_t sum"]:
while (sum > 65535)
sum = (sum >> 16) + (sum & 0xFFFF);
This carry-normalization can at *most* loop twice.
[Warning: Only works for packets < 128 KB in length (but all IP pkts are).]
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Raymond Toy
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4nsobyawo0.fsf@rtp.ericsson.se>
>>>>> "Johan" == Johan Kullstam <········@ne.mediaone.net> writes:
Johan> ····@rigden.engr.sgi.com (Rob Warnock) writes:
>> | GF(256) arithmetic is quite a bit different. You can't use
>> modulo | arithmetic on integers. You have to manipulate
>> polynomials whose | coefficients are from GF(2). You can,
>> represent the polynomials as | bit-vectors or integers, however.
>> +---------------
>>
>> If you represent them as integers, then you can use table-lookups
>> for multiplication & division [to multiply, look up the "logs" of
>> the numbers, add them mod 256, then look up the anti-log of the sum
>> -- and you can even avoid the "mod 256" if you make the anti-log
>> table be 512 entries long], and addition/subtraction is still just
>> XOR.
In my C version, I did use a table of logs and anti-logs. Worked
well.
Johan> the logtable is good. however, you need to mod by 255 since
Johan> GF(256) without 0 under multiplication is isomorphic to Z_255
Johan> and not Z_256.
Johan> to multiply two non-zero elements of GF(256), it's probably
Johan> easiest and fastest to take logs, add them, subtract 255 if the
Johan> sum exceeds 254 and then do anti-log. the simple integer
Johan> subtraction is very cheap. of course, using the div/mod
Johan> instruction is horribly slow if it needs to be done often.
Johan> for multiplying many non-zero elements of GF(256), take log on
Johan> the lot (gotta love mapcar!), add them, run a while-loop
Johan> subtraction of 255 until you get something in the range 0-254
Johan> then antilog.
To handle the case of zero, I just made the log function return
"-infinity", a very negative integer. The anti-log function checked
to see if a very negative integer was used (but not the same as the
log function) and would return 0 as the answer.
>> So GF(256) can be done reasonably fast, even without 64 KB lookup
>> tables...
GF(256) only has 256 elements. Why do you need a 64KB lookup?
Johan> yes.
Johan> GF(p^k) with p prime but not equal to 2 is another can of
Johan> worms...
You can still represent them as integers, although at this point, I
was going to just go with the polynomial representation and implement
the multiplication and division as shift registers. Alternatively, I
thought about representing the elements as powers of a primitive
element and use Zech (?) logs to do addition and subtraction.
Never finished this, though. I should though. Bummer.
Ray
From: Rob Warnock
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7atrgs$74oes@fido.engr.sgi.com>
Raymond Toy <···@rtp.ericsson.se> wrote:
+---------------
| ····@rigden.engr.sgi.com (Rob Warnock) writes:
| >> So GF(256) can be done reasonably fast, even without 64 KB lookup
| >> tables...
|
| GF(256) only has 256 elements. Why do you need a 64KB lookup?
+---------------
Consider this alterative to the log-add-antilog method:
(defun gf256-multiply (x y)
(svref gf256-multiply-table (+ (* 256 x) y)))
How big is "gf256-multiply-table"?
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Raymond Toy
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4nogmkbtsj.fsf@rtp.ericsson.se>
>>>>> "Rob" == Rob Warnock <····@rigden.engr.sgi.com> writes:
Rob> Consider this alterative to the log-add-antilog method:
Rob> (defun gf256-multiply (x y)
Rob> (svref gf256-multiply-table (+ (* 256 x) y)))
Rob> How big is "gf256-multiply-table"?
Of course, the old multiplication table. Forgot about the most
obvious way of doing multiplication. :-)
Ray
From: Rob Warnock
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7avouq$87b3l@fido.engr.sgi.com>
[Off-topic alert!]
Raymond Toy <···@rtp.ericsson.se> wrote:
+---------------
| Rob> How big is "gf256-multiply-table"?
|
| Of course, the old multiplication table. Forgot about the most
| obvious way of doing multiplication. :-)
+---------------
Which reminds me of a piece of computer history trivia:
The IBM 1620 (which was used in an NMR Lab where I worked in college),
like the IBM 1410, had arbitrary-precision hardware arithmetic. Numbers
were literally strings of decimal digits. And the hardware "multiply"
in the 1620 (though not the 1410) *did* use a lookup table, which was
loaded into low core (yes, "core"!) at boot time.
One of the favorite practical jokes the old-timers would play on the
newbies was to alter a few of the entries in the multiply lookup table,
then walk away. A newbie would come in, see the machine unused, and --
wanting to quickly get a chance to run their program before the grad
students came back & kicked him off the machine -- would load & run
their programs WITHOUT REBOOTING FIRST... (Oops!)
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: David Combs
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <dkcombsF7oJ0x.rC@netcom.com>
In article <············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>[Off-topic alert!]
><snip>
>Which reminds me of a piece of computer history trivia:
>
>The IBM 1620 (which was used in an NMR Lab where I worked in college),
>like the IBM 1410, had arbitrary-precision hardware arithmetic. Numbers
>were literally strings of decimal digits. And the hardware "multiply"
>in the 1620 (though not the 1410) *did* use a lookup table, which was
>loaded into low core (yes, "core"!) at boot time.
>
<snip>
At Dartmouth in 1964 across from the engineering school,
in the business school basement, was a 1620.
They put a radio on top of the machine.
Then would program multiply-loops of different-length
numbers, generating magnetic fields that the radio picked up.
Composed and played music on the radio. "Dartmouth's in town
again, ...", etc.
From: Erik Naggum
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128303134858480@naggum.no>
* Johan Kullstam <········@ne.mediaone.net>
| no, i do *not* want an integer (at least in the mathematical sense).
the MD5 algorithm requires a number of operations on 32-bit machine
integers. it would have cost them approximately nothing to require them
to be bignums (the algorithm is basically written in machine language,
and it appears only foolish to try anything else). the solution is to
use LOGAND to mask out the number bits. I'm probably going to rewrite
MD5 in assembler -- the C code is amazingly non-optimal, too.
#:Erik
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjd838rsqf.fsf@tfeb.org>
Johan Kullstam <········@ne.mediaone.net> writes:
> no, i do *not* want an integer (at least in the mathematical sense).
> i want elements of Z_n = Z - <n> which is not the integers Z but
> equivalence classes on Z, i.e., Z modulo multiples of n. the math in
> Z - <n> is different from integer math. mapping elements of Z - <n>
> into a subset of fixnum or bignum would be a particular
> representation. operations on the group elements do not follow the
> `conventional' integer operations.
Yes, I agree you don't want integers. But if you want an efficient
representation, you probably do need to represent them as integers,
because languages (even lisp) find it difficult to provide new
`nuerical' types that the hardware does not support a representation
of with any reasonable efficiency without sneakily using one that it
does. And choosing a representation matters unfortunately.
(of course, most HW *does* support Z_n but typically only for n =
2^8,2^16,2^32 and 2^32).
--tim
From: Raymond Toy
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <4nyalxuevf.fsf@rtp.ericsson.se>
>>>>> "Johan" == Johan Kullstam <········@ne.mediaone.net> writes:
Johan> the books i have seen are a little weak on the number crunching, bit
Johan> banging side of the house. i hear that lisp can be as fast as fortran
One starting point on number crunching in Lisp can be found in the
CMUCL User's Guide (see www.cons.org). It's written for CMUCL, but
the hints there probably apply to all implementations of Lisp.
Johan> on numeric problems. i have come to lisp out of disgust with C++ and
Johan> i am finding that i like lisp. but is they any information on how to
Johan> solve those problems which are traditionally done in fortran or C?
You can solve them in exactly the same way, I would think. Your Lisp
code might look more like Fortran or C, but so what? It works now,
and if you want, you can redo it later.
Ray
From: Paolo Amoroso
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <36cbf173.2499845@news.mclink.it>
On 17 Feb 1999 08:10:48 -0500, Johan Kullstam <········@ne.mediaone.net>
wrote:
> i am finding that i like lisp. but is they any information on how to
> solve those problems which are traditionally done in fortran or C?
You may check:
"Fast Floating Point in Common Lisp"
K.A. Broughan, R.J. Fateman, D. Rettig, D.K. Willcock
ftp://peoplesparc.berkeley.edu/pub/papers/lispfloat.ps
"Floating Point Performance of Common Lisp"
Christopher J. Vogt
ACM SIGPLAN Notices, Vol. 33, N. 9, September 1998, page 103
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Steve Gonedes
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m267906haf.fsf@KludgeUnix.com>
Johan Kullstam <········@ne.mediaone.net> writes:
< nod.
<
< however, what if i actually *want* a wrap around. i do not want an
< integer but a number from the ring Z_n.
<
< this is not an idle question. i could actually use this. for
< example, i am measuring angles on a satellite dish pedestal and my
< sensor equipment maps the angle to a number from 0 to 65535. it'd be
< nice to wrap around automatically, since the concept i am trying to
< handle - angles - do this.
<
< i.e., (+ angle1 angle2) should return a new angle in the canonical
< angle format 0 to 65535.
<
< other times it'd be nice to have a wrapping integer type is for
< periodic time-varying filter operations in a modem.
<
< the books i have seen are a little weak on the number crunching, bit
< banging side of the house. i hear that lisp can be as fast as fortran
< on numeric problems. i have come to lisp out of disgust with C++ and
< i am finding that i like lisp. but is they any information on how to
< solve those problems which are traditionally done in fortran or C?
<
< --
< Johan Kullstam [········@ne.mediaone.net] Don't Fear the Penguin!
You can define a new type and keep the number withing a range using
ldb.
(deftype signed-short () '(signed-byte 16))
(defun add-signed-shorts (x y)
(the (signed-short)
(ldb (byte 16 0) (+ x y))))
(add-signed-shorts 65535 12)
=> 11
The declaration is really just cosmetic, but maybe useful for readers
of your program. The call to `ldb' is like `ash' with my
implementation. It just provides you with a nice abstraction.
From: James A. Crippen
Subject: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <g183k7lr.fsf_-_@lambda.uaa.alaska.edu>
Johan Kullstam <········@ne.mediaone.net> writes:
> the books i have seen are a little weak on the number crunching, bit
> banging side of the house. i hear that lisp can be as fast as fortran
> on numeric problems. i have come to lisp out of disgust with C++ and
> i am finding that i like lisp. but is they any information on how to
> solve those problems which are traditionally done in fortran or C?
(This is a bit off topic, but considering the drift of this thread
nobody should notice.)
I've been noticing more and more "I came to Lisp because {C,C++}
churns my stomach and leaves spots before my eyes" comments. As the
Lisp family of languages slowly (re?)infiltrates the commercial
computing community can we expect better design of competing
programming languages and development systems in response? It seems
that modern development environments are finally starting to approach
the awesome standard that *Emacs presents, and in some cases non-Lisp
development systems are approaching the almost unreal capabilities
offered by Genera (though I'm sure nothing will be *that* nifty and
well integrated for n years, where n is a suitably large positive
integer). And the programming languages are attaining respectable
heights of capability as well. But Lisp is just kinda plodding along,
something new here and something new there, but nothing truly
astounding seems to be going on. Lisp is subverting other systems,
but it doesn't appear to be doing much itself, IMHO.
I'm of the opinion that we need some sort of free implementation of a
total-Lisp environment analogous to the Lisp Machines of yore.
Something that anyone who has enough marbles to run a FreeNIX can
download and install on YA partition and run, and presumably in a few
weeks of fooling around realize the Way Things Should Be.
Perhaps it all goes back to Gabriel's "Right Thing" versus "Worse is
Better". And the only people who know that there's another way,
specifically the "Right Thing" way, are Lisp programmers and their
friends in the research communities. Everyone else steals ideas from
Lispish systems and implements them with a "Worse is Better"
philosophy which creates constant problems with integration,
completeness, orthogonality, and so forth. Everything we've come to
expect from modern commercial software.
Anyway, just had to rant a bit.
james
--
<crippenj at saturn math uaa alaska edu> Kallisti! <james at cryptology org>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/MU/O d?(--) s: a--(?) C+++(++++)>$ UBLOS*+++(++++)>$ P+>+++ L+++>$ E++++
W-- N++ o+ K+++>++++ w--- O- M- V--- ···@ ··@ Y+ PGP>+++ ···@ 5? X? R* !tv
b++++ DI++++ D--- G++>++++ e* h* r--- y-- NT{-} A48 HH++++>* PP+++
------END GEEK CODE BLOCK------
From: Rainer Joswig
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <joswig-1802991739300001@pbg3.lavielle.com>
In article <···············@lambda.uaa.alaska.edu>, ········@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> development systems are approaching the almost unreal capabilities
> offered by Genera (though I'm sure nothing will be *that* nifty and
> well integrated for n years, where n is a suitably large positive
> integer)
A bignum or a fixnum?
> I'm of the opinion that we need some sort of free implementation of a
> total-Lisp environment analogous to the Lisp Machines of yore.
> Something that anyone who has enough marbles to run a FreeNIX can
> download and install on YA partition and run, and presumably in a few
> weeks of fooling around realize the Way Things Should Be.
I think so. But it will not happen very soon:
- bad reputation of Lisp (parentheses, XYZ is cooler, lacks static typing, ...)
- not enough mass of experience Lisp hackers
- no real concrete need for a Lisp OS
--
http://www.lavielle.com/~joswig
From: Duane Rettig
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <4r9rno8y7.fsf@beta.franz.com>
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@lambda.uaa.alaska.edu>, ········@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
>
> > development systems are approaching the almost unreal capabilities
> > offered by Genera (though I'm sure nothing will be *that* nifty and
> > well integrated for n years, where n is a suitably large positive
> > integer)
>
> A bignum or a fixnum?
Yes.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Rainer Joswig
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <joswig-1802992027520001@pbg3.lavielle.com>
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <···············@lambda.uaa.alaska.edu>, ········@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> >
> > > development systems are approaching the almost unreal capabilities
> > > offered by Genera (though I'm sure nothing will be *that* nifty and
> > > well integrated for n years, where n is a suitably large positive
> > > integer)
> >
> > A bignum or a fixnum?
>
> Yes.
Which one?
--
http://www.lavielle.com/~joswig
From: Johan Kullstam
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <m290dvl0wv.fsf@sophia.axel.nom>
······@lavielle.com (Rainer Joswig) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > > In article <···············@lambda.uaa.alaska.edu>, ········@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> > >
> > > > development systems are approaching the almost unreal capabilities
> > > > offered by Genera (though I'm sure nothing will be *that* nifty and
> > > > well integrated for n years, where n is a suitably large positive
> > > > integer)
> > >
> > > A bignum or a fixnum?
> >
> > Yes.
>
> Which one?
maybe it's a long-float?
--
Johan Kullstam [········@ne.mediaone.net] Don't Fear the Penguin!
From: Christopher R. Barry
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <874sohogc1.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > > In article <···············@lambda.uaa.alaska.edu>, ········@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> > >
> > > > development systems are approaching the almost unreal capabilities
> > > > offered by Genera (though I'm sure nothing will be *that* nifty and
> > > > well integrated for n years, where n is a suitably large positive
> > > > integer)
> > >
> > > A bignum or a fixnum?
> >
> > Yes.
>
> Which one?
Absolutely.
Christopher
From: Kelly Murray
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <36CDC21D.18724772@IntelliMarket.Com>
James A. Crippen wrote:
> ...
> I'm of the opinion that we need some sort of free implementation of a
> total-Lisp environment analogous to the Lisp Machines of yore.
> Something that anyone who has enough marbles to run a FreeNIX can
> download and install on YA partition and run, and presumably in a few
> weeks of fooling around realize the Way Things Should Be.
>
Good idea. Now that Linux is becoming more mainstream
and gonna be bundled-in with PC
hardware by IBM (and others), the "something different,
something better" crowd (of which I'm a member) might actually
have a chance to build something "different and better."
At least the "inferior because its popular" crowd (of which
I'm NOT a member) might have to look for something else to champion.
-Kelly Murray ···@niclos.com
NiCLOS -- New Internet Common Language Object System
where there isn't an Operating System, only an Object System
where there isn't Bits in Memory, only Objects
where there isn't Bytes in Files, only Collections of Objects
From: Christopher Browne
Subject: Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))
Date:
Message-ID: <p0sz2.5546$fZ4.3483@news2.giganews.com>
On Fri, 19 Feb 1999 11:57:17 -0800, Kelly Murray <···@IntelliMarket.Com> wrote:
>James A. Crippen wrote:
>> ...
>> I'm of the opinion that we need some sort of free implementation of a
>> total-Lisp environment analogous to the Lisp Machines of yore.
>> Something that anyone who has enough marbles to run a FreeNIX can
>> download and install on YA partition and run, and presumably in a few
>> weeks of fooling around realize the Way Things Should Be.
>>
>
>Good idea. Now that Linux is becoming more mainstream
>and gonna be bundled-in with PC
>hardware by IBM (and others), the "something different,
>something better" crowd (of which I'm a member) might actually
>have a chance to build something "different and better."
>At least the "inferior because its popular" crowd (of which
>I'm NOT a member) might have to look for something else to champion.
Minor problem: OSKit may be a preferable candidate for the "ultimate
Lisp system," since it encourages the notion of attaching in
language-specific functionality down at the OS level, which would be
particularly useful for Lisp in terms of providing a global memory pool.
It uses device drivers from Linux/FreeBSD, which *hopefully* simplifies
the annoying task of trying to support new hardware.
Happily, it appears that there has been a new release of OSKit, and it
looks like they may have resolved the licensing issues...
--
Who needs fault-tolerant computers when there's obviously an ample
market of fault-tolerant users?
········@hex.net- <http://www.ntlug.org/~cbbrowne/oses.html>
From: Christopher R. Barry
Subject: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <87zp69mnql.fsf_-_@2xtreme.net>
········@news.hex.net (Christopher Browne) writes:
> [...] OSKit [...] "ultimate Lisp system" [...] device drivers [...]
I think all that could be discussed about this has been. The LispOS
mailing list is finally shutting down this month.
Mike McDonald is working on a free CLIM which you need to implement
the Listener (could not Garnet do this?), which has generally been
agreed to be the first thing you need for a cool Lisp
environment. Fred Gilham also mentioned something of doing a
full-blown Garnet IDE/Debugger.
It seems to me like it's more effort than it's worth (and I
substantiate my view with the progress that has been made so far. If
someone with the know-how thought it was really worth it than they
might have actually written a little code).
Some stuff just isn't fast in Lisp anyways, or fast in Lisp on
Intel/commodity hardware at any rate. Christopher Vogt's JPEG decoder
comes to mind... Erik Naggum mentioned improving the performance of
his system ten-fold by writing one small part in C, and recently
mentioned how Lisp couldn't do MD5 Checksums so hot or something like
that either.
Until hardware gets better support for Lisp or Lisp compilers get
better at bit-fiddling brain-dead hardware for essential
speed-critical low-level utility code that C and assembler are the
better choices for right now I think I'll be content knowing that a
nice IDE is the best way to go.
And Emacs ain't too shabby either. I've had my fill of Genera
screenshots courtesy of Rainier and none of this "dynamic window" and
likewise stuff seems to do anything that Emacs fundamentally can't. So
you can click a URL in any app for a completion instead of just Emacs
frames. Big deal. I bet most of the fundamental applications in the
Genera environment have applications with largely equivalent
functionality that are already well integrated into Emacs. Document
Examiner you say? We've got an info node browser, hypertext browser,
OO-browser and manual page browser that I can think of off the top of
my head, along with all the powerful help functions. And XEmacs can
embed cool color graphics and glyphs/widgets into the frames to.
Is there anything a programmer cannot do elegantly and efficiently
within Emacs? This is a wonderfully documented Lisp environment with
interpreter and compiler that runs on any modern platform. It's also
probably the most famous and successful Lisp application of all time.
So we've got our "LispOS". Problem is, the Lisp is very old and far,
far from ANSI CL conforming. XEmacs has made a little progress in
modernization and some of the core developer homepages and posts
indicate a desire to move to CL but it will be a long, long road and
GNU Emacs is slated for Guile Scheme, so it ain't ever getting
there. Hemlock is a CL Emacs but it has extremely limited features
compared to the heavyweights and a lot more difficult coding would be
needed to get it to the point where it has the primitive functionality
to support some of the features of the heavyweights, and even then the
real battle would have only begun as moving cool packages like gnus
and all the other stuff over would take more effort than any group
could be motivated to put in.
Anyways, the only reason I posted all of this is because we can safely
assume at this point that noone is ever going to actually try and port
a modern CL to the OSKit or somesuch or write anything large and
powerful and sophisticated from scratch that would only be of use to a
LispOS, so we can stop throwing around ideas for some lurking LispOS
mystery hacker.
Emacs needs to be extended into a true, modern application development
platform based on CL. Instead of people thinking "I'm going to develop
for Win32, or Java, or Unix, or Motif, or ...", they should think
Emacs. So we need to get Emacs looking good in CL and have one
standard API for all platforms within which you can do real GUI
applications, and then ultimately high performance 3D graphics, stereo
sound, networking, etc, etc....
Of course none of this will ever get done either and it was also kind
of dumb to bring up, but if we must have yet another LispOS thread, I
think it's more useful to discuss modernizing Emacs into a modern CL
programming platform instead of just talking about OSKit and
implementing various OS services in Lisp for the hundredth time.
Hmm... think I'll play a game of tetris or minesweeper in XEmacs, then
it's time to sleep.
Christopher
From: Kent M Pitman
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <sfwyalt6vnb.fsf@world.std.com>
I'm not going to reply to this whole message, and might also decline
to even reply to followups since this looks like a tar-pit where one
could waste time uselessly, but I feel something needs to be said
here:
······@2xtreme.net (Christopher R. Barry) writes:
> And Emacs ain't too shabby either. I've had my fill of Genera
> screenshots courtesy of Rainier and none of this "dynamic window" and
> likewise stuff seems to do anything that Emacs fundamentally can't. So
> you can click a URL in any app for a completion instead of just Emacs
> frames. Big deal. I bet most of the fundamental applications in the
> Genera environment have applications with largely equivalent
> functionality that are already well integrated into Emacs.
I started to reply at length to the many misstatements in your
message. I don't really have a problem with your excitement about
Emacs. I use Emacs a lot. I have for over 20 years. I'm typing to
it now. BUT to the extent that you try to claim it replicates Genera,
you're both kidding yourself (which I don't really care about one way
or another) and engaging in historical revisionism (which does trouble
me and is the reason I'm responding here).
The value in Genera's Dynamic Windows is NOT about "completion" it's
about object-oriented connected-ness of the entire system. You aren't
clicking on the "name" in dynamic windows. You are clicking on the EQ
object. This means you can, for example, mouse an instance of
something and get that instance as an object to inspect and
manipulate. Emacs has NO basis for equivalent stuff. None. If
you've seen Genera only through screen shots, you could never imagine.
It's like trying to explain someone whose only seen streams of text
what an object pointer is.
Last night on my Lisp Machine I was frustrated by the absence of NT
file support. I had no idea how file support was implemented, but I had
a general working understanding of how the Lisp Machine was organized,
and within a small number of hours I had learned about how to extend the
operating system to talk to NT over TCP and implemented a new set of classes
so that I could transparently talk to my NT box over my local ethernet.
A lot of my ability to do this was enabled by the ability to point and click
on objects in order to debug them and inspect them without any fear or
confusion about whether I was using the right sources, the right packages,
etc.
I cannot by any stretch of the imagination sit down at Emacs and do
the equivalent thing. I can't learn about even how to extend Emacs
itself in so short a time, much less use Emacs to help me learn about
Windows NT or Unix or whatever. Sure, Emacs has some
self-documentation. Sure, the sources are there. But for example,
there's no assurance when I read in a source file that it's the same
source file that I loaded. The lisp machine keeps meticulous records
not only of which source files are loaded and from where but which
functions have been patched by which files. That means I can't make a
mistake and use the wrong tags file or the wrong version of files
backing up a tags file. I was confused by the behavior of something
that and I looked at its source, it correctly told me about the patch
file that had redefined the function rather than just leading me to
believe that the system source was correct. There are myriad subtle
ways in which Emacs is only a pale shadow of Zmacs.
> Document
> Examiner you say? We've got an info node browser, hypertext browser,
> OO-browser and manual page browser that I can think of off the top of
> my head, along with all the powerful help functions.
The document examiner had some nice ideas for the time, and is functional
enough for what it tries to do. I wouldn't advocate it for modern use,
but what's really compelling about it even now is how much better
documented the Lisp Machine is than many modern operating systems.
Sometimes when people point at the document examiner, they're really
meaning the doc.
> And XEmacs can
> embed cool color graphics and glyphs/widgets into the frames to.
> Is there anything a programmer cannot do elegantly and efficiently
> within Emacs?
In principle? Well, it's all software. You can make it be whatever
youwant, I guess. But in practice, if you're asserting that Emacs
duplicates the features of Genera's editor, I think you're kidding
yourself.
Certainly the Lisp Machine is missing some recent bells and whistles,
yes, but so too are modern systems missing many things the Lisp
Machine did right.
Also, I'm not suggesting this was a property of the Lisp Machine or of
special hardware. Nothing the LispM did couldn't be implemented in
standard systems if people were of a mind to do it. But they haven't
been, and it's historical revisionism to deny that stuff has been lost.
> [...] Emacs needs to be extended into a true, modern application development
> platform based on CL. Instead of people thinking "I'm going to develop
> for Win32, or Java, or Unix, or Motif, or ...", they should think
> Emacs. So we need to get Emacs looking good in CL and have one
> standard API for all platforms within which you can do real GUI
> applications, and then ultimately high performance 3D graphics, stereo
> sound, networking, etc, etc....
I have no problem with this as an approach to take. But if you want
something to study, the Lisp Machine still has a LOT of lessons for you
in what more an editor could do in this regard. It is not the only resource
to look at--much useful stuff has been done in recent years not tracked
by the Lisp Machine. But the right thing is not to be dismissive. There
IS a basis for people's lingering fondness for the Lisp Machine.
Also, I don't see how GNU Emacs Lisp could ever become CL-like, since
Stallman seems to control it and he doesn't seem to like CL. I and
others fussed at him long ago when he diverged from CL. It seemed to me a
conscious decision on his part to not care. (Maybe even a good decision,
I'm not trying to moralize. i'm just saying that the decision to be more
or less cl-like is a political one, and not a community one. And for all
he talks about freedom for all, my impression is that he's very possessive
and controlling about these free things he makes, such that you have a pretty
severe obstacle to ever really changing it...)
From: Christopher R. Barry
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <87ogmon1it.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> The value in Genera's Dynamic Windows is NOT about "completion" it's
> about object-oriented connected-ness of the entire system. You aren't
> clicking on the "name" in dynamic windows. You are clicking on the EQ
> object. This means you can, for example, mouse an instance of
> something and get that instance as an object to inspect and
> manipulate.
> within a small number of hours I had learned about how to extend the
> operating system to talk to NT over TCP and implemented a new set of
> classes so that I could transparently talk to my NT box over my
> local ethernet. A lot of my ability to do this was enabled by the
> ability to point and click on objects in order to debug them and
> inspect them without any fear or confusion about whether I was using
> the right sources, the right packages, etc.
Within Garnet you can move your mouse over any object in your GUI and
hit F1 to bring up the Inspector which gives you information about
every single slot value in the object, displays it's "is-a" hierarchy,
and shows you what things it's formulas depend on.
Under the X windowing system there is this standard tool "editres"
that lets you click on any client and bring up it's class hierarchy
tree and edit resources interactively.
I know these things aren't as cool as the LispM's equivalent, but is
that it? It sounds like you have few nice applications that have
functionality equivalent to modern environments but because of their
tight integration you can do a few things that you otherwise couldn't.
> But for example, there's no assurance when I read in a source file
> that it's the same source file that I loaded. The lisp machine
> keeps meticulous records not only of which source files are loaded
> and from where but which functions have been patched by which files.
> That means I can't make a mistake and use the wrong tags file or the
> wrong version of files backing up a tags file.
There are modern IDEs available for popular languages with powerful
project file mechanisms with very similar capability. Not as cool, but
still powerful and usable.
> There are myriad subtle ways in which Emacs is only a pale shadow of
> Zmacs.
Other than some of the cool functionality that arises within Zmacs
from its super-tight integration with the rest of the environment,
what can Zmacs itself specifically do that Emacs can't?
> > And XEmacs can
> > embed cool color graphics and glyphs/widgets into the frames to.
> > Is there anything a programmer cannot do elegantly and efficiently
> > within Emacs?
>
> In principle? Well, it's all software. You can make it be whatever
> youwant, I guess. But in practice, if you're asserting that Emacs
> duplicates the features of Genera's editor, I think you're kidding
> yourself.
This functionality to click on an instance of any object seems really
cool, and indeed Emacs as it is currently could never do this. But is
that all? And again, this feature doesn't seem specific to Zmacs but
rather Genera itself within which Zmacs is tightly integrated.
> Also, I'm not suggesting this was a property of the Lisp Machine or of
> special hardware. Nothing the LispM did couldn't be implemented in
> standard systems if people were of a mind to do it. But they haven't
> been, and it's historical revisionism to deny that stuff has been lost.
Problem is, only people that have access to them know specifically
what makes them cool. It's nice to hear from you what some of this
functionality really is, but it seems that most of it is duplicated at
least in part by some modern tools/environments.
> Also, I don't see how GNU Emacs Lisp could ever become CL-like, since
> Stallman seems to control it and he doesn't seem to like CL. I and
> others fussed at him long ago when he diverged from CL. It seemed to me a
> conscious decision on his part to not care. (Maybe even a good decision,
> I'm not trying to moralize. i'm just saying that the decision to be more
> or less cl-like is a political one, and not a community one. And for all
> he talks about freedom for all, my impression is that he's very possessive
> and controlling about these free things he makes, such that you have a pretty
> severe obstacle to ever really changing it...)
As I mentioned before, GNU Emacs is slated for Guile Scheme and
nothing in the world can stop that. I remember some post from a guy
that was working on getting lexical scope into GNU Emacs and the
compiler but he said that RMS expressed reluctance in an email because
the introduction of lexical scope would probably break some older code
and in his opinion (I speculate) it must not be worth the effort to
update older code to do the right thing in a lexical environment
despite its advantages. I know GNU Emacs is kinda doomed in this
specific regard, but XEmacs isn't. The developers are more open and
have expressed interest in modernization to CL. For example, as of
XEmacs 20.x the character-integer equivalence no longer applies and
there are new data types like "character" and "char-table". There are
functions like "old-eq" and "old-equal" that pretend that characters
and integers are the same.
Under GNU Emacs:
(eq ?A 65)
t
Under XEmacs:
(eq ?A 65)
nil
(old-eq ?A 65)
t
Now of course, we've got to get the "#" read syntax going so we can do
#\A instead of ?A, and have the read-case uppercase symbols by default
instead of doing everything case-sensitively, for starters....
Christopher
From: Kent M Pitman
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <sfwyalstyq7.fsf@world.std.com>
······@2xtreme.net (Christopher R. Barry) writes:
> Within Garnet you can move your mouse over any object in your GUI and
> hit F1 to bring up the Inspector which gives you information about
> every single slot value in the object, displays it's "is-a" hierarchy,
> and shows you what things it's formulas depend on.
Within DW, you can move your mouse over any object or subobject
that has been displayed, whether or not it was part of any GUI.
You get this virtually for free and have to work hard to suppress it
if you don't want it. But it doesn't require any special programming.
One of the most common ways to get a foothold in Genera for debugging
something is to (1) find a place where the thing you want to use
appears visually, (2) click Super-Left to get the object into your
hands for read-eval-print, inspection, etc, (3) use (ed (type-of *))
to find its source reliably and with no foreknowledge of what the
type is, who wrote the program, what their file conventions were,
who loaded it, or any of myriad other things that other systems
make me do.
> Under the X windowing system there is this standard tool "editres"
> that lets you click on any client and bring up it's class hierarchy
> tree and edit resources interactively.
Not resources. Objects. All objects. Not just the heavyweight ones.
Lists. Integers. I somehow don't believe you when you say this is the
same as what Genera does.
The usual thing DW enables is the debugging of things that the
person did NOT make part of the standard interface. Pointing to a UI
tool and saying it allows you to plan for structured debugging of
something is missing the point.
Or maybe you're saying that Garnet allows me to cross the boundary into
the internals of systems. Maybe I'm missing out.
When you can make the claim that if you teach me a few paragraphs
worth of stuff, I will have all of the information I need in order to
bootstrap myself into a complete understanding of the entire operating
system and all of its conventions, I'll believe you Garnet and X are
as powerful as Genera and Dynamic Windows. Until then, I'll continue
to believe they are different. Incidentally, I'm dying to know that
there is a tool that will do all that Genera could do only for stock
hardware becuase the stack of books I need to buy in order to be
equivalently competent with other systems is daunting and I could
really do with the savings in time, energy, and money of learning things
about standard systems in the way I've been doing...
I don't even find Emacs itself to be equivalently self-documenting and
easy to get around in, much less the many systems that Emacs touches.
> I know these things aren't as cool as the LispM's equivalent, but is
> that it? It sounds like you have few nice applications that have
> functionality equivalent to modern environments but because of their
> tight integration you can do a few things that you otherwise couldn't.
Dynamic Windows offered a tight integration with the system.
You alleged that all that it offered is captured by Emacs.
The burden is on you to show that it is. Defining away the problem
does not do that.
You haven't said how Emacs lets me "discover" systems. You've only
said it provides tools that enable those who already know about a system,
and Garnet/X tools that let me inspect the formally presented UI of a
system. That's not the same.
> > But for example, there's no assurance when I read in a source file
> > that it's the same source file that I loaded. The lisp machine
> > keeps meticulous records not only of which source files are loaded
> > and from where but which functions have been patched by which files.
> > That means I can't make a mistake and use the wrong tags file or the
> > wrong version of files backing up a tags file.
>
> There are modern IDEs available for popular languages with powerful
> project file mechanisms with very similar capability. Not as cool, but
> still powerful and usable.
This started out by a discussion of what's cool. You said Emacs was
cool and nothing else was needed. Now you're qualifying your remarks
by saying everything is not as cool, and dodging the specifics I laid out.
> > There are myriad subtle ways in which Emacs is only a pale shadow of
> > Zmacs.
>
> Other than some of the cool functionality that arises within Zmacs
> from its super-tight integration with the rest of the environment,
> what can Zmacs itself specifically do that Emacs can't?
Paraphrase: "Other than the fact that the system you're talking about
involved a lot of people investing time and thought on various issues
that have been lost, can you explain to me why a system in which
that thought has been lost is deficient?" Uh, ... no. I can't.
This was about lost features. This was about your claim that nothing
had been lost. If you leave out the stuff that's lost, you're right,
there's no difference.
Look, I used to literally sit around in my office at MIT years ago and
fuss at people who said Lisp Machines were everything. (I used and liked
Lisp Machines but I myself didn't think they were what they were because
of the hardware--they were what they were because of the software and
the ideas behind them.) I used to ask people "What's an impossible thing
to do? I'm looking for something to do this afternoon in Teco that people
say can only do on Lisp Machines." People said Zmail. I wrote the
approximate equivalent in Teco--filters, and all that. They wanted a
filter menu. I wrote that in Teco. They wanted mouse handling. (That
was tough because PDP10's didn't have mice, but I used my imagination a
little and arranged a mouse protocol from Lisp Machines so you could telnet
to the teco-based Emacs and click on my filter menus.) They wanted
Zmail init files. I wrote a Lisp compiler in Teco so that I could use
people's Zmail init files unmodified. It was about 20K words of Teco
code, btw. Code was smaller back then... sigh.
Anyway, I *know* what it is to look at functionality and duplicate it
elsewhere. It CAN be done. I am not saying it can't. What I'm
saying is that it has not been done, and it's a crying shame. Few
people even know there ever WAS a lisp machine, and those who do are
mostly not rich enough personally to invest the time to duplicate what
was there. Many people spent a big chunk of their lives investing in this
dream and it didn't pan out quite as we wish. Ok. Sometimes other
events win out--not always even for the right reasons. Or at least for
the reasons you wish. But don't add insult to injury to say that the
losers in battles such as these had nothing to offer.
Common Lisp beat out Interlisp, and maybe for good reasons but it doesn't
mean Interlisp had nothing to offer--some very good ideas got lost in the
shuffle and I don't pretend that Common Lisp just obviously had a better
way. Java is going to beat out Smalltalk perhaps, but that doesn't mean
Java is better than Smalltalk. We owe it to the losers in these little
skirmishes to make sure that, if nothing else, the good ideas are not lost
along with the framework. And we do not accomplish that by defining
that there was nothing lost. That's both callous to those who worked
hard on these other things and short-sighted to the future, which might one
day care about the things that got lost.
There are still Lisp Machines around. If you want to opine on them
with authority, get one and use it. There is no substitute for first-hand
data in situations like this.
> > > And XEmacs can
> > > embed cool color graphics and glyphs/widgets into the frames to.
> > > Is there anything a programmer cannot do elegantly and efficiently
> > > within Emacs?
> >
> > In principle? Well, it's all software. You can make it be whatever
> > youwant, I guess. But in practice, if you're asserting that Emacs
> > duplicates the features of Genera's editor, I think you're kidding
> > yourself.
>
> This functionality to click on an instance of any object seems really
> cool, and indeed Emacs as it is currently could never do this. But is
> that all? And again, this feature doesn't seem specific to Zmacs but
> rather Genera itself within which Zmacs is tightly integrated.
No. It's not all. I could enumerate any of a zillion things the
Lisp Machine editor system has that are not in Emacs. But what would be
the point? You'd see any finitely enumerable list, tell me it was all
stuff that could be done, and then say that my point was moot.
Here are a few, not intended to be complete, but to give you a spirit
of the degre of "precision" in Zmacs commands that distinguish them from
Emacs commands:
* Tags Multiple Query Replace From Buffer
This is an extension to Tags Multiple Query Replace (which does a
multiple-strings-at-once Query Replace over a Tags Table; and,
incidentally, the Tags Tables don't have to be files--the Lisp
Machine just makes them up on the fly from spaces of buffers, from
system definitions, etc. on user request). It allows you to put
pairs of elements and their replacements in a buffer and have
all replaced in parallel.
As with all operations of this kind (including Tags operations and
other mapping operations like "Edit Compiler Warnings"), this creates
a "possibilities buffer" which is a physical manifestation of keeping
your finger on where you were in the middle of a complex operation
so that if you see something else you want to do while you are
doing the replacement, you can suspend the operation and resume it
later perhaps after doing other replacements or edits. When editing
the ANSI CL spec, something I refused to do on anything but a Lisp
Machine, I often had dozens of these buffers stacked up in simultaneous
use and was successfully able to resume them to make sure all completed
while allowing the system to accomodate my "focus".
* Source Compare
This command allows you to run a source comparision program (which
itself is just presentationally way better than Unix diff or
emacs compare-windows). There was a public version of a source
comparison program written by someone a while back that is as good
but is in CL and isn't integrated into Emacs. Alas. But in addition
to the presentational issues, which are comparatively minor, the real
feature was how this could be called. It prompts for two things
describing what to compare, including "buffer", "file", "region",
"definition", "top of kill ring" and "second in kill ring". you type
a single character (B/F/R/D/c-Y/m-Y) for each such prompt. It's
completely essential for comparing files. What I can't comprehend
is why no one thinks this is essential in a non-versioned file system.
It's important enough in a versioned file system but in a non-versioned
system one is always finding "probable copies" of files all over the place
and trying to understand the differences. Ready access to program
controlled source compare is central to everything I do and basically
wholly absent on stock hardware. Another example is when you are saving
a file on the lisp machine and you find it's been written by someone else;
in emacs the query just tells you of a problem--in zmacs it offers to
compare the files before making you decide whether to continue saving.
It's not the feature itself, though that's important, but
it's the attention to detail at this fine-grained level throughout the
system which is why the lisp machine is so fondly remembered.
And that's my overall point. It's not just about what's missing.
It's about the lack of interest in those who have created Emacs in
supporting those other things. I still just use my Lisp Machine.
It's right here next to my PC, and on a regular basis I just move to
the other chair and edit in Zmacs. 6 years after heavy-duty
development ceased on Zmacs, it still whomps the competition and makes
me not care that processor speeds have gone up a zillionfold in the
meantime. Others will tell you the same.
I WISH I could use features like that on a fast processor. that would
be great. But it isn't likely to happen soon.
You can say the burden is on us old-timers to tell you what's missing or
we shouldn't be whining. But I don't see it that way. I see the burden is
on the victors, who have the resources and who claim their way is better,
to show us that they won for good reason. We did our part for the cause.
We may or may not continue to try to do things to assure the ideas aren't
lost.
I spend a lot of my time trying to make sure old ideas make it onto
the books and don't get lost. But I'm just one person. It takes more
than one person. And the task does not begin by dismissing the need
to do the job.
> > Also, I'm not suggesting this was a property of the Lisp Machine or of
> > special hardware. Nothing the LispM did couldn't be implemented in
> > standard systems if people were of a mind to do it. But they haven't
> > been, and it's historical revisionism to deny that stuff has been lost.
>
> Problem is, only people that have access to them know specifically
> what makes them cool. It's nice to hear from you what some of this
> functionality really is, but it seems that most of it is duplicated at
> least in part by some modern tools/environments.
You can order doc sets ... people give them away on this and other lists
periodically.
> > Also, I don't see how GNU Emacs Lisp could ever become CL-like, since
> > Stallman seems to control it and he doesn't seem to like CL. I and
> > others fussed at him long ago when he diverged from CL. It seemed to me a
> > conscious decision on his part to not care. (Maybe even a good decision,
> > I'm not trying to moralize. i'm just saying that the decision to be more
> > or less cl-like is a political one, and not a community one. And for all
> > he talks about freedom for all, my impression is that he's very possessive
> > and controlling about these free things he makes, such that you have a pretty
> > severe obstacle to ever really changing it...)
>
> As I mentioned before, GNU Emacs is slated for Guile Scheme and
> nothing in the world can stop that. I remember some post from a guy
> that was working on getting lexical scope into GNU Emacs and the
> compiler but he said that RMS expressed reluctance in an email because
> the introduction of lexical scope would probably break some older code
> and in his opinion (I speculate) it must not be worth the effort to
> update older code to do the right thing in a lexical environment
> despite its advantages. I know GNU Emacs is kinda doomed in this
> specific regard, but XEmacs isn't. The developers are more open and
> have expressed interest in modernization to CL. For example, as of
> XEmacs 20.x the character-integer equivalence no longer applies and
> there are new data types like "character" and "char-table". There are
> functions like "old-eq" and "old-equal" that pretend that characters
> and integers are the same.
>
> Under GNU Emacs:
>
> (eq ?A 65)
> t
>
> Under XEmacs:
>
> (eq ?A 65)
> nil
>
> (old-eq ?A 65)
> t
>
> Now of course, we've got to get the "#" read syntax going so we can do
> #\A instead of ?A, and have the read-case uppercase symbols by default
> instead of doing everything case-sensitively, for starters....
I wish you luck in this regard. These matters are syntactically small
and I don't really care a lot about them at the micro level. But agreement
is important and Anything that unifies the Lisp communities is good.
"?" is a bad choice of character becuase it frustrates Scheme programs
who want to use "?" instead of "P" for the end of predicate names.
Even if one isn't going for Scheme compatibility, going for things that
don't creating gaping divides between the communities is good.
From: Christopher R. Barry
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <87lnhsmw3v.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
[several hundred lines of great Lisp Machine info deleted]
Well, maybe I'll look around for an old 3650 sometime....
Christopher
From: Kent M Pitman
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <sfwn2287f7e.fsf@world.std.com>
······@2xtreme.net (Christopher R. Barry) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> [several hundred lines of great Lisp Machine info deleted]
>
> Well, maybe I'll look around for an old 3650 sometime....
I recommend a Macivory. Fits neatly out of sight and still gives you
access to the Mac, though not sure if compatible with newer Mac OS's.
(Fortunately, the Mac is such a trouble-free consumer item that using
an old OS on it isn't a big deal. The Lisp Machine isn't the only good
idea that's been trompled; thank goodness the IMacs are making headway.)
Or if you have an Alpha, I hear a new release for that is out just recently.
From: R. Matthew Emerson
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <7anoo6$kaf$1@news-2.news.gte.net>
Kent M Pitman <······@world.std.com> writes:
>
> I recommend a Macivory. Fits neatly out of sight and still gives you
> access to the Mac, though not sure if compatible with newer Mac OS's.
> (Fortunately, the Mac is such a trouble-free consumer item that using
> an old OS on it isn't a big deal. The Lisp Machine isn't the only good
> idea that's been trompled; thank goodness the IMacs are making headway.)
>
If only I could *find* a MacIvory. I would pay a moderate amount of
real money for a MacIvory III.
An art school I know has several mothballed 3600s (including a 3670,
which would definitely *not* fit in the back of my car, or even fit up
the stairs to my office at home). An acquaintance who teaches there
used to work for Acclaim, who used XL1200s. I had a momentary hope of
getting one of those, but they'd already sold them.
-matt
From: Simon Leinen
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <aaiucwgkcs.fsf@limmat.switch.ch>
Yes, the 3670 is huge. 3650s are quite big and *noisy*, too. I sure
wouldn't want one in my apartment! The 3620 has a smaller package and
makes less noise, but I think they were a bit wimpy in terms of CPU,
disk and memory.
My preference would be an NXP1000, which you can plug into an Ethernet
and access over X. Of course for those who are familiar with the Mac,
a MacIvory is probably nicer.
--
Simon Leinen ·····@babar.switch.ch
SWITCH http://www.switch.ch/misc/leinen/
Who is General Failure & why's he reading my disk?
From: Tim Bradshaw
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <nkjemni368m.fsf@tfeb.org>
Simon Leinen <·····@limmat.switch.ch> writes:
> Yes, the 3670 is huge. 3650s are quite big and *noisy*, too. I sure
> wouldn't want one in my apartment! The 3620 has a smaller package and
> makes less noise, but I think they were a bit wimpy in terms of CPU,
> disk and memory.
>
I don't know quite how much memory a 20 can take, but a 30 can take
enough (8MW, maybe more, I've not tried), and is really the same
machine as a 50 (which in turn is faster than a 70 or 40). The
difference is they can;t have the colour graphics, but you probably
don't want them.
--tim
From: Christopher R. Barry
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <87iucwmt4r.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > [several hundred lines of great Lisp Machine info deleted]
> >
> > Well, maybe I'll look around for an old 3650 sometime....
>
> I recommend a Macivory. Fits neatly out of sight and still gives you
> access to the Mac, though not sure if compatible with newer Mac OS's.
> (Fortunately, the Mac is such a trouble-free consumer item that using
> an old OS on it isn't a big deal. The Lisp Machine isn't the only good
> idea that's been trompled; thank goodness the IMacs are making headway.)
Well what does a Macivory + 68k Mac to drive it these days go for?
I've heard you can get working older 3650s for $350-$500 or so (and
that gets you one of these oh-so-special keyboards I'm always hearing
about).
From what I know, the 3600 and similar models can be obtained for only
a few hundred but cost many times that to ship and can't be lifted by
one person and consume that much money in electricity bills rather
quickly anyways and being so old they break down easily, while the
Ivory machines still demand from about $5000 on up to $20,000+ for the
works. The mid-range 3650 and one or two other 36xx variants are
supposed to be liftable by a single human, have reasonable power
requirements, and have a reasonable (to a guy that's riding his bike
to school cus' he doesn't feel like spending the cash right now to fix
his car up to the task) initial cost.
> Or if you have an Alpha, I hear a new release for that is out just recently.
For $5000 I understand. Kalman Reti also said that a 500 MHz 21164
Alpha is only 4 times faster than a 20MHz XL1200 at running
Genera. Geez.
Christopher
From: Tim Bradshaw
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <nkjg17y36e5.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> From what I know, the 3600 and similar models can be obtained for only
> a few hundred but cost many times that to ship and can't be lifted by
> one person and consume that much money in electricity bills rather
> quickly anyways and being so old they break down easily, while the
> Ivory machines still demand from about $5000 on up to $20,000+ for the
> works. The mid-range 3650 and one or two other 36xx variants are
> supposed to be liftable by a single human, have reasonable power
> requirements, and have a reasonable (to a guy that's riding his bike
> to school cus' he doesn't feel like spending the cash right now to fix
> his car up to the task) initial cost.
>
Small 36xx machines (3620/30) are pretty domestic. Screens tend to
wear out unfortunately and are hard to replace. The machines
themselves are OK, except fans & disks (disks may be hard to find).
They should be free really. MacIvories (non-last-generation ones)
should be free pretty much too, and if you have old VME Suns then you
can get UX400s for not much. *Finding* them is the problem. I was
lucky and found a 3670 in the basement & then a got a whole bunch of
smaller machines leading to a 3630 and a lot of spare cards.
The 3650 is *not* liftable by one human! 3620s and 30s are, just
about.
--tim
From: Espen Vestre
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <w64soe6c6o.fsf@wallace.nextel.no>
Kent M Pitman <······@world.std.com> writes:
> an old OS on it isn't a big deal. The Lisp Machine isn't the only good
> idea that's been trompled; thank goodness the IMacs are making headway.)
...but those with access to an imac should definitely try out MCL
(http://www.digitool.com) as well. It's almost unbelievably fast
on my G3/266 (same CPU as in the new imacs). MCL is much closer to
being a "lisp os" as other (non-lisp-os) lisps - Digitool definitely
deserves more customers! (if only the new and revitalized Apple
could discover that abandoning MCL and MCL-related activity was
_yet_ another error they made (and the next cube even once was bundled
with ACL - those were the days!)).
--
espen
From: Rob Warnock
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <7ap6oq$7ekqa@fido.engr.sgi.com>
Kent M Pitman <······@world.std.com> wrote:
+---------------
| ······@2xtreme.net (Christopher R. Barry) writes:
| > #\A instead of ?A...
|
| "?" is a bad choice of character becuase it frustrates Scheme programs
| who want to use "?" instead of "P" for the end of predicate names.
+---------------
Actually, IMHO that's not really a problem for Scheme people.
A more serious issue with "?A" would be that (at least, according
to several Lisp & Scheme texts I've read) a bunch of people tend
to use variables prefixed with "?" as "pattern match" variables,
e.g., similar to an example on p.161 of Norvig's PAIP:
> (setf foo '(joe is a big boy))
> (pat-match '(?x is a (?* ?y)) foo)
==> ((?x joe) (?y big boy))
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Lieven Marchand
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <7as6t2$m7g$1@xenon.inbe.net>
Kent M Pitman <······@world.std.com> writes:
> The document examiner had some nice ideas for the time, and is functional
> enough for what it tries to do. I wouldn't advocate it for modern use,
> but what's really compelling about it even now is how much better
> documented the Lisp Machine is than many modern operating systems.
> Sometimes when people point at the document examiner, they're really
> meaning the doc.
I don't understand your last sentence. What do you mean by the doc?
Anyways, I've only read about this tool in the preface of Keene's book
on CLOS, but I'm not sure modern tools allow everything she describes
CONCORDIA does. The closest would seem to be Framemaker, but it has
quite some way to go.
--
Lieven Marchand <···@bewoner.dma.be>
------------------------------------------------------------------------------
It was six months of C++ that made me determined to find something else to do
with my life. #:Eric Naggum
From: Kent M Pitman
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <sfwlnhqm73r.fsf@world.std.com>
Lieven Marchand <···@bewoner.dma.be> writes:
> > Sometimes when people point at the document examiner, they're really
> > meaning the doc.
>
> I don't understand your last sentence. What do you mean by the doc?
The documentation (writing) itself, not the vehicle for examining it.
From: Marco Antoniotti
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <lw7lt9w6ht.fsf@copernico.parades.rm.cnr.it>
Kent M Pitman <······@world.std.com> writes:
> Also, I don't see how GNU Emacs Lisp could ever become CL-like, since
> Stallman seems to control it and he doesn't seem to like CL. I and
> others fussed at him long ago when he diverged from CL. It seemed to me a
> conscious decision on his part to not care. (Maybe even a good decision,
> I'm not trying to moralize. i'm just saying that the decision to be more
> or less cl-like is a political one, and not a community one. And for all
> he talks about freedom for all, my impression is that he's very possessive
> and controlling about these free things he makes, such that you have a pretty
> severe obstacle to ever really changing it...)
I had the same feeling over and over. I never exchanged opinions with
RMS on the subject (not that I ever exchanged much email with him),
but the feeling stuck.
My suggestion is to always have
(require 'cl)
in your .emacs file. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Jon 'tex' Boone
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <m3n223iz1h.fsf@fulbert.isc-net.upenn.edu>
Kent M Pitman <······@world.std.com> writes:
> I'm just saying that the decision to be more or less cl-like is a
> political one, and not a community one.
Well, I agree with you that the decision to be more or less cl-like is
a political one. However, it is still a community decision.
Thanks to the GPL, no one, not even RMS, can dictate how Elisp
changes. All one needs to do is to fork the code base and create your
own version of emacs (ala XEmacs) and you can evolve your version of
Elisp all you want.
Of course, substantial effort is required to successfully establish an
alternative version that is going to continue to track the changes to
GNU Emacs, so this is less likely to occur unless the community
generally feels that the benefits to be gained from forking (a more
cl-like Elisp) are worth the effort required to sustain the fork.
Kent M Pitman <······@world.std.com> writes:
> And for all he talks about freedom for all, my impression is that
> he's very possessive and controlling about these free things he
> makes, such that you have a pretty severe obstacle to ever really
> changing it...)
He's the "architect", right? He is (naturally) very protective of his
designs and how they change over time. Thank goodness the code is
covered by the GPL - we can take the good ideas, integrating them into
our own version, while leaving the bad ones behind. And, without the
pain of having to reverse engineer it --- we get to look at the code.
:-)
--
--------------------------------------------------
Jon 'tex' Boone Senior Network Engineer
ISC Networking University of Pennsylvania
···@isc.upenn.edu (215) 898-2477
From: Johan Kullstam
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <m2678re1ok.fsf@sophia.axel.nom>
Jon 'tex' Boone <···@isc.upenn.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
> > I'm just saying that the decision to be more or less cl-like is a
> > political one, and not a community one.
>
> Well, I agree with you that the decision to be more or less cl-like is
> a political one. However, it is still a community decision.
>
> Thanks to the GPL, no one, not even RMS, can dictate how Elisp
> changes. All one needs to do is to fork the code base and create your
> own version of emacs (ala XEmacs) and you can evolve your version of
> Elisp all you want.
>
> Of course, substantial effort is required to successfully establish an
> alternative version that is going to continue to track the changes to
> GNU Emacs, so this is less likely to occur unless the community
> generally feels that the benefits to be gained from forking (a more
> cl-like Elisp) are worth the effort required to sustain the fork.
what would a CL emacs be? erik naggum has made the suggestition in
the past. i believe he has even started some work on it but has been
busy with other projects.
emacs is composed of two languages, a big chunk of C for implementing
the lower level functionality and a lot of emacs-lisp for gluing these
parts together.
in a CL emacs, i would guess that both the low level C stuff and the
higher level elisp part would both be done in common-lisp.
how do we borrow packages from (gnu-|x)emacs? do we create a CL
emacs-lisp to common-lisp translator? do we implement an emacs-lisp
interpreter in CL?
what do i want to keep? i like the programming modes and gnus.
perhaps the info reader can stay. others may find great utility in
devices such as ange-ftp. some are small and can be reimplemented.
some are fairly long and involved. it's a bit task.
what do we want to leave behind? perhaps mule should be dropped in
favor of a unicode solution.
just some (unoriginal) ideas.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Lieven Marchand
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <7b44b4$mec$1@nickel.uunet.be>
Jon 'tex' Boone <···@isc.upenn.edu> writes:
> Of course, substantial effort is required to successfully establish an
> alternative version that is going to continue to track the changes to
> GNU Emacs, so this is less likely to occur unless the community
> generally feels that the benefits to be gained from forking (a more
> cl-like Elisp) are worth the effort required to sustain the fork.
I think the deficiencies of elisp are more in its implementation than
in its definition. Sure, I'd like it to be more CL-like but give me
threads that my news or mail reader doesn't stop the world whilst
importing stuff and a better compiler and I'll take elisp as is. Since
writing a *good* CL compiler is a major undertaking, perhaps Hemlock
is a better base than [X]Emacs?
--
Lieven Marchand <···@bewoner.dma.be>
------------------------------------------------------------------------------
It was six months of C++ that made me determined to find something else to do
with my life. #:Eric Naggum
From: Christopher Browne
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <nY2B2.11335$yv3.6880@news2.giganews.com>
On 24 Feb 1999 10:47:38 -0500, Jon 'tex' Boone <···@isc.upenn.edu> wrote:
>Kent M Pitman <······@world.std.com> writes:
>> I'm just saying that the decision to be more or less cl-like is a
>> political one, and not a community one.
>
> Well, I agree with you that the decision to be more or less cl-like is
> a political one. However, it is still a community decision.
>
> Thanks to the GPL, no one, not even RMS, can dictate how Elisp
> changes. All one needs to do is to fork the code base and create your
> own version of emacs (ala XEmacs) and you can evolve your version of
> Elisp all you want.
>
> Of course, substantial effort is required to successfully establish an
> alternative version that is going to continue to track the changes to
> GNU Emacs, so this is less likely to occur unless the community
> generally feels that the benefits to be gained from forking (a more
> cl-like Elisp) are worth the effort required to sustain the fork.
And if GNU Emacs does something of a migration towards using a
Scheme-like language, whilst XEmacs converges more towrads CL, then this
has the benefit that we get to see a reduction of "duplication of
effort," as they'll both be doing things that are interestingly
different.
--
"What's wrong with 3rd party tools? Especially if they are free? What
the **** do you think UNIX is anyway? It's a big honkin' party of 3rd
party free tools." -- Bob Cassidy (········@uci.edu)
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Tim Bradshaw
Subject: Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Date:
Message-ID: <nkjbtiohjem.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> And Emacs ain't too shabby either. I've had my fill of Genera
> screenshots courtesy of Rainier and none of this "dynamic window" and
> likewise stuff seems to do anything that Emacs fundamentally can't. So
> you can click a URL in any app for a completion instead of just Emacs
> frames.
Emacs is shabby, really. When you see an object displayed in a window
in Genera you are looking at the actual object, not a bit of text that
someone has taught Emacs how to treat roughly equivalently,
sometimes. This is enormously more powerful than what Emacs can do,
because you can never be confused about what is being displayed.
Lots of other things have been overtaken by events -- the document
examiner never seemed that great to me (though there is a lot of
documentation compared to most systems). I think Sun's answerbook 2
stuff is as good as docex. But the basic thing of having this
intimate link between what was displayed and what was happening in the
underlying system is not something that emacs can do, not nearly.
--tim
From: Bruno Haible
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <7betab$rci$1@news.u-bordeaux.fr>
Sam Steingold <···@goems.com> writes:
>
> My exchange with RMS on the subject went along the following lines:
>
> me: when I do (require 'cl), I get THIS instead of THAT...
> rms: (require 'cl) cannot turn Emacs Lisp into Common Lisp
> me: I am very sorry about that!
> rms: I am certainly not!
>
> :-(
In a talk, four months ago, RMS mentioned plans to replace the Lisp engine
in GNU Emacs with another one. He ruled out Common Lisp as "too big" and
favoured Scheme. I told him about ISO ISLisp and that it is much smaller
than Common Lisp, yet has all the good properties. His answer was (more or
less) that he's already decided for Scheme.
Bruno http://clisp.cons.org/~haible/
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129317074195616@naggum.no>
* ······@clisp.cons.org (Bruno Haible)
| In a talk, four months ago, RMS mentioned plans to replace the Lisp
| engine in GNU Emacs with another one. He ruled out Common Lisp as "too
| big" and favoured Scheme. I told him about ISO ISLisp and that it is much
| smaller than Common Lisp, yet has all the good properties. His answer was
| (more or less) that he's already decided for Scheme.
the irony is that his Scheme (i.e., GUILE) is much larger than CLISP, and
is taking on the size of larger Common Lisp implementations very quickly,
especially in memory consumption. well, that's what you get for using a
small language.
#:Erik
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129402613403914@naggum.no>
* Sam Steingold <···@goems.com>
| With all due respect, this is not quite true, at least it needs a
| clarification.
|
| CLISP is ~800k lisp.run + ~1,000k lispinit.mem (with UNICODE; or ~800k
| 8bit) = 1,8M (or 1,6M) on my linux box. On the same platform, the guile
| executable is 4k and libguile.so is < 500k. I agree that any reasonable
| program will have to extend guile significantly, thus probably pushing
| its size above that of CLISP.
unfortunately, memory management and data matters quite a lot.
#:Erik
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129441516179845@naggum.no>
* Sam Steingold <···@goems.com>
| could you please be more specific?
fire up GUILE, CLISP, and any other Common Lisp implementations you have
at hand. run them for a while. do real stuff. watch how much system
memory the heaps consume. watch GUILE lose. fire up 100 copies of each
of them, and watch code space being insignificant compared to heap space.
the U in GUILE is for Ubiquitous. there's going to be _many_ copies of
the GUILE heap on a system, one in each process, just like the C library.
in contrast, you're unlikely to exhibit the same behavior with a Common
Lisp system, which users load stuff into instead of running a new process
with its own heap all the time.
the problem with retrofitting a Lisp or Scheme onto Unix is that Unix
really is a C programming environment, and using the C mindset when
building Lisp or Scheme applications or systems on top of it loses. the
same is true of any other programming language with an environment that
takes the role of Unix for C.
#:Erik
From: Tim Bradshaw
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <nkju2w2es79.fsf@tfeb.org>
Erik Naggum <····@naggum.no> writes:
> the U in GUILE is for Ubiquitous. there's going to be _many_ copies of
> the GUILE heap on a system, one in each process, just like the C library.
> in contrast, you're unlikely to exhibit the same behavior with a Common
> Lisp system, which users load stuff into instead of running a new process
> with its own heap all the time.
That doesn't have to be that bad. Obviously it depends on the
application, but shared heaps are fairly doable. Either using the
Emacs technique (purecopy + unexec) or just relying on
copy-on-first-write VM, which I think most Unices can do now. Whether
they'll do that is another matter of course.
Of course it's not the same as a single address space system, but it
has its advantages as well. I'm much happier reading my mail in a
completely different address space than my other Emacses live in for
instance, so nothing I do in them can clobber mail. A shared-space
system relies much more on really high-quality software, and even then
you can end up dying horribly, and just having to reboot.
--tim
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129458184729552@naggum.no>
* Tim Bradshaw <···@tfeb.org>
| That doesn't have to be that bad. Obviously it depends on the
| application, but shared heaps are fairly doable. Either using the Emacs
| technique (purecopy + unexec) or just relying on copy-on-first-write VM,
| which I think most Unices can do now. Whether they'll do that is another
| matter of course.
first: that isn't how GUILE is intended to be used. second: I'm talking
about actual memory consumed by the process for its _own_ data. data or
code that cannot be shared. state information, whatever you want to call
it. I haven't see anyone refer to this as anything other than "heap",
and I find it odd that you think such a heap should be sharable.
#:Erik
From: Tim Bradshaw
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <nkj678ibpik.fsf@tfeb.org>
Erik Naggum <····@naggum.no> writes:
> first: that isn't how GUILE is intended to be used. second: I'm talking
> about actual memory consumed by the process for its _own_ data. data or
> code that cannot be shared. state information, whatever you want to call
> it. I haven't see anyone refer to this as anything other than "heap",
> and I find it odd that you think such a heap should be sharable.
I think I was not clear enough. What I meant was that it's possible
to share some static parts of the heap, either by lazy copying (the
good way) or by the emacs trick. per-process data is obviously not
sharable. However, at least in theory that per-process data should
not be significantly more than the per-`application' data in a shared
address-space system. Of course, in pratice it usually seems to be,
for both good (finite page size means you end up copying a whole page
if you only touch one thing on it) and bad (general bloat I guess,
also no one ever actually seems to do the copy-on-write thing in
practice) reasons.
As to how Guile is meant to be used, I don't know about that. I was
just trying to argue that the Unix model doesn't have to be death in
theory even though it may be in practice.
--tim
>>>>> "tb" == Tim Bradshaw <···@tfeb.org> writes:
tb> What I meant was that it's possible to share some static parts
tb> of the heap, either by lazy copying (the good way) or by the
tb> emacs trick.
What implementations are able to do this? I assume that this implies
storing a part of the heap in text pages of the executable, which
seems incompatible with the was most Lisp systems are implemented (a
stub program loading an image file into memory). Scheme 48 has a
static heap linker to address this problem.
I would appreciate any pointers to documentation on this subject.
--
Nail [X] here for new monitor.
From: Fernando D. Mato Mira
Subject: Re: sharing heaps (was Re: Emacs and CL (was Re:...))
Date:
Message-ID: <36DFC5A4.30AA836F@iname.com>
This is a multi-part message in MIME format.
--------------32CBCEB8E77584443566F769
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruno Haible wrote:
> No implementation I know of does this currently, but Tim's idea seems to
> be actually implementable. CLISP's generational GC already makes use of
> the Unix copy-on-write technique. When you fire up CLISP, heap pages
> will be fetched from the heap image on disk in a lazy manner. And as long
> as they aren't being written to, they will be shared with other CLISP
> processes. Unfortunately, this only lasts until the first GC - which is
> likely to modify a whole lot of heap pages.
This reminds me ILOG Talk was not really usable together with IRIS
Performer,whose databases normally need many MB of shared arenas created at
startup
(default is 256MB). Launching such a program would take ages because
the Talk GC would first scan that whole yet unused thing.
--------------32CBCEB8E77584443566F769
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------32CBCEB8E77584443566F769--
Eric Marsden (········@mail.dotcom.fr) wrote:
: >>>>> "tb" == Tim Bradshaw <···@tfeb.org> writes:
: tb> What I meant was that it's possible to share some static parts
: tb> of the heap, either by lazy copying (the good way) or by the
: tb> emacs trick.
: What implementations are able to do this?
Poplog (which includes a CL implementation) does this.
: I assume that this implies
: storing a part of the heap in text pages of the executable,
As far as I understand, Poplog does not work in this way, but the heap
images can be tree structured.
On OSes which support shared memory, the part of the heap which is in
common is shared.
I'm sure comp.lang.pop folks may add further details.
P.
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129467830883882@naggum.no>
* Tim Bradshaw <···@tfeb.org>
| What I meant was that it's possible to share some static parts of the
| heap, either by lazy copying (the good way) or by the emacs trick.
| per-process data is obviously not sharable.
then this needs to be _added_ to GUILE.
| However, at least in theory that per-process data should not be
| significantly more than the per-`application' data in a shared
| address-space system.
this theory does not apply to GUILE. GUILE consumes a _lot_ of memory.
| As to how Guile is meant to be used, I don't know about that. I was just
| trying to argue that the Unix model doesn't have to be death in theory
| even though it may be in practice.
I think it's death in theory, but doesn't have to be in practice, the
same way whole populations don't die out under dictatorships or under
oppressive taxation -- i.e., the population survives because people do
the _wrong_ thing according to its planners and designers.
it has been said that Microsoft's "operating systems" are nothing but a
boot loader with a GUI. the process model in Unix is likewise geared
towards a mode of operation that may cause it to be trivialized the same
way, in not too distant a future, if it has not already happened.
think about it, the programming environment model in Unix is an imitation
of the Lisp machine, and the way it is implemented is through processes
and inter-process communication instead of function calls. functions in
the Lisp heap are programs on disk in the Unix model. the optimizations
that made Unix able to survive this incredible inefficiency are bad for
Lisp, which would have done it a lot better had it been in control, but
GUILE doesn't do it any better. GUILE combines the worst of both worlds,
in an attempt to bring the best of one world to a world where it doesn't
really belong. on top of this, it's Scheme, and it's expensive to run,
there's so much wrong with it that nobody can use it without fixing some
part of it. so, it's going to be a winner, but a real Lisp world would
be so much better. however, a real Lisp world cannot win as long as
GUILE is the image people have of a Lisp environment, just like Lisp has
suffered tremendously from the Scheme people's insistence that Scheme as
taught to college students is what they should expect from Lisp.
I'm not sure what needs to be done about this dismal situation, however.
#:Erik
From: R. Matthew Emerson
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <7bkbef$t5f$1@news-1.news.gte.net>
Erik Naggum <····@naggum.no> writes:
>
> think about it, the programming environment model in Unix is an imitation
> of the Lisp machine, and the way it is implemented is through processes
> and inter-process communication instead of function calls. functions in
> the Lisp heap are programs on disk in the Unix model.
This reminds me of some things that I wonder about from time to time,
namely:
How does a lisp machine deal with multiple simultaneous users, and how
does it protect users' programs from interfering with one another?
Are there permissions associated with lisp objects? Packages? On
files in the file system?
Can one telnet in to a lisp machine, start up a lisp world and display
it on one's desktop machine?
It seems to me that Lisp is about being able to have control of and
access to everything, and is distinctly non-fascist. For example,
just a little while ago, Kent Pitman wrote about extending the OS on
his lispm to talk to his NT machine. So, thinking about a multi-user
lisp system with all sorts of permissions and restrictions causes
cognitive dissonance.
With a unix/plan9 process model, it is straightforward to deal with
multiple users. Or maybe I just think it's straightforward, since
I've had very little experience with anything else.
-matt
From: Mike McDonald
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <7bkd7q$7ud$1@spitting-spider.aracnet.com>
In article <············@news-1.news.gte.net>,
···@nightfly.apk.net (R. Matthew Emerson) writes:
> Erik Naggum <····@naggum.no> writes:
>>
>> think about it, the programming environment model in Unix is an imitation
>> of the Lisp machine, and the way it is implemented is through processes
>> and inter-process communication instead of function calls. functions in
>> the Lisp heap are programs on disk in the Unix model.
>
> This reminds me of some things that I wonder about from time to time,
> namely:
>
> How does a lisp machine deal with multiple simultaneous users, and how
> does it protect users' programs from interfering with one another?
> Are there permissions associated with lisp objects? Packages? On
> files in the file system?
On the LispM's of old, there was only one user logged in at a time.
> Can one telnet in to a lisp machine, start up a lisp world and display
> it on one's desktop machine?
You can on the Symbolics LispMs, although only one of you will be logged in.
> It seems to me that Lisp is about being able to have control of and
> access to everything, and is distinctly non-fascist. For example,
> just a little while ago, Kent Pitman wrote about extending the OS on
> his lispm to talk to his NT machine. So, thinking about a multi-user
> lisp system with all sorts of permissions and restrictions causes
> cognitive dissonance.
>
> With a unix/plan9 process model, it is straightforward to deal with
> multiple users. Or maybe I just think it's straightforward, since
> I've had very little experience with anything else.
>
> -matt
Part of the problem is this notion that one size fits all. That what you
want from a server machine is the same as what you want on a desktop. The
Lispm's philosophy was that there should be only one user of a "desktop"
machine, namely the person who's desk it was sitting on. You don't need all of
the multiuser protection stuff built in when there's only one user. As a
result, they were able to make a different set of trade-offs than the Unix
guys who's aim was to provide multiuser capabilities to expensive machines.
LispM were meant to be cheap enough that everyone could have their own.
My hunch is that the vast majority of Unix machines only have one real user
logged into them. So why pay for the protection you don't need nor necessarily
want? Unix suffers from the same attitude that Windows does, namely that there
can only be one OS and everything from supercomputers to toasters HAS to run
it. Do you really think it's necessary to check my permissions before you'll
let turn down the toaster?
Oh well, I'm ranting.
Mike McDonald
·······@mikemac.com
From: Sunil Mishra
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <efyu2w26oth.fsf@whizzy.cc.gatech.edu>
·······@mikemac.com (Mike McDonald) writes:
> My hunch is that the vast majority of Unix machines only have one real
> user logged into them. So why pay for the protection you don't need
> nor necessarily want? Unix suffers from the same attitude that
> Windows does, namely that there can only be one OS and everything
> from supercomputers to toasters HAS to run it. Do you really think
> it's necessary to check my permissions before you'll let turn down
> the toaster?
One physical user... Yes. But then there are many other things imagineable
with the multi-user capabilities. Running low priority jobs over a long
period of time without interfering with the person at the desktop... Not
accidentally trashing some important system files, because the admin is
another user (even though that other user may in fact turn out to be
you)...
I don't think UNIX really suffers from that problem, at least not to the
extent you suggest. It is possible to adjust various parameters, such as
buffer sizes, VM size, process switch granularity, etc. so that you can
adjust to a variety of environments. Of course, there are some things that
are simply not needed on a unix box meant for a single user. There are many
annoying side-effects that protection has, such as the need to copy data
from a user buffer to a network or print buffer before it can go out to the
appropriate device. I believe there are quite a few efforts underway that
get around some of these problems.
The advantage that Unix has had all along is that the one-size-fits-all
model allows for simplicity of implementation, and therefore spread of the
paradigm. Then they can take their own time slowly improving upon what they
have. This point is of course not new. We can put down worse-is-better as
much as we like, but IMHO we will lose unless we learn from it.
Sunil
From: Rob Warnock
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <7blmrv$ajam0@fido.engr.sgi.com>
Sunil Mishra <·······@whizzy.cc.gatech.edu> wrote:
+---------------
| [things] not needed on a unix box meant for a single user. There are many
| annoying side-effects that protection has, such as the need to copy data
| from a user buffer to a network or print buffer before it can go out to the
| appropriate device. I believe there are quite a few efforts underway that
| get around some of these problems.
+---------------
Indeed. On Unix-based platforms, we at SGI have been shipping TCP/IP stacks
and networking hardware that do "zero-copy" DMA since at least 1992 or so.
This allowed, for example, achieving (circa 1994) "wire-speed" TCP/IP over
HIPPI (well, ~94 MB/s) user-mode to user-mode, instead of the ~30 MB/s that
the machines of the day could do if they had to bcopy user buffers to/from
kernel mbufs.
Likewise, for several years we've been shipping the "XFS" filesystem
which (among other things) adds an "O_DIRECT" mode that allows disk
reads & writes to DMA directly into/out of user-mode buffers, allowing
a filesystem read/write speed of ~300 MB/s, sustained. [And not just in
toy test programs, but in production applications such as media-serving,
database, etc. See http://www.sgi.com/origin/teraback/ for a report
of backing up an online Oracle database with Legato "Networker" backup
software at a speed of 1 TB/hr, or >275 MB/s sustained.]
I say these things not to brag on SGI (*blush*), but to assert that
the "annoying side-effects [of] protection [in Unix]" have *not* proved,
in fact, to be a great deterrent to achieving superb I/O or networking
performance. Quite to the contrary, the things you have to do in a Unix
system to get high performance are very much the same as you'd have to
do under *any* other operating system on the same hardware (well, an O/S
that offers at least *some* form of virtual memory -- for it is VM, not
user/kernel protection per se, that causes much of the grief).
So if you added some sort of "multi-user" and/or "protection" to a LispM,
it wouldn't *necessarily* hurt your I/O performance (unless you botched
the job).
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
From: Tim Bradshaw
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <nkjzp5sgua3.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
> > Right. So now why would you need/want to create a new LispM with
> > protection? You still have the same inherent protection from using
> > Lisp instead of C as the LispMs of old had.
>
> As far as I can tell with Genera and its operation in a single
> address-space, it's as though it had no kernel, for everything was
> pulled into the "kernel". Daniel Finster mentioned that it's still all
> too easy to crash the system from any account when you please just by
> evaluating a small expression. Another person replied to me in email
> mentioning that they were better than Windows if you weren't careless
> but still quite possible to fubar.
>
That person was me, and yes they are easy to crash, or to get into a
state where you really need just to boot the machine. I was doing
some stuff a while ago which aimed to create `conduit' packages --
packages which were just like (say) CL but had (say) DEFCLASS done
differently. So I had all sorts of stuff which did package-type
things, and was not quite clever enough and at some point did
something really horrible to the CL package. At least I was able to
save my editor buffers. Similar (worse) things can happen if you muck
around with the GC parameters. Or really, if you just make any kind
of bad enough mistake. I don't mind restarting my Lisp world if I do
something like that, but I do *not* want to have to lose my n weeks of
editor state, or my mail state, or my production version of the system
or any of that stuff. Which is why I read my mail and do most of my
editing on Unix machines: that ruthless stability is really worth
something. If only it was combined with a better & more open
programming environment and a less simple-minded protection model than
`root is God'.
Does anyone remember the `just boot' article from far too long ago?
Perhaps I should dig it out and post it.
--tim
From: Lieven Marchand
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <7brdok$s8c$2@xenon.inbe.net>
Tim Bradshaw <···@tfeb.org> writes:
> Does anyone remember the `just boot' article from far too long ago?
> Perhaps I should dig it out and post it.
If you refer to a rather long description of the advantages of Suns over
LispM's being they boot really fast, it's reprinted in 'The Unix haters
handbook'.
--
Lieven Marchand <···@bewoner.dma.be>
------------------------------------------------------------------------------
It was six months of C++ that made me determined to find something else to do
with my life. #:Erik Naggum
From: Johan Kullstam
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <m2lnhbzdks.fsf@sophia.axel.nom>
·······@mikemac.com (Mike McDonald) writes:
> > So if you added some sort of "multi-user" and/or "protection" to a LispM,
> > it wouldn't *necessarily* hurt your I/O performance (unless you botched
> > the job).
>
> But why would I want a LispM that "protected" me? Why should I trust your
> buggy kernel anymore than I trust my own abilities? That's the core question
> when deciding whether you want multi-user and/or protection: do you trust the
> user of the machine? The LispMs said yes, Unix says no.
for the same reason you have a safety on a gun. you don't want any
sudden leg off blowings. sometimes you will want to fire and then
you can take the safety off and pay more attention to what you are
doing.
in keeping with the analogy, it ought to be mildly annoying to take
the safety off in order to let you be a bit more relaxed during normal
operation but easy enough not to be prevented from taking your foot
off should you really want to.
i mean you do use lisp, you could be running assembler. why use a
high level language in the first place?
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Christopher R. Barry
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <87emn6kl7l.fsf@2xtreme.net>
·······@mikemac.com (Mike McDonald) writes:
> LispM were meant to be cheap enough that everyone could have their
> own.
For only $100,000 to $150,000???
> My hunch is that the vast majority of Unix machines only have one
> real user logged into them. So why pay for the protection you don't
> need nor necessarily want?
Since Lisp programming doesn't expose you to memory addresses I guess
it's not as nessecary, but having to reboot Windows or MacOS or DOS
everytime you you accidentally dereference the wrong pointer can be a
real pain. If you want to do everything in C then the Unix protection
model is the only sane way. Unix's relative stability is strong
testament to this.
> Unix suffers from the same attitude that Windows does, namely that
> there can only be one OS and everything from supercomputers to
> toasters HAS to run it.
What does Windows run on other than Intel and a backwards NT Alpha
port? I think portability and scalability are very important and Lisp
need not make excuses here. I consider Lisp in one form or another as
a one-size-fits-all solution.
To counter the fact that you can't do gzip or JPEG and other things
fast in Lisp I think it would be nice to have some functions and types
that give you C's hardware control when you need it instead of FFIing
to C.
But then again, if such a feature were made available it would
probably be abused to death and not used in the spirit it was
originally intended so maybe that's not such a hot idea after
all. What did Symbolics do about gzip? Do they have low-level Lisp
functions for Genera that let you control memory when you want?
> Do you really think it's necessary to check my permissions before
> you'll let turn down the toaster?
You say that a vast majority of Unix machines only have one real user
logged in to them and I say that a vast majority of them are also on a
network, even if only via PPP sometimes to the internet. Unix is the
only OS that gets it right in this kind of environment.
On Windows 95 you can do whatever you want to other machines on the
network just by typing crap into the "run" dialogue box. How many
virus protection programs are there for sale for Windows, DOS and
MacOS? How many for Unix? Come on.
Putting up with the crap involved in properly administrating my Linux
box has been far less frustrating then the crap Windows gave
me. Especially in the case of Debian, which gives you hassle-free way
to worrylessly upgrade everything on your disk without any
"foo.bar.so.6 not found" errors and the like.
Christopher
From: Daniel Finster
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <36DEAF22.58FCD505@nanofab.utdallas.edu>
"Christopher R. Barry" wrote:
>
> ·······@mikemac.com (Mike McDonald) writes:
>
> > LispM were meant to be cheap enough that everyone could have their
> > own.
>
> For only $100,000 to $150,000???
More like $50,000 to $200,000. Nowadays anywhere from free to maybe
$10,000. This is cheap enough that -everyone- can have their own.
>
> > My hunch is that the vast majority of Unix machines only have one
> > real user logged into them. So why pay for the protection you don't
> > need nor necessarily want?
>
> Since Lisp programming doesn't expose you to memory addresses I guess
> it's not as nessecary, but having to reboot Windows or MacOS or DOS
> everytime you you accidentally dereference the wrong pointer can be a
> real pain. If you want to do everything in C then the Unix protection
> model is the only sane way. Unix's relative stability is strong
> testament to this.
Actually, on the Symbolics you can be exposed to memory addresses, and
can do all the hairy things with them that you can do with C (actually
more: what C-based system allows you to grab ahold of the main paging
table for the virtual memory system and mung it to your hearts content?
(easy way to crash a LispM instantly: (setq sys::*mmpt* nil))). Only
the system internals (so far as I know) actually use this stuff though.
Despite this, LispM's manage to be far more robust than any Unix
system. It's not any lack of grungy low-level bit-twiddling that gives
you this robustness, its the fact that most people know better than to
mess with it. Also, if you do mess with it and screw up, you'll almost
always end up in a debugger rather than just simply crashing (the *mmpt*
example above is a pathological case) -- if you are pointer-diddling and
pass something the wrong pointer, you typically don't blow away your
entire system or even your program; you just excersize the debugger a
little and continue on.
> But then again, if such a feature were made available it would
> probably be abused to death and not used in the spirit it was
> originally intended so maybe that's not such a hot idea after
> all. What did Symbolics do about gzip? Do they have low-level Lisp
> functions for Genera that let you control memory when you want?
As I said above, such a feature is readily accessible, and almost never
actually used.
From: Daniel Finster
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <36DEAA1D.81371E59@nanofab.utdallas.edu>
"R. Matthew Emerson" wrote:
>
> Erik Naggum <····@naggum.no> writes:
> >
> > think about it, the programming environment model in Unix is an imitation
> > of the Lisp machine, and the way it is implemented is through processes
> > and inter-process communication instead of function calls. functions in
> > the Lisp heap are programs on disk in the Unix model.
>
> This reminds me of some things that I wonder about from time to time,
> namely:
>
> How does a lisp machine deal with multiple simultaneous users, and how
> does it protect users' programs from interfering with one another?
It deals with multiple simultaneous users just fine, except that the
login paradigm is somewhat broken in that only one user can be "logged
in" at a time (if 4 people are using the machine at one time, all 4 of
them have the identity of the "logged in" user.)
It does not even try and protect one program from another.
> Are there permissions associated with lisp objects?
No
> Packages?
No
> files in the file system?
Not really. There is an ACL system, but its primarily only useful for
protecting
files for FTP access. If 4 people are all using a machine that is
logged in as "Zippy", then all 4 of them have access to all of Zippy's
files. Someone coming in over FTP, however, would have to prove that he
is Zippy. Also, if you have access to a Lisp listener, then of course
no amount of security can protect the files from you, because you can
always just completely bypass it since you have full control.
The LispM was really designed around the philosophy of being a
single-user-at-a-time machine.
>
> Can one telnet in to a lisp machine, start up a lisp world and display
> it on one's desktop machine?
Yes, quite easily, via X.
>
> It seems to me that Lisp is about being able to have control of and
> access to everything, and is distinctly non-fascist. For example,
> just a little while ago, Kent Pitman wrote about extending the OS on
> his lispm to talk to his NT machine. So, thinking about a multi-user
> lisp system with all sorts of permissions and restrictions causes
> cognitive dissonance.
Well, I think it'd be neat to have a LispM type system with multi-user
security. It's not really any harder to understand than 4 people each
running a Lisp process under a Unix system -- each user gets mostly full
control of his own process.
>
> With a unix/plan9 process model, it is straightforward to deal with
> multiple users. Or maybe I just think it's straightforward, since
> I've had very little experience with anything else.
Well, you can implement the same process model on a LispM. Of course,
having a secure multi-user shared-memory system is less straightforward,
but quite doable I think (check out Jonathon Rees' scheme-based paper "A
security kernel based on the Lambda Calculus" (I think that's the
title)).
From: Christopher Browne
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <A8HC2.220$YV6.753@news2.giganews.com>
On 1 Mar 1999 20:28:59 GMT, Bruno Haible <······@clisp.cons.org> wrote:
>Sam Steingold <···@goems.com> writes:
>>
>> My exchange with RMS on the subject went along the following lines:
>>
>> me: when I do (require 'cl), I get THIS instead of THAT...
>> rms: (require 'cl) cannot turn Emacs Lisp into Common Lisp
>> me: I am very sorry about that!
>> rms: I am certainly not!
>>
>> :-(
>
>In a talk, four months ago, RMS mentioned plans to replace the Lisp engine
>in GNU Emacs with another one. He ruled out Common Lisp as "too big" and
>favoured Scheme. I told him about ISO ISLisp and that it is much smaller
>than Common Lisp, yet has all the good properties. His answer was (more or
>less) that he's already decided for Scheme.
ISO ISLisp may be nice in some ways; it is not clear that anyone has yet
implemented it. (I won't be offended if someone supplies the URL to
an example...)
Scheme has the benefit over ISO Lisp that there are quite a number of
implementations out there, quite a lot of existing code, and
considerable public understanding of it.
Those are all properties that are of non-zero value.
--
"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Fernando D. Mato Mira
Subject: ISO ISLisp (was: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))))
Date:
Message-ID: <36DC22AD.622E365D@iname.com>
This is a multi-part message in MIME format.
--------------EE114DC30D73D62042E4A6DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Christopher Browne wrote:
> ISO ISLisp may be nice in some ways; it is not clear that anyone has yet
> implemented it. (I won't be offended if someone supplies the URL to
> an example...)
Well, there was the now defunct ILOG Tal (descendant of LeLisp), which was
something of an `extended ISO Lisp'.
It was a nice product. The automatic dependency tracking reminded me of Eiffel.
Quite cool after you got used to it.
There's currently something called OpenLisp but I have not checked it:
http://www.ilog.fr:8001/Eligis/index.html
[Don't be fooled by the URL. This is not an ILOG product.]
--------------EE114DC30D73D62042E4A6DB
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------EE114DC30D73D62042E4A6DB--
From: Marco Antoniotti
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <lwyalggs51.fsf@copernico.parades.rm.cnr.it>
········@news.hex.net (Christopher Browne) writes:
> On 1 Mar 1999 20:28:59 GMT, Bruno Haible <······@clisp.cons.org> wrote:
> >Sam Steingold <···@goems.com> writes:
> >>
> >> My exchange with RMS on the subject went along the following lines:
> >>
> >> me: when I do (require 'cl), I get THIS instead of THAT...
> >> rms: (require 'cl) cannot turn Emacs Lisp into Common Lisp
> >> me: I am very sorry about that!
> >> rms: I am certainly not!
> >>
> >> :-(
> >
> >In a talk, four months ago, RMS mentioned plans to replace the Lisp engine
> >in GNU Emacs with another one. He ruled out Common Lisp as "too big" and
> >favoured Scheme. I told him about ISO ISLisp and that it is much smaller
> >than Common Lisp, yet has all the good properties. His answer was (more or
> >less) that he's already decided for Scheme.
>
> ISO ISLisp may be nice in some ways; it is not clear that anyone has yet
> implemented it. (I won't be offended if someone supplies the URL to
> an example...)
>
> Scheme has the benefit over ISO Lisp that there are quite a number of
> implementations out there, quite a lot of existing code, and
> considerable public understanding of it.
I beg to differ. I do not believe that the number of Scheme
implementations is a good meter. While they all - more or less -
implement *some* RxRS (for x variable), they all differ in one way or
the other.
As per the 'a lot of code' out there, a lot of it is of the "let's
re-implement DEFSTRUCT" kind.
> Those are all properties that are of non-zero value.
They are, but CL is still better. The fact that RMS decided to go with
Scheme for Emacs is a relatively "bad thing", but IMHO a minor one in the
grand lisp of things. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Barry Margolin
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <QnXC2.11$Ey6.1476@burlma1-snr2>
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
>········@news.hex.net (Christopher Browne) writes:
>> Those are all properties that are of non-zero value.
>
>They are, but CL is still better. The fact that RMS decided to go with
>Scheme for Emacs is a relatively "bad thing", but IMHO a minor one in the
>grand lisp of things. :)
But the issue you're responding to isn't Scheme vs CL, it's Scheme
vs. ISLISP. RMS is clearly biased against CL. Given the constraint that
CL isn't an option, I would probably choose Scheme over ISLISP as well.
ISLISP essentially came out of nowhere, just to fill a political niche (a
number of members of the ISO Lisp technical committee didn't want to adopt
CL as the ISO standard, so they created a brand new dialect just so there
would be an alternative).
In general, the GNU project decided a couple of years ago that they wanted
to make Scheme the basis of their extension languages across the board, and
they developed the GUILE implementation to support this effort. Using it
for Emacs would be consistent with this plan.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Christopher R. Barry
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <87n21uld78.fsf@2xtreme.net>
Barry Margolin <······@bbnplanet.com> writes:
> In general, the GNU project decided a couple of years ago that they wanted
> to make Scheme the basis of their extension languages across the board, and
> they developed the GUILE implementation to support this effort. Using it
> for Emacs would be consistent with this plan.
Anyone remember the GNU manifesto?
<http://www.gnu.org/gnu/manifesto.html>
Stallman mentions:
"GNU will be able to run Unix programs, but will not be identical to
Unix ... [GNU will have] perhaps eventually a Lisp-based window system
through which several Lisp programs and ordinary Unix programs can
share a screen. Both C and Lisp will be available as system
programming languages."
IIRC, he wrote that in 1984.
Christopher
From: Erik Naggum
Subject: Re: Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))
Date:
Message-ID: <3129471031871814@naggum.no>
* ······@2xtreme.net (Christopher R. Barry)
| IIRC, he wrote that in 1984.
at the time, incidentally, Common Lisp was his favorite Lisp. GNU CL
(based on Kyoto Common Lisp, which I played with back in 1987) has turned
out to be a serious flop, so maybe he thinks Scheme will fare better in
the new language GUILE. I don't think it will. it has even less overall
design than usual for overgrown Scheme implementations, and people add
stuff to in the Unix and C spirit (each man his own conventions).
#:Erik
······@2xtreme.net (Christopher R. Barry) writes:
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
???? ANSI Common Lisp doesn't have any size for FIXNUMs. It only
mandates that FIXNUM be a supertype of (signed-byte 16). But FIXNUMs
can grow to any size the implementation can support, i.e. given that
most current 32bit implementations use 2 tag bits, I'd guess that
64bit implementations would offer FIXNUMs with 62bit range. OTOH
there might be better uses for some of the added bits, who knows.
But the most important point is, that the size of FIXNUMs in CL
matters only for points of speed, which is as it should be. In CL you
don't worry about integer bittyness, unless you really need to, which
is either for speed or data-layout reasons, where you get the tools
for doing what needs to be done. And this doesn't change one jota even
if your plattform evolves. You just get the benefits, without the
hassles.
The standard doesn't have to change in any way to accomodate 2^n
plattforms for n>16.
> > How many times has the Java "standard" already changed?)
>
> It's been updated twice, and the runtime environment and browsers all
> still have to run the 1.0 code and 1.1 code too.
Which is twice too often for a standard of a language that's only been
around for 4-5 years. But of course this is to be expected, which is
why you just don't use languages this young for real work. You don't
even start standardization efforts, with a language this young. This
is the really unprecended thing about Java that scares me! We never
ever had so large a rush to one language which as yet hasn't even
started to settle down, let alone matured to any sufficient point.
Even C++ only ever got that amount of hype and public attention after
6-10 years of it's first definition (C with classes dates to 1980, in
1984 it started to be called C++, and most of the core features were
there).
> Why can't Lisp become more popular? What's stopping it? Do you think
> that the reasons outlined in "The Rise of Worse Is Better" are the
> _real_ reasons?
If anything, things have gotten worse: Whereas prior generations
preferred Unix (which went 90% of the way) to Multics&Co. (which
tried to go 100%), in more recent times, people have gotten less
critical, accepting 80%, 70%, 60% and less, without even flinching.
They only got slightly upset, when Microsoft consistently tried to
only go 20% of the way, and mocking those who complained. But who
will we be rescued by? Java/Sun, who will be hailed for going 40% of
the way?
It seems to me that much of Java's "success" stems from the fact, that
current users/programmers prefer an application that gives you
internet access, draws pretty pictures, is slow as hell even on the
most modern machines, insecure and so buggy that it crashes
about every 5-10 minutes to a program that works reliably and
stand-alone on reasonable machines and is rock solid. Mostly because
the first application is "cool", and the other one isn't[1].
Of course CL will never be able to match Java in coolness, since
coolness and reliability are mutually exclusive in the real world,
where resources are limited, and will be distributed according to
priorities. Dito for Ada. Is this a bad thing? Not in my book.
As long as the value-system and priorities of the masses are so at
odds with my priorities, I don't want the languages and tools I choose
to go mainstream and get popular. We don't have to change CL to make
it popular[2], we have to change popular priorities and value-systems.
Then popularity will follow naturally.
Regs, Pierre.
Footnotes:
[1] Just look at WWW browsers to see a real world example of this.
[2] We may of course see the need to change and expand CL to meet
demands of its user community, w.r.t to certain features or
clarifications. There are enough things to think about, but
popularity is not the driving force here.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Kent M Pitman
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <sfwn22dk0ws.fsf@world.std.com>
Pierre Mai <····@acm.org> writes:
> ANSI Common Lisp doesn't have any size for FIXNUMs. It only
> mandates that FIXNUM be a supertype of (signed-byte 16).
And doesn't it also say that the fixnum type has to be big enough that
all array indices can be declared fixnum? That's actually a pretty
important constraint on it, almost as important as the bitcount.
It's late and I'm too lazy to go browsing to be sure, though.
> The standard doesn't have to change in any way to accomodate 2^n
> plattforms for n>16.
Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
architecture (Multics) back in the late 1970's. And I vaguely recall
there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
this biz of what are we going to do when we get to 64 bit
architectures is kinda funny...
From: Mike McDonald
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7af7mu$q9d$1@spitting-spider.aracnet.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
> architecture (Multics) back in the late 1970's. And I vaguely recall
> there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
> this biz of what are we going to do when we get to 64 bit
> architectures is kinda funny...
And conses were "interesting" too. They had three fields, CAR, CDR, and I
think CXR. CXR was used as a property list! (Addresses were 22bits so three of
them would fit in a 72bit word.)
Mike McDonald
·······@mikemac.com
From: Kent M Pitman
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <sfwaeycbohg.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
>
> > Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
> > architecture (Multics) back in the late 1970's. And I vaguely recall
> > there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
> > this biz of what are we going to do when we get to 64 bit
> > architectures is kinda funny...
>
> And conses were "interesting" too. They had three fields, CAR,
> CDR, and I think CXR. CXR was used as a property list! (Addresses
> were 22bits so three of them would fit in a 72bit word.)
Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
But I might be wrong. Anyway, none of this contradicts the main point.
People should start making permanent records, e.g., in web pages or
archival media of some form, documenting these parts of computer
history. Very little of what was done between 1960 and 1994 (birth of
the web) will survive if aggressive work is noe done to preserve it
now while there are people alive who remember. And so much of it was
on now-yellowing line printer paper... I'm working aggressively on the
Maclisp piece and making progress slowly. But I don't know to what
degree there's any historical record of the CDC Lisp. Of course, some
people have written books. But that's a lot of work and considerable
stuff gets lost that's interesting for lack of someone willing to do
the formal effort of a book. Not to mention the expense. Sigh.
From: Mike McDonald
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7afkac$14l$1@spitting-spider.aracnet.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> In article <···············@world.std.com>,
>> Kent M Pitman <······@world.std.com> writes:
>>
>> > Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
>> > architecture (Multics) back in the late 1970's. And I vaguely recall
>> > there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
>> > this biz of what are we going to do when we get to 64 bit
>> > architectures is kinda funny...
>>
>> And conses were "interesting" too. They had three fields, CAR,
>> CDR, and I think CXR. CXR was used as a property list! (Addresses
>> were 22bits so three of them would fit in a 72bit word.)
>
> Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
> If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
> for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
> But I might be wrong. Anyway, none of this contradicts the main point.
How about 60bit words with 18bit addresses. I remember the cons had 6bits
for the type code and there wasn't much memory.
Mike McDonald
·······@mikemac.com
From: Frank A. Adrian
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <jOXy2.3612$rs2.4530424@client.news.psi.net>
The Lisp for the CDC 6600 Series was done at UT Austin. The 6600 was a
60-bit machine (Seymour Cray was idiosyncratic, ya know) with 18-bit
addresses. Since three such addresses could fit in a single word, there
were three address field in a CONS - the CAR, the CDR, and the CSR. The
latter was used infrequently, as you may well imagine. Another odd thing
about this architecture was that it used a six-bit character. The system
software for some languages actually supported a mixed 6/12 bit char set
(which got real interesting). The Lisp stuff, though, was straight six
bits. The Lisp system had a built in assembler which made use of the
wonderfully wierd architecture.
faa - who used this system for his first exposure to Lisp and was thus
irrevocably warped
Kent M Pitman wrote in message ...
>·······@mikemac.com (Mike McDonald) writes:
>
>> In article <···············@world.std.com>,
>> Kent M Pitman <······@world.std.com> writes:
>>
>> > Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
>> > architecture (Multics) back in the late 1970's. And I vaguely recall
>> > there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
>> > this biz of what are we going to do when we get to 64 bit
>> > architectures is kinda funny...
>>
>> And conses were "interesting" too. They had three fields, CAR,
>> CDR, and I think CXR. CXR was used as a property list! (Addresses
>> were 22bits so three of them would fit in a 72bit word.)
>
>Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
>If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
>for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
>But I might be wrong. Anyway, none of this contradicts the main point.
>
>People should start making permanent records, e.g., in web pages or
>archival media of some form, documenting these parts of computer
>history. Very little of what was done between 1960 and 1994 (birth of
>the web) will survive if aggressive work is noe done to preserve it
>now while there are people alive who remember. And so much of it was
>on now-yellowing line printer paper... I'm working aggressively on the
>Maclisp piece and making progress slowly. But I don't know to what
>degree there's any historical record of the CDC Lisp. Of course, some
>people have written books. But that's a lot of work and considerable
>stuff gets lost that's interesting for lack of someone willing to do
>the formal effort of a book. Not to mention the expense. Sigh.
>
From: Bruce R Miller
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <7ahk95$h2o$1@news.nist.gov>
In article <······················@client.news.psi.net>,
"Frank A. Adrian" <············@firstdatabank.com> writes:
>The Lisp for the CDC 6600 Series was done at UT Austin. The 6600 was a
>60-bit machine (Seymour Cray was idiosyncratic, ya know) with 18-bit
>addresses. Since three such addresses could fit in a single word, there
>were three address field in a CONS - the CAR, the CDR, and the CSR. The
..
>faa - who used this system for his first exposure to Lisp and was thus
>irrevocably warped
Likewise!
A friend of mine's wife was (according to him) a Computing Genius.
Knowing my love of Lisp, he was teasing me with a report his wife had
written condemning Lisp. She had used the CDC lisp for her `study'.
While I was trying to explain that that really wasn't an ideal lisp
implementation to base the comparison on, he went on to explain
how she found lisp to be bad at data structures --- Say WHAT? ---
Yeah, it's real clumsy for doing doubly linked lists. (!?!?!?!?)
Some people just dont get it.
--
--
············@nist.gov
http://math.nist.gov/~BMiller/
From: Steve Gonedes
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2d839k7r9.fsf@KludgeUnix.com>
······@2xtreme.net (Christopher R. Barry) writes:
< You could write applets in CL and basically gain all the advantages
< and cross-platform functionality Java has. You can't do sockets or
< threads in CL without a hell of a lot of #+ and #- and have it work in
< any CL providing access to these features. And many are reluctant to
< ship source code.
<
< Christopher
Actually I just saw the neatest idea for handling the `#+' in the
scigraph program. It uses a reader macro called `#FEATURE-CASE'.
Really made things easier to read.
Also, in cl-http there is a wrapper layer for threads and I think
there is another one floating around on the net.
From: Tim Bradshaw
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <nkjaeydo77i.fsf@tfeb.org>
······@2xtreme.net (Christopher R. Barry) writes:
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
CL doesn't specify fixnum sizes (well it says they have to be bigger than
some small number of bits I think). RTFM before you flame.
--tim
From: Jon S Anthony
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <ufpv79c25o.fsf@synquiry.com>
"David B. Lamkins" <········@teleport.com> writes:
> > * True keyboard and mouse control (you can distinguish between a
> > keyboard down-press and release, so you can give your text fields
> > Emacs-like incremental searching and bindings or do sophisticated
> > word completions or any other cool thing you could think up. And of
> > course, completely standard and cross-platform.
>
> Of course, completely standard and cross-platform... Hmm, didn't Microsoft
> make an argument that it had to break from the Pure Java fold because Sun
> didn't want to support 3-button mice?
Another point here is that the behavior is (sadly, even depressingly)
quite platform dependent.
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Oh, yes. OTOH, the Java thread model is stunningly impoverished.
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms. But their portability claims are _vastly_ oversold.
In our experience, the stuff (JDK 1.2) actually runs better overall
(less bugs and better performance) on an NT.Intel box than on a
Solaris.Sparc box. Go figure.
> Every ounce of hype Java has received is still just hype. I have
> observed early adopters foundering and failing with Sun's
> not-quite-ready-for-primetime "free" products, and with not-free
I believe this is too strong. There are definitely some good things
about Java, especially wrt (more or less) platform independent GUI and
connectivity work. While it's true that due to various central flaws,
Java will never be more than a *yawn* in the space of programming
language design, in the nuts and bolts world it does have some
advantages over other players. I suppose Java is best characterized
by the following scenario: upon first looking at it the response is
something like, "Hey, this is pretty cool"; upon further examination
and use the response becomes something like, "Wow, this could have
been a _lot_ better..."
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
From: Steve Gonedes
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2hfsme0ex.fsf@KludgeUnix.com>
······@2xtreme.net (Christopher R. Barry) writes:
< ···@crl3.crl.com (Bradley Yearwood) writes:
<
< > Could someone please remind me of what exactly we gain by abandoning
< > Lisp and moving to Java?
<
< Well...
<
< * You can download a full, uncrippled Java implementation + IDE for
< any major platform absolutely free, and in the case of the JDK even
< get the source code. AFAIK you can only do this with the Unix
< platform for Common Lisp.
Really? You mean Java runs on every Java platform - Solaris and
windows. You do know that all software is portable right?
You can get the source code for Java on _Solaris_ if you sign an NDA,
I think you can do this for lisp as well.
From: Jon S Anthony
Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <ufww1iaynv.fsf@synquiry.com>
······@2xtreme.net (Christopher R. Barry) writes:
We use Java extensively here. We also use CL extensively here.
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
It's also bigger and _way_ slower.
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
Yes, but oddly enough "green threads" (single process style) are
stunningly slow. Native threads on Solaris also suck unless you get
the right patches to run the production version - and even then they
require mind numbing amounts of cpu power to do much. Of course this
_could_ be fixed, but then why bother?
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
Sort of. Anybody actually using this stuff in real world situations
knows that there is more hype here than reality. Yes, some of it
actually works and some of it is more convenient than using something
else in certain situations. But it isn't even remotely anything like
the panacea that it is made out to be - and it often just plain
doesn't work.
> language itself, I think it's better than C, C++, Eiffel, ADA,
That's Ada - a proper name. Like Eiffel...
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things
> considered).
How can you make such a claim? "Most situations" meaning..., what?
Toy oneoffs? Simple minded university class projects? Maybe. Maybe
not.
> It would be nice if Common Lisp could at least standardise some of
> the networking, threads and i/o functionality you get in Java, and
> if it had a standard, accessible and reasonably priced GUI toolkit.
Yes, it would be great if CL had a standard thread/tasking definition
- it's an important fundamental piece of functionality. Networking
stuff is really a shoulder shrug wrt "standardization" in the
language. Probably too specialized to even be appropriate.
But all of that is irrelevant in this context when you consider the
_fact_ that _nothing_ in Java is standardized! Not even the basic
constructs of the language let alone any of the libraries/APIs and
such. A _standard_ means something accepted by a _real_ standards
body - like ANSI or ISO. Sun is not a standards body and it can (and
often _does_) just change things out from under you - and then (adding
insult to injury) deprecate those changes in a future release.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
From: Steve Gonedes
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <m2k8xie0o1.fsf@KludgeUnix.com>
···@crl3.crl.com (Bradley Yearwood) writes:
<
< In article <···············@engc.bu.edu>, David Bakhash <·····@bu.edu> wrote:
< >Kelly Murray <···@IntelliMarket.Com> writes:
< >
< >> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
< >> Seems most people laughed at the name. Having Netscape/Sun use it
< >> perhaps makes it not so funny anymore?
< >> My language is now called NiCLOS(tm), the name is funny,
< >> but is the language?
< >
< >So what's Lisp-like and what's Java-like in your language? Does your
< >langage compile down to Java VM code? Do you have a uniform way to
< >use Java classes via CLOS? I can't see how this is even remotely
< >possible, considering that:
< >
< >1) Java has no multiple inheritance
< >2) Java's class definitions are lexical with respect to methods, if
< > you consider a class file as a lexical entity.
< >3) Java has no multimethods, and dispatch depends only on the class of
< > a single object.
<
< Could someone please remind me of what exactly we gain by abandoning
< Lisp and moving to Java?
<
< Here is all I am able to come up with:
<
< 1) Unprecedented momentum of hype
< 2) Infix notation to avoid frightening dogs and small children
< 2.5) Reduced wear on parentheses keys on keyboards
< 3) Some slightly challenging concepts like macros are made to vanish
< 4) Some slightly suspicious hand-waving claims that useful integrity
< checks can be performed on portable bytecode before running it
< 5) An opportunity for yet another generation of enthusiasts to reinvent
< compilers, operating systems, utilities, interactive development
< environments, and special purpose hardware for the nth time in ever slower
< and bulkier forms
< 6) An opportunity to slip some sizable loads of ignorance of prior art past
< snoozing patent examiners, and thus lay down potentially lucrative legal
< minefields
You forgot that you can run Java programs on every windows and Solaris
computer in the world!
From: Christopher R. Barry
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <87pv7af7mj.fsf@2xtreme.net>
Steve Gonedes <········@worldnet.att.net> writes:
> You forgot that you can run Java programs on every windows and Solaris
> computer in the world!
And almost every Unix computer (even Crays), and the MacOS, and NeXT,
and ...within 2 web browsers that run on OSs covering 99% of the OS
market share.
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> Steve Gonedes <········@worldnet.att.net> writes:
>
> > You forgot that you can run Java programs on every windows and Solaris
> > computer in the world!
>
> And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> and ...within 2 web browsers that run on OSs covering 99% of the OS
> market share.
Hmm, last time I wanted to install Solaris via a Java interface:
- HotJava crashed
- Netscape on a PC had a version conflict with the Applet
- Netscape on a Mac did not really wanted to accept
my click on an install button
Well, I switched to a terminal...
--
http://www.lavielle.com/~joswig
From: Duane Rettig
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <47lthx7fm.fsf@beta.franz.com>
······@2xtreme.net (Christopher R. Barry) writes:
> Steve Gonedes <········@worldnet.att.net> writes:
>
> > You forgot that you can run Java programs on every windows and Solaris
> > computer in the world!
>
> And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> and ...
The same can be said about CL; at least one CL implementation runs on
just about every Unix; usually there are two or three on each. At
least one CL (though not ours) runs on MacOS. Our lisp used to run
on both Crays and NeXT boxes, but we discontinued them for business
reasons. (And you forgot IBM 360/370; Amdahl had a Unix called UTS
and we ran on that ...)
> and ...within 2 web browsers that run on OSs covering 99% of the OS
> market share.
You can run a CL plugin on either Windows browser. As for the Unix
browsers, we have theorized that it may be possible to run a plugin
on a Unix Netscape without needing native os-threads, but we choose
to follow the path to get native os-threads out first, and then the
browser plug-in capability will be much easier. Perhaps the former
would be a good project for you; you have the tools you need: linux,
a free netscape, a free lisp, the ability to load it into a non-lisp
environment and call it as subroutines ...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Christopher R. Barry
Subject: Allegro plugin and lnkacl.dll Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <871zjop4su.fsf_-_@2xtreme.net>
Duane Rettig <·····@franz.com> writes:
> You can run a CL plugin on either Windows browser.
This got me interested enough to actually download Allegro CL 5.0 Lite
(I've been meaning to look at it for a while) and Netscape 4.5 for
Windows and reboot to the thing for the first time in 1999 (God knows
how many months it's really been). Allegro for Windows is really,
really different... the Common Graphics thing is a lot like the Garnet
interface builder (at least from the 45 seconds I played with it).
Anyways, there are four files I'm supposed to copy into the Netscape
plugins directory, including one called lnkacl.dll that is supposed to
be in #p"sys:". Netscape gives me an error dialogue when I try to run
the thing, but seems to indicate that the plugin is registered okay.
Was the lnkacl.dll accidentally not included in Lite? The docs
specific to Lite say that a prebuilt *.dxl for the plugin is provided
since Lite doesn't have the capability to generate it, and you guys
probably wouldn't provide this without intending that people with Lite
be able to run the plugin example.
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher
R. Barry) wrote:
> Steve Gonedes <········@worldnet.att.net> writes:
>
> > You forgot that you can run Java programs on every windows and Solaris
> > computer in the world!
>
> And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> and ...within 2 web browsers that run on OSs covering 99% of the OS
> market share.
Actually, Common Lisp also runs on nearly everything. I'm not sure
about Crays and NeXT (who uses NeXT any more?) but CL definitely
runs on Mac, Wintel, Linux, Suns, and even vxWorks. CLisp will run
on pretty much anything that has a C compiler.
E.
From: William Paul Vrotney
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <vrotneyF7Bv0s.Hnr@netcom.com>
In article <····················@milo.jpl.nasa.gov> ···@jpl.nasa.gov (Erann
Gat) writes:
>
> > Steve Gonedes <········@worldnet.att.net> writes:
> >
> > > You forgot that you can run Java programs on every windows and Solaris
> > > computer in the world!
> >
> > And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> > and ...within 2 web browsers that run on OSs covering 99% of the OS
> > market share.
>
> Actually, Common Lisp also runs on nearly everything. I'm not sure
> about Crays and NeXT (who uses NeXT any more?) but CL definitely
Yes. I have Allegro, GCL, Clisp running on my NeXT. Although I mostly use
my Linux box now, I miss the elegance of NeXT and sometimes wish Linux could
have a nice well developed alternative to X windows.
--
William P. Vrotney - ·······@netcom.com
From: Erik Naggum
Subject: Re: Sun thinks about switching Java to S-expression syntax: Lava
Date:
Message-ID: <3128302633245925@naggum.no>
* ···@jpl.nasa.gov (Erann Gat)
| I'm not sure about Crays and NeXT (who uses NeXT any more?) ...
when he first NeXT cube arrived at the U of Oslo, I found two interesting
things: (1) it had a _real_ dictionary on it, Merriam-Webster's Ninth
Collegiate, and (2) it had a _real_ Common Lisp on it, Allegro CL from
Franz Inc. unfortunately, it was locked up in a room and was not even
made accessible to the systems hackers, only academic employees and some
graduate students.
#:Erik
Erik Naggum <····@naggum.no> writes:
> * ···@jpl.nasa.gov (Erann Gat)
> | I'm not sure about Crays and NeXT (who uses NeXT any more?) ...
>
> when he first NeXT cube arrived at the U of Oslo, I found two interesting
> things: (1) it had a _real_ dictionary on it, Merriam-Webster's Ninth
> Collegiate, and (2) it had a _real_ Common Lisp on it, Allegro CL from
> Franz Inc. unfortunately, it was locked up in a room and was not even
> made accessible to the systems hackers, only academic employees and some
> graduate students.
Early NeXTs also came with Mathematica, which I thought was kind of
cool; especially its "interesting" approach to documentation. I'm
pretty sure that the first NeXT version of Mathematica (that came with
OS version 0.8) was documented by taking the Macintosh documentation
and doing a global search-and-replace of NeXT for Macintosh. I base
this conclusion on several oddities in the documentation:
1) It mentioned the NeXT Color Picker (at a time when all NeXTs were
4-level grayscale).
2) It described how to exchange graphics with (paraphrased) "other
NeXT applications, such as MacPaint and MacDraw".
3) It pluralized NeXT as NeXTes.
:-)
Carl Witty
······@newtonlabs.com
From: Howard R. Stearns
Subject: Java portability (and not about Lisp at all!)
Date:
Message-ID: <36CAD890.13BFE941@elwood.com>
Steve Gonedes wrote:
>
> You forgot that you can run Java programs on every windows and Solaris
> computer in the world!
Well that's the idea, and indeed, I do believe that a good byte code
format that can be compiled once and run anywhere is a good thing, and
if it existed, should be widely used. However:
1. That is a function of the Java Virtual Machine (JVM), and not a
feature of the Java programming LANGUAGE. Other languages could use the
JVM, too, if it worked right.
2. I don't believe that your statement is correct -- you can't reliably
run it anywhere. Anecdotaly, I read this week about some drug maker
that had a lot invested in some client-server apps. They used a Java
applet on the client side, and ALL THEIR CLIENT MACHINES WERE RUNNING
WINDOWS. Unfortunately, the Windows implementation of the JVM was
broken and the app didn't run. They had to have someone (Oracle?) build
them a special JVM for Windows.
Now instead of having an application that was written once and running
on all platforms, they have an application that was written more than
once and running only on one. And this BECAUSE OF, not despite, the
fact that they relied on the univerality of the JVM.
Now this is just one story, and I can't even recall the source
(Performance Computing???) Furthermore, I get a lot of free magazines
and they're worth every penny I pay. So take this all with a grain of
salt.
Nonetheless, I think the point is fair that the JVM is MARKETED as
universal, but in practice it is technically no closer than, say, CLISP
byte-code. You might believe that market forces are likely to make that
dream a reality sooner for JVM than for alternatives, but that's another
story, and it's not quite what you said.
Howard R. Stearns wrote in message <·················@elwood.com>...
>Steve Gonedes wrote:
>>
>> You forgot that you can run Java programs on every windows and
Solaris
>> computer in the world!
>...
>1. That is a function of the Java Virtual Machine (JVM), and not a
>feature of the Java programming LANGUAGE. Other languages could use
the
>JVM, too, if it worked right.
>...
Quite true. Here is a list of about 60 of them:
<http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html>
There are a dozen LISP dialects, including a *very* nice compiling
Scheme called Kawa (free - open source):
<http://www.cygnus.com/~bothner/kawa.html>
No CL though (yet).
The Java VM platform greatly enhances the value of having many
languages. The (evolving) cross platform capability, large library of
very useful stuff, secure networked deployment, and tremendously
enhanced interlanguage compatibility provide immense benefit right now.
By virtue of the fact that performance is directly a function of
resources devoted to development, as time and resources continue to be
devoted to the JVM, it will eventually outperform practically every
other language compilation/runtime solution.
jim
-------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
From: Erik Naggum
Subject: Re: Java portability (and not about Lisp at all!)
Date:
Message-ID: <3128341921012330@naggum.no>
* "Jim White" <···@pagesmiths.com>
| By virtue of the fact that performance is directly a function of
| resources devoted to development, as time and resources continue to be
| devoted to the JVM, it will eventually outperform practically every
| other language compilation/runtime solution.
to get this behavior from the business community, you would have to
encourage investors with a linear growth in features. once you go
logarithmic on investors, they find something else with exponential or
linear growth. Microsoft's pyramid game of trust in its future ability
to fix past mistakes will be killed just this way.
I'm frankly suspicious of the high interest in Java at the moment -- from
what I have read about the "AI summer", people's hopes and expectations
were so high that actual achievements were disappointing, and after that
followed the "AI winter" and reasonable, realistic people turned away
from AI out of a sense of having been fools to have believed the hype.
the still frosty reactions to Lisp stem from this period.
the treatment that AI got was bad enough, but I don't see any evidence
indicating that something of importance has been learned from it, and
this is a bit surprising considering the number of Lisp people in the
core Java community.
so I'm frankly not sure Java will sustain investor interest long enough
to overtake much anything since the principle attractor is currently a
disturbing (to me) growth in features with premature specifications,
which only _add_ to the distance between Java and mature languages. add
to this that fancier features require significantly more resources to
specify well because fewer people really know how they should work and
much fewer people will have the mental capacity to relate them to the
rest of the language if they are not well-designed.
Java effectively killed the investments in C++ that were also slated to
outperform every other language according the hype that has now been put
to shame. _perhaps_ Microsoft's Java killer "COOL" (geez, how nerdy can
you _get_?) will just be enough of an investment detractor that COOL will
be another Microcruft product and Java will struggle with buggy and fancy
features for a long time to come?
I hate it when political overtake technological reasons for success, but
Java may well have put itself in such a position by having its own
political motivation and in effect playing Microsoft's con game. those
who live by politics will die by politics.
#:Erik
From: David Combs
Subject: Re: Java portability (and not about Lisp at all!)
Date:
Message-ID: <dkcombsF7HKI3.2rp@netcom.com>
Am mostly lurking here, but the comment about all the
hype on java, or the ai summer then winter, makes me
consider sun.
Remember way back in the 80's when McNealy started shouting
how sun was going to take over the desktop market -- sun had
windows, m$ didn't. And intel was small and slow (their thips,
that is) (chips). (too tired to go fix it)
I wonder what would have happened has McNealy kept his mouth
shut. By opening it I would imagine he scared the bejesus
out of intel and m$ -- put them to hard work, and the rest is
history. :-(
David Combs
From: Kent M Pitman
Subject: Re: Java portability (and not about Lisp at all!)
Date:
Message-ID: <sfwr9rkickg.fsf@world.std.com>
·······@netcom.com (David Combs) writes:
> I wonder what would have happened has McNealy kept his mouth
> shut. By opening it I would imagine he scared the bejesus
> out of intel and m$ -- put them to hard work, and the rest is
> history. :-(
I see where you're getting. If only we stop evangelizing Lisp so
heavily, we won't scare the Java camp ... yeah, that's the ticket.
;-)
>>>>> "HRS" == Howard R Stearns <······@elwood.com> writes:
HRS> Other languages could use the JVM, too, if it worked right.
Last year, from about April to May, a group of us wrote a Tiger-to-JVM
compiler (in Java) for a Compilers course at Rose-Hulman. The course
was 10 weeks long, and it took us about 8 weeks to get a featureful
compiler. Tiger is Andrew Appel's ML knock-off used in his (very
good, IMHO) _Modern Compiler Implementation_ text book. The version
of Tiger we implemented included record types and top-level function
definitions, but not closures or nested functions (couldn't figure out
how to cleanly build environments, plus we ran out of time).
Our Tiger compiler generated JVM 1.1 bytecodes using the wonderful
JASMIN package (which itself, in part, uses Scheme).
--
"When I was a kid, I used to think that Dammit was God's last name, just like
Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
Rainer Joswig wrote in message ...
>http://www.performancecomputing.com/columns/java/9903.shtml
>
>;-)
Great. A Sun Java researcher who apparently likes LISP but doesn't know
about Kawa[1] (the Scheme for the JVM). Not only does it have
S-expressions but even compiles them to bytecodes including the
useful-seperate-from-scheme gnu.bytecode package so you can make classes
from whatever you want.
Now if they were only researching the JVM change that is really needed:
continuations.
If the JVM specification had been based on continuations instead of the
implementation-minded threads stuff they would not only have avoided
having to deprecate the whole damn thing as they have, but would have a
machine model that could/would be amenable to formal analysis (as it is
no one tries - they simply ignore the threading stuff).
jim
[1] <http://www.cygnus.com/~bothner/kawa.html>
-------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC