I have sat here and wondered over a longish time why Lisp is dying a slow
death and yet ST-80 holds, at least, steady. This is, I think, because it
is like getting a frikking tooth pulled to get an answer out of anyone
other than Barry or a certain former member of harlequin. _Why_ is it so
hard to get an honest answer out of the lisp list when I _know_ that any
question I have about ST-80 or Squeak will get an answer from the person
responsible in a matter of hours? John M, Allen Kay, Dan Ingals, etc -
Well, it really doesn't matter does it? This is why, ultimately, I stopped
trying to build a free interpreter for Medley (Inter-)Lisp; Squeak fulfills
each and every little thing that Lisp could hope to. And I know that
anything I want to know _will_ come up in our list and it _will_ be
answered... even if that answer is "I don't know."
More than anyone else here, this message is to you, Erik, because you are
the day to day expression of everything that is wrong with C.L.L.
William
A few months ago, I began to learn LISP. Around the same time I
subscribed to this newsgroup. During this time, I have become more and
more impressed with the power of LISP, as well as the posts that the
practitioners of the language make to this newsgroup. However, I feel
it is posts similiar to yours that are an expression of what is wrong
with C.L.L.
re:politeness
=============
I appreciate impoliteness. I also appreciate politeness. Generally,
I appreciate _honesty_ - and that is what I have found in the postings
on this group. When all you are witnessing is politeness, you can be
assured that there is some dishonesty present.
A newsgroup is not a textbook. What distinguishes USENET from other
information resources is the human factor - the mind; not half a mind,
or one third, but hopefully an entire mind - with all its complexity,
beauty, as well as _attitude_. If you find that other newsgroups serve
up fine, tasteless, bland responses guaranteed not to cause
indigestion, by all means enjoy. I, for one, appreciate the attitude
that resides in this and other newsgroups. It keeps everyone honest
and lets those that ask 'stupid questions' know that someone cares
about them.
re:death of Lisp
================
For me, lisp was just born. It may be dying in your eyes, but for
me it has created new ways of thinking about old ideas, as well as
simplifying formerly complex tasks.
If you believe that the impoliteness on this newsgroup somehow aids
the death of lisp, I can only disagree. If someone that was interested
in learning LISP, stops doing so after receiving an impolite response
on comp.lang.lisp, about all I can say is that they were not truly
interested. Learning anything demands that you truly want to learn it,
whether to get a scrap of food, or for the 'cool' factor of it, or out
of plain curiosity - and you will not be deterred by a simple USENET
post if that is the case.
re:Erik and others
==================
Unrestricted self-expression is the driving force behind art,
programming, and many of the positive changes that have occurred within
society throughout history. Restriction can only bring negative
changes, and will not produce striking art or code. Freedom of expression
on USENET is important. For the first time, we can all talk to each
other, instantly, across the globe - let us not restrict ourselves
mindlessly.
--
Samir Barjoud (can now legally drink, but why?)
·····@mindspring.com
* ······@mailbag.com (William Barnett-Lewis)
| More than anyone else here, this message is to you, Erik, because you are
| the day to day expression of everything that is wrong with C.L.L.
it must be great to be able to find someone to blame for all ills or
evils you see. I wish I had the intellectual capacity for this
simplicity, sometimes. understanding the more complex interplay of
factors is such an _effort_ most of the time.
#:Erik
--
if people came with documentation, could men get the womanual?
--------------A0EE1FD1C3E7F3524E4DA8FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> * ······@mailbag.com (William Barnett-Lewis)
> | More than anyone else here, this message is to you, Erik, because you are
> | the day to day expression of everything that is wrong with C.L.L.
>
Got to admit had to laugh at this. Lisp's decline in use has nothing to do
with the people who use it, at least in North Texas. Lisp's demise is due to
the fact that lisp (by reputation anyway) answers question that are not being
asked much these days. I can't remember the last time I had a user request a
program to solve "the eight piece puzzle", one that needed a A* search, or
even an expert system (they gave up on those sometime ago).
I enjoy most of the *off topics* the news group has but this personality
analysis should be carried on by personal email. If Erick wants to boil
someone in oil in public...it is his business. If you wish to take issue with
Erick please email him directly.
Hmmm strange how a news group reflects life in general.
Neither Erick or any one's _personality_ is going to influence the future of
lisp to any extent. So please let's give it a rest and put the time to better
use.....writing lisp. Writing lisp and lisp programs might help lisp more or
maybe start a lisp user group at your local college. I stopped by Texas
Christian University library not to long ago; the last time a lisp or scheme
book of any kind was checked out by a student was 1993. There were _six_ books
on lisp or scheme...and you know they don't even know Erick. (there were three
full sections on java).
One of the students at TCU is helping me put muLisp on an EPROM. The professor
was in the lab talking to us while we were working. I ran a lisp (muLisp)
program for him that contained an algorithm that Gareth McCaughan cooked up for
serial data gathering. I can not say that I made a convert but he is ordering
muLisp for the department even though they do little or no DOS (muLisp is a DOS
program) work.
As I said in my first posting to this NG....lisp on the other end of things
that is small, fast, low-level has a place in the world. Controlls machines,
electornics, and communications. If you have ever made little machines go with
Forth we will love doing it with lisp.....you can maintain your code, remember
what a piece of code does and how it does it. If you don't have a little
machine, well get one and muLisp. Beats the hell out of tring to develope
personalities online.
btw Erick I am interested in your 99.95% uptime and how your run your test
application in parallel with production. Does your application not have a
"dayend" process for backup, archive, billing etc or do you count this as
uptime also?
muLisp a machine and smile
rusty
--------------A0EE1FD1C3E7F3524E4DA8FB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>
<blockquote TYPE=CITE>* ······@mailbag.com (William Barnett-Lewis)
<br>| More than anyone else here, this message is to you, Erik, because
you are
<br>| the day to day expression of everything that is wrong with C.L.L.
<br> </blockquote>
<font size=+1>Got to admit had to laugh at this. Lisp's decline in
use has nothing to do with the people who use it, at least in North Texas.
Lisp's demise is due to the fact that lisp (by reputation anyway)
answers question that are not being asked much these days. I can't
remember the last time I had a user request a program to solve "the eight
piece puzzle", one that needed a A* search, or even an expert system
(they gave up on those sometime ago).</font><font size=+1></font>
<p><font size=+1>I enjoy most of the *off topics* the news group has but
this personality analysis should be carried on by personal email.
If Erick wants to boil someone in oil in public...it is his business.
If you wish to take issue with Erick please email him directly.</font><font size=+1></font>
<p><font size=+1>Hmmm strange how a news group reflects life in general.</font><font size=+1></font>
<p><font size=+1>Neither Erick or any one's _personality_ is going to influence
the future of lisp to any extent. So please let's give it a rest
and put the time to better use.....writing lisp. Writing lisp and lisp
programs might help lisp more or maybe start a lisp user group at your
local college. I stopped by Texas Christian University library not
to long ago; the last time a lisp or scheme book of any kind was checked
out by a student was 1993. There were _six_ books on lisp or scheme...and
you know they don't even know Erick. (there were three full sections
on java).</font><font size=+1></font>
<p><font size=+1>One of the students at TCU is helping me put muLisp on
an EPROM. The professor was in the lab talking to us while we were
working. I ran a lisp (muLisp) program for him that contained
an algorithm that Gareth McCaughan cooked up for serial data gathering.
I can not say that I made a convert but he is ordering muLisp for the department
even though they do little or no DOS (muLisp is a DOS program) work.</font><font size=+1></font>
<p><font size=+1>As I said in my first posting to this NG....lisp on the
other end of things that is small, fast, low-level has a place in the world.
Controlls machines, electornics, and communications. If you have
ever made little machines go with Forth we will love doing it with lisp.....you
can maintain your code, remember what a piece of code does and how it does
it. If you don't have a little machine, well get one and muLisp.
Beats the hell out of tring to develope personalities online.</font><font size=+1></font>
<p><font size=+1>btw Erick I am interested in your 99.95% uptime
and how your run your test application in parallel with production.
Does your application not have a "dayend" process for backup, archive,
billing etc or do you count this as uptime also?</font><font size=+1></font>
<p><font size=+1>muLisp a machine and smile</font>
<br><font size=+1>rusty</font></html>
--------------A0EE1FD1C3E7F3524E4DA8FB--
* rusty craine <········@flash.net>
| btw Erick I am interested in your 99.95% uptime and how your run your
| test application in parallel with production. Does your application not
| have a "dayend" process for backup, archive, billing etc or do you count
| this as uptime also?
the uptime statistics are for the hours of regular operation, that is
from 04:00 through 23:00 on weekdays and from 18:00 through 23:00 on
Sundays. outside those hours, the system can be taken down for (major)
upgrades. we have start of day reset at 00:00 which basically unloads
all the heavy objects (they are loaded back from disk if needed) and runs
a global GC. there's also a start of week reset at Sunday 00:00. (both
are run manually if the system needs downtime in the off hours.) backup
is not disruptive. other administrative functions run concurrently with
normal system operation.
by the way, 99.95% uptime is for the entire period of operation. we had
99.996% uptime until the backup operator failed to call me while I was at
the Lisp Conforence, mistakenly thinking that my sleep was more important
than getting the system back on track -- unfortunately, I don't know what
caused this problem. it could have been that Emacs got problems with the
way it stupidly fails to close X connections after the last frame on a
display is closed -- Emacs gets seriously confused when a remote X server
goes down. other than this fairly major incident, the downtime has been
the time it has taken to correct a problem when some process invoked the
Allegro CL debugger due to some simple coding mistakes or some unexpected
problems with the input from one of the many clients we talk to. even
with outright bugs that would have terminated any other application,
recovery has taken a few minutes at worst. thus, we have extremely fine-
grained control over the failure modes, and the excellent multiprocessing
debugging environment in Allegro CL makes it possible to survive almost
all kinds of problems.
the source of several small downtime incidents has actually been isolated
to a problem in Linux: select(2) spuriously returns, lying that a socket
in listen(2) mode would not block on an accept(2) call. (it lies in
other situations, too, but they are much less of a "permanent block".)
figuring out which socket to connect to to unblock it falls in the "life
is too long to know this stuff well" category. the solution was a second
call to select(2) with that socket, only, and ignoring failed ACCEPT-
-CONNECTION calls. what's really interesting here is that I get _way_
more control over low-level issues like this in Allegro CL than I would
have done in C, as I would have to _build_ an abstraction/protection
layer on top of the "standard" socket interface in C to get the ability
to make small changes to it -- and Allegro CL already has that, so it was
merely a matter of tweaking the existing "abstractive layer".
#:Erik
--
if people came with documentation, could men get the womanual?
* Andi Kleen <·····@muc.de>
| This happens when an connection attempt arrives, but it gets removed
| again before the program accepts it - this happens e.g. when an ICMP
| packet arrives exactly in the right window.
this doesn't make sense as you explain it. could you be more specific?
(assume that I know all the protocol specs by heart, actually helped
write the Internet Host Requirements RFCs, and sometimes do network
debugging for a living.) I don't see how you are supposed to be able to
"remove" a connection attempt (by which I assume you mean a TCP SYN) and
presumably _before_ the SYN ACK can see a RST from the other end. which
type of ICMP packet do you mean could interfere here?
| if an application cannot accept any blocking it is supposed to set the
| listening socket to non blocking mode first, then the accept'ed sockets
| will be non blocking too and return EAGAIN when the connection
| disappeared. The application has to handle this inherent race by
| retrying.
this scenario seems extremely unlikely to cause blocking calls. yet it
happens. with both TCP logs and ICMP logs on the system in question,
select returns an apparently random fd from either the input or output
set without evidence of activity. in the test case where this has
happened to me, the machine does _nothing_ apart from waiting for
connections on 64 sockets, input on 64 sockets, and output on 64 sockets.
there is _no_ activity that should trigger and make select return, yet it
does, and there is, invariably, nothing there. the network only has the
usual background noises, to which it does not seem to relate in any way.
| In what other situations do you think does select "lie" too?
it has lied to me about write not blocking on sockets. just today, I had
to shut down the whole application and restart it because we couldn't
wait for my finding the bug during production hours. uptime requirements
are extremely tight. we were down for 3 minutes, and during that time,
all of nine people had been yanked out of whatever concentration the have
left and asked to participate in fixing the problem.
the problem is actually two-fold: select is used a number of fds, but
when a false positive is returned, due to system internals, it keeps
retrying on only the one that failed for a while before giving up on it,
and returning to normal operation. sometimes, it doesn't give up. I
have looked over the Allegro CL code and I can find no fault with it.
I have coded around this by asking select if he lied about the return
value, and if it doesn't confirm the return value, I ignore it and retry.
(I have replaced the functions FILESYS-WRITE-BYTES and -STRING, and
FILESYS-READ-BYTES and -BUFFER.) I have found _nothing_ to support any
theory of external influences of any kind, although I'm sure there's
_something_, like a clock ticking or some other apparently-innocuous
element. I wish I understood what's going on, but I have stopped my
research at select, and have coded around select, and that appears to
remove the problem, for whatever reason. if and when I have more time,
I'd like to dig even deeper, but this has already cost us some delays and
I have some catching up and some code cleanup to do.
#:Erik
* Andi Kleen <·····@muc.de>
| Sorry, I meant RST instead of ICMP of course.
OK.
| There are possible scenarios, e.g. when the final ACK is delayed, the
| SYN-ACK is retransmitted, RST is send for the SYN-ACK, SYN-ACK arrives in
| between and select succeeds, RST arrives, application calls accept.
yup, but these abnormal cases were all handled correctly, and we still
got bogus return values from select.
| Do multiple processes/threads write to this socket?
there's only one Linux process/thread, but within the Allegro CL process,
multiple Lisp processes talk to these sockets. however, only one process
does listen, read, or write on any given socket at any given time.
(separate Lisp processes take care of input and output, though.)
| One common bug that may cause it is that Linux select differes from BSD
| select in a critical point: Linux select modifies the passed timeval to
| the time left after select finished, BSD leaves it alone. A lot of
| applications forget to reinitialize the timeout before every select call
| in their main loop. You can check for this situation simply with strace.
| Of course there should be no bit set then in the output fd_sets in this
| case.
yes, this possibility has been investigated (with strace as you suggest)
and found not to apply. timeouts cause the sets to be cleared on return,
as expected. the error does _not_ occur while tracing -- the system has
to be quiet in some weird way for this to happen. that's why it took so
long to figure it out, and while I'm not sure select is the real culprit
and I may only have cured a symptom.
while I would appreciate any help in this matter, I also feel somewhat
exhausted by it and I'm unhappy to go over the details yet again. it
also doesn't appear to be comp.lang.lisp material. when I feel up to it,
and I'm able to reproduce it consistently, whatever that means in a case
like this, I'll try and work with both Franz Inc and Linux developers to
see how these things interact so unreliably.
I regret that I'm not at liberty to share the code modified code with
other than Allegro CL licensees, and I'm letting Franz Inc engineers take
care of any other customers who might report similar problems. at least
we know that this can happen and we know a way that appears to circumvent
the problem that doesn't break when the real cause is found.
I've said this before, but one of the more bizarre things about this
whole experience is that I have _more_ low-level control over things in
Allegro CL than I would have in C. in C I can trace the system calls,
but in Allegro CL I can trace nigh everything, and peeking under the hood
has never been easier. this did come as somewhat of a revelation to me.
#:Erik
rusty craine wrote:
-- snip --
> As I said in my first posting to this NG....lisp on the other end of
> things that is small, fast, low-level has a place in the world.
> Controlls machines, electornics, and communications. If you have ever
> made little machines go with Forth we will love doing it with
> lisp.....
I've never heard of lisp being described as small or fast before:)
Maybe it can _seem_ fast on modern (fast) CPUs though. However, to
compare its "smallness" and "fastness" with Forth is like comparing...
OK so I can't think of a good analogy... I'm sure both Forth and lisp
can do the same things... but so can a Turing machine.
However, I remember something about "the right tool for the job."
How small and fast can you make your "small, fast" lisp? My cuurent
Forth environment is a 68HC11 with an 8K (ROMed) Forth and 2K RAM.
Can your "small" lisp fit into such an environment?
> you can maintain your code, remember what a piece of code does
> and how it does it. If you don't have a little machine, well get
> one and muLisp. Beats the hell out of tring to develope personal-
> ities online.
-- snip --
> muLisp a machine and smile
> rusty
I'm looking forward to trying muLisp on my DOS box and compare its
smallnes and speed to Pygmy Forth:)
With best wishes,
Ken
Ken Deboy <······@locked_and_loaded.reno.nv.us> writes:
>
> I've never heard of lisp being described as small or fast before:)
> Maybe it can _seem_ fast on modern (fast) CPUs though. However, to
> compare its "smallness" and "fastness" with Forth is like comparing...
> OK so I can't think of a good analogy... I'm sure both Forth and lisp
> can do the same things... but so can a Turing machine.
>
Actually I think Lisp and Forth have a lot in common in the mind-set
area. Programming in each is a matter of extending the language; both
languages are designed to make that easy and both even tend to be
implemented that way.
For those who've never read the Forth newsgroups, I think it'd be
interesting to do so for the perspective it gives on another language
that has much the same philosophy as Lisp though the realization of
that philosophy is wildly different.
--
Fred Gilham gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
From: rusty craine
Subject: Re: Forth and Lisp (was Re: Politeness and language growth)
Date:
Message-ID: <368F68FD.897EACC@flash.net>
Fred Gilham wrote:
> Ken Deboy <······@locked_and_loaded.reno.nv.us> writes:
>
> >
>
> > can do the same things... but so can a Turing machine.
> >
> [snip]
> Actually I think Lisp and Forth have a lot in common in the mind-set
> area. Programming in each is a matter of extending the language; both
> languages are designed to make that easy and both even tend to be
> implemented that way.
> [snip]
>
> Forth is a very powerful language. muLisp's 16 bit program can't compare
> with forth's size, it runs about 50k. As for the right tool for the right
> job....well muLisp has a set of functions that let you program at a very low
> levels (interrupts, registers, segments etc). I have included a very simple
> program that illustrates one of them MEMORY [address,value,flag] (if value is
> not nil, value is writen to address, if flag is not nil it handles word's if
> nil bytes)
I use the parallel port to controll stepper motors (from old disk drives etc).
This program tells you what parallel ports the computer has. _I_ find lisp
programs interface the machine, computer, and programmer well. _I_ find forth
programs not as programmer friendly as lisp but I have seen forth used by
programmers more apt at the language and was very impressed. To me MEMORY is
much more descriptive than "!" and "." (i think those are store and fetch but
maybe i've forgetten).
Rusty
> .
> ;;;muLisp 16 bit program for DOS to locate parallel ports
> ;;;address stored as follows
> ;
> ;;;; -----------------------------------------------
> ;;;;| 408 | 409 | 40a | 40b | 40c | 40d |
> ;;;;-------------------------------------------------
> ;;;;| lpt1 | lpt2 | lpt3 |
> ;;;;-------------------------------------------------
> ;;;;| low | high | low | high | low | high |
> ;;;;| byte | byte | byte | byte | byte | byte |
> ;;;; -----------------------------------------------
> ;
> ;;; 00 00 will retrun if lpt port not present
> ;
> (setq *read-base* 16 *print-base* 16)
> ;
> (defun parallel-ports-available ()
> (setq lpt1-low (memory 408))
> (setq lpt1-high (memory 409))
> (setq lpt2-low (memory 40a))
> (setq lpt2-high (memory 40b))
> (setq lpt3-low (memory 40c))
> (setq lpt3-high (memory 40d))
> (if (and (= 00 lpt1-low) (= 00 lpt1-high))
> (print "LPT1 IS NOT PRESENT")
> (print "LPT1 IS PRESENT"))
> (if (and (= 00 lpt2-low) (= 00 lpt2-high))
> (print "LPT2 IS NOT PRESENT")
> (print "LPT2 IS PRESENT"))
> (if (and (= 00 lpt3-low) (= 00 lpt3-high))
> (print "LPT3 IS NOT PRESENT")
> (print "LPT3 IS PRESENT")))
>
William Barnett-Lewis wrote:
> I have sat here and wondered over a longish time why Lisp is dying a slow
> death and yet ST-80 holds, at least, steady. This is, I think, because it
> is like getting a frikking tooth pulled to get an answer out of anyone
> other than Barry or a certain former member of harlequin.
...
> More than anyone else here, this message is to you, Erik, because you are
> the day to day expression of everything that is wrong with C.L.L.
I have seen Erik answer *plenty* of questions here. If your
diagnosis were "Lisp people are rude" then I'd understand
that last sentence, but refusal to give information doesn't
seem to me to be among Erik's faults.
(Incidentally, a quick DejaNews trawl doesn't reveal *any* Lisp
questions from you since 1995. I'm puzzled.)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
In article <·································@news.binc.net>,
William Barnett-Lewis <······@mailbag.com> wrote:
>
>I have sat here and wondered over a longish time why Lisp is dying a slow
>death and yet ST-80 holds, at least, steady. This is, I think, because it
>is like getting a frikking tooth pulled to get an answer out of anyone
>
Having had various forms of dental work, I'd say that getting a useful
answer here is more like, say, flossing.
>More than anyone else here, this message is to you, Erik, because you are
>the day to day expression of everything that is wrong with C.L.L.
>
Erik is very free with his knowledge and opinions. I don't necessarily
agree with his opinions, but he is a useful member of this group.
Have you ever hung around comp.lang.perl.misc? Last time I was there,
the civility level of certain experts was somewhere in the Erik
category, and none of the experts answered a question I was asking.
By your reasoning, Perl should be as dead as Autocoder by now.
Instead, it seems to be more popular than Common Lisp (no accounting
for taste, I guess). For that matter, what's ST80 or Squeak,
and are they or it or whatever really more used than Lisp?
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
In article <····················@ptah.visi.com>,
David Thornley <········@visi.com> wrote:
...
>for taste, I guess). For that matter, what's ST80 or Squeak,
>and are they or it or whatever really more used than Lisp?
ST80 -- SmallTalk 80 ( from whom these days? it keeps changing.
There is also the IBM VisuageAge product. )
Squeak -- A highly portable (virtual machine ), "self contained", and
"open source" Smalltak implementation initially created by
Alan Kay et. al. at Apple. Luckily "freed" before the
Apple's R&D was "steved".
http://squeak.cs.uiuc.edu/
There seems to be a healthy market for software developed in SmallTalk.
Relative to Java and C++ I'd say Lisp and Smalltalk were in aproximately the
same status. Smalltalk, being OO, slightly higher in terms in
favorable hype factor.
[ CLOS is "strange" to most initiated in OO. For example UML doesn't
exactly map onto CLOS like the more "popular" OO languages.
Thereby can't float on the hype factor as well. ]
[ a "healthy market" is one in which vibrant enough to be self sustaining.
Not necessarily showing double digit growth, plastered on the
front page of trade journals, and/or filling you local newspaper's
want ads. ]
--
Lyman S. Taylor "I'm a Doctor! Not a commando."
(·····@cc.gatech.edu) The enhanced EMH Doctor in a ST:Voyager epidsode.