Simon Gadbois wrote:
>
> (A copy of this message has also been posted to the following newsgroups:
> comp.lang.lisp)
>
> > Since Apple looks like it is going down the tubes, maybe we need
> > to make the free Lisp implementations better, so that there is
> > a choice available.(I fully admit that I am not yet qualified to
> > do so)
>
> You are not reading the news... Apple is actually doing great recently!
>
(snip)
Well, they don't seem to support Dylan anymore, which is a huge
disappointment. They may be able to survive, but their market share
is tiny.
---Rant mode on---
(Please don't take this personally, I'm just trying
to get some debate going. And maybe a little action to...)
If we want to make Lisp popular, there must be powerful, cheap Lisp
environments (both Lisp programming tools and eventually a Lisp-based
operating system) available for cheap hardware (PC clones). Even if a
product is technically superior, a cheaper product that sort of does the
job will win out. Look at the Mac vs. Windoze 3.1, Genera and VMS vs.
Unix, VHS vs. Beta. The companies that marketed the better systems were
able to make more money in the short term by charging a premium for a
superior product, but the "worse-is-better" product won in the end. A
long-time hardware engineer where I work told me that TTL logic wasn't
that great, but Texas Instruments marketed it well, so soon digital
logic soon had to be TTL-compatible. The "invisible hand" of the free
market doesn't have a strong track record when it comes to this. It has
happened over and over again.
Unfortunatly, the the free software seems to be much stronger on
the C/Unix side of things. This is part of why many programmers are
only exposed to this stuff, instead of the much more powerful Lisp
systems. For example, I've known many intelligent programmers that
think that C++ is great. This occurs because they have never been
exposed to a decent implementation of object oriented programming. They
see that C++ lets them get rid of some of the disadvantages of C, and
they think that it therefore is a great thing. Programming with
Microsoft Foundation Classes is easier than calling all of those Win32
API routines, so Microsoft must know all there is to know about greating
powerful GUI systems. People think that Unix is great because it's
better than DOS, and it doesn't have Microsoft giving itself an unfair
advantage with hidden APIs. I don't think that most these people are
stupid, they just think that putting up with this crap is part of
creating software.
Quoting from my favorite computer book, The UNIX-HATERS Handbook:
"I liken starting one's computing career with Unix, say as an
undergraduate, to being born in East Africa. It is intolerably hot, your
body is covered with lice and flies, you are malnourished and you are
suffering from numerous curable diseases. But, as far as young East
Africans can tell, this is simply the natural condition and they live
withing it. By the time they find out differently, it is too late.
They already think the writing of shell scripts is a natural act."
--Ken Pier
I think that this can also be said of many languages around, like Perl.
Well, writing Perl is better than shell scripts, so it must be good.
It's just natural to have to put a $ in front of variables to tell the
interpreter "This is variable". It's what scripting languages need,
right?
The success of DOS and Linux indicates that a cheap solution can take
the world by storm. Imagine how well a free operating system could do
if it had a decent user interface, with something as advanced as file
versions. (Oh my gosh, have they done that before? That would be a
great idea!)
I am totally unqualified to do this technically, but I wish I was.
--
*********************************************
Semi-encrypted email address: m_b_p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_
n_e_t_
All non-solicited commercial email will be billed $1,000.
In article <·················@inav.net> "Martin B. Pomije"
<········@inav.net> writes:
>
> ---Rant mode on---
> (Please don't take this personally, I'm just trying
> to get some debate going. And maybe a little action to...)
>
> If we want to make Lisp popular, there must be powerful, cheap Lisp
> environments (both Lisp programming tools and eventually a Lisp-based
> operating system) available for cheap hardware (PC clones). Even if a
> product is technically superior, a cheaper product that sort of does the
> job will win out. Look at the Mac vs. Windoze 3.1, Genera and VMS vs.
> Unix, VHS vs. Beta. The companies that marketed the better systems were
> able to make more money in the short term by charging a premium for a
> superior product, but the "worse-is-better" product won in the end. A
> long-time hardware engineer where I work told me that TTL logic wasn't
> that great, but Texas Instruments marketed it well, so soon digital
> logic soon had to be TTL-compatible. The "invisible hand" of the free
> market doesn't have a strong track record when it comes to this. It has
> happened over and over again.
>
First, you are not alone in your frustrations. I would have added NeXT
versus Windoze to your list but that is my own personal frustration.
Second, don't worry about Lisp. While most of these idiot preferences are
product related, Lisp is more an idea than a product. And Lisp is a *good*
idea. And good ideas don't die easily. It is quite clear at this point
that 4GLs and modern programming languages and systems are struggling to
achieve the things that Lisp has had for some time now. It is also quite
clear at this point that there is an anti-Lisp faction. We don't know why
these people are so fearful of Lisp but it is clear that they are. Now,
they even want to take Lisp out of Emacs for some reason.
So I think Lisp has time on its side. Time to let a good idea re-emerge when
the world is ready for it. Time to let the Lisp haters fade away.
--
William P. Vrotney - ·······@netcom.com
William Paul Vrotney wrote:
>
> In article <·················@inav.net> "Martin B. Pomije"
> <········@inav.net> writes:
>
> >
> > ---Rant mode on---
> > (Please don't take this personally, I'm just trying
> > to get some debate going. And maybe a little action to...)
> >
> > If we want to make Lisp popular, there must be powerful, cheap Lisp
> > environments (both Lisp programming tools and eventually a Lisp-based
> > operating system) available for cheap hardware (PC clones). Even if a
> > product is technically superior, a cheaper product that sort of does the
> > job will win out. Look at the Mac vs. Windoze 3.1, Genera and VMS vs.
> > Unix, VHS vs. Beta. The companies that marketed the better systems were
> > able to make more money in the short term by charging a premium for a
> > superior product, but the "worse-is-better" product won in the end. A
> > long-time hardware engineer where I work told me that TTL logic wasn't
> > that great, but Texas Instruments marketed it well, so soon digital
> > logic soon had to be TTL-compatible. The "invisible hand" of the free
> > market doesn't have a strong track record when it comes to this. It has
> > happened over and over again.
> >
>
> First, you are not alone in your frustrations. I would have added NeXT
> versus Windoze to your list but that is my own personal frustration.
>
> Second, don't worry about Lisp. While most of these idiot preferences are
> product related, Lisp is more an idea than a product. And Lisp is a *good*
> idea. And good ideas don't die easily. It is quite clear at this point
> that 4GLs and modern programming languages and systems are struggling to
> achieve the things that Lisp has had for some time now. It is also quite
> clear at this point that there is an anti-Lisp faction. We don't know why
> these people are so fearful of Lisp but it is clear that they are. Now,
> they even want to take Lisp out of Emacs for some reason.
>
> So I think Lisp has time on its side. Time to let a good idea re-emerge when
> the world is ready for it. Time to let the Lisp haters fade away.
>
> --
>
> William P. Vrotney - ·······@netcom.com
I must repectfully disagree. I don't think Lisp has time on it's side.
I think that we need someone like Linus Torvalds who is willing to get
off his butt and write a free operating system instead of just
complaining
about what is available. I'm not a fan of Unix, but I think that you
have
to give him his due: He actually did something about the situation he
was in (having to use DOS/Windoze) instead of saying that someday
something
better will come along. In some markets, Linux is the only thing
keeping
NT from achievingtotal control.
What if Microsoft does achieve total control of software tools? They
could do this if Intel is the only company producing high-end processors
and hardware manufacturers are under NDA agreements to not give out
information about how to interface to their systems(ala I2O). Then
the only way Lisp could win is if Bill Gates could be convinced that
Basic isn't the greatest language ever. Good luck.
--
*********************************************
Semi-encrypted email address: m_b_p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_
n_e_t_
All non-solicited commercial email will be billed $1,000.
In article <·················@inav.net> "Martin B. Pomije"
<········@inav.net> writes:
> >
> > So I think Lisp has time on its side. Time to let a good idea re-emerge when
> > the world is ready for it. Time to let the Lisp haters fade away.
> >
> > --
> >
> > William P. Vrotney - ·······@netcom.com
>
> I must repectfully disagree. I don't think Lisp has time on it's side.
>
> I think that we need someone like Linus Torvalds who is willing to get
> off his butt and write a free operating system instead of just
> complaining
> about what is available. I'm not a fan of Unix, but I think that you
> have
> to give him his due: He actually did something about the situation he
> was in (having to use DOS/Windoze) instead of saying that someday
> something
> better will come along. In some markets, Linux is the only thing
> keeping
> NT from achievingtotal control.
>
> What if Microsoft does achieve total control of software tools? They
> could do this if Intel is the only company producing high-end processors
> and hardware manufacturers are under NDA agreements to not give out
> information about how to interface to their systems(ala I2O). Then
> the only way Lisp could win is if Bill Gates could be convinced that
> Basic isn't the greatest language ever. Good luck.
Basically I agree with you, even though you say you disagree. But here are
a few comments:
When I say that Lisp has time on its side I do not mean that those of us who
are pro-Lisp should wait around and be complacent. What I mean is that time
eventually erodes away the impediments to grand ideas. The grand theory of
Copernicus is an example.
I am afraid that if for some reason Lisp became real popular today Microsoft
would suck it up and turn it into something tasteless. By the way,
Microsoft will never gain complete control of software tools, they can't
even control the software tools they have. :-)
Here is a question to ponder: Will Lisp still be around after Microsoft is
gone?
Lets give some credit to classic free Lisp implementations such as Emacs and
KCL.
It would be nice if some energetic individual like Linus T would create the
Lisp based equivalent of Linux. But it is not going to happen soon for a
few reasons. Linus had an existing model, Unix, from which to proceed. No
such good model exists for a Lisp based OS. I am afraid that something like
Genera is far to complex and inelegant to be a candidate for the kind of
thing you hope for. On the other hand some systems like Scheme are far to
simplistic to be a basis for a viable operating system. Common Lisp comes
closer as a candidate but even then a whole myriad of hard issues becomes
quickly apparent to anyone attempting such a feat. For example, should the
secondary memory model be a standard file system with fixed attributes or a
file-less persistent object model with open-ended attributes. Lisp wants
things to be open-ended and automatic. Such a persistent object model
however is not clearly understood yet.
And even if someone like Linus could conquer the implied task here they
would probably be tempted to consider the the anti-Lisp faction and how it
might try to squash the fruits of their labor.
Many of us would like to take the time off and take a stab a such a Lisp OS
despite the obstacles. In fact some of us have. But that ugly green stuff
always becomes an issue. But don't stop wishing and suggesting, you've
certainly put a bug in my ear.
Finally, I wish the world would get over the idea of something "winning" to
be successful. Things that win have nothing left to do but lose.
--
William P. Vrotney - ·······@netcom.com
Moin, Moin!
William Paul Vrotney <·······@netcom.com> schreibt �ber `Re: MCL':
> Here is a question to ponder: Will Lisp still be around after Microsoft is
> gone?
I'd say Yes. Unlike most other languages it is not one of those
sophisticated macro assemblers (C, Pascal and the like) but based on
mathematical ideas. "Recursive Functions of Symbolic Expressions and Their
Computation by Machine, Part I" [1] That was the title of McCarty's paper
which introduced the idea of LISP. Though nearly fourty years old it still
applies to our needs. More than ever we long for non-numeric computational
power. Why are products like Mathematica or Maple so popular? Certainly not
because of their colourful function plots.
The concepts of LISP define the language and not vice versa. Besides
recursive functions and conditional expressions for an elegant flow control
it offers the manipulation of symbolic data. Furthermore the meaning of
"data" and "program" is interchangable -- you can add data to your system
at runtime and later execute it as if it had been there from the beginning
on. A LISP program is even able to create new functions on its own and is
thus able to "grow".
You can not easily find better concepts that void those of LISP. However,
I wouldn't say that any language based on these ideas will exactly be LISP
(I'd prefer a LISP with less parenthesis :-). We might end up with something
different when Micro$oft has left, but it will contain the spirit of LISP.
ALGOL 60 has died long ago but still lives inside Pascal (or whatever
Pascal's name is today) and is popular that way.
> It would be nice if some energetic individual like Linus T would create the
> Lisp based equivalent of Linux. But it is not going to happen soon for a
> few reasons. Linus had an existing model, Unix, from which to proceed. No
> such good model exists for a Lisp based OS.
This reminds me of the time when every home computer's user interface (and
scipting language) was its BASIC interpreter. Why shouldn't this work any
more? You need some kind of bootstrap code to kick the existing OS off your
computer, a kernel that offers a LISPy interface for the system specific
functions and a slightly modified version of an existing LISP system that
no longer has to deal with the hardware itself but uses the kernel. Oh yes,
you need a lot of spare time to do the job. :-)
(The last paragraph just sounds like a description of UNIX to me. ;-)
Has anyone ever tried to use Emacs as his login shell on a Unix system?
[1] Part II of which never had been published.
Gru�
Wolfgang
--
(_(__)_) Privat: ···@geodesy.inka.de //
~oo~ Uni: ·······@ipf.bau-verm.uni-karlsruhe.de \X/
(..)
"Wolfgang von Hansen" <···@geodesy.inka.de> writes:
> Has anyone ever tried to use Emacs as his login shell on a Unix system?
no, but I have met people whose X startup script simply opens one
big emacs window :-)
--
Espen
Martin B. Pomije wheezed these wise words:
> I must repectfully disagree. I don't think Lisp has time on it's side.
Hmm. I think that Lisp _does_ have time on it's side, but I'm an
impatient fellow. ;)
> I think that we need someone like Linus Torvalds who is willing to get
> off his butt and write a free operating system instead of just
> complaining
> about what is available. I'm not a fan of Unix, but I think that you
> have
> to give him his due: He actually did something about the situation he
> was in (having to use DOS/Windoze) instead of saying that someday
> something
> better will come along.
Agreed. However, he couldn't have made Linux what it is today without
help from a _lot_ of other people. If one person were willing to do
something similar for Lisp, I'd hope that enough people would join the
project and contribute to it. In fact, this has already happened, with
Emacs, and its happening again with Guile.
> In some markets, Linux is the only thing
> keeping
> NT from achievingtotal control.
Dare I mention Sun? ;) Plus a few other names, like Apple, IBM, SCO.
Let's not take the Linux hype at face value. Linux is wonderful, but
it ain't gonna worry MS - yet. MS are after the corporate market. When
they've got that all to themselves, Linux won't matter to them.
See the "DEC RIP" thread in comp.arch. Esp the recent bit about Linux
and MS. If Linux were a threat to MS, they'd apply the EEE tactic,
Embrace, Extend, Eliminate. They've not yet done this.
MS once sold Unix clone called Xenix. For a while, they even sold
MuLisp. We can speculate about why they dumped them both. (Hint: Gates
is a Basic fan, and many vendors like the "not invented here" game.)
> What if Microsoft does achieve total control of software tools? They
> could do this if Intel is the only company producing high-end processors
> and hardware manufacturers are under NDA agreements to not give out
> information about how to interface to their systems(ala I2O). Then
> the only way Lisp could win is if Bill Gates could be convinced that
> Basic isn't the greatest language ever. Good luck.
Again, see the "DEC RIP" thread in comp.arch.
My hope is that Y2K bugs will wake the world up in a few years, and
bean counters will realise that software is much more critical than
they thought. I expect such a lesson to be very painful, but also
unforgettable. Right now it is too easy to ignore software problems.
That is, not nearly expensive enough to make a difference.
The only reason that _we_ appreciate the significance of software is
that software is our domain. Most people worry about other stuff. When
we tell them they've got their priorities wrong, we need hard facts to
back us up.
So I hope that some Y2K bugs will wipe out some multinational
companies, not so I can enjoy their misfortune, but so that the
message will finally get thru to the bean counters. A few household
names going down the toilet should do it. Like McDonalds.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·················@inav.net>,
Martin B. Pomije <········@inav.net> wrote:
>What if Microsoft does achieve total control of software tools? They
>could do this if Intel is the only company producing high-end processors
>and hardware manufacturers are under NDA agreements to not give out
>information about how to interface to their systems(ala I2O). Then
>the only way Lisp could win is if Bill Gates could be convinced that
>Basic isn't the greatest language ever. Good luck.
Microsoft can no more achieve "total control of software tools" than Chase
Manhattan bank can achieve "total control of money" or the Roman Catholic
church "total control of religion." Furthermore, Bill Gates has no
particular interest in surpressing Lisp. If Lisp becomes popular, he will
support it, as he does C++ and Java (neither of which was popularized within
Microsoft).
Paul Prescod
* Paul Prescod wrote:
> Microsoft can no more achieve "total control of software tools" than Chase
> Manhattan bank can achieve "total control of money" or the Roman Catholic
> church "total control of religion." Furthermore, Bill Gates has no
> particular interest in surpressing Lisp. If Lisp becomes popular, he will
> support it, as he does C++ and Java (neither of which was popularized within
> Microsoft).
So long as Microsoft can add enough value to it so that it's very easy
& tempting to write programs which will run only on MS platforms.
Microsoft don't have an interest in suppressing Lisp, but they *do*
have an interest in suppressing standardised programming systems which
allow you to write portable programs. (look at the Java stuff for
instance).
--tim
Something to reassure us lispers-
If you ever look at old programming books, or study the history of
programming languages, you will see a vast myriad wasteland of
countless score languages coming and going. There is a continual birth
of new languages and death of the old. But one language will stand
out, markedly the same (though evolved) from the original of the
1950's - LISP. There is no other language that approaches it's breath
(from editors to OS's to AI) and persistence (great similarity with
original). Don't worry about LISP going away - it is the one
programming language that never has.
That having been said, I agree with your stance, and I too would like
to be running a LISP OS (in some ways I do - I rarely leave
emacs!). My main concern is that computer science has not advanced to
the point where an efficient LISP OS is implementable. CS is a nascent
field with many unanswered questions. Then again, perhaps the time
has come to answer them.
John Arley Burns wrote:
> That having been said, I agree with your stance, and I too would like
> to be running a LISP OS (in some ways I do - I rarely leave
> emacs!). My main concern is that computer science has not advanced to
> the point where an efficient LISP OS is implementable.
A possible approach would be to piggyback a Lisp OS
onto a conventional OS implemented with a microkernel. Properly
designed, the Lisp OS and the conventional OS could run at
the same time. This could make Lisp more efficient, by
exposing more OS details (better interaction with the virtual
memory system, say). And it would let you run Unix apps
as you migrate more function into Lisp.
You'd want an efficient second generation microkernel
for this. Maybe QNX or L4 (the latter has had Linux ported on
top of it, with good results.)
Paul
Moin, Moin!
Juergen Nickelsen <··········@acm.org> schreibt �ber `Re: MCL':
> While I share your sentiments about Lisp, I think FORTRAN and COBOL
> deserve equal credit for persistence. While I don't know what to expect
> from COBOL in the future, FORTRAN will probably stay the preferred
> languague for scientific computing at least for the next decade.
I am not so sure about that. When I began to study surveying engineering a
few years ago, they did everything happily in FORTRAN 77 and were looking
forward to the advent of a Fortran 90 compiler. Now they have dropped
FORTRAN completely in favor of C (and believe me, the step certainly was
not easy because they had _very_ good software written in FORTRAN).
Gru�
Wolfgang
--
(_(__)_) Privat: ···@geodesy.inka.de //
~oo~ Uni: ·······@ipf.bau-verm.uni-karlsruhe.de \X/
(..)
In article <········@geodesy.inka.de>,
Wolfgang von Hansen <···@geodesy.inka.de> wrote:
>Juergen Nickelsen <··········@acm.org> schreibt �ber `Re: MCL':
>> While I share your sentiments about Lisp, I think FORTRAN and COBOL
>> deserve equal credit for persistence. While I don't know what to expect
>> from COBOL in the future, FORTRAN will probably stay the preferred
>> languague for scientific computing at least for the next decade.
>
>I am not so sure about that. When I began to study surveying engineering a
>few years ago, they did everything happily in FORTRAN 77 and were looking
>forward to the advent of a Fortran 90 compiler. Now they have dropped
>FORTRAN completely in favor of C (and believe me, the step certainly was
>not easy because they had _very_ good software written in FORTRAN).
This is truly sad, an example of the "worse is better" principle in
action.
Fortran, for all its idiosyncracies, was an excellent language for its
intended purpose: representing mathematical calculations. For a very
long time it was the only truly standardized computer language for
scientific work. I can remember using portable macro assembler programs
written in Fortran back in the early '80s.
C, in contrast, isn't even standardized enough to be portable between
differing implementations on the same hardware architecture.
If even surveying engineering has switched to C, what does that say
about the future of Lisp and similar languages?
-- Chuck, still paid to use Common Lisp, but for how long?...
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
From: Wolfgang von Hansen
Subject: Re: (not really about) MCL
Date:
Message-ID: <97864786@geodesy.inka.de>
Moin, Moin!
Chuck Fry <······@shell5.ba.best.com> schreibt �ber `Re: (not really about)
MCL':
>
> Fortran, for all its idiosyncracies, was an excellent language for its
> intended purpose: representing mathematical calculations.
But a good programming language needs more than just an excellent
representation of mathematical calculations. To me, learning FORTRAN was
an awful experience. Everything looked very much like BASIC (implicit
data typing, fixed array sizes, very limited support of function calls
with arrays as arguments) with added idiosy^H^H^H^H^H^Hdisadvantages.
One of my early programs crashed on startup because I named it (using
that PROGRAM(?) directive) similar to one of its functions. The compiler
didn't report that violation of the rules...
> C, in contrast, isn't even standardized enough to be portable between
> differing implementations on the same hardware architecture.
It is standardized (ANSI-C), but implementations tend to add their own
functions which aren't. Or some implementations warn about implicit type
conversions which others don't mind.
> If even surveying engineering has switched to C, what does that say
> about the future of Lisp and similar languages?
Nothing. You should start to worry when the AI people drop Lisp (and see
what they're converting to).
> -- Chuck, still paid to use Common Lisp, but for how long?...
Gru�
Wolfgang, just beginning with Lisp by programming his own interpreter.
--
(_(__)_) Privat: ···@geodesy.inka.de //
~oo~ Uni: ·······@ipf.bau-verm.uni-karlsruhe.de \X/
(..)
In article <········@geodesy.inka.de>,
Wolfgang von Hansen <···@geodesy.inka.de> wrote:
>Chuck Fry <······@shell5.ba.best.com> schreibt �ber `Re: (not really about)
>MCL':
>> Fortran, for all its idiosyncracies, was an excellent language for its
>> intended purpose: representing mathematical calculations.
>
>But a good programming language needs more than just an excellent
>representation of mathematical calculations. To me, learning FORTRAN was
>an awful experience. Everything looked very much like BASIC (implicit
>data typing, fixed array sizes, very limited support of function calls
>with arrays as arguments) with added idiosy^H^H^H^H^H^Hdisadvantages.
There's a good reason for the similarity: BASIC was patterned after
FORTRAN!
>> C, in contrast, isn't even standardized enough to be portable between
>> differing implementations on the same hardware architecture.
>
>It is standardized (ANSI-C), but implementations tend to add their own
>functions which aren't. Or some implementations warn about implicit type
>conversions which others don't mind.
One key aspect that is not standardized is the exact size of int and
related types. Then there's byte ordering issues, etc., etc.
>> If even surveying engineering has switched to C, what does that say
>> about the future of Lisp and similar languages?
>
>Nothing. You should start to worry when the AI people drop Lisp (and see
>what they're converting to).
I *am* an AI person, and because our applications are on spacecraft,
we're seeing a lot of pressure to switch to C and C++.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
In article <············@shell5.ba.best.com>, ······@shell5.ba.best.com
(Chuck Fry) wrote:
> I *am* an AI person, and because our applications are on spacecraft,
> we're seeing a lot of pressure to switch to C and C++.
Aren't there other Lisp systems on spacecrafts? How about
the DS1 mission?
--
http://www.lavielle.com/~joswig/
In article <·······················@194.163.195.66>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <············@shell5.ba.best.com>, ······@shell5.ba.best.com
>(Chuck Fry) wrote:
>> I *am* an AI person, and because our applications are on spacecraft,
>> we're seeing a lot of pressure to switch to C and C++.
>
>Aren't there other Lisp systems on spacecrafts? How about
>the DS1 mission?
That's my current project: the Remote Agent Experiment (RAX) for the New
Millenium program's Deep Space One mission, an asteroid/Mars/comet
flyby, and technology validation mission. Autonomous operation is one
of the technologies being validated. I'm a staff programmer for a
contractor on the planner/scheduler and smart executive teams at NASA
Ames Research Center. NASA Ames is collaborating with the Jet
Propulsion Laboratory on the autonomy software. See
<http://www.jpl.nasa.gov/ds1/> for an overview of the mission; see
<http://ic-www.arc.nasa.gov/ic/projects/Autonomous-Systems.html>
for some of my group's work.
And yes, we're flying Common Lisp for a one-week autonomy experiment.
Ironically the planner/scheduler portion was halfway ported to C++
before the flight S/W management team pulled the plug on C++ due to
political and S/W tools issues. Personally I was dismayed at the lack
of maturity of our C++ tools, and the inconsistencies between various
C++ implementations. (Sorry, I'm not naming names.)
But getting Lisp onboard has been one hell of a struggle politically,
and was possible at all only because our team had strong allies in NASA
upper management. About half the autonomy team feels that follow-on
projects would have a greater chance of success if coded in C or maybe
C++ (assuming the previous technical issues are resolved). Some
adventurous folks are even suggesting Java for flight. IMHO Java makes
C++ look mature!
In addition to the usual misperceptions about Lisp, commercial CL
implementations are still perceived as carrying too much dead weight for
spacecraft use, and rightfully so IMHO. Unlike the PC/workstation
world, space-qualified megabytes and megahertz are NOT cheap. The
radiation would stun most commercial grade processors and reduce memory
to gibberish. Available rad-hardened processors lag their commercial
cousins by an order of magnitude in speed. And there is a huge
incentive for keeping spacecraft mass to a minimum. "Dead weight" in
memory translates to literal dead weight in flight!
A commercial CL compiler that fit the usual compile/link/load paradigm
and/or produced small executables would make CL a MUCH more viable
choice for spaceflight. You don't need compilers in space, and only a
lightweight debugger/interpreter is required for changes "on the fly".
Alternate approaches like byte-code interpreters may also be viable, if
the performance is adequate. Note that these comments apply equally
to compact embedded software applications on Earth.
A colleague at another NASA center is working on a CL implementation
specifically for spaceflight applications. I'll let him speak for
himself if he wishes.
In case it is not abundantly clear, I speak only for myself, and not for
NASA, Ames Research Center, or my employer Caelum Research Corporation.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
From: Charles Martin
Subject: Re: Lisp in space was: (not really about) MCL
Date:
Message-ID: <3502F5D9.C10C8382@connix.com>
Chuck Fry wrote:
>
> In article <·······················@194.163.195.66>,
> Rainer Joswig <······@lavielle.com> wrote:
> >In article <············@shell5.ba.best.com>, ······@shell5.ba.best.com
> >(Chuck Fry) wrote:
> >> I *am* an AI person, and because our applications are on spacecraft,
> >> we're seeing a lot of pressure to switch to C and C++.
> >
> >Aren't there other Lisp systems on spacecrafts? How about
> >the DS1 mission?
>
> That's my current project: the Remote Agent Experiment (RAX) for the New
> Millenium program's Deep Space One mission, an asteroid/Mars/comet
> flyby, and technology validation mission. Autonomous operation is one
> of the technologies being validated. I'm a staff programmer for a
> contractor on the planner/scheduler and smart executive teams at NASA
> Ames Research Center. NASA Ames is collaborating with the Jet
> Propulsion Laboratory on the autonomy software. See
> <http://www.jpl.nasa.gov/ds1/> for an overview of the mission; see
> <http://ic-www.arc.nasa.gov/ic/projects/Autonomous-Systems.html>
> for some of my group's work.
>
> And yes, we're flying Common Lisp for a one-week autonomy experiment.
> Ironically the planner/scheduler portion was halfway ported to C++
> before the flight S/W management team pulled the plug on C++ due to
> political and S/W tools issues. Personally I was dismayed at the lack
> of maturity of our C++ tools, and the inconsistencies between various
> C++ implementations. (Sorry, I'm not naming names.)
>
> But getting Lisp onboard has been one hell of a struggle politically,
> and was possible at all only because our team had strong allies in NASA
> upper management. About half the autonomy team feels that follow-on
> projects would have a greater chance of success if coded in C or maybe
> C++ (assuming the previous technical issues are resolved). Some
> adventurous folks are even suggesting Java for flight. IMHO Java makes
> C++ look mature!
Well, you COULD put in a C/C++ Lisp interpreter and claim your lisp is
just data....
Chuck Fry wrote:
>
> You don't need compilers in space, and only a
> lightweight debugger/interpreter is required for changes "on the fly".
Maybe I'm overlooking the obvious, but can't you dump an image without
the compiler?
In article <··········@bgtnsc02.worldnet.att.net>,
Steve Gonedes <··@address.net> wrote:
>Chuck Fry wrote:
>> You don't need compilers in space, and only a
>> lightweight debugger/interpreter is required for changes "on the fly".
>
>Maybe I'm overlooking the obvious, but can't you dump an image without
>the compiler?
Sure you can, and we're doing that. But there is still a substantial
amount of unused code (as in megabytes) remaining in the image. I
believe this would be true of any of the commercial CL implementations
I'm familiar with.
Working around this with large shared libraries a la MCL (getting back
to the original topic!) is not a solution IMHO.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
From: Philip Lijnzaad
Subject: Re: Lisp in space was: (not really about) MCL
Date:
Message-ID: <u7en09qvqu.fsf@ebi.ac.uk>
Craig Brozefsky <·····@onshore.com> writes:
> "Software is not designed or intended for use in on-line control of
> aircraft, air traffic, aircraft navigation or aircraft communications;
> or in the design, construction, operation or maintenance of any
> nuclear facility. Licensee warrants that it will not use or
> redistribute the Software for such purposes."
do we find this notice bundled with your average Basic/C/Fortran/Cobol
compiler ? Does this imply anything about *their* safety (and implied
liability) as a tool for mission critical stuff?
I think this paragraph is largely there to defuse any unreasonable safety
expectations that resulted from the much publicized Java sandbox safety. Not
too unreasonable (especially in this overlawyerized day and age). Just my
0.02,
Philip
--
Any coffee stains in this message must have occured in transit
-----------------------------------------------------------------------------
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: Charles Martin
Subject: Re: Lisp in space was: (not really about) MCL
Date:
Message-ID: <35069FCF.31C9F46B@connix.com>
Philip Lijnzaad wrote:
>
> Craig Brozefsky <·····@onshore.com> writes:
>
> > "Software is not designed or intended for use in on-line control of
> > aircraft, air traffic, aircraft navigation or aircraft communications;
> > or in the design, construction, operation or maintenance of any
> > nuclear facility. Licensee warrants that it will not use or
> > redistribute the Software for such purposes."
>
> do we find this notice bundled with your average Basic/C/Fortran/Cobol
> compiler ? Does this imply anything about *their* safety (and implied
> liability) as a tool for mission critical stuff?
I wonder if this is true any longer? As you say, the way litigation is
going, it seems only a matter of time before the OS and compiler
vendor(s) are brought into a product liability suit.
>
> I think this paragraph is largely there to defuse any unreasonable safety
> expectations that resulted from the much publicized Java sandbox safety.
Safety is not the same as security: the java applet sandbox (1) applies
only to applets (2) is just an access-control mechanism.
Chuck Fry wrote:
....
>
> I *am* an AI person, and because our applications are on spacecraft,
> we're seeing a lot of pressure to switch to C and C++.
>
I am curious why there is such pressure to enforce tool choices - with
the adoption of CORBA and/or ActiveX, and Lisp vendor support of such
standards, why should a particular application be concerned with which
language it is written in, apart from its suitability to the task at
hand? BTW, I wrote an application in ACL for a PC - my client was very
nervous because "Lisp is slow, a memory hog, yada, yada, yada." My
initial software package was as he feared - it took 7 minutes to process
a 6 MB file, but when I spent two weeks doing memory management and
strong data typing, that time fell to 40 seconds - a time that would
have been considered fast in C/C++. My point here is not to toot my own
horn, but to point out that Lisp should be able to hold its own in the
market place if it is evaluated on its merits, not on someone's
prejudice.
--
Raymond Laning
12481 Bentbrook Ln
Chesterland, OH 44026
440-729-6206
186,000 miles/second - it's a speed we can live with
* Raymond Laning <·······@ix.netcom.com>
| I am curious why there is such pressure to enforce tool choices - with
| the adoption of CORBA and/or ActiveX, and Lisp vendor support of such
| standards, why should a particular application be concerned with which
| language it is written in, apart from its suitability to the task at
| hand?
in brief: the blue-collarization of programming. managers don't need
_programmers_, anymore, they need coders, lots of them. programming is
not an art, it's just skilled labor. lots of coders sitting at an
assembly line putting together some bulky, crappy application in C/C++ is
cheap, easy to manage, and fits right in with how MBAs have learned to
run factories.
| BTW, I wrote an application in ACL for a PC - my client was very nervous
| because "Lisp is slow, a memory hog, yada, yada, yada." My initial
| software package was as he feared - it took 7 minutes to process a 6 MB
| file, but when I spent two weeks doing memory management and strong data
| typing, that time fell to 40 seconds - a time that would have been
| considered fast in C/C++. My point here is not to toot my own horn, but
| to point out that Lisp should be able to hold its own in the market place
| if it is evaluated on its merits, not on someone's prejudice.
this parallels my experience. initial cuts on solutions are developed
fast, run slow, and allow the customer (or the developer) to assess the
various designs and approaches. then I profile, rewrite, and shine the
code up, and it runs faster than the dumb C code some cheap labor would
have written. at lower costs. of course, some management gets nervous
just because the development cycle is different from that of C/C++ -- and
there are usually enough unknowns in the development process already to
give anybody good reason to be nervous, especially since it's no fun to
do what already has a known, simple solution.
there _are_ managers out there who care more about the results than about
being control freaks and reducing irrelevant uncertainty factors, but
they aren't in the majority. the majority optimize for costs and time
schedules prematurely. come to think of it, that's just what C/C++
programmers do, too... I guess they deserve each other. :)
#:Erik
--
God grant me serenity to accept the code I cannot change,
courage to change the code I can, and wisdom to know the difference.
In article <················@naggum.no>, Erik Naggum <······@naggum.no> wrote:
> there _are_ managers out there who care more about the results than about
> being control freaks and reducing irrelevant uncertainty factors, but
> they aren't in the majority. the majority optimize for costs and time
> schedules prematurely. come to think of it, that's just what C/C++
> programmers do, too... I guess they deserve each other. :)
.sig quote alert!!
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
In article <············@shell5.ba.best.com>, ······@shell5.ba.best.com
(Chuck Fry) wrote:
> I *am* an AI person, and because our applications are on spacecraft,
> we're seeing a lot of pressure to switch to C and C++.
Dear Christ in heaven! They want to implement man-critical (meaning: if the
software fails, someone dies) software in C and/or C++? Why not just shoot
the astronauts and be done with it?
Seriously... I can see moving away from Lisp... but my choice of
destinations would probably be something like Standard ML, where I could
actually submit the software to theorem provers to ascertain its
correctness, etc. And even with that, I'd *still* insist on triple
redundancy...
If my software were responsible for keeping people alive, I'd want
something better than C or C++ behind it. Something *much* better.
> -- Chuck
>
>
> --
> Chuck Fry -- Jack of all trades, master of none
> ······@chucko.com (text only please), ········@home.com (MIME enabled),
> ······@gateway.idiom.com (SPAM ONLY)
Paul Snively
In article <·································@news.mci2000.com>,
Paul F. Snively <·····@mcione.com> wrote:
>In article <············@shell5.ba.best.com>, ······@shell5.ba.best.com
>(Chuck Fry) wrote:
>> In article <·································@news.mci2000.com>,
>> Paul F. Snively <·····@mcione.com> wrote:
>> >Dear Christ in heaven! They want to implement man-critical (meaning: if the
>> >software fails, someone dies) software in C and/or C++? Why not just shoot
>> >the astronauts and be done with it?
>>
>> You misunderstand. We're sending the AI in lieu of astronauts. The
>> missions in question are unmanned probes.
>
>Oh right right right. Of course. Mea culpa, both for the repeated posts and
>the brain-damage. I know about this. Eran Gat is working on this at JPL,
>yes?
Yes, Erann Gat (corrected spelling) is part of the DS1 Remote Agent
Experiment team.
Erann is also working on the Lisp implementation for spaceflight that I
obliquely referred to earlier in this thread, along with Gary Byers,
late of the MCL compiler team (tying this back to the original subject
line again!).
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled),
······@gateway.idiom.com (SPAM ONLY)
* John Arley Burns wrote:
> That having been said, I agree with your stance, and I too would
> like to be running a LISP OS (in some ways I do - I rarely leave
> emacs!). My main concern is that computer science has not advanced
> to the point where an efficient LISP OS is implementable.
I think this is not true. It depends to an extent on what you mean by
`efficient', but if you mean `plenty fast enough' then such an OS is
clearly possible. Example: my home computer is a Symbolics 3650,
which is perhaps twice as fast as a Vax 11/750, has 27Mb of memory (6
Mwords, 36 bit words), and runs an OS written in Lisp. It has
hardware & microcode support for Lisp, which gets it perhaps an
advantage of a factor of 4 speed (this is probably a considerable
overestimate).
It's very usable. Developing programs &c is extremely possible on a
machine like this, and in fact I write Lisp code by preference on this
machine rather than my ultrasparc at work because I find the
environment better (and I have access to two commercial lisp systems
at work). It does have the kind of performance problems you'd expect
-- big compute intensive programs take a long time, recompiling large
programs takes a while. It also has much slower disk I/O than Unix
machines of that era, but I suspect that' largely because it's a much
less filesystem-oriented machine so they never optimised that.
As I said above, perhaps this machine is getting a 4x speedup from the
hardware support. But 8x as fast as an 11/750 is not fast. If you
scaled its performance to the kind of commodity hardware that's
available now, taking out the factor of 4, I'm reasonably sure the
general performance of the system would beat modern systems hands down
(as would the general performance of most systems of that era). Of
course it wouldn't be winning for large scale numerical simulations,
but the editor & mail system would be lot faster than currently
fashionable offerings for instance. Modern C/C++ systems are taking
performance hits of orders of magnitude both to provide features with
completely marginal benefit, and also simply because modern HW removes
the incentive to write efficiently.
So yes, a Lisp OS with good performance is possible.
--tim
Martin B. Pomije wheezed these wise words:
> If we want to make Lisp popular, there must be powerful, cheap Lisp
> environments (both Lisp programming tools and eventually a Lisp-based
> operating system) available for cheap hardware (PC clones). Even if a
> product is technically superior, a cheaper product that sort of does the
> job will win out. Look at the Mac vs. Windoze 3.1, Genera and VMS vs.
> Unix, VHS vs. Beta.
I've also said this. Perhaps I expressed myself poorly, because I got
flamed. Yet I stressed again and again that I was only offering
constructive critisim - which nobody denied. Since others have said
similar things without reprisals, it may have been something personal.
Anyway...
> The companies that marketed the better systems were
> able to make more money in the short term by charging a premium for a
> superior product, but the "worse-is-better" product won in the end. A
> long-time hardware engineer where I work told me that TTL logic wasn't
> that great, but Texas Instruments marketed it well, so soon digital
> logic soon had to be TTL-compatible. The "invisible hand" of the free
> market doesn't have a strong track record when it comes to this. It has
> happened over and over again.
Market demands. So TI are the MS of hardware?
> Unfortunatly, the the free software seems to be much stronger on
> the C/Unix side of things. This is part of why many programmers are
> only exposed to this stuff, instead of the much more powerful Lisp
> systems. For example, I've known many intelligent programmers that
> think that C++ is great. This occurs because they have never been
> exposed to a decent implementation of object oriented programming. They
> see that C++ lets them get rid of some of the disadvantages of C, and
> they think that it therefore is a great thing. Programming with
> Microsoft Foundation Classes is easier than calling all of those Win32
> API routines, so Microsoft must know all there is to know about greating
> powerful GUI systems. People think that Unix is great because it's
> better than DOS, and it doesn't have Microsoft giving itself an unfair
> advantage with hidden APIs. I don't think that most these people are
> stupid, they just think that putting up with this crap is part of
> creating software.
As Kent Pitman (amoung others) has pointed out, people faced with
unpleasant tools, and no way of avoiding them, may feel a need to
justify using them. I've noticed many ex-DOS programmers doing this,
even when they have access to superior tools for a superior OS.
Some of us crawl out of the mud. ;) Even when we're in it, we may
still gaze up at the stars. Sadly, not all of us do. Either there's a
lack of imagination, or a lack of education. Both can be cured.
Some may convince themselves that eating dirt is good when that's all
they have. Others look around for new pastures.
> Quoting from my favorite computer book, The UNIX-HATERS Handbook:
> "I liken starting one's computing career with Unix, say as an
> undergraduate, to being born in East Africa. It is intolerably hot, your
> body is covered with lice and flies, you are malnourished and you are
> suffering from numerous curable diseases. But, as far as young East
> Africans can tell, this is simply the natural condition and they live
> withing it. By the time they find out differently, it is too late.
> They already think the writing of shell scripts is a natural act."
> --Ken Pier
I know people who never get as far as writing shell scripts. They do
it all by hand, step by step, every time. Tool building should be
easy, and tool building tools are abundant, yet some people will still
ignore them. Worse, they may use these tools to do _some_ things, but
not everything. They then complain about those things as if there's no
solution. Is this stupidity or just laziness? I consider myself to be
a lazy programmer, which is why I choose tools that do the most work
for me, letting the machine serve me instead of the other way around.
> I think that this can also be said of many languages around, like Perl.
> Well, writing Perl is better than shell scripts, so it must be good.
> It's just natural to have to put a $ in front of variables to tell the
> interpreter "This is variable". It's what scripting languages need,
> right?
The worst thing about Perl is that it does just what I need, without
much fuss. I use it as an alternative to NT's batch language. I could
also use VBS, JavaScript, and no doubt many others. However, it's the
regex and process control that I like in Perl. Guile also has this, so
I expect I'll start using that as soon I find the Win32 port.
Then I'll see if I can use Guile at work. That's a non-techie issue,
but since I'm the only one there who uses Perl or anything like it, it
should be as easy to justify using Guile. We'll see.
Mindshare is one of the non-techie factors. Perl has a lot of that.
See how Larry Wall promoted Perl. My hope is that Guile will enjoy a
similar rise in popularity, to the point where people regularly use it
write CGI scripts, ORA publish books about it, etc.
> The success of DOS and Linux indicates that a cheap solution can take
> the world by storm. Imagine how well a free operating system could do
> if it had a decent user interface, with something as advanced as file
> versions. (Oh my gosh, have they done that before? That would be a
> great idea!)
How about a cheap LispOS? This may yet happen.
> I am totally unqualified to do this technically, but I wish I was.
Same here. However, we can all play a small part. This is usually how
it happens. Take a look at Guile, if you haven't already.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish