A Gentle proposal: Coup d'etat
JShr...@gmail.com
be formed to create a neolisp sublanguage -- a sanctioned set of
add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe
for obvious reasons.) I tend to agree with those who think that this
needs to be done in public by a semi-formal elected committee. But I'm
not much for talk. Therefore, I propose that we simply form the
committee and start putting together the addons. What would have to
happen is:
1. Create a sourceforge project. (I already have one that we could
co-opt temporarily).
2. Elect the committee who create a charter.
3. Create a web site. (I run a server that we can use for free
temporarily.)
4. Create a process, like the Python PEP process for proposal to be
considered.
5. Do it.
#2 seems to be the most problematic, so I propose the following
process:
2a. We set a target number of members, say 5. (Of course, anyone can
help,
but there needs to be a reasonable non-even voting block to make
decisions.)
2b. Anyone wishing to become a member write a short self-promoting
note.
2c. There is a period of voting through email to me.
2d. I'll tally the vote. (Anyone who has stood for election can review
the raw vote email trail.)
2e. The top n (default 5) win.
2f. Those 5 worry themselves about the charter, which will presumably
include how to change membership, etc.
I'll start setting up the web site, and those wishing to stand for
election should register with me (just send me email), including
writing your self-promoting bio (1000 word limit, please) by the end of
this month.
The vote will take place for one week (7 days) beginning on May 1. We
will begin the development effort mid-May.
Cheers,
'Jeff
Zach Beane
> I'll start setting up the web site,
Excellent! The hardest part already out of the way!
Zach
C Y
JShr...@gmail.com wrote:
> It has been repeatedly and voluminously proposed that a cadre or cabal
> be formed to create a neolisp sublanguage -- a sanctioned set of
> add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe
> for obvious reasons.) I tend to agree with those who think that this
> needs to be done in public by a semi-formal elected committee. But I'm
> not much for talk. Therefore, I propose that we simply form the
> committee and start putting together the addons.
Just for the enlightenment of the clueless, what happened to this
effort? http://clrfi.alu.org/
I'd agree we need something like this (I suppose I'm part of the
voluminous proposals you refer to) but it needs to be well structured,
well organized, and have the active support of enough of the Lisp
community to have moral authority. Probably the best way is to create
good proposals. Also, perhaps the commercial Lisp vendors would have
some interest in such a process, as well as the resources to do high
quality work?
funkyj
> It has been repeatedly and voluminously proposed that a cadre or cabal
> be formed to create a neolisp sublanguage -- a sanctioned set of
> add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe
> for obvious reasons.) I tend to agree with those who think that this
> needs to be done in public by a semi-formal elected committee.
Most wildly successful open source projects have a BDFL (benevolent
dictator for life) that keeps things focused and moving forward at a
good speed. You don't elect a BDFL, he emerges because he is doing
something so kick ass that others want to be a part of it.
While popular, the term BFDL is really a misnomer. It would be more
accurate to call Linus, Larry, Guido et. al. prophets rather than
BFDLs. Any Joe can climb to the top of a hill and preach a sermon.
When a true prophet preaches, people gather round. People begin to
follow. If the leader loses his chops then folks lose interest and
move on.
Of course in the technical realm, "preaching" means creating useful
working code.
If you yourself are not a prophet and you can't find a prophet you want
to follow then you need to learn to make due with the status quo (e.g.
pick a CL implementation) and get on with your own work.
Pascal Bourguignon
> Just for the enlightenment of the clueless, what happened to this
> effort? http://clrfi.alu.org/
Some people took the CLRFI idea and tried to define a process which
would give them work, which they didn't do, so the process stopped.
In my opinion, in this time of web and wiki, the CLRFI could just be
posted and commented in cliki.net, without a need for a central
"authority", at least until some momentum is gained and resources
agregated.
For example, useful libraries like CFFI could be posted as a CLRFI.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
JShr...@gmail.com
in church and pray for the nth coming ... Oh, and to dis any proposal
to organize the community into collective action. Forgive me... (What
page were we on in the hymnal?)
Ken Tilton
JShr...@gmail.com wrote:
> Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around
> in church and pray for the nth coming ...
No, we agreed to go write code. You made the mistake of listening to
Yegge and Garret and wanted to...
> Oh, and to dis any proposal
> to organize the community into collective action.
...form a committee? Paging Scott Adams.
ken (hoping you go write some code, not wallow in self-pity)
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Bob Felts
> Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around
> in church and pray for the nth coming ...
Heretic! We are to pray for the elt coming... You nth'ers have
everything backwards, you know!
> Oh, and to dis any proposal to organize the community into collective
> action. Forgive me... (What page were we on in the hymnal?)
You were on page 36 and in the wrong book.
(My apologies to everyone... I'm going back to learning and immensely
enjoying Lisp, warts and all.)
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
Bill Atkins
That's an interesting perspective. An individual with no obvious
credentials comes along and proposes to do something that's been done
in the past to little avail (cf. CLRFI) and which, in the minds of
many Lispers, may or may not even be a worthwhile goal. The community
largely ignores this individual and somehow this is proof that there
is something deeply wrong with the Lisp community. Go away.
Christophe Rhodes
> For example, useful libraries like CFFI could be posted as a CLRFI.
They could, but I think that this would be a bad idea: libraries like
CFFI are unstable in the sense that their interface is changing as new
requirements are being discovered. What might make more sense to
submit as a CLRFI is some interface to the low-level operations that
CFFI uses to implement itself: operators dealing with things like C
pointers, pinning vectors against being moved by garbage collectors,
and similar. Bonus points if these operators are required by more
than one 'userspace' library, so that one can judge the semantics
needed against more than one use case.
Christophe
Sacha
"Bill Atkins" <NOatki...@rpi.edu> wrote in message
news:87k69mj...@rpi.edu...
On one hand we have a community that agrees about the lack of standard
for threads, gui, sockets and whatnot...
On the other hand we have people that agree about the standard being pretty
good
as it is and frankly quite big already.
It seems obvious that a standard library is the solution that will fit
both views.
Sacha
JShr...@gmail.com
First off, if you think that I don't write code, you clearly have no
idea who you are talking to (which I guess is possible, but would be
unfortunate). We all write code (most of us, anyway) or we would be
reading rec.poker, or some such thing. So let's get it clear from the
start: You write code. I write code. Possibly even Bill Atkins writes
code (although no one seems to have taught him manners or, like you, to
figure out who you are conversing with before telling them in public to
go to hell).
Writing code is NOT what is needed now; Code abounds. What is needed is
not more code but buy-in from the community to a process for adopting
the best code into a new standard package. By "Buy-in" I mean at least
the help and blessings of the community -- having the community elect
the people to do the organizing is the only way I know to get this. But
"buy in" could also mean money to support the process -- possibly
paying some of the people who do the work. And by "process" I mean
people who will do the work (and possibly get paid for it).
I therefore hereby publicly offer $10,000 (in addition to my volunteer
help) to support the process if it involves duly elected (by YOU ALL --
NOT BY ME!) representatives of the community who have a charter and
process by which to produce a public open source standard add-on
package for Common Lisp. And I hope for my 10 grand to see an elected
committee and a package produced within a year from when I write the
check. These folks can choose to pay themselves with my money, and
hopefully with other community support as well.
[Note that I don't expect to be a paid part of this process -- I don't
have high enough profile in the community to expect to be elected to
the CADRe I have proposed -- and I probably shouldn't be as there many
better Lisp programmers around here than me (and, from the amount of
talk on this board, they all have more time than I do -- I'm too busy
writing code! :-) I expect only to help as I can and as needed.]
Okay, Ken, and everyone else. Put your money where your mouth is.
Ken Tilton
JShr...@gmail.com wrote:
> This is exactly wrong.
>
> First off, if you think that I don't write code, you clearly have no
> idea who you are talking to (which I guess is possible, but would be
> unfortunate).
Nope. Never noticed you until you snapped like a twig when the whole
world did throw themselves at your feet. Get used to it because you are
so exactly wrong: about two people on c.l.l write code.
> We all write code (most of us, anyway) or we would be
> reading rec.poker, or some such thing. So let's get it clear from the
> start: You write code. I write code. Possibly even Bill Atkins writes
> code (although no one seems to have taught him manners or, like you, to
> figure out who you are conversing with before telling them in public to
> go to hell).
Aw, jeez, this is Usenet. Get over it.
>
> Okay, Ken, and everyone else. Put your money where your mouth is.
>
$10k? Very impressive. Good for you. LispNYC is about to waste $4500 on
something related. Ron Garret is looking for a place to spend his
fortune. Maybe you all should talk. You and Ron on a committee should do
great.
As for my Incredibly Shrinking money is committed to keeping me alive
until I can ship a "Win Big With Lisp". That means I am writing code,
btw, some of which is a universal CL GUI. Eat your heart out. :)
ken
funkyj
You miss my meaning. Yes, I write code. I also cook, but no one would
confuse the crap that comes out of my kitchen with the works of art
that Thomas Keller produces at the French Laundry.
Likewise, while I do write code for a living, my technical chops don't
compare to Linus, Guido, Larry or Theo. It is not enough to write
code. You must create an awesome product with that code. Not a
mediocre product. Not a good product. An awesome product.
CLISP and SBCL are pretty good but apparently not good enough to take
over the evolution of the CL world like GCC did for the open source
C/C++ space.
> Writing code is NOT what is needed now; Code abounds. What is needed is
> not more code but buy-in from the community to a process for adopting
> the best code into a new standard package.
I agree that buy in is key. Where we differ is how to get buy in.
Forming yet another committee is not an effective way to get buy in
(IMESHO).
> I therefore hereby publicly offer $10,000 (in addition to my volunteer
> help) to support the process if it involves duly elected (by YOU ALL --
> NOT BY ME!) representatives of the community who have a charter and
> process by which to produce a public open source standard add-on
> package for Common Lisp.
I commend your fiscal commitment but trying to hire someone else to be
inspired is not effective. If you yourself don't have a plan for
exactly what you want to do then I doubt you will be effective in
hiring others to come up with the plan to improve lisp.
Of course I remember back in 1991 a schoolmate told me about this
exciting new operating system linux that was much better than minux and
would be as good as SunOS soon. I was skeptical that a bunch of
hobbyists could produce a professional grade OS. I could not have been
more wrong...
Nothing would make me happier than to see you prove me wrong by jump
starting the growth and improvement of the Lisp community.
Good luck,
--fj
Tim Bradshaw
> They could, but I think that this would be a bad idea: libraries like
> CFFI are unstable in the sense that their interface is changing as new
> requirements are being discovered. What might make more sense to
> submit as a CLRFI is some interface to the low-level operations that
> CFFI uses to implement itself: operators dealing with things like C
> pointers, pinning vectors against being moved by garbage collectors,
> and similar. Bonus points if these operators are required by more
> than one 'userspace' library, so that one can judge the semantics
> needed against more than one use case.
I think the problem with that idea is that implementations will already
have these sorts of things, and they will all be different, and the
implementors will have a significant investment in how they do things
now (lots of working code) and won't want to change them, quite
reasonably. Specifying some thin standard wrapper around the various
extant implementations might be a good approach, but only if they are
similar enough that one or more is not unduly penalised. This matters
a lot for FFIs in particular of course - no one wants some standard
wrapper that causes enormous overhead when calling C code, on *some*
implementations.
So I think a higher-level standard interface would be a better idea.
But if CFFI is unstable then that's probably a good indication that the
time is not yet ripe for one.
Of course, there are things that could be done that aren't this hard.
For instance (just from looking at the CFFI-SYS manual and cringing):
how hard would some package-related standards be? It is about 10 years
past time that people started giving packages sensible names and it's
easy to just borrow what Java has done there (ORG.TFEB.UTILS for
instance, not UTILS). Then we want things like short names for
packages, and there are some fairly obvious things to do with that.
And all of this has the nice property that, though implementation
changes will be required, they will probably be very small ones, and
also not on any kind of critical performance path (really, you just
need a few hooks on which to hang the new DEFPACKAGE etc). Finally,
getting this done lets you construct variant CLs by package
manipulations of various kinds (for instance: one where the symbol you
get buy reading CL:DEFPACKAGE is not the common lisp DEFPACKAGE. So
something like this is perhaps a good jumping-off place.
(Of course, I happen to have done work implementing things that do all
this, which is why I'm mentioning it - there are probably other areas
which would pay off at least as well. In any case what I *don't* have
is a specification, I just have code. Still less do I have a
specification which might be acceptable to implementors.)
I'm not disagreeing with you by the way - at least not intentionally.
On the subject of BDFLs which came up in another branch of this thread.
All the mentioned BDFLs are for *implementations* not for standards.
Standards are very different things, and I'm not aware of any driven by
BDFLs. In many ways standards are *harder* than implementations,
because for them to be useful they need to be widely accepted, and that
requires social skills. Which is why the coup d'etat approach is not
likely to work for them.
Finally, the money issue. Writing code is something that people will do
for free (fools that they are), because it has an immediate payoff -
you have a problem, so you write something that makes the problem go
away. And then you can write a little bit more code and some more
problems go away - it's just drugs without the being-illegal bit
really. Writing standards, and doing all the political stuff involved
with them is a different issue: there is no immediate hit from solving
a problem, and you have to deal with a whole lot of social & political
stuff that most programmers find very painful, are really bad at and
avoid whenever they can. And writing good standards is also just hard
work, even without the human interaction aspects, requiring very good
command of language and so on. My guess is that very few standards are
written by people for free, and those that are will generally be thin
skins on an imlementation (like the python standard or something). No
one is going to work on POSIX for free for instance! And though the
original poster has mentioned money, I don't think he realises how
little it is, given that people with the skills to do standardisation
work also have the skills to earn a lot of money (all those social
skills turn out to matter).
--tim
JShr...@gmail.com
> ... though the original poster has mentioned money, I don't think
> he realises how little it is ...
Of course he relalizes how little it is. He didn't just offer the cash,
he challenged others to step up like he did. You don't have to give
$10,000 -- how about $1000? How about $500? How about $100?
Tayssir John Gabbour
> Of course he relalizes how little it is. He didn't just offer the cash,
> he challenged others to step up like he did. You don't have to give
> $10,000 -- how about $1000? How about $500? How about $100?
If the goal is newbie adoption, it sounds like there's a much easier
solution, based on work that's already been done for us by hard
workers. The canonical newbie distro can be LispBox. The nice website
can be built around it, with recommended, tested libs. Resources can be
applied to port things to Wintel and MacOS X.
If someone else thinks this is a bad approach, they can do something
else. A democratic process where people manage themselves.
And really, it seems more important to hear newbies talk, rather than
experienced Lisp users debate. Seems the newbies' problems are much
more humble than we think. Like being able to reliably install CLSQL
under Lispbox. (Which I kinda did yesterday, and had a big hiccup,
which would've turned off the casual newbie. I say "kinda" because I
didn't use Lispbox but did use asdf-extensions.lisp which I extracted
from Lispbox. That interacts badly with makefiles, requiring a
workaround; an issue I expect Lispbox users face.)
Tayssir
JShr...@gmail.com
> solution, based on work that's already been done for us by hard
> workers.
The goal isn't newbie adoption, but if it were, you'd be right, Lispbox
is good. Regardless, what you are in fact exactly right about is that
building and maintaining Lispbox is hard work done by hard workers, and
the guy/folks who does/do it need to pay his/their rent and
occasionally eat. As has been pointed out, $10,000 isn't much, but it's
something. I don't mean this in a nasty way, but I'll bet you and the
rest of the community aren't going to offer the Lispbox guy/folks a
dime for all his/their hard work, nor will you (that is, the community)
offer him/them, nor anyone else anything but a warm handshake for the
work involved in doing what it takes to keep Lisp alive. The open
source/freeware mentality has broken something deep in the world, and
it's killing Lisp, and probably lots of other good things. Companies
that build fantastic Lisp platforms can barely stay in business and
need to scratch for every dime to pay their hard-working engineers, and
the community is full of people who think that just because they write
and give away yet another crappy, partly working implementation of
variable persistence that they knocked off in their spare time, they
deserve to get excellent working software by the hard work of brilliant
people for free. Ugh.
(Sorry, TJG, this flame isn't directed at you -- just prompted by your
note.)
Erik Enge
> I don't mean this in a nasty way, but I'll bet you and the
> rest of the community aren't going to offer the Lispbox guy/folks a
> dime for all his/their hard work, nor will you (that is, the community)
> offer him/them, nor anyone else anything but a warm handshake for the
> work involved in doing what it takes to keep Lisp alive.
My reply may be besides your point but I'd like to offer, as a
data-point, that part of the community collectively gave $1123.09 to
common-lisp.net. If you look at the donors list you'll recognize some
of them as regular posters to this group. While it may not be much
money, the annual budget is only $900.
(Thanks everyone!)
Erik.
Ken Tilton
JShr...@gmail.com wrote:
>>If the goal is newbie adoption, it sounds like there's a much easier
>>solution, based on work that's already been done for us by hard
>>workers.
>
>
> The goal isn't newbie adoption, but if it were, you'd be right, Lispbox
> is good. Regardless, what you are in fact exactly right about is that
> building and maintaining Lispbox is hard work done by hard workers, and
> the guy/folks who does/do it need to pay his/their rent and
> occasionally eat. As has been pointed out, $10,000 isn't much, but it's
> something. I don't mean this in a nasty way, but I'll bet you and the
> rest of the community aren't going to offer the Lispbox guy/folks a
> dime for all his/their hard work, nor will you (that is, the community)
> offer him/them, nor anyone else anything but a warm handshake for the
> work involved in doing what it takes to keep Lisp alive. The open
> source/freeware mentality has broken something deep in the world, and
> it's killing Lisp, and probably lots of other good things.
Well, nothing is going to kill Lisp. What may get killed is people
trying to make money off commodity software, because they will be up
against free versions and it is hard to be better enough to justify
bucks. Especially when some people do not realize how much the rough
edges of "free" stuff costs them.
> Companies
> that build fantastic Lisp platforms can barely stay in business and
> need to scratch for every dime to pay their hard-working engineers,
Agreed. But look at CLisp. That sets the bar $$$ Lisps must clear by a
high enough margin to justify the $$$. And Lispworks sets the bar for
Franz in re runtime licensing. I mention only win32-portable Lisps
because commercial success kinda requires that.
As a Lisp entrepreneur myself I am of course rooting for the commercial
Lisp vendors, but am I supposed to treat them as charity cases and give
them revenue for no reason when I could be using cheaper alternatives
(assuming for the sake of argument that CLisp and LW do not fall into
the "expensive free" category).
Note, btw, that your $10k would be financing another knife in the
$$$Lisp back, since all they have to point to are add-ons like CAPI (LTk
and Cells-Gtk killed that advantage) and AllegroCache. And their
proprietary implementations of sockets and FFI (CFFI killed that) do a
little to lock in developers (not much, tho).
The answer is simple: vertical apps, not tools. It is time for the IT
community to stop creating tools (or trying to make money off them) and
start using them to solve problems in the real world. Paul Graham did
it. Orbitz did it. That is what I have been trying to do for seven years.
All aboard?
JShr...@gmail.com
You're right. It's already dead. (In the sense that it's stopped
evolving-- which is what this was all about to begin with.)
> What may get killed is people
> trying to make money off commodity software, because they will be up
> against free versions and it is hard to be better enough to justify
> bucks. Especially when some people do not realize how much the rough
> edges of "free" stuff costs them.
Amen to that!
> The answer is simple: vertical apps, not tools. It is time for the IT
> community to stop creating tools (or trying to make money off them) and
> start using them to solve problems in the real world. Paul Graham did
> it. Orbitz did it. That is what I have been trying to do for seven years.
>
> All aboard?
I would be, if you were right, but unfortunately, you're not. "Vertical
apps" is too simplistic a way of thinking about it. I work primarily in
biocomputing (which, btw, I do entirely in Lisp!) where freeware
vertical apps abound too, and thus the vertical app manufacturers are
scratching around just like the platform manufacturers in the IT world
are.
It's utterly amazing to me that the folks in the labs that I work with
will drop $50,000 without even thinking about it hard for an HPLC
machine that they'll use, maybe 10 times a year, but I have to beg them
for $1500 to buy the Lisp platform that I use to support every
biocomputing activity in the lab (which is a LOT, and a LOT more work
than the HPLC machine supports.)
The answer isn't vertical or horizontal or anything so simple, and it's
not real or virtual -- what I do for the biologists in my lab is as
real as what that HPLC machine does -- do I get paid for it? No. Can I
get them to pay for software licenses (vertical or horizontal)? No.
It's something like: "Do something that no one can replicate, and that
everyone needs, and charge for it." No one can replicate what an HPLC
machine does, but the biologists <i>believe</i> that they can replicate
what I do for them... with excel or something (which, of course, they
think is free because it <i>appears</i> to be free on the Stanford site
license). In fact, I (and a team of mostly volunteer, but paid when I
get pay them) engineers built them a lovely platform (entirely on Lisp)
with which to do their work... will they help pay for it at all? No.
Why? Well, because it's on the web, and it's just a web thing, and all
web things are just free, aren't they?
The world is all sooooooooooooo f'ed up with respect to software and
money that I just can't believe it...
Tayssir John Gabbour
> (Sorry, TJG, this flame isn't directed at you -- just prompted by your
> note.)
No problem. I personally feel the recent discussions here are almost
too objectionable and irrational to participate in, partly because I
don't think people are interested in listening to each other
(preferring debate rather than building something). While I may not
agree with your points, it's not a reason for aiming abuse at you.
> > If the goal is newbie adoption, it sounds like there's a much easier
> > solution, based on work that's already been done for us by hard
> > workers.
>
> The goal isn't newbie adoption, but if it were, you'd be right, Lispbox
> is good.
Hmm, what's your goal? I (and perhaps others) haven't understood you,
in that case.
> Regardless, what you are in fact exactly right about is that
> building and maintaining Lispbox is hard work done by hard workers, and
> the guy/folks who does/do it need to pay his/their rent and
> occasionally eat. As has been pointed out, $10,000 isn't much, but it's
> something. I don't mean this in a nasty way, but I'll bet you and the
> rest of the community aren't going to offer the Lispbox guy/folks a
> dime for all his/their hard work, nor will you (that is, the community)
> offer him/them, nor anyone else anything but a warm handshake for the
> work involved in doing what it takes to keep Lisp alive.
Yes, there isn't even much funding for the people working hard on vital
issues like environmental destruction and need for independent media,
is there? Still, we prioritize. Where money is effective, maybe we give
money. Where our skills as Lisp programmers are effective, maybe we
contribute in that manner.
Or not.
> The open
> source/freeware mentality has broken something deep in the world, and
> it's killing Lisp, and probably lots of other good things. Companies
> that build fantastic Lisp platforms can barely stay in business and
> need to scratch for every dime to pay their hard-working engineers, and
Such is our economic system... it does not support infinitely
reproduceable goods well.
> the community is full of people who think that just because they write
> and give away yet another crappy, partly working implementation of
> variable persistence that they knocked off in their spare time, they
> deserve to get excellent working software by the hard work of brilliant
> people for free. Ugh.
Which persistence libs are you critiquing? A serious critique sounds
interesting.
Tayssir
JShr...@gmail.com
> > > solution, based on work that's already been done for us by hard
> > > workers.
> > The goal isn't newbie adoption, but if it were, you'd be right, Lispbox
> > is good.
> Hmm, what's your goal? I (and perhaps others) haven't understood you,
> in that case.
It's having a systematic process through which the langauge -- by which
I mean the core language and the "standard library set" which amounts
to a distributed part of the language -- can be extended to encompass
modern needs and discoveries in order that professional work can be
done in it, and that we (professionals) can expect (and may have to
expect to support!) the continued growth of the language as new needs
and discoveries are discovered. The goal -- my goal, anyhow -- is to
retain professionals, and lead professionals to choose lisp for app
development over, say, Python, PERL, or Java or even C/C++ (although I
think that the latter serve a useful role in the world at the moment in
deep near-hardware development). I'm not just pissing this stuff: I
program in Lisp every single day of the week, and have to nearly 30
years. I do absolutely everything in Lisp (except, as above,
near-hardware stuff, and in many cases I do that with Lisp-based
macros!) I've written god knows how much code, and published over 50
peer-reviewed professional papers most of who's contents is ENTIRELY
based on Lisp -- InterLisp, *Lisp, MacLisp, CMUCL (the origianl -- I
was at CMU!). But, you know, every time I need to dig around to find
something that is essentially standard in Python or Java, and end up
just writing it myself and hating it, I have to resist the urge to jump
ship myself. And it's not merely that the language doesn't have X or Y,
it's that there is no process by which X or Y could EVER become part of
the language (or standard libraries), and so I watch Python, Perl, C#,
and Java racing by while I'm yet-again writing my own dumb partial
implementation of something that should be standard in ANY MODERN
LANGUAGE. The language is like Latin. It's perfect for the Roman world.
And like Latin it's perfectly dead. So, to answer your quesiton: My
goals is not to attract newbies, it's to keep myself from breaking my
own heart by leaving the love of my life.
Tim Bradshaw
I don't think you realise who ill-conceived I think the idea is.
--tim
Jack Unrue
>
> It's having a systematic process through which the langauge -- by which
> I mean the core language and the "standard library set" which amounts
> to a distributed part of the language -- can be extended to encompass
> modern needs and discoveries in order that professional work can be
> done in it, and that we (professionals) can expect (and may have to
> expect to support!) the continued growth of the language as new needs
In my opinion, Common Lisp is caught in a catch-22. On the one hand,
the language and the standard library are not a commodity. Thus in
the marketplace for implementations and tools, customer lock-in is
still a viable business plan -- given all the parameters that go
into a decision of which implementation(s) to use, today the path
of least resistance given many permutations of those parameters is
to just go with a single vendor, and then it becomes very, very
hard to migrate to a different implementation. This situation is
facilitated in part by the spec that we have today (which we must
recognize is a product of not just a technical process, but also a
political process).
The vendors today have enough marketshare and remain healthy enough
as businesses that the bar for commoditization to take hold is too
high. The FOSS implementations are strong in their own right, but
not yet compelling enough to displace the commercial implementations.
And the commercial vendors see a relatively low potential ROI
in encouraging further standardization. So for all of these
reasons, the status quo remains. But I do think there is a
change occurring.
I do not in any way blame the commercial vendors for finding
strategies to earn revenue. I would be hard-pressed to come up
with better strategies, and I deeply respect the ability of these
companies to survive conditions that would have put lesser companies
out of business long ago. In other words, I don't have an
anti-commercial mindset. I'm just explaining my view as to
why a sanctioned standards process is a non-starter right
now.
So, my thinking is that Common Lisp can only evolve at this
point through ad hoc standards, with CFFI being the easiest
and most obvious example of an emerging ad hoc standard.
It's getting harder and harder to justify staying with
vendor-specific FFI. To my way of thinking, emerging ad hoc
standards are the most likely disruptive development that
could change the status quo.
Obviously I can't say where the tipping point is, but I do
believe that there is a tipping point where commoditization
can occur. That's where I see a sanctioned process coming
into play, and in my opinion a process like that would become
essential.
--
Jack Unrue
C Y
> Likewise, while I do write code for a living, my technical chops don't
> compare to Linus, Guido, Larry or Theo. It is not enough to write
> code. You must create an awesome product with that code. Not a
> mediocre product. Not a good product. An awesome product.
That's a VERY good point. Or at least, if the code isn't awesome, it
must do something no one ever thought to do before or is so hard to do
no one has done it nearly as well.
> CLISP and SBCL are pretty good but apparently not good enough to take
> over the evolution of the CL world like GCC did for the open source
> C/C++ space.
I may be wrong in this, but I think there is quite a bit of active
resistance to any one lisp enviornment becoming the de-facto standard
lisp. People seem to like the variety. I agree variety is good but it
must be tempered by agreement on vital points.
> > Writing code is NOT what is needed now; Code abounds. What is needed is
> > not more code but buy-in from the community to a process for adopting
> > the best code into a new standard package.
>
> I agree that buy in is key. Where we differ is how to get buy in.
> Forming yet another committee is not an effective way to get buy in
> (IMESHO).
True. I suspect there are only two ways this might actually come to
pass:
a) The situation gets so bad that both commercial and non-commercial
lisp folk agree on the vital necessity of updating the ANSI standard,
and take the steps needed to do so. I don't know what "bad enough" for
this to happen would be, but it would be bad.
b) A new spec is created that is good enough that everyone agrees it
would be silly not to adopt and follow it. This is almost as unlikely
and would be unofficial unless it gets sucked back into ANSI, but it
would be effective. I think this is more likely than a) however, which
is one reason I would like to see the status of dpANS3 cleared up. I
need to get back to that effort once I get enough time on my hands -
I'm not qualified to create a new spec from that but at least a clearly
Free dpANS3 might help make the conditions more favorable. However,
there seems to be very little interest in that side of things. To be
fair, I too am an unknown and not a logical person to propose such an
effort, so this is not very surprising.
> > I therefore hereby publicly offer $10,000 (in addition to my volunteer
> > help) to support the process if it involves duly elected (by YOU ALL --
> > NOT BY ME!) representatives of the community who have a charter and
> > process by which to produce a public open source standard add-on
> > package for Common Lisp.
>
> I commend your fiscal commitment but trying to hire someone else to be
> inspired is not effective. If you yourself don't have a plan for
> exactly what you want to do then I doubt you will be effective in
> hiring others to come up with the plan to improve lisp.
Pascal's idea of moving the CLRFI to cliki I think is a good one. Who
should kick that off? Anyone interested?
As for the use of a $10,000 kick start, I might have a suggestion
there. It would require a great deal of preliminary work and some
concrete, ready to include proposals for the standard.
Let's say we want the ANSI standard to continue being the "gold"
standard for Lisp. The big problem there, as far as I can tell, is
that the J13 doesn't have enough members to accomplish much and is
stuck in limbo. Well, it looks $10,000 might be enough to get a couple
of academic institutions onto the comittee for 1 year at least:
http://www.incits.org/meminfo.htm
So if "informal" work is done by the J13 member organizations and
academic institutions up until the point of near-readyness for
inclusion in ANSI, $10,000 might be enough to increase the J13
membership for a year to the point where effective updates could
happen. Admittedly I don't know all the details of J13 so there may be
reasons this would fail, but if it could succeed we could have an
updated ANSI standard again (at least for another few years).
Of course, the J13 members and some academic institutions would need to
be convinced to do the "behind the scenes" work, or at least polish up
work done by the community to "standards" levels, but it might help get
something to actually happen again.
Maybe no more practical than anything else suggested of late, but maybe
it will prompt a more useful idea.
Cheers,
CY
Cameron MacKinnon
>>>>If the goal is newbie adoption, it sounds like there's a much easier
>>>>solution, based on work that's already been done for us by hard
>>>>workers.
>>>
>>>The goal isn't newbie adoption, but if it were, you'd be right, Lispbox
>>>is good.
>>
>>Hmm, what's your goal? I (and perhaps others) haven't understood you,
>>in that case.
>
>
> It's having a systematic process through which the langauge -- by which
> I mean the core language and the "standard library set" which amounts
> to a distributed part of the language -- can be extended to encompass
> modern needs and discoveries in order that professional work can be
> done in it, and that we (professionals) can expect (and may have to
> expect to support!) the continued growth of the language as new needs
> and discoveries are discovered.
This is a great goal and I wish you luck, notwithstanding the constant
naysayers on this group who come up with the same tired non-logic and
whine for a specific example, then desparately attack it rather than
address the lack of process for change anywhere. I've lobbied for change
here in the past. Kent Pitman wanted to address it with his
Substandards, various luminaries tried again with CLRFI, and a few
former lurkers often come out in favour of progress every six months
when this issue comes up.
> The language is like Latin. It's perfect for the Roman world.
> And like Latin it's perfectly dead. So, to answer your quesiton: My
> goals is not to attract newbies, it's to keep myself from breaking my
> own heart by leaving the love of my life.
This is, unfortunately, not true. Latin is alive and well and has been
updated more recently than Common Lisp. Which just goes to show that if
you reduce change to absolute zero and hold it there long enough, even
the Roman Catholic Church will eventually speed by you.
http://www.economist.com/diversions/displayStory.cfm?story_id=2281926
Ken Tilton
JShr...@gmail.com wrote:
>>Well, nothing is going to kill Lisp.
>
>
> You're right. It's already dead. (In the sense that it's stopped
> evolving-- which is what this was all about to begin with.)
Lisp does need to evolve. is perfect. It was perfect in 1956. m-exprs
almost killed it, but they died a natural and early death because
s-exprs were perfect.
You guys have now been backed into a corner and freely confess that the
only thing missing is libraries that have, with the Internet, recently
become a big deal. And those libraries are not even missing. Every
implementation has them. So really, this is just about it being a little
annoying to develop a portable library, cuz you have to type #+this and
#-that all over the place.
But you cannot even complain about that! Last year Luis rounded out
James's CFFI and filled in one checkbox. This year LTk and Celtk rule
the portable gui roost, tho some prefer Cells-Gtk. Some of us who
Actually Code are talking about re-visiting cl-sockets. And so it goes...
>
>
>>What may get killed is people
>>trying to make money off commodity software, because they will be up
>>against free versions and it is hard to be better enough to justify
>>bucks. Especially when some people do not realize how much the rough
>>edges of "free" stuff costs them.
>
>
> Amen to that!
>
>
>>The answer is simple: vertical apps, not tools. It is time for the IT
>>community to stop creating tools (or trying to make money off them) and
>>start using them to solve problems in the real world. Paul Graham did
>>it. Orbitz did it. That is what I have been trying to do for seven years.
>>
>>All aboard?
>
>
> I would be, if you were right, but unfortunately, you're not. "Vertical
> apps" is too simplistic a way of thinking about it. I work primarily in
> biocomputing (which, btw, I do entirely in Lisp!) where freeware
> vertical apps abound too, and thus the vertical app manufacturers are
> scratching around just like the platform manufacturers in the IT world
> are.
yeah, there are some surprisingly vertical open source apps out there.
But I know of a few people who carved out handy little income streams by
going into (I will make this up so as not to attract more competition)
health club software. Started as an exercise for one health club
owner/friend who was going nuts with their crappy package. And believe
me, all that software out there for dedicated niches like that are crap
compared to what a solid Lisper with half a brain could do.
Lispniks just have to pull themselves away from c.l.l and go to more
cocktail parties or bars and listen to people cry about their systems.
This will usually be your better than average health club owner, because
they are smart enough to know things should be better. Then ask them if
they want a better system and a 5% royalty for a few hours analysis and
to serve as the alpha test site.
>
> It's utterly amazing to me that the folks in the labs that I work with
> will drop $50,000 without even thinking about it hard for an HPLC
> machine that they'll use, maybe 10 times a year, but I have to beg them
> for $1500 to buy the Lisp platform that I use to support every
> biocomputing activity in the lab (which is a LOT, and a LOT more work
> than the HPLC machine supports.)
>
> The answer isn't vertical or horizontal or anything so simple, and it's
> not real or virtual -- what I do for the biologists in my lab is as
> real as what that HPLC machine does -- do I get paid for it? No. Can I
> get them to pay for software licenses (vertical or horizontal)? No.
> It's something like: "Do something that no one can replicate, and that
> everyone needs, and charge for it." No one can replicate what an HPLC
> machine does, but the biologists <i>believe</i> that they can replicate
> what I do for them... with excel or something (which, of course, they
> think is free because it <i>appears</i> to be free on the Stanford site
> license). In fact, I (and a team of mostly volunteer, but paid when I
> get pay them) engineers built them a lovely platform (entirely on Lisp)
> with which to do their work... will they help pay for it at all? No.
> Why? Well, because it's on the web, and it's just a web thing, and all
> web things are just free, aren't they?
>
> The world is all sooooooooooooo f'ed up with respect to software and
> money that I just can't believe it...
>
I like the bit about the FBI using two of the same three vendors for the
next $1b they plan to sink into failed sofwtare. Don't get me started!
But that is why the key is retail sales, not megatools for corporations,
unis, or gov't. I only need to sell to a few percent of any given market
to catch up with Ron; it is OK if 97% of them are too dumb to know their
sofwtare sucks and use it because "everyone else does".
:)
bobbys...@gmail.com
>should kick that off? Anyone interested?
I can copy the whole website to CLiki if that is actually wanted.
Is it?
Might it not be better to just contact the CLRFI editors and see what
the deal is? Maybe start working on compiling the common functionality
of a few of the "Util libraries" (arnesi, kmrcl, etc) into a single
standard library(s) as a base case effort toward actually moving
forward with CLRFI? Or maybe something more directly useful like a
standard streams library based of the few (dozen) that are in existence
currently? If we can progress toward actually pushing through a few
RFI's as a community (hopefully with asdf-installable implementations),
maybe we can actually make a start on this.
In my (clueless?) opinion, maybe we should just spend a bit of time
actually organizing all of the code that is out there into standard,
crossplatform libraries. This is already happening for a few projects
CFFI, and Closer-MOP seem to have a good deal of community support.
But even with this, no one has gone so far as to actually make a
comprehensive list:
http://www.cliki.net/Current%20recommended%20libraries
http://www.cliki.net/Library
http://www.cliki.net/Categorized%20Libraries
Are three examples of a start on this each of which is missing some
fairly notable libraries.
http://common-lisp.net/projects.shtml
This is kindof useful except that they are not categorized and have no
descriptive text.
I get the impression from the rest of the thread that there is little
complaint with the idea of standard libraries so much as no one
actually wants to do it. Maybe the best approach would be to spend
some money hiring cheap collegiate labor to handle, reading library
docs, tagging the libraries, and organizing them somewhat sensibly.
This job could be relatively low paying, as it requires more
organizational prowess than technical (its wiki markup ).
Just my 2 cents,
Russ
Larry Elmore
>
>
> JShr...@gmail.com wrote:
>
>>> Well, nothing is going to kill Lisp.
>>
>>
>>
>> You're right. It's already dead. (In the sense that it's stopped
>> evolving-- which is what this was all about to begin with.)
>
>
> Lisp does need to evolve. is perfect. It was perfect in 1956. m-exprs
> almost killed it, but they died a natural and early death because
> s-exprs were perfect.
Dayyum, boy! You still using LISP 1.5? Oh wait, that was released in
1959 or '60. In fact, John McCarthy says he discovered Lisp in 1958.
Now I see how come you have the perfect Lisp -- you've got the imaginary
one that never was. Can you find some way to open-source it, or at
least publish a comprehensive description of the perfect 1956 Lisp? The
world awaits with bated breath.
--Larry
Ken Tilton
Here ya go, smart-ass:
> Early thoughts about a language that eventually became Lisp started in 1956 when John McCarthy
> attended the Dartmouth Summer Research Project on Arti cial Intelligence.
> http://www.cs.umbc.edu/331/resources/papers/Evolution-of-Lisp.pdf:
This must be terribly embarrassing for you.
funkyj
> funkyj wrote:
> > CLISP and SBCL are pretty good but apparently not good enough to take
> > over the evolution of the CL world like GCC did for the open source
> > C/C++ space.
>
> I may be wrong in this, but I think there is quite a bit of active
> resistance to any one lisp enviornment becoming the de-facto standard
> lisp. People seem to like the variety. I agree variety is good but it
> must be tempered by agreement on vital points.
Variety, BAH! I guarantee that if some billionaire stepped up and said
"I'm going to plonk down $100,000,000 to start a foundation that HIRES
and pays TOP DOLLAR to the best language developers out there so that
they will make <insert favorite open source lisp distro here> the best
programming environment ever" and followed through on that promise,
that distro (be it CLISP, SBCL, CMUCL or some other) would without a
doubt become the GCC of the lisp world.
People do not want variety, they want the best tool for the job. If
someone threw huge amounts of money at making your favorite open source
Lisp much much better the other distros would wither. Lisp isn't
magically different from C. Those C and C++ programmers who switched
to GCC did so because GCC became so much better than other free
compilers (due in equal parts to the FSF guidance and Cygwin putting
some commercial muscle behind GCC for several years).
The reason there is not one dominant free lisp distro is that none of
them is that much better than the others. Sure, CMUCL and SBCL are
faster than CLISP but I use CLISP because it is easy to install on
windows (just use the cygwin installer).
Just look at SLIME. Emacs has 'inferior-lisp' mode and that other one
I tried but now I can't even remember it's name but most everyone on
emacs uses SLIME because it is so much better.
Friedrich Dominicus
> People do not want variety, they want the best tool for the job.
And they use GCC because of that? Or maybe because they have no choice
at all? And because the GCC people keep everything undocumented?
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Rob Thorpe
> "funkyj" <fun...@gmail.com> writes:
>
> > People do not want variety, they want the best tool for the job.
> And they use GCC because of that? Or maybe because they have no choice
> at all?
A lot of people certainly did do it because there was little real
choice. I remember in 1999 if you wanted an open-source C++ compiler
GCC was really the only choice.
> And because the GCC people keep everything undocumented?
The amount of internal documentation of GCC is high, and most of it is
quite good. The free Lisp implementations are not as good in this
regard.
Still, what people want is quality implementations. If all free common
lisp implementations were great then no-one would care that there are
so many of them. Similarly if one of them was great few would care
that there is only one, though I for one would worry a bit. The problem
is that the existing implementations all have problems.
Timothy Moore
> was at CMU!). But, you know, every time I need to dig around to find
> something that is essentially standard in Python or Java, and end up
> just writing it myself and hating it, I have to resist the urge to jump
> ship myself. And it's not merely that the language doesn't have X or Y,
> it's that there is no process by which X or Y could EVER become part of
> the language (or standard libraries), and so I watch Python, Perl, C#,
> and Java racing by while I'm yet-again writing my own dumb partial
> implementation of something that should be standard in ANY MODERN
> LANGUAGE. [...]
If it is any good, why don't you post your code for X and Y on
your web site or create projects on common-lisp.net? It very well
could become part of the standard libraries in the same way that, I would
assert, asdf, cffi, clx and many others are now.
Tim
Pascal Bourguignon
> Variety, BAH! I guarantee that if some billionaire stepped up and said
> "I'm going to plonk down $100,000,000 to start a foundation that HIRES
> and pays TOP DOLLAR to the best language developers out there so that
> they will make <insert favorite open source lisp distro here> the best
> programming environment ever" and followed through on that promise,
> that distro (be it CLISP, SBCL, CMUCL or some other) would without a
And this very same implementation would be perfect to run both on my
PDA and on a 10,000 CPU cluster?
How many different versions of Allegro does Franz sell?
We could take all the free lisp implementations and call them by the
same name, eg: TOOCL (The Only One Common Lisp).
We'd have: TOOCL/python(*) option,
TOOCL/vm option,
TOOCL/xyz option, etc.
(*) python, the compiler, not the language.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Bill Atkins
> People do not want variety, they want the best tool for the job. If
"The job," unfortunately, encompasses a whole variety of different
situations.
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
funkyj
> "funkyj" <fun...@gmail.com> writes:
> > Variety, BAH! I guarantee that if some billionaire stepped up and said
> > "I'm going to plonk down $100,000,000 to start a foundation that HIRES
> > and pays TOP DOLLAR to the best language developers out there so that
> > they will make <insert favorite open source lisp distro here> the best
> > programming environment ever" and followed through on that promise,
> > that distro (be it CLISP, SBCL, CMUCL or some other) would without a
> > doubt become the GCC of the lisp world. [...]
>
> And this very same implementation would be perfect to run both on my
> PDA and on a 10,000 CPU cluster?
to make discussions easier lets call my hypothetical lisp foundation
SuperCL.
Probably not but it is very possible that something similar to the
linux world would develop. The is a workstation flavor of linux that
is very widely used and there are forked project for specialty
platforms like PDAs and giant clusters. Generally these specialty
versions of linux try only to change what is necessary to make linux
work well on their platform.
Also, I"m not saying that their wouldn't be specialty lisps for small
niches but that SuperCL would dominate the workstation open source lisp
market. It would also likely dominate the super computer and cluster
market.
Consider the various benchmark threads we've seen in this newsgroup.
If SuperCL was optimized so that it was faster than Java (e.g. the
cellular automata thread last month) and as fast as Ocaml (e.g.
harrop's ray tracing example), and had the following extensions:
* call/cc
* syntax case macros (not replacing CL macros but in addition to)
* <your favorite FFI>
* <your most wished for item here>
and worked well on these platforms:
* cygwin
* native Windows XP/NT
* linux
* mac
* BSD
Are you telling me you would use CLISP, CMUCL, SBCL or some other open
source lisp?
I"m mean sure, lots of people buy Oracle or DB2 but if you want a free
open source SQL you get mySQL. If you want a free web server you get
Apache. If either of these were merely "good", alternatives would
spring up. Because they kick ass people consider it a better use of
their time to contribute to these projects rather than start competing
projects.
Of course this discussion that I started about SuperCL is not very
useful as it is unlikely someone will decide to pour millions of
dollars into an open source lisp foundation as an act of charity.
There are plenty of other charity causes that would give the donor much
more emotional satisfaction for his $100 million. Don't let me waste
too much of your time :^)
> How many different versions of Allegro does Franz sell?
I dunno. As purely a newbie hobbyist I haven't ventured into the realm
of commercial lisp. You tell me, how many versions do they sell?
Joe Marshall
Ken Tilton wrote:
> The answer is simple: vertical apps, not tools.
Amen to that.
Pascal Bourguignon
> Are you telling me you would use CLISP, CMUCL, SBCL or some other open
> source lisp?
No, this not what I'm telling. What I'm telling, is that the offer
you'd get under one name SuperCL, you are getting it right now with
different names CLISP, CMUCL, SBCL, OpenMCL, etc.
There is the technical problem of defining interfaces between modules.
What we call COMMON-LISP and defines the interface between some
low-level modules called CLISP, CMUCL, etc, and the higher level
modules called "libraries", you'd still have to have it in a SuperCL
project.
For example, when you download the LispBox, you've got the choice of
the lowlevel module you want to use, and of the platform you want to
use. You get integrated into one LispBox name, an IDE, a couple of
libraries, some random implementation of the COMMON-LISP API, for some
random platform.
We already have the situation you want, only missing the name, and
being realistical, we don't have those $1e8 to pay the administrative
body to federate all the free hackers who are developing organically
this SuperCL without a name. The only thing we have, is a couple of
API definitions: COMMON-LISP, Closer-to-MOP, CFFI, etc, and this is
all we need, technically. Perhaps we need a new name for all?
http;//www.common-lisp.net is not a good name? Go create a
http://www.supercl.com name and make a SuperCL distribution!
If you want to compare the free CL situation with the Linux situation,
we could say that indeed we're like Linux, but just before the first
distribution: people have to download the kernel, and the GNU tools,
and to compile and integrate them themselves.
The LispBox is one first distribution.
(In the mean time, if you inherit some $1e8, don't hesitate to finance
us Lisp hacker to improve the modules needed to build a SuperCl
distribution ;-)
>> How many different versions of Allegro does Franz sell?
>
> I dunno. As purely a newbie hobbyist I haven't ventured into the realm
> of commercial lisp. You tell me, how many versions do they sell?
There's at least:
- Allegro CL 7.0 Student Edition
- Allegro CL 8.0 Professional Edition
- Allegro CL 8.0 Enterprise 32 Edition
- Allegro CL 8.0 Enterprise 64 Edition
- Allegro CL 8.0 Enterprise 64 Platinum Edition
- some more Add-On products (optional libraries!)
Each declined on several platforms.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
Larry Elmore
>
>
> Larry Elmore wrote:
>
>> Ken Tilton wrote:
>>
>>>
>>> JShr...@gmail.com wrote:
>>>
>>>
>>>>> Well, nothing is going to kill Lisp.
>>>>
>>>>
>>>>
>>>>
>>>> You're right. It's already dead. (In the sense that it's stopped
>>>> evolving-- which is what this was all about to begin with.)
>>>
>>>
>>>
>>> Lisp does need to evolve. is perfect. It was perfect in 1956. m-exprs
>>> almost killed it, but they died a natural and early death because
>>> s-exprs were perfect.
>>
>>
>>
>> Dayyum, boy! You still using LISP 1.5? Oh wait, that was released in
>> 1959 or '60. In fact, John McCarthy says he discovered Lisp in 1958.
>> Now I see how come you have the perfect Lisp -- you've got the imaginary
>> one that never was. Can you find some way to open-source it, or at
>> least publish a comprehensive description of the perfect 1956 Lisp? The
>> world awaits with bated breath.
>
>
> Here ya go, smart-ass:
>
>> Early thoughts about a language that eventually became Lisp started in
>> 1956 when John McCarthy
>> attended the Dartmouth Summer Research Project on Arti cial Intelligence.
>>
>> http://www.cs.umbc.edu/331/resources/papers/Evolution-of-Lisp.pdf:
>
>
> This must be terribly embarrassing for you.
Not at all, since you apparently don't even comprehend what you quoted.
By the way, you can be one of the proud owners of the world's first
perfect anti-gravity flying car, and not just the 4th or 5th generation
improved model, but the *perfect* model I started having thoughts about
last night as I was drifting off to sleep. Hell, the first prototype
won't even be *started on* for another two years! And it can be yours,
YOURS, *YOURS* for the low, LOW, *LOW* price of $49,995!!! (not
including shipping and handling, tax applicable in some states)
--Larry
Ken Tilton
Larry Elmore wrote:
> Ken Tilton wrote:
>
>>
>>Larry Elmore wrote:
>>
>>
>>>Ken Tilton wrote:
>>>
>>>
>>>>JShr...@gmail.com wrote:
>>>>
>>>>
>>>>
>>>>>>Well, nothing is going to kill Lisp.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>You're right. It's already dead. (In the sense that it's stopped
>>>>>evolving-- which is what this was all about to begin with.)
>>>>
>>>>
>>>>
>>>>Lisp does need to evolve. is perfect. It was perfect in 1956. m-exprs
>>>>almost killed it, but they died a natural and early death because
>>>>s-exprs were perfect.
>>>
>>>
>>>
>>>Dayyum, boy! You still using LISP 1.5? Oh wait, that was released in
>>>1959 or '60. In fact, John McCarthy says he discovered Lisp in 1958.
>>>Now I see how come you have the perfect Lisp -- you've got the imaginary
>>>one that never was. Can you find some way to open-source it, or at
>>>least publish a comprehensive description of the perfect 1956 Lisp? The
>>>world awaits with bated breath.
>>
>>
>>Here ya go, smart-ass:
>>
>>
>>>Early thoughts about a language that eventually became Lisp started in
>>>1956 when John McCarthy
>>>attended the Dartmouth Summer Research Project on Artificial Intelligence.
>>>
>>>http://www.cs.umbc.edu/331/resources/papers/Evolution-of-Lisp.pdf:
>>
>>
>>This must be terribly embarrassing for you.
>
>
> Not at all, since you apparently don't even comprehend what you quoted.
Oh, sorry, I thought it meant this:
"This paper concentrates on the development of the basic ideas and
distinguishes two periods - Summer 1956 through Summer 1958 when most of
the key ideas were developed...."
What ideas? I do not know, but those are the opening words of the
introduction to the "History of Lisp", 2/12/1979, by some guy named John
McCarthy.
Tip #1: Quit while you are behind.
Tip #2: Your attempts at humor are too heavy-handed. ease up on the
throttle a little. You have to leave some work for the audience.
Tip #3: When someone is standing on a chair waving a pint in the air
singing a eulogy to something, be it Lisp or the local football club,
well, no one likes a wise-ass. :)
peace, kenny
Larry Elmore
In other words, the "perfect Lisp" that you use is the one that existed
before any implementation work even started? All I can say is, "Wow, I
wish my meds were that good." :)
--Larry
Raffael Cavallaro
> All I can say is, "Wow, I
> wish my meds were that good." :)
That's what the pint is for ;^)
Larry Elmore
That explains it then. All I get are these diabetic meds with warnings
not to mix with alcohol. :-(
--Larry
kent...@gmail.com
/discovered/ Lisp in 1958.
kennj
Ken Tilton
Here is a seriously friendly tip: stop trying to be funny. The trying
really shows. Let humor happen or not.
best, kennj
Friedrich Dominicus
>
>> And because the GCC people keep everything undocumented?
>
> The amount of internal documentation of GCC is high, and most of it is
> quite good. The free Lisp implementations are not as good in this
> regard.
Ok, let's getting a bit more off-topic here. Tell me where to find an
actual documentation of the exception handling on AMD 64-but
machines.
>
>
> Still, what people want is quality implementations. If all free common
> lisp implementations were great then no-one would care that there are
> so many of them. Similarly if one of them was great few would care
> that there is only one, though I for one would worry a bit. The problem
> is that the existing implementations all have problems.
What problems? Name them, just writing "they all have problems" is as
unspecific as can be. I'm using SBCL for quite some time now have
compiled it over and over again and it mostly works. There are some
problems sometimes, but the same is true with GCC also.
Tagore Smith
cash,
> he challenged others to step up like he did. You don't have to give
> $10,000 -- how about $1000? How about $500? How about $100?
Hey, this is easy. Just get a PO box and...
"My name is Dave Rhodes, err, Common Lisp..."
Title it: "Introduce Misfeatures Fast". "For every appallingly wrong
idea you send out, you are _guaranteeed_ to receive 30,000 badly though
out "improvements". No longer will C++ lord it over you- you too can be
rich in botched semantics if you follow my advice. This program has
remained successful because of the unimpeachable, err, well, because
Larry Wall sits on our board. Please continue its success by CAREFULLY
ADHERING to the instructions."
Send the first copy to EN, just for fun.
Trust me- I've been in prison!
Stefan Scholl
> code (although no one seems to have taught him manners or, like you, to
> figure out who you are conversing with before telling them in public to
> go to hell).
Then use your name.
Rob Thorpe
> "Rob Thorpe" <robert...@antenova.com> writes:
>
> >
> >> And because the GCC people keep everything undocumented?
> >
> > The amount of internal documentation of GCC is high, and most of it is
> > quite good. The free Lisp implementations are not as good in this
> > regard.
> Ok, let's getting a bit more off-topic here. Tell me where to find an
> actual documentation of the exception handling on AMD 64-but
> machines.
:) I have no idea. For a slightly amusing slant on problems like these
read the thread "linux api" here
http://www.realworldtech.com/forums/index.cfm?action=forum&roomID=11
> > Still, what people want is quality implementations. If all free common
> > lisp implementations were great then no-one would care that there are
> > so many of them. Similarly if one of them was great few would care
> > that there is only one, though I for one would worry a bit. The problem
> > is that the existing implementations all have problems.
> What problems? Name them, just writing "they all have problems" is as
> unspecific as can be. I'm using SBCL for quite some time now have
> compiled it over and over again and it mostly works. There are some
> problems sometimes, but the same is true with GCC also.
Other current threads on c.l.l cover the topic quite well, amongst lots
of noise.