Interesting developments since "Beating the averages"?
Tin Gherdanarra
and was the seed crystal that put Lisp into the spotlight.
I noticed that Lisp moved from belittled fringe player
to radical chic since then. However, I'm under the impression
that not much has changed in terms of technology and
community efforts. Peter Seibel's admirable book and
promising current gardeners-project is the only exception,
but I might have missed something. If so, what? Maybe
it's too early to tell, but I don't have the feeling
that Lisp's handicaps have been alleviated since April 2001
when "Beating the averages" came out. But maybe I'm
wrong because I was looking at the wrong places.
Kenny Tilton
I think you need to list the handicaps you have in mind or it is a
little hard to answer your question. No standard FFI? sockets? GUI?
libraries in general? What? Anyway....
There has been some progress on those things, but your assessment is not
far off. The main thing that has changed is what you have observed, viz.
that Lisp mindshare has done a 180 degree turn and there is an exploding
grassroots thing going on. And that is where libraries come from, so
watch for things to change over the next couple of years.
btw, 4/2001 may be when BtA was published (taking your word for it) but
the grassroots boom did not get interesting until late 2005.
kenny
Cameron MacKinnon
http://phx.corporate-ir.net/phoenix.zhtml?c=62198&p=irol-newsArticle&ID=757976&highlight=
http://groups.google.com/group/comp.lang.lisp/msg/f7e44b6483c4f0fe
I think that Lisp's traditional strengths in symbol manipulation are
exactly the sort of thing which likely have received a lot of funding in
the last four and a half years,* but you'd have to look carefully for
evidence of this, as it isn't exactly being trumpeted from the rooftops.
Also, if you look at a five year chart of SUNW, you can see how well
Java has worked out as a 'save the company' strategy. Five years ago,
Python was the hot new thing. This year, it's Ruby. Not exactly
schadenfreude, but all that we need for success is that our competitors
continue to fail.
"...not much has changed in terms of technology and community efforts":
Well, my vote for best Lisp technology in the past five years would go
to SLIME. While it's certainly true that Lisp still has a way to go to
be more newbie friendly (standard TCP/IP & threads, better and more
standard graphics libraries, Cells documentation), I believe that Lisp's
stability is generally an advantage, in the sense that the core language
doesn't need the constant tweaking that you see in less mature languages.
Five years ago, our most comprehensive collection of libraries was
probably the old CMU AI repository. Things are improving.
* Assuming competence in the places where such decisions are made.
Tin Gherdanarra
>
>
> I think you need to list the handicaps you have in mind or it is a
> little hard to answer your question.
I think they know who they are. And so do you. Take no offense,
this helps saving bandwidth because there is no reason to
flame over the issues.
> No standard FFI? sockets? GUI?
> libraries in general? What? Anyway....
>
Argh! You said it!
> There has been some progress on those things, but your assessment is not
> far off.
This is exactly what I was afraid of.
> The main thing that has changed is what you have observed, viz.
> that Lisp mindshare has done a 180 degree turn and there is an exploding
> grassroots thing going on.
Yes. I like it. But it's fairly new.
> And that is where libraries come from, so
> watch for things to change over the next couple of years.
>
Mhm.
> btw, 4/2001 may be when BtA was published (taking your word for it) but
> the grassroots boom did not get interesting until late 2005.
The resonance was there in 2001. I think it was the first time Paul
Graham got slashdotted. I did not have usenet back then, but are there
any veterans who have noticed an increase in traffic since then? No
"September that never ended" on comp.lang.lisp? There are not very many
newbie-questions here right now -- this is open to all sorts of speculation.
Tin Gherdanarra
>
>
> http://phx.corporate-ir.net/phoenix.zhtml?c=62198&p=irol-newsArticle&ID=757976&highlight=
>
>
> http://groups.google.com/group/comp.lang.lisp/msg/f7e44b6483c4f0fe
>
> I think that Lisp's traditional strengths in symbol manipulation are
> exactly the sort of thing which likely have received a lot of funding in
> the last four and a half years,* but you'd have to look carefully for
> evidence of this, as it isn't exactly being trumpeted from the rooftops.
I'm not sure I understand what you are talking about, but if you
mean text mining and indexing, you are wrong. The companies I know
all use C++ and Java for this. They even use it for prototyping --
talk about beating the averages.
>
> Also, if you look at a five year chart of SUNW, you can see how well
> Java has worked out as a 'save the company' strategy. Five years ago,
> Python was the hot new thing.
... and failed because Zope turned out to be such a mess.
> This year, it's Ruby. Not exactly
> schadenfreude, but all that we need for success is that our competitors
> continue to fail.
The problem with hype is that it eventually ends. Then it becomes
post-cool and the object of affection is abandoned. Ruby and rails
are the next big razor-scooter. In this light, any premature Lisp-hype,
i.e. before any tangible results, is probably harmful.
>
> "...not much has changed in terms of technology and community efforts":
> Well, my vote for best Lisp technology in the past five years would go
> to SLIME. While it's certainly true that Lisp still has a way to go to
> be more newbie friendly (standard TCP/IP & threads, better and more
> standard graphics libraries, Cells documentation), I believe that Lisp's
> stability is generally an advantage, in the sense that the core language
> doesn't need the constant tweaking that you see in less mature languages.
>
I'm not sure if there isn't more to this. For one, there are all sorts
of research projects that use specialized Schemes as implementation
language because it is so easy to implement domain-specific langauges
(concurrent, linear, for various vms, etc.) In a way this IS "tweaking
the language". Then there are several
CL implementation with different focus -- these implementations all
adhere to the standard, but this external, independent standard
is exactly the problem because it gets in the way of blessing any
community-based module (like TCP/IP sockets and threads) as "the"
implementation and including it in the standard distribution. In
other words, Lisp lacks a benevolent dictator, and this is bad for
standardizing wheels in a pragmatic way.
> Five years ago, our most comprehensive collection of libraries was
> probably the old CMU AI repository. Things are improving.
What about CLiki? Most stuff over there has been sitting there longer
than that. Not much of progress there.
>
> * Assuming competence in the places where such decisions are made.
Never overestimate the competence of decisionmakers.
Frank Buss
> The resonance was there in 2001. I think it was the first time Paul
> Graham got slashdotted. I did not have usenet back then, but are there
> any veterans who have noticed an increase in traffic since then?
you can research at Microsoft:
http://netscan.research.microsoft.com/
before 2001 the average number of message per days were 30, after this
until today it was about 70.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Christophe Rhodes
> [ someone else, attribution snipped by "tinman31337": ]
>> Five years ago, our most comprehensive collection of libraries was
>> probably the old CMU AI repository. Things are improving.
>
> What about CLiki? Most stuff over there has been sitting there longer
> than that. Not much of progress there.
Feeding the troll is likely to be unproductive, but CLiki came into
being on May 29, 2000, so claims for "most stuff over there" having
been sitting there for longer than five years aren't just wrong,
they're foolishly wrong.
Christophe
Adam Connor
<cs...@cam.ac.uk> wrote:
>Feeding the troll is likely to be unproductive, but CLiki came into
>being on May 29, 2000, so claims for "most stuff over there" having
>been sitting there for longer than five years aren't just wrong,
>they're foolishly wrong.
Why do you assume trolling? Is it not possible to ask these questions
without being a troll?
--
adamnospamaustin.rr.com
s/nospam/c\./
Christophe Rhodes
Read the bit I quoted in the message you're responding to, and then
answer your own question. A (fortunately blatant, making it easier to
detect) falsehood is expressed as a fact and used as substantiating
evidence for the usual claim ("Lisp is dead") in slightly different
words. It is possible to ask this kind of question without being a
troll, but this case wasn't an example of such.
Christophe
jos...@corporate-world.lisp.de
> I'm not sure if there isn't more to this. For one, there are all sorts
> of research projects that use specialized Schemes as implementation
> language because it is so easy to implement domain-specific langauges
> (concurrent, linear, for various vms, etc.) In a way this IS "tweaking
> the language". Then there are several
> CL implementation with different focus -- these implementations all
> adhere to the standard, but this external, independent standard
> is exactly the problem because it gets in the way of blessing any
> community-based module (like TCP/IP sockets and threads) as "the"
> implementation and including it in the standard distribution. In
> other words, Lisp lacks a benevolent dictator, and this is bad for
> standardizing wheels in a pragmatic way.
Lisp does not need a 'benevolent dictator'. You may need one.
But then you can always join the Python community.
Tin Gherdanarra
Hm, I said that in good faith, so I ain't no troll. Appearantly
I'm victimized by a coincidence. Not before March 2002 I noticed
CLiki, and it made the impression of having been around for years.
How could I know that? And I remember finding lots of packages
like parser generators, all sorts of regex processors and the
like with only incremental additions over the years. So I might
be foolishly wrong, but I'm not a troll.
>
> Christophe
Tin Gherdanarra
Tin Gherdanarra
> Tin Gherdanarra schrieb:
>
> Lisp does not need a 'benevolent dictator'. You may need one.
This is a catchy sound-bite on my expense, but it misses
the point.
> But then you can always join the Python community.
You sound like a German redneck before 1989 telling
student protesters and "commies" to emigrate to the
GDR if they don't like it here. The python community
is where I'm from. Lisp has its virtues over python,
but there is no such thing as a "batteries included" for
Lisp, and most people here agree that this is a bad thing,
at least hampering wide-spread acceptance of the language.
I attribute this to the fact that there is no maintainer
of a single implementation (as with perl) who integrates
contributions into a distribution. The result is a
twisted little maze of little Lisps and slightly incompatible
wheels, as with Unix ca 1990. "Batteries included",
a default set of modules, is a strong incentive to adopt
the language. If you agree that Lisp is undervalued, than
you might or might not agree that fragmentation is the
problem and a central figure would have alleviated this.
Just stating that "Lisp does not need 'benevolent dictator'
is not gonna cut it. Why do you think that?
Tayssir John Gabbour
> >
> > btw, 4/2001 may be when BtA was published (taking your word for it) but
> > the grassroots boom did not get interesting until late 2005.
>
> The resonance was there in 2001. I think it was the first time Paul
> Graham got slashdotted. I did not have usenet back then, but are there
> any veterans who have noticed an increase in traffic since then? No
> "September that never ended" on comp.lang.lisp? There are not very many
> newbie-questions here right now -- this is open to all sorts of speculation.
<shrug> I'm sure you'll find your news on O'Reilly or Dr. Dobbs if Lisp
is getting to the point you want, or if some Benevolent Hitler starts
making efficient decisions.
Tayssir
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>>>btw, 4/2001 may be when BtA was published (taking your word for it) but
>>>the grassroots boom did not get interesting until late 2005.
>>
>>The resonance was there in 2001. I think it was the first time Paul
>>Graham got slashdotted. I did not have usenet back then, but are there
>>any veterans who have noticed an increase in traffic since then? No
>>"September that never ended" on comp.lang.lisp? There are not very many
>>newbie-questions here right now -- this is open to all sorts of speculation.
>
>
> <shrug> I'm sure you'll find your news on O'Reilly or Dr. Dobbs if Lisp
> is getting to the point you want,
I'm sure I will, but right now there are next to no Lisp
news on O'Reilly or Dr. Dobbs, so it might be a long way
to get there.
> or if some Benevolent Hitler starts
> making efficient decisions.
I'm not talking about making decisions, I'm talking
about integration and batteries included. Look at
this: http://docs.python.org/modindex.html
If anyone could get me such a thing for CL, I'd
vote NSDAP, politcal correctness be damned.
>
> Tayssir
>
Kenny Tilton
My tipoff that the OP is a troll is that it turned out they were not
really asking a question. They already have all the answers. And the
record for getting into my killfile fastest.
kenny
Tin Gherdanarra
I don't have any answers. I wouldn't be here if I had. I'm just
stating some assumptions in the expectation that they will be
affirmed or refuted. I thought this is an essential technique of
discourse. Please take me out of your killfile.
> kenny
Pascal Costanza
> jos...@corporate-world.lisp.de wrote:
>>
>> Lisp does not need a 'benevolent dictator'. You may need one.
>
> This is a catchy sound-bite on my expense, but it misses
> the point.
>
>> But then you can always join the Python community.
>
> You sound like a German redneck before 1989 telling
> student protesters and "commies" to emigrate to the
> GDR if they don't like it here. The python community
> is where I'm from. Lisp has its virtues over python,
> but there is no such thing as a "batteries included" for
> Lisp, and most people here agree that this is a bad thing,
> at least hampering wide-spread acceptance of the language.
I don't think that most people agree.
> I attribute this to the fact that there is no maintainer
> of a single implementation (as with perl) who integrates
> contributions into a distribution.
You make the same category error like most other people who have stated
similar things like you in the past. ANSI Common Lisp is a
specification, not an implementation. End of story.
Of course there are maintainers of single implementations. Each Common
Lisp implementation has at least one, and each Common Lisp
implementation comes with a far richer set of libraries than what is
specified in ANSI Common Lisp. Just go with the one that best suits your
needs.
Many people here agree that having a common specification is a good
thing. Many also agree that having more common de-facto standard
libraries is also a good things, and they are successfully working on
them. If you don't agree with them and prefer a single implementation,
there's noone stopping you from choosing exactly one implementation and
forgetting about the rest. So effectively, you have more choices than
the single implementation languages where you cannot choose to focus on
writing portable code against a spec, because such a spec doesn't exist
over there. Lisp is about having more freedom, not less.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>> jos...@corporate-world.lisp.de wrote:
>>
>>>
>>> Lisp does not need a 'benevolent dictator'. You may need one.
>>
>>
>> This is a catchy sound-bite on my expense, but it misses
>> the point.
>>
>>> But then you can always join the Python community.
>>
>>
>> You sound like a German redneck before 1989 telling
>> student protesters and "commies" to emigrate to the
>> GDR if they don't like it here. The python community
>> is where I'm from. Lisp has its virtues over python,
>> but there is no such thing as a "batteries included" for
>> Lisp, and most people here agree that this is a bad thing,
>> at least hampering wide-spread acceptance of the language.
>
>
> I don't think that most people agree.
>
>> I attribute this to the fact that there is no maintainer
>> of a single implementation (as with perl) who integrates
>> contributions into a distribution.
>
>
> You make the same category error like most other people who have stated
> similar things like you in the past. ANSI Common Lisp is a
> specification, not an implementation. End of story.
Yes. That's in contrast to perl and python that have no
specification, just an implementation that is some sort
of the borg assimilating modules, thus discouraging writing
another modules with overlapping function. Common Lisp does have a
specification, so there are various independent implementations
resultin in fragmentation.
>
> Of course there are maintainers of single implementations. Each Common
> Lisp implementation has at least one, and each Common Lisp
> implementation comes with a far richer set of libraries than what is
> specified in ANSI Common Lisp. Just go with the one that best suits your
> needs.
It's not just my needs. It's something like
import sockets
>
> Many people here agree that having a common specification is a good
> thing.
It IS a good thing, but there are some blanks and various attempts
to fill in the blanks. The standard was an attempt to unify various
successful Lisps in order to avoid duplication of effort in the
future and make Lisp more popular. This has not worked out so far.
Johnny-come-lately-languages entered the scene and easily slammed
Lisp against the wall because an entire community worked on each of
them. There was competition among various projects, but eventually
the best results got absorbed fairly early, thereby pruning off dead
ends.
> Many also agree that having more common de-facto standard
> libraries is also a good things, and they are successfully working on
> them. If you don't agree with them and prefer a single implementation,
> there's noone stopping you from choosing exactly one implementation and
> forgetting about the rest.
Not so fast. Choice and competing implementations precluded
Unix from becoming an OS monopoly. Things changed considerably when
Linus Torvalds hijacked the Minix community and a large part of
the community decided that it was a worthy project to invest into.
Don't you think that this is a good thing, too?
> So effectively, you have more choices than
> the single implementation languages where you cannot choose to focus on
> writing portable code against a spec, because such a spec doesn't exist
> over there.
A single implementation obsoletes the need for a specification.
Since Lisp began its career as a family of dialects, standardization
after the fact was necessary. perl, python or PHP never had this
problem.
> Lisp is about having more freedom, not less.
You are stating the obvious, but at this time it means freedom from
something as easy as
import sockets.
Actually, all I wanted to know was whether you guys notice
improvement in Lisp's mindshare and lower barrier to entry. And
now I'm sitting here, arguing over implementation vs. specification
and being called all sorts of things.
jos...@corporate-world.lisp.de
Tin Gherdanarra schrieb:
> jos...@corporate-world.lisp.de wrote:
> > Tin Gherdanarra schrieb:
>
> >
> > Lisp does not need a 'benevolent dictator'. You may need one.
>
> This is a catchy sound-bite on my expense, but it misses
> the point.
Can you imagine that some people get tired when each
new year some newbie wants the Lisp community to
to be like he expects it to be?
You are like a runner, seeing a hurdle, running full-speed against
this hurdle and protesting that actually there is this hurdle.
But it is part of the race, and you could have jumped
over it. Some even jump over it elegantly.
> > But then you can always join the Python community.
>
> You sound like a German redneck before 1989 telling
> student protesters and "commies" to emigrate to the
> GDR if they don't like it here.
And where is the GDR now?
> The python community
> is where I'm from. Lisp has its virtues over python,
> but there is no such thing as a "batteries included" for
> Lisp, and most people here agree that this is a bad thing,
> at least hampering wide-spread acceptance of the language.
This 'wide-spread acceptance' thing is a misunderstanding. You
are really looking for Python. Common Lisp has not been
designed to support 'wide-spread acceptance'.
> I attribute this to the fact that there is no maintainer
> of a single implementation (as with perl) who integrates
> contributions into a distribution.
But this is wrong. There are lots of maintainers of single
implementations. Just pick one.
> The result is a
> twisted little maze of little Lisps and slightly incompatible
> wheels, as with Unix ca 1990. "Batteries included",
The Lisp systems are widely different with lots of
different targets communities. Lisp is NOT limited to web
scripting.
> a default set of modules, is a strong incentive to adopt
> the language. If you agree that Lisp is undervalued,
I don't even care about that.
> than
> you might or might not agree that fragmentation is the
> problem and a central figure would have alleviated this.
You really want to use Python.
> Just stating that "Lisp does not need 'benevolent dictator'
> is not gonna cut it. Why do you think that?
For me it's not fragmentation. It is choice. It is different target
markets.
If you want to do a little (web) scripting, guided by a 'central
figure',
you can go to GDR, err., to Python.
Or once you get over it, you can choose that Lisp implementation
that fits your needs best and stay with it. Just close your
eyes and pretend there are no other Lisps. Then you have
a single implementation.
Wade Humeniuk
>
> You are stating the obvious, but at this time it means freedom from
> something as easy as
>
> import sockets.
>
What's a socket? CL does not have sockets, it has streams.
Sockets are an OS concept. I don't need no stinkin sockets.
Wade
jos...@corporate-world.lisp.de
Tin Gherdanarra schrieb:
Does that work in Python? Perl? TCL? Ruby? Rebol? JavaScript? PHP?
REXX? AppleScript? Lua?
The reality is that you have a multitude of scripting languages
with small differences in capabilities - each completely incompatible.
Common Lisp is not a scripting language (and not designed as such).
It has a large shared core language and several very different
implementations, many with lots of extensions. Unless you
accept that, you are probably better off somewhere else.
Really.
Tin Gherdanarra
> Tin Gherdanarra schrieb:
>
>
>>jos...@corporate-world.lisp.de wrote:
>>
>>>Tin Gherdanarra schrieb:
>>
>>>Lisp does not need a 'benevolent dictator'. You may need one.
>>
>>This is a catchy sound-bite on my expense, but it misses
>>the point.
>
>
> Can you imagine that some people get tired when each
> new year some newbie wants the Lisp community to
> to be like he expects it to be?
>
> You are like a runner, seeing a hurdle, running full-speed against
> this hurdle and protesting that actually there is this hurdle.
> But it is part of the race, and you could have jumped
> over it. Some even jump over it elegantly.
You have seen a lot of newbies I guess and so you
are oversensitive. I haven't complained about anything.
My original post was a simple question: Any improvements
in lisp's usability or mindshare since April 2001?
I got a single answer to that question, everybody
else tried to involve me in a lengthy discussion,
deliberately misunderstanding me. You do, too.
I don't expect the lisp community to change, and
I did not utter a complaint. What I said - upon
popular demand, mind you - was that I think other
programming languages owe their success to the fact
that there is a single implementation. This was a
thesis up for debate, the debate did not happen. You,
for example, basically told me to go and boil my head.
>
>
>>>But then you can always join the Python community.
>>
>>You sound like a German redneck before 1989 telling
>>student protesters and "commies" to emigrate to the
>>GDR if they don't like it here.
>
>
> And where is the GDR now?
>
On usenet nobody sees me rolling up my eyes.
>
>>The python community
>>is where I'm from. Lisp has its virtues over python,
>>but there is no such thing as a "batteries included" for
>>Lisp, and most people here agree that this is a bad thing,
>>at least hampering wide-spread acceptance of the language.
>
>
> This 'wide-spread acceptance' thing is a misunderstanding. You
> are really looking for Python. Common Lisp has not been
> designed to support 'wide-spread acceptance'.
>
You should tell that to Peter Seibel. He is wasting his time
in a futile attempt to improve on Lisp's acceptance. It's
called Lisp Gardeners.
And maybe you should page Richard P Gabriel who still hopes
Lisp to "Win Big" and become the seminal prototyping language,
if nothing else.
>
>>I attribute this to the fact that there is no maintainer
>>of a single implementation (as with perl) who integrates
>>contributions into a distribution.
>
>
> But this is wrong. There are lots of maintainers of single
> implementations. Just pick one.
Which one is the single implementation? SBCL? CLisp? Allegro
Common Lisp?
>
>
>>The result is a
>>twisted little maze of little Lisps and slightly incompatible
>>wheels, as with Unix ca 1990. "Batteries included",
>
>
> The Lisp systems are widely different with lots of
> different targets communities.
The word for this is "fragmented".
> Lisp is NOT limited to web
> scripting.
The sum of the angles in a triangle is always 180 degrees.
November 11th 1918 was a Monday.
Nobody expects the Spanish Inquisition.
>
>
>>a default set of modules, is a strong incentive to adopt
>>the language. If you agree that Lisp is undervalued,
>
>
> I don't even care about that.
So you should contribute to some other thread, perhaps?
>
>
>>than
>>you might or might not agree that fragmentation is the
>>problem and a central figure would have alleviated this.
>
>
> You really want to use Python.
>
No, I don't. I would know that.
>
>>Just stating that "Lisp does not need 'benevolent dictator'
>>is not gonna cut it. Why do you think that?
>
>
> For me it's not fragmentation. It is choice. It is different target
> markets.
How is "choice" different from "fragmentation", apart from spelling?
>
> If you want to do a little (web) scripting,
You have an obsession with web-scripting. I don't do webscripting.
> guided by a 'central
> figure',
> you can go to GDR, err., to Python.
>
> Or once you get over it, you can choose that Lisp implementation
> that fits your needs best and stay with it. Just close your
> eyes and pretend there are no other Lisps. Then you have
> a single implementation.
I have a diluted single implementation, right. And buggy
packages without documentation. Now you can say "Want documentation?
Want less bugs? Get yourself a python interpreter" again.
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>>
>> You are stating the obvious, but at this time it means freedom from
>> something as easy as
>>
>> import sockets.
>>
>
> What's a socket? CL does not have sockets, it has streams.
So where is my
(require 'tcpip-streams)
then?
Wade Humeniuk
> Wade Humeniuk wrote:
>> Tin Gherdanarra wrote:
>>
>>>
>>> You are stating the obvious, but at this time it means freedom from
>>> something as easy as
>>>
>>> import sockets.
>>>
>>
>> What's a socket? CL does not have sockets, it has streams.
>
> So where is my
>
> (require 'tcpip-streams)
>
> then?
>
>
I have mine, you mean you do not have yours?? Hmmm.... you are
bringing tears to mine eyes..
Wade
Rainer Joswig
<tinma...@gmail.com> in 445a4g...@individual.net:
> You have seen a lot of newbies I guess and so you
> are oversensitive. I haven't complained about anything.
> My original post was a simple question: Any improvements
> in lisp's usability or mindshare since April 2001?
'Lisp usability' and 'mindshare' are pretty broad
terms. Next to useless.
> I got a single answer to that question, everybody
> else tried to involve me in a lengthy discussion,
> deliberately misunderstanding me.
Then you should provide more specific questions?
> You do, too.
> I don't expect the lisp community to change, and
> I did not utter a complaint. What I said - upon
> popular demand, mind you - was that I think other
> programming languages owe their success to the fact
> that there is a single implementation. This was a
> thesis up for debate, the debate did not happen. You,
> for example, basically told me to go and boil my head.
People are trying to explain to you that this has
to do with 'other programming languages'. Here you
are in comp.lang.lisp .
>> This 'wide-spread acceptance' thing is a misunderstanding. You
>> are really looking for Python. Common Lisp has not been
>> designed to support 'wide-spread acceptance'.
>>
> You should tell that to Peter Seibel. He is wasting his time
> in a futile attempt to improve on Lisp's acceptance. It's
> called Lisp Gardeners.
Improving acceptance is fine. 'wide-spread acceptance' is something
different. Common Lisp is ugly and complicated. It is more
for expert programmers, who can shoot themselves in the foot
in a more controlled way.
> And maybe you should page Richard P Gabriel who still hopes
> Lisp to "Win Big" and become the seminal prototyping language,
> if nothing else.
Oh really? How does 'hope' make this happen? Last I saw Richard P Gabriel
was working for SUN on Java.
>> But this is wrong. There are lots of maintainers of single
>> implementations. Just pick one.
>
> Which one is the single implementation? SBCL? CLisp? Allegro
> Common Lisp?
Pick one.
...
>> You really want to use Python.
>>
> No, I don't. I would know that.
Benevolent Dictator. Check.
One Implementation. Check.
Wide-Spread Acceptance. Well, check.
Large library. Check.
Sounds like Python to me.
> You have an obsession with web-scripting. I don't do webscripting.
Okay. But do you have any specific and practical questions, where
one could help?
>> Or once you get over it, you can choose that Lisp implementation
>> that fits your needs best and stay with it. Just close your
>> eyes and pretend there are no other Lisps. Then you have
>> a single implementation.
>
> I have a diluted single implementation, right. And buggy
> packages without documentation. Now you can say "Want documentation?
> Want less bugs? Get yourself a python interpreter" again.
Now you start to completely confuse me. One implementation is not
what you want?
Ulrich Hobelmann
>> Lisp is about having more freedom, not less.
>
> You are stating the obvious, but at this time it means freedom from
> something as easy as
>
> import sockets.
I agree, but in Lisp you can choose between different packages that do
similar or the same things. The downside is that each implementation
might have different thread or socket packages, but on the upside, once
you choose an implementation, you can choose your packages with it.
Besides, there's compatibility stuff, like Peter Seibel's Pathname
wrapper, or the ACL-compat package from Portable Allegroserve.
It IS choice, even though you may not like it. I don't always like it,
but progress only happens when people *work* on it, and most Lisp users
seem to have their set of packages configured, so there's no huge need
for platform-independent wrappers / standardized packages.
> Actually, all I wanted to know was whether you guys notice
> improvement in Lisp's mindshare and lower barrier to entry. And
> now I'm sitting here, arguing over implementation vs. specification
> and being called all sorts of things.
I think the mindshare is there, but the barrier to entry is fairly high,
compared to other languages, yes. It depends on what you want.
--
Suffering from Gates-induced brain leakage...
Pascal Costanza
>>> I attribute this to the fact that there is no maintainer
>>> of a single implementation (as with perl) who integrates
>>> contributions into a distribution.
>>
>> You make the same category error like most other people who have
>> stated similar things like you in the past. ANSI Common Lisp is a
>> specification, not an implementation. End of story.
>
> Yes. That's in contrast to perl and python that have no
> specification, just an implementation that is some sort
> of the borg assimilating modules, thus discouraging writing
> another modules with overlapping function. Common Lisp does have a
> specification, so there are various independent implementations
> resultin in fragmentation.
Any language that is based on a specification has what you call
"fragmentation". You can't have the cake and eat it at the same time.
>> Of course there are maintainers of single implementations. Each Common
>> Lisp implementation has at least one, and each Common Lisp
>> implementation comes with a far richer set of libraries than what is
>> specified in ANSI Common Lisp. Just go with the one that best suits
>> your needs.
>
> It's not just my needs. It's something like
>
> import sockets
You haven't looked closely enough.
>> Many people here agree that having a common specification is a good
>> thing.
>
> It IS a good thing, but there are some blanks and various attempts
> to fill in the blanks. The standard was an attempt to unify various
> successful Lisps in order to avoid duplication of effort in the
> future and make Lisp more popular. This has not worked out so far.
The standardization of ANSI Common Lisp has followed a number of very
specific and concrete goals. They are listed in "Common Lisp, the
Language - 2nd Edition" by Guy Steele et al. in Chapter 1.1. You can
download that book from http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html
The goals are commonality, portability, consistency, expressiveness,
compatibility, efficiency, power and stability.
From that chapter:
"There are now many implementations of Common Lisp, some programmed by
research groups in universities and some by companies that sell them
commercially, and a number of useful programming environments have
indeed grown up around these implementations. What is more, all the
goals stated above have been achieved, most notably that of portability.
Moving large bodies of Lisp code from one computer to another is now
routine."
And from the introduction to that book:
"Common Lisp has succeeded. Since publication of the first edition of
this book in 1984, many implementors have used it as a de facto standard
for Lisp implementation. As a result, it is now much easier to port
large Lisp programs from one implementation to another. Common Lisp has
proved to be a useful and stable platform for rapid prototyping and
systems delivery in artificial intelligence and other areas. WIth
experience gained in using Common Lisp for so many applications,
implementors found no shortage of opportunities for innovation. One of
the important characteristics of Lisp is its good support for
experimental extension of the language; while Common Lisp has been
stable, it has not stagnated."
Common Lisp is indeed one of the few languages that has met its goals.
They may not be your goals, but that's a secondary issue. Especially,
popularity was not among the goals.
>> Many also agree that having more common de-facto standard libraries is
>> also a good things, and they are successfully working on them. If you
>> don't agree with them and prefer a single implementation, there's
>> noone stopping you from choosing exactly one implementation and
>> forgetting about the rest.
>
> Not so fast. Choice and competing implementations precluded
> Unix from becoming an OS monopoly. Things changed considerably when
> Linus Torvalds hijacked the Minix community and a large part of
> the community decided that it was a worthy project to invest into.
> Don't you think that this is a good thing, too?
I am absolutely against monopolies because that stifles innovation in
the long run. Computer science and IT in general is currently in a very
bad shape because of such "monopolies". I am very happy that there are
some corners where people share very different values.
>> So effectively, you have more choices than the single implementation
>> languages where you cannot choose to focus on writing portable code
>> against a spec, because such a spec doesn't exist over there.
>
> A single implementation obsoletes the need for a specification.
> Since Lisp began its career as a family of dialects, standardization
> after the fact was necessary. perl, python or PHP never had this
> problem.
They have this problem as well because they are basically all variations
of the same idea. Why do you think they are working on Parrot? If these
languages were indeed so different then it wouldn't be possible to
define a single virtual machine for them.
> Actually, all I wanted to know was whether you guys notice
> improvement in Lisp's mindshare and lower barrier to entry.
Absolutely yes!
> And now I'm sitting here, arguing over implementation vs. specification
> and being called all sorts of things.
You're stating things that are considered to be wrong by many people
over here. You should be able to cope with that.
Why don't you simply ask questions like "Which CL implementation comes
with a built-in socket library?"
Rob Warnock
+---------------
| Tin Gherdanarra wrote:
| > import sockets
...
| Why don't you simply ask questions like "Which CL
| implementation comes with a built-in socket library?"
He probably wouldn't like the answer: "All of them."
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pisin Bootvong
Pascal Costanza wrote:
> Tin Gherdanarra wrote:
> > Since Lisp began its career as a family of dialects, standardization
> > after the fact was necessary. perl, python or PHP never had this
> > problem.
>
> They have this problem as well because they are basically all variations
> of the same idea.
What variation of the same idea do they have in common, "being touring
equivelent"? (And what makes same idea not count in Common Lisp?)
Are there ongoing process in the community to unified Perl/Python/PHP
into one single language named CommonP? :D
> Why do you think they are working on Parrot?
Parrot is a Virtual Machine. They want to make a virtual machine that
has bytecode and architecture that is friendly to dynamic-type
language. From what I heard, JVM favors static type language, as well
as CLR. Although CLR 2 may support better of dynamic-type language.
> If these languages were indeed so different then it wouldn't be possible to
> define a single virtual machine for them.
>
Then I would say, C, Assembly, Java and **LISP** is not so different
since it is possible to define a single virtual machine for them, an
x86 machine.
> Why don't you simply ask questions like "Which CL implementation comes
> with a built-in socket library?"
>
To be honest, there are differences between
import socket
and
#+clisp(require 'socket)
#+sbcl(require 'sb-bsd-socket)
#+cmucl(require 'sb-bsd-socket)
...
And how each API have to be called in each implementation, that's the
point. One of the goal of CL is poratbility, isn't it?
[see Dave Roberts' Socket API Proposal:
http://www.findinglisp.com/papers/sockets-analysis-0-2-5.pdf]
Anyway, one can always find some portable socket library to use,
trivial-socket for instances. And things will hopefully improve in the
future.
----
By the way, I'm starting to feel that, like the fact that every
programming language is touring equivelant, every language is also
portable.
Java is portable because you can do "new Socket()" on any platform.
Python is portable you can do socket.open on any platform.
...
C is portable because you can do open() on any POSIX system. And WIN32
API on Win32.
...
Common Lisp is portable because you can do
#+sbcl(...)#+clisp(...)#+cmucl(...)
...
Assembly is portable because you could probably do #define X86 ...
#define SPARC ... #define POWERPC, given some preproccessing tools.
I think it is good that we don't fall in to portability trap.
There are levels of portability.
ISO Common Lisp is portable at "Algorithm Level". If you look at CLHS
the only external environment defined by ISO Common Lisp is Pathname
and partly Stream. CLHS standardize mostly on common algorithm and
infrastructure of the runtime.
Perl/Python/PHP/C/Java is practical in that, even though they can't
effort to get an ISO standard (as many here said how hard/costly it is
to push for a next CL standard), they are portable at the "Environment
Level". May be they are semi portable, some things still must be code
differently for Win32 and Linux. But their situation is probably better
than with CLISP/SBCL/CMUCL.
Pascal Costanza
> Pascal Costanza wrote:
>
>>Tin Gherdanarra wrote:
>>
>>>A single implementation obsoletes the need for a specification.
>>>Since Lisp began its career as a family of dialects, standardization
>>>after the fact was necessary. perl, python or PHP never had this
>>>problem.
>>
>>They have this problem as well because they are basically all variations
>>of the same idea.
>
> What variation of the same idea do they have in common, "being touring
> equivelent"? (And what makes same idea not count in Common Lisp?)
>
> Are there ongoing process in the community to unified Perl/Python/PHP
> into one single language named CommonP? :D
Yes, that's what Parrot is going to be: A single language with skinnable
syntax. Just like .NET. ;)
>>Why do you think they are working on Parrot?
>
> Parrot is a Virtual Machine. They want to make a virtual machine that
> has bytecode and architecture that is friendly to dynamic-type
> language. From what I heard, JVM favors static type language, as well
> as CLR. Although CLR 2 may support better of dynamic-type language.
What those virtual machines do is that they actually provide high-level
constructs (for example, an object model in the sense of OOP). A
language that targets one of those VMs can either buy into that model,
making it essentially just a different surface syntax for the same
language, or it can try to work around the given model to better
implement its own idea what the model should look like. But this will
give you a number of disadvantages that stem from the fact that you are
incompatible with the "native" model.
As an extreme case, consider porting Haskell to one of those virtual
machine while staying completely free of side effects. Common Lisp
typically also has problems targetting such VMs because some of its
design decisions are not widely shared.
>>If these languages were indeed so different then it wouldn't be possible to
>>define a single virtual machine for them.
>
> Then I would say, C, Assembly, Java and **LISP** is not so different
> since it is possible to define a single virtual machine for them, an
> x86 machine.
An x86 machine is different from such VMs in the sense that it
instruction set is neutral and doesn't assume specific language models.
>>Why don't you simply ask questions like "Which CL implementation comes
>>with a built-in socket library?"
>
> To be honest, there are differences between
>
> import socket
>
> and
>
> #+clisp(require 'socket)
> #+sbcl(require 'sb-bsd-socket)
> #+cmucl(require 'sb-bsd-socket)
> ...
>
> And how each API have to be called in each implementation, that's the
> point.
Again, you are comparing a single-implementation language against a
specification. No matter how hard you try to standardize libraries,
there will always be open ends. If you don't like this, the way out is
to choose one particular implementation and forget about the others. Or
switch to one of the Lisp dialects that effectively have only one
implementation.
It doesn't make sense to suggest that all Common Lisp implementations
should be collapsed into a single one. It won't happen anyway.
> One of the goal of CL is poratbility, isn't it?
Right.
> [see Dave Roberts' Socket API Proposal:
> http://www.findinglisp.com/papers/sockets-analysis-0-2-5.pdf]
> Anyway, one can always find some portable socket library to use,
> trivial-socket for instances. And things will hopefully improve in the
> future.
Yes. BTW, things don't improve by themselves - it requires people to
devote their valuable time into improving the situation. These people
exist, and as far as I can tell they are doing a pretty good job given
the constraints of the comparatively small Common Lisp community.
> By the way, I'm starting to feel that, like the fact that every
> programming language is touring equivelant, every language is also
> portable.
You mean "Turing equivalent". No, not every programming language is
Turing equivalent, and this doesn't relate to portability.
> Java is portable because you can do "new Socket()" on any platform.
I haven't checked carefully, but I guess that you cannot perform "new
Socket()" on all platforms. Consider platforms like J2ME or Javacard. If
you take into account other libraries, there are definitely (important)
Java libraries out there that don't work in all Java enviroments. It's
essentially the same effect that we see in Common Lisp: There is a
standard specification, and numerous deviations from that specification.
It's an inevitable effect of languages which separate specifications
from implementations.
> ISO Common Lisp is portable at "Algorithm Level". If you look at CLHS
> the only external environment defined by ISO Common Lisp is Pathname
> and partly Stream. CLHS standardize mostly on common algorithm and
> infrastructure of the runtime.
You mean ANSI Common Lisp. The ISO standard is ISLISP. Apart from that
you're mostly right.
> Perl/Python/PHP/C/Java is practical in that, even though they can't
> effort to get an ISO standard (as many here said how hard/costly it is
> to push for a next CL standard), they are portable at the "Environment
> Level". May be they are semi portable, some things still must be code
> differently for Win32 and Linux. But their situation is probably better
> than with CLISP/SBCL/CMUCL.
Depends heavily on what is important to you. For example, if you
consider GUI programming they are probably on par (thanks to LispWorks
and LTK). If you consider metaprogramming, Common Lisp is hard to beat. Etc.
alessi...@gmail.com
choose between multiple implementations and libraries; but, I think
that the choice should be made "at a higher level". I'll try to explain
myself better.
Every major CL implementation has its own library for, say, sockets.
All those libraries perform the *very same* tasks, but they haven't got
a common interface (same function names, same data structures...). Now,
if I want to write a portable program, that uses sockets and is
supposed to run on all major CL implementations, I have to write a lot
of implementation-specific code. And this isn't very inviting for a
newbie who is accustomed to a simple "import socket"-like statement.
Even if you don't care about newbies, consider that you'll have to
spend some valuable effort just to use a trivial library.
I feel that having the possibility to choose in this case isn't very
profitable. You should be able to choose between different
*implementations*, not different *interfaces* to the same thing! Of
course this is not always possible, but for trivial/low-level libraries
I don't think it's so difficult to achieve.
However, I don't think Lisp needs something like a "benevolent
dictator"; just some cooperation between implementors would be fine.
All this is rigorously My Humble Opinion.
Alessio
Ulrich Hobelmann
>> Why do you think they are working on Parrot?
>
> Parrot is a Virtual Machine. They want to make a virtual machine that
> has bytecode and architecture that is friendly to dynamic-type
> language. From what I heard, JVM favors static type language, as well
> as CLR. Although CLR 2 may support better of dynamic-type language.
What I know about Parrot, sucks. Why have a virtual machine at all?
It's only slow, and restricts users to that VM model. I prefer having a
"real" compiler for every platform, unless you use a VM mainly for small
footprint and portability (like CLisp), which is a very good reason.
VMs aren't useful in themselves, only if they bring good advantages. I
don't see what advantage Parrot could bring, other than being a
faster-than-now Perl. Lisp has other VMs or runs natively, as do other
languages. Why *one* VM?
> Then I would say, C, Assembly, Java and **LISP** is not so different
> since it is possible to define a single virtual machine for them, an
> x86 machine.
That's the most commonly used VM, indeed. And it's pretty fast, too, so
it only underlines my position, that we don't need more VMs.
Pascal Costanza
> I think I understand what Tin says. Sure it's a good thing that you can
> choose between multiple implementations and libraries; but, I think
> that the choice should be made "at a higher level". I'll try to explain
> myself better.
> Every major CL implementation has its own library for, say, sockets.
> All those libraries perform the *very same* tasks, but they haven't got
> a common interface (same function names, same data structures...). Now,
> if I want to write a portable program, that uses sockets and is
> supposed to run on all major CL implementations, I have to write a lot
> of implementation-specific code. And this isn't very inviting for a
> newbie who is accustomed to a simple "import socket"-like statement.
I don't have any specific experience with socket libraries because I
have never needed them, but it seems to me that
http://www.cliki.net/ACL-COMPAT gives you what you need in that regard.
> Even if you don't care about newbies, consider that you'll have to
> spend some valuable effort just to use a trivial library.
> I feel that having the possibility to choose in this case isn't very
> profitable. You should be able to choose between different
> *implementations*, not different *interfaces* to the same thing! Of
> course this is not always possible, but for trivial/low-level libraries
> I don't think it's so difficult to achieve.
That's, of course, a reasonable desire.
> However, I don't think Lisp needs something like a "benevolent
> dictator"; just some cooperation between implementors would be fine.
That kind of cooperation is hard to achieve, since it is pretty costly
and time consuming, without a lot of immediate benefits. Most people
seem to prefer to work on more concrete things, like code, libraries and
repositories, because this doesn't require the overhead of a more formal
standardization approach.
Always keep in mind that this is still a rather small community. If you
take this into account, you should admit that we are doing pretty well.
There are enough opportunities for you to invest some of your time to
improve the overall situation. That's the only way to improve things.
Paolo Amoroso
> Every major CL implementation has its own library for, say, sockets.
[...]
> I feel that having the possibility to choose in this case isn't very
> profitable. You should be able to choose between different
> *implementations*, not different *interfaces* to the same thing! Of
> course this is not always possible, but for trivial/low-level libraries
> I don't think it's so difficult to achieve.
You might try:
(asdf-install:install :trivial-sockets)
It works with ABCL (client only), Allegro CL, CMUCL, GNU CLISP,
LispWorks, OpenMCL and SBCL.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paul Griffioen
"Pascal Costanza" <p...@p-cos.net> schreef in bericht
news:446it3...@individual.net...
> alessi...@gmail.com wrote:
>
>> However, I don't think Lisp needs something like a "benevolent
>> dictator"; just some cooperation between implementors would be fine.
>
> That kind of cooperation is hard to achieve, since it is pretty costly and
> time consuming, without a lot of immediate benefits. Most people seem to
> prefer to work on more concrete things, like code, libraries and
> repositories, because this doesn't require the overhead of a more formal
> standardization approach.
> ...
This reminds me of the strong case for cooperation between competitors
Norman Macrae made in his biography of John von Neumann.
In outline he argued that such cooperation is extremely beneficial to all
competitors. He explains how the big Japanese companies used to cooperate
when designing products like the video recorder and when they decided on a
standard they would all go their separate way to implement this standard and
compete with each other. (He used this argument to justify Johnny's belief
that technological innovations should be made public as soon as possible and
not be withheld for competitive advantage. Some people were unhappy when he
wrote the 'first draft' because they thought they lost their competitive
advantages). According to Macrae this was the biggest reason for the
enormous economic growth of Japan after the second world war.
Unlike Macrae I'm not an economist so I cannot say he is correct or whether
this applies to the different Lisp implementers or not, but there seem to be
some parallels.
Paul Griffioen
Randall Randall
>
> So where is my
>
> (require 'tcpip-streams)
>
> then?
Here: http://www.cliki.net/trivial-sockets
--
Randall Randall <ran...@randallsquared.com>
"Tough crowd. The OP needs a little encouragement
and you sucker punch him. Excellent." - Kenny Tilton
Pisin Bootvong
(ISO Common Lisp, Touring).
Shame on me!!! :-(
Tin Gherdanarra
> Am 30.01.2006 2:58 Uhr schrieb "Tin Gherdanarra" unter
> <tinma...@gmail.com> in 445a4g...@individual.net:
>
>
>>You have seen a lot of newbies I guess and so you
>>are oversensitive. I haven't complained about anything.
>>My original post was a simple question: Any improvements
>>in lisp's usability or mindshare since April 2001?
>
>
> 'Lisp usability' and 'mindshare' are pretty broad
> terms. Next to useless.
Come on; pluuaeessee -- you know what I mean.
>
>
>>I got a single answer to that question, everybody
>>else tried to involve me in a lengthy discussion,
>>deliberately misunderstanding me.
>
>
> Then you should provide more specific questions?
There you go:
I'm under the impression
that not much has changed in terms of technology and
community efforts. Peter Seibel's admirable book and
promising current gardeners-project is the only exception,
but I might have missed something. If so, what?
>
> People are trying to explain to you that this has
> to do with 'other programming languages'. Here you
> are in comp.lang.lisp .
>
Of course it has to do with other programming
languages. If you relate something to some other
thing, it involves the other thing as well as
the something.
>
>
> Improving acceptance is fine. 'wide-spread acceptance' is something
> different.
You are right, but wide-spread acceptance is a good
way to improve utility of language. You can say that
Lisp has utility enough for you, but isn't it weird
that all the open source resources go into perl?
> Common Lisp is ugly and complicated.
I will be curious to see how much flak you will get
for this statement.
> It is more
> for expert programmers, who can shoot themselves in the foot
> in a more controlled way.
>
I've heard this a lot from other people, too, but
I doubt that this is right. Lisp is actually easier
than many other languages. I won't comment on this
because there is a stampede of 20 more people in the
queue trampling on me.
>
>>And maybe you should page Richard P Gabriel who still hopes
>>Lisp to "Win Big" and become the seminal prototyping language,
>>if nothing else.
>
>
> Oh really? How does 'hope' make this happen? Last I saw Richard P Gabriel
> was working for SUN on Java.
>
He sold out.
>>
>>Which one is the single implementation? SBCL? CLisp? Allegro
>>Common Lisp?
>
>
> Pick one.
>
But then I'm incompatible with all the others.
>
> Benevolent Dictator. Check.
> One Implementation. Check.
> Wide-Spread Acceptance. Well, check.
> Large library. Check.
>
> Sounds like Python to me.
>
Python does not have Lisp's syntax or its constructs.
Guido even wants to take out map and reduce.
>
>>You have an obsession with web-scripting. I don't do webscripting.
>
>
> Okay. But do you have any specific and practical questions, where
> one could help?
You have switched to this channel too late.
My original question was
I'm under the impression
that not much has changed in terms of technology and
community efforts. Peter Seibel's admirable book and
promising current gardeners-project is the only exception,
but I might have missed something. If so, what?
>
>
>>>Or once you get over it, you can choose that Lisp implementation
>>>that fits your needs best and stay with it. Just close your
>>>eyes and pretend there are no other Lisps. Then you have
>>>a single implementation.
>>
>>I have a diluted single implementation, right. And buggy
>>packages without documentation. Now you can say "Want documentation?
>>Want less bugs? Get yourself a python interpreter" again.
>
>
> Now you start to completely confuse me. One implementation is not
> what you want?
>
One implementation with a CPAN or a large set of built-in
modules would be nice.
Tin Gherdanarra
> Pisin Bootvong wrote:
>
>>> Why do you think they are working on Parrot?
>>
>>
>> Parrot is a Virtual Machine. They want to make a virtual machine that
>> has bytecode and architecture that is friendly to dynamic-type
>> language. From what I heard, JVM favors static type language, as well
>> as CLR. Although CLR 2 may support better of dynamic-type language.
>
>
> What I know about Parrot, sucks.
The parrot projects is stalled, or so it seems. The
parrot vm is fairly advanced and build on good ideas.
> Why have a virtual machine at all?
It simplifies the compiler. The resulting binary can be
run anywhere, just rewrite the core of the vm.
Writing a good debugger is much easier for a vm than
for a native CPU.
> It's only slow,
There is virtually no practical application for fast
computer programs.
> and restricts users to that VM model.
Yessss -- that's why parrot is stalled. They can't reconcile
perl's and python's different object models.
> I prefer having a
> "real" compiler for every platform, unless you use a VM mainly for small
> footprint and portability (like CLisp), which is a very good reason.
>
There you go. A small footprint won't be one of parrot's virtues,
I'm afraid.
> VMs aren't useful in themselves, only if they bring good advantages. I
> don't see what advantage Parrot could bring, other than being a
> faster-than-now Perl. Lisp has other VMs or runs natively, as do other
> languages. Why *one* VM?
One VM for Lisp, python, perl and more languages would be the coolest
thing since electricity. You could link Lisp, python, perl and more
vm object code together. Unfortunately, the different understanding of
classes, instances and run-time type information gets in the way
and make this utopian world impossible.
>
>> Then I would say, C, Assembly, Java and **LISP** is not so different
>> since it is possible to define a single virtual machine for them, an
>> x86 machine.
You are right. In 10 years there will be just one hardware-platform:
Intel. And hundreds of incompatible virtual machines running on
it.
>
>
> That's the most commonly used VM, indeed. And it's pretty fast, too, so
> it only underlines my position, that we don't need more VMs.
>
You are probably an sbcl-driver, right?
Tin Gherdanarra
Tin Gherdanarra
> alessi...@gmail.com writes:
>
>
>>Every major CL implementation has its own library for, say, sockets.
>
> [...]
>
>>I feel that having the possibility to choose in this case isn't very
>>profitable. You should be able to choose between different
>>*implementations*, not different *interfaces* to the same thing! Of
>>course this is not always possible, but for trivial/low-level libraries
>>I don't think it's so difficult to achieve.
>
>
> You might try:
>
> (asdf-install:install :trivial-sockets)
This works, thank you. Now I have to come up
with another example to make a point.
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>>Tayssir John Gabbour wrote:
>>
>>><shrug> I'm sure you'll find your news on O'Reilly or Dr. Dobbs if Lisp
>>>is getting to the point you want,
>>
>>I'm sure I will, but right now there are next to no Lisp
>>news on O'Reilly or Dr. Dobbs, so it might be a long way
>>to get there.
>
>
> Of course it will be a long way; did I make it seem otherwise?
>
> Assuming you are serious about scouting, I'd check the Lisp world every
> 6 months, with a serious check in 2 years.
Hm -- "scouting"?
>
>
>
>>>or if some Benevolent Hitler starts
>>>making efficient decisions.
>>
>>I'm not talking about making decisions, I'm talking
>>about integration and batteries included. Look at
>>this: http://docs.python.org/modindex.html
>>
>>If anyone could get me such a thing for CL, I'd
>>vote NSDAP, politcal correctness be damned.
>
>
> I completed projects in Python before ever hearing about "Lisp."
>
So we are confr.e.res in a way.
> To clarify, does your willingness to vote Nazi extend to a willingness
> to pay for a commercial implementation? (Or do you believe commercial
> impls also fail to have batteries included?)
>
I'm a miser, so paying for software is out of the question.
I heard good things about allegro, though.
> I tell people early and often not to assume free Common Lisps have
> "batteries included." It's not easy for many people to use Lisp. I tell
> them to do something more important with their time, such as take up
> trashball.
This is bad advice because Lisp is very important.
However, "it's not easy for many people to use Lisp" is
what I observed, too. This has nothing to do with the
language itself, but with the OSS support for it. My
original question basically was: Has it gotten any easier
since Paul Graham wrote his "Beating the averages"? Are
there more newbies here?
> http://widro.com/throwpaper.html
>
Gross!
>
> Tayssir
>
Tin Gherdanarra
>
>
> "Pascal Costanza" <p...@p-cos.net> schreef in bericht
> news:446it3...@individual.net...
>
>>alessi...@gmail.com wrote:
>>
>>
>>>However, I don't think Lisp needs something like a "benevolent
>>>dictator"; just some cooperation between implementors would be fine.
>>
>>That kind of cooperation is hard to achieve, since it is pretty costly and
>>time consuming, without a lot of immediate benefits. Most people seem to
>>prefer to work on more concrete things, like code, libraries and
>>repositories, because this doesn't require the overhead of a more formal
>>standardization approach.
>>...
>
>
> This reminds me of the strong case for cooperation between competitors
> Norman Macrae made in his biography of John von Neumann.
Sounds like a smart biographist.
>
>
>
> In outline he argued that such cooperation is extremely beneficial to all
> competitors. He explains how the big Japanese companies used to cooperate
> when designing products like the video recorder and when they decided on a
> standard they would all go their separate way to implement this standard and
> compete with each other. (He used this argument to justify Johnny's belief
> that technological innovations should be made public as soon as possible and
> not be withheld for competitive advantage. Some people were unhappy when he
> wrote the 'first draft' because they thought they lost their competitive
> advantages). According to Macrae this was the biggest reason for the
> enormous economic growth of Japan after the second world war.
>
>
>
> Unlike Macrae I'm not an economist so I cannot say he is correct or whether
> this applies to the different Lisp implementers or not, but there seem to be
> some parallels.
You don't need to be an economist for this. Common sense should suffice.
>
> Paul Griffioen
>
>
>
Pascal Costanza
> You don't need to be an economist for this. Common sense should suffice.
Common sense is often wrong. (For example, recall that the earth was
considered flat for quite some time.)
Tin Gherdanarra
> alessi...@gmail.com wrote:
>
>> I think I understand what Tin says. Sure it's a good thing that you can
>> choose between multiple implementations and libraries; but, I think
>> that the choice should be made "at a higher level". I'll try to explain
>> myself better.
>> Every major CL implementation has its own library for, say, sockets.
>> All those libraries perform the *very same* tasks, but they haven't got
>> a common interface (same function names, same data structures...). Now,
>> if I want to write a portable program, that uses sockets and is
>> supposed to run on all major CL implementations, I have to write a lot
>> of implementation-specific code. And this isn't very inviting for a
>> newbie who is accustomed to a simple "import socket"-like statement.
>
>
> I don't have any specific experience with socket libraries because I
> have never needed them, but it seems to me that
> http://www.cliki.net/ACL-COMPAT gives you what you need in that regard.
Don't pin me down on this one example because it's a pretty
bad one anyway. Another correspondet has pointed to
(asdf-install 'trivial-sockets) making me look pretty stupid
in the process. It's not quite as batteries included as
import sockets, but almost.
>
>> Even if you don't care about newbies, consider that you'll have to
>> spend some valuable effort just to use a trivial library.
>> I feel that having the possibility to choose in this case isn't very
>> profitable. You should be able to choose between different
>> *implementations*, not different *interfaces* to the same thing! Of
>> course this is not always possible, but for trivial/low-level libraries
>> I don't think it's so difficult to achieve.
>
>
> That's, of course, a reasonable desire.
>
>> However, I don't think Lisp needs something like a "benevolent
>> dictator"; just some cooperation between implementors would be fine.
>
See the next reply in this subthread.
>
> That kind of cooperation is hard to achieve, since it is pretty costly
> and time consuming, without a lot of immediate benefits. Most people
> seem to prefer to work on more concrete things, like code, libraries and
> repositories, because this doesn't require the overhead of a more formal
> standardization approach.
>
> Always keep in mind that this is still a rather small community.
It is even smaller than you think. Most people here on c.l.l
are actually the same person posing as multiple posters just
to inflate the lisp user count.
> If you
> take this into account, you should admit that we are doing pretty well.
They had more time than most other communities to build this stuff.
And Lisp is a very productive language.
> There are enough opportunities for you to invest some of your time to
> improve the overall situation. That's the only way to improve things.
>
I did not plan to build anything for the community, I just
want to leech it off. I'm not sure how legitimate it is to
ask other people to do one's work, but it seems to work
pretty well for the perl and python folks.
>
> Pascal
>
Pascal Costanza
> Rainer Joswig wrote:
>
>> Then you should provide more specific questions?
>
> There you go:
>
> I'm under the impression
> that not much has changed in terms of technology and
> community efforts. Peter Seibel's admirable book and
> promising current gardeners-project is the only exception,
> but I might have missed something. If so, what?
Quite a lot. (That answer is as specific as your question.)
Tin Gherdanarra
> I think I understand what Tin says.
Thanks for you support,
> Sure it's a good thing that you can
> choose between multiple implementations and libraries; but, I think
> that the choice should be made "at a higher level". I'll try to explain
> myself better.
> Every major CL implementation has its own library for, say, sockets.
> All those libraries perform the *very same* tasks, but they haven't got
> a common interface (same function names, same data structures...). Now,
> if I want to write a portable program, that uses sockets and is
> supposed to run on all major CL implementations, I have to write a lot
> of implementation-specific code. And this isn't very inviting for a
> newbie who is accustomed to a simple "import socket"-like statement.
The important thing is not that it is easy to import it for a newbie.
It is the fact that it is the one socket module that is more equal
because it comes with the language. Most people would use this module
because they could expect that everybody else has it.
> Even if you don't care about newbies, consider that you'll have to
> spend some valuable effort just to use a trivial library.
CLOCC was hardest.
> I feel that having the possibility to choose in this case isn't very
> profitable. You should be able to choose between different
> *implementations*, not different *interfaces* to the same thing! Of
> course this is not always possible, but for trivial/low-level libraries
> I don't think it's so difficult to achieve.
In the open source world the implementation is the interface.
If you want to embody something compatible, you don't write
something that adheres to the same interface -- you just
take the entire code and drop it in.
> However, I don't think Lisp needs something like a "benevolent
> dictator"; just some cooperation between implementors would be fine.
> All this is rigorously My Humble Opinion.
>
Good opinion, but cooperation requires a seed crystal in
integration figure.
> Alessio
>
Pascal Costanza
> I did not plan to build anything for the community, I just
> want to leech it off. I'm not sure how legitimate it is to
> ask other people to do one's work, but it seems to work
> pretty well for the perl and python folks.
Your honesty is remarkable.
jayessay
> Adam Connor wrote:
> > On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
> > <cs...@cam.ac.uk> wrote:
> >
> >>Feeding the troll is likely to be unproductive, but CLiki came into
> >>being on May 29, 2000, so claims for "most stuff over there" having
> >>been sitting there for longer than five years aren't just wrong,
> >>they're foolishly wrong.
> > Why do you assume trolling? Is it not possible to ask these questions
> > without being a troll?
>
> Thanks for your support (:
LOL! You're thanking another well known troll here for his support!
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay
> Wade Humeniuk wrote:
> > Tin Gherdanarra wrote:
> >
> >>
> >> You are stating the obvious, but at this time it means freedom from
> >> something as easy as
> >>
> >> import sockets.
> >>
> > What's a socket? CL does not have sockets, it has streams.
>
> So where is my
>
> (require 'tcpip-streams)
>
> then?
Who knows where _yours_ is. Mine is from my vendor and it works
great.
Tayssir John Gabbour
> Tayssir John Gabbour wrote:
> > I tell people early and often not to assume free Common Lisps have
> > "batteries included." It's not easy for many people to use Lisp. I tell
> > them to do something more important with their time, such as take up
> > trashball.
>
> This is bad advice because Lisp is very important.
Excuse me; I deleted my message from google once others explained that
you're a troll, or someone indistinguishable from one. I retract that
post.
(To clarify my post, as it stands quoted, I of course think Lisp is
"important", and the free implementations are awesome. But people seem
to like it when I try not preaching to them, explaining the warts and
power of Lisp best I know, so some people ignore my trashball comments
and understand that it's rough, interesting terrain.)
Tayssir
Peter Herth
> Paolo Amoroso wrote:
>
>> alessi...@gmail.com writes:
>>
>>
>>> Every major CL implementation has its own library for, say, sockets.
>>
>>
>> [...]
>>
>>> I feel that having the possibility to choose in this case isn't very
>>> profitable. You should be able to choose between different
>>> *implementations*, not different *interfaces* to the same thing! Of
>>> course this is not always possible, but for trivial/low-level libraries
>>> I don't think it's so difficult to achieve.
>>
>>
>>
>> You might try:
>>
>> (asdf-install:install :trivial-sockets)
>
>
> This works, thank you. Now I have to come up
> with another example to make a point.
And equally simple is:
(asdf-install:install :ltk) ;; GUI
(asdf-install:install :cl-ppcre) ;; REGEXPs
(asdf-install:install :cliki) ;; a whole webserver/wiki
... and much more you can equally install, just
look at www.cliki.net
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Tin Gherdanarra
> Pisin Bootvong wrote:
>
>> Pascal Costanza wrote:
>>
>>> Tin Gherdanarra wrote:
>>>
>>>> A single implementation obsoletes the need for a specification.
>>>> Since Lisp began its career as a family of dialects, standardization
>>>> after the fact was necessary. perl, python or PHP never had this
>>>> problem.
>>>
>>>
>>> They have this problem as well because they are basically all variations
>>> of the same idea.
>>
perl and php. Python has several, but they closely mimick
the original implementation and don't deviate from the
original implementation.
>>
>> What variation of the same idea do they have in common, "being touring
>> equivelent"? (And what makes same idea not count in Common Lisp?)
>>
>> Are there ongoing process in the community to unified Perl/Python/PHP
>> into one single language named CommonP? :D
>
>
> Yes, that's what Parrot is going to be: A single language with skinnable
> syntax. Just like .NET. ;)
>
Don't hold your breath for that one.
>>> Why do you think they are working on Parrot?
>>
>>
>> Parrot is a Virtual Machine. They want to make a virtual machine that
>> has bytecode and architecture that is friendly to dynamic-type
>> language. From what I heard, JVM favors static type language, as well
>> as CLR. Although CLR 2 may support better of dynamic-type language.
>
>
> What those virtual machines do is that they actually provide high-level
> constructs (for example, an object model in the sense of OOP). A
> language that targets one of those VMs can either buy into that model,
> making it essentially just a different surface syntax for the same
> language, or it can try to work around the given model to better
> implement its own idea what the model should look like. But this will
> give you a number of disadvantages that stem from the fact that you are
> incompatible with the "native" model.
Right. Parrot fails to reconcile these object models. See next post.
>
> As an extreme case, consider porting Haskell to one of those virtual
> machine while staying completely free of side effects. Common Lisp
> typically also has problems targetting such VMs because some of its
> design decisions are not widely shared.
>
I think it is impossible to reconcile CLOS with C#'s object model,
deeply ingrained in the CLR. Since the CLR is Turing-complete,
you can build a Lisp with CLOS on it, but it will be very hard
to derive a CLOS class from a C# class, for example.
>>> If these languages were indeed so different then it wouldn't be
>>> possible to
>>> define a single virtual machine for them.
>>
It is always possible, but it probably hurts. JPython, the python
compiler for the jvm, hurts pretty good. What's funny is that
the only vm that can cons is the obscure inferno vm. Lisp is not
on the radar for the designers.
>>
>> Then I would say, C, Assembly, Java and **LISP** is not so different
>> since it is possible to define a single virtual machine for them, an
>> x86 machine.
>
This is like saying that an x86 is not so different from a
AMD 29k because both are made from transistors.
>
> An x86 machine is different from such VMs in the sense that it
> instruction set is neutral and doesn't assume specific language models.
>
>>> Why don't you simply ask questions like "Which CL implementation comes
>>> with a built-in socket library?"
>>
>>
>> To be honest, there are differences between
>>
>> import socket
>>
>> and
>>
>> #+clisp(require 'socket)
>> #+sbcl(require 'sb-bsd-socket)
>> #+cmucl(require 'sb-bsd-socket)
>> ...
>>
>> And how each API have to be called in each implementation, that's the
>> point.
>
My original question was:
I'm under the impression
that not much has changed in terms of technology and
community efforts. Peter Seibel's admirable book and
promising current gardeners-project is the only exception,
but I might have missed something. If so, what?
>
> Again, you are comparing a single-implementation language against a
> specification. No matter how hard you try to standardize libraries,
> there will always be open ends. If you don't like this, the way out is
> to choose one particular implementation and forget about the others. Or
> switch to one of the Lisp dialects that effectively have only one
> implementation.
>
> It doesn't make sense to suggest that all Common Lisp implementations
> should be collapsed into a single one. It won't happen anyway.
>
I did not suggest that. I was talking about collapsing various
important libraries into a single one. I was not demanding it,
I just said that perl and python and php have that, and it works
very well for them.
>> One of the goal of CL is poratbility, isn't it?
>
>
> Right.
>
>> [see Dave Roberts' Socket API Proposal:
>> http://www.findinglisp.com/papers/sockets-analysis-0-2-5.pdf]
>> Anyway, one can always find some portable socket library to use,
>> trivial-socket for instances. And things will hopefully improve in the
>> future.
>
>
> Yes. BTW, things don't improve by themselves - it requires people to
> devote their valuable time into improving the situation. These people
> exist, and as far as I can tell they are doing a pretty good job given
> the constraints of the comparatively small Common Lisp community.
>
>> By the way, I'm starting to feel that, like the fact that every
>> programming language is touring equivelant, every language is also
>> portable.
>
>
> You mean "Turing equivalent". No, not every programming language is
> Turing equivalent, and this doesn't relate to portability.
>
Perl is turing-complete?
Tin Gherdanarra
> Pascal Costanza <p...@p-cos.net> wrote:
> +---------------
> | Tin Gherdanarra wrote:
> | > import sockets
> ...
> | Why don't you simply ask questions like "Which CL
> | implementation comes with a built-in socket library?"
>
> He probably wouldn't like the answer: "All of them."
It's not polite to refer to people participating in a
conversation as "he".
I originally asked a very different question:
I'm under the impression
that not much has changed in terms of technology and
community efforts. Peter Seibel's admirable book and
promising current gardeners-project is the only exception,
but I might have missed something. If so, what?
>
>
> -Rob
>
> -----
> Rob Warnock <rp...@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>
André Thieme
> Wade Humeniuk wrote:
> > Tin Gherdanarra wrote:
> >
> >>
> >> You are stating the obvious, but at this time it means freedom from
> >> something as easy as
> >>
> >> import sockets.
> >>
> >
> > What's a socket? CL does not have sockets, it has streams.
>
> So where is my
>
> (require 'tcpip-streams)
>
> then?
What do you miss since Grahams article? What libraries are you missing?
What implementation are you using?
Have you checked the manual of your specific implementation if it
supports your tcpip-streams?
At least Lispworks, Allegro, SBCL and CMUCL support what you want. And
I believe that CLisp can do it too, and why not Corman Lisp?
I like your idea: you want to bring up some healthy critizim. Science
works that way. People should always be allowed to critizie
ideas/theories or progresses. What I miss is concrete material. I would
like to see detailed critizism from you. Now you mentioned your sockets
and were proven that they are there. You must admit that if you act
logically on this issue and not too emotional (like some other people
did in this thread).
In science it often happens that scientists say, "You know, that's a
really good argument, my position is mistaken," and then they actually
change their minds, and you never hear that old view from them again.
They really do it. It doesn't happen as often as it should, because
scientists are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like that happened
in politics or religion.
[Carl Sagan]
André
--
Ulrich Hobelmann
> The parrot projects is stalled, or so it seems. The
> parrot vm is fairly advanced and build on good ideas.
The one thing about it that I remember is that they liked the idea of
being not stack-based, but register-based. To me it sounds like they
have to fix a number of registers then, and including explicit spilling
into the architecture; something that a stack VM would nicely avoid.
>> Why have a virtual machine at all?
>
> It simplifies the compiler. The resulting binary can be
> run anywhere, just rewrite the core of the vm.
> Writing a good debugger is much easier for a vm than
> for a native CPU.
That's a good point, yes. But I'm thinking that exchanging compiler
backends can't be that hard, either, and interpreters can also debug.
But the VM has a purpose there.
>> It's only slow,
>
> There is virtually no practical application for fast
> computer programs.
Well, but if there's no reason, I'd rather run native code than use the
VM as a public (i.e. not easily changed) intermediate code representation.
>> VMs aren't useful in themselves, only if they bring good advantages.
>> I don't see what advantage Parrot could bring, other than being a
>> faster-than-now Perl. Lisp has other VMs or runs natively, as do
>> other languages. Why *one* VM?
>
> One VM for Lisp, python, perl and more languages would be the coolest
> thing since electricity. You could link Lisp, python, perl and more
> vm object code together. Unfortunately, the different understanding of
> classes, instances and run-time type information gets in the way
> and make this utopian world impossible.
Yes. It's not the instruction set that's the problem, but the whole
linking assumptions, the object model etc.
>>> Then I would say, C, Assembly, Java and **LISP** is not so different
>>> since it is possible to define a single virtual machine for them, an
>>> x86 machine.
>
> You are right. In 10 years there will be just one hardware-platform:
> Intel. And hundreds of incompatible virtual machines running on
> it.
Probably. They seem to be the new fashion, especially now that people
say that they have nice code density and might - because of caching -
actually perform better than native code. Still, I miss better OS
constructs or application frameworks, not better languages or VMs.
>> That's the most commonly used VM, indeed. And it's pretty fast, too,
>> so it only underlines my position, that we don't need more VMs.
>>
>
> You are probably an sbcl-driver, right?
No, I'm happy with OpenMCL so far. It's a quick and easy install, and
they say it has threads when I need them (SBCL on the Mac doesn't yet).
I don't need superfast code. I just don't see why we need many more
VMs, that's all. ;)
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>>>> of a single implementation (as with perl) who integrates
>>>> contributions into a distribution.
>>>
>>>
>>> You make the same category error like most other people who have
>>> stated similar things like you in the past. ANSI Common Lisp is a
>>> specification, not an implementation. End of story.
>>
>>
>> Yes. That's in contrast to perl and python that have no
>> specification, just an implementation that is some sort
>> of the borg assimilating modules, thus discouraging writing
>> another modules with overlapping function. Common Lisp does have a
>> specification, so there are various independent implementations
>> resultin in fragmentation.
>
>
> Any language that is based on a specification has what you call
> "fragmentation". You can't have the cake and eat it at the same time.
Since software is an intangible product that can be copied easily
you CAN have the cake and eat it at the same time. C has a
specification, too. Where is common lisp's POSIX?
>
>>> Of course there are maintainers of single implementations. Each
>>> Common Lisp implementation has at least one, and each Common Lisp
>>> implementation comes with a far richer set of libraries than what is
>>> specified in ANSI Common Lisp. Just go with the one that best suits
>>> your needs.
>>
>>
>> It's not just my needs. It's something like
>>
>> import sockets
>
>
> You haven't looked closely enough.
You are right. Another correspondent has pointed to trivial-sockets.
But this was just one example. And there are several socket-libs.
>
>>> Many people here agree that having a common specification is a good
>>> thing.
>>
>>
>> It IS a good thing, but there are some blanks and various attempts
>> to fill in the blanks. The standard was an attempt to unify various
>> successful Lisps in order to avoid duplication of effort in the
>> future and make Lisp more popular. This has not worked out so far.
>
>
> The standardization of ANSI Common Lisp has followed a number of very
> specific and concrete goals. They are listed in "Common Lisp, the
> Language - 2nd Edition" by Guy Steele et al. in Chapter 1.1. You can
> download that book from
> http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html
>
> The goals are commonality, portability, consistency, expressiveness,
> compatibility, efficiency, power and stability.
>
> From that chapter:
>
> "There are now many implementations of Common Lisp, some programmed by
> research groups in universities and some by companies that sell them
> commercially, and a number of useful programming environments have
> indeed grown up around these implementations. What is more, all the
> goals stated above have been achieved, most notably that of portability.
> Moving large bodies of Lisp code from one computer to another is now
> routine."
>
> And from the introduction to that book:
>
> "Common Lisp has succeeded. Since publication of the first edition of
> this book in 1984, many implementors have used it as a de facto standard
> for Lisp implementation. As a result, it is now much easier to port
> large Lisp programs from one implementation to another. Common Lisp has
> proved to be a useful and stable platform for rapid prototyping and
> systems delivery in artificial intelligence and other areas. WIth
> experience gained in using Common Lisp for so many applications,
> implementors found no shortage of opportunities for innovation. One of
> the important characteristics of Lisp is its good support for
> experimental extension of the language; while Common Lisp has been
> stable, it has not stagnated."
>
That's all very okay and probably an improvement over the state of
affairs when MacLisp and Interlisp competed for the hacker's hearts,
but in the meantime interesting things have happened. It is a world
of open source hackers now. CL is on the periphery of what's happening
on the internet in terms of open source software.
> Common Lisp is indeed one of the few languages that has met its goals.
> They may not be your goals, but that's a secondary issue. Especially,
> popularity was not among the goals.
>
A language that's not popular has a problem because it means that
it can't compete for hearts and minds. And hearts and minds is where
a language gets its life from. In the case of Lisp that's unfortunate
because I think it has deserved more than a small community.
>>> Many also agree that having more common de-facto standard libraries
>>> is also a good things, and they are successfully working on them. If
>>> you don't agree with them and prefer a single implementation, there's
>>> noone stopping you from choosing exactly one implementation and
>>> forgetting about the rest.
>>
>>
>> Not so fast. Choice and competing implementations precluded
>> Unix from becoming an OS monopoly. Things changed considerably when
>> Linus Torvalds hijacked the Minix community and a large part of
>> the community decided that it was a worthy project to invest into.
>> Don't you think that this is a good thing, too?
>
>
> I am absolutely against monopolies because that stifles innovation in
> the long run. Computer science and IT in general is currently in a very
> bad shape because of such "monopolies". I am very happy that there are
> some corners where people share very different values.
You should be careful what you are saying because this is a
controversial issue. Fragmentation and a high barrier of entry
is what made Unix loose and Microsoft win. Everybody - and this
includes Bill and Stevo, I kid you not - expected to inherit the
mantle of DOS eventually. It did not happen because in 1990 Unix
not only was infighting for dominance in the Unix-Market, but
most implementations DID suck. The monopolies of idiocy you despise
so much are a consequence of "The Cleverer Give In". I mean,
it's probably okay to loose against a corporate-powered Visual Basic
steamroller, but how could it happen that perl - with a lot less
premise than Common Lisp, mind you - walked away with a thousand
times larger user-base? It gives me the rabies sometimes -- good for
you if you are less worked up about this phenomenon.
>
>
> They have this problem as well because they are basically all variations
> of the same idea. Why do you think they are working on Parrot? If these
> languages were indeed so different then it wouldn't be possible to
> define a single virtual machine for them.
>
Funny you'd mention it -- they hit a brickwall because those
languages are not similiar enough.
>> Actually, all I wanted to know was whether you guys notice
>> improvement in Lisp's mindshare and lower barrier to entry.
>
>
> Absolutely yes!
>
May I ask for some pointers, perhaps? Anything is welcome.
>> And now I'm sitting here, arguing over implementation vs. specification
>> and being called all sorts of things.
>
>
> You're stating things that are considered to be wrong by many people
> over here. You should be able to cope with that.
>
I hope you appreciate my stamina in this mess. However, if it
goes on like this it will push me over the top and I might
end up as a swearing, sobbing alt.angst-er.
Vagif Verdi
>>>Java is portable because you can do "new Socket()" on any platform.
>>>Python is portable you can do socket.open on any platform.
>>>Common Lisp is portable because you can do
>>>#+sbcl(...)#+clisp(...)#+cmucl(...)
I disagree. Portable code is code without knowlegde of the platform it
is gonna run on.
Java programmer writing new Socket() does not give a darn wherther this
code gonna run on linux, solaris, or windows. Whether it is gonna run
on suns jvm, or ibms or jrockit.
In Comon Lisp code you have to deliberately think about which platforms
it is gonna run, and specificly say what to do in each particular case.
This is not portable code. Common lisp IS NOT PORTABLE.
I'm saying it because i'm trying to run UCW on windows. I tried it with
clisp - no luck.
I tried it with ACL - no luck.
Every time different issues in different libraries.
André Thieme
> I originally asked a very different question:
>
> I'm under the impression
> that not much has changed in terms of technology and
> community efforts. Peter Seibel's admirable book and
> promising current gardeners-project is the only exception,
> but I might have missed something. If so, what?
in no particular order
CLisp now produces .exe files,
SBCL is working under windows,
CFFI,
Compilers produce faster code,
AllegroServe (and portable AllegroServe),
Araneida,
AllegroCache (does Python or Ruby have that??),
Slime,
Lisp movies,
UnCommon Web,
SOAP support for Webservices,
Cells,
wxCL,
asdf-install,
reg ex (cl-ppcre),
etc., etc., etc.
You see? You don't have to worry, there have been many improvements.
André
--
Pascal Costanza
>> It doesn't make sense to suggest that all Common Lisp implementations
>> should be collapsed into a single one. It won't happen anyway.
>>
> I did not suggest that. I was talking about collapsing various
> important libraries into a single one.
Which one are you missing?
André Thieme
> In Comon Lisp code you have to deliberately think about which platforms
> it is gonna run, and specificly say what to do in each particular case.
> This is not portable code. Common lisp IS NOT PORTABLE.
> I'm saying it because i'm trying to run UCW on windows. I tried it with
> clisp - no luck.
> I tried it with ACL - no luck.
> Every time different issues in different libraries.
I think you oversimplyfy your position. You state how something is
working in general (CL --> not portable). And why isn't it? Because you
tried to get one programm running and it didn't work. Not exactly a
scientific procedure.
By analogy I could tell you that airplanes can't crash because the last
time I sat in one it didn't.
I understand that you are frustrated about that. When I want to run
some code and it doesn't work I am also not happy about it. Anyway, in
general CL code is pretty portable and even more so if the author is
interested in portability. Sometimes it just is a bit complicated and
not doable for the beginner.
André
--
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>> The parrot projects is stalled, or so it seems. The
>> parrot vm is fairly advanced and build on good ideas.
>
>
> The one thing about it that I remember is that they liked the idea of
> being not stack-based, but register-based. To me it sounds like they
> have to fix a number of registers then, and including explicit spilling
> into the architecture; something that a stack VM would nicely avoid.
You are right. To be more specific, a vm should have no registers
but work as a memory-memory-memory machine (like
[3000] := [1000] + [2000]) This is more or less how a generic
compiler sees code before it passes interim code for a
cpu with an infinite number of registers to the backend that
creates the actual code. Such interim code is ideal for JIT-compilation
because the JIT compiler more or less works like the backend
for such a compiler. The difference is that the interim code
can be run WITHOUT compiling, and it can be run pretty fast.
There are some finesses when it comes to abstract memory-handles
that are subject to garbage-collection, but these problems
have been solved a while ago or so it seems.
>
>>> Why have a virtual machine at all?
>>
>>
>> It simplifies the compiler. The resulting binary can be
>> run anywhere, just rewrite the core of the vm.
>> Writing a good debugger is much easier for a vm than
>> for a native CPU.
>
>
> That's a good point, yes. But I'm thinking that exchanging compiler
> backends can't be that hard, either, and interpreters can also debug.
> But the VM has a purpose there.
One thing a vm can do well, albeit slowly, is memory protection
and type-checking at runtime. This is not as easy to duplicate for
for native-code executables. Since all programs are buggy all
the time and a lot can go wrong at runtime, you want any help
you can get when debugging at runtime. With a vm, you can plug
a programmable virtual in-circuit-emulator and an oscilloscope
into your virtual electronics. This slows down execution but
speeds up development.
>
>>> It's only slow,
>>
>>
>> There is virtually no practical application for fast
>> computer programs.
>
>
> Well, but if there's no reason, I'd rather run native code than use the
> VM as a public (i.e. not easily changed) intermediate code representation.
>
I'm not sure if I understand what you mean, but that's probably where
the JIT-compiler comes into play, or a vm-to-real-cpu-compiler. It's
probably seductive to remove virtual waterwings after a while, but
I don't think I would do that if it is my server application, for
example. If I'm running my next big viaweb (that's the application
that made Paul Graham a millionaire), I'd rather have a fully
scrutinized slow CPU than a fast native CPU that runs my application.
If something goes wrong, and this is guaranteed to happen, I want
to react swiftly to avoid lossage of customers. Shrink-wrapped
applications are different matter, at least when it comes to
today's priorities, but this, too could change in the future.
Maybe users will want to run their apps in a sandbox, too.
>>> VMs aren't useful in themselves, only if they bring good advantages.
>>> I don't see what advantage Parrot could bring, other than being a
>>> faster-than-now Perl. Lisp has other VMs or runs natively, as do
>>> other languages. Why *one* VM?
>>
>>
>> One VM for Lisp, python, perl and more languages would be the coolest
>> thing since electricity. You could link Lisp, python, perl and more
>> vm object code together. Unfortunately, the different understanding of
>> classes, instances and run-time type information gets in the way
>> and make this utopian world impossible.
>
>
> Yes. It's not the instruction set that's the problem, but the whole
> linking assumptions, the object model etc.
>
How depressing.
>>>> Then I would say, C, Assembly, Java and **LISP** is not so different
>>>> since it is possible to define a single virtual machine for them, an
>>>> x86 machine.
>>
>>
>> You are right. In 10 years there will be just one hardware-platform:
>> Intel. And hundreds of incompatible virtual machines running on
>> it.
>
>
> Probably. They seem to be the new fashion, especially now that people
> say that they have nice code density and might - because of caching -
> actually perform better than native code.
That's very well possible because a layer of emulation slows
execution down by approximately the same factor as accessing
memory not in the cache. This balance will shift to and fro
several times in the future, as it did in the past. Caches will
get bigger, buses will get faster, transistors will hit a
brick-wall, fiber-optic buses, quantum-entanglement, telepathy --
it's hard to tell where we will end up with parrot.
> Still, I miss better OS
> constructs or application frameworks, not better languages or VMs.
>
Application frameworks are several floors above any vm-issues.
And I guess there is next to no overlap between people doing apps
or frameworks and people doing vms. So it is not likely that the
vm-people are wasting their time for more urgent things because
they would not know how to build frameworks anyway.
>>> That's the most commonly used VM, indeed. And it's pretty fast, too,
>>> so it only underlines my position, that we don't need more VMs.
>>>
>>
>> You are probably an sbcl-driver, right?
>
>
> No, I'm happy with OpenMCL so far. It's a quick and easy install, and
> they say it has threads when I need them (SBCL on the Mac doesn't yet).
>
And it compiles to native code? Interesting.
> I don't need superfast code. I just don't see why we need many more
> VMs, that's all. ;)
>
It's a phase of experimentation. Everybody has better ideas.
Tin Gherdanarra
> Tin Gherdanarra schrieb:
>
>
>>I originally asked a very different question:
>>
>>I'm under the impression
>>that not much has changed in terms of technology and
>>community efforts. Peter Seibel's admirable book and
>>promising current gardeners-project is the only exception,
>>but I might have missed something. If so, what?
>
>
> in no particular order
> CLisp now produces .exe files,
> SBCL is working under windows,
> CFFI,
> Compilers produce faster code,
> AllegroServe (and portable AllegroServe),
> Araneida,
> AllegroCache (does Python or Ruby have that??),
> Lisp movies,
> UnCommon Web,
> SOAP support for Webservices,
> Cells,
> wxCL,
> asdf-install,
> reg ex (cl-ppcre),
> etc., etc., etc.
>
>
> You see? You don't have to worry, there have been many improvements.
Are you sure these have come up in the last five years?
> Slime,
> wcCL,
> asdf-install
> regex
>
>
> André
> --
>
André Thieme
> Are you sure these have come up in the last five years?
> > Slime,
In september 2003 Luke Gorrie explained that Slime is usable. It seems
to me that a usable version did not exist too many years before his
posting.
> > wxCL,
This project exists since a long time. But the first anouncement of its
availability on c.l.l was on 19 Aug. 2005 02:20 by Robert Uhl.
> > asdf-install
The first time "asdf-install" was mentioned on comp.lang.lisp was 15
Okt. 2003 20:10 in a post by David Steuber. It might have been
available for a much longer time, but then I am curious why nobody ever
mentioned it.
asdf on the other hand is available for a longer time.
> > regex
I was talking about cl-ppcre. Edi Weitz has posted on this newsgroup
the first time on 4 Feb. 2001 17:10. I did not have the impression that
he already had cl-ppcre finished. If he had I am sure he will jump in
and explain it.
André
--
Robert Uhl
>
> Can you imagine that some people get tired when each new year some
> newbie wants the Lisp community to to be like he expects it to be?
>
> You are like a runner, seeing a hurdle, running full-speed against
> this hurdle and protesting that actually there is this hurdle. But it
> is part of the race, and you could have jumped over it. Some even jump
> over it elegantly.
There's a hurdle, yes. And if the race were about hurdles, then that
would be appropriate. But is it? Is the point of programming to keep
on reinventing the wheel?
Methinks that the fact that folks keep on saying the same thing should
lead one to wonder if perhaps they're on to something. Sure, they could
all be wrong, or unintelligent, or failing to appreciate one factor or
another--but they could also have a point.
> Or once you get over it, you can choose that Lisp implementation that
> fits your needs best and stay with it. Just close your eyes and
> pretend there are no other Lisps. Then you have a single
> implementation.
This works, but in the Python (or Perl, or Ruby) world one gets to enjoy
a large community of coders all writing Python (or Perl, or Ruby); the
SBCL community is small; the LispWorks community is relatively small and
so forth. It's _nice_ when someone else has already done the work...
And yes, the answer is for folks to sit down and knock out the stuff
that needs to be done; yes, too, that this is already being done. But
it's not done yet--everyone who wants it done, should quit whining and
do it; everyone else should recognise that at the moment, for the
programmer who wants to be able to hit the ground running, Lisp doesn't
seem to be quite there.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Modern art is what happens when painters stop looking at girls and
persuade themselves that they have a better idea. --John Ciardi
Edi Weitz
> I was talking about cl-ppcre. Edi Weitz has posted on this newsgroup
> the first time on 4 Feb. 2001 17:10. I did not have the impression
> that he already had cl-ppcre finished. If he had I am sure he will
> jump in and explain it.
CL-PPCRE was first released on December 12, 2002, and it was written
in the two months before that.
Of course, if the OP weren't just trolling he could check change logs
and other sources of information himself.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Cameron MacKinnon
> I like your idea: you want to bring up some healthy critizim. Science
> works that way. People should always be allowed to critizie
> ideas/theories or progresses. What I miss is concrete material. I would
> like to see detailed critizism from you. Now you mentioned your sockets
> and were proven that they are there. You must admit that if you act
> logically on this issue and not too emotional (like some other people
> did in this thread).
The unfortunate truth is that the Original Troll has a point. It isn't
original or new but, since it isn't being addressed, it is going to keep
being brought up, and c.l.l's collective response to it will continue to
feel unsatisfying to those who bring it up.
It isn't that sockets libraries are available. It's that a fair number
of newbies apparently have trouble finding them, there's no one
standard, and composing/integrating several sockets-using packages
(which use different compatibility layers) leads to bloated, obfuscated
code (in the best case). This applies equally to various other things
which are now considered infrastructure, and the problem is
multiplicative, not additive.
I've argued from the OT's point of view in the past, in this thread:
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/919d5ed40b3272d
...where I think c.l.l did a very good job of exposing the issues and
debating them intelligently and eloquently, from both sides.
I don't hold out much hope that the community is going to solve this
problem in the near term, mainly because its elders are (virtually by
definition) people who have surmounted the problem in their own work.
I'm still here because I believe Lisp to be my best choice (by far) in
spite of these issues, not because I believe they don't exist. People
like the OT (though with variations in the coherence/abrasiveness
continuum) will continue to show up here, and our usual response of
clapping our hands over our ears and insisting that Lisp works for us
isn't likely to get any more satisfying.
funkyj
> alessi...@gmail.com writes:
>
> > Every major CL implementation has its own library for, say, sockets.
> [...]
> > I feel that having the possibility to choose in this case isn't very
> > profitable. You should be able to choose between different
> > *implementations*, not different *interfaces* to the same thing! Of
> > course this is not always possible, but for trivial/low-level libraries
> > I don't think it's so difficult to achieve.
>
> You might try:
>
> (asdf-install:install :trivial-sockets)
>
> LispWorks, OpenMCL and SBCL.
I tried it with clisp (cygwin) and it failed (see output below). I'm
guessing that the clisp 2.35 distribution does not include "asdf" and
that I must download and install it. Ditto for "trivial-sockets"?
I doubt the fact that I'm using 2.35 and the latest clisp is 2.38 is
the problem.
does your
> (asdf-install:install :trivial-sockets)
work, out of the box, for the other distributions above (e.g. SBCL,
CMUCL) or do they also require the usual 3rd party package download
and install procedure for "asdf" and/or "trivial-sockets"?
Regards,
--jfc
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; clisp output
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(19:0) $ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2005
[1]> (asdf-install:install :trivial-sockets)
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO TERMINAL-STREAM>>
: there is no package with name "ASDF-INSTALL"
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]> :q
[3]> (quit)
Bye.
(20:0) $ clisp --version
GNU CLISP 2.35 (2005-08-29) (built on
winsteingoldlap.ad.alphatech.com [10.41.52.182]
)
Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type
-Wmissing-declarat
ions -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE
-DDYNAMIC_FFI -I. -x n
one -lintl libcharset.a libavcall.a libcallback.a -lreadline
-lncurses -liconv -L/us
r/local/libsigsegv-cygwin/lib -lsigsegv -L/usr/X11R6/lib -lX11
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.2
libiconv 1.9
Features:
(REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL
COMMON-LISP LISP=CL
INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
GETTEXT UNICODE
BASE-CHAR=CHARACTER PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /usr/lib/clisp/
User language: ENGLISH
Machine: I686 (I686) jcano-lt.jnpr.net [172.24.145.215]
d...@telent.net
> > > asdf-install
>
> The first time "asdf-install" was mentioned on comp.lang.lisp was 15
> Okt. 2003 20:10 in a post by David Steuber. It might have been
> available for a much longer time, but then I am curious why nobody ever
> mentioned it.
It was first hacked together in June 2003 -
http://ww.telent.net/diary/2003/6/#4.11945
> asdf on the other hand is available for a longer time.
But still postdates CLiki. August 2001, according to the cvs revision
history.
-dan
Ron Garret
Cameron MacKinnon <cmack...@clearspot.net> wrote:
> André Thieme wrote:
> > I like your idea: you want to bring up some healthy critizim. Science
> > works that way. People should always be allowed to critizie
> > ideas/theories or progresses. What I miss is concrete material. I would
> > like to see detailed critizism from you. Now you mentioned your sockets
> > and were proven that they are there. You must admit that if you act
> > logically on this issue and not too emotional (like some other people
> > did in this thread).
>
> The unfortunate truth is that the Original Troll has a point. It isn't
> original or new but, since it isn't being addressed, it is going to keep
> being brought up, and c.l.l's collective response to it will continue to
> feel unsatisfying to those who bring it up.
>
> It isn't that sockets libraries are available. It's that a fair number
> of newbies apparently have trouble finding them, there's no one
> standard, and composing/integrating several sockets-using packages
> (which use different compatibility layers) leads to bloated, obfuscated
> code (in the best case). This applies equally to various other things
> which are now considered infrastructure, and the problem is
> multiplicative, not additive.
And newbies aren't the only ones facing this problem. I would love to
use Lisp, and I am in a position where it is my call, but I cannot in
good conscience use it because from a strategic business perspective it
presents more problems than it solves.
Notwithstanding its core technical superiority, Lisp will continue to
wallow in commercial obscurity until someone starts treating it like a
business where outsiders are customers, instead of the current approach
which seems to be more like a fraternity with outsiders as pledges.
rg
Tin Gherdanarra
> Tin Gherdanarra wrote:
>
>> Rainer Joswig wrote:
>>
>>> Then you should provide more specific questions?
>>
>>
>> There you go:
>>
>> I'm under the impression
>> that not much has changed in terms of technology and
>> community efforts. Peter Seibel's admirable book and
>> promising current gardeners-project is the only exception,
>> but I might have missed something. If so, what?
>
>
> Quite a lot. (That answer is as specific as your question.)
(asdf:asdf-install 'trivial-sockets) works on SBCL. I have
tried the same on clisp-2.33.2 on Windows. It does not
work. I did the following.
0.) Went to cliki.net and searched for "asdf".
1.) Followed the link to the asdf cvs repository
2.) Opened the asdf.lisp source code and asdf-install.lisp source code
3.) Copy-pasted both sources into files named asdf-install.lisp
and asdf.lisp.
4.) Incanted (load "asdf.lisp")
5.) Incanted (load "asdf-install.lisp") and got an error:
"sb-posix does not exist"
6.) When I checked the sources there was
(require 'asdf)
(require 'sb-posix)
(require 'sb-executable)
(require 'sb-bsd-sockets))
7.) A quick check on my harddisk revealed that these
sources are not on my computer.
8.) Faced with the task to find "sb-posix.lisp", "sb-executable.lisp"
and "sb-bsd-sockets.lisp" on the web and copy-paste them
into files with my editor, I decided to postpone everything
to tomorrow. Or whenever.
I mean, you will probably flame me for my ineptitude and
gross incompetence, but isn't this somehow what we've been
talking about here all the time? In other words: doesn't this pretty
much suck compared to python or perl? Please note that this is
not an issue whether I like it or not or whether I'm an idiot
or not or whether I should go and use python instead.
At least not only. This is what pisses people off from Lisp
and I think that's very unfortunate because Lisp would deserve
better. Say it ain't so because you are set with how Lisp feels
and are all happy campers, but this does not change the fact
that Lisp has a problem when it comes to attracting new
happy campers. And that's bad because the more the merrier.
Tin Gherdanarra
Wade Humeniuk
>
> And newbies aren't the only ones facing this problem. I would love to
> use Lisp, and I am in a position where it is my call, but I cannot in
> good conscience use it because from a strategic business perspective it
> presents more problems than it solves.
>
> Notwithstanding its core technical superiority, Lisp will continue to
> wallow in commercial obscurity until someone starts treating it like a
> business where outsiders are customers, instead of the current approach
> which seems to be more like a fraternity with outsiders as pledges.
>
Are you saying that LispWorks, Corman and Franz Inc. do not treat Lisp like
a business and people like customers?
Wade
Edi Weitz
> [...] clisp-2.33.2 on Windows [...]
>
> 5.) Incanted (load "asdf-install.lisp") and got an error:
> "sb-posix does not exist"
Google for ASDF-INSTALL and click on the first link. That should
explain why it behaves differently on CLISP.
> In other words: doesn't this pretty much suck compared to python or
> perl?
Yes. I don't think Perl's infrastructure originated from Usenet
whining, though. And as you seem to use Windows - where do you think
would Perl on Windows be today without a commercial entity like
ActiveState behind it (not to mention O'Reilly)?
Kaz Kylheku
> 2 Pisin Bootvong
>
> >>>Java is portable because you can do "new Socket()" on any platform.
> >>>Python is portable you can do socket.open on any platform.
> >>>Common Lisp is portable because you can do
> >>>#+sbcl(...)#+clisp(...)#+cmucl(...)
>
> I disagree. Portable code is code without knowlegde of the platform it
> is gonna run on.
That is a rather naive, academic conception of portability. It's a
useful concept when we are discussing the semantics of a standard
language. What constitutes a maximally portable, ANSI conforming
program, that sort of thing.
In practice, if a program is easily /targettable/ to platforms, then
it's portable.
Should UNIX not have been called portable?
Was Johnson wrong to name his program "Portable C Compiler"?
:)
> Java programmer writing new Socket() does not give a darn wherther this
> code gonna run on linux, solaris, or windows.
And it shows.
> In Comon Lisp code you have to deliberately think about which platforms
> it is gonna run, and specificly say what to do in each particular case.
Not for everything.
> This is not portable code. Common lisp IS NOT PORTABLE.
If we take a rigid definition of Common Lisp, if it contains
nonportable constructs, it's not Common Lisp.
André Thieme
No no, I will just forward you to a how-to:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/cclan/asdf-install/doc/index.html
André
--
Tin Gherdanarra
> On Mon, 30 Jan 2006 23:54:03 +0100, Tin Gherdanarra <tinma...@gmail.com> wrote:
>
>
>>[...] clisp-2.33.2 on Windows [...]
>>
>>5.) Incanted (load "asdf-install.lisp") and got an error:
>> "sb-posix does not exist"
>
>
> Google for ASDF-INSTALL and click on the first link. That should
> explain why it behaves differently on CLISP.
for import sockets I don't need to google, if you catch my
drift.
>
>
>>In other words: doesn't this pretty much suck compared to python or
>>perl?
>
>
> Yes. I don't think Perl's infrastructure originated from Usenet
> whining, though.
> And as you seem to use Windows -
> where do you think
> would Perl on Windows be today without a commercial entity like
> ActiveState behind it (not to mention O'Reilly)?
>
O'Reilly her! Commercial entity her!
Pascal Costanza
> Pascal Costanza wrote:
>
>> I am absolutely against monopolies because that stifles innovation in
>> the long run. Computer science and IT in general is currently in a
>> very bad shape because of such "monopolies". I am very happy that
>> there are some corners where people share very different values.
>
> You should be careful what you are saying because this is a
> controversial issue.
I know that this is a controversial issue.
>>> Actually, all I wanted to know was whether you guys notice
>>> improvement in Lisp's mindshare and lower barrier to entry.
>>
>> Absolutely yes!
>>
> May I ask for some pointers, perhaps? Anything is welcome.
http://common-lisp.net/
http://www.cl-user.net/
http://wiki.alu.org/
Cameron MacKinnon
> Are you saying that LispWorks, Corman and Franz Inc. do not treat Lisp like
> a business and people like customers?
As regards the specific topic we've been discussing here,
standardization of infrastructure, people have been inquiring about it
on this NG for years. Either the three named companies have been
discussing harmonization efforts in secret, or they've concluded that
these people are whiners who can safely be ignored without it affecting
their decisions to use commercial Lisps, or they're not treating these
people like potential customers.
Pascal Costanza
> (asdf:asdf-install 'trivial-sockets) works on SBCL. I have
> tried the same on clisp-2.33.2 on Windows. It does not
> work.
Thanks for getting more specific. Yes, you are describing an issue that
hasn't been dealt with yet. There are most certainly people discussing
these issues and working on solutions.
Five years ago, asdf-install didn't exist. I'd call its existence an
improvement.
Pascal Costanza
> I don't hold out much hope that the community is going to solve this
> problem in the near term, mainly because its elders are (virtually by
> definition) people who have surmounted the problem in their own work.
> I'm still here because I believe Lisp to be my best choice (by far) in
> spite of these issues, not because I believe they don't exist. People
> like the OT (though with variations in the coherence/abrasiveness
> continuum) will continue to show up here, and our usual response of
> clapping our hands over our ears and insisting that Lisp works for us
> isn't likely to get any more satisfying.
The actual and concrete problems that do exist are being worked on,
right? Improvements don't come over night, they need steady and
continuous investments of work and time by people. This is definitely
happening.
Ulrich Hobelmann
>> Well, but if there's no reason, I'd rather run native code than use
>> the VM as a public (i.e. not easily changed) intermediate code
>> representation.
>>
> I'm not sure if I understand what you mean, but that's probably where
> the JIT-compiler comes into play, or a vm-to-real-cpu-compiler. It's
> probably seductive to remove virtual waterwings after a while, but
> I don't think I would do that if it is my server application, for
> example. If I'm running my next big viaweb (that's the application
> that made Paul Graham a millionaire), I'd rather have a fully
> scrutinized slow CPU than a fast native CPU that runs my application.
Well, lots of companies are buying lots of big servers for their big
websites. A slow, great, app might be nice for small audiences, but it
won't work for big sites. OTOH, most big companies seem to prefer
buying Java crap anyway ;) (and it's not even fast, so maybe they need
more servers *because* of Java tools!)
> If something goes wrong, and this is guaranteed to happen, I want
> to react swiftly to avoid lossage of customers. Shrink-wrapped
> applications are different matter, at least when it comes to
> today's priorities, but this, too could change in the future.
> Maybe users will want to run their apps in a sandbox, too.
That's true. I don't understand why modern OSes still don't provide
sandboxing by default. If I run a web browser, why does it need *any*
privileges other than the channels it has open by default (i.e. its
window server connection, and a connection to the file server to save
web pages to disk if the user says "ok")? It certainly doesn't need to
run with my full user permissions, and the same goes for everything
else. I also don't want any proprietary crap to run with full
permissions. For that reason I won't ever buy Myst 5 or MS Office for
the Mac; their demos won't even install or run, unless you give them
your admin password (as if it wasn't bad enough that they take more than
a drag-n-drop to de/install).
I think having a sound, mandatory, security inside the OS is better than
having it inside a VM that only *some* programs will use.
> That's very well possible because a layer of emulation slows
> execution down by approximately the same factor as accessing
> memory not in the cache. This balance will shift to and fro
Yes, but the cache loads whole lines, and most instructions will run
much faster than a series of VM instructions. Ok, with JIT things
change, but I don't see why my machine shouldn't compile everything in
advance (or when idle), instead of recompiling on every program startup
/ on demand.
Not all native code has to consist of lots of unrolled loops and
otherwise big, duplicative code (C++ templates?).
> several times in the future, as it did in the past. Caches will
> get bigger, buses will get faster, transistors will hit a
> brick-wall, fiber-optic buses, quantum-entanglement, telepathy --
> it's hard to tell where we will end up with parrot.
True. I'm curious where it will fly.
>> Still, I miss better OS constructs or application frameworks, not
>> better languages or VMs.
>>
> Application frameworks are several floors above any vm-issues.
> And I guess there is next to no overlap between people doing apps
> or frameworks and people doing vms. So it is not likely that the
> vm-people are wasting their time for more urgent things because
> they would not know how to build frameworks anyway.
Yes, totally different domains. Nonetheless I see most current problems
in the lack of total OS integration. It's 2006 and we still work with
sockets and pipes (and \r\n-terminated line protocols). ;)
>> No, I'm happy with OpenMCL so far. It's a quick and easy install, and
>> they say it has threads when I need them (SBCL on the Mac doesn't yet).
>>
> And it compiles to native code? Interesting.
Yes, so far only on PPC/32bit I think. They focused on fast code
generation, so maybe the code isn't optimal, but it's still native and
thus pretty fast I think.
--
Suffering from Gates-induced brain leakage...
Tin Gherdanarra
I only know LispWorks, but their support is very good.
That's not the point, though, because they are living off of it.
Larry Wall (perl) does not, though. He is so concerned with
satisfaction with his language that he busily included every
brain-damaged feature people wanted -- "the customer is always
right". The result is admittedly
questionable at best, but it paid off in form of a large
community. And although he might not be first-class party-materiel
(reading scripture for fun), he knows how to pitch a language
at conferences and captivates his audience with amusing platonic
sound-bites. Maybe it's all common sense, maybe Larry Wall
is a natural marketing genius, but clearly he has been
on a successful jihad to pimp perl to a dominant garbage-collected
language -- what I find remarkable in the light of the fact
that perl is actually a catastrophy. Lisp, on the other hand,
is built on extremely clever concepts, possibly constituting
a theoretical optimum that can't get ANY better, has been built
and polished by several generations of geniuses for decades --
and failed in the market. "Lisp is not more dead than usual"
sounds funny at first but it's not only a laughing matter, at
least not if you are jealous for perl's and PHP's undeserved
success. Living on the fringe and indulging in a rich subculture
is pretty cool, of course, but considered harmful when it
comes to software. Those who have will get. Lenience about
mindshare-issues has given us a race of hucksters -- the
price goes to the technology that sucks most. In other words:
0.) "Hahaha -- look at those XML-pansies! They are re-inventing
S-expressions with an uglier syntax!"
This is because you have to surf the web or make a
complete ass of yourself on c.l.l before you can do
something that requires
import sockets
in python.
1.) "Hahaha -- look at those lex/yacc-jockeys! Toiling away
with grammars when they could just (read) in a form
structuring their data as nested lists!"
This is because you have to surf the web or make a
complete ass of yourself on c.l.l before you can do
something that requires
import sockets
in python.
2.) "Hahaha -- look at those java-monkeys! Getting carpal
tunnel syndrome before they can even start to think
about writing their first bloated for-loop!"
This is because you have to surf the web or make a
complete ass of yourself on c.l.l before you can do
something that requires
import sockets
in python.
3.) "Hahaha -- look at those C#-suckers! They got closure
support LAST YEAR! And no macros yet!"
This is because you have to surf the web or make a
complete ass of yourself on c.l.l before you can do
something that requires
import sockets
in python.
Well, since all those poor lost souls have much less of
a problem finding a pointy-haired boss willing to employ
them and have much less of a problem using sockets, I guess
the last laugh is on them. This is not exactly whining, it
is just heart-breaking to see beautiful Lisp in such a poor
position. For some reason everybody keeps saying I should go
and use python if I don't like Lisp. Or worse. Because
everything is fine.
>
> Wade
Edi Weitz
> I only know LispWorks, but their support is very good. That's not
> the point, though, because they are living off of it. Larry Wall
> (perl) does not, though.
He does. He is paid by O'Reilly for Perl development and evangelism.
Tin Gherdanarra
> On Tue, 31 Jan 2006 00:57:32 +0100, Tin Gherdanarra <tinma...@gmail.com> wrote:
>
>
>>I only know LispWorks, but their support is very good. That's not
>>the point, though, because they are living off of it. Larry Wall
>>(perl) does not, though.
>
>
> He does. He is paid by O'Reilly for Perl development and evangelism.
You are right, but this did not happen before 1999 or so.
Before that Larry had a day-gig as a Sysadmin and perl
his pet-project.
I don't know how Guido van Rossum made python what it is
today, by the way. He was a student when it all started.
I have never heard him talk. Maybe he did nothing at all
but cranking out code and making sure it's easy to work
with.
>
André Thieme
Back to your original question: did something change since Grahams
article.
You got the proof: yes, a lot changed.
Back at the time when Graham wrote his essay tons of libs did not exist
and the free Lisps had less features, etc.
Now that you see that you suddenly changed your point of view. Now you
critizise that these libs are not easy enough to use.
I suggest to look at this issue again in three years. I think we will
have even more libs and cool frameworks and a lot more stuff will run
on most Lisps and on most OSes (mainly windows, linux and mac, maybe
also more solaris support). With your posting you maybe reached one
author who will sit down and make his lib easier to use or write a
better documentation.
André
--
Tin Gherdanarra
I have not changed my view, others have brought up
these issue. This thread has fanned out into all sorts
of discussions, most of them of the "It does -- no it doesn't --
sure it does -- you suck"-type.
>
> I suggest to look at this issue again in three years.
I will call my editor and tell him I won't make the
deadline then.
> I think we will
> have even more libs and cool frameworks and a lot more stuff will run
> on most Lisps and on most OSes (mainly windows, linux and mac, maybe
> also more solaris support).
Anything you say.
> With your posting you maybe reached one
> author who will sit down and make his lib easier to use or write a
> better documentation.
It'd be sad if it took a flamefest to have this effect.
>
> André
> --
>
Ron Garret
Wade Humeniuk <whumeniu+...@telus.net> wrote:
No. The Lisp vendors' customers are not outsiders.
For Lisp to grow it is necessary for someone to take Lisp and *use* it
in a way that provides a competitive advantage *for some economically
viable purpose*, which is to say, for some purpose that is useful to
someone outside of the Lisp microeconomy. It is astonishing that for
all the brains in this community, the vast majority seem unable to grasp
this elementary fact. What made Paul rich was not that he had a
knock-down argument to convince people of Lisp's technical superiority,
but that he was able to use it to provide a useful service to a bunch of
people who neither knew nor cared what Lisp was. What makes PHP popular
is that it's really easy to pull it out of the box and build web sites
with it for people who neither know nor care what PHP is. The only
thing that's easy to do with Lisp out of the box is write Lisp
interpreters. And the only people who care about that are Lisp hackers.
That is not a sustainable economic model.
Not all potential customers will be indifferent. Some will be curious.
Some will be hackers of varying levels of skill. Be that as it may, at
the moment the community seems unable to even *recognize* potential
customers, let alone to treat their concerns with the respect that they
deserve. Until that changes, Lisp will continue to live in
well-deserved exile from the rest of the world.
rg
Wade Humeniuk
>> Are you saying that LispWorks, Corman and Franz Inc. do not treat Lisp like
>> a business and people like customers?
>
> No. The Lisp vendors' customers are not outsiders.
>
> For Lisp to grow it is necessary for someone to take Lisp and *use* it
> in a way that provides a competitive advantage *for some economically
> viable purpose*, which is to say, for some purpose that is useful to
> someone outside of the Lisp microeconomy. It is astonishing that for
You mean like Orbitz?
Wade
Pisin Bootvong
> 2 Pisin Bootvong
>
> >>>Java is portable because you can do "new Socket()" on any platform.
> >>>Python is portable you can do socket.open on any platform.
> >>>Common Lisp is portable because you can do
> >>>#+sbcl(...)#+clisp(...)#+cmucl(...)
>
> I disagree. Portable code is code without knowlegde of the platform it
> is gonna run on.
Well, I already agreed with you, may be you misunderstand me.
I was trying to point out the "portability trap" it looks like when
many people here said one of the major advantage of Common Lisp is that
it's portable. But it's only portable on the algortihm construct.
It's like "Turing Trap".
BrainF*ck language is Turing complete. But Which one would you write
even a simple application in Brainf*ck or (C, Java, Lisp, or even
Assembly).
Many people here said Common Lisp is portable. And it is true. But only
if you don't talk to the outside world, once you start talking to
socket/thread/ffi there is not any standard there. And regarding this,
lisp is inferior in portability to other languages. Lisp the language
is the best, it's implementation and environment is not there yet,
though.
Rich and poor people have equal right to buy the same stuff, it just
require more effort from the poor to get the same thing as the rich.
Which one would you chose to be?
Ron Garret
Wade Humeniuk <whumeniu+...@telus.net> wrote:
> Ron Garret wrote:
>
> >> Are you saying that LispWorks, Corman and Franz Inc. do not treat Lisp like
> >> a business and people like customers?
> >
> > No. The Lisp vendors' customers are not outsiders.
> >
> > For Lisp to grow it is necessary for someone to take Lisp and *use* it
> > in a way that provides a competitive advantage *for some economically
> > viable purpose*, which is to say, for some purpose that is useful to
> > someone outside of the Lisp microeconomy. It is astonishing that for
>
> You mean like Orbitz?
Yes, exactly.
rg
Pascal Costanza
What do you think about the efforts that are put into projects like
common-lisp.net, cl-user.net, the ALU wiki, asdf, asdf-install, the
latest additions to asdf, the various libraries that have come into
existence in recent years, etc. pp.?
Maybe you're too influenced by the very bad shape of Digitool?
Edi Weitz
> For Lisp to grow it is necessary for someone to take Lisp and *use*
> it in a way that provides a competitive advantage *for some
> economically viable purpose*, which is to say, for some purpose that
> is useful to someone outside of the Lisp microeconomy.
And why aren't you this someone? Why are you waiting for others to do
this for you?
> It is astonishing that for all the brains in this community, the
> vast majority seem unable to grasp this elementary fact.
If you're the only one it'll most likely increase your competitive
advantage, so don't try to explain it to us.
FWIW, I'm fine with the money I earn using Lisp. Pays my rent. And
it helps me to overcome the fact that I don't grasp everything.
Espen Vestre
> FWIW, I'm fine with the money I earn using Lisp. Pays my rent.
AOL! And not only my rent, I think it's fair to say that the competive
advantage of lisp is one of the main reasons that my company has
survived in a fierce competition.
And you still find time to be helpful to newbies on c.l.l., so I don't
know what more Ron could ask for. As for me, I'm sorry that I don't
find enough time to do my share of work for the community, but there
are so many new lisp software to write at Netfonds, and a family to
take care of too...
--
(espen)
Paolo Amoroso
> talking about here all the time? In other words: doesn't this pretty
> much suck compared to python or perl? Please note that this is
> not an issue whether I like it or not or whether I'm an idiot
> or not or whether I should go and use python instead.
> At least not only. This is what pisses people off from Lisp
> and I think that's very unfortunate because Lisp would deserve
> better. Say it ain't so because you are set with how Lisp feels
Yes, this does suck. I see only one way out: roll your sleeves and do
something. Some suggestions:
CL Gardeners - Tending the Common Lisp garden
http://www.lispniks.com/cl-gardeners/
Gardeners Projects
http://wiki.alu.org/Gardeners_Projects
If nobody contributes, things are not going to improve, no matter how
much you like Lisp.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso
> Notwithstanding its core technical superiority, Lisp will continue to
> wallow in commercial obscurity until someone starts treating it like a
> business where outsiders are customers, instead of the current approach
> which seems to be more like a fraternity with outsiders as pledges.
In case you didn't notice:
CL Gardeners - Tending the Common Lisp garden
http://www.lispniks.com/cl-gardeners/
Gardeners Projects
http://wiki.alu.org/Gardeners_Projects
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
> What do you think about the efforts that are put into projects like
> common-lisp.net, cl-user.net, the ALU wiki, asdf, asdf-install, the
> latest additions to asdf, the various libraries that have come into
> existence in recent years, etc. pp.?
I think these are positive developments.
> Maybe you're too influenced by the very bad shape of Digitool?
Perhaps, but what I am more influenced by is that in the last ten years
I am aware of only three commercially successful ventures that used
Lisp: viaweb, orbitz, and Espen's company. There is to my knowledge not
a single company today providing contract web development services using
Lisp. Lisp is not even a blip on the commercial radar.
rg
Paolo Amoroso
> Lisp: viaweb, orbitz, and Espen's company. There is to my knowledge not
> a single company today providing contract web development services using
> Lisp. Lisp is not even a blip on the commercial radar.
Lisp-Friendly Web Hosting/Development
http://bc.tech.coop/blog/060112.html
If you need more, just ask.