From: Tin Gherdanarra
Subject: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444gioFbclrU1@individual.net>
Arguably, Paul Graham's essay has been very influential
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.
Tin Gherdanarra wrote:
> Arguably, Paul Graham's essay has been very influential
> 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.
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.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444pb5Fd9ieU1@individual.net>
>
>
> 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.
Tin Gherdanarra schrieb:
> 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.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444uv9Fdp9tU1@individual.net>
······@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.
> 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?
Tin Gherdanarra schrieb:
> ······@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.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <445a4gFf3bbU1@individual.net>
······@corporate-world.lisp.de wrote:
> Tin Gherdanarra schrieb:
>
>
>>······@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.
From: Rainer Joswig
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <C0036D5F.28548%joswig@lisp.de>
Am 30.01.2006 2:58 Uhr schrieb "Tin Gherdanarra" unter
<···········@gmail.com> in ·············@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?
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4474ldFmp9rU1@individual.net>
Rainer Joswig wrote:
> Am 30.01.2006 2:58 Uhr schrieb "Tin Gherdanarra" unter
> <···········@gmail.com> in ·············@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.
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4476l8Fne4cU2@individual.net>
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.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447jmhFr7gnU1@individual.net>
Pascal Costanza wrote:
> 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.
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u1wypz5bu.fsf@agharta.de>
On Mon, 30 Jan 2006 23:54:03 +0100, Tin Gherdanarra <···········@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.
> 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)?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447kqpFqqivU1@individual.net>
Edi Weitz wrote:
> On Mon, 30 Jan 2006 23:54:03 +0100, Tin Gherdanarra <···········@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!
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447lhqFq5i1U2@individual.net>
Tin Gherdanarra wrote:
> (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
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Andrew Cristina
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <qaXDf.334656$0l5.108599@dukeread06>
Pascal Costanza wrote:
> Tin Gherdanarra wrote:
>
>> (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.
>
If you mean getting asdf-install to work on clisp on win32 platforms, I
claim to have this working (not to say that it works amazingly well or
is a good solution), and I have submitted patches. If my code doesn't
completely suck and break things for people on other platforms,
asdf-install on clisp under windows may be a reality soon. And if my
code is unacceptably bad, someone else could get it working quite
easily. The hard part is finding a copy of gnu tar that isn't broken
with respect to asdf-install.
> Five years ago, asdf-install didn't exist. I'd call its existence an
> improvement.
>
>
> Pascal
>
On 9370 day of my life Tin Gherdanarra wrote:
>> 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?
SBCL. Now go write code.
--
Ivan Boldyrev
Is 'evening' a gerund?
From: Robert Uhl
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m3bqxto2rs.fsf@NOSPAMgmail.com>
······@corporate-world.lisp.de writes:
>
> 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
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4454d4FemaaU1@individual.net>
Tin Gherdanarra wrote:
> ······@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/
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4456n0Ff82uU1@individual.net>
Pascal Costanza wrote:
> Tin Gherdanarra wrote:
>
>> ······@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.
Tin Gherdanarra schrieb:
> Pascal Costanza wrote:
> > Tin Gherdanarra wrote:
> >
> >> ······@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
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.
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <1YdDf.160125$km.71381@edtnps89>
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.
Sockets are an OS concept. I don't need no stinkin sockets.
Wade
> 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.
>
>
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <445abpFem6tU1@individual.net>
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?
> Sockets are an OS concept. I don't need no stinkin sockets.
>
> Wade
>
>> 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.
>>
>>
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <sPgDf.125197$m05.31030@clgrps12>
Tin Gherdanarra wrote:
> 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
On 2006-01-29 21:02:26 -0500, Tin Gherdanarra <···········@gmail.com> said:
>
> So where is my
>
> (require 'tcpip-streams)
>
> then?
Here: http://www.cliki.net/trivial-sockets
--
Randall Randall <·······@randallsquared.com>
"Tough crowd. The OP needs a little encouragement�
�and you sucker punch him. Excellent." - Kenny Tilton
Tin Gherdanarra schrieb:
> 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é
--
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.
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.
In article <·························@news.sunsite.dk>,
Cameron MacKinnon <··········@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
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <YQwDf.150345$AP5.23454@edtnps84>
Ron Garret wrote:
>
> 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
In article <······················@edtnps84>,
Wade Humeniuk <··················@telus.net> wrote:
> Ron Garret wrote:
>
> >
> > 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?
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
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <mrADf.150442$AP5.95921@edtnps84>
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?
Wade
> 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
In article <······················@edtnps84>,
Wade Humeniuk <··················@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
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <448lt7FtsaoU1@individual.net>
Ron Garret wrote:
> In article <······················@edtnps84>,
> Wade Humeniuk <··················@telus.net> wrote:
>
>>Ron Garret wrote:
>>
>>>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?
>
> 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.
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?
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <·············@individual.net>,
Pascal Costanza <··@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
From: Bill Atkins
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <874q3km7mz.fsf@rpi.edu>
Ron Garret <·········@flownet.com> writes:
> In article <·············@individual.net>,
> Pascal Costanza <··@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
Marco Baringer's company uses Lisp (www.bese.it), too.
Bill
Ron Garret <·········@flownet.com> writes:
> 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.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <fSNDf.172405$km.142991@edtnps89>
Ron Garret wrote:
> In article <·············@individual.net>,
> Pascal Costanza <··@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.
>
And...
Macro's Fractal Concept
IZWare's Mirai
Xanalys's (which now seems to be CompuDyne) Investigation tools
Memetrics
MDL Information Systems
AutoCAD (of course not CL)
PriceWaterhouseCoopers (Comet)
....
In article <······················@edtnps89>,
Wade Humeniuk <··················@telus.net> wrote:
> Ron Garret wrote:
> > In article <·············@individual.net>,
> > Pascal Costanza <··@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.
> >
>
> And...
>
> Macro's Fractal Concept
> IZWare's Mirai
> Xanalys's (which now seems to be CompuDyne) Investigation tools
> Memetrics
> MDL Information Systems
> AutoCAD (of course not CL)
> PriceWaterhouseCoopers (Comet)
OK, then I stand corrected. The situation is better than I thought.
That's still a pretty short list though.
rg
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <YkVDf.236087$OU5.227323@clgrps13>
Ron Garret wrote:
> In article <······················@edtnps89>,
> Wade Humeniuk <··················@telus.net> wrote:
>
>> Ron Garret wrote:
>>> In article <·············@individual.net>,
>>> Pascal Costanza <··@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.
>>>
>> And...
>>
>> Macro's Fractal Concept
>> IZWare's Mirai
>> Xanalys's (which now seems to be CompuDyne) Investigation tools
>> Memetrics
>> MDL Information Systems
>> AutoCAD (of course not CL)
>> PriceWaterhouseCoopers (Comet)
>
> OK, then I stand corrected. The situation is better than I thought.
>
> That's still a pretty short list though.
>
> rg
And ...
AMD, Lucifer
American Microsystems, Access Design Tools
Cadence Design Systems, Design Planner
Ascent Technology, ARIS
Northwest Airlines, Gate Scheduling
British Telecom Labs, SPEED
Johnson Engineering, CPACS
....
There is more on the Franz site.
In article <·······················@clgrps13>,
Wade Humeniuk <··················@telus.net> wrote:
> Ron Garret wrote:
> > In article <······················@edtnps89>,
> > Wade Humeniuk <··················@telus.net> wrote:
> >
> >> Ron Garret wrote:
> >>> In article <·············@individual.net>,
> >>> Pascal Costanza <··@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.
> >>>
> >> And...
> >>
> >> Macro's Fractal Concept
> >> IZWare's Mirai
> >> Xanalys's (which now seems to be CompuDyne) Investigation tools
> >> Memetrics
> >> MDL Information Systems
> >> AutoCAD (of course not CL)
> >> PriceWaterhouseCoopers (Comet)
> >
> > OK, then I stand corrected. The situation is better than I thought.
> >
> > That's still a pretty short list though.
> >
> > rg
>
> And ...
>
> AMD, Lucifer
> American Microsystems, Access Design Tools
> Cadence Design Systems, Design Planner
> Ascent Technology, ARIS
> Northwest Airlines, Gate Scheduling
> British Telecom Labs, SPEED
> Johnson Engineering, CPACS
>
> ....
>
> There is more on the Franz site.
How many of those are recent? In particular, apropos the topic of this
thread, how many of them are post-BTA?
There are 55 "success stories" on Franz's site.
(http://www.franz.com/success/all_customer_apps.lhtml)
BTA was first published in April of 2001. The wayback machine on the
success stories page only goes back to October 2002.
(http://web.archive.org/web/20021019085140/http://www.franz.com/success/a
ll_customer_apps.lhtml)
At that point there were 52 success stories.
I don't have time to correlate them to see if some may have dropped off
the list, but a cursory inspection reveals that the lists are largely
identical.
So to first order, since BTA, new success stories have been added to
this list at the rate of one a year.
There is some good news though. Since 2002 the number of job openings
at Franz has doubled -- from one to two. In 2002 Franz was hiring an
accountant. Now they're hiring a senior software engineer and director
of engineering. So things do seem to be looking up a bit. (But only at
Franz. The other Lisp vendors show no outward signs of benefiting from
Lisp's meteoric rise. So maybe we shouldn't pop the champagne just yet.)
rg
Ron Garret wrote:
> In article <·······················@clgrps13>,
> Wade Humeniuk <··················@telus.net> wrote:
>
>
>>Ron Garret wrote:
>>
>>>In article <······················@edtnps89>,
>>> Wade Humeniuk <··················@telus.net> wrote:
>>>
>>>
>>>>Ron Garret wrote:
>>>>
>>>>>In article <·············@individual.net>,
>>>>> Pascal Costanza <··@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.
>>>>>
>>>>
>>>>And...
>>>>
>>>>Macro's Fractal Concept
>>>>IZWare's Mirai
>>>>Xanalys's (which now seems to be CompuDyne) Investigation tools
>>>>Memetrics
>>>>MDL Information Systems
>>>>AutoCAD (of course not CL)
>>>>PriceWaterhouseCoopers (Comet)
>>>
>>>OK, then I stand corrected. The situation is better than I thought.
>>>
>>>That's still a pretty short list though.
>>>
>>>rg
>>
>>And ...
>>
>>AMD, Lucifer
>>American Microsystems, Access Design Tools
>>Cadence Design Systems, Design Planner
>>Ascent Technology, ARIS
>>Northwest Airlines, Gate Scheduling
>>British Telecom Labs, SPEED
>>Johnson Engineering, CPACS
>>
>>....
>>
>>There is more on the Franz site.
>
>
> How many of those are recent? In particular, apropos the topic of this
> thread, how many of them are post-BTA?
>
> There are 55 "success stories" on Franz's site.
> (http://www.franz.com/success/all_customer_apps.lhtml)
>
> BTA was first published in April of 2001. The wayback machine on the
> success stories page only goes back to October 2002.
> (http://web.archive.org/web/20021019085140/http://www.franz.com/success/a
> ll_customer_apps.lhtml)
>
> At that point there were 52 success stories.
>
> I don't have time to correlate them to see if some may have dropped off
> the list, but a cursory inspection reveals that the lists are largely
> identical.
>
> So to first order, since BTA, new success stories have been added to
> this list at the rate of one a year.
>
> There is some good news though. Since 2002 the number of job openings
> at Franz has doubled -- from one to two. In 2002 Franz was hiring an
> accountant. Now they're hiring a senior software engineer and director
> of engineering. So things do seem to be looking up a bit. (But only at
> Franz. The other Lisp vendors show no outward signs of benefiting from
> Lisp's meteoric rise. So maybe we shouldn't pop the champagne just yet.)
>
> rg
Oh, God, Ron. You were doing so well. What happened? You are back
spinning your wheels on c.l.l. Here, i will be of no help:
Tell me. For each language, what percentage of total users are also
entrepreneurs who built the enterprise application using that language
because it mattered?
I'll tell you what matters. The higher-order trend in languages towards
greater dynamic and reflective and interactive yadda yadda. You do know
what lies at the end of that trend, don't you? Hint: not Python.
Now cheer up, will you? Life is good.
kenny
In article <·····················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> Oh, God, Ron. You were doing so well. What happened?
A different question was raised.
> You are back spinning your wheels on c.l.l.
Indeed. Sometimes I wonder why I bother.
> Here, i will be of no help:
>
> Tell me. For each language, what percentage of total users are also
> entrepreneurs who built the enterprise application using that language
> because it mattered?
I have no idea. How is that relevant?
> I'll tell you what matters. The higher-order trend in languages towards
> greater dynamic and reflective and interactive yadda yadda. You do know
> what lies at the end of that trend, don't you? Hint: not Python.
Right. And it's only a matter of time before the betamax makes a
comeback too.
> Now cheer up, will you?
:-) :-) :-)
There, did that help?
> Life is good.
Oh, Kenny, you have no idea. :-)
rg
Ron Garret wrote:
> In article <·····················@news-wrt-01.rdc-nyc.rr.com>,
> Kenny Tilton <·············@nyc.rr.com> wrote:
>
>
>>Oh, God, Ron. You were doing so well. What happened?
>
>
> A different question was raised.
No, I meant your return to c.l.l altogether. Get back on the wagon man!
(I am trying, too.)
>
>
>>You are back spinning your wheels on c.l.l.
>
>
> Indeed. Sometimes I wonder why I bother.
>
>
>>Here, i will be of no help:
>>
>>Tell me. For each language, what percentage of total users are also
>>entrepreneurs who built the enterprise application using that language
>>because it mattered?
>
>
> I have no idea. How is that relevant?
>
>
>>I'll tell you what matters. The higher-order trend in languages towards
>>greater dynamic and reflective and interactive yadda yadda. You do know
>>what lies at the end of that trend, don't you? Hint: not Python.
>
>
> Right. And it's only a matter of time before the betamax makes a
> comeback too.
>
>
>>Now cheer up, will you?
>
>
> :-) :-) :-)
>
> There, did that help?
>
>
>>Life is good.
>
>
> Oh, Kenny, you have no idea. :-)
Yes, Ron, we heard you the first time, Goggle made you rich. What are
you flying these days? :)
I think you are right about Common Lisp never making it. Five years ago
there were like three of us moaning about Lisp being unpopular, now it
is so much worse, we have hundreds of newbies moaning about Lisp being
unpopular. And with all the newbies in c.l.l asking for help learning
Lisp, lord, who has time to figure out how we can save it? (I remember
your brilliant idea was to change the name.) On top of that, Microsoft
has asked us to eliminate dynamism and join .NET, and not one but two of
their engineers have taken the time to blog why Lisp sucks. We must be
in sad shape if M$ is training their guns on us.
:)
kt
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <upsm63x7a.fsf@agharta.de>
On Thu, 02 Feb 2006 04:35:59 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> I remember your brilliant idea was to change [Lisp's] name.
Instead he changed /his/ name. Did that help?
:)
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Thu, 02 Feb 2006 04:35:59 GMT, Kenny Tilton <·············@nyc.rr.com>
> wrote:
>
> > I remember your brilliant idea was to change [Lisp's] name.
>
> Instead he changed /his/ name. Did that help?
>
> :)
Actually, yes, it has. You would be amazed.
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
> wrote:
>
> > On Thu, 02 Feb 2006 04:35:59 GMT, Kenny Tilton <·············@nyc.rr.com>
> > wrote:
> >
> > > I remember your brilliant idea was to change [Lisp's] name.
> >
> > Instead he changed /his/ name. Did that help?
> >
> > :)
>
> Actually, yes, it has. You would be amazed.
cf:
http://en.wikipedia.org/wiki/Loretta_Sanchez
rg
Ron Garret wrote:
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
> > wrote:
> >
> > > On Thu, 02 Feb 2006 04:35:59 GMT, Kenny Tilton <·············@nyc.rr.com>
> > > wrote:
> > >
> > > > I remember your brilliant idea was to change [Lisp's] name.
> > >
> > > Instead he changed /his/ name. Did that help?
> > >
> > > :)
> >
> > Actually, yes, it has.
>
> cf:
>
> http://en.wikipedia.org/wiki/Loretta_Sanchez
Hmmm. Looks like you changed more than your name, there. Damn, but
you're a lot cuter than I remember.
> You would be amazed.
Yes. Yes, I am.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44cpj6F1inhhU1@individual.net>
<snippo />
>> There is some good news though. Since 2002 the number of job openings
>> at Franz has doubled -- from one to two. In 2002 Franz was hiring an
>> accountant. Now they're hiring a senior software engineer and
>> director of engineering. So things do seem to be looking up a bit.
>> (But only at Franz. The other Lisp vendors show no outward signs of
>> benefiting from Lisp's meteoric rise. So maybe we shouldn't pop the
>> champagne just yet.)
Meteoric rise? When did that start? A meteoric rise would be
exactly what I was interested in when I posted my original
message a few days ago. Why do you think it's a meteoric rise?
My curiousity is keenly aroused.
>>
>> rg
>
>
> Oh, God, Ron. You were doing so well. What happened? You are back
> spinning your wheels on c.l.l. Here, i will be of no help:
>
> Tell me. For each language, what percentage of total users are also
> entrepreneurs who built the enterprise application using that language
> because it mattered?
>
> I'll tell you what matters. The higher-order trend in languages towards
> greater dynamic and reflective and interactive yadda yadda. You do know
> what lies at the end of that trend, don't you? Hint: not Python.
>
> Now cheer up, will you? Life is good.
>
> kenny
In article <··············@individual.net>,
Tin Gherdanarra <···········@gmail.com> wrote:
> <snippo />
>
> >> There is some good news though. Since 2002 the number of job openings
> >> at Franz has doubled -- from one to two. In 2002 Franz was hiring an
> >> accountant. Now they're hiring a senior software engineer and
> >> director of engineering. So things do seem to be looking up a bit.
> >> (But only at Franz. The other Lisp vendors show no outward signs of
> >> benefiting from Lisp's meteoric rise. So maybe we shouldn't pop the
> >> champagne just yet.)
>
> Meteoric rise? When did that start? A meteoric rise would be
> exactly what I was interested in when I posted my original
> message a few days ago. Why do you think it's a meteoric rise?
> My curiousity is keenly aroused.
That is known as "irony."
http://www.answers.com/irony
Lisp *should* be having a meteoric rise, but it doesn't seem to be
happening. Here's a recent data point:
http://reddit.com/blog/2005/12/on-lisp.html
Kenny's reaction to this is that if we just smile and keep cheering then
everything will be hunky-dory. Well, maybe he's right, but he's been
cheering for an awfully long time now, and things look pretty unhunky to
me. Better than they were to be sure, but still far from Lisp Nirvana.
My position is pretty much along these lines:
http://www.findinglisp.com/blog/2005/12/reddit-and-lisp-psychosis.html
but I go a step further and say that there is a deeper underlying
problem that needs to be addressed. If all were as it should be there
would be a steady stream of Lisp-based startups making Lispers rich who
would then turn around and fund more Lisp-based startups, all of whom
would then make the Lisp vendors rich. It isn't happening. Possible
explanations include:
1. Lisp doesn't really offer any competitive advantage after all.
2. Lisp *could* offer a competitive advantage, but the current state of
the art is such that a lot of technical work (like writing libraries and
getting threads working) is needed before it actually is a net win in
today's climate.
3. Lisp *does* offer a competitive advantage as things stand, but no
one is taking advantage of it because not enough people in the Lisp
community have the necessary business savvy.
and then there's Kenny's theory:
4. All that is needed to make Lisp wildly successful is for everyone to
close their eyes, raise their hands, and shout out at the top of their
lungs, "Lisp is great! Halelujah!" Unfortunately, Ron Garret's unique
power of destructive pessimism is singlehandedly preventing this
strategy from working.
My money (literally) is on 2 and/or 3.
rg
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44dchrF1ju7cU1@individual.net>
Ron Garret wrote:
> In article <··············@individual.net>,
> Tin Gherdanarra <···········@gmail.com> wrote:
>
>
>><snippo />
>>
>>>>There is some good news though. Since 2002 the number of job openings
>>>>at Franz has doubled -- from one to two. In 2002 Franz was hiring an
>>>>accountant. Now they're hiring a senior software engineer and
>>>>director of engineering. So things do seem to be looking up a bit.
>>>>(But only at Franz. The other Lisp vendors show no outward signs of
>>>>benefiting from Lisp's meteoric rise. So maybe we shouldn't pop the
>>>>champagne just yet.)
>>
>>Meteoric rise? When did that start? A meteoric rise would be
>>exactly what I was interested in when I posted my original
>>message a few days ago. Why do you think it's a meteoric rise?
>>My curiousity is keenly aroused.
>
>
> That is known as "irony."
Bummer. I thought you were serious and can point to some
interesting material. There IS some reason to think that
Lisp has more exposure than five years ago, but then again,
exposure is not the same as adoption. Adaption pays the rent,
exposure gets you, well, exposure.
>
> http://www.answers.com/irony
I'm frowning because I know what irony is. I just didn't know
that the statement above was ironic.
>
> Lisp *should* be having a meteoric rise, but it doesn't seem to be
> happening. Here's a recent data point:
>
> http://reddit.com/blog/2005/12/on-lisp.html
>
> Kenny's reaction to this is that if we just smile and keep cheering then
> everything will be hunky-dory. Well, maybe he's right, but he's been
> cheering for an awfully long time now, and things look pretty unhunky to
> me. Better than they were to be sure, but still far from Lisp Nirvana.
>
Cheering is your friend, and good things happen to those who
smile, but - NLP-freaks will beg to differ - it has its limits when
it comes to real-world problems like lack of mindshare.
Being far away from Lisp-Nirvana is not a good thing, I'm sorry
to say.
> My position is pretty much along these lines:
>
> http://www.findinglisp.com/blog/2005/12/reddit-and-lisp-psychosis.html
>
I read that yesterday while having lunch. This was a mistake because
it is a really tasteless article. The author is very eloquent, though.
He might be right on that reddit is being read by uncool people, but
reproaching on them that they suck up to Paul Graham is a little low.
I mean, they do suck up to Paul Graham, but, after all, it's a site
with a large number of Lispniks AND it's funded by Paul Graham.
> but I go a step further and say that there is a deeper underlying
> problem that needs to be addressed.
You are a troll. At least that's what I was called when I said this.
I've just started to work on a Troll-o-Matic for newbies. It's like
a FAQ, just that it discusses issues like
Standardization vs. Single Implementation
Importance of newbies vs. elitism
Benevolent dictator
Do-it-yourself-ism
etc.
This is for newbies so that they can read up on the c.l.l.-Tradition
on these things. I will publish it on angelfire to piss off even
more people. And run it thru a leet-speak-converter, perhaps.
Reddit is not on the list, but it deserves its own section in
the Troll-o-Matic.
> If all were as it should be there
> would be a steady stream of Lisp-based startups making Lispers rich who
> would then turn around and fund more Lisp-based startups, all of whom
> would then make the Lisp vendors rich. It isn't happening. Possible
> explanations include:
>
> 1. Lisp doesn't really offer any competitive advantage after all.
>
Yet another section for the Troll-o-Matic. It DOES offer a
competetive advantage. I don't go into details because I don't have
much more to say about than what you've probably read already.
> 2. Lisp *could* offer a competitive advantage, but the current state of
> the art is such that a lot of technical work (like writing libraries and
> getting threads working) is needed before it actually is a net win in
> today's climate.
Fragmentation gets into the way of this. It is a lot of work, but
many hands make light work. The problem is, the few hands able and
willing enough to do the work are diluted even further because they
are spread over several multiple implementations. Multiple
implementations do not suck, but the same people who point to the
CL standard as a good thing fail to admit that a standard for
sockets, threads, etc. would also be a good thing for some reason.
>
> 3. Lisp *does* offer a competitive advantage as things stand, but no
> one is taking advantage of it because not enough people in the Lisp
> community have the necessary business savvy.
"Business savvy" might be the wrong term for what you and I (or just me)
mean. I think Larry Wall or Guido van Rossum are pretty savvy when it
comes to promoting their language. Both are good speakers, both have
gotten O'Reilly on their side. Why does O'Reilly ignore Lisp? Maybe
that's a good question to ask him. Why isn't there a
"Programming Common Lisp" from O'Reilly? Why doesn't he chip in the
few thousand bucks to pay Edi Weitz or Pascal Constanza or Peter Seibel
to write a some module? Maybe it's just greed, but maybe it's simply
that nobody has tried to convince him that Lisp would be worth it.
>
> and then there's Kenny's theory:
>
> 4. All that is needed to make Lisp wildly successful is for everyone to
> close their eyes, raise their hands, and shout out at the top of their
> lungs, "Lisp is great! Halelujah!" Unfortunately, Ron Garret's unique
> power of destructive pessimism is singlehandedly preventing this
> strategy from working.
Gossip! Groovy...
It's good to know Kenny's theory and Ron Garret's pessimism.
>
> My money (literally) is on 2 and/or 3.
>
> rg
I agree. From troll to dittohead. How pathetic.
From: Peter Seibel
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m21wymiaiy.fsf@gigamonkeys.com>
Tin Gherdanarra <···········@gmail.com> writes:
> Ron Garret wrote:
>> 2. Lisp *could* offer a competitive advantage, but the current
>> state of the art is such that a lot of technical work (like writing
>> libraries and getting threads working) is needed before it actually
>> is a net win in today's climate.
>
> Fragmentation gets into the way of this. It is a lot of work, but
> many hands make light work. The problem is, the few hands able and
> willing enough to do the work are diluted even further because they
> are spread over several multiple implementations.
I think this is a slightly inaccurate reading of the current
situation. At the moment there are, I'd guess, on the order of a
couple dozen folks in the world working on various Common Lisp
implementations. These folks are--if I may be so bold as to broadly
characterize a bunch of folks I've met briefly, if at all--"systems"
programmers, the kind of folks who write OS's, compilers, and virtual
machines. If they weren't working on the guts of some Lisp
implementation they'd probably be working on the implementation of
some other language, or hacking on an OS, or some other systems-level
programming project. In other words, they wouldn't be writing
comprehensive libraries with easy-to-use APIs. Note, I'm not saying
that none of the folks who work on Lisp implementations *could* write
good libraries if they wanted to; just that that it's not their main
interest. And even if they decided too, there just aren't enough of
them to really make a dent.
But that's fine. I'd bet that if one went and looked at the libraries
available in those languages known for having lots of libraries, they
are mostly written by people other than the main language
implementors. By the same token, if Common Lisp is going to get a rich
collection of libraries it's going to be because talented hackers who
like to hack at a level between systems and application
programming--folks like Edi Weitz and Marc Battyani--roll up their
sleeves and get to work. Luckily the kind of hacker who likes writing
good libraries, typically likes for them to be usable by lots of folks
and thus is usually interested in having their libraries work on
multiple Common Lisp implementations.
So I don't think that the existence of multiple Common Lisp
implementations is actually hurting the availability of libraries--it
just means that the Lisp world gets to keep a dozen or so folks
working on improving the state of the art of Lisp implementation
techniques and providing a bit of friendly competition to keep all the
implementations honest. If there was just one implementation, it would
probably just mean that there would be fewer smart systems hackers
working on it because a single project can only support so many of
these guys.
In the meantime, folks who care about libraries should write them. I
suspect 99%, or more, of the library code that needs to be written to
make Common Lisp competitive in the library realm with Perl and Python
can be written in pure Common Lisp. And even the remaining 1% isn't so
bad--I suspect if someone writes a high quality (documented, works as
advertised, etc.) library that runs only in their favorite Lisp
implementation, they'll soon receive patches from Lispers using it on
other implementations. Folks who would like to help out but don't know
where to start should consider joining the CL Gardener's project:
<http://www.lispniks.com/cl-gardeners/>
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Tin Gherdanarra wrote:
> Bummer. I thought you were serious and can point to some
> interesting material. There IS some reason to think that
> Lisp has more exposure than five years ago, but then again,
> exposure is not the same as adoption. Adaption pays the rent,
> exposure gets you, well, exposure.
Hmmm. My landlord expects legal tender, on the first of every month,
not adoption of an abstract language standard, no matter how large the
library is.
From: Stefan Nobis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87r76mywjs.fsf@snobis.de>
Tin Gherdanarra <···········@gmail.com> writes:
> the same people who point to the CL standard as a good thing fail to
> admit that a standard for sockets, threads, etc. would also be a
> good thing for some reason.
No, you fail to see the problems. :)
Maybe a good API for sockets is not that hard (beware: problems with
IPv4, IPv6, other protocols and the like), but multithreading is
really hard (the simple way like pthreads is *very* error-prone, other
ideas like from Oz/Mozart are not that simple and I don't think there
is broad consensus about the one right way do to multithreading.
Another example are GUIs (by the way, there is some kind of a standard
with McCLIM, as far as I understand it) -- there is just no single way
of doing it right. So a standard is no good idea, we *need* different
libraries (like LTK, cells-gtk, cl-wx, CAPI,...).
What's missing in the CL standard are things like MOP (so we don't
need these different MOP abstraction layers), maybe continuations,
something like iterate or equal as generic function. But that's all no
show-stoppers, just nice to have.
--
Stefan.
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1irry3x9c.fsf@mordac.netfonds.no>
Ron Garret <·········@flownet.com> writes:
> 1. Lisp doesn't really offer any competitive advantage after all.
Maybe not always, but definitely sometimes.
> 3. Lisp *does* offer a competitive advantage as things stand, but no
> one is taking advantage of it because not enough people in the Lisp
> community have the necessary business savvy.
This is partly a valid point, lisp probably needs more good sales
people. In many organizations above a certain size (say, most
organizations that have more than 2 organizational layers), decisions
aren't made in such a rational manner that market liberalism prophets
like to think. The winning technologies are usually not the best
ones, but the ones that have the best power point presentations. All
off-the-beaten-track solutions face two obstacles in larger
organizations: The Dilbert Principle and the "nobody got fired for
buying ibm" principle.
There are very few people that can fill the roles of good hacker and
good salesman simultaneously, so what the hacker needs to do, is not
to try to be a businesswoman she can never become, but rather team up
with someone that trusts her, a friend, coworker, boss,... who
/is/ a good salesman (to either do actual sales or "sell the
solution" in a larger organization).
The sad thing though, is that in some really bad organizations, even
"seeing is believing" won't work, if you e.g. save a lot of money by
using lisp and this doesn't fit in with the last-slide-punchlines of
the power point block heads, they will try to adjust /you/ instead of
their distorted world view. If you're part of such an organization,
the best advice is to leave them before you either get ill, a cynical
grumpy old fart - or adjust and become one of the block heads.
--
(espen)
From: Robert Uhl
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m3slr1tu5p.fsf@NOSPAMgmail.com>
Espen Vestre <·····@vestre.net> writes:
>
> In many organizations above a certain size (say, most organizations
> that have more than 2 organizational layers), decisions aren't made in
> such a rational manner that market liberalism prophets like to think.
That's because most large organisations aren't free markets--they're
command-and-control economies, with all the inefficiencies and mistakes
that implies...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Never attribute to malice that which can be explained by French sanitation.
--Tanuki
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1slr1sacr.fsf@vestre.net>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> That's because most large organisations aren't free markets--they're
> command-and-control economies, with all the inefficiencies and mistakes
> that implies...
Yep. Private enterprise still hasn't grasped that stalinism failed ;-)
--
(espen)
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44fdkmF1up7hU1@individual.net>
Robert Uhl wrote:
> Espen Vestre <·····@vestre.net> writes:
>
>>In many organizations above a certain size (say, most organizations
>>that have more than 2 organizational layers), decisions aren't made in
>>such a rational manner that market liberalism prophets like to think.
>
>
> That's because most large organisations aren't free markets--they're
> command-and-control economies, with all the inefficiencies and mistakes
> that implies...
>
"Soviet-Capitalism" they call it here in Vienna.
Later
Tin
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44f7kmF1u3tiU1@individual.net>
Espen Vestre wrote:
> This is partly a valid point, lisp probably needs more good sales
> people. In many organizations above a certain size (say, most
> organizations that have more than 2 organizational layers), decisions
> aren't made in such a rational manner that market liberalism prophets
> like to think. The winning technologies are usually not the best
> ones, but the ones that have the best power point presentations. All
> off-the-beaten-track solutions face two obstacles in larger
> organizations: The Dilbert Principle and the "nobody got fired for
> buying ibm" principle.
That's because currently we only have big corps, because small ones have
trouble existing, with regulations and stuff that are costly for small
companies, but peanuts for a Big Player.
A market might not exist inside companies, but a market can allow
competitors to offer better products (overall), and better technologies
would probably give an edge to such competition. In addition, internal
inefficiencies are increasingly outsourced, so that the technology areas
become actual companies that consist of nothing but.
But I agree about Dilbert and IBM. Overall, only a fair number of
competitors will ensure that at least a few might use non-mainstream tech.
--
Suffering from Gates-induced brain leakage...
From: Don Geddis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87acdbj9l8.fsf@geddis.org>
Ron Garret <·········@flownet.com> wrote on Tue, 31 Jan 2006:
>> >>> 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 are 55 "success stories" on Franz's site.
> (http://www.franz.com/success/all_customer_apps.lhtml)
One of these was a company I co-founded, Cadabra:
http://www.franz.com/success/customer_apps/data_mining/cadabra.lhtml
Founded in 1996, used Common Lisp exclusively for the first couple of years,
sold in 2000 to Goto.com (aka Overture in turn bought by Yahoo) for $250
million. And at that time, we STILL had a core engine that was written in
Common Lisp.
That's in "the last ten years". And note that Viaweb (aka Yahoo Stores) sold
for "only" $40M, vs. the $250M purchase price of Cadabra.
(On the other hand, Yahoo Stores is still an active application, while
Cadabra's comparison shopping service is no longer functioning.)
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
From: Zach Beane
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m364nz9dmd.fsf@unnamed.xach.com>
Don Geddis <···@geddis.org> writes:
> (On the other hand, Yahoo Stores is still an active application, while
> Cadabra's comparison shopping service is no longer functioning.)
And you're really slacking on the essay front!
Zach
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Ron Garret <·········@flownet.com> wrote on Tue, 31 Jan 2006:
> >> >>> 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 are 55 "success stories" on Franz's site.
> > (http://www.franz.com/success/all_customer_apps.lhtml)
>
> One of these was a company I co-founded, Cadabra:
> http://www.franz.com/success/customer_apps/data_mining/cadabra.lhtml
> Founded in 1996, used Common Lisp exclusively for the first couple of years,
> sold in 2000 to Goto.com (aka Overture in turn bought by Yahoo) for $250
> million.
Congratulations. I had no idea.
> And at that time, we STILL had a core engine that was written in
> Common Lisp.
>
> That's in "the last ten years". And note that Viaweb (aka Yahoo Stores) sold
> for "only" $40M, vs. the $250M purchase price of Cadabra.
>
> (On the other hand, Yahoo Stores is still an active application, while
> Cadabra's comparison shopping service is no longer functioning.)
So what you're saying is that you managed to get Goto to pay you $250M
for an asset that ultimately proved to be worthless. From a business
point of view that sounds more like snake oil than success. To be fair,
there was a lot of that sort of thing going on around that time, but the
mere fact that you were able to fleece someone for nine figures is
hardly a ringing endorsement of Lisp.
And Yahoo Store has been rewritten in C++.
rg
From: Don Geddis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <873bj1gtnk.fsf@geddis.org>
Ron Garret <·········@flownet.com> wrote on Wed, 01 Feb 2006:
> So what you're saying is that you managed to get Goto to pay you $250M
> for an asset that ultimately proved to be worthless. From a business
> point of view that sounds more like snake oil than success.
You're of course entitled to your point of view. But to be fair, you should
note that there are many possible explanations besides "snake oil" for such an
outcome.
The process of business is inherently one of reasoning under uncertainty.
You make predictions about the future, and you place bets. To do this well,
it's important to distinguish good/bad decisions from good/bad outcomes.
They're related, but they aren't the same thing.
If you saw an opportunity that required $100 investment, but had a 50% chance
of returning $1000 within a year, you ought to jump at it, right? And if you
get unlucky, and wind up in the 50% outcome that gets $0 instead, this doesn't
mean that you made a bad decision. Nor that the opportunity was "snake oil".
Secondly, different business opportunities can be more or less feasible
depending on economic conditions. As the price of oil jumps from $20/barrel
to $60-$100/barrel, then the profits to be found processing Canadian tar sands
for oil skyrocket. If you're one of those companies, and you own some tar
sands, and then the price of oil plunges back down to $20/barrel, then your
business plan no longer works. But again, it doesn't mean you were peddling
snake oil (aka that you misled investors about what you had to offer, or what
the risks were).
It's worth noting that the US economic conditions from 1995-2000 were radically
different than from mid-2000 through about 2003. Plenty of profitable,
sustainable businesses in the earlier period were no longer feasible in the
latter one.
> To be fair, there was a lot of that sort of thing going on around that
> time, but the mere fact that you were able to fleece someone for nine
> figures is hardly a ringing endorsement of Lisp.
Without going into the specifics of my own case, I think it's clear that you
have no special knowledge of it.
So I think you owe me an apology for leaping to the conclusion that I must have
fleeced someone by selling them snake oil. That's insulting, and undeserved.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Ron Garret <·········@flownet.com> wrote on Wed, 01 Feb 2006:
> > So what you're saying is that you managed to get Goto to pay you $250M
> > for an asset that ultimately proved to be worthless. From a business
> > point of view that sounds more like snake oil than success.
>
> You're of course entitled to your point of view. But to be fair, you should
> note that there are many possible explanations besides "snake oil" for such
> an
> outcome.
>
> The process of business is inherently one of reasoning under uncertainty.
> You make predictions about the future, and you place bets. To do this well,
> it's important to distinguish good/bad decisions from good/bad outcomes.
> They're related, but they aren't the same thing.
>
> If you saw an opportunity that required $100 investment, but had a 50% chance
> of returning $1000 within a year, you ought to jump at it, right? And if you
> get unlucky, and wind up in the 50% outcome that gets $0 instead, this
> doesn't
> mean that you made a bad decision. Nor that the opportunity was "snake oil".
>
> Secondly, different business opportunities can be more or less feasible
> depending on economic conditions. As the price of oil jumps from $20/barrel
> to $60-$100/barrel, then the profits to be found processing Canadian tar
> sands
> for oil skyrocket. If you're one of those companies, and you own some tar
> sands, and then the price of oil plunges back down to $20/barrel, then your
> business plan no longer works. But again, it doesn't mean you were peddling
> snake oil (aka that you misled investors about what you had to offer, or what
> the risks were).
>
> It's worth noting that the US economic conditions from 1995-2000 were
> radically
> different than from mid-2000 through about 2003. Plenty of profitable,
> sustainable businesses in the earlier period were no longer feasible in the
> latter one.
>
> > To be fair, there was a lot of that sort of thing going on around that
> > time, but the mere fact that you were able to fleece someone for nine
> > figures is hardly a ringing endorsement of Lisp.
>
> Without going into the specifics of my own case, I think it's clear that you
> have no special knowledge of it.
>
> So I think you owe me an apology for leaping to the conclusion that I must
> have
> fleeced someone by selling them snake oil. That's insulting, and undeserved.
Indeed. I did not say that you *did* fleece someone, only that it
*sounds* *more* like that than it sounds like a success story.
Notwithstanding, I apologize for casting any aspersions on you. I
certainly have no basis for judging you.
rg
Don Geddis wrote:
> That's in "the last ten years". And note that Viaweb (aka Yahoo Stores) sold
> for "only" $40M, vs. the $250M purchase price of Cadabra.
But from the buyer's point of view, investing in Lisp was a $250M
mistake.
BTW, if you and your partners made so much money, how come you didn't
reinvest it into what you must have believed to be a superior
technology, likely to bring in even more? (lisp that is)
·········@gmail.com writes:
> Don Geddis wrote:
>
> > That's in "the last ten years". And note that Viaweb (aka Yahoo Stores)
> > sold for "only" $40M, vs. the $250M purchase price of Cadabra.
>
> But from the buyer's point of view, investing in Lisp was a $250M
> mistake.
No, investing in Cadabra was. Unless you are/were a share holder - a
mind reader, what else can you possibly know? Oh right - you're the
guy who claims to be a mind reader.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44b8gkF1a95mU3@individual.net>
Ron Garret wrote:
> How many of those are recent? In particular, apropos the topic of this
> thread, how many of them are post-BTA?
Does it matter? Why?
> So to first order, since BTA, new success stories have been added to
> this list at the rate of one a year.
I'd say that's a pretty good rate, isn't it?
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> > How many of those are recent? In particular, apropos the topic of this
> > thread, how many of them are post-BTA?
>
> Does it matter? Why?
Because that is the topic under discussion. See the title of this
thread.
> > So to first order, since BTA, new success stories have been added to
> > this list at the rate of one a year.
>
> I'd say that's a pretty good rate, isn't it?
One success story per year? On a planet with more than six billion
people? For what is supposedly the best programming language? I think
we ought to be able to do better.
rg
Ron Garret <·········@flownet.com> writes:
> > I'd say that's a pretty good rate, isn't it?
>
> One success story per year? On a planet with more than six billion
> people? For what is supposedly the best programming language? I think
> we ought to be able to do better.
This seems more likely a simple statistical result. You and I both
know that most new ventures fail - mostly due to various "business"
reasons than any "technical" reasons (the numbers vary depending on
the source but out to two nines of them failing is not especially
hyperbole). If you don't have huge numbers trying with any given
thing you simply won't have even "largish" numbers of success stories
involving that thing - irrespective of the merits (or demerits).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ron Garret <·········@flownet.com> writes:
> How many of those are recent? In particular, apropos the topic of this
> thread, how many of them are post-BTA?
>
> There are 55 "success stories" on Franz's site.
> (http://www.franz.com/success/all_customer_apps.lhtml)
>
> BTA was first published in April of 2001. The wayback machine on the
> success stories page only goes back to October 2002.
> (http://web.archive.org/web/20021019085140/http://www.franz.com/success/a
> ll_customer_apps.lhtml)
>
> At that point there were 52 success stories.
>
> I don't have time to correlate them to see if some may have dropped off
> the list, but a cursory inspection reveals that the lists are largely
> identical.
I found that there may be little correlation between published Lisp
success stories and the actual number of stories themselves. Several
years ago, I set up these web pages for collecting pointers to related
information:
Industry Applications using Lisp
http://wiki.alu.org/Industry_Application
Research Organizations
http://wiki.alu.org/Research_Organizations
Back then, they were at the ALU Wiki page and were fairly accurate. I
based that information on a number of sources: corporate web sites,
published success stories, job openings, conference proceedings,
product announcements, comp.lang.lisp articles, and more. I tried to
include companies and organizations that were known to have used Lisp
within the previous one or two years.
But I stopped maintaining those pages long ago for a couple of
reasons. The first is that, although I asked for help, only a handful
of new entries were added. I kept publicly hearing about more success
stories[*] and new companies using Lisp, but those involved didn't add
entries or notified me.
The other reason is that, no matter how many links I added, people
kept complaining that the companies using Lisp were too few--sounds
familiar?
> So to first order, since BTA, new success stories have been added to
> this list at the rate of one a year.
Try higher orders.
> There is some good news though. Since 2002 the number of job openings
> at Franz has doubled -- from one to two. In 2002 Franz was hiring an
Duane Rettig discussed here more than once the history of his company
and the number of employees.
Paolo
[*] I heard the latest a couple of days ago. Incidentally, it
involved martian rovers...
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Paolo Amoroso
Subject: Re: success stories (was: Re: Interesting developments since "Beating the averages"?)
Date:
Message-ID: <87slr39m3o.fsf@plato.moon.paoloamoroso.it>
Matthias <··@spam.please> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> I found that there may be little correlation between published Lisp
>> success stories and the actual number of stories themselves. Several
>> years ago, I set up these web pages for collecting pointers to related
>> information:
>>
>> Industry Applications using Lisp
>> http://wiki.alu.org/Industry_Application
>
> I followed a number of links on this page and many (most?) resulting
> pages did not contain the word "lisp".
Yes, that's why my research was time consuming: I didn't just search
for the string "lisp" on corporate sites. As I said in my original
message, I checked a wide range of sources such as product
announcements, job openings, conference proceedings, first-hand
accounts posted to several mailing lists, etc. I originally didn't
include references to such sources. Then Daniel Barlow left this
comment, which you can still read in the above page:
[An impressive list, but it would be much more interesting if (where
possible) additional links to technical information were
included. paul graham's site would be a good place to start, but I
imagine alain picard and others can also be leaned on to write more
stuff. -- Daniel Barlow]
and I started adding such links. Some time later, I stopped
maintained the page because nobody cared anyway.
> To me, a "success story" is really a story with some explanation about
> why X was chosen and what lessons were learned and so on. It's not
That's why I have said that I collected information "related" to
success stories (see the quoted text above).
> just a list of links where some company may have chosen X for a
> product or service. With success stories quality is more important
> than quantity, IMHO.
That's a job for Andersen Consulting--or whatever it's called now.
With volunteer labor, you get what you pay for.
>> The other reason is that, no matter how many links I added, people
>> kept complaining that the companies using Lisp were too few--sounds
>> familiar?
>
> If you want to defeat this argument success stories might not be the
> best tool. A small search over job adds can be much more convincing.
I'm glad I took the right decision.
> Because people complaining there are not enough companies using X
> really mean: "There are not enough jobs where I can use X."
[...]
> in blogs (or whatever, you get the idea). On the other side,
>
> http://www.indeed.com/jobtrends?q=lisp%2C+python%2C+ruby
Indeed:
http://www.lispjobs.com
Never mind, there are no Lisp jobs.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Matthias wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
>
>>I found that there may be little correlation between published Lisp
>>success stories and the actual number of stories themselves. Several
>>years ago, I set up these web pages for collecting pointers to related
>>information:
>>
>> Industry Applications using Lisp
>> http://wiki.alu.org/Industry_Application
>
>
> I followed a number of links on this page and many (most?) resulting
> pages did not contain the word "lisp".
>
> To me, a "success story" is really a story with some explanation about
> why X was chosen and what lessons were learned and so on. It's not
> just a list of links where some company may have chosen X for a
> product or service. With success stories quality is more important
> than quantity, IMHO.
There's a chicken-and-egg problem here. Some companies advertize the
fact that they use a particular language for implementing their
software. These are typically popular languages, probably to take
advantage of exactly that popularity and to make their products or
services look similarly popular. (Personally, I find this a questionable
style of marketing. Why should I as a customer care what tools a company
uses to produce their products?)
Lisp is not as popular as other languages. So companies cannot use the
fact that they base their software on Lisp to advertize their offerings
in the same way.
> A little query like
>
> http://www.indeed.com/jobtrends?q=blog
>
> can be convincing that, from a job perspective, it's useful to invest
> in blogs (or whatever, you get the idea). On the other side,
>
> http://www.indeed.com/jobtrends?q=lisp%2C+python%2C+ruby
>
> doesn't yet make a very convincing argument for lisp. (Unfortunately,
> indeed.com supports queries over the last year only.)
I don't think that the knowledge of a particular language or a
particular set of languages is the best way to judge wether a programmer
is competent or not. What matters more is how good someone is at the
conceptual level and how good someone is understanding problem domains
to the degree that they can produce working solutions for such domains.
It doesn't really matter what language someone uses to produce such
solutions, as long as it is not a braindead language and as long as that
language isn't chosen purely based on the perception that everyone else
uses the same language.
I have seen some pretty impressive programs written in all kinds of
languages, but they are typically not written in mainstream languages.
People who decide to use a non-mainstream language typically have good
reasons to do so. People who decide to use popular languages typically
don't have good reasons to do so. That's the more interesting
distinction IMHO.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <ud5i8n5dc.fsf@agharta.de>
On Mon, 30 Jan 2006 17:47:30 -0800, Ron Garret <·········@flownet.com> wrote:
> 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.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Mon, 30 Jan 2006 17:47:30 -0800, Ron Garret <·········@flownet.com> wrote:
>
> > 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?
Because I'm a customer.
> > 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.
I don't understand that comment at all.
> 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.
Ignorance can be bliss. I made a comfortable living using Lisp for more
than ten years. But there is an enormous difference between making a
comfortable *salary* using Lisp and starting a viable *business* using
Lisp. There are probably a few dozen, maybe even a few hundred (but
almost certainly not a few thousand) people in the world making
comfortable salaries using Lisp. To my knowledge, in the last ten years
there have only been three successful businesses started using Lisp.
rg
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uek2ojo88.fsf@agharta.de>
On Tue, 31 Jan 2006 09:20:27 -0800, Ron Garret <·········@flownet.com> wrote:
>> And why aren't you this someone?
>
> Because I'm a customer.
And this mystical "someone" you're waiting for is not a customer?
> I don't understand that comment at all.
I expected that.
> Ignorance can be bliss. I made a comfortable living using Lisp for
> more than ten years. But there is an enormous difference between
> making a comfortable *salary* using Lisp and starting a viable
> *business* using Lisp.
I don't make a *salary* using Lisp because I'm not employed. There's
an enormous difference between doing something on your own and sitting
around waiting for someone else doing it for you.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Tue, 31 Jan 2006 09:20:27 -0800, Ron Garret <·········@flownet.com> wrote:
>
> >> And why aren't you this someone?
> >
> > Because I'm a customer.
>
> And this mystical "someone" you're waiting for is not a customer?
No, he or she would be a vendor. (Not a Lisp vendor, but a vendor of a
product that was sold outside of the Lisp community.)
rg
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <umzhba2gd.fsf@agharta.de>
On Tue, 31 Jan 2006 18:15:40 -0800, Ron Garret <·········@flownet.com> wrote:
> No, he or she would be a vendor. (Not a Lisp vendor, but a vendor
> of a product that was sold outside of the Lisp community.)
Sounds like complete nonsense to me. If he's not a Lisp vendor and
he's using Lisp for his cool new product, then for the purpose of this
discussion he's a customer (of some Lisp vendor, commercial or not).
Unless you think some people are born to be entrepreneurs and the
others are doomed to be passive customers/consumers for the rest of
their life.
Sorry, I don't see this leading anywhere - I'm done with this thread.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1lkwwsqk0.fsf@mordac.netfonds.no>
Edi Weitz <········@agharta.de> writes:
> 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)
In article <··············@mordac.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Edi Weitz <········@agharta.de> writes:
>
> > 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.
Your company is one of three that I am aware of that have succeeded
using Lisp in the last ten years. Three is not enough.
> 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.
I'm asking for investment opportunities. I'm asking for a dozen
mid-stage startups in a dozen different industries stomping on their
competition because they are using Lisp, and looking for round A or B
venture capital to finance their growth. (I'll settle for one to start.)
rg
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1oe1stecu.fsf@vestre.net>
Ron Garret <·········@flownet.com> writes:
> Your company is one of three that I am aware of that have succeeded
> using Lisp in the last ten years. Three is not enough.
Heh, there is at least one other company with a larger lisp programmer
group just in /Oslo/!
> I'm asking for investment opportunities. I'm asking for a dozen
> mid-stage startups in a dozen different industries stomping on their
> competition because they are using Lisp, and looking for round A or B
> venture capital to finance their growth. (I'll settle for one to start.)
Hmm, I think you should stop looking for the fairy tale lisp stories,
there are a lot of good lisp stories that are more down-to-earth. For
instance, Netfonds wasn't much of a lisp company in the beginning, it
was first and foremost an internet company that used php and emacs as
its main tools. By the time I joined Netfonds, they were already
using a lot of lisp, though, and our lisp code base keeps
growing. Programming in common lisp helps us meet higher demands, more
customers and tougher competition. Simple as that.
(You should have a look at the stuff Marc Battyani is doing, btw.
Might cheer you up :-))
--
(espen)
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44bsoqF1dr9vU1@individual.net>
> 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.
This is basically what I was saying, too, but maybe I failed
to put into such concise words. However...
> That is not a sustainable economic model.
I don't think that Lisp needs an economic model.
PHP, to stick with the example above, never had one.
>
> Not all potential customers will be indifferent. Some will be curious.
And drop it when they can't figure out in five minutes how to fetch a
page from an URL and extract all the <h3>.*?<\/h3>s in Lisp.
> 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.
It is Larry Wall's "the customer is always right, I will suck up to
everybody who shows any interest in perl" vs.
Lisp's "Let's write another socket library". I exaggerate, but
not much. Here it seems that you are tainted as a troll
if you say that PHP works out of the box and Lisp
does not.
> Until that changes, Lisp will continue to live in
> well-deserved exile from the rest of the world.
I disagree because Lisp does not deserve to live in
an exile. I wonder whether perl or PHP had happened if Lisp
had been on the map in 1985. All those people buying
"Learn PHP in 21 days" could be Lisp people. How neat would
be that be?
>
> rg
In article <··············@individual.net>,
Tin Gherdanarra <···········@gmail.com> wrote:
> > That is not a sustainable economic model.
>
> I don't think that Lisp needs an economic model.
> PHP, to stick with the example above, never had one.
Of course it did. And it still does. Actually, Lisp had (and has) an
economic model too, it's just not a very good one. Lisp's current model
is similar (to use a car analogy) to Ferrari: be the very best, and put
a significant burden on the user to drive it right, and replace the
clutch every 3000 miles. PHP is more like a Toyota Corolla. It's no
good on the track, but anyone can drive it. Guess who sells more cars?
rg
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u8xsuykto.fsf@agharta.de>
On Wed, 01 Feb 2006 08:05:28 -0800, Ron Garret <·········@flownet.com> wrote:
> Of course it did. And it still does. Actually, Lisp had (and has)
> an economic model too, it's just not a very good one. Lisp's
> current model is similar (to use a car analogy) to Ferrari: be the
> very best, and put a significant burden on the user to drive it
> right, and replace the clutch every 3000 miles. PHP is more like a
> Toyota Corolla. It's no good on the track, but anyone can drive it.
> Guess who sells more cars?
It might be interesting to note that Porsche (which is in a situation
very similar to Ferrari but an independent company while Ferrari is a
part of Fiat) is by far the most profitable car maker in the world.
Guess whose shareholders are happiest? So far for analogies.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> It might be interesting to note that Porsche (which is in a situation
> very similar to Ferrari but an independent company while Ferrari is a
> part of Fiat) is by far the most profitable car maker in the world.
> Guess whose shareholders are happiest? So far for analogies.
Not a valid comparison for two reasons: a) A typical employee at
"Porsche" will never have the opportunity to buy such a Porsche and b)
The man who is able to straighten out the money for a Porsche is well
off and has a lot of money. Well I know for sure that making a lot of
money is not possible in any kinds of legal ways.
I for one would not like to work for Porsche. And I for one would not
like buying and owning a Porsche. And I for one would not like being a
shareholder with Porsche.
However, if I had more time I would like to study a bit deeper Common
Lisp.
Schneewittchen
Förster vom Silberwald wrote:
> Well I know for sure that making a lot of
> money is not possible in any kinds of legal ways.
Sounds like the legal system in Germany is more restricting that I
thought.
·········@gmail.com wrote:
> F�rster vom Silberwald wrote:
>
>>Well I know for sure that making a lot of
>>money is not possible in any kinds of legal ways.
>
>
> Sounds like the legal system in Germany is more restricting that I
> thought.
While I try to stay away from political discussions, for sure there
are plenty of legal ways here in Germany to earn the money to buy
a Porsche.
Peter
--
Ltk, the cute Lisp GUI.
http://www.peter-herth.de/ltk/
Peter Herth wrote:
> ·········@gmail.com wrote:
> > Förster vom Silberwald wrote:
> >
> >>Well I know for sure that making a lot of
> >>money is not possible in any kinds of legal ways.
> >
> >
> > Sounds like the legal system in Germany is more restricting that I
> > thought.
>
> While I try to stay away from political discussions, for sure there
> are plenty of legal ways here in Germany to earn the money to buy
> a Porsche.
>
Of course. I was being sarcastic.
·········@gmail.com wrote:
> Förster vom Silberwald wrote:
> > Well I know for sure that making a lot of
> > money is not possible in any kinds of legal ways.
>
> Sounds like the legal system in Germany is more restricting that I
> thought.
I happen to live in Austria. What might be legal at law does not always
count when you once will have to report to Lord.
Schneewittchen
Förster vom Silberwald wrote:
> ·········@gmail.com wrote:
> > Förster vom Silberwald wrote:
> > > Well I know for sure that making a lot of
> > > money is not possible in any kinds of legal ways.
> >
> > Sounds like the legal system in Germany is more restricting that I
> > thought.
>
> I happen to live in Austria. What might be legal at law does not always
> count when you once will have to report to Lord.
So, which religion do you belong to? Some religions pretty much
encourage getting rich.
·········@gmail.com wrote:
> > I happen to live in Austria. What might be legal at law does not always
> > count when you once will have to report to Lord.
>
> So, which religion do you belong to? Some religions pretty much
> encourage getting rich.
Hello: At the moment I am bit in a hurry since two weeks ago my ibook
its hard disc crashed and I lost a whole lot of very important research
results from my PhD work in physics. I replaced the hard disc (there
were more than 30 small screws to cope with) but after that my CD-ROM
drive crashed and scratched my Panther install disc. Eventually we
installed a new Tiger Mac OSX by means of fire wire and second ibook.
And I am still coping to get all the software right at the moment.
But for your answer:
I resigned from any church. However, I plan to enter (catholic) church
again since I cannot any longer live with the following two things:
too much feminism and abortion is considered a good thing in the
meantime.
And before some of you laugh and deride at me: go to the Vatikan page
and really read some of the documents of Pope Ratzinger. They are
available in English language too.
Schneewittchen
Förster vom Silberwald wrote:
> ·········@gmail.com wrote:
>
> > > I happen to live in Austria. What might be legal at law does not always
> > > count when you once will have to report to Lord.
> >
> > So, which religion do you belong to? Some religions pretty much
> > encourage getting rich.
>
> Hello: At the moment I am bit in a hurry since two weeks ago my ibook
> its hard disc crashed and I lost a whole lot of very important research
> results from my PhD work in physics. I replaced the hard disc (there
> were more than 30 small screws to cope with) but after that my CD-ROM
> drive crashed and scratched my Panther install disc. Eventually we
> installed a new Tiger Mac OSX by means of fire wire and second ibook.
> And I am still coping to get all the software right at the moment.
>
Sometimes I wonder if Apple is a religion too.
> But for your answer:
>
> I resigned from any church. However, I plan to enter (catholic) church
> again since I cannot any longer live with the following two things:
> too much feminism and abortion is considered a good thing in the
> meantime.
>
If you are sick of feminism, perhaps Islam might be a better choice?
> And before some of you laugh and deride at me: go to the Vatikan page
> and really read some of the documents of Pope Ratzinger. They are
> available in English language too.
Do you think the CEO of that richest and oldest corporation in the
world drives a Corolla?
·········@gmail.com wrote:
> Do you think the CEO of that richest and oldest corporation in the
> world drives a Corolla?
Yes. I know for sure that "Kardinal Ratzinger" drove an old Golf. You
know the story concerning ebay and his car? Google a bit around.
Sorry. I am bussy could be an interesting duscussion. I lack time.
However, the "Porsche" itself is not the problem.
Schneewittchen
Btw: Islam and all favors of it and my critisisms against feminism is
putting words in my mouth. What do you think that I am used to beat my
girlfried? Sorry, but I have in all my whole life never put forward
force against a woman or children. How could I? Once you read the bible
you will never beat a woman. The problem is that so many people will
never read and study the bible.
·········@gmail.com writes:
> If you are sick of feminism, perhaps Islam might be a better choice?
Be serrious, Islam is not a religion, it's a political system.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
Pascal Bourguignon wrote:
> ·········@gmail.com writes:
>> If you are sick of feminism, perhaps Islam might be a better choice?
>
> Be serrious, Islam is not a religion, it's a political system.
>
Does Godwin's Law need an update for the post 9/11 world? Either way,
Hitler or Nazi's can only be a few days away and this thread can finally
receive its well deserved death certificate.
Pascal Bourguignon <······@informatimago.com> wrote:
> ·········@gmail.com writes:
>> If you are sick of feminism, perhaps Islam might be a better choice?
>
> Be serrious, Islam is not a religion, it's a political system.
CL-USER> (troll-p (msg-from-id ···············@thalassa.informatimago.com"))
T
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
> Pascal Bourguignon <······@informatimago.com> wrote:
>
>> ·········@gmail.com writes:
>>> If you are sick of feminism, perhaps Islam might be a better choice?
>>
>> Be serrious, Islam is not a religion, it's a political system.
>
> CL-USER> (troll-p (msg-from-id ···············@thalassa.informatimago.com"))
> T
Didier: ouvre un journal ou regarde un peu les nouvelles � la t�l�vision!
Damien was right.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Pascal Bourguignon wrote:
> ·········@gmail.com writes:
> > If you are sick of feminism, perhaps Islam might be a better choice?
>
> Be serrious, Islam is not a religion, it's a political system.
>
> --
Christian is not a religion either. It's a marketing campaign. From my
point of view:
- What's with that "Jesus is the only one born without sin"? What's the
point of doing good to the world if the world has exception? So the
world of Christian is not based on justice because even your leader is
borned out of Dictatorship and exception.
- What's with that "God will forgive all your sin even if you say that
you believe in god one single second before your death"? So that you
can do all crap whole life? So Christian doesn't give a shit about what
they do in life, they will be wealthy and protect by god just because
they believe in god. And no matter how good I treat other people, if I
don't believe in god, I'll still be punished at the ended and sucked
into sand?
I live in Thailand and nine years ago when I was in America a guy asked
me if I still hunt for food and commute by elephant. A preach in the
church near the place I lived even said in teenage religion teaching
class that some Buddhism in Asia believed in eating people!!
I'm neither Chritian or Muslim. But I accept the fact that you don't
understand my religion, and I don't understand your either. So don't
talk on other religion just because you don't believe in them. Don't
use some violence caused by some Muslim to say that Islam is the
violent religion. Everyday thounsands of Christian kill other Christian
or even bomb the whole innocent village because of the possiblity that
the leader of some criminal might be living there. Will you bomb the
whole new york if there's news that Bin Laden might be hiding there?
Every religion teaches people to get along together, it's always the
people who misinterpret the religion and misuse it.
Regards,
Pascal Bourguignon wrote:
> ·········@gmail.com writes:
> > If you are sick of feminism, perhaps Islam might be a better choice?
>
> Be serrious, Islam is not a religion, it's a political system.
>
What do Mohammed, Richard Stallman, Jesus Christ, Linux Torvalds and
Erik Naggum have in common?
On 2006-02-10 00:56:21 -0500, ·········@gmail.com said:
> What do Mohammed, Richard Stallman, Jesus Christ, Linux Torvalds and
> Erik Naggum have in common?
Valiant effort, and still nary a bite. Might I humbly suggest you
return to trolling comp.lang.functional - Stepanov and the STL seemed
to have them practially jumping onto the deck over there...
Raffael Cavallaro wrote:
> > What do Mohammed, Richard Stallman, Jesus Christ, Linux Torvalds and
> > Erik Naggum have in common?
Sorry to disappoint, but I was 100% serious about STL. The ideas that
went into STL are indeed brilliant, on par with the "code is data"
mantra Lispers like to talk about.
From: Gianni Mariani
Subject: Re: (off topic) GOT-STL-P (Re: Interesting developments since "Beating the averages"?)
Date:
Message-ID: <eZydnc7btLzyh3PeRVn-vA@speakeasy.net>
·········@gmail.com wrote:
> Raffael Cavallaro wrote:
>
>>>What do Mohammed, Richard Stallman, Jesus Christ, Linux Torvalds and
>>>Erik Naggum have in common?
>
>
> Sorry to disappoint, but I was 100% serious about STL. The ideas that
> went into STL are indeed brilliant, on par with the "code is data"
> mantra Lispers like to talk about.
OK - I'll bite.
Let me preface this by saying I'm a proponent of the STL however there
is nothing special about it that has not been done before.
It's using the "It's all about the interface" mantra that has been
touted since before I can remember. Admitedly, C++ just got a whole lot
more knobs in the ability to generate Very Cool (TM) interfaces, but
this is not attributable to the STL.
C++ templates are brilliant. The learning curve may be a bit steep, but
it's one of those things you can learn gradually and be useful early.
Having said that, I think C++ templates was not designed in light of
many of the uses it has today and so some things that would seem like
obvious things to do are much harder than you would think they should be).
Perhaps my biggest peeve about the STL is that there is no "null"
iterator. This one simple thing can cause so much bother when creating
generic interfaces that I've resorted to writing ny own containers in
some cases.
(Is Erik Naggum reputation still alive and kicking ? Last time I heard
about Mr Naggum was about 10 years ago).
I think part of the problem is that this thread is played out. A more
skilled troll would start a new thread with a semi legitimate topic and
then steer it into trollish waters.
·········@gmail.com wrote:
> What do Mohammed, Richard Stallman, Jesus Christ, Linux Torvalds and Erik
> Naggum have in common?
They're not French.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44rjk5F3a2jhU1@individual.net>
F�rster vom Silberwald wrote:
> I resigned from any church. However, I plan to enter (catholic) church
> again since I cannot any longer live with the following two things:
> too much feminism and abortion is considered a good thing in the
> meantime.
What do a pro-life attitude and equality of man and woman (as opposed to
blind feminism) have to do with catholicism?
> And before some of you laugh and deride at me: go to the Vatikan page
> and really read some of the documents of Pope Ratzinger. They are
> available in English language too.
Uuuuh.
--
Suffering from Gates-induced brain leakage...
Förster vom Silberwald wrote:
> Ulrich Hobelmann wrote:
>
> > Uuuuh.
>
> You should read and not laugh. That is all what I can do for you. Take
> on the chances.
>
I did, actually. One thing I still don't understand is how come
Catholic nuns don't dress like Hooters' waitresses? I think it would be
better for the church if they did.
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44mlurF2uircU1@individual.net>
F�rster vom Silberwald wrote:
> Edi Weitz wrote:
>
>> It might be interesting to note that Porsche (which is in a situation
>> very similar to Ferrari but an independent company while Ferrari is a
>> part of Fiat) is by far the most profitable car maker in the world.
>> Guess whose shareholders are happiest? So far for analogies.
>
> Not a valid comparison for two reasons: a) A typical employee at
> "Porsche" will never have the opportunity to buy such a Porsche and b)
Why not? It's called saving. Of course to buy an expensive car you
maybe have to stop living in a big apartment, buy less brand clothing,
don't buy a new PowerBook every year etc.
From what I know, workers in the car industry in Germany earn quite
well. (maybe people in IT earn more, but I'm not there yet)
> The man who is able to straighten out the money for a Porsche is well
> off and has a lot of money. Well I know for sure that making a lot of
> money is not possible in any kinds of legal ways.
He made a lot of money, either quick, or by saving it. "A lot" of money
might take *a lot* of time to accumulate, depending on how lucky you are
to work our crooked system, or to find a job in Great Demand.
> I for one would not like to work for Porsche. And I for one would not
> like buying and owning a Porsche. And I for one would not like being a
> shareholder with Porsche.
I wouldn't buy one, either, because I would rather spend the money on
lots of more useful things. Being a shareholder might be a future
option though, if they continue to do well.
> However, if I had more time I would like to study a bit deeper Common
> Lisp.
Yes :)
--
Suffering from Gates-induced brain leakage...
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uwtg9u5ya.fsf@agharta.de>
On 5 Feb 2006 07:09:52 -0800, "F�rster vom Silberwald" <··········@hotmail.com> wrote:
> Not a valid comparison
Why is it not valid to compare Porsche with Ferrari? Read upthread
before you post.
> for two reasons: a) A typical employee at "Porsche" will never have
> the opportunity to buy such a Porsche and b) The man who is able to
> straighten out the money for a Porsche is well off and has a lot of
> money. Well I know for sure that making a lot of money is not
> possible in any kinds of legal ways.
Nonsense.
> I for one would not like to work for Porsche. And I for one would
> not like buying and owning a Porsche. And I for one would not like
> being a shareholder with Porsche.
Fine. And why do you think we care?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> Fine. And why do you think we care?
I did not write you should care! I still do not see why your weak
"Porsche" example might count.
Dream of your "Porsche" or your shares poor sole.
Schneewittchen
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <umzh3qs1t.fsf@agharta.de>
On 7 Feb 2006 04:09:15 -0800, "F�rster vom Silberwald" <··········@hotmail.com> wrote:
> I still do not see why your weak "Porsche" example might count.
Then you should probably work on your reading comprehension. As I
already said, read upthread. This was a discussion about economic
models, and Ron came up with Ferrari vs. Toyota. I talked about
profitability. A couple of days later you started posting your
uncalled-for pseudo-religious opinions.
> Dream of your "Porsche" or your shares poor sole.
You're talking about shoes or about fish?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m18xsnpa9x.fsf@mordac.netfonds.no>
Edi Weitz <········@agharta.de> writes:
> > Dream of your "Porsche" or your shares poor sole.
>
> You're talking about shoes or about fish?
Eek, poor sole doesn't sound good. Porsche-drivers of course only eat
the best sole available, if necessary they drive their Porsches to
France!
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Edi Weitz <········@agharta.de> writes:
>
> > > Dream of your "Porsche" or your shares poor sole.
> >
> > You're talking about shoes or about fish?
>
> Eek, poor sole doesn't sound good. Porsche-drivers of course only eat
> the best sole available, if necessary they drive their Porsches to
> France!
Yes, but the soles can only dream of being in such a position, the
poor, tasty things.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Edi Weitz wrote:
> > for two reasons: a) A typical employee at "Porsche" will never have
> > the opportunity to buy such a Porsche and b) The man who is able to
> > straighten out the money for a Porsche is well off and has a lot of
> > money. Well I know for sure that making a lot of money is not
> > possible in any kinds of legal ways.
>
> Nonsense.
Btw. It is not nonsense. You should actually read what the CEO and
leader of "Porsche" talks in interviews. If you are luck you can still
found the rather long interview in the weekly newspaper "Die Zeit".
Could be it is still online.
Schneewittche
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44d3tmF1jq1bU1@individual.net>
Ron Garret wrote:
> In article <··············@individual.net>,
> Tin Gherdanarra <···········@gmail.com> wrote:
>
>
>>>That is not a sustainable economic model.
>>
>>I don't think that Lisp needs an economic model.
>>PHP, to stick with the example above, never had one.
>
>
> Of course it did. And it still does. Actually, Lisp had (and has) an
> economic model too, it's just not a very good one.
Please outline what you mean by "economic model", then, because
I'm not following you. Is it like "Linux needs a business model"?
Or is it "economic model" in the sense of "competing for resources"?
> Lisp's current model
> is similar (to use a car analogy) to Ferrari: be the very best, and put
> a significant burden on the user to drive it right, and replace the
> clutch every 3000 miles. PHP is more like a Toyota Corolla. It's no
> good on the track, but anyone can drive it. Guess who sells more cars?
>
> rg
Hm, I can't see a connection to an economic model here, but there's an
objection to a similiar point in another corner of this thread.
It seems to be a common narrative among lispniks: Lisp is unpopular
because it is so powerful. Only the biggest brains need to apply.
It is hard to prove, especially without having to move into
an asbestos-inbox, but nevertheless, the narrative is deeply
flawed. What makes Lisp /intrinsically/ elitist (and your view
is elitist)? Is it the prefix-notation? The nested parantheses?
MAPCAR? And even if it was true that Lisp is harder to use than
other languages, making it easier to use for as many people
as possible should be a high priorty. Lack of mindshare is a
problem in the world of software, because with mindshare comes
industry support, and industry support is good for everybody
in the community.
A language competes for developer resources, mind you. The more
people do your and my work (for love or for money) the less
you and I have to work, and the more interesting things you and
I can do for love or money. An elitist programming language
is a loosing proposition for the elitists -- it is like having
an elitist phone network.
In article <··············@individual.net>,
Tin Gherdanarra <···········@gmail.com> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Tin Gherdanarra <···········@gmail.com> wrote:
> >
> >
> >>>That is not a sustainable economic model.
> >>
> >>I don't think that Lisp needs an economic model.
> >>PHP, to stick with the example above, never had one.
> >
> >
> > Of course it did. And it still does. Actually, Lisp had (and has) an
> > economic model too, it's just not a very good one.
>
> Please outline what you mean by "economic model", then, because
> I'm not following you. Is it like "Linux needs a business model"?
> Or is it "economic model" in the sense of "competing for resources"?
Both. An economic model is a story you tell about how an activity fits
into the grand and glorious scheme of things, and specifically, how the
resources needed to support that activity are obtained.
Let's stick with the car analogy. The typical economic model for a
Ferrari is that a rich person buys it with money that they got doing
something completely unrelated to cars and drives it purely for fun.
The typical economic model for a Corolla is that a middle class person
buys it with money loaned from the bank and then uses it to drive to
work where they earn a salary to pay off the loan.
A typical economic model for a large truck is that a business buys it,
hires a driver (who commutes to work in a Corolla), and charges other
people to haul things in the truck. The proceeds are used to pay for
the truck and the driver, buy more trucks, and make the owners of the
company rich enough to buy Ferraris.
> Hm, I can't see a connection to an economic model here, but there's an
> objection to a similiar point in another corner of this thread.
> It seems to be a common narrative among lispniks: Lisp is unpopular
> because it is so powerful. Only the biggest brains need to apply.
Any argument that mentions brains has completely missed the point. This
is not about brains, it's about dollars. If you have dollars you can
buy brains. The converse is not necessarily true.
> A language competes for developer resources, mind you. The more
> people do your and my work (for love or for money) the less
> you and I have to work, and the more interesting things you and
> I can do for love or money.
Certainly, but even programmers have to eat and have a roof over their
heads, and most of them prefer to acquire those things by purchasing
them rather than building their own shelter and raising their own crops.
So, as Paul Graham has pointed out, you have a choice: you can treat
programming as a hobby and get a day job to pay for food and rent, or
you can treat programming as a business and get your money that way.
Look, maybe I'm wrong and there really is no problem. Maybe everyone in
the world who wants to make a living programming in Lisp is able to do
so, is making as much money as they want, doesn't have to worry about
being laid off, etc. etc. But I suspect that there are a lot of people
out there who would love to use Lisp, but use Perl instead because that
means they don't have to wait tables to support their programming habit.
People think that Lisp needs to build mindshare to make money. I think
that's backwards. Lisp ought to make money to gain mindshare. I think
you'd be amazed how much more popular Lisp would be if a couple of dozen
people became millionaires every year by using it.
rg
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uwtgf895v.fsf@agharta.de>
On Wed, 01 Feb 2006 14:53:24 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
> Here it seems that you are tainted as a troll if you say that PHP
> works out of the box and Lisp does not.
I had the misfortune of participating in a large PHP project from
ca. 1999 to 2003. We discovered several mission-critical bugs that we
had to code around, we had severe perfomance problems, and everyone
who has seen /one/ other programming language, no matter which one,
will probably agree that this abomination is a complete mess as far as
design and concept is concerned. Also, from my experience I'd say
that for any web project that's significantly larger than "here are
photos from my latest vacation" PHP is a nightmare w.r.t. maintenance.
So, yes, if someone is seriously comparing PHP and Common Lisp my
initial reaction is that he is either a troll or he doesn't know what
he's talking about.
If that's the price of becoming popular - lowering your standards to
meet PHP's level -, then I'd prefer that CL would stay as "unpopular"
as it currently is.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <jQ4Ef.153283$6K2.11542@edtnps90>
Edi Weitz wrote:
> On Wed, 01 Feb 2006 14:53:24 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
>
>> Here it seems that you are tainted as a troll if you say that PHP
>> works out of the box and Lisp does not.
>
> I had the misfortune of participating in a large PHP project from
> ca. 1999 to 2003. We discovered several mission-critical bugs that we
> had to code around, we had severe perfomance problems, and everyone
> who has seen /one/ other programming language, no matter which one,
> will probably agree that this abomination is a complete mess as far as
> design and concept is concerned. Also, from my experience I'd say
> that for any web project that's significantly larger than "here are
> photos from my latest vacation" PHP is a nightmare w.r.t. maintenance.
>
This is very important point. To make a language (or its associated
libraries) "easy" to use one has to limit how it is used. To make
it really simple you have to give people "one" way of doing something.
They have to follow a template. Unfortunately when someone needs
something different from the template falls apart because it cannot be
shaped enough to solve the need. You see all those books about
programming who pitch this "easy" (but inflexible) approach, i.e.
"Learn PHP in 24 Hours". You will see all sorts of hoops and
poor approaches to circumvent the "easy" libraries' "set" approach.
Without the psychological acceptance that programming can be very hard,
and an times needs to be hard out of necessity, then we have
programmers with this cognitive dissonance.
Wade
> So, yes, if someone is seriously comparing PHP and Common Lisp my
> initial reaction is that he is either a troll or he doesn't know what
> he's talking about.
>
> If that's the price of becoming popular - lowering your standards to
> meet PHP's level -, then I'd prefer that CL would stay as "unpopular"
> as it currently is.
>
In article <······················@edtnps90>,
Wade Humeniuk <··················@telus.net> wrote:
> Edi Weitz wrote:
> > On Wed, 01 Feb 2006 14:53:24 +0100, Tin Gherdanarra <···········@gmail.com>
> > wrote:
> >
> >> Here it seems that you are tainted as a troll if you say that PHP
> >> works out of the box and Lisp does not.
> >
> > I had the misfortune of participating in a large PHP project from
> > ca. 1999 to 2003. We discovered several mission-critical bugs that we
> > had to code around, we had severe perfomance problems, and everyone
> > who has seen /one/ other programming language, no matter which one,
> > will probably agree that this abomination is a complete mess as far as
> > design and concept is concerned. Also, from my experience I'd say
> > that for any web project that's significantly larger than "here are
> > photos from my latest vacation" PHP is a nightmare w.r.t. maintenance.
> >
>
> This is very important point. To make a language (or its associated
> libraries) "easy" to use one has to limit how it is used.
No, one merely has to provide and document an easily learned subset that
is complete with respect to a common task like writing simple web pages.
See http://webpy.org/tutorial for an example.
rg
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44d2uuF1kaunU1@individual.net>
Wade Humeniuk wrote:
> Edi Weitz wrote:
>
>> On Wed, 01 Feb 2006 14:53:24 +0100, Tin Gherdanarra
>> <···········@gmail.com> wrote:
>>
>>> Here it seems that you are tainted as a troll if you say that PHP
>>> works out of the box and Lisp does not.
>>
>>
>> I had the misfortune of participating in a large PHP project from
>> ca. 1999 to 2003. We discovered several mission-critical bugs that we
>> had to code around, we had severe perfomance problems, and everyone
>> who has seen /one/ other programming language, no matter which one,
>> will probably agree that this abomination is a complete mess as far as
>> design and concept is concerned. Also, from my experience I'd say
>> that for any web project that's significantly larger than "here are
>> photos from my latest vacation" PHP is a nightmare w.r.t. maintenance.
>>
>
> This is very important point. To make a language (or its associated
> libraries) "easy" to use one has to limit how it is used. To make
> it really simple you have to give people "one" way of doing something.
> They have to follow a template. Unfortunately when someone needs
> something different from the template falls apart because it cannot be
> shaped enough to solve the need. You see all those books about
> programming who pitch this "easy" (but inflexible) approach, i.e.
> "Learn PHP in 24 Hours". You will see all sorts of hoops and
> poor approaches to circumvent the "easy" libraries' "set" approach.
> Without the psychological acceptance that programming can be very hard,
> and an times needs to be hard out of necessity, then we have
> programmers with this cognitive dissonance.
You are right in that pitching programming
as easy is a mistake, but it works well for a publishing
industry playing simpletons for suckers. However...
It's hard to be specific without examples here, but I have
the vague feeling that this
"one way"-thing and ease of use vs. flexibility and hard to
use is not correct for any programming language, and even
less for Lisp. I'm aware of the two battle cries
"one way to do it" (python) vs.
"more than one way to skin the cat" (perl), but both sides
are chasing a phantom. There is ALWAYS more than one way.
Python, supposedly "one way to do it", supports alternatives
to iterative programming, for example. (Guido wants to nix these,
but he will have a hard time.)
Every programming language would support some flexibility
on the consumer-side of the API, even C. Ease of use can
always be built on sufficient flexibility, it might require
some thought and some work, though. And Lisp facilities
building simple hoops on flexible components probably better
than any other language. Flexibility does not create
complexity, it is the way to address complexity, and
flexibility can help hiding complexity when components
are assembled to prefab-, ready-to-use operators or
objects. A simplistic example is a function with default
values for parameters that can be expected to cover
common cases. A more elaborate example is setf:
There are off-the-shelf mechanisms that cover common
(special) variables, but you are free to write your
own. Writing your own is complex, but for many
scenarios you can resort to define-setf-expander.
Zope is a web-application framework that is all
defaults -- install it and you basically have a
running web-application. You can start embellishing
it by using a very simplistic scripting language
and uploading files and images. The more kinky your
desires get, and the farther you move away from
the simplistic view on how a web-application should
behave, the more work you have to do, and the
more sophisticated languages you have to use. Thus,
simpletons can do simple things in a simple way and
cracks can do complicated things in a sophisticated
way. Lisp is ideal for such things, for obvious reasons
(macros, passing functions, pulling domain-specific
languages out thin air -- you probably know what I
mean).
>
> Wade
>
>> So, yes, if someone is seriously comparing PHP and Common Lisp my
>> initial reaction is that he is either a troll or he doesn't know what
>> he's talking about.
>>
>> If that's the price of becoming popular - lowering your standards to
>> meet PHP's level -, then I'd prefer that CL would stay as "unpopular"
>> as it currently is.
>>
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <RJcEf.239271$OU5.1150@clgrps13>
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44cpq7F1j22pU1@individual.net>
Edi Weitz wrote:
> On Wed, 01 Feb 2006 14:53:24 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
>
>
>>Here it seems that you are tainted as a troll if you say that PHP
>>works out of the box and Lisp does not.
>
> So, yes, if someone is seriously comparing PHP and Common Lisp my
> initial reaction is that he is either a troll or he doesn't know what
> he's talking about.
I'm the one who does not know what he is talking about.
I did not like PHP and dismissed it as a poorly designed
mess after a few evenings, so I believe everything you
are telling in this paragraph:
>
>
> I had the misfortune of participating in a large PHP project from
> ca. 1999 to 2003. We discovered several mission-critical bugs that we
> had to code around, we had severe perfomance problems, and everyone
> who has seen /one/ other programming language, no matter which one,
> will probably agree that this abomination is a complete mess as far as
> design and concept is concerned. Also, from my experience I'd say
> that for any web project that's significantly larger than "here are
> photos from my latest vacation" PHP is a nightmare w.r.t. maintenance.
I figured that PHP, weird as it is, does work. After all, python
and perl work, so I thought the same is true for PHP. Why did you work
on a PHP-project, by the way? I thought you've been a Lisp hacker
for years? Did you give in to the siren song of big bucks?
You can whisper your reply into my ear, I won't tell anyone...
>
> If that's the price of becoming popular - lowering your standards to
> meet PHP's level -, then I'd prefer that CL would stay as "unpopular"
> as it currently is.
You were right if this really was the deal, but it isn't.
I don't think that Lisp has traded its effectiveness for
unpopularity. This might be up for dispute, of course, but
Lisp's handicaps for wide-spread adaption are what Peter Seibel
calls "extra-linguistic". I think the "import socket"-issue
is part of "extra-linguistic".
>
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44ctq2F1j5seU1@individual.net>
Tin Gherdanarra wrote:
> I don't think that Lisp has traded its effectiveness for
> unpopularity.
From "The Evolution of Lisp" by Guy Steele and Richard Gabriel [1]:
"After a day and a half of technical discussion, this group went off to
the Oakland Original, a greasy submarine sandwich place not far from
CMU. During and after lunch the topic of the name for the Lisp came up,
and such obvious names as NIL and SPICE Lisp were proposed and rejected
� as giving too much credit to one group and not enough to others � and
such non-obvious names as Yu-Hsiang Lisp were also proposed and
reluctantly rejected.
The name felt to be best was �Standard Lisp,� but another dialect was
known by that name already. In searching for similar words, the name
�Common Lisp� came up. Gabriel remarked that this wasn�t a good name
because we were trying to define an Elitist Lisp, and �Common Lisp�
sounded too much like �Common Man Lisp.�
The naming discussion resumed at dinner at the Pleasure Bar, an Italian
restaurant in another Pittsburgh district, but no luck was had by all.
Later in E-mail, Moon referred to �whatever we call this common Lisp,�
and this time, amongst great sadness and consternation that a better
name could not be had, it was selected."
Pascal
[1] Available at http://www.dreamsongs.com/NewFiles/HOPL2-Uncut.pdf
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uu0bive2f.fsf@agharta.de>
On Wed, 01 Feb 2006 23:09:04 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
> Why did you work on a PHP-project, by the way?
Money.
> I thought you've been a Lisp hacker for years?
Nah, I started playing with CL in 2000 and I only started using it
commercially around 2002.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44c21eF1eutcU1@individual.net>
Tin Gherdanarra wrote:
> I disagree because Lisp does not deserve to live in
> an exile. I wonder whether perl or PHP had happened if Lisp
> had been on the map in 1985. All those people buying
> "Learn PHP in 21 days" could be Lisp people. How neat would
> be that be?
Definitely (they would have happened nonetheless).
Perl is first and foremost a shell replacement that integrates regexp
stuff (or sed+awk in general). Only later was it (ab?)used for CGI.
PHP was similar: a very small, fast util-library for Web stuff written
in C. Later versions expanded by feature creep, until PHP became a HTML
template language that merely included executable code (rather than
containing HTML fragments inside the C program).
Using Lisp as a CGI language, or even writing a whole server in Lisp is
a completely different approach. I'm sure the kind of people who like C
for web applications don't really want Lisp there.
--
Suffering from Gates-induced brain leakage...
Tin Gherdanarra wrote:
> > Not all potential customers will be indifferent. Some will be curious.
>
> And drop it when they can't figure out in five minutes how to fetch a
> page from an URL and extract all the <h3>.*?<\/h3>s in Lisp.
<h3 id="thing">Heading
level 3</h3 >
Lisp programmers do tend to have more of a "do the right thing"
mentality, it is true
-dan
Tin Gherdanarra <···········@gmail.com> writes:
> And drop it when they can't figure out in five minutes how to fetch a
> page from an URL and extract all the <h3>.*?<\/h3>s in Lisp.
If that is something which prevents people from using Lisp I'll post
the code here:
(find :h3 (first (multiple-value-bind
(res code serv uri)
(net.aserve.client:do-http-request "http://gustad.com/h3.html")
(when (= code 200)
(net.html.parser:parse-html res))))
:test #'(lambda (a b) (and (consp b) (eq a (first b)))))
Which returns:
(:H3 " This is some H3 stuff ")
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Bill Atkins
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <877j8d32jv.fsf@rpi.edu>
Petter Gustad <·············@gustad.com> writes:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>> And drop it when they can't figure out in five minutes how to fetch a
>> page from an URL and extract all the <h3>.*?<\/h3>s in Lisp.
>
>
> If that is something which prevents people from using Lisp I'll post
> the code here:
>
> (find :h3 (first (multiple-value-bind
> (res code serv uri)
> (net.aserve.client:do-http-request "http://gustad.com/h3.html")
> (when (= code 200)
> (net.html.parser:parse-html res))))
> :test #'(lambda (a b) (and (consp b) (eq a (first b)))))
Beautiful.
> Which returns:
>
> (:H3 " This is some H3 stuff ")
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44cd2cF1gehdU1@individual.net>
Ron Garret wrote:
> The only
> thing that's easy to do with Lisp out of the box is write Lisp
> interpreters.
Here is what you can do out of the box in Allegro Common Lisp:
http://www.franz.com/products/allegrocl/
Here is what you can do out of the box in CLisp:
http://clisp.cons.org/impnotes/extensions.html
Here is what you can do out of the box in CMUCL: http://www.cons.org/cmucl/
Here is what you can do out of the box in Corman Lisp:
http://www.cormanlisp.com/features.html
Here is what you can do out of the box in ECL: http://ecls.sourceforge.net/
Here is what you can do out of the box in LispWorks:
http://www.lispworks.com/products/features.html
Here is what you can do out of the box in MCL:
http://www.digitool.com/getting-started.html
Here is what you can do out of the box in OpenMCL:
http://www.openmcl.org/Doc/index.html
Here is what you can do out of the box in Scieneer CL:
http://www.scieneer.com/scl/index.html
Here is what you can do out of the box in SBCL:
http://www.sbcl.org/manual/Extensions.html#Extensions
I have missed a few implementations. The difference between a language
specification and language implementations really matters!
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> > The only
> > thing that's easy to do with Lisp out of the box is write Lisp
> > interpreters.
>
> Here is what you can do out of the box in Allegro Common Lisp:
> http://www.franz.com/products/allegrocl/
>
> Here is what you can do out of the box in CLisp:
> http://clisp.cons.org/impnotes/extensions.html
>
> Here is what you can do out of the box in CMUCL: http://www.cons.org/cmucl/
>
> Here is what you can do out of the box in Corman Lisp:
> http://www.cormanlisp.com/features.html
>
> Here is what you can do out of the box in ECL: http://ecls.sourceforge.net/
>
> Here is what you can do out of the box in LispWorks:
> http://www.lispworks.com/products/features.html
>
> Here is what you can do out of the box in MCL:
> http://www.digitool.com/getting-started.html
>
> Here is what you can do out of the box in OpenMCL:
> http://www.openmcl.org/Doc/index.html
>
> Here is what you can do out of the box in Scieneer CL:
> http://www.scieneer.com/scl/index.html
>
> Here is what you can do out of the box in SBCL:
> http://www.sbcl.org/manual/Extensions.html#Extensions
>
>
> I have missed a few implementations. The difference between a language
> specification and language implementations really matters!
Indeed. That is why I said "Lisp" and not any particular
implementation. There are particular implementations of Lisp that are
quite fine for many useful tasks, but if you want to avoid vendor
lock-in (a business issue, one should note) you now have to figure out
the intersections of all those lists of features. That can be a
significant task.
It gets worse. How do I know which of those implementations are
reliable? What will it take to get problems fixed? For the commercial
implementations, how stable are the companies producing them? What
happens if my vendor goes bankrupt? I could go on and on. How easy is
it to find Lisp programmers? How much do they expect to be paid? Are
there contract services that I can go to get my code written if I don't
want to make a long-term commitment to an employee? etc. etc. etc.
And, at the end of the day, what have I, not as a programmer but *as a
businessman*, really gained by going with Lisp?
rg
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44e02dF1mnlgU1@individual.net>
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>Ron Garret wrote:
>>
>>
>>>The only
>>>thing that's easy to do with Lisp out of the box is write Lisp
>>>interpreters.
>>
>>Here is what you can do out of the box in Allegro Common Lisp:
>>http://www.franz.com/products/allegrocl/
>>
>>Here is what you can do out of the box in CLisp:
>>http://clisp.cons.org/impnotes/extensions.html
>>
>>Here is what you can do out of the box in CMUCL: http://www.cons.org/cmucl/
>>
>>Here is what you can do out of the box in Corman Lisp:
>>http://www.cormanlisp.com/features.html
>>
>>Here is what you can do out of the box in ECL: http://ecls.sourceforge.net/
>>
>>Here is what you can do out of the box in LispWorks:
>>http://www.lispworks.com/products/features.html
>>
>>Here is what you can do out of the box in MCL:
>>http://www.digitool.com/getting-started.html
>>
>>Here is what you can do out of the box in OpenMCL:
>>http://www.openmcl.org/Doc/index.html
>>
>>Here is what you can do out of the box in Scieneer CL:
>>http://www.scieneer.com/scl/index.html
>>
>>Here is what you can do out of the box in SBCL:
>>http://www.sbcl.org/manual/Extensions.html#Extensions
>>
>>
>>I have missed a few implementations. The difference between a language
>>specification and language implementations really matters!
>
>
> Indeed. That is why I said "Lisp" and not any particular
> implementation. There are particular implementations of Lisp that are
> quite fine for many useful tasks, but if you want to avoid vendor
> lock-in (a business issue, one should note) you now have to figure out
> the intersections of all those lists of features. That can be a
> significant task.
>
> It gets worse. How do I know which of those implementations are
> reliable? What will it take to get problems fixed? For the commercial
> implementations, how stable are the companies producing them? What
> happens if my vendor goes bankrupt? I could go on and on. How easy is
> it to find Lisp programmers? How much do they expect to be paid? Are
> there contract services that I can go to get my code written if I don't
> want to make a long-term commitment to an employee? etc. etc. etc.
>
> And, at the end of the day, what have I, not as a programmer but *as a
> businessman*, really gained by going with Lisp?
These are all questions that are not Lisp-specific. You have to ask
those questions for any language, more specifically for any language
implementation. The fact that some of those languages are
single-implementation languages doesn't really matter. (For example,
"What if Ruby ultimately wins over Python?" is also a valid question in
the same vein.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >
> >>Ron Garret wrote:
> >>
> >>
> >>>The only
> >>>thing that's easy to do with Lisp out of the box is write Lisp
> >>>interpreters.
> >>
> >>Here is what you can do out of the box in Allegro Common Lisp:
> >>http://www.franz.com/products/allegrocl/
> >>
> >>Here is what you can do out of the box in CLisp:
> >>http://clisp.cons.org/impnotes/extensions.html
> >>
> >>Here is what you can do out of the box in CMUCL: http://www.cons.org/cmucl/
> >>
> >>Here is what you can do out of the box in Corman Lisp:
> >>http://www.cormanlisp.com/features.html
> >>
> >>Here is what you can do out of the box in ECL: http://ecls.sourceforge.net/
> >>
> >>Here is what you can do out of the box in LispWorks:
> >>http://www.lispworks.com/products/features.html
> >>
> >>Here is what you can do out of the box in MCL:
> >>http://www.digitool.com/getting-started.html
> >>
> >>Here is what you can do out of the box in OpenMCL:
> >>http://www.openmcl.org/Doc/index.html
> >>
> >>Here is what you can do out of the box in Scieneer CL:
> >>http://www.scieneer.com/scl/index.html
> >>
> >>Here is what you can do out of the box in SBCL:
> >>http://www.sbcl.org/manual/Extensions.html#Extensions
> >>
> >>
> >>I have missed a few implementations. The difference between a language
> >>specification and language implementations really matters!
> >
> >
> > Indeed. That is why I said "Lisp" and not any particular
> > implementation. There are particular implementations of Lisp that are
> > quite fine for many useful tasks, but if you want to avoid vendor
> > lock-in (a business issue, one should note) you now have to figure out
> > the intersections of all those lists of features. That can be a
> > significant task.
> >
> > It gets worse. How do I know which of those implementations are
> > reliable? What will it take to get problems fixed? For the commercial
> > implementations, how stable are the companies producing them? What
> > happens if my vendor goes bankrupt? I could go on and on. How easy is
> > it to find Lisp programmers? How much do they expect to be paid? Are
> > there contract services that I can go to get my code written if I don't
> > want to make a long-term commitment to an employee? etc. etc. etc.
> >
> > And, at the end of the day, what have I, not as a programmer but *as a
> > businessman*, really gained by going with Lisp?
>
> These are all questions that are not Lisp-specific. You have to ask
> those questions for any language, more specifically for any language
> implementation.
Of course. But other languages currently have better answers.
> The fact that some of those languages are
> single-implementation languages doesn't really matter.
Of course it matters. It removes a degree of freedom. It means, for
example, that a library written for "Python" or "Ruby" or "Perl" is much
more likely to work with *my* Python or Ruby or Perl (because there is
only one) than a Lisp library is likely to work with my Lisp. It means
that any feature available in Python will be available in the
implementation that I'm using, because there is only one (modulo
OS-specific features of course). It means that all else being equal
there are ten times as many people using the same Python implementation
that I'm using, finding and fixing bugs, and so it is that much more
likely that my/the implementation will be stable and reliable.
> (For example,
> "What if Ruby ultimately wins over Python?" is also a valid question in
> the same vein.)
Of course it's a valid question. The answer is: if Ruby ultimately wins
over Python it will be the result of a very slow process that unfolds
over a long period of time. It is unlikely in the extreme that the
level of available Python support will drop suddenly and without warning.
rg
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44eubgF1sp6rU1@individual.net>
Ron Garret wrote:
>>>It gets worse. How do I know which of those implementations are
>>>reliable? What will it take to get problems fixed? For the commercial
>>>implementations, how stable are the companies producing them? What
>>>happens if my vendor goes bankrupt? I could go on and on. How easy is
>>>it to find Lisp programmers? How much do they expect to be paid? Are
>>>there contract services that I can go to get my code written if I don't
>>>want to make a long-term commitment to an employee? etc. etc. etc.
>>>
>>>And, at the end of the day, what have I, not as a programmer but *as a
>>>businessman*, really gained by going with Lisp?
>>
>>These are all questions that are not Lisp-specific. You have to ask
>>those questions for any language, more specifically for any language
>>implementation.
>
> Of course. But other languages currently have better answers.
I don't think so. Recall Edi Weitz's story when he had to provide
evidence for one of his customers that there are enough Lispers willing
to take over his job in case he gets hit by a bus. ;)
>>The fact that some of those languages are
>>single-implementation languages doesn't really matter.
>
> Of course it matters. It removes a degree of freedom. It means, for
> example, that a library written for "Python" or "Ruby" or "Perl" is much
> more likely to work with *my* Python or Ruby or Perl (because there is
> only one) than a Lisp library is likely to work with my Lisp. It means
> that any feature available in Python will be available in the
> implementation that I'm using, because there is only one (modulo
> OS-specific features of course). It means that all else being equal
> there are ten times as many people using the same Python implementation
> that I'm using, finding and fixing bugs, and so it is that much more
> likely that my/the implementation will be stable and reliable.
I really, really, really, really, really don't get this. Any library
written for CLisp is highly likely to run on my copy of CLisp. Any
library written for SBCL is highly likely to run on my copy of SBCL.
Etc. pp. What's the problem?
Any language that has a larger community than your favourite language
will fare better in those areas. Any language that has a smaller
community will turn out worse. That's a trivial fact.
>>(For example,
>>"What if Ruby ultimately wins over Python?" is also a valid question in
>>the same vein.)
>
>
> Of course it's a valid question. The answer is: if Ruby ultimately wins
> over Python it will be the result of a very slow process that unfolds
> over a long period of time. It is unlikely in the extreme that the
> level of available Python support will drop suddenly and without warning.
Same for Common Lisp.
I really think you are too influenced by the bad state of Digitool.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> I really, really, really, really, really don't get this. Any library
> written for CLisp is highly likely to run on my copy of CLisp. Any
> library written for SBCL is highly likely to run on my copy of SBCL.
> Etc. pp. What's the problem?
How is this different from the Scheme community? When newbies ask about
the differences between Common Lisp and Scheme, the conventional wisdom
that they get here is that Scheme is a minimalist standard, in order to
get anything practical done with it one needs a library that brings it
up to the level of Common Lisp and, since in Common Lisp the library is
standardized and in Scheme it's typically implementation specific,
Common Lisp is in that respect superior (because there's consensus that
standardizing e.g. 'member' rather than having everyone's toolbox
contain a copy with slightly different semantics/name is a Good Thing).
Schemers, for some odd reason, don't find this a problem, perhaps
because the majority of functions in CL that aren't in R5RS take about
as long to write as they do to look up.
Lispers learn that even with all those standardized functions, it's
still impossible to get any useful work done in pure CL, because it
doesn't standardize those things which MOST NEED standardization, such
as the semantics of IPC, multiprocessing, XML processing...
So we've got i implementations, j compatibility layers to handle the
implementation differences, and k libraries using some combination of
incompatible implementation specific stuff and incompatible
compatibility layers. All that, and I've got to be an amateur IP lawyer
as well, because of course all the licenses are different, untested and
written by other amateur lawyers. Tell me how integrating a ball of mud
like that is going to save me time and grief compared to writing
everything from scratch?
The REASON we like to see the community growing -- or one of the main
ones, anyway -- is because we understand the benefits of the network
effect combined with software reuse. We can all stand on each others'
shoulders and see farther. UNFORTUNATELY, our exponent (if we're growing
at e^n) is lower than that in other languages, because the
incompatibilities between implementations/compatibility layers creates
something analogous to friction; a loss of a percentage of our
productivity. Making this friction go away is an itch that nobody wants
to scratch, since writing new code is fun and leads to plaudits and
laurels, whereas porting old code and asking wizards and vendors to
change/standardize their interfaces is not fun and leads to darts and
brickbats.
On 2006-02-02 13:42:35 -0500, Cameron MacKinnon
<··········@clearspot.net> said:
> Lispers learn that even with all those standardized functions, it's
> still impossible to get any useful work done in pure CL, because it
> doesn't standardize those things which MOST NEED standardization, such
> as the semantics of IPC, multiprocessing, XML processing...
At the risk of having history prove me laughably wrong I would go so
far as to say that the fragmentation of lisp will end when a single,
affordable[1] implementation provides all of the following across
Windows, Linux intel, and Mac OS X intel[2]:
a. SMP friendly multiprocessing
b. asdf-installablily of most major libraries
c. c library interface which includes access to platform native GUI
facilities [3]
This implementation will then just become the de-facto standard and
other implementations will either become compatible with it, or remain
niche players.
[1] I cynically contend that what makes open source software popular is
its beer-nature not it's speech-nature ;^)
[2] by the time this comes about, Mac OS X ppc will be largely irrelevant.
[3] a cross-platform GUI layer is neither necessary nor even desirable
since this almost always means LCD which is unacceptable for many
purposes
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uslr19snl.fsf@agharta.de>
On Thu, 2 Feb 2006 18:38:58 -0500, Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> At the risk of having history prove me laughably wrong I would go so
> far as to say that the fragmentation of lisp will end when a single,
> affordable[1] implementation provides all of the following across
> Windows, Linux intel, and Mac OS X intel[2]:
>
> a. SMP friendly multiprocessing
> b. asdf-installablily of most major libraries
> c. c library interface which includes access to platform native GUI
> facilities [3]
>
> This implementation will then just become the de-facto standard and
> other implementations will either become compatible with it, or
> remain niche players.
>
> [1] I cynically contend that what makes open source software popular
> is its beer-nature not it's speech-nature ;^)
> [2] by the time this comes about, Mac OS X ppc will be largely irrelevant.
> [3] a cross-platform GUI layer is neither necessary nor even
> desirable since this almost always means LCD which is unacceptable
> for many purposes
Sounds pretty convincing to me and at the moment SBCL seems to be the
most likely candidate. I won't bet against you... :)
Two points, though:
1. I'd replace "affordable" with "free" (as in beer), underlining your
first footnote. If money is to be made, then it'll be through
support, packaging, or some kind of added value - see ActiveState's
business model or this link:
<http://random-state.net/log/3343480139.html>
2. As far as GUI is concerned most people will probably want something
slightly higher-level than C-based access to the native facilities.
LispWorks' CAPI is on the right track IMHO but it's not hackable if
you're missing something. An open source replacement will change
exactly that even if it'll probably take a long time until it's on
par with CAPI.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2006-02-02 19:45:34 -0500, Edi Weitz <········@agharta.de> said:
> 2. As far as GUI is concerned most people will probably want something
> slightly higher-level than C-based access to the native facilities.
> LispWorks' CAPI is on the right track IMHO but it's not hackable if
> you're missing something. An open source replacement will change
> exactly that even if it'll probably take a long time until it's on
> par with CAPI.
True, most people will want more, I was just saying that we'd want both
- low level platform native GUI interfaces and a cross-platform
library. We can code the CAPI-like library with low-level access, but
not the other way round - unless the cross-platform library is open
source, in which case we must have some sort of low-level access to
modify it anyway.
Raffael Cavallaro wrote:
> On 2006-02-02 19:45:34 -0500, Edi Weitz <········@agharta.de> said:
>
>> 2. As far as GUI is concerned most people will probably want something
>> slightly higher-level than C-based access to the native facilities.
>> LispWorks' CAPI is on the right track IMHO but it's not hackable if
>> you're missing something. An open source replacement will change
>> exactly that even if it'll probably take a long time until it's on
>> par with CAPI.
>
>
> True, most people will want more, I was just saying that we'd want both
> - low level platform native GUI interfaces and a cross-platform library.
> We can code the CAPI-like library with low-level access, but not the
> other way round - unless the cross-platform library is open source, in
> which case we must have some sort of low-level access to modify it anyway.
>
So, with your desire of an open source cross platform library, you
can be helped, just look at my signature :).
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <ufyn098gn.fsf@agharta.de>
On Fri, 03 Feb 2006 08:42:03 +0100, Peter Herth <·······@t-online.de> wrote:
> So, with your desire of an open source cross platform library, you
> can be helped, just look at my signature :).
I don't know about others but while LTK is cute it's not what I was
talking about and what I would want. Being able to directly access
the operating system's native GUI without the need to go through some
middle layer is something completely different. It's like the
difference between using your Lisp's socket interface to access a
remote web server or using JFLI to let Java do it for you.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 03 Feb 2006 08:42:03 +0100, Peter Herth <·······@t-online.de> wrote:
>
>
>>So, with your desire of an open source cross platform library, you
>>can be helped, just look at my signature :).
>
>
> I don't know about others but while LTK is cute it's not what I was
> talking about and what I would want. Being able to directly access
> the operating system's native GUI without the need to go through some
> middle layer is something completely different. It's like the
> difference between using your Lisp's socket interface to access a
> remote web server or using JFLI to let Java do it for you.
Yes, I rather was answering Raffael, who spoke about a Lisp library
talking to an open source gui set - and that Tk is (and many extensions
show that you can extend Tk using native widgets too, like the Quicktime
Tk widget). But in any case, you made me update my signature! :)
Cheers,
Peter
--
Ltk, the cute lisp gui http://www.peter-herth.de/ltk/
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44f7cjF1u47lU1@individual.net>
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> I really, really, really, really, really don't get this. Any library
>> written for CLisp is highly likely to run on my copy of CLisp. Any
>> library written for SBCL is highly likely to run on my copy of SBCL.
>> Etc. pp. What's the problem?
>
> How is this different from the Scheme community?
Not at all.
> When newbies ask about
> the differences between Common Lisp and Scheme, the conventional wisdom
> that they get here is that Scheme is a minimalist standard, in order to
> get anything practical done with it one needs a library that brings it
> up to the level of Common Lisp and, since in Common Lisp the library is
> standardized and in Scheme it's typically implementation specific,
> Common Lisp is in that respect superior (because there's consensus that
> standardizing e.g. 'member' rather than having everyone's toolbox
> contain a copy with slightly different semantics/name is a Good Thing).
Correct, as far as I can see.
> Schemers, for some odd reason, don't find this a problem, perhaps
> because the majority of functions in CL that aren't in R5RS take about
> as long to write as they do to look up.
I think you are on the wrong track here. Try implementing CLOS. ;)
No, I think that the majority of Scheme programmers is just as pragmatic
as Common Lispers. They pick the one implementation that suits their
specific needs best and just go with it.
> Lispers learn that even with all those standardized functions, it's
> still impossible to get any useful work done in pure CL, because it
> doesn't standardize those things which MOST NEED standardization, such
> as the semantics of IPC, multiprocessing, XML processing...
You don't need standards to get things done, you only need portable
libraries. Those libraries exist, and/or are being worked on.
It's amazing that in this whole discussion factual improvements of the
state of affairs are typically silently dismissed. I recall that the
most often asked feature when I entered the Lisp community was a
portable GUI library. Peter Herth single-handedly solved this issue.
And, BTW, got famous for it and was eventually employed because of the
good reputation he earned by doing this.
I agree with Kenny that things are much better off than some people seem
to think. It's not paradise yet, but it's also not the end of all hope.
> The REASON we like to see the community growing -- or one of the main
> ones, anyway -- is because we understand the benefits of the network
> effect combined with software reuse. We can all stand on each others'
> shoulders and see farther. UNFORTUNATELY, our exponent (if we're growing
> at e^n) is lower than that in other languages, because the
> incompatibilities between implementations/compatibility layers creates
> something analogous to friction; a loss of a percentage of our
> productivity. Making this friction go away is an itch that nobody wants
> to scratch, since writing new code is fun and leads to plaudits and
> laurels, whereas porting old code and asking wizards and vendors to
> change/standardize their interfaces is not fun and leads to darts and
> brickbats.
It seems that the only solution would then be to drop Common Lisp and go
with a new Lisp dialect that doesn't suffer from the large number of
implementations. That would be counterproductive as well though because
the accumulated technical investments that have been put into Common
Lisp implementations over the decades would be lost.
Again, an alternative approach would be to regard the diversity of the
Common Lisp community as an advantage, which I think it indeed is. The
different implementations have, for example, very different performance
characteristics and different strengths and weaknesses that are, to a
certain degree, incompatible. The ability to choose from a range of
implementations can be an advantage.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> It's amazing that in this whole discussion factual improvements of the
> state of affairs are typically silently dismissed.
Not at all. I certainly acknowledge that things are getting better.
I'm just saying that things are still far from where ideally they ought
to be, that the pace of change is slow, that the pace could be increased
with money, and that the most effective way to inject money into the
process is for the community to pay more attention to business issues.
> I agree with Kenny that things are much better off than some people seem
> to think. It's not paradise yet, but it's also not the end of all hope.
No one ever said it was the end of all hope. If it were, we would not
be having this discussion.
> > The REASON we like to see the community growing -- or one of the main
> > ones, anyway -- is because we understand the benefits of the network
> > effect combined with software reuse. We can all stand on each others'
> > shoulders and see farther. UNFORTUNATELY, our exponent (if we're growing
> > at e^n) is lower than that in other languages, because the
> > incompatibilities between implementations/compatibility layers creates
> > something analogous to friction; a loss of a percentage of our
> > productivity. Making this friction go away is an itch that nobody wants
> > to scratch, since writing new code is fun and leads to plaudits and
> > laurels, whereas porting old code and asking wizards and vendors to
> > change/standardize their interfaces is not fun and leads to darts and
> > brickbats.
>
> It seems that the only solution would then be to drop Common Lisp and go
> with a new Lisp dialect that doesn't suffer from the large number of
> implementations. That would be counterproductive as well though because
> the accumulated technical investments that have been put into Common
> Lisp implementations over the decades would be lost.
That is known as the "sunk cost fallacy."
> Again, an alternative approach would be to regard the diversity of the
> Common Lisp community as an advantage, which I think it indeed is. The
> different implementations have, for example, very different performance
> characteristics and different strengths and weaknesses that are, to a
> certain degree, incompatible. The ability to choose from a range of
> implementations can be an advantage.
Multiple implementations has (have?) both advantages and disadvantages.
Many of the disadvantages could be mitigated with standardized
interfaces to libraries for programming tasks that have become common
since CL was standardized (sockets, HTML, XML, email, etc.).
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>It's amazing that in this whole discussion factual improvements of the
>>state of affairs are typically silently dismissed.
>
>
> Not at all. I certainly acknowledge that things are getting better.
> I'm just saying that things are still far from where ideally they ought
> to be, that the pace of change is slow...
Patience, grasshopper. Lisp has been Found(tm). The outcome is inevitable.
Don't forget, Lisp really is as good as we say it is. Though I am not
sure you really believe that any more.
kenny
In article <··············@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >
> >>It's amazing that in this whole discussion factual improvements of the
> >>state of affairs are typically silently dismissed.
> >
> >
> > Not at all. I certainly acknowledge that things are getting better.
> > I'm just saying that things are still far from where ideally they ought
> > to be, that the pace of change is slow...
>
> Patience, grasshopper. Lisp has been Found(tm). The outcome is inevitable.
Is it? I suppose you're eagerly awaiting the return of the betamax too?
The belief that technical superiority insures success in the marketplace
is hopelessly naive.
> Don't forget, Lisp really is as good as we say it is. Though I am not
> sure you really believe that any more.
I certainly don't believe that Lisp as it currently stands is so good
that its return to economic viability is inevitable. And frankly, I
don't think you think so either, otherwise why would you spend so much
time and effort cheerleading for it?
rg
Ron Garret wrote:
> In article <··············@news-wrt-01.rdc-nyc.rr.com>,
> Kenny Tilton <·············@nyc.rr.com> wrote:
>
>
>>Ron Garret wrote:
>>
>>>In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>
>>>
>>>>It's amazing that in this whole discussion factual improvements of the
>>>>state of affairs are typically silently dismissed.
>>>
>>>
>>>Not at all. I certainly acknowledge that things are getting better.
>>>I'm just saying that things are still far from where ideally they ought
>>>to be, that the pace of change is slow...
>>
>>Patience, grasshopper. Lisp has been Found(tm). The outcome is inevitable.
>
>
> Is it? I suppose you're eagerly awaiting the return of the betamax too?
I see you are in "argue mode". Have you seen a surge in new Betamax
machines and/or releases in the last year? Of course you haven't, but
you are in "argue mode" so you just throw stuff out to keep the flamewar
going.
>
> The belief that technical superiority insures success in the marketplace
> is hopelessly naive.
Who are you to tell me what I believe? I am going mostly by c.l.l newby
traffic, somewhat by blogging I see, and a lot by the overall trend
towards dynamic languages. Java doing Groovy is like new VHS receivers
bragging about a new feature: being Betamax compatible. (Since you like
that godforsaken analogy so much.)
>
>
>>Don't forget, Lisp really is as good as we say it is. Though I am not
>>sure you really believe that any more.
>
>
> I certainly don't believe that Lisp as it currently stands is so good
> that its return to economic viability is inevitable. And frankly, I
> don't think you think so either, otherwise why would you spend so much
> time and effort cheerleading for it?
Nonsense. I like arguing as much as you. I just try to be a little more
careful with my analogies.
By the way, this group has been watching me work on a C-to-Lisp
translator for a month. I am resurrecting an old C app I used to sell.
Why do I want to translate it to Lisp if I do not believe the time and
trouble will pay for itself?
After you answer that (hopefully with an analogy yo Betamax), explain
why, after I saw what the Lisp looked like, I decided to just rewrite
the damn thing from scratch in Lisp.[1] Remember, you cannot use "Kenny
loves Lisp" in your explanation.
Now enough of this bullshit. What are you flying now?
kt
[1] Yeah, I could have figured this out without first doing the
translation. But it was more fun than I have had in a while, and it got
me programming again, and I used deftype and pretty-printer callbacks
for the first time, so it was not a total waste. k
In article <···············@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> >>Patience, grasshopper. Lisp has been Found(tm). The outcome is inevitable.
> >
> >
> > Is it? I suppose you're eagerly awaiting the return of the betamax too?
>
> I see you are in "argue mode".
And you are in pontification and condescension mode. So?
> you just throw stuff out to keep the flamewar going.
Oh, and addressing me as "grasshopper" was supposed to douse the fire?
> > The belief that technical superiority insures success in the marketplace
> > is hopelessly naive.
>
> Who are you to tell me what I believe?
You are the one who said, "Lisp really is as good as we say it is" and
"The outcome is inevitable." What was I supposed to conclude?
> Now enough of this bullshit. What are you flying now?
Read Xooglers if you really want to know.
rg
Ron Garret wrote:
>>Now enough of this bullshit. What are you flying now?
>
>
> Read Xooglers if you really want to know.
Oh, I read that. Very well written. Still flying the plane you had when
Chuck passed up the flight? I thought you might have made an upgrade.
kenny
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1ek2kx0ui.fsf@mordac.netfonds.no>
Kenny Tilton <·············@nyc.rr.com> writes:
> I see you are in "argue mode". Have you seen a surge in new Betamax
> machines and/or releases in the last year? Of course you haven't, but
> you are in "argue mode" so you just throw stuff out to keep the
> flamewar going.
The betamax analogy is just plain wrong. Betamax was the better
technology for a short timespan a long time ago, whereas lisp /is/ the
better technology, and I bet we're not going to see programming
languages for a loong time which are to lisp what hard disk video
recorders (or next year: iPod nano-like flash-based video recorders
;)) are to betamax recorders...
(anyone remember the japanese 5th generation projects? har-har!)
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Kenny Tilton <·············@nyc.rr.com> writes:
>
>> I see you are in "argue mode". Have you seen a surge in new Betamax
>> machines and/or releases in the last year? Of course you haven't, but
>> you are in "argue mode" so you just throw stuff out to keep the
>> flamewar going.
>
> The betamax analogy is just plain wrong. Betamax was the better
> technology for a short timespan a long time ago, whereas lisp /is/ the
> better technology, and I bet we're not going to see programming
> languages for a loong time which are to lisp what hard disk video
> recorders (or next year: iPod nano-like flash-based video recorders
> ;)) are to betamax recorders...
Yes.
> (anyone remember the japanese 5th generation projects? har-har!)
You mean like Aibot, Asimo, and all this robotics industry they've developped?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais �t�: �Qui suis-je? O� vais-je?�
comme l'a formul� si adroitement notre ami Pascal, mais plut�t:
�Comment vais-je m'en tirer?� -- Jean Yanne
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1irrwveqy.fsf@mordac.netfonds.no>
Pascal Bourguignon <······@informatimago.com> writes:
> You mean like Aibot, Asimo, and all this robotics industry they've developped?
No, I was thinking of 5GL:
http://en.wikipedia.org/wiki/Fifth-generation_programming_language
There were some cool by-products, though, like Nakashima's "Uranus", an
extended prolog implemented in common lisp.
--
(espen)
Pascal Costanza <··@p-cos.net> writes:
> Cameron MacKinnon wrote:
> > Pascal Costanza wrote:
> >
> >> I really, really, really, really, really don't get this. Any
> >> library written for CLisp is highly likely to run on my copy of
> >> CLisp. Any library written for SBCL is highly likely to run on my
> >> copy of SBCL. Etc. pp. What's the problem?
> > How is this different from the Scheme community?
>
> Not at all.
Is de facto portability actually that good between the major Schemes?
Impressive if that's true, but I thought it was more painful, like
porting Smalltalk. The reality of porting between implementations is
that it's almost always really easy. Since all implementations use
the same high-level facilities, you only have to port a few grungy
low-level details, which is easy if you're porting to your preferred
lisp (where you know how, for example, character encoding or sockets
work). I bet that applications like ITA's would be hard to port, though.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44gmujF21pa1U1@individual.net>
Thomas F. Burdick wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Cameron MacKinnon wrote:
>>
>>>Pascal Costanza wrote:
>>>
>>>>I really, really, really, really, really don't get this. Any
>>>>library written for CLisp is highly likely to run on my copy of
>>>>CLisp. Any library written for SBCL is highly likely to run on my
>>>>copy of SBCL. Etc. pp. What's the problem?
>>>
>>>How is this different from the Scheme community?
>>
>>Not at all.
>
> Is de facto portability actually that good between the major Schemes?
> Impressive if that's true, but I thought it was more painful, like
> porting Smalltalk. The reality of porting between implementations is
> that it's almost always really easy. Since all implementations use
> the same high-level facilities, you only have to port a few grungy
> low-level details, which is easy if you're porting to your preferred
> lisp (where you know how, for example, character encoding or sockets
> work). I bet that applications like ITA's would be hard to port, though.
You're right, I guess, but the context was about how easy it is to pick
a single implementation of Common Lisp or Scheme, focus on that single
implementation and get work done with it. If you don't care about
portability, it seems to me that there are quite a few Scheme
implementations which are very usable.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> >>>It gets worse. How do I know which of those implementations are
> >>>reliable? What will it take to get problems fixed? For the commercial
> >>>implementations, how stable are the companies producing them? What
> >>>happens if my vendor goes bankrupt? I could go on and on. How easy is
> >>>it to find Lisp programmers? How much do they expect to be paid? Are
> >>>there contract services that I can go to get my code written if I don't
> >>>want to make a long-term commitment to an employee? etc. etc. etc.
> >>>
> >>>And, at the end of the day, what have I, not as a programmer but *as a
> >>>businessman*, really gained by going with Lisp?
> >>
> >>These are all questions that are not Lisp-specific. You have to ask
> >>those questions for any language, more specifically for any language
> >>implementation.
> >
> > Of course. But other languages currently have better answers.
>
> I don't think so. Recall Edi Weitz's story when he had to provide
> evidence for one of his customers that there are enough Lispers willing
> to take over his job in case he gets hit by a bus. ;)
What are you referring to? The only reference I could find (searching
Google groups for author Edi Weitz and "hit by a bus") was a call for
Lisp programmers in Hamburg to contact him privately.
> >>The fact that some of those languages are
> >>single-implementation languages doesn't really matter.
> >
> > Of course it matters. It removes a degree of freedom. It means, for
> > example, that a library written for "Python" or "Ruby" or "Perl" is much
> > more likely to work with *my* Python or Ruby or Perl (because there is
> > only one) than a Lisp library is likely to work with my Lisp. It means
> > that any feature available in Python will be available in the
> > implementation that I'm using, because there is only one (modulo
> > OS-specific features of course). It means that all else being equal
> > there are ten times as many people using the same Python implementation
> > that I'm using, finding and fixing bugs, and so it is that much more
> > likely that my/the implementation will be stable and reliable.
>
> I really, really, really, really, really don't get this. Any library
> written for CLisp is highly likely to run on my copy of CLisp. Any
> library written for SBCL is highly likely to run on my copy of SBCL.
> Etc. pp. What's the problem?
The problem is that CLisp and SBCL (and all the others) are effectively
all different languages with different feature sets that just happen to
share a common but by itself not very useful core.
> Any language that has a larger community than your favourite language
> will fare better in those areas. Any language that has a smaller
> community will turn out worse. That's a trivial fact.
Yes, but a language with N mutually incompatible implementations will
fragment its user community N-ways. So even if all else were equal,
each Lisp implementation would on average have only one tenth as many
users as each (which is to say "the") Python implementation.
> >>(For example,
> >>"What if Ruby ultimately wins over Python?" is also a valid question in
> >>the same vein.)
> >
> >
> > Of course it's a valid question. The answer is: if Ruby ultimately wins
> > over Python it will be the result of a very slow process that unfolds
> > over a long period of time. It is unlikely in the extreme that the
> > level of available Python support will drop suddenly and without warning.
>
> Same for Common Lisp.
But Common Lisp by itself (as contrasted with any particular
implementation of Common Lisp with implementation-specific extensions)
has very limited utility.
> I really think you are too influenced by the bad state of Digitool.
That is possible. MCL is my favorite implementation, and I know more
about the state of Digitool than any other vendor. Still, I have
looked, and I do not see overt signs of robust growth at any of the
other vendors either.
rg
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44fm33F1vg53U1@individual.net>
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>Ron Garret wrote:
>>
>>>Of course. But other languages currently have better answers.
>>
>>I don't think so. Recall Edi Weitz's story when he had to provide
>>evidence for one of his customers that there are enough Lispers willing
>>to take over his job in case he gets hit by a bus. ;)
>
> What are you referring to? The only reference I could find (searching
> Google groups for author Edi Weitz and "hit by a bus") was a call for
> Lisp programmers in Hamburg to contact him privately.
Yep, that's the one.
>>>>The fact that some of those languages are
>>>>single-implementation languages doesn't really matter.
>>>
>>>Of course it matters. It removes a degree of freedom. It means, for
>>>example, that a library written for "Python" or "Ruby" or "Perl" is much
>>>more likely to work with *my* Python or Ruby or Perl (because there is
>>>only one) than a Lisp library is likely to work with my Lisp. It means
>>>that any feature available in Python will be available in the
>>>implementation that I'm using, because there is only one (modulo
>>>OS-specific features of course). It means that all else being equal
>>>there are ten times as many people using the same Python implementation
>>>that I'm using, finding and fixing bugs, and so it is that much more
>>>likely that my/the implementation will be stable and reliable.
>>
>>I really, really, really, really, really don't get this. Any library
>>written for CLisp is highly likely to run on my copy of CLisp. Any
>>library written for SBCL is highly likely to run on my copy of SBCL.
>>Etc. pp. What's the problem?
>
> The problem is that CLisp and SBCL (and all the others) are effectively
> all different languages with different feature sets that just happen to
> share a common but by itself not very useful core.
>
>>Any language that has a larger community than your favourite language
>>will fare better in those areas. Any language that has a smaller
>>community will turn out worse. That's a trivial fact.
>
> Yes, but a language with N mutually incompatible implementations will
> fragment its user community N-ways. So even if all else were equal,
> each Lisp implementation would on average have only one tenth as many
> users as each (which is to say "the") Python implementation.
This argument seems to be based on the hidden assumption that everything
is greener on the other side. I don't think it is.
Do you mean Python, JPython, Jython, IronPython or Stackless Python? Do
you mean Python 2.2, 2.3 or 2.4? What if Guido van Rossum changes the
language again and again?
>>>>(For example,
>>>>"What if Ruby ultimately wins over Python?" is also a valid question in
>>>>the same vein.)
>>>
>>>Of course it's a valid question. The answer is: if Ruby ultimately wins
>>>over Python it will be the result of a very slow process that unfolds
>>>over a long period of time. It is unlikely in the extreme that the
>>>level of available Python support will drop suddenly and without warning.
>>
>>Same for Common Lisp.
>
> But Common Lisp by itself (as contrasted with any particular
> implementation of Common Lisp with implementation-specific extensions)
> has very limited utility.
It is unlikely in the extreme that the level of available support for
Allegro Common Lisp, CLisp, CMUCL, LispWorks, OpenMCL, SBCL, etc. pp.
will drop suddenly and without warning.
>>I really think you are too influenced by the bad state of Digitool.
>
> That is possible. MCL is my favorite implementation, and I know more
> about the state of Digitool than any other vendor. Still, I have
> looked, and I do not see overt signs of robust growth at any of the
> other vendors either.
Allegro has just released 8.0. LispWorks is going to release 5.0 this
year. Most open source implementations are doing fine and seem to have a
steady user community.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >
> >>Ron Garret wrote:
> >>
> >>>Of course. But other languages currently have better answers.
> >>
> >>I don't think so. Recall Edi Weitz's story when he had to provide
> >>evidence for one of his customers that there are enough Lispers willing
> >>to take over his job in case he gets hit by a bus. ;)
> >
> > What are you referring to? The only reference I could find (searching
> > Google groups for author Edi Weitz and "hit by a bus") was a call for
> > Lisp programmers in Hamburg to contact him privately.
>
> Yep, that's the one.
Well, that's hardly reassuring. Do we know how many responses he got?
(The mere fact that I have to ask this question is a show stopper under
many circumstances!)
> >>>>The fact that some of those languages are
> >>>>single-implementation languages doesn't really matter.
> >>>
> >>>Of course it matters. It removes a degree of freedom. It means, for
> >>>example, that a library written for "Python" or "Ruby" or "Perl" is much
> >>>more likely to work with *my* Python or Ruby or Perl (because there is
> >>>only one) than a Lisp library is likely to work with my Lisp. It means
> >>>that any feature available in Python will be available in the
> >>>implementation that I'm using, because there is only one (modulo
> >>>OS-specific features of course). It means that all else being equal
> >>>there are ten times as many people using the same Python implementation
> >>>that I'm using, finding and fixing bugs, and so it is that much more
> >>>likely that my/the implementation will be stable and reliable.
> >>
> >>I really, really, really, really, really don't get this. Any library
> >>written for CLisp is highly likely to run on my copy of CLisp. Any
> >>library written for SBCL is highly likely to run on my copy of SBCL.
> >>Etc. pp. What's the problem?
> >
> > The problem is that CLisp and SBCL (and all the others) are effectively
> > all different languages with different feature sets that just happen to
> > share a common but by itself not very useful core.
> >
> >>Any language that has a larger community than your favourite language
> >>will fare better in those areas. Any language that has a smaller
> >>community will turn out worse. That's a trivial fact.
> >
> > Yes, but a language with N mutually incompatible implementations will
> > fragment its user community N-ways. So even if all else were equal,
> > each Lisp implementation would on average have only one tenth as many
> > users as each (which is to say "the") Python implementation.
>
> This argument seems to be based on the hidden assumption that everything
> is greener on the other side. I don't think it is.
>
> Do you mean Python, JPython, Jython, IronPython or Stackless Python? Do
> you mean Python 2.2, 2.3 or 2.4? What if Guido van Rossum changes the
> language again and again?
There is a canonical implementation of Python, which is what is referred
to when one says Python. There are many niche offshoots, and they are
conveniently referred to by other names. For Lisp there is nothing but
offshoots.
As for version changing, most people consider this a feature. It means
that the language is evolving with the times, and indeed Python has a
very nice mechanism for managing version migration through the use of
the __future__ feature. Lisp has no such mechanism, which is one of the
reasons why it is such a mess w.r.t. certain crucial features like
threads. (Certain *implementations* of Lisp have such mechanisms, but
Lisp itself does not.)
> >>>>(For example,
> >>>>"What if Ruby ultimately wins over Python?" is also a valid question in
> >>>>the same vein.)
> >>>
> >>>Of course it's a valid question. The answer is: if Ruby ultimately wins
> >>>over Python it will be the result of a very slow process that unfolds
> >>>over a long period of time. It is unlikely in the extreme that the
> >>>level of available Python support will drop suddenly and without warning.
> >>
> >>Same for Common Lisp.
> >
> > But Common Lisp by itself (as contrasted with any particular
> > implementation of Common Lisp with implementation-specific extensions)
> > has very limited utility.
>
> It is unlikely in the extreme that the level of available support for
> Allegro Common Lisp, CLisp, CMUCL, LispWorks, OpenMCL, SBCL, etc. pp.
> will drop suddenly and without warning.
Given that the level of support for many of these is already lamentably
low [1] that is not saying much. But how do you know that LispWorks
won't go bankrupt next week, or that Franz won't go bankrupt next year?
For that matter, how do you know that they aren't bankrupt already?
Digitool has been putting on a brave face for years now. (So has Gold
Hill, since you don't seem to like my using Digitool as an example.)
> >>I really think you are too influenced by the bad state of Digitool.
> >
> > That is possible. MCL is my favorite implementation, and I know more
> > about the state of Digitool than any other vendor. Still, I have
> > looked, and I do not see overt signs of robust growth at any of the
> > other vendors either.
>
> Allegro has just released 8.0. LispWorks is going to release 5.0 this
> year. Most open source implementations are doing fine and seem to have a
> steady user community.
Like I keep saying, there is certainly cause for optimism or we would
not be having this conversation. But it can be an anti-self-fulfilling
prophecy if one allows optimism to turn into complacency.
rg
[1] I do not wish to take anything away from the fine job that is being
done by the volunteers who maintain and support the open-source
implementations. But for someone running a *business* it is an enormous
risk to bet the future of the company on their continued good will.
From: Bulent Murtezaoglu
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87ek2lyxgo.fsf@p4.internal>
>>>>> "RG" == Ron Garret <·········@flownet.com> writes:
[...]
RG> ... Do we know how many responses
RG> he got?
Arthur Lemmens started collecting some info a while ago. He lists
235 people [1]. I couldn't find you there under either name, so I think
quite a few of even the regulars here are missing. A search for lisp
in linkedin.com yields 230 users that are 3 people away from me (I
couln't figure out how to get the total number). This is for the entire
world and doesn't include criteria such as experience, availability etc.
Don't know what the numbers mean though, but that's what I could think
of. If there is a genuine need for this we could advertise Arthur's
database more and perhaps include more criteria. On the other hand
people are getting shy about their info and I don't know how much they'd
be willing to put in a public database.
cheers,
BM
[1] http://www.xs4all.nl/~alemmens/alu/database/
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44gnptF23tv3U1@individual.net>
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>Ron Garret wrote:
>>
>>>In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>>Ron Garret wrote:
>>>>
>>>>>Of course. But other languages currently have better answers.
>>>>
>>>>I don't think so. Recall Edi Weitz's story when he had to provide
>>>>evidence for one of his customers that there are enough Lispers willing
>>>>to take over his job in case he gets hit by a bus. ;)
>>>
>>>What are you referring to? The only reference I could find (searching
>>>Google groups for author Edi Weitz and "hit by a bus") was a call for
>>>Lisp programmers in Hamburg to contact him privately.
>>
>>Yep, that's the one.
>
> Well, that's hardly reassuring. Do we know how many responses he got?
http://groups.google.com/group/comp.lang.lisp/msg/bfa88e14a6ef1ec2
> (The mere fact that I have to ask this question is a show stopper under
> many circumstances!)
>
[...]
>>Do you mean Python, JPython, Jython, IronPython or Stackless Python? Do
>>you mean Python 2.2, 2.3 or 2.4? What if Guido van Rossum changes the
>>language again and again?
>
> There is a canonical implementation of Python, which is what is referred
> to when one says Python. There are many niche offshoots, and they are
> conveniently referred to by other names. For Lisp there is nothing but
> offshoots.
The canonical implementation of Common Lisp is the one that you choose
it to be.
> As for version changing, most people consider this a feature. It means
> that the language is evolving with the times, and indeed Python has a
> very nice mechanism for managing version migration through the use of
> the __future__ feature. Lisp has no such mechanism, which is one of the
> reasons why it is such a mess w.r.t. certain crucial features like
> threads. (Certain *implementations* of Lisp have such mechanisms, but
> Lisp itself does not.)
I had to port Java applications from various version numbers to other
version numbers. Let me just tell you that this is definitely not a
feature. I don't have enough experience in Python to be able to comment
on that.
>>>>>>(For example,
>>>>>>"What if Ruby ultimately wins over Python?" is also a valid question in
>>>>>>the same vein.)
>>>>>
>>>>>Of course it's a valid question. The answer is: if Ruby ultimately wins
>>>>>over Python it will be the result of a very slow process that unfolds
>>>>>over a long period of time. It is unlikely in the extreme that the
>>>>>level of available Python support will drop suddenly and without warning.
>>>>
>>>>Same for Common Lisp.
>>>
>>>But Common Lisp by itself (as contrasted with any particular
>>>implementation of Common Lisp with implementation-specific extensions)
>>>has very limited utility.
>>
>>It is unlikely in the extreme that the level of available support for
>>Allegro Common Lisp, CLisp, CMUCL, LispWorks, OpenMCL, SBCL, etc. pp.
>>will drop suddenly and without warning.
>
> Given that the level of support for many of these is already lamentably
> low [1] that is not saying much.
Is it? Where do you get that from?
> But how do you know that LispWorks
> won't go bankrupt next week, or that Franz won't go bankrupt next year?
> For that matter, how do you know that they aren't bankrupt already?
Same for each and every company. Not Lisp specific.
Allegro and LispWorks are in the market for many years / decades, and
are still doing fine. They must be doing something right, right? ;)
> Like I keep saying, there is certainly cause for optimism or we would
> not be having this conversation. But it can be an anti-self-fulfilling
> prophecy if one allows optimism to turn into complacency.
You shouldn't underestimate the adverse effect of doomsaying. It makes a
difference when Lisp critics can point to the fact that even members of
the Lisp community seem to argue against the use of Lisp. The impression
you give of the state of Lisp is far too negative IMHO.
Yes, there is room for improvement. But that's about it.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> > There is a canonical implementation of Python, which is what is referred
> > to when one says Python. There are many niche offshoots, and they are
> > conveniently referred to by other names. For Lisp there is nothing but
> > offshoots.
>
> The canonical implementation of Common Lisp is the one that you choose
> it to be.
I think you're missing the point. The advantage of a canonical
implementation [1] is that the vast majority of the user community will
be using it, with the attendant benefits in terms of having bugs found
and fixed by others, availability of libraries that work out of the box,
etc. etc. If I choose an implementation I do not obtain those benefits
unless everyone else follows my choice, which I very much doubt they
will. (Indeed they have not, as my choice is MCL.)
> > Given that the level of support for many of these is already lamentably
> > low [1] that is not saying much.
>
> Is it? Where do you get that from?
Again, I think you're missing the point. The level of support available
for Lisp is quite good from a hacker's point of view. It is not so good
from a business point of view. There are many (dozens, perhaps
hundreds) of companies providing contract services for Java, Visual
Basic, or PHP. I don't know what the comparable number is for SBCL, but
I'm pretty sure it's between zero and five, with zero being a strong
possibility.
> > But how do you know that LispWorks
> > won't go bankrupt next week, or that Franz won't go bankrupt next year?
> > For that matter, how do you know that they aren't bankrupt already?
>
> Same for each and every company. Not Lisp specific.
The crucial difference is that if the company that provides my PHP
support goes belly up there are a dozen others lining up to take their
place.
> Allegro and LispWorks are in the market for many years / decades, and
> are still doing fine. They must be doing something right, right? ;)
It is not at all clear from the outside the Lispworks is doing well. It
used to be Lucid, then it was acquired by Xanalys, then it was spun off
as Lispworks. This has all the earmarks of a marginal business that is
making just enough money to sustain itself but isn't actually growing.
(The fact that they have no job postings supports this view.)
And what Franz is doing right is snapping up their competitors' market
share as one by one they all go out of business.
> > Like I keep saying, there is certainly cause for optimism or we would
> > not be having this conversation. But it can be an anti-self-fulfilling
> > prophecy if one allows optimism to turn into complacency.
>
> You shouldn't underestimate the adverse effect of doomsaying. It makes a
> difference when Lisp critics can point to the fact that even members of
> the Lisp community seem to argue against the use of Lisp. The impression
> you give of the state of Lisp is far too negative IMHO.
You are still missing the point. If Lisp had a robust economic model it
wouldn't matter what the critics say. You could thumb your noses at the
critics all the way to the bank. Google and Microsoft have a lot more
critics than Lisp does. That doesn't seem to have slowed them down much.
rg
[1] or a comprehensive canonical standard
Ron Garret <·········@flownet.com> writes:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> > There is a canonical implementation of Python, which is what is referred
>> > to when one says Python. There are many niche offshoots, and they are
>> > conveniently referred to by other names. For Lisp there is nothing but
>> > offshoots.
>>
>> The canonical implementation of Common Lisp is the one that you choose
>> it to be.
>
> I think you're missing the point. The advantage of a canonical
> implementation [1] is that the vast majority of the user community will
> be using it, with the attendant benefits in terms of having bugs found
> and fixed by others, availability of libraries that work out of the box,
> etc. etc. If I choose an implementation I do not obtain those benefits
> unless everyone else follows my choice, which I very much doubt they
> will. (Indeed they have not, as my choice is MCL.)
You'd need to define "canonical".
As I understand it, I'd rather bet that nobody would use the
"canonical" implementation of the standard Common Lisp.
For example, the canonical implementaton of the standard Common Lisp
wouldn't need to implement TCO. It wouldn't need to have a garbage
collector either. Users would be unhappy with this.
Otherwise, let's just agree clisp-2.38 is the canonical implementation
of the standard Common Lisp, and by the way, redefine the mathematical
continuity. Perhaps this will allow us to travel instantenously to
the other side of the Galaxy...
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <······@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> > There is a canonical implementation of Python, which is what is referred
> >> > to when one says Python. There are many niche offshoots, and they are
> >> > conveniently referred to by other names. For Lisp there is nothing but
> >> > offshoots.
> >>
> >> The canonical implementation of Common Lisp is the one that you choose
> >> it to be.
> >
> > I think you're missing the point. The advantage of a canonical
> > implementation [1] is that the vast majority of the user community will
> > be using it, with the attendant benefits in terms of having bugs found
> > and fixed by others, availability of libraries that work out of the box,
> > etc. etc. If I choose an implementation I do not obtain those benefits
> > unless everyone else follows my choice, which I very much doubt they
> > will. (Indeed they have not, as my choice is MCL.)
>
> You'd need to define "canonical".
I mean an implementation (or standard) that is used/accepted by a
majority of users. There doesn't have to be a canonical implementation,
it would suffice to have a canonical standard (even if it's only a
de-facto one) that covers more than what ANSI covers, including e.g.
sockets, regexps, threading, etc.
> As I understand it, I'd rather bet that nobody would use the
> "canonical" implementation of the standard Common Lisp.
>
> For example, the canonical implementaton of the standard Common Lisp
> wouldn't need to implement TCO. It wouldn't need to have a garbage
> collector either. Users would be unhappy with this.
These are good examples. Not every CL implementation has TCO, and so
one cannot say that Common Lisp has TCO. Contrariwise, every CL
implementation has GC, so one can say that CL has GC despite the fact
that GC is not part of the ANSI standard.
Accordingly, CL does not have sockets, regular expressions, XML parsing,
multithreading, etc. etc. etc. Some implementations have these things,
but CL as a whole does not. This is a significant obstacle to building
a business case for the use of Lisp.
> Otherwise, let's just agree clisp-2.38 is the canonical implementation
> of the standard Common Lisp, and by the way, redefine the mathematical
> continuity. Perhaps this will allow us to travel instantenously to
> the other side of the Galaxy...
If it were that simple we wouldn't be having the conversation.
rg
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u8xssuelp.fsf@agharta.de>
On Fri, 03 Feb 2006 15:05:01 -0800, Ron Garret <·········@flownet.com> wrote:
> Accordingly, CL does not have sockets, regular expressions, XML
> parsing, multithreading, etc. etc. etc. Some implementations have
> these things, but CL as a whole does not. This is a significant
> obstacle to building a business case for the use of Lisp.
Right. And for exactly the same reason nobody ever built a business
case for the use of C++. It's sooooo simple...
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Fri, 03 Feb 2006 15:05:01 -0800, Ron Garret <·········@flownet.com> wrote:
>
> > Accordingly, CL does not have sockets, regular expressions, XML
> > parsing, multithreading, etc. etc. etc. Some implementations have
> > these things, but CL as a whole does not. This is a significant
> > obstacle to building a business case for the use of Lisp.
>
> Right. And for exactly the same reason nobody ever built a business
> case for the use of C++. It's sooooo simple...
It is indeed very simple. First, although C++ is fragmented, it is not
nearly as fragmented as Lisp. In most environments there are usually at
most two C++ compilers, and one of them is almost invariably gcc.
Second, the C++ economy is large enough to support multiple standards.
The Lisp economy isn't. Third, C++ has indeed lost market share to
other languages because it lacks support in certain areas, most notably,
web server applications.
rg
Edi Weitz wrote:
> On Fri, 03 Feb 2006 15:05:01 -0800, Ron Garret <·········@flownet.com> wrote:
>
>
>>Accordingly, CL does not have sockets, regular expressions, XML
>>parsing, multithreading, etc. etc. etc. Some implementations have
>>these things, but CL as a whole does not. This is a significant
>>obstacle to building a business case for the use of Lisp.
>
>
> Right. And for exactly the same reason nobody ever built a business
> case for the use of C++. It's sooooo simple...
>
I am now betting the ranch on Common Lisp for the third time. I think
three things establish the business (ranch?) case, two necessary things,
and one very nice thing to have.
The necessary things were the maturity and native compilation. I would
ease up on the latter ten years later and settle for a good byte-code
compiled implementation. But the maturity still makes CL a big win over
moving targets like Python and Perl. You just cannot build a software
business atop an uncertain language. Not to say Python and Perl at this
stage have not reached maturity, but I still am bothered by the amount
of ongoing evolution ("lambdas? we don't need no stinkin lambdas").
The very nice thing is the dynamism and GC (later I came to appreciate
more about CL).
The crap Ron is trying to elevate to a crisis can be solved with a
small, known, finite effort, and nothing to worry about, business case
or otherwise. The killers are big efforts and uncertain tasks that can
drag you down from behind.
kenny
In article <················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> The crap Ron is trying to elevate to a crisis
I am not trying to elevate anything to a crisis. And I would appreciate
it if you would stop misrepresenting my position.
rg
Ron Garret <·········@flownet.com> writes:
> In article <················@news-wrt-01.rdc-nyc.rr.com>,
> Kenny Tilton <·············@nyc.rr.com> wrote:
>
> > The crap Ron is trying to elevate to a crisis
>
> I am not trying to elevate anything to a crisis.
I'll certainly grant you this. You haven't said anything even
remotely interesting, let alone "crisis" inducing.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <················@news-wrt-01.rdc-nyc.rr.com>,
> > Kenny Tilton <·············@nyc.rr.com> wrote:
> >
> > > The crap Ron is trying to elevate to a crisis
> >
> > I am not trying to elevate anything to a crisis.
>
> I'll certainly grant you this. You haven't said anything even
> remotely interesting,
Then why are you bothering to respond? Don't you have anything better
to do?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> jayessay <······@foo.com> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <················@news-wrt-01.rdc-nyc.rr.com>,
> > > Kenny Tilton <·············@nyc.rr.com> wrote:
> > >
> > > > The crap Ron is trying to elevate to a crisis
> > >
> > > I am not trying to elevate anything to a crisis.
> >
> > I'll certainly grant you this. You haven't said anything even
> > remotely interesting,
>
> Then why are you bothering to respond? Don't you have anything better
> to do?
Not at the time I responded.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>In article <················@news-wrt-01.rdc-nyc.rr.com>,
>> Kenny Tilton <·············@nyc.rr.com> wrote:
>>
>>
>>>The crap Ron is trying to elevate to a crisis
>>
>>I am not trying to elevate anything to a crisis.
>
>
> I'll certainly grant you this. You haven't said anything even
> remotely interesting, let alone "crisis" inducing.
First person to cite a dictionary on "crisis" loses.
:)
kenny
From: Robert Uhl
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m3psm0jdt5.fsf@NOSPAMgmail.com>
jayessay <······@foo.com> writes:
> Ron Garret <·········@flownet.com> writes:
>>
>> I am not trying to elevate anything to a crisis.
>
> I'll certainly grant you this. You haven't said anything even
> remotely interesting, let alone "crisis" inducing.
a) that's rude
b) it's untrue
--
Robert Uhl <http://public.xdi.org/=ruhl>
A pipe gives a wise man time to think and a fool something to stick in
his mouth. --Anonymous
Robert Uhl <·········@NOSPAMgmail.com> writes:
> jayessay <······@foo.com> writes:
>
> > Ron Garret <·········@flownet.com> writes:
> >>
> >> I am not trying to elevate anything to a crisis.
> >
> > I'll certainly grant you this. You haven't said anything even
> > remotely interesting, let alone "crisis" inducing.
>
> b) it's untrue
That obviously depends on your perspective. Hence, your claim may
well be untrue depending on context.
> a) that's rude
I believe this only would hold in those contexts where your b) claim
holds. Your b) claim does not hold for me.
Shrug.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ron Garret wrote:
> In article <················@news-wrt-01.rdc-nyc.rr.com>,
> Kenny Tilton <·············@nyc.rr.com> wrote:
>
>
>>The crap Ron is trying to elevate to a crisis
>
>
> I am not trying to elevate anything to a crisis.
Oh. I would think things pretty dire for Lisp if in 2006 there is no
Common Lisp implementation in which a Lisp-enthusiast empowered to
choose any language can trust because it has too many problems:
Ron Garret wrote:
"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."
When you consider that the above-quoted enthusiast perceives great value
in the language, has championed it in the past, has been to annual
conferences, etc etc and now is betting the ranch against, well then the
perceived greater problems must be extraordinary .
ie, In crisis.
"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."
So Lisp's problem is social, not technical? Good.
Well, call me weird, but I just think about minimizing the total cost of
development. Which brings me to:
Since you didn't ask, what happened to my C-to-Lisp translator is that
(a) I had a ball doing it, which tells you something about (i) open
source and (ii) Lisp, (b) it worked (after a fashion <g>), and (c) When
I saw imperative C in Lisp I /really/ saw it. I also had a nagging
suspicion that it would take the same amount of time to replicate the
functionality from scratch (new algorithms as well (the objective,
actually)) as it would be to finish resurrecting the C engine in Lisp's
clothing. But it would be a close call and opened up risk because once I
start writing new code anything can happen timewise. So why undertake
the risk?
I have to get to Lisp anyway. Graham was right. Lisp is a secret weapon.
And I enjoy writing it. But after just a few days of polishing the
transation (that was going well) I could not help stopping from time to
remind myself of the code. Not bad, but definitely too awkward to keep
around. I have not mentioned that I see ten-twenty percent new work
being done, so any (and it might go the other way) time lost going from
scratch gets made up during the new work. And then the product should
come out in multiple similar versions. Staying literal with the C means
cobbling myself forever to those data structures -- unless we do a
rewrite, but if we are going to do a rewrite, why not do it now? One
does not always get time to redo things once the crowds arrive.
OK, the other thing is that I have ten more years experience, including
a couple of doozies on CliniSys.
What conversion factor can we expect for (a) me with six years
experience in 1985 newly learning C /and/ my first GUI programming
Quickdraw/System 6) versus (b) 27 years experience in 2006 with ten
years of Common Lisp and having written /three/ GUIs myself?
Ten? Twenty? 10 for solid CL over weak C (well, it was OK, I used a lot
of macros), and 2 for Me2006 over Me1985?
I think I spent two years writing it. So...five weeks? Oh, shit. I
forgot I have Cells now. Happy thought.
We sure have made different bets for our companies. Could you be the
first person fired for not using Lisp?
peace and fair skies to you. I just bought X-Plane and have been having
a ball. What was that small pocket rocket of which you once posted a
picture link? There may be a virtual model I can try out.
kenny
In article <··················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> Ron Garret wrote:
> > In article <················@news-wrt-01.rdc-nyc.rr.com>,
> > Kenny Tilton <·············@nyc.rr.com> wrote:
> >
> >
> >>The crap Ron is trying to elevate to a crisis
> >
> >
> > I am not trying to elevate anything to a crisis.
>
> Oh. I would think things pretty dire for Lisp if in 2006 there is no
> Common Lisp implementation in which a Lisp-enthusiast empowered to
> choose any language can trust because it has too many problems:
You are missing the point. (Holy cow, I am getting so tired of saying
that.) Of course there are CL implementations I can trust. What there
is not is a CL implementation I can build a business case for using.
This is not to say that someone else couldn't do it. I have subtly
hinted at this, but perhaps I should be more explicit: I have money to
invest, and I believe that Lisp's core technical superiority could and
should be a source of lucrative opportunities. But I have tried to
construct a business case for Lisp and I have failed for reasons I have
tried to describe in this thread, and I do not see evidence that others
are meeting with more success than I have had in this regard.
There are only two possible constructive responses to this. One is:
you're wrong, here's a business plan (or "you're wrong, we just signed a
deal with Sequoia for $25M is round A funding"). The other is: you're
right. What should we do to improve the situation?
Whining about "crisis" and "doomsaying" is neither correct nor
constructive. So please stop it.
> Ron Garret wrote:
> "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."
>
> When you consider that the above-quoted enthusiast perceives great value
> in the language, has championed it in the past, has been to annual
> conferences, etc etc and now is betting the ranch against, well then the
> perceived greater problems must be extraordinary .
>
> ie, In crisis.
No. There is a big difference between "betting the ranch against" and
"on balance not a win as things currently stand." The problems that
currently exist can be rectified. But they do require that some people
get down off their high horses.
> "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."
>
> So Lisp's problem is social, not technical?
Yes.
> Good.
Well, yes and no. Social problems are often more difficult to solve
than technical ones. (This one is turning out to be quite the
challenge.)
> Well, call me weird, but I just think about minimizing the total cost of
> development.
I wouldn't call you weird, I would call you a programmer. Minimizing
total cost of development is only one of many considerations when it
comes to building a business.
> Which brings me to:
>
> Since you didn't ask, what happened to my C-to-Lisp translator is
I didn't ask because it's irrelevant to the point I am trying to make.
It's not that I'm not interested, it's just not the matter at hand.
> We sure have made different bets for our companies. Could you be the
> first person fired for not using Lisp?
Nope. My boss is pretty reasonable nowadays.
> peace and fair skies to you.
Thank you. The same to you.
rg
Ron Garret wrote:
> You are missing the point. (Holy cow, I am getting so tired of saying
> that.) Of course there are CL implementations I can trust. What there
> is not is a CL implementation I can build a business case for using.
What's the problem, then? If you can trust an implementation (I assume
that by "trust" you mean that you're confident in its stability and
future support), why not write to it, and to hell with the ANSI
standard? This is basically what Python and Perl people do, except
that they don't have a standard to ignore in the first place. Perl
even gets away with being incompatible with itself.
If the success of those two languages has shown us anything, it's that
ANSI standards are overrated.
In article <························@g47g2000cwa.googlegroups.com>,
··········@gmail.com wrote:
> Ron Garret wrote:
> > You are missing the point. (Holy cow, I am getting so tired of saying
> > that.) Of course there are CL implementations I can trust. What there
> > is not is a CL implementation I can build a business case for using.
>
> What's the problem, then? If you can trust an implementation (I assume
> that by "trust" you mean that you're confident in its stability and
> future support), why not write to it, and to hell with the ANSI
> standard?
Because of the high risk of using any software product with a very small
user community and limited or nonexistent commercial support.
> This is basically what Python and Perl people do, except
> that they don't have a standard to ignore in the first place. Perl
> even gets away with being incompatible with itself.
Python can get away with this because it has a de facto standard. Perl
can get away with it because its user community is large enough that
they can just brute-force their way around problems.
Look, this is important to understand: as a hacker, Perl is a nightmare.
I wouldn't touch it with a ten-foot pole. But as a businessman Perl is
great because I can deal with all the technical problems that Perl
presents merely by hiring a Perl programmer, which is a relatively easy
thing to do. It's much easier than hiring a Lisp programmer, or even a
Python programmer (as I discovered to my dismay during my last startup),
and it's certainly easier than hacking Perl.
> If the success of those two languages has shown us anything, it's that
> ANSI standards are overrated.
That's exactly right. The ANSI standard, from a business perspective,
is not useful in and of itself. Its utility derives entirely from one
of its effects: driving disparate user communities together to create a
single larger user community, which in turn reduces the risk of using
the software produced and used by that community.
rg
Ron Garret wrote:
....
> Look, this is important to understand: as a hacker, Perl is a nightmare.
> I wouldn't touch it with a ten-foot pole. But as a businessman Perl is
> great because I can deal with all the technical problems that Perl
> presents merely by hiring a Perl programmer, which is a relatively easy
> thing to do. It's much easier than hiring a Lisp programmer, or even a
> Python programmer (as I discovered to my dismay during my last startup),
> and it's certainly easier than hacking Perl.
Is this the crux of the matter, that it is hard to hire Lisp
programmers? I personally think that given any problem domain it is
hard to hire good programmers that fit exactly. For example, for my
day job I work with Windows CE doing OS and driver development for
handheld devices. This is probably a relatively small niche market,
but then most software probably addresses a specific niche market when
you get down to it.
>From the hiring that I have seen and participated in, it is hard or
impossible to find people who have the exact experiance we are looking
for. So the best that we can do is hire the smartest and most
adaptable person we can find and accept that there will be a period of
time where the new hire is not 100% productive.
If you're starting a new company, this problem doesn't crop up because
you need a resident expert in the given technology before you even
start.
Don't get me wrong, I agree with much of what you have said. I think
that time and/or money can fix the technical issues (eg portable
sockets). But the only way to get more programmers is to be like Paul
Graham and evangelise. Of course, you need to have used Lisp to make
yourself into a sucess before you can really evangelise properly - so
maybe the best thing to do would be to find all the Lisp made
millionaires & get them to say how nice it is.
Cheers
Brad
In article <························@g14g2000cwa.googlegroups.com>,
"bradb" <··············@gmail.com> wrote:
> Ron Garret wrote:
> ....
> > Look, this is important to understand: as a hacker, Perl is a nightmare.
> > I wouldn't touch it with a ten-foot pole. But as a businessman Perl is
> > great because I can deal with all the technical problems that Perl
> > presents merely by hiring a Perl programmer, which is a relatively easy
> > thing to do. It's much easier than hiring a Lisp programmer, or even a
> > Python programmer (as I discovered to my dismay during my last startup),
> > and it's certainly easier than hacking Perl.
>
> Is this the crux of the matter, that it is hard to hire Lisp
> programmers?
No. That's just a detail, albeit an important one. The crux of the
matter is that business considerations are very different from technical
considerations.
> Don't get me wrong, I agree with much of what you have said. I think
> that time and/or money can fix the technical issues (eg portable
> sockets). But the only way to get more programmers is to be like Paul
> Graham and evangelise.
No, that is not the only way. Another way, the way I am suggesting, is
to start to take business considerations seriously, make money, and
start *paying* people. People don't learn Perl because they love it,
they learn Perl because they think (correctly) that they can make a
living by knowing it. If people think they can make a living by knowing
Lisp they'll learn Lisp even without evangelism.
Imagine: it is 2008. From seed capital invested in 2006 there are now
ten newly minted startups all stomping on their competition because they
are using Lisp (and all pooling their risk and sharing resources because
they are all using the same implementation, or at least mutually
compatible implementations). They are not necessarily software
companies. In fact, most likely they won't be. (ViaWeb wasn't.) They
all have solid revenues and growth. Some of them might even be
profitable already. VCs are lining up to participate in round A
financing. Every one of them needs to hire two or three more
programmers in the next month or two to keep up with the growth. So now
there are twenty or thirty vacant jobs for Lisp programmers paying above
market salaries because of the demand. What do you think would be more
effective at getting people's attention, the scenario I've just
outlined, or having me, Edi and Kenny shout "Lisp is great! Lisp is
great!" for the next two years?
> Of course, you need to have used Lisp to make
> yourself into a sucess before you can really evangelise properly - so
> maybe the best thing to do would be to find all the Lisp made
> millionaires & get them to say how nice it is.
Or just start making more of them and let the numbers speak for
themselves.
rg
Ron Garret wrote:
> Imagine: it is 2008. From seed capital invested in 2006 there are now
> ten newly minted startups all stomping on their competition because they
> <snip description of glorious future>
I note that In your dream scenario, the people who would make big, easy
money would be the ones who took a risk in 2006, not the followers who
"bought high" in 2008, just as the people who made big money on Google
stock were the ones who bought it 2 years ago, not the ones who bought
it last week. You don't make big money investing in something that's
obviously good. I'm sure you're aware of this.
In 2008, the competition would be using Lisp too, so Lisp would be a
requirement to even have a chance of success rather than a competitive
advantage.
In article <·······················@o13g2000cwo.googlegroups.com>,
··········@gmail.com wrote:
> Ron Garret wrote:
> > Imagine: it is 2008. From seed capital invested in 2006 there are now
> > ten newly minted startups all stomping on their competition because they
> > <snip description of glorious future>
>
> I note that In your dream scenario, the people who would make big, easy
> money would be the ones who took a risk in 2006, not the followers who
> "bought high" in 2008, just as the people who made big money on Google
> stock were the ones who bought it 2 years ago, not the ones who bought
> it last week.
Actually, the people who made the big money on Google are the ones who
bought it seven years ago at a dollar a share, not the chumps who bought
at the IPO. All they got was a measly 400% return.
> You don't make big money investing in something that's
> obviously good. I'm sure you're aware of this.
Yes. In my scenario, the ten two-year-old startups in 2008 come from
100 seed ventures started in 2006. (I'm counting on Y-Combinator to
provide a few of them. I don't have *that* much money.) Those ten each
get O($10M) in round-A funding. Two years later, two of those ten will
have failed. Six of them will be struggling. And two of them will have
IPOs. And two hundred new seed ventures will be in the pipeline.
> In 2008, the competition would be using Lisp too, so Lisp would be a
> requirement to even have a chance of success rather than a competitive
> advantage.
Wouldn't that be great?
rg
From: Peter Seibel
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m2ek2irkj1.fsf@gigamonkeys.com>
Ron Garret <·········@flownet.com> writes:
> No, that is not the only way. Another way, the way I am suggesting, is
> to start to take business considerations seriously, make money, and
> start *paying* people. People don't learn Perl because they love it,
> they learn Perl because they think (correctly) that they can make a
> living by knowing it. If people think they can make a living by knowing
> Lisp they'll learn Lisp even without evangelism.
*You're* the one with money to invest--why don't *you* pay people.
Seriously, I really don't get what you're looking for the readers of
comp.lang.lisp to do. Agree that it'd be cool for there to be lots of
well-paying Lisp jobs? Done. Agree that if we're ever in a position to
hire Lisp programmers, we'll actually pay them? I'll be happy to.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > No, that is not the only way. Another way, the way I am suggesting, is
> > to start to take business considerations seriously, make money, and
> > start *paying* people. People don't learn Perl because they love it,
> > they learn Perl because they think (correctly) that they can make a
> > living by knowing it. If people think they can make a living by knowing
> > Lisp they'll learn Lisp even without evangelism.
>
> *You're* the one with money to invest--why don't *you* pay people.
I answered this in another post, but briefly, because starting a company
is a lot of work, I've tried and failed twice, and I'm not ready to try
again just now.
> Seriously, I really don't get what you're looking for the readers of
> comp.lang.lisp to do. Agree that it'd be cool for there to be lots of
> well-paying Lisp jobs? Done. Agree that if we're ever in a position to
> hire Lisp programmers, we'll actually pay them? I'll be happy to.
I'm hoping for four outcomes. First, I'm hoping that some Lispers will
take what I say to heart and start to think seriously about business
issues instead of focusing entirely on technical ones. Second, I'm
hoping that the community will realize that it is their best interests
to agree on some standard library interfaces and a versioning process,
and that such a process will somehow emerge. (Whatever happened to Kent
Pitman's substandards?) Third, I'm hoping people will start sending me
business plans -- not immediately but over time. (I've already gotten
one. It wasn't very good.) Fourth, I'm hoping that there are some
Lispers with money in the Bay Area who will get excited about this and
want to start a West-Coast branch of Y-Combinator or something like that.
But mostly I'm just looking to make trouble and annoy Kenny. ;-)
rg
Ron Garret wrote:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>
>>Ron Garret <·········@flownet.com> writes:
>>
>>
>>>No, that is not the only way. Another way, the way I am suggesting, is
>>>to start to take business considerations seriously, make money, and
>>>start *paying* people. People don't learn Perl because they love it,
>>>they learn Perl because they think (correctly) that they can make a
>>>living by knowing it. If people think they can make a living by knowing
>>>Lisp they'll learn Lisp even without evangelism.
>>
>>*You're* the one with money to invest--why don't *you* pay people.
>
>
> I answered this in another post, but briefly, because starting a company
> is a lot of work, I've tried and failed twice, and I'm not ready to try
> again just now.
>
>
>>Seriously, I really don't get what you're looking for the readers of
>>comp.lang.lisp to do. Agree that it'd be cool for there to be lots of
>>well-paying Lisp jobs? Done. Agree that if we're ever in a position to
>>hire Lisp programmers, we'll actually pay them? I'll be happy to.
>
>
> I'm hoping for four outcomes. First, I'm hoping that some Lispers will
> take what I say to heart and start to think seriously about business
> issues instead of focusing entirely on technical ones. Second, I'm
> hoping that the community will realize that it is their best interests
> to agree on some standard library interfaces and a versioning process,
> and that such a process will somehow emerge. (Whatever happened to Kent
> Pitman's substandards?)
Some people talk, other people do. In my case, I encourage others to do,
and from what I can see the Google (heard of them?) Summer of Code
project I mentored has produced a standard FFI, CFFI, full cred to James
Bielman and Luis Oliveira for Actually Doing Something.
Now I am working on doing a second Cells+LTk marriage (the first forked
LTk) so Lisp can have not just a standard GUI, but a Cells-driven one
(the only kind you want).
Why don't you sign off c.l.l and get to work on a standard sockets
package? That was a third Google project that did not fare so well
(pilot error).
ken
In article <·················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> Why don't you sign off c.l.l and get to work on a standard sockets
> package?
Well, you'll get half your wish. I am going to sign off c.l.l. shortly
because I will be leaving town for a while.
As to why I don't work on a standard sockets package, well, number one
I'm busy doing other things, and number two, I'm not a particularly good
programmer, and this sort of work probably ought to be done by someone
who actually know what they're doing.
rg
From: Wade Humeniuk
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <cvbFf.258058$OU5.72224@clgrps13>
Ron Garret wrote:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>>> No, that is not the only way. Another way, the way I am suggesting, is
>>> to start to take business considerations seriously, make money, and
>>> start *paying* people. People don't learn Perl because they love it,
>>> they learn Perl because they think (correctly) that they can make a
>>> living by knowing it. If people think they can make a living by knowing
>>> Lisp they'll learn Lisp even without evangelism.
>> *You're* the one with money to invest--why don't *you* pay people.
>
> I answered this in another post, but briefly, because starting a company
> is a lot of work, I've tried and failed twice, and I'm not ready to try
> again just now.
>
So you are saying that because you failed twice that you know what is
needed to succeed in business? I assume you think you seriously focused on
business issues (as you suggest). How did that help?
It is interesting that you do not think that people here (who
participate in a technical group) do not consider business issues
(if they are in business).
Wade
In article <······················@clgrps13>,
Wade Humeniuk <··················@telus.net> wrote:
> Ron Garret wrote:
> > In article <··············@gigamonkeys.com>,
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >>> No, that is not the only way. Another way, the way I am suggesting, is
> >>> to start to take business considerations seriously, make money, and
> >>> start *paying* people. People don't learn Perl because they love it,
> >>> they learn Perl because they think (correctly) that they can make a
> >>> living by knowing it. If people think they can make a living by knowing
> >>> Lisp they'll learn Lisp even without evangelism.
> >> *You're* the one with money to invest--why don't *you* pay people.
> >
> > I answered this in another post, but briefly, because starting a company
> > is a lot of work, I've tried and failed twice, and I'm not ready to try
> > again just now.
> >
>
> So you are saying that because you failed twice that you know what is
> needed to succeed in business?
Of course not. Don't be ridiculous.
> I assume you think you seriously focused on
> business issues (as you suggest). How did that help?
My second business actually generated revenues. My first never made a
dime. So I'm making progress. At my current rate I'll turn my first
profit in ten years or so. :-)
> It is interesting that you do not think that people here (who
> participate in a technical group) do not consider business issues
> (if they are in business).
Please stop mischaracterizing what I said. I never said that people
here do not consider business issues. The probably do (particularly the
ones who are running businesses). What I said is that that the
community does not appear to take business issues seriously, as
evidenced in part by the hounding I'm getting by merely bringing up the
topic.
rg
Ron Garret <·········@flownet.com> writes:
>> It is interesting that you do not think that people here (who
>> participate in a technical group) do not consider business issues
>> (if they are in business).
>
> Please stop mischaracterizing what I said. I never said that people
> here do not consider business issues. The probably do (particularly the
> ones who are running businesses). What I said is that that the
> community does not appear to take business issues seriously, as
> evidenced in part by the hounding I'm getting by merely bringing up the
> topic.
From the top of my head, there are four commercial vendors (Franz,
LispWorks, Corman, DigiTools) who are addressing business issues.
What more do you want? Or are you saying commercial vendors are not
serriously adddressing their customers' issues?
I don't see what we can do about it: we're not employeed and neither
shareholder of these corporations. BOCTAOE. The best you can do is to
become customer of one of them and ask them to address serriously your
issues.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <······@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
> >> It is interesting that you do not think that people here (who
> >> participate in a technical group) do not consider business issues
> >> (if they are in business).
> >
> > Please stop mischaracterizing what I said. I never said that people
> > here do not consider business issues. The probably do (particularly the
> > ones who are running businesses). What I said is that that the
> > community does not appear to take business issues seriously, as
> > evidenced in part by the hounding I'm getting by merely bringing up the
> > topic.
>
> From the top of my head, there are four commercial vendors (Franz,
> LispWorks, Corman, DigiTools) who are addressing business issues.
> What more do you want? Or are you saying commercial vendors are not
> serriously adddressing their customers' issues?
I already addressed this in an earlier post. The issue I am raising
concerns the case where people outside of the Lisp community are the
customers.
rg
Ron Garret wrote:
> In article <······················@clgrps13>,
> Wade Humeniuk <··················@telus.net> wrote:
>
>
>>Ron Garret wrote:
>>
>>>In article <··············@gigamonkeys.com>,
>>> Peter Seibel <·····@gigamonkeys.com> wrote:
>>>
>>>
>>>>Ron Garret <·········@flownet.com> writes:
>>>>
>>>>
>>>>>No, that is not the only way. Another way, the way I am suggesting, is
>>>>>to start to take business considerations seriously, make money, and
>>>>>start *paying* people. People don't learn Perl because they love it,
>>>>>they learn Perl because they think (correctly) that they can make a
>>>>>living by knowing it. If people think they can make a living by knowing
>>>>>Lisp they'll learn Lisp even without evangelism.
>>>>
>>>>*You're* the one with money to invest--why don't *you* pay people.
>>>
>>>I answered this in another post, but briefly, because starting a company
>>>is a lot of work, I've tried and failed twice, and I'm not ready to try
>>>again just now.
>>>
>>
>>So you are saying that because you failed twice that you know what is
>>needed to succeed in business?
>
>
> Of course not. Don't be ridiculous.
Don't be so fast. Most successful entrepreneurs do not succeed with
their first few tries. That's what keeps me going anyway. :)
ken
In article <··················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> Ron Garret wrote:
> > In article <······················@clgrps13>,
> > Wade Humeniuk <··················@telus.net> wrote:
> >
> >
> >>Ron Garret wrote:
> >>
> >>>In article <··············@gigamonkeys.com>,
> >>> Peter Seibel <·····@gigamonkeys.com> wrote:
> >>>
> >>>
> >>>>Ron Garret <·········@flownet.com> writes:
> >>>>
> >>>>
> >>>>>No, that is not the only way. Another way, the way I am suggesting, is
> >>>>>to start to take business considerations seriously, make money, and
> >>>>>start *paying* people. People don't learn Perl because they love it,
> >>>>>they learn Perl because they think (correctly) that they can make a
> >>>>>living by knowing it. If people think they can make a living by knowing
> >>>>>Lisp they'll learn Lisp even without evangelism.
> >>>>
> >>>>*You're* the one with money to invest--why don't *you* pay people.
> >>>
> >>>I answered this in another post, but briefly, because starting a company
> >>>is a lot of work, I've tried and failed twice, and I'm not ready to try
> >>>again just now.
> >>>
> >>
> >>So you are saying that because you failed twice that you know what is
> >>needed to succeed in business?
> >
> >
> > Of course not. Don't be ridiculous.
>
>
> Don't be so fast. Most successful entrepreneurs do not succeed with
> their first few tries. That's what keeps me going anyway. :)
Oh, I would never allow cluelessness to stand in my way (my own or other
people's). I'll be back, just not right now.
rg
On 2006-02-04 16:51:17 -0500, Ron Garret <·········@flownet.com> said:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
> *You're* the one with money to invest--why don't *you* pay people.
>
> I answered this in another post, but briefly, because starting a
> company is a lot of work, I've tried and failed twice, and I'm not
> ready to try again just now.
Ron,
might I suggest that at least some of your (and Paul Graham's) surplus
dollars might be well spent paying one of the maintainers of one of the
cross-platform free lisp implementations to turn it into the thing I
suggested in an earlier post - a de-facto standard implementation of
common lisp:
On 2006-02-02 18:38:58 -0500, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> said:
> At the risk of having history prove me laughably wrong I would go so
> far as to say that the fragmentation of lisp will end when a single,
> affordable[1] implementation provides all of the following across
> Windows, Linux intel, and Mac OS X intel[2]:
>
> a. SMP friendly multiprocessing
> b. asdf-installablily of most major libraries
> c. c library interface which includes access to platform native GUI
> facilities [3]
>
> This implementation will then just become the de-facto standard and
> other implementations will either become compatible with it, or remain
> niche players.
>
> [1] I cynically contend that what makes open source software popular is
> its beer-nature not it's speech-nature ;^)
> [2] by the time this comes about, Mac OS X ppc will be largely irrelevant.
> [3] a cross-platform GUI layer is neither necessary nor even desirable
> since this almost always means LCD which is unacceptable for many
> purposes
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-02-04 16:51:17 -0500, Ron Garret <·········@flownet.com> said:
>
> > In article <··············@gigamonkeys.com>,
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> > *You're* the one with money to invest--why don't *you* pay people.
> >
> > I answered this in another post, but briefly, because starting a
> > company is a lot of work, I've tried and failed twice, and I'm not
> > ready to try again just now.
>
> Ron,
> might I suggest that at least some of your (and Paul Graham's) surplus
> dollars might be well spent paying one of the maintainers of one of the
> cross-platform free lisp implementations to turn it into the thing I
> suggested in an earlier post - a de-facto standard implementation of
> common lisp:
I would seriously consider that. Which implementation would you
recommend?
rg
On 2006-02-05 02:34:27 -0500, Ron Garret <·········@flownet.com> said:
> I would seriously consider that. Which implementation would you recommend?
Well Edi Weitz in a reply to my original post opined that sbcl is the
most likely candidate, and I'm inclined to agree. In this connection it
might be worth noting that Nikodemus Siivola who works on sbcl has
started a project intended to be a common lisp environment based on
sbcl and slime:
sb-studio:
<http://sb-studio.net/index.html>
the announcement:
<http://random-state.net/log/3343480139.html>
his website:
<http://random-state.net/index.html>
As he writes that "Consulting and custom development will also be
available, prices subject to negotiation" I assume you could contract
with him to do the necessary work to make smtp-friendly multithreading,
asdf-installability of major libraries, and native GUI access available
across the 3 platforms I noted, Windows, Linux intel and Mac OS X intel.
Whether you choose sbcl or not, I hope you see fit to help some
affordable common lisp implementation become the de facto standard. I
really think it is the only way that the fragmentation of lisp will end.
As regards Kenny's comment on commercial implementations, I would say
that LispWorks is closest to the goal I put forward, but even though I
am a paying customer, I have doubts about its general affordability,
and that would hurt its widespread uptake and hence its chances of
becoming a de facto common lisp standard.
regards,
Ralph
Raffael Cavallaro wrote:
> On 2006-02-05 02:34:27 -0500, Ron Garret <·········@flownet.com> said:
>
>> I would seriously consider that. Which implementation would you
>> recommend?
>
>
> Well Edi Weitz in a reply to my original post opined that sbcl is the
> most likely candidate, and I'm inclined to agree. In this connection it
> might be worth noting that Nikodemus Siivola who works on sbcl has
> started a project intended to be a common lisp environment based on sbcl
> and slime:
>
> sb-studio:
> <http://sb-studio.net/index.html>
>
> the announcement:
> <http://random-state.net/log/3343480139.html>
>
> his website:
> <http://random-state.net/index.html>
>
> As he writes that "Consulting and custom development will also be
> available, prices subject to negotiation" I assume you could contract
> with him to do the necessary work to make smtp-friendly multithreading,
> asdf-installability of major libraries, and native GUI access available
> across the 3 platforms I noted, Windows, Linux intel and Mac OS X intel.
>
> Whether you choose sbcl or not, I hope you see fit to help some
> affordable common lisp implementation become the de facto standard. I
> really think it is the only way that the fragmentation of lisp will end.
>
> As regards Kenny's comment on commercial implementations, I would say
> that LispWorks is closest to the goal I put forward, but even though I
> am a paying customer, I have doubts about its general affordability, and
> that would hurt its widespread uptake and hence its chances of becoming
> a de facto common lisp standard.
If SBCL (or any one implementation) becomes the de facto standard, well,
what does that mean? Does that mean that MCL or AllegroCL become de
facto non-standard? They have to change or they are non-standard? Then
you still have fragmentation until the vendors decide (if even they do)
to conform to SBCL.
What you really want is to be able to write portable socket code. So the
mistake is burying standard sockets inside an all-or-nothing standard
implementation. You won't get portable code until the commercial
competition goes outof business (again, unless they conform, and when
will that happen and who will pay for that?
Now look at CFFI. That seems very close to being a substandard. Not that
everyone has ported their bindings to it, but what matters is that I can
now write portable FFI bindings.
We tried at Lisp-NYC to do the same with sockets, but that task, I am
assured by those who know, is more than a summer project. So maybe that
is something that should be developed. Then you get portability as well
a standard.
ken
ps. I was thinking the ALU should look at a role in development of
substandards. I happen to know they are looking for some way to stir up
trouble. :)
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44m0b4F2qrrbU1@individual.net>
Kenny Tilton wrote:
> If SBCL (or any one implementation) becomes the de facto standard, well,
> what does that mean? Does that mean that MCL or AllegroCL become de
> facto non-standard? They have to change or they are non-standard? Then
> you still have fragmentation until the vendors decide (if even they do)
> to conform to SBCL.
Since we don't have a dictator, I think making SBCL standard only means
extending it with all kinds of libraries that Just Work (tm) with it, so
everybody who wants to get stuff done can pick up SBCL, look at the docu
and get started.
This isn't saying that other implementations are worse (I don't use SBCL
myself, right now), but one location for downloading stuff, and one
method of installing software (doesn't SBCL include ASDF?) might help
newbies.
Think of it as the PLT Scheme of Lisp. There will be other
implementations, though they are encouraged - by competition - to lower
their barriers of entry to that level.
> What you really want is to be able to write portable socket code. So the
> mistake is burying standard sockets inside an all-or-nothing standard
> implementation. You won't get portable code until the commercial
> competition goes outof business (again, unless they conform, and when
> will that happen and who will pay for that?
Yes, but if one implementation attracts substantial market share, and it
has a good socket implementation built-in, then maybe others will
follow. Or maybe that implementation might simply implement some
portable interface as its own (like elements of ACL-compat).
> Now look at CFFI. That seems very close to being a substandard. Not that
> everyone has ported their bindings to it, but what matters is that I can
> now write portable FFI bindings.
>
> We tried at Lisp-NYC to do the same with sockets, but that task, I am
> assured by those who know, is more than a summer project. So maybe that
> is something that should be developed. Then you get portability as well
> a standard.
Both portable libraries, and a batteries-included big implementation,
are worthy goals.
--
Suffering from Gates-induced brain leakage...
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>
>> If SBCL (or any one implementation) becomes the de facto standard,
>> well, what does that mean? Does that mean that MCL or AllegroCL become
>> de facto non-standard? They have to change or they are non-standard?
>> Then you still have fragmentation until the vendors decide (if even
>> they do) to conform to SBCL.
>
>
> Since we don't have a dictator, I think making SBCL standard only means
> extending it with all kinds of libraries that Just Work (tm) with it, so
> everybody who wants to get stuff done can pick up SBCL, look at the docu
> and get started.
The problem there is that EMACS+SLIME is no match for a real IDE.
I posted in ignorance of the main impetus behind this idea, viz.,
getting newbies off the ground quickly. I think newbies will be more
worried about the bizarro so-called IDE than whether their code is
portable to other Lisps.
ken
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44mm3aF2uircU2@individual.net>
Kenny Tilton wrote:
>> Since we don't have a dictator, I think making SBCL standard only
>> means extending it with all kinds of libraries that Just Work (tm)
>> with it, so everybody who wants to get stuff done can pick up SBCL,
>> look at the docu and get started.
>
> The problem there is that EMACS+SLIME is no match for a real IDE.
Maybe. So far I've only tried Lispworks Personal, and Emacs+SLIME. The
latter works great for me, and I don't yet see the advantage of an IDE.
Maybe someday someone will make another one of those demo videos...
> I posted in ignorance of the main impetus behind this idea, viz.,
> getting newbies off the ground quickly. I think newbies will be more
> worried about the bizarro so-called IDE than whether their code is
> portable to other Lisps.
Yes, Emacs can be quite a turnoff, if you only want to learn a language.
Aquamacs on the Mac helps to ease the context switch between it and
other native apps.
--
Suffering from Gates-induced brain leakage...
Kenny Tilton wrote:
> The problem there is that EMACS+SLIME is no match for a real IDE.
>
> I posted in ignorance of the main impetus behind this idea, viz.,
> getting newbies off the ground quickly. I think newbies will be more
> worried about the bizarro so-called IDE than whether their code is
> portable to other Lisps.
Hmmm, I guess if you don't like emacs that is true. I've used Visual
C++ and I much prefer emacs, gdb and g++ to Visual C++. I agree that
getting comfortable with emacs probably has a steeper learning curve
that some fancy windows IDE.
One area in which SLIME is weaker than its emacs bretheren, Edebug, is
in stepping through code. Edebug moves the point each step so that it
is on the paren of the form that has just been evaluated and whose
value is being displayed. Of course coming from the embedded
programming world I'm used to not getting to step through code.
Lets apply the first principle of software design -- wishful thinking:
You don't like emacs/SLIME. OK. Imagine your dream Lisp IDE and tell
us what it would look like. Extra credit: imagine some less costly
(in terms of man power) alternatives and describe those.
For example, there is a project to get SLIME working with VI. Is that
good enough for you?
Cheers,
--fj
funkyj wrote:
> Kenny Tilton wrote:
>
>
>>The problem there is that EMACS+SLIME is no match for a real IDE.
>>
>>I posted in ignorance of the main impetus behind this idea, viz.,
>>getting newbies off the ground quickly. I think newbies will be more
>>worried about the bizarro so-called IDE than whether their code is
>>portable to other Lisps.
>
>
> Hmmm, I guess if you don't like emacs that is true.
I love emacs. For editing. FRED got me started, and I stuck with it even
though AllegroCL hid it deep in an options sub-dialog.
> I've used Visual
> C++ and I much prefer emacs, gdb and g++ to Visual C++. I agree that
> getting comfortable with emacs probably has a steeper learning curve
> that some fancy windows IDE.
>
> One area in which SLIME is weaker than its emacs bretheren, Edebug, is
> in stepping through code.
I do not believe in stepping through code. :)
> Edebug moves the point each step so that it
> is on the paren of the form that has just been evaluated and whose
> value is being displayed. Of course coming from the embedded
> programming world I'm used to not getting to step through code.
>
> Lets apply the first principle of software design -- wishful thinking:
> You don't like emacs/SLIME.
> OK. Imagine your dream Lisp IDE and tell
> us what it would look like.
It would look like it was aware that bit-mapped graphics, multi-window
GUIs were popularized twenty-one years ago.
> Extra credit: imagine some less costly
> (in terms of man power) alternatives and describe those.
>
> For example, there is a project to get SLIME working with VI. Is that
> good enough for you?
No. Emacs is fine as an editor. The problem is the GUI. I do not know
myself if having to talk to CL over a pipe is a problem. It might even
be an advantage in re bouncing (or recovering from hosing) the Lisp
environment.
ken
From: Robert Uhl
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m3k6c75a6q.fsf@NOSPAMgmail.com>
Kenny Tilton <·············@nyc.rr.com> writes:
>> You don't like emacs/SLIME.
>> OK. Imagine your dream Lisp IDE and tell
>> us what it would look like.
>
> It would look like it was aware that bit-mapped graphics, multi-window
> GUIs were popularized twenty-one years ago.
Oddly enough, my emacs has bit-mapped graphics, multiple windows, a GUI
and even support such things as toolbars...
--
Robert Uhl <http://public.xdi.org/=ruhl>
No wonder Unix makes you feel boxed in. It ties you to an inflexible
system. It requires you to pay for expensive experts. It makes you
struggle daily with a server environment that's more complex than ever.
--Microsoft ad proving that irony isn't dead
Robert Uhl wrote:
> Kenny Tilton <·············@nyc.rr.com> writes:
>
>>>You don't like emacs/SLIME.
>>> OK. Imagine your dream Lisp IDE and tell
>>>us what it would look like.
>>
>>It would look like it was aware that bit-mapped graphics, multi-window
>>GUIs were popularized twenty-one years ago.
>
>
> Oddly enough, my emacs has bit-mapped graphics, multiple windows, a GUI
> and even support such things as toolbars...
>
yeah, and it is using them all to emulate VT100s.
kenny
From: Lars Brinkhoff
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <85hd7ei0ju.fsf@junk.nocrew.org>
Kenny Tilton <·············@nyc.rr.com> writes:
> I was thinking the ALU should look at a role in development of
> substandards.
I thought ALU's substandard process was spelled CLRFI?
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u1wyiuhgr.fsf@agharta.de>
On Sun, 05 Feb 2006 09:32:40 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> If SBCL (or any one implementation) becomes the de facto standard,
> well, what does that mean? Does that mean that MCL or AllegroCL
> become de facto non-standard? They have to change or they are
> non-standard?
They will be driven out of the market or into a niche. I'm not saying
that this is a good thing nor am I predicting that it will happen
soon. But it is my impression that the only way we'll get a "de facto
standard" w.r.t. things like sockets and MP is one implementation
monopolizing Common Lisp. (In the MS ballpark - 80% will probably
suffice.)
> I was thinking the ALU should look at a role in development of
> substandards.
ROTFL.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Sun, 05 Feb 2006 13:18:28 +0100, Edi Weitz wrote:
> On Sun, 05 Feb 2006 09:32:40 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
>
>> If SBCL (or any one implementation) becomes the de facto standard,
>> well, what does that mean? Does that mean that MCL or AllegroCL
>> become de facto non-standard? They have to change or they are
>> non-standard?
>
> They will be driven out of the market or into a niche. I'm not saying
> that this is a good thing nor am I predicting that it will happen
> soon. But it is my impression that the only way we'll get a "de facto
> standard" w.r.t. things like sockets and MP is one implementation
> monopolizing Common Lisp. (In the MS ballpark - 80% will probably
> suffice.)
There still seems to be a substantial commercial C/C++ market even in the
presence of the GCC.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On 2006-02-05 04:32:40 -0500, Kenny Tilton <·············@nyc.rr.com> said:
> If SBCL (or any one implementation) becomes the de facto standard,
> well, what does that mean? Does that mean that MCL or AllegroCL become
> de facto non-standard? They have to change or they are non-standard?
> Then you still have fragmentation until the vendors decide (if even
> they do) to conform to SBCL.
As with all de facto standards others will find it in their interest to
provide compatibility. This does not mean that commercial
implementations will go away. Each has something unique and valuable to
offer customers - whether it be a cross platform GUI library, a
specialized persistence library, a platform specific header parsing
library, or maybe most importantly, support.
I'm simply saying that if there were an affordable single
implementation that did all these desirable things across these 3
platforms then it would become a de facto standard because it would be
so widely used. Other implementations would then find it in their
interests to provide compatibility with this de facto standard and
common lisp as a whole would become more uniform in important areas
such as multithreading, major library installation, and native GUI apps.
I can easily forsee a situation in which, speaking hypothetically, sbcl
became this implementation and LispWorks or some LispWorks users
implemented compatibility libraries that allowed one to use LispWorks
as if it were sbcl (with regard to multi-threading, asdf-installibility
of key libraries, and native GUI) but I would still choose to be a
LispWorks customer because I like the LispWorks IDE, or because
LispWorks generates faster CLOS code, or because LispWorks support is
so knowledgeable and responsive, etc. etc.
I don't see this as a bad thing for commercial vendors. I see it as a
way to make the whole lisp pie bigger because important, basic things
would "just work" *identically* across every major implementation, free
and commercial, which would draw more users to common lisp. IOW, it is
just a way to informally enlarge the standard without having to resort
to the time sink of a committee standardization process.
regards,
Ralph
Raffael Cavallaro wrote:
> I'm simply saying that if there were an affordable single
> implementation that did all these desirable things across these 3
> platforms then it would become a de facto standard because it would be
> so widely used. Other implementations would then find it in their
> interests to provide compatibility with this de facto standard and
> common lisp as a whole would become more uniform in important areas
> such as multithreading, major library installation, and native GUI apps.
"Trolls" have been saying this for *years* !
On 2006-02-06 21:33:50 -0500, ·········@gmail.com said:
> "Trolls" have been saying this for *years* !
No one is biting here. Try another paean to Stepanov and the STL on
comp.lang.functional.
Raffael Cavallaro wrote:
> On 2006-02-06 21:33:50 -0500, ·········@gmail.com said:
>
> > "Trolls" have been saying this for *years* !
>
> No one is biting here. Try another paean to Stepanov and the STL on
> comp.lang.functional.
What does STL have to do with the topic at hand (grand unified lisp
implementation, and your stealing ideas from "the trolls", and claiming
it as your own)?
But if you want to know more /about/ STL without actually learning it,
as seems to be the case, I suggest reading the introduction in Jeremy
Siek's Ph.D. thesis.
On 2006-02-07 07:18:42 -0500, ·········@gmail.com said:
> What does STL have to do with the topic at hand (grand unified lisp
> implementation, and your stealing ideas from "the trolls", and claiming
> it as your own)?
That was the topic at hand until you changed it to trolling:
On 2006-02-06 21:33:50 -0500, ·········@gmail.com said:
> "Trolls" have been saying this for *years* !
Since you changed the topic to trolls, I was just suggesting that you
play to your strength in that area which google groups indicates
consists in praising Stepanov and the STL on comp.lang.functional.
Raffael Cavallaro wrote:
> On 2006-02-04 16:51:17 -0500, Ron Garret <·········@flownet.com> said:
>
>> In article <··············@gigamonkeys.com>,
>> Peter Seibel <·····@gigamonkeys.com> wrote:
>> *You're* the one with money to invest--why don't *you* pay people.
>>
>> I answered this in another post, but briefly, because starting a
>> company is a lot of work, I've tried and failed twice, and I'm not
>> ready to try again just now.
>
>
> Ron,
> might I suggest that at least some of your (and Paul Graham's) surplus
> dollars might be well spent paying one of the maintainers of one of the
> cross-platform free lisp implementations to turn it into the thing I
> suggested in an earlier post - a de-facto standard implementation of
> common lisp:
So we finally kill off those pesky commercial Lisp vendors? :)
ken
Ron Garret <·········@flownet.com> writes:
> Pitman's substandards?) Third, I'm hoping people will start sending me
> business plans -- not immediately but over time. (I've already gotten
> one. It wasn't very good.) Fourth, I'm hoping that there are some
Where is your business-related "Ron's Combinator" web site? I have
been able to find only this one:
Ron Garret's Personal Home Page
http://www.flownet.com/gat/
Which doesn't apparently mention your call for business plans. But
you do have a nice cat.
I am by no means a business guy, a marketing guy or a Lisp wizard.
But I have been following the Lisp world pretty closely since the
early 1990s, and this thread is the first time of you mentioning this
particular kind of business I ever remember reading. Of course, I may
well be wrong.
If Lispers don't know you are looking^H^H^H^H^H^H^Hhoping for business
plans to fund, how can they apply?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > Pitman's substandards?) Third, I'm hoping people will start sending me
> > business plans -- not immediately but over time. (I've already gotten
> > one. It wasn't very good.) Fourth, I'm hoping that there are some
>
> Where is your business-related "Ron's Combinator" web site? I have
> been able to find only this one:
>
> Ron Garret's Personal Home Page
> http://www.flownet.com/gat/
>
> Which doesn't apparently mention your call for business plans.
I haven't set up a site yet. I wasn't actually planning on announcing
this soon, but I felt I had to explain why I was taking the discussion
in the direction I was taking it.
> But you do have a nice cat.
Thank you.
> I am by no means a business guy, a marketing guy or a Lisp wizard.
> But I have been following the Lisp world pretty closely since the
> early 1990s, and this thread is the first time of you mentioning this
> particular kind of business I ever remember reading. Of course, I may
> well be wrong.
>
> If Lispers don't know you are looking^H^H^H^H^H^H^Hhoping for business
> plans to fund, how can they apply?
Well, when I have my ducks in a row I was going to put out an official
announcement, but this thread seemed like an opportune moment to do a
little preliminary market research. In the meantime there's always
email.
rg
Ron Garret <·········@flownet.com> writes:
> > Don't get me wrong, I agree with much of what you have said. I think
> > that time and/or money can fix the technical issues (eg portable
> > sockets). But the only way to get more programmers is to be like Paul
> > Graham and evangelise.
>
> No, that is not the only way. Another way, the way I am suggesting, is
> to start to take business considerations seriously, make money, and
> start *paying* people. People don't learn Perl because they love it,
> they learn Perl because they think (correctly) that they can make a
> living by knowing it. If people think they can make a living by knowing
> Lisp they'll learn Lisp even without evangelism.
Your scenario of startups in 2008 (snipped) actually sounds
conservative. Putting together a web startup can be done on a
shoestring these days (open source, intel servers, cheap bandwidth,
blog marketing, and hard work), and if you are in the right field,
Google, Yahoo, Microsoft or someone else just might snap you up
instead of going through an A-round. That's for better or worse, but
the point is, you probably won't need a lot of capital for the angel
round.
Since Lisp should be useful for machine learning, search, etc., it
rather sounds like a competitive advantage in a business plan for that
sort of "web service". (If anyone even cares about such a detail as
the implementation language.) For instance, Mark Battyani (sp?)
whipped together that Reddit clone in just a couple of days, didn't
he? How hard would it be to surpass del.icio.us? Or Craigslist?
So, worrying too much about the underlying technology is probably
premature in this scenario. Franz or whoever are unlikely to fold in
the next year or two, and in that time, you will have proven whether
the idea works or not. Later on, if your startups are clamouring to
buy Lisp licenses, the companies selling them probably won't go under;
or the open source volunteers can incorporate to support the chosen
version. (And maybe you can force the startups you fund to use a
certain implementation to get a modest bit of economy of scale. If
you're in a controlling mood.)
But when you are the guy with the dollars, you're in an even better
position: you simply select an investment theme, e.g., "I am doing
angel funding for startups working in the intersection of web services
and machine learning / AI. Your use of Lisp is not seen as a problem."
Then fund the ones that seem to know what they are doing.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Ron Garret wrote:
> In article <························@g47g2000cwa.googlegroups.com>,
> ··········@gmail.com wrote:
>
> > Ron Garret wrote:
> > > You are missing the point. (Holy cow, I am getting so tired of saying
> > > that.) Of course there are CL implementations I can trust. What there
> > > is not is a CL implementation I can build a business case for using.
> >
> > What's the problem, then? If you can trust an implementation (I assume
> > that by "trust" you mean that you're confident in its stability and
> > future support), why not write to it, and to hell with the ANSI
> > standard?
>
> Because of the high risk of using any software product with a very small
> user community and limited or nonexistent commercial support.
I see that your definition of "trust" differs from mine. I would call
that "mistrust."
Using Lisp carries risks and benefits. The benefits, assuming we're
not all dead wrong about Lisp's superiority, would include the obvious
one that it's cheaper to pay for fewer programmer hours. But more
importantly, you'd have shorter time to market. That can make the
difference between becoming the Ebay of your market and becoming one of
the numerous also-rans (remember all the Ebay clone auction sites?
Neither do I).
I'm not going to enumerate the risks, because you've already done so,
but I think you're exaggerating them. SBCL, at least, is healthy
enough that no n hackers abandoning it would kill it, where n >=2
(maybe somebody more familiar with that community can give a better
estimate). There's at least one shop offering commercial support, and
you could probably just hire some SBCL hackers. I don't know enough
about other implementations to make a judgement.
If you could score a startup, where 1.0 means guaranteed success and 0
means guaranteed failure, what would you estimate the risks and
benefits of using Lisp subtract or add to the value of the company?
How about Python?
I think that Lisp may be more risky, but it also carries a greater
chance of reward, assuming we're all right about its superiority. That
sounds like a good deal to me, if you're making a risky, all-or-none
gamble on a start-up.
In article <························@o13g2000cwo.googlegroups.com>,
··········@gmail.com wrote:
> Ron Garret wrote:
> > In article <························@g47g2000cwa.googlegroups.com>,
> > ··········@gmail.com wrote:
> >
> > > Ron Garret wrote:
> > > > You are missing the point. (Holy cow, I am getting so tired of saying
> > > > that.) Of course there are CL implementations I can trust. What there
> > > > is not is a CL implementation I can build a business case for using.
> > >
> > > What's the problem, then? If you can trust an implementation (I assume
> > > that by "trust" you mean that you're confident in its stability and
> > > future support), why not write to it, and to hell with the ANSI
> > > standard?
> >
> > Because of the high risk of using any software product with a very small
> > user community and limited or nonexistent commercial support.
>
> I see that your definition of "trust" differs from mine. I would call
> that "mistrust."
I meant trust as a hacker. I've actually never used SBCL, but I have
used CLisp, MCL (both closed and open), Franz, LispWorks, and ECL (a
long, long time ago). Of those, as a hacker I would trust them all
except ECL which, at the time I used it, was too buggy to be useful.
I won't say that there couldn't be situations where I would trust one or
more of these even as a businessman. You could think of the remote
agent as a little micro-business within the closed economy of NASA, and
I certainly trusted Lisp for that. But that worked only because we were
developing a completely new thing more or less from scratch that didn't
have to interface with anything except other custom software that was
being developed more or less from scratch. Opportunities to make money
doing that sort of thing are exceedingly rare nowadays. Also, the
competition has done a lot of catching up since the RA days. Back then,
C++ was a mess, Java was in its infancy, and Python didn't exist at all.
> Using Lisp carries risks and benefits. The benefits, assuming we're
> not all dead wrong about Lisp's superiority, would include the obvious
> one that it's cheaper to pay for fewer programmer hours. But more
> importantly, you'd have shorter time to market. That can make the
> difference between becoming the Ebay of your market and becoming one of
> the numerous also-rans (remember all the Ebay clone auction sites?
> Neither do I).
I think you actually missed one of the most important potential benefits
of Lisp: the ability to make changes quickly and reliably once you're
already in production. I think that's actually a much bigger win than
anything else, but it only manifests itself in the long run.
> I'm not going to enumerate the risks, because you've already done so,
> but I think you're exaggerating them.
You are entitled to your opinion. But since I'm the one soliciting
proposals here I get the final say on what is and what is not an
acceptable risk. Which is not to say that my opinion couldn't be
changed, but so far all the responses I've seen are straw men.
> SBCL, at least, is healthy
> enough that no n hackers abandoning it would kill it, where n >=2
> (maybe somebody more familiar with that community can give a better
> estimate).
That's not enough. To build a business case I need to be able to
estimate my costs and schedule. It's not enough to know that there are
some volunteers out there working on stuff when it suits them. There is
a huge difference between "not dead" and "suitable to base a business
on", between healthy from a hacker's point of view and healthy from a
businessman's point of view.
> There's at least one shop offering commercial support,
Really? Which shop would that be? How long have they been in business?
How likely are they to still exist one year from now?
> and you could probably just hire some SBCL hackers.
I probably could, but if I'm the only one doing that then I need to bear
the full cost of any infrastructure development and maintenance that
needs to be done. The bigger the user community the more these costs
can be amortized across multiple parties.
> If you could score a startup, where 1.0 means guaranteed success and 0
> means guaranteed failure, what would you estimate the risks and
> benefits of using Lisp subtract or add to the value of the company?
> How about Python?
It all depends on the circumstances. But all else being equal, more
people using whatever I'm using the better (assuming, of course, that
not too many of them are my competitors).
> I think that Lisp may be more risky, but it also carries a greater
> chance of reward, assuming we're all right about its superiority. That
> sounds like a good deal to me, if you're making a risky, all-or-none
> gamble on a start-up.
All true, but given that people are not exactly tripping over themselves
to accept the current risks, why not make some effort to mitigate them
instead of just accepting them as givens?
rg
··········@gmail.com wrote:
> Ron Garret wrote:
>
>>In article <························@g47g2000cwa.googlegroups.com>,
>> ··········@gmail.com wrote:
>>
>>
>>>Ron Garret wrote:
>>>
>>>>You are missing the point. (Holy cow, I am getting so tired of saying
>>>>that.) Of course there are CL implementations I can trust. What there
>>>>is not is a CL implementation I can build a business case for using.
>>>
>>>What's the problem, then? If you can trust an implementation (I assume
>>>that by "trust" you mean that you're confident in its stability and
>>>future support), why not write to it, and to hell with the ANSI
>>>standard?
>>
>>Because of the high risk of using any software product with a very small
>>user community and limited or nonexistent commercial support.
>
>
> I see that your definition of "trust" differs from mine. I would call
> that "mistrust."
>
> Using Lisp carries risks and benefits. The benefits, assuming we're
> not all dead wrong about Lisp's superiority, would include the obvious
> one that it's cheaper to pay for fewer programmer hours.
And it is hugely cheaper. If my language is half as good as Lisp, I have
to hire four times as many programmers -- bigger teams create
communication problems, step on each other's toes, don't know all the
code, and additional programmers are never as good as the one or two
whizzes spearheading development... better make that ten times as many.
Now I have twenty monkeys banging out code in a crappy language --
thanks Ron!
:)
ken
Kenny Tilton <·············@nyc.rr.com> writes:
>>>>Ron Garret wrote:
>>>>
>>>>>You are missing the point. (Holy cow, I am getting so tired of saying
>>>>>that.) Of course there are CL implementations I can trust. What there
>>>>>is not is a CL implementation I can build a business case for using.
>>> [...]
> And it is hugely cheaper. If my language is half as good as Lisp, I
> have to hire four times as many programmers -- bigger teams create
> communication problems, step on each other's toes, don't know all the
> code, and additional programmers are never as good as the one or two
> whizzes spearheading development... better make that ten times as
> many.
>
> Now I have twenty monkeys banging out code in a crappy language --
> thanks Ron!
Ron confessed to be in the business business, he plans to make yet
another startup in a couple of years. It's a good strategy for him to
do all he can to deter competition meanwhile ;-) Unfortunately, the
secret is out, too many people already know lisp is a secret weapon.
The only thing remaining is disinformation.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u7j8b8o5n.fsf@agharta.de>
On Fri, 03 Feb 2006 23:46:35 -0800, Ron Garret <·········@flownet.com> wrote:
> You are missing the point. (Holy cow, I am getting so tired of
> saying that.)
Yeah, isn't it kind of strange that /everybody/ you're arguing with is
missing the point? Hmm....
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Fri, 03 Feb 2006 23:46:35 -0800, Ron Garret <·········@flownet.com> wrote:
>
> > You are missing the point. (Holy cow, I am getting so tired of
> > saying that.)
>
> Yeah, isn't it kind of strange that /everybody/ you're arguing with is
> missing the point? Hmm....
Actually, it seems to be just you and Kenny. You two just keep missing
it over and over and over again.
rg
On Fri, 03 Feb 2006 23:46:35 -0800, Ron Garret <·········@flownet.com>
wrote:
>should be a source of lucrative opportunities. But I have tried to
>construct a business case for Lisp and I have failed for reasons I have
Can you construct a business case for doing the same work without
Lisp? If the common wisdom that most software projects fail is true,
the business cases for those projects must either take that failure
into account and expect to fail, or fail to take that failure into
account. Either way, that kind of business case is not worth much.
A business case for a programming project should, but usually doesn't,
take into account some factors that would favor Lisp:
1. Programmers tend to leave their jobs for similar work elsewhere.
2. The value of a programmer to a project increases with time, so the
programmer who leaves the project is taking more value from it per
future amount of time than he put into it per past amount of time.
3. Lisp programmers can't leave their jobs as easily, because it's
harder for them to find similar work elsewhere.
4. The value of a Lisp programmer might be higher earlier in the
project than non-Lisp programmers. He might have a less steep
learning curve. Lisp programmers tend to have more programming talent
and experience.
5. Software development is very costly. Lisp programmers do more
software development for less money.
6. The hiring decisions made by software development managers take
into account not only the best interests of their company/project but
also the best interests of their own careers. The more programmers
working for them, the higher their status and value, and the more
secure their jobs. If they can find 1000 Java programmers to do the
work of 10 Lisp programmers, they will have a much higher status for
being the manager of 1000 people.
A lot of business cases are full of BS, partly to try to improve some
careers at the expense of some companies/projects, and partly because
those who write and those who read the business case usually aren't
very good at it.
Lisp gives individual programmers the chance to become successful in
business by letting them do all the programming work alone that would
normally be done by large teams, and still have time left for the
management of the one-person company. When Lisp takes over the
software development world, it might be with a new business model
where each programmer is a one-person company doing all the
development, maintenance, and marketing, for one product, or a group
of similar products. New companies to assist programmers with
marketing, etc. might come as part of that new landscape. Large
projects might still exist for a long time, from momentum, as a place
for mediocre programmers to draw a salary while waiting for each
project to fail before going on to the next.
In article <··································@4ax.com>,
····@unreal.uncom wrote:
> On Fri, 03 Feb 2006 23:46:35 -0800, Ron Garret <·········@flownet.com>
> wrote:
>
> >should be a source of lucrative opportunities. But I have tried to
> >construct a business case for Lisp and I have failed for reasons I have
>
> Can you construct a business case for doing the same work without
> Lisp? If the common wisdom that most software projects fail is true,
> the business cases for those projects must either take that failure
> into account and expect to fail, or fail to take that failure into
> account. Either way, that kind of business case is not worth much.
>
> A business case for a programming project should, but usually doesn't,
> take into account some factors that would favor Lisp:
>
> 1. Programmers tend to leave their jobs for similar work elsewhere.
> 2. The value of a programmer to a project increases with time, so the
> programmer who leaves the project is taking more value from it per
> future amount of time than he put into it per past amount of time.
> 3. Lisp programmers can't leave their jobs as easily, because it's
> harder for them to find similar work elsewhere.
> 4. The value of a Lisp programmer might be higher earlier in the
> project than non-Lisp programmers. He might have a less steep
> learning curve. Lisp programmers tend to have more programming talent
> and experience.
> 5. Software development is very costly. Lisp programmers do more
> software development for less money.
> 6. The hiring decisions made by software development managers take
> into account not only the best interests of their company/project but
> also the best interests of their own careers. The more programmers
> working for them, the higher their status and value, and the more
> secure their jobs. If they can find 1000 Java programmers to do the
> work of 10 Lisp programmers, they will have a much higher status for
> being the manager of 1000 people.
>
> A lot of business cases are full of BS, partly to try to improve some
> careers at the expense of some companies/projects, and partly because
> those who write and those who read the business case usually aren't
> very good at it.
>
> Lisp gives individual programmers the chance to become successful in
> business by letting them do all the programming work alone that would
> normally be done by large teams, and still have time left for the
> management of the one-person company. When Lisp takes over the
> software development world, it might be with a new business model
> where each programmer is a one-person company doing all the
> development, maintenance, and marketing, for one product, or a group
> of similar products. New companies to assist programmers with
> marketing, etc. might come as part of that new landscape. Large
> projects might still exist for a long time, from momentum, as a place
> for mediocre programmers to draw a salary while waiting for each
> project to fail before going on to the next.
Yes, I actually advanced this theory many years ago that the reason Lisp
fails is precisely *because* it allows a single programmer to be so
enormously productive. As a result Lisp tends to attract people who are
not good team players (like me) while C tends to attract those who are
because that's the only way to get anything done. Unfortunately, in
almost all cases, a team of less effective people will beat the living
crap out of even the most effective loner because there's just too much
work to do to support a business. Building the product is just a small
part of it.
I did my first startup more than ten years ago. We spent a lot (by our
standards at the time) of money building a prototype (it was a hardware
product). Then we talked to a *lot* of VC's. To my surprise, not a
single one of them ever wanted to see the prototype. Whether or not the
product worked was a secondary consideration for them that was dominated
by the fact that we had no management, no sales force, no marketing
plan, no customers, in short, no business. A business is much, much
more than just a product. In fact, it is not even necessary to have a
product to have a business! That's the basis of the so-called "service
economy." Consultants, agents, psychotherapists, house cleaners -- none
of them produce a product.
rg
From: Don Geddis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87zml2gbwi.fsf@geddis.org>
Ron Garret <·········@flownet.com> wrote on Sat, 04 Feb 2006:
> Then we talked to a *lot* of VC's. To my surprise, not a single one of
> them ever wanted to see the prototype. Whether or not the product worked
> was a secondary consideration for them that was dominated by the fact that
> we had no management, no sales force, no marketing plan, no customers, in
> short, no business.
Sounds typical.
> A business is much, much more than just a product.
I agree. That's part of the reason the search for "Lisp-based startup" is
so difficult. Any startup that emphasizes "we use Lisp!" is probably missing
the big picture (customers, value proposition, profits) and thus doomed to
failure. Really, in some sense, the tools used to build the product are
in the noise as far as whether a business succeeds.
Despite what Paul Graham writes...
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If I could sum up my life in one sentence, I think it would be: He was born, he
lived, and then he kept on living, much longer than anyone had ever lived
before, getting richer and richer and glowing with a bright white light.
-- Deep Thoughts, by Jack Handey [1999]
From: Peter Seibel
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m2oe1nqipm.fsf@gigamonkeys.com>
Ron Garret <·········@flownet.com> writes:
> You are missing the point. (Holy cow, I am getting so tired of
> saying that.) Of course there are CL implementations I can trust.
> What there is not is a CL implementation I can build a business case
> for using.
In what context? You're obviously operating in some specific
situation, with money burning a hole in your pocket that you've got to
invest. But maybe there are contstraints on how you can invent that
money that make Lisp a bad choice for you. Which is fine, but that
doesn't mean that there's never a business case for using Lisp.
Having been through several startups, some successful and some not, my
estimation is that the benefits of using Lisp would be much more
powerful in a bootstrap startup, i.e. exactly the kind of company
that's not looking for your money.
> This is not to say that someone else couldn't do it. I have subtly
> hinted at this, but perhaps I should be more explicit: I have money
> to invest, and I believe that Lisp's core technical superiority
> could and should be a source of lucrative opportunities. But I have
> tried to construct a business case for Lisp and I have failed for
> reasons I have tried to describe in this thread, and I do not see
> evidence that others are meeting with more success than I have had
> in this regard.
Do you have a list of business success stories for other languages?
Seems to me that actual business successes are quite rare to start
with and ones that took specific advantage of one programming language
or another even more rare. (Is Google a C++ success story? Maybe. What
about all the Python they use? And if they had used CL instead of
Python, would they have failed? Maybe. Maybe not.)
> There are only two possible constructive responses to this. One is:
> you're wrong, here's a business plan (or "you're wrong, we just
> signed a deal with Sequoia for $25M is round A funding"). The other
> is: you're right. What should we do to improve the situation?
If you insist that those are the only two possible constructive
responses, then maybe you can show us an acceptable business plan
based on some *other* language, and then we can figure out how to
tweak it to mitigate the risks of using Lisp while taking advantage of
Lisp's great technical advantages.
In the meantime those of us who are happily using Lisp and making
money doing so will probably continue to do so and may even do a thing
or two to make Lisp competitive in more contexts than it is now.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > You are missing the point. (Holy cow, I am getting so tired of
> > saying that.) Of course there are CL implementations I can trust.
> > What there is not is a CL implementation I can build a business case
> > for using.
>
> In what context? You're obviously operating in some specific
> situation, with money burning a hole in your pocket that you've got to
> invest. But maybe there are contstraints on how you can invent that
> money that make Lisp a bad choice for you.
The constraint is that I want to minimize my risk for a given expected
return.
> Which is fine, but that
> doesn't mean that there's never a business case for using Lisp.
I never said that there is never a business case for using Lisp. I only
said that I have tried and failed to come up with one myself. If I
could we wouldn't be having this conversation because I'd be too busy
running my startup.
> Having been through several startups, some successful and some not, my
> estimation is that the benefits of using Lisp would be much more
> powerful in a bootstrap startup, i.e. exactly the kind of company
> that's not looking for your money.
Perhaps, but even bootstrap startups, if they are successful, eventually
get to the point where they can make effective use of capital to expand.
In fact, it is much easier to get funding for companies that are already
in business than it is for raw startups.
> Do you have a list of business success stories for other languages?
Of course, there's a long list of them, starting with Microsoft and
Google. In fact, every successful startup that uses software (which is
pretty much every successful startup nowadays) necessarily uses software
written in some language, and very nearly 100% of them nowadays use some
language other than Lisp.
> Seems to me that actual business successes are quite rare to start
> with and ones that took specific advantage of one programming language
> or another even more rare. (Is Google a C++ success story? Maybe. What
> about all the Python they use?
Google is a C++/Python/Perl/SQL success story, with maybe a few others
tossed in to the mix.
> And if they had used CL instead of
> Python, would they have failed? Maybe. Maybe not.)
I think they might well have failed if Larry and Sergey had tried to
write the original Google search engine using the CL implementations
available in 1998.
> > There are only two possible constructive responses to this. One is:
> > you're wrong, here's a business plan (or "you're wrong, we just
> > signed a deal with Sequoia for $25M is round A funding"). The other
> > is: you're right. What should we do to improve the situation?
>
> If you insist that those are the only two possible constructive
> responses, then maybe you can show us an acceptable business plan
> based on some *other* language, and then we can figure out how to
> tweak it to mitigate the risks of using Lisp while taking advantage of
> Lisp's great technical advantages.
Like I said, take any successful startup that involves software. One of
the features of a successful Lisp business plan is that it will very
likely not mention Lisp.
> In the meantime those of us who are happily using Lisp and making
> money doing so will probably continue to do so and may even do a thing
> or two to make Lisp competitive in more contexts than it is now.
More power to you.
rg
From: Peter Seibel
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m2irrvq67r.fsf@gigamonkeys.com>
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > You are missing the point. (Holy cow, I am getting so tired of
>> > saying that.) Of course there are CL implementations I can trust.
>> > What there is not is a CL implementation I can build a business case
>> > for using.
>>
>> In what context? You're obviously operating in some specific
>> situation, with money burning a hole in your pocket that you've got to
>> invest. But maybe there are contstraints on how you can invent that
>> money that make Lisp a bad choice for you.
>
> The constraint is that I want to minimize my risk for a given
> expected return.
I'd suggest a nice index fund.
>> Which is fine, but that doesn't mean that there's never a business
>> case for using Lisp.
>
> I never said that there is never a business case for using Lisp. I
> only said that I have tried and failed to come up with one myself.
> If I could we wouldn't be having this conversation because I'd be
> too busy running my startup.
Have you tried and succeeded in coming up with a plan for a startup
using some *other* language. Maybe the language isn't the problem. I'm
not trying to be snide--just pointing out that it's *hard* to come up
with good ideas for a business, regardless of what tools one would
like to use. I'm pretty sure if I could come up with a good idea for a
business, that I'd then find a way to use Lisp to advantage but I
can't say for sure because I haven't had any good ideas.
>> Having been through several startups, some successful and some not,
>> my estimation is that the benefits of using Lisp would be much more
>> powerful in a bootstrap startup, i.e. exactly the kind of company
>> that's not looking for your money.
>
> Perhaps, but even bootstrap startups, if they are successful,
> eventually get to the point where they can make effective use of
> capital to expand. In fact, it is much easier to get funding for
> companies that are already in business than it is for raw startups.
So what. I'm more interested in the challenges of getting to that
point. I think Lisp offers--for at least some software-based
businesses--an advantage that can increase ones chance of getting
there. After that, you either cash out or stick around to deal with
making the company a long-term success. But most companies never make
it that far.
>> Do you have a list of business success stories for other languages?
>
> Of course, there's a long list of them, starting with Microsoft and
> Google. In fact, every successful startup that uses software (which
> is pretty much every successful startup nowadays) necessarily uses
> software written in some language, and very nearly 100% of them
> nowadays use some language other than Lisp.
Well, nearly 100% of programmers use some language other than Lisp.
That most companies happen to use a different language just reflects
the times. But if most people are making a suboptimal choice, it seems
like that's a good opportunity to make money, if you can stand the
risk.
>> Seems to me that actual business successes are quite rare to start
>> with and ones that took specific advantage of one programming
>> language or another even more rare. (Is Google a C++ success story?
>> Maybe. What about all the Python they use?
>
> Google is a C++/Python/Perl/SQL success story, with maybe a few others
> tossed in to the mix.
>
>> And if they had used CL instead of Python, would they have failed?
>> Maybe. Maybe not.)
>
> I think they might well have failed if Larry and Sergey had tried to
> write the original Google search engine using the CL implementations
> available in 1998.
Why? Don't you think they could have picked one implementation and run
with it if they really wanted to? That they happened to by C++ hackers
rather than Lisp hackers seems to me an accident of history. A likely
accident of history, of course, given the relative number of C++
programmers and Lisp programmers, but an accident none the less.
>> > There are only two possible constructive responses to this. One
>> > is: you're wrong, here's a business plan (or "you're wrong, we
>> > just signed a deal with Sequoia for $25M is round A funding").
>> > The other is: you're right. What should we do to improve the
>> > situation?
>>
>> If you insist that those are the only two possible constructive
>> responses, then maybe you can show us an acceptable business plan
>> based on some *other* language, and then we can figure out how to
>> tweak it to mitigate the risks of using Lisp while taking advantage
>> of Lisp's great technical advantages.
>
> Like I said, take any successful startup that involves software.
So what you're saying is that I can take the business plan of *any*
successful startup and replace Python/Java/C++/Perl/Ruby/whatever with
Common Lisp and be guaranteed to have made it a less good business
plan? I suspect most business plans would retain the same liklihoood
of success after that change. A few would immediately become stupid
and a few would probably be improved.
If you like Lisp, as you say you do, then you should pick one of the
latter ones. But if you like making money more, then you might not
want to limit your options that way. That's fine. And you might wish
that there were more business plans that would benefit from the
addition of a little Lisp. My prediction is that the only way that
situation will change is if some folks find the places where Lisp
already gives an advantage and use it. As some of them succeed it'll
probably have some effect on the Lisp ecosystem, broadening the niche
in which it can be used to advantage.
Or, if you believe that Lisp is already technically superior to other
languages and lacks only certain business infrastructure to make a
superior choice for business, then maybe you should take that money in
your pocket and start a tool company--if you're right, then once
you've provided the necessary customer-centric, business-focused
infrastructure for using Lisp then there should be a huge number of
startups that will want to use your product to obtain a competitive
advantage. What are you waiting for?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Have you tried and succeeded in coming up with a plan for a startup
> using some *other* language.
Sure, lots of them. I have even followed through on two of them (both
failed, not because I didn't use Lisp, but rather because I was naive
about business issues).
> Maybe the language isn't the problem. I'm
> not trying to be snide--just pointing out that it's *hard* to come up
> with good ideas for a business, regardless of what tools one would
> like to use. I'm pretty sure if I could come up with a good idea for a
> business, that I'd then find a way to use Lisp to advantage but I
> can't say for sure because I haven't had any good ideas.
Yes, it's very hard. I'm certainly not suggesting otherwise. But the
rewards are great, and I'm hoping there are some lurkers out there who
will be motivated to try, and that by posting here I might be able to
help (by providing capital, and maybe advice and contacts) and be
compensated with a piece of the action.
> >> Having been through several startups, some successful and some not,
> >> my estimation is that the benefits of using Lisp would be much more
> >> powerful in a bootstrap startup, i.e. exactly the kind of company
> >> that's not looking for your money.
> >
> > Perhaps, but even bootstrap startups, if they are successful,
> > eventually get to the point where they can make effective use of
> > capital to expand. In fact, it is much easier to get funding for
> > companies that are already in business than it is for raw startups.
>
> So what. I'm more interested in the challenges of getting to that
> point. I think Lisp offers--for at least some software-based
> businesses--an advantage that can increase ones chance of getting
> there. After that, you either cash out or stick around to deal with
> making the company a long-term success. But most companies never make
> it that far.
That's right, and that's usually for one of two reasons. Either the
person starting the company doesn't have any business savvy, or they run
out of capital.
> >> Do you have a list of business success stories for other languages?
> >
> > Of course, there's a long list of them, starting with Microsoft and
> > Google. In fact, every successful startup that uses software (which
> > is pretty much every successful startup nowadays) necessarily uses
> > software written in some language, and very nearly 100% of them
> > nowadays use some language other than Lisp.
>
> Well, nearly 100% of programmers use some language other than Lisp.
> That most companies happen to use a different language just reflects
> the times. But if most people are making a suboptimal choice, it seems
> like that's a good opportunity to make money, if you can stand the
> risk.
Yes, that would be precisely the point I am trying to make.
> >> Seems to me that actual business successes are quite rare to start
> >> with and ones that took specific advantage of one programming
> >> language or another even more rare. (Is Google a C++ success story?
> >> Maybe. What about all the Python they use?
> >
> > Google is a C++/Python/Perl/SQL success story, with maybe a few others
> > tossed in to the mix.
> >
> >> And if they had used CL instead of Python, would they have failed?
> >> Maybe. Maybe not.)
> >
> > I think they might well have failed if Larry and Sergey had tried to
> > write the original Google search engine using the CL implementations
> > available in 1998.
>
> Why? Don't you think they could have picked one implementation and run
> with it if they really wanted to? That they happened to by C++ hackers
> rather than Lisp hackers seems to me an accident of history. A likely
> accident of history, of course, given the relative number of C++
> programmers and Lisp programmers, but an accident none the less.
Because to make Google work they had to optimize it very heavily. They
had to write a new file system for Linux. That alone would have been
impossible in Lisp.
> >> > There are only two possible constructive responses to this. One
> >> > is: you're wrong, here's a business plan (or "you're wrong, we
> >> > just signed a deal with Sequoia for $25M is round A funding").
> >> > The other is: you're right. What should we do to improve the
> >> > situation?
> >>
> >> If you insist that those are the only two possible constructive
> >> responses, then maybe you can show us an acceptable business plan
> >> based on some *other* language, and then we can figure out how to
> >> tweak it to mitigate the risks of using Lisp while taking advantage
> >> of Lisp's great technical advantages.
> >
> > Like I said, take any successful startup that involves software.
>
> So what you're saying is that I can take the business plan of *any*
> successful startup and replace Python/Java/C++/Perl/Ruby/whatever with
> Common Lisp and be guaranteed to have made it a less good business
> plan?
No, that is not what I am saying. That is a caricature of what I am
saying, and I'm not going to respond to those any more.
> I suspect most business plans would retain the same liklihoood
> of success after that change. A few would immediately become stupid
> and a few would probably be improved.
Yes, most likely.
> If you like Lisp, as you say you do, then you should pick one of the
> latter ones. But if you like making money more, then you might not
> want to limit your options that way. That's fine. And you might wish
> that there were more business plans that would benefit from the
> addition of a little Lisp. My prediction is that the only way that
> situation will change is if some folks find the places where Lisp
> already gives an advantage and use it. As some of them succeed it'll
> probably have some effect on the Lisp ecosystem, broadening the niche
> in which it can be used to advantage.
>
> Or, if you believe that Lisp is already technically superior to other
> languages and lacks only certain business infrastructure to make a
> superior choice for business, then maybe you should take that money in
> your pocket and start a tool company--if you're right, then once
> you've provided the necessary customer-centric, business-focused
> infrastructure for using Lisp then there should be a huge number of
> startups that will want to use your product to obtain a competitive
> advantage. What are you waiting for?
I'm a two-time loser when it comes to starting my own company, so I'm a
little gun-shy about it at the moment. So I've decided to play venture
capitalist for a while and see if I could leverage other people's bright
ideas instead of my own, and maybe learn what I should be doing
differently. I suspect I'll give my own startup another shot in a
couple of years, but right now I'm not ready.
rg
From: Peter Seibel
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m2acd6rdl3.fsf@gigamonkeys.com>
Ron Garret <·········@flownet.com> writes:
> Yes, it's very hard. I'm certainly not suggesting otherwise. But the
> rewards are great, and I'm hoping there are some lurkers out there
> who will be motivated to try, and that by posting here I might be
> able to help (by providing capital, and maybe advice and contacts)
> and be compensated with a piece of the action.
Okay. So you might want to consider that your postings to date in this
thread have sounded--to me anyway--more like:
"Lisp can not be used in business for the following reasons and
which won't change until some realignment of the universe happens,
which I don't think will happen because none of you jokers seems to
even understand there's a problem."
than:
"I think Lisp could be a huge advantage for a startup but haven't
personally been able to figure out how to capitalize on that
advantage. If someone else has, get in touch because I have cash,
contacts, and experience that might be valuable to you."
>> > Perhaps, but even bootstrap startups, if they are successful,
>> > eventually get to the point where they can make effective use of
>> > capital to expand. In fact, it is much easier to get funding for
>> > companies that are already in business than it is for raw
>> > startups.
>>
>> So what. I'm more interested in the challenges of getting to that
>> point. I think Lisp offers--for at least some software-based
>> businesses--an advantage that can increase ones chance of getting
>> there. After that, you either cash out or stick around to deal with
>> making the company a long-term success. But most companies never
>> make it that far.
>
> That's right, and that's usually for one of two reasons. Either the
> person starting the company doesn't have any business savvy, or they
> run out of capital.
And one of the reason I think Lisp is a good tool for startups is that
you can get to your early milestones faster which means you are less
likely to run out of capital.
>> Well, nearly 100% of programmers use some language other than Lisp.
>> That most companies happen to use a different language just
>> reflects the times. But if most people are making a suboptimal
>> choice, it seems like that's a good opportunity to make money, if
>> you can stand the risk.
>
> Yes, that would be precisely the point I am trying to make.
Okay, so add me to the list of people who didn't get that at all.
>> > I think they might well have failed if Larry and Sergey had tried
>> > to write the original Google search engine using the CL
>> > implementations available in 1998.
>>
>> Why? Don't you think they could have picked one implementation and
>> run with it if they really wanted to? That they happened to by C++
>> hackers rather than Lisp hackers seems to me an accident of
>> history. A likely accident of history, of course, given the
>> relative number of C++ programmers and Lisp programmers, but an
>> accident none the less.
>
> Because to make Google work they had to optimize it very heavily. They
> had to write a new file system for Linux. That alone would have been
> impossible in Lisp.
But who cares? Once they get to the point where they realize they need
a new filesystem, that's a separate development effort from their main
search algorithm/application. At least I assume so--the file system
isn't intertwingled into their app is it? If they had started in Lisp
and then realized that the existing file systems weren't performant
enough or whatever they can do exactly what I assume they did--write a
new filesystem in C and use it from their main app written in
whatever.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > Yes, it's very hard. I'm certainly not suggesting otherwise. But the
> > rewards are great, and I'm hoping there are some lurkers out there
> > who will be motivated to try, and that by posting here I might be
> > able to help (by providing capital, and maybe advice and contacts)
> > and be compensated with a piece of the action.
>
> Okay. So you might want to consider that your postings to date in this
> thread have sounded--to me anyway--more like:
>
> "Lisp can not be used in business for the following reasons and
> which won't change until some realignment of the universe happens,
> which I don't think will happen because none of you jokers seems to
> even understand there's a problem."
>
> than:
>
> "I think Lisp could be a huge advantage for a startup but haven't
> personally been able to figure out how to capitalize on that
> advantage. If someone else has, get in touch because I have cash,
> contacts, and experience that might be valuable to you."
Fair enough. I think Lisp could be a huge advantage for a startup but
haven't personally been able to figure out how to capitalize on that
advantage. If someone else has, get in touch because I have cash,
contacts, and experience that might be valuable to you.
> >> > Perhaps, but even bootstrap startups, if they are successful,
> >> > eventually get to the point where they can make effective use of
> >> > capital to expand. In fact, it is much easier to get funding for
> >> > companies that are already in business than it is for raw
> >> > startups.
> >>
> >> So what. I'm more interested in the challenges of getting to that
> >> point. I think Lisp offers--for at least some software-based
> >> businesses--an advantage that can increase ones chance of getting
> >> there. After that, you either cash out or stick around to deal with
> >> making the company a long-term success. But most companies never
> >> make it that far.
> >
> > That's right, and that's usually for one of two reasons. Either the
> > person starting the company doesn't have any business savvy, or they
> > run out of capital.
>
> And one of the reason I think Lisp is a good tool for startups is that
> you can get to your early milestones faster which means you are less
> likely to run out of capital.
Good point.
> >> Well, nearly 100% of programmers use some language other than Lisp.
> >> That most companies happen to use a different language just
> >> reflects the times. But if most people are making a suboptimal
> >> choice, it seems like that's a good opportunity to make money, if
> >> you can stand the risk.
> >
> > Yes, that would be precisely the point I am trying to make.
>
> Okay, so add me to the list of people who didn't get that at all.
See? This is what happens when you take a Lisp iterative development
strategy and apply it to social engineering. Everyone latches on to the
first, buggy iteration and everything gets all muddled. ;-)
> >> > I think they might well have failed if Larry and Sergey had tried
> >> > to write the original Google search engine using the CL
> >> > implementations available in 1998.
> >>
> >> Why? Don't you think they could have picked one implementation and
> >> run with it if they really wanted to? That they happened to by C++
> >> hackers rather than Lisp hackers seems to me an accident of
> >> history. A likely accident of history, of course, given the
> >> relative number of C++ programmers and Lisp programmers, but an
> >> accident none the less.
> >
> > Because to make Google work they had to optimize it very heavily. They
> > had to write a new file system for Linux. That alone would have been
> > impossible in Lisp.
>
> But who cares? Once they get to the point where they realize they need
> a new filesystem, that's a separate development effort from their main
> search algorithm/application. At least I assume so--the file system
> isn't intertwingled into their app is it? If they had started in Lisp
> and then realized that the existing file systems weren't performant
> enough or whatever they can do exactly what I assume they did--write a
> new filesystem in C and use it from their main app written in
> whatever.
I don't know how intertwingled it was (what a wonderful word!). I just
know that a lot of effort was put into optimizing disk access, that this
was crucial to performance, and that the run times were measured in days.
But you know, I could be wrong. If I am then there might be an
opportunity to compete with Google in e.g. the search appliance market.
Now, there's an idea.
rg
On Sat, 04 Feb 2006 15:49:27 -0800, Ron Garret <·········@flownet.com>
wrote:
>But you know, I could be wrong. If I am then there might be an
>opportunity to compete with Google in e.g. the search appliance market.
>Now, there's an idea.
The speed of the search is just one factor. Another is getting the
desired subset of results with the most concise query. Most search
queries result in long lists of results, most of them hardly relevant
to what is being sought by that search. Future search engines may
have sophisticated query languages, with different user skill levels,
like Dr. Scheme has different user skill levels of its Scheme
language. Still another factor is the completeness of the results.
E.g. how does Google get all the data from an ecommerce system for
everything being sold by it, when most of that data requires logging
in to that ecommerce system and doing local searches in it?
The problem with such a huge programming project is not that it needs
a lot of programmers but that it needs a lot of domain expertise. One
good Lisp programmer could implement all of Google, if he only had all
the right expertise to overcome all the technical obstacles such as
those mentioned above. But he's likely to spend years developing
better search algorithms etc. That's domain expertise, not
programming expertise.
A better way to organize such a project might be to have a group of
domain experts working with the one programmer, and each of the domain
experts does just enough programming to work with his domain,
prototyping, experimenting, etc. Lisp could be the medium for such
prototyping, which would be used for improving the expert's domain
knowledge and for sharing it with the group.
Given enough such domain knowledge among such a group of experts, the
bottleneck for development of the software is likely to be in the
inefficiency of communicating the domain knowledge to the programmer,
and making him understand it clearly enough. But that wouldn't be as
hard as sharing the programming work among multiple programmers. One
good programmer developing all the code works many times more
efficiently than a group of programmers developing the code together,
if you don't count domain knowledge as part of what the programmers
contribute.
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
> > Why? Don't you think they could have picked one implementation and run
> > with it if they really wanted to? That they happened to by C++ hackers
> > rather than Lisp hackers seems to me an accident of history. A likely
> > accident of history, of course, given the relative number of C++
> > programmers and Lisp programmers, but an accident none the less.
>
> Because to make Google work they had to optimize it very heavily. They
> had to write a new file system for Linux. That alone would have been
> impossible in Lisp.
It was impossible in C++ as well.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick schrieb:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@gigamonkeys.com>,
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> >
> > > Why? Don't you think they could have picked one implementation and run
> > > with it if they really wanted to? That they happened to by C++ hackers
> > > rather than Lisp hackers seems to me an accident of history. A likely
> > > accident of history, of course, given the relative number of C++
> > > programmers and Lisp programmers, but an accident none the less.
> >
> > Because to make Google work they had to optimize it very heavily. They
> > had to write a new file system for Linux. That alone would have been
> > impossible in Lisp.
>
> It was impossible in C++ as well.
You made me curious. Why was it impossible in C++ as well?
André
--
André Thieme wrote:
> Thomas F. Burdick schrieb:
>
> > Ron Garret <·········@flownet.com> writes:
> > > Because to make Google work they had to optimize it very heavily. They
> > > had to write a new file system for Linux. That alone would have been
> > > impossible in Lisp.
> >
> > It was impossible in C++ as well.
>
> You made me curious. Why was it impossible in C++ as well?
Karl Marx said so. It's all a big racist conspiracy.
From: =?utf-8?b?R2lzbGUgU8ODwqZsZW5zbWk=?= =?utf-8?b?bmRl?=
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <0nr76g179g.fsf@geitved.ii.uib.no>
"André Thieme" <······························@justmail.de> writes:
> Thomas F. Burdick schrieb:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <··············@gigamonkeys.com>,
> > > Peter Seibel <·····@gigamonkeys.com> wrote:
> > >
> > > > Why? Don't you think they could have picked one implementation and run
> > > > with it if they really wanted to? That they happened to by C++ hackers
> > > > rather than Lisp hackers seems to me an accident of history. A likely
> > > > accident of history, of course, given the relative number of C++
> > > > programmers and Lisp programmers, but an accident none the less.
> > >
> > > Because to make Google work they had to optimize it very heavily. They
> > > had to write a new file system for Linux. That alone would have been
> > > impossible in Lisp.
> >
> > It was impossible in C++ as well.
> > You made me curious. Why was it impossible in C++ as well?
>
It is indeed possible to write kernel modules for the linux kernel in
c++ as well as lisp, and in fact there has been written kernel modules
in c++ as well as scheme (that should be close enough to common lisp).
Both languages miss a runtime environment in the kernel, and that has
to be added, which would be a big enough effort in both cases that it
would be easier to just do the job in C.
For examples see:
http://netlab.ru.is/exception/LinuxCXX.shtml
http://www.abstractnonsense.com/schemix/
The first project is a research project, while the second is (was) a hobbyist
project, but they at least demonstrate that it is not impossible.
>
--
Gisle Sælensminde, Phd student, Scientific programmer
Computational biology unit, BCCS, University of Bergen, Norway,
Email: ·····@cbu.uib.no
The best way to travel is by means of imagination
"Andr� Thieme" <······························@justmail.de> writes:
> Thomas F. Burdick schrieb:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <··············@gigamonkeys.com>,
> > > Peter Seibel <·····@gigamonkeys.com> wrote:
> > >
> > > > Why? Don't you think they could have picked one implementation and run
> > > > with it if they really wanted to? That they happened to by C++ hackers
> > > > rather than Lisp hackers seems to me an accident of history. A likely
> > > > accident of history, of course, given the relative number of C++
> > > > programmers and Lisp programmers, but an accident none the less.
> > >
> > > Because to make Google work they had to optimize it very heavily. They
> > > had to write a new file system for Linux. That alone would have been
> > > impossible in Lisp.
> >
> > It was impossible in C++ as well.
>
> You made me curious. Why was it impossible in C++ as well?
Well, it's not really impossible, but it's just as impossible as doing
so in Lisp. The Linux kernel is written in C. Both Lisp and C++
require a runtime environment that the kernel doesn't provide -- of
course, you can build a kernel-friendly C++ or Lisp, but AFAIK neither
existed at the time. As a contrast, Darwin does support writing
drivers in C++ through its iokit rutime.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44rjr6F3a2jhU2@individual.net>
Thomas F. Burdick wrote:
> Well, it's not really impossible, but it's just as impossible as doing
> so in Lisp. The Linux kernel is written in C. Both Lisp and C++
> require a runtime environment that the kernel doesn't provide -- of
> course, you can build a kernel-friendly C++ or Lisp, but AFAIK neither
> existed at the time. As a contrast, Darwin does support writing
> drivers in C++ through its iokit rutime.
Why does C++ need a runtime? Everything of C++'s OOP is done by
translation to C structs and VMTs. The only thing that the language
requires (if you don't overload it) is malloc() for the "new" operator,
I'd say. You could say, even C needs a library then, if you want to use
utility functions you don't want to write yourself. But I'm open to
correction.
--
Suffering from Gates-induced brain leakage...
Ulrich Hobelmann wrote:
> Thomas F. Burdick wrote:
> > Well, it's not really impossible, but it's just as impossible as doing
> > so in Lisp. The Linux kernel is written in C. Both Lisp and C++
> > require a runtime environment that the kernel doesn't provide -- of
> > course, you can build a kernel-friendly C++ or Lisp, but AFAIK neither
> > existed at the time. As a contrast, Darwin does support writing
> > drivers in C++ through its iokit rutime.
>
> Why does C++ need a runtime? Everything of C++'s OOP is done by
> translation to C structs and VMTs. The only thing that the language
> requires (if you don't overload it) is malloc() for the "new" operator,
> I'd say. You could say, even C needs a library then, if you want to use
> utility functions you don't want to write yourself. But I'm open to
> correction.
>
> --
> Suffering from Gates-induced brain leakage...
It's hard to explain since English is not my native language.
But look at http://www.invalidsoftware.net/os/?the_id=11 for overview.
In short, things like exception, RTTI, and static object constructor
need runtime. you cannot just jump to an address of C++ function and
expect things to work.
From: Russell McManus
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87vevrjnte.fsf@cl-user.org>
Ulrich Hobelmann <···········@web.de> writes:
> Why does C++ need a runtime?
dynamic_cast<>. exceptions. rtti. prolly other stuff, too.
-russ
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44rqstF3k1mlU2@individual.net>
Russell McManus wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>> Why does C++ need a runtime?
>
> dynamic_cast<>. exceptions. rtti. prolly other stuff, too.
Ok, but I'm not sure what you'd need dynamic-cast or RTTI for in a
kernel. But exceptions? Well, one could probably provide the little
bit of library that it would take (probably just longjmp/setjmp)...
--
Suffering from Gates-induced brain leakage...
From: Russell McManus
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87r76fja8n.fsf@cl-user.org>
Ulrich Hobelmann <···········@web.de> writes:
> Ok, but I'm not sure what you'd need dynamic-cast or RTTI for in a
> kernel. But exceptions? Well, one could probably provide the little
> bit of library that it would take (probably just longjmp/setjmp)...
Nope, gotta run destructors.
-russ
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <u3biz8nsm.fsf@agharta.de>
On Sat, 04 Feb 2006 02:28:14 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> The necessary things were the maturity and native compilation.
Beep! Wrong.
Our referee Ron just told me that CL does /not/ compile to native code
because it's not in the standard and there is at least one
implementation that doesn't. So, please hand over your ranch.
Besides, you were missing the point anyway... :)
BTW, does C++ compile to native code? I'm not familiar with their
standard.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44jdgvF2g4tmU1@individual.net>
Edi Weitz wrote:
> BTW, does C++ compile to native code? I'm not familiar with their
> standard.
Not quite. Without a linker and a dynamic loader you can't run most C++
programs, I suppose.
But I don't know what's standard in C, and what's merely GNU or MS-VC++.
There's not much choice in C, at least unless you go embedded. There
you probably do get native code.
--
Suffering from Gates-induced brain leakage...
Ron Garret <·········@flownet.com> writes:
> Again, I think you're missing the point. The level of support available
> for Lisp is quite good from a hacker's point of view. It is not so good
> from a business point of view. There are many (dozens, perhaps
> hundreds) of companies providing contract services for Java, Visual
> Basic, or PHP. I don't know what the comparable number is for SBCL, but
> I'm pretty sure it's between zero and five, with zero being a strong
> possibility.
At least one is a stronger possibility:
Coming in 2006: Steel Bank Studio
http://random-state.net/log/3343480139.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Ron Garret <·········@flownet.com> writes:
> > The fact that some of those languages are
> > single-implementation languages doesn't really matter.
>
> Of course it matters. It removes a degree of freedom. It means, for
> example, that a library written for "Python" or "Ruby" or "Perl" is much
> more likely to work with *my* Python or Ruby or Perl (because there is
> only one) than a Lisp library is likely to work with my Lisp.
Is this just speculation on your part? Taking perl as an example,
there is a multitude of different perl versions, and even minor
revisions are incompatible with each other. There is not one single
Perl for anyone with a perl project older than a month[*]. Anyone who
chose to go with perl at some point in time has to deal with a
veritable version hell when upgrading, especially (but not limited to)
when using many libraries. And this is for a single implementation
language. CL implementations are stable enough that if you choose one,
you will very likely not have these kinds of problems over the next
five years.
So the truth is that the relative maturity of CL provides exactly what
you are looking for, and the new fast moving scripting languages is
the worst possible counter example you could have come up with.
[*] Ok, so Perl development is at a stand still, while everone awaits
the mythical "Perl 6". Perl 6 of course being completely
incompatible with any previous perl version.
Bj�rn
Björn Lindberg wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > > The fact that some of those languages are
> > > single-implementation languages doesn't really matter.
> >
> > Of course it matters. It removes a degree of freedom. It means, for
> > example, that a library written for "Python" or "Ruby" or "Perl" is much
> > more likely to work with *my* Python or Ruby or Perl (because there is
> > only one) than a Lisp library is likely to work with my Lisp.
>
> Is this just speculation on your part? Taking perl as an example,
> there is a multitude of different perl versions, and even minor
> revisions are incompatible with each other. There is not one single
> Perl for anyone with a perl project older than a month[*]. Anyone who
> chose to go with perl at some point in time has to deal with a
> veritable version hell when upgrading, especially (but not limited to)
> when using many libraries. And this is for a single implementation
> language.
Perl just happen to be the language that changed it's syntax too
frequently.
Python and Ruby is stable enough in that regards. Program writing for
Python 2.2 usually works with Python 2.4 as well as Ruby 1.6 and Ruby
1.8. There is some changes. And yes, in some case you would have to
edit code in order to get it working again.
But if you use Perl/Python/Ruby and get the project done faster than CL
because you don't have to spend time writing XML library, Flash
library, ODBC binding, solving threading problem, etc. Then you would
have money to hire a programmer to keep updating to compatibility
changes.
(Paul Graham said that using Lisp you can get your product out of the
door faster. But the advantage of CL only shines in Complex Algorithm
problem. How many of that kind of product is in the market? On the
other hand, how many product involve at least talking to the database
and using FFI? )
> CL implementations are stable enough that if you choose one,
> you will very likely not have these kinds of problems over the next
> five years.
>
But bitrot happens primarily not because of the language
syntax/semantic (those are infrequent). Bitrot happens because the
environment around it changes. No language can avoid that not even CL.
Show me a medium-sized CL application that runs in 1995 and can be run
now on SBCL 0.9.9 without any changes. Not the project that starts in
1995, it must be source code that last modified date is before 1995 and
taken as is to run on the system today.
> So the truth is that the relative maturity of CL provides exactly what
> you are looking for, and the new fast moving scripting languages is
> the worst possible counter example you could have come up with.
>
The truth is that standardization of CL is only about core function
that cannot even talk to the outside world. If you take only
defun/if/loop than syntax of those for Python/Perl/Ruby haven't
changed, either.
If you take into account the other library such as FFI or Socket which
are needed for an application to be useful. Then there is no advantage
in term of stability of API between CL or Python. There is always some
user visible changes noted in ReleaseNote every couple release of
CLISP/SBCL.
Now if both language equally suffer from having to maintain the code
and update to reflect the API changes in the library. Then which one
has more chance to stay alive and be supported after 5 years, a popular
library on c-l.net with around 100 of users and a less popular library
on Python with 5000+ users?
> [*] Ok, so Perl development is at a stand still, while everone awaits
> the mythical "Perl 6". Perl 6 of course being completely
> incompatible with any previous perl version.
>
>
> Björn
"Pisin Bootvong" <··········@gmail.com> writes:
> But if you use Perl/Python/Ruby and get the project done faster than CL
> because you don't have to spend time writing XML library, Flash
> library, ODBC binding, solving threading problem, etc. Then you would
> have money to hire a programmer to keep updating to compatibility
> changes.
I don't understand why/how you and others can seriously make this
claim. I have _never_ had an issue with this sort of thing and use
all of that stuff and a lot more. I have typically always used a
single implementation, but have indeed ported well over 90+% of two
applications to another implementation at one point because I wasn't
sure I would stick with the original. Most of the "porting" consisted
of simply compiling the code.
I find it hard to believe that others would have a lot of trouble in
this regard as well (either getting the libs and using them in some
implementation or porting to another). Maybe they would, but that
doesn't seem to be the general consensus here from people who are
actually doing work (as opposed to simply talking about it).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
"Pisin Bootvong" <··········@gmail.com> writes:
> Bj�rn Lindberg wrote:
> > Ron Garret <·········@flownet.com> writes:
> >
> > > > The fact that some of those languages are
> > > > single-implementation languages doesn't really matter.
> > >
> > > Of course it matters. It removes a degree of freedom. It means, for
> > > example, that a library written for "Python" or "Ruby" or "Perl" is much
> > > more likely to work with *my* Python or Ruby or Perl (because there is
> > > only one) than a Lisp library is likely to work with my Lisp.
> >
> > Is this just speculation on your part? Taking perl as an example,
> > there is a multitude of different perl versions, and even minor
> > revisions are incompatible with each other. There is not one single
> > Perl for anyone with a perl project older than a month[*]. Anyone who
> > chose to go with perl at some point in time has to deal with a
> > veritable version hell when upgrading, especially (but not limited to)
> > when using many libraries. And this is for a single implementation
> > language.
>
> Perl just happen to be the language that changed it's syntax too
> frequently.
Python does too.
> Python and Ruby is stable enough in that regards. Program writing for
> Python 2.2 usually works with Python 2.4 as well as Ruby 1.6 and Ruby
> 1.8. There is some changes. And yes, in some case you would have to
> edit code in order to get it working again.
How about Python 1.5? 2.0?
> But if you use Perl/Python/Ruby and get the project done faster than CL
> because you don't have to spend time writing XML library, Flash
> library, ODBC binding, solving threading problem, etc. Then you would
> have money to hire a programmer to keep updating to compatibility
> changes.
Not that I think that you didn't just write up a list of what you
first came to think of rather than choosing good examples, but CL
certainly has usable XML libraries and DB bindings
available. Threading too.
> (Paul Graham said that using Lisp you can get your product out of the
> door faster. But the advantage of CL only shines in Complex Algorithm
> problem. How many of that kind of product is in the market? On the
> other hand, how many product involve at least talking to the database
> and using FFI? )
(Answering the last question:) Many. What do you need an FFI for?
> > CL implementations are stable enough that if you choose one,
> > you will very likely not have these kinds of problems over the next
> > five years.
> >
>
> But bitrot happens primarily not because of the language
> syntax/semantic (those are infrequent). Bitrot happens because the
> environment around it changes. No language can avoid that not even CL.
> Show me a medium-sized CL application that runs in 1995 and can be run
> now on SBCL 0.9.9 without any changes. Not the project that starts in
> 1995, it must be source code that last modified date is before 1995 and
> taken as is to run on the system today.
Show /me/ the equivalent program in Perl/Python/Ruby. In fact, finding
one last modified in 2000 would be good enough for me.
> > So the truth is that the relative maturity of CL provides exactly what
> > you are looking for, and the new fast moving scripting languages is
> > the worst possible counter example you could have come up with.
> >
>
> The truth is that standardization of CL is only about core function
> that cannot even talk to the outside world. If you take only
> defun/if/loop than syntax of those for Python/Perl/Ruby haven't
> changed, either.
Yes, they have.
> If you take into account the other library such as FFI or Socket which
> are needed for an application to be useful. Then there is no advantage
> in term of stability of API between CL or Python. There is always some
> user visible changes noted in ReleaseNote every couple release of
> CLISP/SBCL.
>
> Now if both language equally suffer from having to maintain the code
> and update to reflect the API changes in the library. Then which one
> has more chance to stay alive and be supported after 5 years, a popular
> library on c-l.net with around 100 of users and a less popular library
> on Python with 5000+ users?
I don't know, but I do know that when I was writing something in
Python I found several cases where among the Python standard libraries
there were both a new and an old deprecated library for doing the same
thing. Mutually incompatible, of course.
Bj�rn
Björn Lindberg wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
> >
> > But bitrot happens primarily not because of the language
> > syntax/semantic (those are infrequent). Bitrot happens because the
> > environment around it changes. No language can avoid that not even CL.
> > Show me a medium-sized CL application that runs in 1995 and can be run
> > now on SBCL 0.9.9 without any changes. Not the project that starts in
> > 1995, it must be source code that last modified date is before 1995 and
> > taken as is to run on the system today.
>
> Show /me/ the equivalent program in Perl/Python/Ruby. In fact, finding
> one last modified in 2000 would be good enough for me.
>
You're missing the point. I'm not trying to say that Program written in
Python/Ruby will not get bitrotten after five years. What I'm saying is
that "Program in Python/Ruby/Perl do get bitrot, but SO DOES CL" So is
it that much advantage of "Stable language core" over "Fast moving
scripting laguage + fast moving library" when with both language you
have to do maintenant nontheless?
You program with CL stable core, but don't you have to use/write
library?
What's the guarantee of stability of CMUCL/CLISP/SBCL 's socket API and
how is that different from Python?
What's the guarantee that Gray Stream will still be used now that Franz
have introduced Simple Stream and Edi's Flexistream is useful in
practice?
Don't you have to work around deficiency/non-compilant of the
implementation you are using?
Don't you have to fix your code when that work around is not needed any
more? Is there any magic in CL that will make API of thounsands of CL
library developed by thoundsands of people around the world stable over
ten years?
I agree that of itself CL the language is the superior language to
Python/Perl. But having only minimal core standard is not one of the
advantage.
> >
> > Now if both language equally suffer from having to maintain the code
> > and update to reflect the API changes in the library. Then which one
> > has more chance to stay alive and be supported after 5 years, a popular
> > library on c-l.net with around 100 of users and a less popular library
> > on Python with 5000+ users?
>
> I don't know, but I do know that when I was writing something in
> Python I found several cases where among the Python standard libraries
> there were both a new and an old deprecated library for doing the same
> thing. Mutually incompatible, of course.
>
And you would prefer written all of that yourself from scratch, of
course.
By the way, I'm not fond of calling Python/Ruby "Scripting Language".
It kinda gives them low credit a little bit. They are structured
languaged, there's nothing in the language itself that prevent it from
being used to implement a large system. The fact that it runs on
interpreter doesn't have anything to do with the language (CL is not
scripting language just because CLISP is interpreter). If "Scripting
language" means being able to implement some little utility fast then
it's a good thing, and there's nothing that claims that language that
can be use to solve easy problem fast cannot be used to solve hard
problem, too.
"Pisin Bootvong" <··········@gmail.com> writes:
> Bj�rn Lindberg wrote:
> > "Pisin Bootvong" <··········@gmail.com> writes:
> > >
> > > But bitrot happens primarily not because of the language
> > > syntax/semantic (those are infrequent). Bitrot happens because the
> > > environment around it changes. No language can avoid that not even CL.
> > > Show me a medium-sized CL application that runs in 1995 and can be run
> > > now on SBCL 0.9.9 without any changes. Not the project that starts in
> > > 1995, it must be source code that last modified date is before 1995 and
> > > taken as is to run on the system today.
> >
> > Show /me/ the equivalent program in Perl/Python/Ruby. In fact, finding
> > one last modified in 2000 would be good enough for me.
> >
>
> You're missing the point. I'm not trying to say that Program written in
> Python/Ruby will not get bitrotten after five years. What I'm saying is
> that "Program in Python/Ruby/Perl do get bitrot, but SO DOES CL" So is
> it that much advantage of "Stable language core" over "Fast moving
> scripting laguage + fast moving library" when with both language you
> have to do maintenant nontheless?
So, basically you admit to holding CL to a much higher standard than
the other languages. That is certainly a valid position, but not how
this discussion was characterized in the first place.
Bj�rn
From: Stefan Nobis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87r76fzc4z.fsf@snobis.de>
"Pisin Bootvong" <··········@gmail.com> writes:
> You program with CL stable core, but don't you have to use/write
> library?
Yes, but in CL people are more aware of differences. It's about the
same as Windows vs Unix: WinNT and newer has a sound base. But all
those app-writers don't recognise. What's your fine grained rights
management worth, if most important app only run(!) with
administration pivileges?
The same with Java, Perl and Co. All think "hey, there's only one
implementation -- just write for it and everything works". In the CL
world there it's more like "uh, this may not run on all
implementations, let's check."
So yes, CL libs *tend* to be more stable and less prone to bitrot than
Perl, Python or Java libs. At least I see a bonus on the lisp side;
no technical reason, but one of perception and attitude.
--
Stefan.
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44rk0rF3a2jhU3@individual.net>
Stefan Nobis wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
>
>> You program with CL stable core, but don't you have to use/write
>> library?
>
> Yes, but in CL people are more aware of differences. It's about the
> same as Windows vs Unix: WinNT and newer has a sound base. But all
> those app-writers don't recognise. What's your fine grained rights
> management worth, if most important app only run(!) with
> administration pivileges?
>
> The same with Java, Perl and Co. All think "hey, there's only one
> implementation -- just write for it and everything works". In the CL
> world there it's more like "uh, this may not run on all
> implementations, let's check."
These two paragraphs sound as if you consider the wide similarity but
non-equality of Unices and the existence of huge, bloated configure
scripts a good thing. ;)
I think Lisp needs both: the diversity of implementations, but also the
strong standard base in the background. Otherwise we'd end up in
Unix/configure or Scheme hell.
--
Suffering from Gates-induced brain leakage...
"Pisin Bootvong" <··········@gmail.com> writes:
> Now if both language equally suffer from having to maintain the code
> and update to reflect the API changes in the library. Then which one
> has more chance to stay alive and be supported after 5 years, a popular
> library on c-l.net with around 100 of users and a less popular library
> on Python with 5000+ users?
The CL library, because the 5000 Python users will have moved to using
another new cool and fashionable library, while the Lispers cultivate
their gems :)
Jorg Hohle
Telekom/T-Systems Technology Center
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uu0bc7l7e.fsf@agharta.de>
On 06 Feb 2006 11:47:31 +0100, ·····@runa.se (Bj�rn Lindberg) wrote:
> Taking perl as an example, there is a multitude of different perl
> versions, and even minor revisions are incompatible with each
> other. There is not one single Perl for anyone with a perl project
> older than a month[*]. Anyone who chose to go with perl at some
> point in time has to deal with a veritable version hell when
> upgrading, especially (but not limited to) when using many
> libraries. And this is for a single implementation language.
<AOL>
I can confirm that.
</AOL>
> CL implementations are stable enough that if you choose one, you
> will very likely not have these kinds of problems over the next five
> years.
There are exceptions, though, like SBCL. But this is an
implementation under heavy development and the developers are quite
frank about their disposition to break backwards-compatibility if
needed.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
·····@runa.se (Björn Lindberg) writes:
> Ron Garret <·········@flownet.com> writes:
>
> > > The fact that some of those languages are
> > > single-implementation languages doesn't really matter.
> >
> > Of course it matters. It removes a degree of freedom. It means, for
> > example, that a library written for "Python" or "Ruby" or "Perl" is much
> > more likely to work with *my* Python or Ruby or Perl (because there is
> > only one) than a Lisp library is likely to work with my Lisp.
>
> Is this just speculation on your part? Taking perl as an example,
> there is a multitude of different perl versions, and even minor
> revisions are incompatible with each other. There is not one single
> Perl for anyone with a perl project older than a month[*]. Anyone who
> chose to go with perl at some point in time has to deal with a
> veritable version hell when upgrading, especially (but not limited to)
> when using many libraries. And this is for a single implementation
> language. CL implementations are stable enough that if you choose one,
> you will very likely not have these kinds of problems over the next
> five years.
>
> So the truth is that the relative maturity of CL provides exactly what
> you are looking for, and the new fast moving scripting languages is
> the worst possible counter example you could have come up with.
>
> [*] Ok, so Perl development is at a stand still, while everone awaits
> the mythical "Perl 6". Perl 6 of course being completely
> incompatible with any previous perl version.
>
Yes, I really don't know where this perspective that there is "one
version f perl" comes from - even O'Reilly has books on programming
perl and programming perl on 32 bit windows.
When I was managing a data centre, one of the biggest hassles we had
was with perl and java and the number of versions we had to
run. Vendor's have become so frustrated with the various versions of
perl and java, they now ship with their own versions and will not
provide any support unless you are runnig the specific version they
release with. It is common to see 3+ versions of perl and even more
versions of java on a single server. this is often a nightmare as they
commonly expect to be installed in standard locations, which you
cannot do as they connflict, so you have to constantly maintain
various environment variable settings, classpaths so long printing
them fills a whole screen, multiple perl modules - all similar, but
compatible with only specific perl versions and then you get the
update/security fix maintenance nightmare. I'm not sure what the
situation is with Python, but I do notice that my Debian distribution
disks do come with at least 3 different versions of Python, so you
have to wonder....
Anyone who claims perl et. al. has a major advantage over Cl because
it is a 'single implementation' probably
hasn't had to maintain multiple packages which rely on them or they
would realise they are not "one version/implementation" in reality.
Of course, I see this as a different issue from the ones regarding
standardised libraries for sockets, ffi, etc. Personally, if these are
so critical to someone, I would suggest they stop moaning and
implement them.
Alternatively, pick a single CL implementation which runs on the
platforms your interested in and use the implementation specific
extensions. I don't understand why everyone expects all CL
implementations to be able to do everything - while this would be
nice, I've yet to see a language that really allows this in
practice. If you feel Java can do that, then I think you may not have
much experience maintaining java code for multiple platforms - its not
as simple as the hype would have you believe.
We should strive for a truely platform independent implementation of a
language, but I don't feel we should be surprised when the reality
doesn't quite cut it. I also don't think this is what is preventing CL
from becoming more mainstream. The most common objections to CL I come
across in the wider IT world is mainly FUD based on all the
misconceptions we are very familiar with (i.e. it is only functional,
cannot be applied to procedural problems, is slow, is for AI only, is
old and therefore no good, has too many parens, is slow to develop in
etc) plus the fear of not being able to get good experienced
programmers. I'm not sure how valid this last one is, but I would have
to say from my own experience, CL is more fun to use than any language
I've progrmmed in for a long time and it was very quick to learn, but
mastering the language is a long slow (but rewarding) path. Of course,
I don't know if a CL programmer with minimal experience is worse or
better than a Java programmer with medium level experience.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Wade Humeniuk wrote:
> 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.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447ndiFrkkrU1@individual.net>
Wade Humeniuk wrote:
> Ron Garret wrote:
>
>>
>> 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?
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
Tin Gherdanarra schrieb:
> 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.
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é
--
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447poqFr1ncU1@individual.net>
Andr� Thieme wrote:
> Tin Gherdanarra schrieb:
>
>
>>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.
>
>
>
> 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 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�
> --
>
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uhd7lxnxz.fsf@agharta.de>
On Tue, 31 Jan 2006 00:57:32 +0100, Tin Gherdanarra <···········@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.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447oceFqnbuU1@individual.net>
Edi Weitz wrote:
> On Tue, 31 Jan 2006 00:57:32 +0100, Tin Gherdanarra <···········@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.
>
Tin Gherdanarra wrote, over and over again,:
> import sockets
> in python.
...
> import sockets
> in python.
...
> import sockets
> in python.
...
> import sockets
> in python.
Just for the record:
| $ python
| Python 2.4.2 (#2, Oct 4 2005, 04:32:21)
| [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
| Type "help", "copyright", "credits" or "license" for more information.
| >>> import sockets
| Traceback (most recent call last):
| File "<stdin>", line 1, in ?
| ImportError: No module named sockets
| >>>
Admittedly that isn't quite fair, because "import socket"
works just fine :-), but I thought it was amusing; apparently
even "import socket" can be too difficult to get right :-).
--
Gareth McCaughan
.sig under construc
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44bpg4Flv7dU1@individual.net>
Gareth McCaughan wrote:
> Tin Gherdanarra wrote, over and over again,:
>
>
>> import sockets
>> in python.
>
> ...
>
>> import sockets
>> in python.
>
> ...
>
>> import sockets
>> in python.
>
> ...
>
>> import sockets
>> in python.
>
>
> Just for the record:
>
> | $ python
> | Python 2.4.2 (#2, Oct 4 2005, 04:32:21)
> | [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
> | Type "help", "copyright", "credits" or "license" for more information.
> | >>> import sockets
> | Traceback (most recent call last):
> | File "<stdin>", line 1, in ?
> | ImportError: No module named sockets
> | >>>
>
> Admittedly that isn't quite fair, because "import socket"
> works just fine :-), but I thought it was amusing; apparently
> even "import socket" can be too difficult to get right :-).
It was a typo. It was late in the night.
And I don't have a compiler in my e-mail window.
Such things happen. Its embarrassing, all right,
but it does not change the fact common lisp
provides all sorts of slightly incompatible
socket modules.
>
Tin Gherdanarra <···········@gmail.com> writes:
> And I don't have a compiler in my e-mail window.
Try Gnus. It comes batteries included.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44brqpF1ef1gU1@individual.net>
Paolo Amoroso wrote:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>
>>And I don't have a compiler in my e-mail window.
>
>
> Try Gnus. It comes batteries included.
I'm not following you. Gnu Lisp?
>
>
> Paolo
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uek2n9p04.fsf@agharta.de>
On Wed, 01 Feb 2006 14:37:23 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
>> Try Gnus. It comes batteries included.
>
> I'm not following you. Gnu Lisp?
<http://justfuckinggoogleit.com/search?q=gnus>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44d34kF1kaunU2@individual.net>
Edi Weitz wrote:
> On Wed, 01 Feb 2006 14:37:23 +0100, Tin Gherdanarra <···········@gmail.com> wrote:
>
>
>>>Try Gnus. It comes batteries included.
>>
>>I'm not following you. Gnu Lisp?
>
>
> <http://justfuckinggoogleit.com/search?q=gnus>
>
I'm sorry for asking the above question, but I
got a little impatient over all the replies in this
thread. So many flames, so little time...
On 2006-02-01 19:48:14 -0500, Tin Gherdanarra <···········@gmail.com> said:
> I'm sorry for asking the above question, but I
> got a little impatient over all the replies in this
> thread. So many flames
Flamebait will do that.
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44dcs6F1ju7cU2@individual.net>
Raffael Cavallaro wrote:
> On 2006-02-01 19:48:14 -0500, Tin Gherdanarra <···········@gmail.com> said:
>
>> I'm sorry for asking the above question, but I
>> got a little impatient over all the replies in this
>> thread. So many flames
>
>
> Flamebait will do that.
>
It was not meant to be flamebait, honestly. I just
walked in asking... you what... and all of sudden
everybody reproached on me all sorts of things. By
replying to all those sorts of things, things got
worse and worse. Fortunately, some pockets of
civilized conversation have showed up in this thread
and I really appreciate this. I mean, do trolls
appreciate pockets of civilized conversation?
From: Peder O. Klingenberg
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <ksoe1rgpo2.fsf@beto.netfonds.no>
Tin Gherdanarra <···········@gmail.com> writes:
> Paolo Amoroso wrote:
>> Tin Gherdanarra <···········@gmail.com> writes:
>>
>>>And I don't have a compiler in my e-mail window.
>> Try Gnus. It comes batteries included.
>
> I'm not following you. Gnu Lisp?
Gnus. See for instance http://my.gnus.org/
A mail/newsreader that runs inside emacs. Since many decent compilers
also run inside emacs, it can provide you with something very close to
"a compiler in your email window".
...Peder...
--
It's not called hacking or trial and error!
It's called rapid prototyping and extreme programming.
- Kristoffer Gleditsch
Ron Garret <·········@flownet.com> writes:
> 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
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447lq9Fq0riU1@individual.net>
Cameron MacKinnon wrote:
> 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.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Cameron MacKinnon wrote:
>
>> 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.
I definitely think things are improving for Lisp, in general. There are
more blogs, videos and documents, packages, wiki content, newbies keep
showing up, and version numbers keep incrementing.
But newbies continue to arrive asking about sockets code, XML, threads
etcetera. As far as I know, there's no effort being made to standardize
this infrastructure. Instead, c.l.l has developed a complete grammar
that it uses to interact with these newbies, e.g.:
"C doesn't standardize that either"
"it isn't fair to compare CL to a single implementation language"
"that's vendor specific"
"there's a few packages that abstract over those incompatibilities.
Pick one, or write your own."
A newbie shows up, whoever is online and feels like fielding the
question answers with one of the stock, non-answer responses, and more
regulars use more responses if the newbie is particularly stubborn.
Meanwhile, the old hands think to themselves (pure speculation on my part):
"Why couldn't this guy have Googled a bit more to find the answer?"
"I solved this problem when I was starting out, why can't he?"
"He's probably a whiner, looking for excuses not to code"
"Lisp isn't for the masses, it's for the elite, and this guy is
self-classifying"
A customer focused group would recognize that prospects showing up with
the same concerns represent, at minimum, a documentation problem, and
probably a legitimate demand for change. In other words, is this a
legitimate question, and what can we do so that the next newbie doesn't
have to ask? I don't see people admitting to that here. In fact, your
comment above, referring to ACTUAL, CONCRETE problems seems to imply the
usual -- that this isn't a problem, notwithstanding countless newbies
who say it is. And don't forget the multiplier: One newbie who posts
usually represents several who couldn't be bothered or gave up, blaming
the language for having insufficient infrastructure.
I would be remiss if I didn't mention LispBox/Lisp in a box. I don't
think it's the solution to the problem, but (as I understand it, I'm not
a user) it's a helpful aid to the newbie who rightly feels (or would, if
he'd gotten that far) that investigating and integrating multiple
complex packages using unfamiliar build tools just to get Lisp
infrastructure off the ground shouldn't be necessary.
I really don't want to argue this all over again. I've no new points to
make, and things haven't changed since the last time I argued it. But I
won't let the NG come to a smug, wrong consensus that there's no problem
despite continuing evidence to the contrary.
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44ae72F17212U1@individual.net>
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Cameron MacKinnon wrote:
>>
>>> 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.
>
> I definitely think things are improving for Lisp, in general. There are
> more blogs, videos and documents, packages, wiki content, newbies keep
> showing up, and version numbers keep incrementing.
...and I would add that these developments definitely also have a
customer-focused feel.
> But newbies continue to arrive asking about sockets code, XML, threads
> etcetera. As far as I know, there's no effort being made to standardize
> this infrastructure. Instead, c.l.l has developed a complete grammar
> that it uses to interact with these newbies, e.g.:
> "C doesn't standardize that either"
> "it isn't fair to compare CL to a single implementation language"
> "that's vendor specific"
> "there's a few packages that abstract over those incompatibilities.
> Pick one, or write your own."
This is not a fair characterization of what happened in this thread. The
OP hasn't stated anything that even resembles a concrete question. When
the OP later concretized the question, it was again far from being about
a specific technical problem.
I think it is rather a fair characterization that specific technical
questions are answered rather promptly and to the point. Yes, it would
be good if the infrastructure would be better in general, but this takes
time. Until then, it's just honest to tell people that certain things
require more effort than in other, more widely used languages.
Please also keep in mind that certain statements are simply insults
toward the people who invest their valuable time to work on improving
the infrastructure. I don't think it's so clear cut why they should bear
more than the people who just make wild claims about the supposedly bad
state of affairs. Those who seriously try to get things done seem to
typically succeed in doing so. It should be acceptable to mention this
as well.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Cameron MacKinnon wrote:
>> Instead, c.l.l has developed a
>> complete grammar that it uses to interact with these newbies, e.g.:
[BNF elided]
>
> This is not a fair characterization of what happened in this thread.
It was meant to be a composite of what generally happens in threads like
this. Most of it has happened in this thread already, and the rest is
probably inevitable. It doesn't even matter how specific the OP was in
his question, because this group acts like a statistical classifier, and
once the OP's point was found to be closer to "lack of infrastructure
sucks" than to any other common topic, the response was reflexive.
> The OP [...]
I'm not going to defend the OT. I'm somewhat miffed at myself for not
noticing his 31337 email in the first place, but the angelfire reference
did it. It's funny he calls himself the Tinman, as he certainly seems to
have courage when it comes to brassing off the tall foreheads in this
group. I'd liken him more to the Scarecrow.
> Those who seriously try to get things done seem to
> typically succeed in doing so.
Where's your data? Some people succeed, some walk away from Lisp shaking
their heads at our intransigence (perhaps never having posted here), and
some sign off with a big "you guys suck."
Since most people wouldn't bother with the final flame, and since we
have no way of counting those too apathetic or self-reliant to post
asking for help, I don't even have enough data to make a
wild-assed-guess of what % of people who try Lisp end up using another
language.
A Big Shout out to all the people working to make things better, since I
apparently haven't been doing enough of that.
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44b8asF1a95mU1@individual.net>
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Cameron MacKinnon wrote:
>>
>>> Instead, c.l.l has developed a complete grammar that it uses to
>>> interact with these newbies, e.g.:
>
> [BNF elided]
>
>>
>> This is not a fair characterization of what happened in this thread.
>
> It was meant to be a composite of what generally happens in threads like
> this. Most of it has happened in this thread already, and the rest is
> probably inevitable. It doesn't even matter how specific the OP was in
> his question, [...]
I disagree. It does matter.
>> Those who seriously try to get things done seem to typically succeed
>> in doing so.
>
> Where's your data? Some people succeed, some walk away from Lisp shaking
> their heads at our intransigence (perhaps never having posted here), and
> some sign off with a big "you guys suck."
I don't have such data, but you don't have it either. However, it is
recognizable that a considerable number of people stay and use Lisp to
their advantage, and they are probably also representative of a larger
crowd of people who never post here. (It works both ways, you know. ;)
It's really important to understand such statements given the current
state: Yes, the infrastructure is not ideal, but there are still enough
people who succeed to get things done. So it is definitely not
impossible to use Lisp. The glass is not half empty, the glass is half
full. And, as Paolo Amoroso has stated so well, it takes people to
further fill that glass, and it _is_ being filled. However, those who
want everything served on a silver plate without investing their own
time and work will still have to wait for a few years, unfortunately. If
people like the OP cannot deal with this, they are in the wrong spot at
this moment in time. It's a very simple fact that noone can change this
over night.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Cameron MacKinnon wrote:
>
>> Where's your data? Some people succeed, some walk away from Lisp
> I don't have such data, but you don't have it either.
I just thought of a public source of counts of a fraction of the people
who try, to a first approximation:
http://sourceforge.net/project/showfiles.php?group_id=1355
The methodology leaves something to be desired (I can almost come up
with enough free parameters to fit the proverbial elephant), but it's
better than nothing, and less brazen than asking the vendors how many
free downloads and sales they're seeing, ha ha.
Centrally counting downloads like this could really be a useful source
of info (mainly in the trends rather than the raw numbers) for the
community, especially for common packages like SLIME and ACL-COMPAT.
And page view stats, maybe?
Cameron MacKinnon <··········@clearspot.net> writes:
[ snipey back-and-forth with Pascal snipped ]
That's not what I expected from the subject line. I have to admit, I
was hoping it was going to be a discussion of which Lispniks group has
the most noses in units of cm^3 month^-1.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Cameron MacKinnon wrote:
>>
>>> Where's your data? Some people succeed, some walk away from Lisp
>
>> I don't have such data, but you don't have it either.
>
> I just thought of a public source of counts of a fraction of the people
> who try, to a first approximation:
>
> http://sourceforge.net/project/showfiles.php?group_id=1355
>
> The methodology leaves something to be desired (I can almost come up
> with enough free parameters to fit the proverbial elephant), but it's
> better than nothing, and less brazen than asking the vendors how many
> free downloads and sales they're seeing, ha ha.
>
> Centrally counting downloads like this could really be a useful source
> of info (mainly in the trends rather than the raw numbers) for the
> community, especially for common packages like SLIME and ACL-COMPAT.
> And page view stats, maybe?
I don't get it. (This is not a rhetorical statement, I really don't get
it.) What does the number of downloads of one particular CL
implementation tell us?
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Cameron MacKinnon <··········@clearspot.net> writes:
> I just thought of a public source of counts of a fraction of the
> people who try, to a first approximation:
>
> http://sourceforge.net/project/showfiles.php?group_id=1355
[...]
> And page view stats, maybe?
See also:
http://common-lisp.net/stats.shtml
Incidentally, it's amazing how few Lispers subscribe to the
Common-Lisp.net admin mailing list or RSS feed, which provide
interesting updates--and a steady breeze of new project creation
requests and announcements.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Cameron MacKinnon <··········@clearspot.net> writes:
> I just thought of a public source of counts of a fraction of the people
> who try, to a first approximation:
> http://sourceforge.net/project/showfiles.php?group_id=1355
I believe this is instead at most an approximation of the number of
downloads from sourceforge per time unit.
How else would you explain that clisp-2.35-win32 has roughly 10 times
the number of downloads of clisp-2.38-win32? It's probably just that
it's been around longer: download/release-period.
Something else could explain the lower UNIX or source rates. I never
downloaded CLISP there. I either got a CVS tarball (count not shown)
and/or installed clisp via the Linux' distribution mechanism
(e.g. Suse or Debian packages, also not shown). That's a behaviour
I'd expect more from UNIX people than users of MS-Windows.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44dkfkF193n9U1@individual.net>
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Cameron MacKinnon wrote:
>>
>>> Instead, c.l.l has developed a complete grammar that it uses to
>>> interact with these newbies, e.g.:
>
> [BNF elided]
>
>>
>> This is not a fair characterization of what happened in this thread.
>
>
> It was meant to be a composite of what generally happens in threads like
> this. Most of it has happened in this thread already, and the rest is
> probably inevitable. It doesn't even matter how specific the OP was in
> his question, because this group acts like a statistical classifier, and
> once the OP's point was found to be closer to "lack of infrastructure
> sucks" than to any other common topic, the response was reflexive.
It actually started with "lack of infrastructure is bad for Lisp"
on my part. The reflexive response was to allege that I said
"lack of infrastructure sucks". And, the O in OT should mean
an entirely different question on if there is any noticible
influence of Paul Graham's "Beating the averages".
Somehow I feel like a guy walking into a family convention where
everybody has just been talking - as always - about that boozily
arsehole Larry-dude. Asking how boozily arsehole Larry-dude is
doing, I learned that it's UNCLE arsehole Larry-dude, so everybody
got made at me and outraged. "How dare you". I could not know
this.
>
>> The OP [...]
>
>
> I'm not going to defend the OT. I'm somewhat miffed at myself for not
> noticing his 31337 email in the first place, but the angelfire reference
> did it.
This makes me laugh. I have to admit, 31337 looks a little silly,
but I figured it's been a long time since it was pseudo-cool in
h4Xor-circles, so I was not in danger of being considered pseudo-cool,
merely pseudo-ironic on my own expense. Besides that, "tinman"
was taken already on gmail, so I had to improvise a sufficiently
large number. 31337 is a prime and easy to remember, so "why not?"
Now I know why not, but it is too late.
As for angelfire, this looks silly too, but I had to improvise
again, and this was the only free webspace-site I vaguely remembered
from the bubble.
> It's funny he calls himself the Tinman, as he certainly seems to
> have courage when it comes to brassing off the tall foreheads in this
> group. I'd liken him more to the Scarecrow.
"Scare" is not my firstname, so I did not get the idea.
>
>
>> Those who seriously try to get things done seem to typically succeed
>> in doing so.
I'm glad to hear that.
>
> Where's your data? Some people succeed, some walk away from Lisp shaking
> their heads at our intransigence (perhaps never having posted here), and
> some sign off with a big "you guys suck."
>
"c.l.l. sucks" is different from "Lisp sucks". I've seen a handful
of blogs complaining about you guys being elitist intellectual
snobs, by the way. I'm not making this up. I can't remember where
I've seen those but maybe you take my word for it. Don't be offended,
elitist intellectual snobs are good company. Most of my friends
are elitist intellectual snobs.
> Since most people wouldn't bother with the final flame, and since we
> have no way of counting those too apathetic or self-reliant to post
> asking for help, I don't even have enough data to make a
> wild-assed-guess of what % of people who try Lisp end up using another
> language.
My guess is: Every reader of reddit, every other Emacs-user,
every reader of slashdot.
Add to those every other college student of computer science
and every halfway advanced AutoCAD-user. That's probably a few
million people.
>
>
> A Big Shout out to all the people working to make things better, since I
> apparently haven't been doing enough of that.
This is a trifle problematic, for the following reason.
Using some snippet of code is usually harder than writing
that snippet of code. Before a newbie can become proficient
enough in Lisp to contribute something good he has to
practice for a while. This while might be years, and for
all those years there must be a good incentive to stay the
course. Good incentives for staying the course are things
newbies like to do with a language, and those things are
precisely what Lisp lacks in a way a newbie can use in
a newbie way -- web programming, scripting and
database connectivity are probably the most important today.
On these terrains Lisp competes with all sorts of
programming languages, most of them start with "p".
I understand that Lisp has a long tradition in various
fields like artificial intelligence, controlling spacecraft,
number theory, etc. but these are not of much attractiveness
for newbies. You could resort to the view that Lisp is
an advanced tool for advanced people. The problem is: it
does not work this way, as O'Reilly has discovered that /perl/
is a big hit in data mining and bio-informatics circles
(genetics is datamining in disguise). It is pure speculation,
but methinks those bio-dudes and dataminers picked perl
for their stuff because it served them so well when they
were teenagers trying to write an echo-server with sockets.
Lisp could *own* bio-informatics or datamining because both
requires a powerful flexible language. What's more: datamining or
bioinformatics probably don't require sockets, regular expressions
or webservers, so you would think that Lisp's lack
of infrastructure would not matter to bio-informaticist
or dataminers.
However, it DOES matter because the bio-informaticists and
data-miners remember their pet p-languages so fondly from
the days when they showed off their first echo-server to
their geek-pals. Can you blame them if they pick perl over
Lisp? For them it's probably a matter of loyalty and trust.
This is where the newbies come into play: Newbies grow up,
and then they vote.
Cameron MacKinnon <··········@clearspot.net> writes:
> But newbies continue to arrive asking about sockets code, XML, threads
> etcetera. As far as I know, there's no effort being made to
> standardize this infrastructure. Instead, c.l.l has developed a
Socket API Analysis
http://www.findinglisp.com/blog/2005/12/socket-api-analysis.html
Reddit and Lisp psychosis
http://www.findinglisp.com/blog/2005/12/reddit-and-lisp-psychosis.html
Portable Threads
http://wiki.alu.org/Portable_Threads
> Meanwhile, the old hands think to themselves (pure speculation on my part):
> "Why couldn't this guy have Googled a bit more to find the answer?"
Another option: the old--and new-- put together a web site that
collects/organizes all known Common Lisp resources, so that novices
don't have to wade through raw Google results:
The Common Lisp Directory
http://www.cl-user.net
> A customer focused group would recognize that prospects showing up
> with the same concerns represent, at minimum, a documentation problem,
> and probably a legitimate demand for change. In other words, is this a
CL Gardeners - Tending the Common Lisp garden
http://www.lispniks.com/cl-gardeners/
> legitimate question, and what can we do so that the next newbie
> doesn't have to ask? I don't see people admitting to that here. In
For the record, the idea for the above project started here in
comp.lang.lisp.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso <·······@mclink.it> writes:
> Cameron MacKinnon <··········@clearspot.net> writes:
[...]
>> Meanwhile, the old hands think to themselves (pure speculation on my part):
>> "Why couldn't this guy have Googled a bit more to find the answer?"
>
> Another option: the old--and new-- put together a web site that
I meant "the old--and new--hands put together [...]".
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44db0oF1kkobU1@individual.net>
snip
> I definitely think things are improving for Lisp, in general. There are
> more blogs, videos and documents, packages, wiki content, newbies keep
> showing up, and version numbers keep incrementing.
I like hearing this, thanks.
>
> But newbies continue to arrive asking about sockets code, XML, threads
> etcetera. As far as I know, there's no effort being made to standardize
> this infrastructure. Instead, c.l.l has developed a complete grammar
> that it uses to interact with these newbies, e.g.:
> "C doesn't standardize that either"
> "it isn't fair to compare CL to a single implementation language"
> "that's vendor specific"
> "there's a few packages that abstract over those incompatibilities.
> Pick one, or write your own."
You can say that loud again. There is more to say...
> A newbie shows up, whoever is online and feels like fielding the
> question answers with one of the stock, non-answer responses, and more
> regulars use more responses if the newbie is particularly stubborn.
>
> Meanwhile, the old hands think to themselves (pure speculation on my part):
> "Why couldn't this guy have Googled a bit more to find the answer?"
> "I solved this problem when I was starting out, why can't he?"
> "He's probably a whiner, looking for excuses not to code"
> "Lisp isn't for the masses, it's for the elite, and this guy is
> self-classifying"
... about each of the quoted statements. Most of them seem to be very
controversial.
>
>
> A customer focused group would recognize that prospects showing up with
> the same concerns represent, at minimum, a documentation problem, and
> probably a legitimate demand for change. In other words, is this a
> legitimate question, and what can we do so that the next newbie doesn't
> have to ask? I don't see people admitting to that here.
This is the problem of this thread in a nutshell. It is a dispute
over legitemacy. It is very hard to convince the participants that
questions or issues like "i could not put araneida to work because
it does not work as advertised" are /legitimate/. Some don't even
understand that it is not necessarily whinyness but concern for
Lisp. Some even dispute that wide adoption of a programming language
is a /good/ thing.
> In fact, your
> comment above, referring to ACTUAL, CONCRETE problems seems to imply the
> usual -- that this isn't a problem, notwithstanding countless newbies
> who say it is. And don't forget the multiplier: One newbie who posts
> usually represents several who couldn't be bothered or gave up, blaming
> the language for having insufficient infrastructure.
>
"countless newbies" repeating the same "usual" questions indeed
sounds like a FAQ problem, but maybe I can do something about
it. Read on.
> I would be remiss if I didn't mention LispBox/Lisp in a box. I don't
> think it's the solution to the problem, but (as I understand it, I'm not
> a user) it's a helpful aid to the newbie who rightly feels (or would, if
> he'd gotten that far) that investigating and integrating multiple
> complex packages using unfamiliar build tools just to get Lisp
> infrastructure off the ground shouldn't be necessary.
>
Again, this is a very rich topic; the details are good for
more than one flamefest.
> I really don't want to argue this all over again. I've no new points to
> make, and things haven't changed since the last time I argued it. But I
> won't let the NG come to a smug, wrong consensus that there's no problem
> despite continuing evidence to the contrary.
Here are some more quoted sentences:
"Lisp has less users than perl or python or php"
This in itself is not a judgement of worthiness and should
not be treated as such. It is an accurate, albeit trivial observation.
Most people here would even agree on that, although it seems to
be common to knee-jerkingly allege that the observer is a whiny
peckerhead or troll. More disputable is the question whether Lisp's
obscurity is a consequence of its power or not. The elitist's view,
and Lisp seems to have an deep elitist tradition (thanks to pascal
constanza for pointing me to an interesting document on this),
is a clear yes. The consent here is: Lisp is extremely powerful,
therefore it is hard to use, therefore it has remained a niche
player for an elite audience. This would be a good first section
for a "Newbie's introduction to c.l.l." or "what you should know
about Lisp before you post to c.l.l" or "The compleat troller's
guide to c.l.l." or "Tin Gherdanarra's Super-Troll-o-Matic" or
whatever, but I don't think that this view is correct, so the
Super-Troll-o-Matic might contain an interesting page for
Lisp-veterans as well.
"Being in a community around an obscure language is a good thing"
I'm not sure if the statement above was an attempt to troll
back on me, but a programming language is a typical
network-externality-product, thus elitists loose big time
when they shrug on the lack of industry support. All those
happy-Lisp-campers out there should be aware of the benefits
of other people doing their work for them, be it for love
or for money. It is absolutely cool to be a connaisseur of
hongkong-trash-movies with korean subtitles and it's totally
rad to dig hawaiian ethno-funk-core, but for a programming
language, this is the wrong type of cool. I'm not saying this
because I hate Lisp or you guys, I'm saying this because
I love Lisp and you guys. The afore-mentioned Super-Troll-o-Matic
should discourage elitism, but it should contain a section
where the elitits can defend their view. More importantly, it
should explain to the newbie that bringing up this topic
is a fool-proof way to raise hell on c.l.l. and thus
pretty cheap. It boils down to: yes, Lisp is fringy; yes,
Peter Seibel is working hard to alleviate this; yes, some
people think that this is a good thing; no, Tinman does not
think it is a good thing for the following reason, so pick your
side. Advantage: old lispniks could tell a newbie to open
the Troll-o-Matic, read the second section and argue with
themselves by copying the points and counter-points in
their preferred newsreader.
"Newbies and idiots suck"
The third chapter of the super-troll-o-matic
should make newbies and people of limited
mental abilities feel good by telling them
that Lisp /does/ provide a few challenges. I
think this is a bad thing, by the way. The
super-troll-o-matic can't do much about it for
the time being, but here is a brief introduction
into my reasoning.
Newbies and idiots have an especially hard time with Lisp,
at least in the time of TCP/IP, free databases and
the web. Lisp is absolutely great for whipping up
a super-nifty towers of hanoi, but in these modern times,
newbies want more than that.
I know a lot of people who made their first
steps in socket-programming with perl or PHP.
They did not even know what a socket /IS/ when
they started tinkering with them, they just
copied some examples from a dummies-book. Imagine
how their eyes lit up with glee when they saw their
first echo-server working! Can you blame them
when they stick to their PHP or perl for life after
such an experience? Now try to imagine the same with,
let's say, CLisp. To me, it is not a very convincing
imagination. My first socket program was an
oldschool C-program. After a couple of hours I had
a listener that could serve an arbitrary numbers
of files simultanously asynchronically, select() and all.
The same thing took me half and hour in python, including
trying out a module named asyncore and dismissing it
for technical reasons.
Despite several attempts, I have failed to even /install/
a socket module in SBCL and CLisp. I've probably
spent twenty hours with those futile attempts.
Maybe I'm an idiot, but even idiots want sockets.
It will offend the elitist, but I think Lisp should be
a language for idiots, too,
because its powerful datastructures, applicative
programming and abstraction facilities can make even
idiots very productive. I'm sure idiots would
prefer Lisp over any other programming language
if they could start building websites after
putting araneida to work by just typing
(require 'araneida).
So failing to attract neophytes and idiots is very bad
for mindshare, and consequently, very bad for Lisp
(see next section), at least if you aim for wide adoption in
order to reap in the benefits of industry support.
I don't say this because I hate Lisp or you guys,
I'm saying this because I love Lisp and you guys.
I think more Lisp would be good for the industry.
And I'm jealous for those PHP/perl/Java-coders getting
all the hot chicks. And I'd love to have a Lisp job.
I can't believe that I got flamed about this, because
Peter Seibel's /Gardeners/ project has been
originated precisely for addressing the issues outlined
here.
"Fragmentation -- good or bad?"
As stated above, there are multiple implementations
of Common Lisp with no one being blessed as THE
implementation. Although competition is good and
fosters innovation, it results in a competition for
developer labor, paid and volunteer. When it comes to
connectivity to
other technology, innovation is not as important as
for garbage collection, object persistence and the like.
Namely socket modules, threading, XML-connectivity and
database connectivity would benefit from a single, canonical
implementation that works across all major Common Lisp
implementations. I'm neither saying nor implying that
Common Lisp sucks, I'm just saying that that there is
no canonical collection of default modules that address
these issues. This is in contrast to perl or python.
There is another big problem with not having a single,
canonical implementation that is virtually overlooked:
Not only labor, but also glamour becomes fragmented.
I don't know who has written pythons regular expression
module (it is attributed to some company), but you can bet
that this company has gained a high reputation in the python
industry. They are "the guys who have written python's
re". When it comes to Common Lisp, there are several
competing regular expression modules, none of it is THE
re module, so the gain in reputation for writing
yet another re module or some re module for a limited
audience is probably a weaker incentive to write one.
The dilution of glamour becomes even more severe if
a module works for just one platform. Contrast "Mister
Foo has written THE parser generator (included in the
stdlib)" to "Mister Bar has written yet another parser
generator for some Common Lisp implementation".
Be honest: Wouldn't you like to be Mister Bar rathern
than Mister Foo? I don't mean to play down the effort
of all the honorable, brave and good-natured authors
of CL re-modules, by the way. I'm glad they did write
re modules for CL and appreciate their skill, patience
and altruism.
For the "Compleat Troller's Guide" this means to
antecipate what type of thinking might pop up in
the newbie's head and to make it clear that others
have thought about such things before. The newbie is
encouraged to tap into the rich folklore of Lisp's
flame culture and learn about the beaten, thus unappealing
paths. The experienced c.l.l.-flamers are welcome to
contribute suggestions, ideas and links to particularly
well-worded or offensive groups.google.com-posts.
IMPORTANT: I'm NOT ridiculing you -- I really mean
it, because I think the Super-Troll-o-Matic should be
an interesting read.
"Do-it-yourself-ism"
The good thing about open source software is that
every programmer can inspect the inner workings
of a program. This comes in handy if someone wants
to learn something or fix a problem, but it should
not be the default mode of operation. Expecting a
module to just work is legitimate, at least for
a mature platform. The exhortion to read the source
and fix some problem under the hood is hard to follow,
even for experienced programmers, and most certainly
not a task most programmers like. I, for example, hate
reading source-code because I hate everything that gets in
the way of my project, and this includes - to the
bewilderment of friends and lovers - hygiene, intimacy,
sleep, partying, food and booze. There are many people
who hate interrupting their work on a project to have
lunch, even to go the bathroom, so I think a little
empathy with people who /just want to use/ Lisp is
in order. Say it ain't so, but the constant appeals
to google, sratch one's head, analyze source-code,
second-guess the documentation and stir around
in muddy water does not make the impression of
a mature platform. And it limits mindshare.
Again, this is top material for the Super-Troll-o-Matic
because it opens so many possibilities for fighting
back. The newbie or idiot can expect to be called
- a whiny peckerhead
- a wannabe freeloader
- someone who should go and use python
- someone who should go and boil his head
- a newbie
- an idiot
and should be able to study the counter-points and insults
offline to save bandwidth and the calories and
nerves of other c.l.l. participants. More on the
importance of newbies and idiots in the "Newbies
and idiots suck" section.
"Standard vs. Non-Standard"
Having a standard like CL is a good idea.
Standardization is the bread and butter in any
industry and the concept of establishing standards
to begin with is one of the major technical and
organizational achievements of the 20th century.
That said, we observe that
Common Lisp has various implementations without one
of them being a dominant, canonized implementation.
This observation does /not/ involve a judgement
of worthiness. In other words, I'm neither stating
nor implying that a standard sucks.
In contrast to Common Lisp, perl, python and PHP do have
one canonical implementation. Their exact specification
has not been codified by an independent standardization
body, though. "In contrast to CL" does not mean
"better than CL". It is just an obvservation: CL is
standardized; perl python and PHP are not.
Although these observations in themselves don't
mean that Lisp is inferior compared to the p-languages,
many c.l.l.-veterans get worked up over them.
Since they do, these observations and discussion
of the interesting question "Do you think that
the Common Lisp standard enabled proliferation of
various implementation" belongs into the Troll-o-Matic.
"Benevolent dictator"
I'm not sure if this issue can be considered canon.
Maybe I've stumbled upon an entirely new and original
trolling idea without knowing it, but here it is:
The observation that - in contrast to common lisp -
perl, python and PHP each have
a project founder who has invested substantial work
to get his language off the ground, and, consequently,
is a central authority guiding the growth of the
language, is neither a thought-crime nor fascist nor
a sure-fire indication that the observer has a BDSM-fetish.
The conclusion that a single integrator can prevent
fragmentation of the language's module-offerings
might be wrong or of no practical value or unverifyable,
but it should be allowed to bring up this topic without
having to emigrate from c.l.l. afterwards. I think it
is an interesting question and could yield insights into
how to make the "Gardeners" project more effective. Maybe
there is a good prothesis for a benevolent dictator or
a way to set up dictatorless benevolence. Since this
seems to be unchartered territory, any flame is welcome --
it will go straight into the corresponding section of
the Trollomatic. So far, most of the insults and counterpoints
SUCKED because they were too brief or unappealing to
a broader audience.
The "benevolent dictator" topic has some implications for
the "Fragmentation" and "Standardization vs. single
Implementation"-chapters, so maybe it should go there.
Finally, the "c.l.l. Guide to Trolling" should
contain an appendix for mature audiences, that is,
the people who might feel offended by these
issues. The chapters in the appendix:
"Trolling"
The wikipedia has this to say about a troll:
"In Internet terminology, a troll is a person who posts rude
or offensive messages on the Internet, such as on
online discussion forums, to disrupt discussion or to
upset its participants."
The operative words here are "rude and offensive messages"
and "to disrupt discussion" and "upset its participants".
If someone is merely asking bona-fide questions he's not
a troll. Asking stupid questions or bringing up controversial
issues in good faith is not trolling. The guy asking
stupid questions might have failed to google for the
topic at hand, he might be of limited mental abilities,
but he is not a troll. Trolling is bad style and not
legitimate; being a peckerhead or being interested in
controversial issues is legitimate. However, with
a comprehensive Troll-o-Matic in place, it will BECOME
legitimate getting worked up on someone who is bringing
up the same old issues again.
"Googling"
It's a big world, so it is impossible to know
everything, even if it is limited to a narrow niche.
Google is extremely practical and effective, but it
has its limits. Good information might be hidden in
the backwaters of google result pages; sometimes
the right information is hard to comprehend.
Failing to find the right needle in the google-haystack
is legitimate, and so is giving up on the documentation
on cliki. That's the good thing about usenet: You can
ask questions to those who've been there and done that.
If you are a little impatient because you been asked
a question before several times, you could make a deal
with the newbie: I tell you how it works and you try it
out, polish my reply and put it into the FAQ or the
cl-cookbook. I'd volunteer for the question: How
can I make 'trivial-sockets work in SBCL?
From: Stefan Nobis
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <87mzhayv7h.fsf@snobis.de>
Tin Gherdanarra <···········@gmail.com> writes:
> As stated above, there are multiple implementations of Common Lisp
> with no one being blessed as THE implementation.
This is also true with Python or Perl. You don't think so? So, tell
me, which Implementation should I use? Perl 4, Perl 5.0, Perl 5.8,
Perl 6?
You look on this problem only from the perspective of a complete
newcomer. But once in a while you have a project, lasting over years
with much code to maintain. There are problems with Perl and Python in
this area, much more than with CL.
So what seems bad for a newcomer, may be a very big advantage for
bigger projects.
The point being: It seems, you like Lisp (or why are you arguing
here). So it has it's powers. Just use it. Period.
BTW: I teach Python to absolute beginners. Let me tell you that Python
is to many people not that appealing and that great. Maybe today the
Python community is a bit bigger and more active (the last point, I
like to doubt), but it's really not that glorious. There are many
problems and one reason I got catched by Lisp, is that I'm a bit
unpleased with the Python community and the direction Python (as a
language) is heading. Maybe Perl 6 will be a highlight, but 'till now
I'm not that impressed with all the scripting languages (be it Python,
Perl, Ruby). There are many, many libraries in much worse a state than
many CL libraries, so in the long run, no much differences here (but
in CL it's easier to do the job yourself).
Maybe the NIH syndrom is a bit more widespread in the CL community,
but I don't think, it's really a problem. I'm not that enthusiastic
about CL's future like Kenny, but I definitley think there is a (good)
future and for sure it's possible to get your work done with CL.
--
Stefan.
Stefan Nobis <······@snobis.de> wrote:
+---------------
| ... and for sure it's possible to get your work done with CL.
+---------------
And this, to me, is the important thing, because (so far) I *can*!!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Tin Gherdanarra <···········@gmail.com> writes:
> 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.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <445qqfFgkrmU1@individual.net>
Tin Gherdanarra wrote:
>> 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...
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44620qFh07gU1@individual.net>
Tin Gherdanarra wrote:
>>> 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?"
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
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
> 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.
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.
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.
Vagif Verdi schrieb:
> 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é
--
Vagif Verdi wrote:
> 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.
Vagif Verdi wrote:
> 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?
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <446cflFivekU1@individual.net>
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.
>
> 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.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
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.
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
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <446it3Fkg4lU1@individual.net>
·············@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.
> 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.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
"Pascal Costanza" <··@p-cos.net> schreef in bericht
··················@individual.net...
> ·············@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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44763oFo2dqU2@individual.net>
Paul Griffioen wrote:
>
>
> "Pascal Costanza" <··@p-cos.net> schreef in bericht
> ··················@individual.net...
>
>>·············@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
>
>
>
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4476fsFne4cU1@individual.net>
Tin Gherdanarra wrote:
> 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.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44cq20F16j2tU1@individual.net>
Pascal Costanza wrote:
> Tin Gherdanarra wrote:
>
>
>> 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.)
Well, in lieu of scientific instruments and without the need to
travel around the world, the model of a flat earth has worked
very well for millenia. It is an accurate model for everyday life.
Common sense is very effective more often than not and should
not be dismissed too quickly.
>
> Pascal
>
Tin Gherdanarra <···········@gmail.com> writes:
> Pascal Costanza wrote:
>> Tin Gherdanarra wrote:
>>
>>> 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.)
>
> Well, in lieu of scientific instruments and without the need to
> travel around the world, the model of a flat earth has worked
> very well for millenia.
What millenia? How well?
http://www-astronomy.mps.ohio-state.edu/~pogge/Ast161/Unit2/measearth.html
It seems to me, that things started to work well only _after_ we
became that earth wasn't flat, and happily, for more than two millenia
it's well known and prooved.
> It is an accurate model for everyday life.
Perhaps for your everyday life if you're a sheperd in a babylonian
desert, but not for mine. Otherwise I could setup an line of sight
laser link between my home and the closest town, but thanks to the
horizon I can't and this impact my everyminute life. Call me
Internet-addict.
> Common sense is very effective more often than not and should
> not be dismissed too quickly.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4476hcFmk13U1@individual.net>
Pascal Costanza wrote:
> ·············@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
>
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4476siFne4cU3@individual.net>
Tin Gherdanarra wrote:
> 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.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
·············@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)
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
Paolo Amoroso wrote:
> ·············@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)
>
> It works with ABCL (client only), Allegro CL, CMUCL, GNU CLISP,
> 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]
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447jogFr7gnU2@individual.net>
funkyj wrote:
> Paolo Amoroso wrote:
>
>>·············@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)
>>
>>It works with ABCL (client only), Allegro CL, CMUCL, GNU CLISP,
>>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
>
>
(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 schrieb:
> funkyj wrote:
> > Paolo Amoroso wrote:
> >
> >>·············@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)
> >>
> >>It works with ABCL (client only), Allegro CL, CMUCL, GNU CLISP,
> >>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
> >
> >
>
>
> (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
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 <···········@gmail.com> writes:
> 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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4475laFnf3jU1@individual.net>
Paolo Amoroso wrote:
> ·············@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.
>
> It works with ABCL (client only), Allegro CL, CMUCL, GNU CLISP,
> LispWorks, OpenMCL and SBCL.
>
>
> Paolo
Tin Gherdanarra wrote:
> Paolo Amoroso wrote:
>
>> ·············@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/
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4476quFo5abU1@individual.net>
·············@gmail.com wrote:
> 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
>
Darn it, by saying things out of my head I got lots of things wrong
(ISO Common Lisp, Touring).
Shame on me!!! :-(
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4475c5Fnmm8U2@individual.net>
Pisin Bootvong wrote:
> Darn it, by saying things out of my head I got lots of things wrong
> (ISO Common Lisp, Touring).
>
> Shame on me!!! :-(
>
Uh, what?
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4477s5FobjcU1@individual.net>
Pascal Costanza wrote:
> 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.
>>
I'm not following you. There is just one implementation for
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?
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4479t4Fp4ktU1@individual.net>
Tin Gherdanarra wrote:
>> 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?
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <446heiFjq49U1@individual.net>
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. 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.
--
Suffering from Gates-induced brain leakage...
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4475bdFnmm8U1@individual.net>
Ulrich Hobelmann wrote:
> 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?
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44792fFod43U1@individual.net>
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.
>> 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. ;)
--
Suffering from Gates-induced brain leakage...
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447bhdFoi7oU1@individual.net>
Ulrich Hobelmann wrote:
> 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.
From: Ulrich Hobelmann
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447mdhFoeh8U1@individual.net>
Tin Gherdanarra wrote:
>> 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...
Pascal Costanza <··@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."
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4477ukFobjcU2@individual.net>
Rob Warnock wrote:
> Pascal Costanza <··@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 <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>
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??),
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é
--
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447btbFos51U1@individual.net>
Andr� Thieme wrote:
> 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�
> --
>
Tin Gherdanarra schrieb:
> 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é
--
André Thieme wrote:
> > > 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
From: Edi Weitz
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <uvew1zb5i.fsf@agharta.de>
On 30 Jan 2006 12:52:57 -0800, "Andr� Thieme" <······························@justmail.de> wrote:
> 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 ·········@agharta.de" 5) "edi")
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44797pFolv9U1@individual.net>
Pascal Costanza wrote:
> Tin Gherdanarra wrote:
>
>>>> 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.
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.
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447lasFq5i1U1@individual.net>
Tin Gherdanarra wrote:
> 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/
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Tin Gherdanarra <···········@gmail.com> writes:
> It's not just my needs. It's something like
>
> import sockets
As of now, you can probably try (untested):
(pythonlisp "import sockets")
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Kevin L
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <og5Gf.12504$%i3.7727@trnddc02>
Tin Gherdanarra wrote:
> Actually, all I wanted to know was whether you guys notice
> improvement in Lisp's mindshare and lower barrier to entry.
I think I may actually be in a reasonable position to respond. I am
learning Lisp now for the first-ish time with the expectation that I
will be using it as my primary language for a significant period of time.
My very first exposure to Lisp was in fall 1999 for a CompSci class, and
the professor-recommended platform was Emacs on Unix and ACL on Windows.
I couldn't make it viable for me. I was used to the Borland, Watcom,
and Microsoft C++ IDEs and by then the write-compile-test sequence with
integrated source debugger was much easier. In addition my textbook
(Noyes: _Artificial Intelligence with Common Lisp: Fundamentals of
Symbolic and Numeric Processing_) is pretty terrible for picking up the
language. However, I still "felt" that Lisp had something to offer, so
I kept the textbook with the hope that someday I would be able to look
at it again. Fast-forward six years, and I've got extensive experience
in Java J2EE, C, Visual Basic, and medium-level experience in C++, Perl,
PHP, ksh/bash, Fortran, and a smattering of others. I had grown very
tired of solving the same kinds of problems just with different syntax,
and quite annoyed at language limitations (putting downcasts all over
the code, not being able to re-use interface function bodies, poor
exception handling, not being able to pass around functions as
arguments, etc.) I looked around and decided to go for serious Lisp.
What I've found so far is that there IS a barrier to entry BUT it's much
lower than years ago. Several practical problems (packaging, pathnames
(!), command-line arguments, accessing low-level APIs, etc.) are glossed
over too much in even the "good" books like PCL. It's almost a mirror
image of Java: it seems every single Java book published spends 120
pages describing the package layout, how to access the compiler, and
syntax, and then ends right before a complex problem can be addressed;
yet the Lisp books I have seen jump right in on syntax and follow
directly with high-level contructs (macros, CLOS, etc.) but just happen
to skip over the initial steps of installing an implementation,
accessing the runtime, and setting up a defsytem. In other words, for a
new Lisper there is relatively little well-organized documentation
between the steps of '1. apt-get install cmucl' and '2. (defsystem
"mypackage" :depends-on (:cl-statistics :matlisp ...)'. But it IS out
there in the form of Usenet, READMEs, etc., just not in a direct HOWTO
that spends a full paragraph outlining each step (that I have seen).
David Lamkins' _Successful Lisp_ has been very helpful also.
Once past those initial hurdles, Lisp is dead easy. I noticed just last
week that writing some code to solve a homework problem took about 5
minutes (really) and was perfect the first time, something unheard of
for me in my other languages. There are a lot of libraries (that each
tend to be quite extensive) for most things I need, and I know how to
get to them now. I got cl-modlisp to work (Apache was actually the hard
side of that) in about 2 hours, and that only because I refused to
follow the exact steps in order.
I tend to use Usenet a lot, and the discussions from the established
Lisp community has influenced what I see as the "right way" Common Lisp
should be like:
1. I DO want more portable libraries of low-level APIs (sockets, raw
file IO, graphics, ODBC, etc.). I DO want these libraries to make use
of easy installers (asdf-install, apt-get, etc.).
2. I DON'T want a CPAN-type code repository in which only a couple
libraries in each problem domain become the "One True Common Lisp
Solution(tm)" -- see as examples Net::FTP (incomplete/buggy API) and
Archive::Zip (leaks memory).
3. I ABSOLUTELY DON'T want non-low-level domain-specific APIs (e.g.
XML) to enter the standard, EVER! That opens the door to madness: is
SAX the real standard, or w3c DOM? Will we have to have XPath too?
These APIs can be directly handled with high-level libraries, and they
should be optional for the user.
4. I DON'T want many many more implementations than we have now. I DO
want all of the most popular ones (GCL, CLISP, CMUCL, SBCL, MCL, ACL,
Corman, etc.) to remain strong and I want libraries to port between them
OK. They each have their strengths and weaknesses and I feel better
knowing that even as one implementation pauses development the others
will continue on. I see this not as fragmentation but cross-pollination
-- see *BSD. Many people want one canonical implementation, and point
to Perl, PHP, Java, etc. as good examples. I've done Java a lot, and I
know that GNU Classpath + Kaffe/SabreVM are very close to being
Java-certified(tm) (it's basically Sun holding up the process right
now); when that happens, I believe there is going to be a cataclysmic
schism for the Java language, as each implementation exposes bugs and
undefined behavior in the other, and customers will be forced to decide
up-front which implementation they will use because their PureJava(tm)
code will not run 100% identically on both stacks. They will have
Sun-Java-on-Windows+Linux+etc OR GNU-Java-on-Windows+Linux+etc but not
both unless they write to a very limited feature set. Lisp has already
been through this process, today has at least six implementations of
equivalent complexity to the Sun JVM, yet still achieves
interoperability between most combinations of platform and
implementation. To me that is called peace of mind: if CMUCL drops
off, I can switch to SBCL, then CLISP, then others.
5. I AGREE that there is a lot of paternalism/elitism in c.l.l. left
over from earlier painful experience. (I'd probably sound that way too
if I had been through it.) However, reasonable heads do prevail and the
Lisp language (both culturally and technically) is becoming more
accessible to newbs like me.
From: Christophe Rhodes
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <squ0bmvhsi.fsf@cam.ac.uk>
Tin Gherdanarra <···········@gmail.com> writes:
> [ 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
On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
<·····@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\./
From: Christophe Rhodes
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <sqirs2vfpo.fsf@cam.ac.uk>
Adam Connor <···@nospam.com> writes:
> On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
> <·····@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?
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
Adam Connor wrote:
> On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
> <·····@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?
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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <4451liFeei8U2@individual.net>
Kenny Tilton wrote:
> Adam Connor wrote:
>
>> On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
>> <·····@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?
>
>
> 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.
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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444turFduvnU2@individual.net>
Adam Connor wrote:
> On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
> <·····@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 (:
> --
> adamnospamaustin.rr.com
> s/nospam/c\./
Tin Gherdanarra <···········@gmail.com> writes:
> Adam Connor wrote:
> > On Sun, 29 Jan 2006 21:35:41 +0000, Christophe Rhodes
> > <·····@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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444tu1FduvnU1@individual.net>
Christophe Rhodes wrote:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>
>> [ 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.
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 wrote:
> Arguably, Paul Graham's essay has been very influential
> 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.
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
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <444o21Fci7uU1@individual.net>
>
>
> 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 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, or if some Benevolent Hitler starts
making efficient decisions.
Tayssir
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <445092FdlbtU1@individual.net>
Tayssir John Gabbour wrote:
> 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
>
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <447605Fo2dqU1@individual.net>
Tayssir John Gabbour wrote:
> 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 wrote:
> 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
Tin Gherdanarra wrote:
> 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, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Tin Gherdanarra
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44fu8hF1usjaU1@individual.net>
Tin Gherdanarra wrote:
> Arguably, Paul Graham's essay has been very influential
> 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.
I found this on reddit today. A /girl/ used Common Lisp
to create some bioinformatics program in two months
with no prior knowledge of the language. That article
http://ileriseviye.org/arasayfa.php?inode=samantha-lisp.html
refutes some of the conceived wisdom here in this
widely ramified thread, so I post it here. Coinkidinkally
I've been musing about how perl grabbed the bioinformatics
market away from Lisp. I don't attribute too much
significates to the article, I think it's more a curiousity.
Maybe it's food for thought, too.
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44go2bF22kr2U1@individual.net>
Tin Gherdanarra wrote:
> I've been musing about how perl grabbed the bioinformatics
> market away from Lisp.
Perl is a programming language, it cannot grab anything. ;)
It's people who choose programming languages. I have adopted Java in
1995 before it went to version 1.0 and stayed with it for more than
seven years. I did so because I didn't know any better and because it
takes a certain level of maturity too see the gross limitations of Java.
I think that's representative - all the people I know who extensively
use Java typically have little knowledge about the alternatives. [1]
That's what you get when you focus on popularity. People stop to think
about why they choose particular tools.
Pascal
[1] There are, of course, exceptions.
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1vevwvjc2.fsf@mordac.netfonds.no>
Pascal Costanza <··@p-cos.net> writes:
> It's people who choose programming languages. I have adopted Java in
> 1995 before it went to version 1.0 and stayed with it for more than
> seven years.
Was that in university? There seems to have been, from around that
time on, a tremendous java wave in CS (and CL/AI, which I know better)
departments in universities (I left academia in 1994, until then I
worked at the University of Saarbr�cken which still had a lot of lisp
stuff going on, both on the university and the DFKI). I think this
seemingly irrational wave of java-embracing was duse to java being
seen as quote a saviour by a lot of professors: It was both
business-credible and theorist-credible at the same time.
I remember talking to some german students at the EDOC'99 conference
in Mannheim (hmm, they might have been from Bonn - were you one of
them ;)?) who had made some pretty cool stuff for dynamically
modifying running java server programs. I asked politely if they had
thought of using lisp instead, then they would get it 100% right and
all for free. The answer was something like "Yeah, we know, but our
Professor is into java, so...".
--
(espen)
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44gqnuF24a7dU1@individual.net>
Espen Vestre wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>It's people who choose programming languages. I have adopted Java in
>>1995 before it went to version 1.0 and stayed with it for more than
>>seven years.
>
> Was that in university? There seems to have been, from around that
> time on, a tremendous java wave in CS (and CL/AI, which I know better)
> departments in universities (I left academia in 1994, until then I
> worked at the University of Saarbr�cken which still had a lot of lisp
> stuff going on, both on the university and the DFKI). I think this
> seemingly irrational wave of java-embracing was duse to java being
> seen as quote a saviour by a lot of professors: It was both
> business-credible and theorist-credible at the same time.
Yes, it was in university, but I have also used it in commercial
projects. Another important element of going for Java was that it wasn't
C++. Some researchers at the University of Bonn had used C++ for their
research, and this was mostly a mess. (C++ is probably good for some
things, but definitely not for experimenting with language extensions.)
I don't know why Lisp was not on the radar at that time. I have only
learned a lot later that our department in Bonn once had a Symbolics
Lisp Machine. But that was before my times. The problem with the
Symbolics Machine was that once they have bought it, Sun Workstations
became more efficient (so I have been told).
> I remember talking to some german students at the EDOC'99 conference
> in Mannheim (hmm, they might have been from Bonn - were you one of
> them ;)?) who had made some pretty cool stuff for dynamically
> modifying running java server programs. I asked politely if they had
> thought of using lisp instead, then they would get it 100% right and
> all for free. The answer was something like "Yeah, we know, but our
> Professor is into java, so...".
Yes, this rings a bell. This was probably the Evolve Platform (or so). I
wasn't involved in that specific project (but have later based some of
my work on it).
I was part of making the decision to go for Java. I feel guilty... ;)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1mzh8vf0v.fsf@mordac.netfonds.no>
Pascal Costanza <··@p-cos.net> writes:
> learned a lot later that our department in Bonn once had a Symbolics
> Lisp Machine. But that was before my times. The problem with the
> Symbolics Machine was that once they have bought it, Sun Workstations
> became more efficient (so I have been told).
Sure, but that wasn't really a reason for dropping lisp (the active
lisp communities started replacing their symbolics- and xerox-machines
with lisp on commoditiy unix workstations and macs already in ~1988).
> Yes, this rings a bell. This was probably the Evolve Platform (or
Yes, I think it was Evolve!
> I was part of making the decision to go for Java. I feel guilty... ;)
Well nobody got fired for choosing java at that time ;)
--
(espen)
From: Pascal Costanza
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <44h0e1F211onU1@individual.net>
Espen Vestre wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>learned a lot later that our department in Bonn once had a Symbolics
>>Lisp Machine. But that was before my times. The problem with the
>>Symbolics Machine was that once they have bought it, Sun Workstations
>>became more efficient (so I have been told).
>
> Sure, but that wasn't really a reason for dropping lisp (the active
> lisp communities started replacing their symbolics- and xerox-machines
> with lisp on commoditiy unix workstations and macs already in ~1988).
I don't know the reasons - I haven't been there at that time.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Espen Vestre wrote:
> > departments in universities (I left academia in 1994, until then I
> > worked at the University of Saarbr�cken which still had a lot of lisp
> > stuff going on, both on the university and the DFKI).
> > lisp communities started replacing their symbolics- and xerox-machines
> > with lisp on commoditiy unix workstations and macs already in ~1988).
> I don't know the reasons - I haven't been there at that time.
Around 1989, the symbolics machines in Saarbr�cken (mostly in use at
DFKI) had a reputation of being slow (or were percieved as such).
Many MacIvory machines were bought around that time, which had the
nice Mac GUI (not only for secretaries) and still contained the
praised Symbolics hardware and software. Most people used the
old Symbolics keyboard instead of the Apple one when doing a lot
of Lisp. And a lot of Lisp was done in that time.
IIRC, most GUI applications were done there. Nobody liked to do Motif
programming on UNIX. (IMHO, GUI programming has not evolved much since)
However, IIRC the MacIvory financial situation was unclear, Symbolics
in trouble (or was that only later?) and the machines still expensive.
But I have not figures about how many were bought per year.
Still, they provided a much better environment than what was present
on Sun and HP-UX workstations: Franz and AKCL. I rarely used these
two. But they were used. A lot of students code was developed there
(often enough using TTY terminals to the UNIX workstations), while the
Symbolics/MacIvory were more in the researcher's offices. More
precisely, students coming late would get the tty terminals, the
earlier ones would sit at the UNIX's GUI huge color display.
In 1992, I was not at Saarbr�cken anymore, but our research project
bought Sun workstations. We then used CMUCL. No talk of buying
MacIvory. Maybe Suns were bought because they would fit what already
was in the new department (nevertheless my group was perceived as
exotic, and our focus on Lisp work did contribute to this (while
Prolog and Smalltalk were already known in out new department :-)).
From 1993 on, students more and more expected to be able to do their
work sitting at home with their PC's instead of in the labs with a
Sun. Such "soft" items may also influence some student's decision in
favour of this or that course.
Well, all that's from memory...
Jorg Hohle
Telekom/T-Systems Technology Center
From: Espen Vestre
Subject: Re: Interesting developments since "Beating the averages"?
Date:
Message-ID: <m1u0aygu1g.fsf@vestre.net>
Joerg Hoehle <······@users.sourceforge.net> writes:
> In 1992, I was not at Saarbr�cken anymore, but our research project
> bought Sun workstations. We then used CMUCL. No talk of buying
> MacIvory.
At that time, MacIvory was starting to look like a really bad deal,
since MCL would run faster on the mac the board was sitting in.
However, MCL didn't yet support multithreading at that time, AFAIR.
--
(espen)
Tin Gherdanarra <···········@gmail.com> writes:
> with no prior knowledge of the language. That article
>
> http://ileriseviye.org/arasayfa.php?inode=samantha-lisp.html
>
> refutes some of the conceived wisdom here in this
What makes you say that? It looks to be a simple case of what many
people have pointed out. It seems clear that she happens to be the
kind of person who simply _does_ something instead of whinning about
how it "can't" be done.
> I've been musing about how perl grabbed the bioinformatics
> market away from Lisp.
I believe this is an incorrect view/perception/belief. "Perl" didn't
grab this away from Lisp (or anything else really). In my experience
(admittedly annecdotal) Perl just happened to be the thing that a lot
of people who hacked early "bioinformatics" already knew. Most of
these folks were biologists, didn't know much about
CS/software/et.al. but simply grabbed a readily availble tool and
started at it. And, for the most part, it shows too.
> I don't attribute too much significates to the article, I think it's
> more a curiousity.
Ideologists never attribute significance to data that conflict with
their apriori world view.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com