MCL
William Barnett-Lewis
Hello,
Having recently made the switch to a Mac from the WinTel world, I find
myself looking for a Mac CL. MCL seems to be an excellent
implementation, but there is no way I can afford full cost. I will not
BS them and claim to be a student either. As a result, I was wonderiung
if anyone has an older version that they would be willing to sell to me.
TIA,
William
William Barnett-Lewis
wle...@mailbag.com
Rainer Joswig
In article <34E9E029...@mailbag.com>, William Barnett-Lewis
<wle...@mailbag.com> wrote:
> Hello,
>
> Having recently made the switch to a Mac from the WinTel world, I find
> myself looking for a Mac CL. MCL seems to be an excellent
> implementation, but there is no way I can afford full cost.
A single issue of MCL costs $345.00 .
--
http://www.lavielle.com/~joswig/
Barry Margolin
In article <34E9E029...@mailbag.com>,
William Barnett-Lewis <wle...@mailbag.com> wrote:
>Having recently made the switch to a Mac from the WinTel world, I find
>myself looking for a Mac CL. MCL seems to be an excellent
>BS them and claim to be a student either. As a result, I was wonderiung
>if anyone has an older version that they would be willing to sell to me.
How about using the shareware PowerLisp? It may not have all the features
of MCL, but it should be in your price range.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
Alan Fullilove
In article <joswig-1802...@kraftbuch.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:
> In article <34E9E029...@mailbag.com>, William Barnett-Lewis
> <wle...@mailbag.com> wrote:
>
> > Hello,
> >
> > Having recently made the switch to a Mac from the WinTel world, I find
> > myself looking for a Mac CL. MCL seems to be an excellent
> > implementation, but there is no way I can afford full cost.
>
> A single issue of MCL costs $345.00 .
If you are a student, it's even less expensive. I believe less than $150.
Ron Parr
I haven't tried PowerLisp in a while, but I found it very unreliable the
last time I checked it out. Code that worked fine in Allegro or MCL
would produce strange or unpredictable results in PowerLisp.
--
Ron Parr email: pa...@cs.berkeley.edu
--------------------------------------------------------------------------
Home Page: http://http.cs.berkeley.edu/~parr/
Mac tips: http://http.cs.berkeley.edu/~parr/rrrt-top.html
Ralph Leonhardt
In article <34E9E029...@mailbag.com>,
William Barnett-Lewis <wle...@mailbag.com> writes:
> Hello,
>
> Having recently made the switch to a Mac from the WinTel world, I find
> myself looking for a Mac CL. MCL seems to be an excellent
> BS them and claim to be a student either. As a result, I was wonderiung
> if anyone has an older version that they would be willing to sell to me.
>
Everything is free
there and there are a lot of LISP implementations.
Ralph 8-)
--
-------------------------------------------------------------------------------
There are three kinds of economists, those who can count and those who can't.
Rainer Joswig
Ralph Leonhardt schrieb in Nachricht ...
>You should switch immediatly to the Lintux (Linux/Intel World).
>Everything is free
>there and there are a lot of LISP implementations.
Why should he switch to Linux when Macintosh Common Lisp is
so much better then the "free" stuff?
I'd rather propose he immediately switch to a Lisp machine,
where everything is written in Lisp.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Why should he switch to Linux when Macintosh Common Lisp is
> so much better then the "free" stuff?
>
> I'd rather propose he immediately switch to a Lisp machine,
> where everything is written in Lisp.
As usual, we barely have enough information to begin asking questions
about what is needed. We know a few things: 1) William Barnett-Lewis
has a Mac 2) He has a budget that makes MCL look expensive.
I'm very reluctant to suggest that _anybody_ change OS, esp when
they've only just made such a change. Thus, I guessing that William is
interested in Apple's OS, and not Linux, which is after all available
for his previous machine. While there may be other reasons for
changing machine, his MCL question suggests that it wasn't so that he
could run Linux.
The real question is: who will run the code? If it's a Mac user with
no Lisp machine, then MCL might be the only option, unless they're
happy to acquire a MacIvory card. The developer might prefer all kinds
of options, and if the developer is the only user of the code, then
there are few non-technical constraints. If the code is for somebody
else, then they may make demands not yet discussed here.
Now, if a MacIvory is cheaper than a copy of MCL, and every user
(possibly just the developer) can afford one, this could be ideal.
I'm assuming availability of a MacIvory, as I can't comment on that.
My final comment is a disclaimer. We all like to recommend the tools
we use ourselves. This is only fair, as we have plenty of experience
with them. ;) My experience with MCL or a MacIvory is the same: nil.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Martin B. Pomije
Rainer Joswig wrote:
>
> Ralph Leonhardt schrieb in Nachricht ...
>
> >You should switch immediatly to the Lintux (Linux/Intel World).
> >Everything is free
> >there and there are a lot of LISP implementations.
>
> so much better then the "free" stuff?
>
> I'd rather propose he immediately switch to a Lisp machine,
> where everything is written in Lisp.
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)
--
*********************************************
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.
Rainer Joswig
In article <34F0B38C...@inav.net>, "Martin B. Pomije"
<mbpo...@inav.net> wrote:
> Rainer Joswig wrote:
> >
> > Ralph Leonhardt schrieb in Nachricht ...
> >
> > >You should switch immediatly to the Lintux (Linux/Intel World).
> > >Everything is free
> > >there and there are a lot of LISP implementations.
> >
> > Why should he switch to Linux when Macintosh Common Lisp is
> > so much better then the "free" stuff?
> >
> > I'd rather propose he immediately switch to a Lisp machine,
> > where everything is written in Lisp.
> Since Apple looks like it is going down the tubes,
Where did you get this from? I wouldn't want to predict this right now.
Recent Macs are very competetive. I can compile CL-HTTP in under
1 minute 30 seconds on a fast Mac. MCL *eats* source code
on those systems like nothing else. CLIM is coming nearer, etc.
> 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)
There is no free Common Lisp on the Mac available. PowerLisp
is Shareware and it is as far as you can get as a single
person developing a Common Lisp (fascinating to see). So, if you
want to stick with the Mac, I think MCL is a good investment.
It is mature, easy to use and has a very active user
community. I wouldn't mind to have it ported to Rhapsody - should
I ever switch to this OS on my laptop.
On Unix and Windows we have a choice. Both Harlequin and
Franz have strong implementations. Drawback on Unix: too
expensive. "Free" versions of Common Lisp are mainly
available on Unix systems, which I'm not a particular fan of.
The quality of those is mostly way behind the commercial offerings.
But often they offer enough features to be useful in certain
areas (we have been using GCL and CLISP).
--
Would there anybody be willing to help me to collect informations
on the various Lisp systems available? An extensive standard description
format would be needed.
This would result in browseable web pages, where it
would be easier to compare the features. I started last year to
write down some categories. Martin Cracauer did send me a
prototype entry for CMU CL. We would need to write some
CL-HTTP code to generate questionaires and browseable
overview and detail pages.
Greetings,
Rainer Joswig
--
http://www.lavielle.com/~joswig/
Simon Gadbois
> 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!
--
_________________________________________________
Simon Gadbois
Department of Psychology
Life Sciences Centre
Dalhousie University
Halifax, Nova Scotia
Canada, B3H 4J1
sgad...@is2.dal.ca
902-494-6809 (office, 2519)
902-494-3603 (Fentress's lab)
902-494-3370 (Moger's lab)
902-494-6585 (fax @ Dalhousie)
902-857-9206
Behavioral (social) endocrinology of the wolf
(aggression and social stress, urinary cortisol).
Sequential and temporal analysis of behavior.
Martin B. Pomije
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!
>
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.
William Paul Vrotney
In article <34F79B28...@inav.net> "Martin B. Pomije"
<mbpo...@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 - vro...@netcom.com
Martin B. Pomije
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.
William Paul Vrotney
In article <34F7C104...@inav.net> "Martin B. Pomije"
<mbpo...@inav.net> writes:
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.
John Arley Burns
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.
Paul Dietz
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
Martin Rodgers
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
Martin Rodgers
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
Paul Prescod
In article <34F7C104...@inav.net>,
>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
Tim Bradshaw
* 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
Wolfgang von Hansen
Moin, Moin!
William Paul Vrotney <vro...@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: w...@geodesy.inka.de //
~oo~ Uni: vha...@ipf.bau-verm.uni-karlsruhe.de \X/
(..)
Espen Vestre
"Wolfgang von Hansen" <w...@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
Wolfgang von Hansen
Moin, Moin!
Juergen Nickelsen <jnick...@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).
Tim Bradshaw
* 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
Chuck Fry
In article <9786...@geodesy.inka.de>,
Wolfgang von Hansen <w...@geodesy.inka.de> wrote:
>Juergen Nickelsen <jnick...@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
chu...@chucko.com (text only please), chuc...@home.com (MIME enabled),
chu...@gateway.idiom.com (SPAM ONLY)
Wolfgang von Hansen
Moin, Moin!
Chuck Fry <chu...@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.
Chuck Fry
>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
Rainer Joswig
In article <6dq0dt$1qu$1...@shell5.ba.best.com>, chu...@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/
Raymond Laning
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++.
>
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
Erik Naggum
* Raymond Laning <rla...@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.
Chuck Fry
In article <joswig-0703...@194.163.195.66>,
Rainer Joswig <jos...@lavielle.com> wrote:
>In article <6dq0dt$1qu$1...@shell5.ba.best.com>, chu...@shell5.ba.best.com
>(Chuck Fry) wrote:
>> we're seeing a lot of pressure to switch to C and C++.
>
>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 Fry
In article <30983383...@naggum.no>, Erik Naggum <cle...@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!!
Charles Martin
Well, you COULD put in a C/C++ Lisp interpreter and claim your lisp is
just data....
Steve Gonedes
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?
Paul F. Snively
> 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
> chu...@chucko.com (text only please), chuc...@home.com (MIME enabled),
> chu...@gateway.idiom.com (SPAM ONLY)
Paul Snively
Chuck Fry
In article <6duu7m$h...@bgtnsc02.worldnet.att.net>,
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 Fry
In article <chewy-ya02408000...@news.mci2000.com>,
Paul F. Snively <ch...@mcione.com> wrote:
>In article <6dq0dt$1qu$1...@shell5.ba.best.com>, chu...@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?
You misunderstand. We're sending the AI in lieu of astronauts. The
missions in question are unmanned probes.
>If my software were responsible for keeping people alive, I'd want
>something better than C or C++ behind it. Something *much* better.
You and me both!
Eric S. Ingram
What news reader software is everyone using? Isn't it capable of
replying to items? There seems to be a proliferation of unnecessary new
threads with subjects starting "RE: ... " in this newsgroup.
Chuck Fry
In article <3503E2E3...@cableinet.co.uk>,
Blame me, I re-titled many of the tangential threads. I don't believe
in reusing the same subject line if the subject has changed.
As for "unnecessary", that's your opinion. I think this stuff matters
to the Lisp community. Don't read it if you don't want to. No one's
holding a gun to your head.
Bill Coderre
chu...@shell5.ba.best.com (Chuck Fry) wrote:
| Some
| adventurous folks are even suggesting Java for flight. IMHO Java makes
| C++ look mature!
Tell these people to read the Sun license agreements for Java. Sun
specifically disallows use of Java for certain "life or death" kinds of
code. If they don't include unmanned space probes in that list, well, they
might have just forgot to add it. You should check.
Not to say anything unkind about Java, of course. I'm sure it's the best
thing since sliced beets.
But really, is NASA turning into the "trendy programming language of the
week" club? Sheesh.
bc
David H Wild
In article <6e1bal$2kd$1...@shell5.ba.best.com>,
Chuck Fry <chu...@shell5.ba.best.com> wrote:
> As for "unnecessary", that's your opinion. I think this stuff matters
> to the Lisp community. Don't read it if you don't want to. No one's
> holding a gun to your head.
To be fair I think the complaint was about the new threads not being
necessary, not the postings themselves.
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | / Acorn Risc_PC
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ dhw...@argonet.co.uk
Uploaded to newnews.dial.pipex.com on Mon,09 Mar 1998.21:39:41
John Arley Burns
I agree... I had forgotten the old days of TI lisp machines - very
nice! I would certainly like to start such a project (if one is not
already in progress) once I graduate from school (I don't really know
enough about OS theory now). I wouldn't mind the performance hit (I
never leave emacs anyhow ;). If a project is started now I could at
least contribute in areas I know something about, at least testing.
Eric S. Ingram
Chuck Fry wrote:
>
> Blame me, I re-titled many of the tangential threads. I don't believe
> in reusing the same subject line if the subject has changed.
>
An appropriate change of the subject line by a moderator is just fine
when the subject line no longer reflects the content of the item.
However, what is the point of breaking the thread between items that do
pertain to the subject line?
Making each item a thread of length one defeats useful news reader
facilities such as 'watch thread'.
Chuck Fry further wrote:
>
> As for "unnecessary", that's your opinion. I think this stuff matters
> to the Lisp community.
I was not suggesting that the item content was unnecessary ... just the
breaking of the threads.
Craig Brozefsky
b...@wetware.com (Bill Coderre) writes:
> chu...@shell5.ba.best.com (Chuck Fry) wrote:
> | Some
> | adventurous folks are even suggesting Java for flight. IMHO Java makes
> | C++ look mature!
>
> Tell these people to read the Sun license agreements for Java. Sun
> specifically disallows use of Java for certain "life or death" kinds of
> code. If they don't include unmanned space probes in that list, well, they
> might have just forgot to add it. You should check.
From the license of JDK 1.1.5:
"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."
--
Craig Brozefsky cr...@onshore.com
onShore Inc. http://www.onshore.com/~craig
Programmer loitering on the edge
Bill Coderre
I am guessing, but maybe the news<->mail gateway is not preserving the
"References" headers, which are used for threading.
Yes, I have noticed the problem. Sorting the newsgroup by subject line
seems like a pretty good hack workaround.
bc
(liking broken headers A LOT more than "C is better than Lisp" bull.)
Paul F. Snively
In article <6e022m$kv2$1...@shell5.ba.best.com>, chu...@shell5.ba.best.com
(Chuck Fry) wrote:
> In article <chewy-ya02408000...@news.mci2000.com>,
> Paul F. Snively <ch...@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?
> >If my software were responsible for keeping people alive, I'd want
> >something better than C or C++ behind it. Something *much* better.
>
> You and me both!
> -- Chuck
Heh! Thanks for setting me straight!
> --
> Chuck Fry -- Jack of all trades, master of none
> chu...@chucko.com (text only please), chuc...@home.com (MIME enabled),
> chu...@gateway.idiom.com (SPAM ONLY)
Paul
Philip Lijnzaad
Craig Brozefsky <cr...@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, lijn...@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
Charles Martin
Philip Lijnzaad wrote:
>
> Craig Brozefsky <cr...@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
In article <chewy-ya02408000...@news.mci2000.com>,
Paul F. Snively <ch...@mcione.com> wrote:
>In article <6e022m$kv2$1...@shell5.ba.best.com>, chu...@shell5.ba.best.com
>(Chuck Fry) wrote:
>> In article <chewy-ya02408000...@news.mci2000.com>,
>> Paul F. Snively <ch...@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