Discussion:
Learning Lisp the Bump Free Way
Daniel Weinreb
2011-01-19 22:06:34 UTC
Permalink
This is a very nice essay to help people get over their
initial problems with Lisp:

http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way

I also just came across an online book called "Successful Lisp",
by David B. Lamkins (maybe many of you already know
about this):

http://psg.com/~dlamkins/sl/

It's also available from Amazon, in trade paperback
(300 pages).

http://www.amazon.com/Successful-Lisp-How-Understand-Common/dp/3937526005/ref=sr_1_1?ie=UTF8&s=books&qid=1295104605&sr=1-1


I'm not sure whether we need any more Lisp textbooks
now that we have Practical Common Lisp, but it's somehow
just nice to know that there are more books about Lisp
that managed to get published; at least in the sense
that Amazon has it (the web site of the publisher seems
to have expired).



-- Dan
Alexander Repenning
2011-01-20 16:04:48 UTC
Permalink
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.

Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.

The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"

best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
Alessio Stalla
2011-01-20 16:38:03 UTC
Permalink
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point > in the near future (months).
Are there big systems written in JS? I'm not aware of any. It would be
interesting to compare big, real-world production systems in both
languages; I suspect CL would win outright. I'm also interested in how
these dynamic languages perform in a multithreading context. As far as
I know, both Python and Ruby (in their C implementation) suffer from
the "global interpreter lock" i.e. are basically single-threaded; and
JavaScript is single-threaded as well in browsers, its most common
environment.
Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.
I don't see how compiling it to JS is supposed to be better than
compiling to C (or even Java bytecode). JIT compilation is certainly
very powerful, but JS is very dynamic and has no provisions for type
annotations (heck, it doesn't even have a type system, as far as I
know). Anyway, a subset of CL already compiles to JS (Parenscript).
Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine > with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.
Emacs+SLIME is not the best possible IDE for sure; but it's enough of
a sweet spot that there's little push for developing a (free)
alternative while there's a lot of work to do in other areas. Also,
apart from Java, C#, VB.NET and perhaps Objective-C (which are all
commercially supported), no language - especially dynamic ones - has a
native IDE that is superior to Emacs+SLIME. What is the IDE of choice
for Javascript? Python? Ruby? PHP? Haskell? C? I suspect most people
use either generic editors like vim or Emacs, or "foreign" IDEs like
Eclipse or IntelliJ IDEA that happen to have a plugin for their
language of choice.
The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining > why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do > not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"
We have different opinions; I don't think developing free IDEs is
worth the effort. I think developing libraries and applications is far
more needed for Lisp to succeed. IDEs are big projects that are best
done by commercial companies or by big groups of volunteers. For any
of those to show up, the community needs to be much bigger, so that
the IDE has many potential users.

Regards,
Alessio
Martin Cracauer
2011-01-20 16:43:12 UTC
Permalink
Post by Alessio Stalla
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
It?s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point > in the near future (months).
Are there big systems written in JS?
All Mozilla products.

I don't think anybody can seriously think that Javascript performance
can ever beat what CMUCL/SBCL can do to Lisp code that is declared
through and doesn't use CLOS (plus assorted other techniques). And
even if so, if a certain somebody would finish the LLVM backend for
SBCL then it's easy picking :-)

Martin
--
Martin Cracauer, Programmer, ITA Software Inc, 617-714-2130
Alessio Stalla
2011-01-20 16:46:15 UTC
Permalink
On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer
Post by Martin Cracauer
Post by Alessio Stalla
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
It?s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point > in the near future (months).
Are there big systems written in JS?
All Mozilla products.
Mozilla products are in C++. Only the GUI is scripted in JS (XUL). And
handling GUI events is not high-performance computing in my book ;)
Post by Martin Cracauer
I don't think anybody can seriously think that Javascript performance
can ever beat what CMUCL/SBCL can do to Lisp code that is declared
through and doesn't use CLOS (plus assorted other techniques).  And
even if so, if a certain somebody would finish the LLVM backend for
SBCL then it's easy picking :-)
I completely agree.

Alessio
Martin Cracauer
2011-01-20 17:00:22 UTC
Permalink
Post by Alessio Stalla
On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer
Post by Martin Cracauer
Post by Alessio Stalla
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
It?s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point > in the near future (months).
Are there big systems written in JS?
All Mozilla products.
Mozilla products are in C++. Only the GUI is scripted in JS (XUL). And
handling GUI events is not high-performance computing in my book ;)
I wish, maybe then the thing wouldn't be so atrocious :-)

There's almost a million lines of Javascript in Firefox and you spend
most of your CPU time in Mozilla's Javascript code. The actual
rendering is C++ but the rendering time is Firefox's least problem.

Martin
--
Martin Cracauer, Programmer, ITA Software Inc, 617-714-2130
Tom Emerson
2011-01-20 17:55:32 UTC
Permalink
Post by Alessio Stalla
Are there big systems written in JS? I'm not aware of any.
Not stand-alone desktop apps, but Google's browser-hosted applications (the
GoogleDocs suite, GMail, Maps) are written in JavaScript (using their
unfortunately named Closure tools : http://code.google.com/closure/).

-tree
--
Tom Emerson
tremerson-***@public.gmane.org
http://treerex.blogspot.com/
Alexander Repenning
2011-01-20 17:39:45 UTC
Permalink
Alex: I realize this isn't your central point but I'm curious what benchmark(s) you're citing?
Hi Brian,

Here is an older list of application level (computation + visualization) benchmarks: http://weup.sourceforge.net/demos/rm/index.html

look for instance at the eColi simulation. http://weup.sourceforge.net/demos/rm/rm.html?app=EcoliModel

or the game of life


a newer version compared performance to Java and Lisp (CCL)

Alex

You need to hit the compile button to run
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"
best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
Brian Taylor
2011-01-20 17:08:15 UTC
Permalink
Alex: I realize this isn't your central point but I'm curious what
benchmark(s) you're citing?
Post by Alexander Repenning
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus
Common Lisp I can see a scary performance cross over point in the near
future (months). Already, in some of our benchmarks JavaScript running in OS
X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is
that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp
instead of advancing it. The result: flatline! As far as I can tell non of
the exciting JIT compiler technologies developed in the last couple of years
have made it into any CL implementation. If you follow this trend you may
conclude the right thing to do, if you want to continue to use Lisp, would
be to compile it down to JavaScript, yes, JavaScript, not C or direct to
binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of
LispWorks it appears that most Lisp programmers are just fine with Emacs.
Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of
Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure
CL. As far as I can tell most people, including some the developers perhaps,
are using SLIME too. Start using something new. For instance start using the
Cocoa based CCL IDE. Yes, still primitive but with real opportunities to
create some fine IDE tools that actually would look OK even to a 21 Century
computer science students. Nowadays, even browser (e.g., Safari and FireFox)
have debugging tools built in that make SLIME look like last century
technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century
computer science world need no more essays explaining why Common Lisp is the
way it is (stale). It is time to leap into action and to IMPLEMENT stuff
that is not just interesting to the Common Lisp community but to computer
science in general. Play with Clozure Common Lisp the IDE version (Mac and
Window). Do not just get frustrated and switch back to Slime but ask
yourself "what can YOU do for Common Lisp (or more specifically CCL) to make
it cool again"
best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Chaitanya Gupta
2011-01-20 18:34:12 UTC
Permalink
[Forgot to reply all, so this went as a private mail to Alexander]
Post by Alexander Repenning
would be to compile it down to JavaScript, yes, JavaScript, not C
So you mean that Javascript will eventually become faster than C? If so,
then its not a problem unique to Common Lisp.

As far as IDEs go, the only thing that you have been implying is that
SLIME doesn't "look" modern (i.e. doesn't use your native GUI toolkits).
While an IDE written that way would have some advantages, its not a big
issue for me. Unless, of course, you have something more substantial to say.

Chaitanya
--
http://chaitanyagupta.com/blog/
Daniel Weinreb
2011-01-20 19:10:48 UTC
Permalink
Post by Alexander Repenning
is still mostly true but as I am tracking the speed of JavaScript
versus Common Lisp I can see a scary performance cross over point in
the near future (months). Already, in some of our benchmarks
JavaScript running in OS X Chrome is getting very close (10% gap) to
Clozure Common Lisp. Why is that? Common Lisp has gone STALE.
I can't argue with that, but there's another thing:

In his keynote speech at SPLASH/OOPSLA, Allan Wirf-Brocks gave
a history of dynamic languages and the phases they went through.
He says that in the current phase, the importance of Javascript
is so high that a lot of the effort on dynamic languages in
general is going to Javascript. Also, the people with expertise
in such languages and how to implement them properly is
also going to Javascript. So some of what is going on here
isn't only specific to Common Lisp.

As more and more applications are written to run inside
browsers, there is more and more motivation to be able
to provide an environment in the browser that is
conducive to writing more sophisticated applications.
Making Javascript faster is one of the elements.

-- Dan
Alexander Repenning
2011-01-20 19:46:02 UTC
Permalink
Hi Drew,

perhaps the point of a mailing list for professional lisp developers is to act, well ... professional?

Remember one of the points made in original article about the Lisp community: "The community isn’t nearly as blood thirsty as some people might portrait it."

Seems to me you just confirmed what many people appear to worry about. Well done.

Alex
Post by Alexander Repenning
Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it.
I participated in the creation of this mailing list in part to get
away from trolling like this on the other lisp forums. Is there no
place on the interwebs safe from such bullshit?
Post by Alexander Repenning
The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale).
And i'm not convinced a mailing list for professional lisp developers
needs more diatribes explaining how _we_ should 'fix' Common Lisp to
make it 'cool' again.
Can we leave this sort of drivel on comp.lang.lisp where i have
plonk-ability, and keep this mailing list for "people who already know
and use Common Lisp and who don't want to discuss the
merits of it or how other languages are worse or better"?
Cheers,
drewc
Post by Alexander Repenning
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"
best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
Scott McKay
2011-01-20 19:53:53 UTC
Permalink
As one of the list moderators, might I interject two words here:
"please" and "stop"?

I agree with Drew's sentiments, if not completely with his tone.
But if his tone offends you or anyone else, please reply to him
off-list.

Let's keep this list very focused. Thanks!

--Scott
Post by Alexander Repenning
Hi Drew,
perhaps the point of a mailing list for professional lisp developers is to act, well ... professional?
Remember one of the points made in original article about the Lisp community: "The community isn’t nearly as blood thirsty as some people might portrait it."
Seems to me you just confirmed what many people appear to worry about. Well done.
Alex
Post by Alexander Repenning
Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it.
I participated in the creation of this mailing list in part to get
away from trolling like this on the other lisp forums. Is there no
place on the interwebs safe from such bullshit?
Post by Alexander Repenning
The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale).
And i'm not convinced a mailing list for professional lisp developers
needs more diatribes explaining how _we_ should 'fix' Common Lisp to
make it 'cool' again.
Can we leave this sort of drivel on comp.lang.lisp where i have
plonk-ability, and keep this mailing list for "people who already know
and use Common Lisp and who don't want to discuss the
merits of it or how other languages are worse or better"?
Cheers,
drewc
Post by Alexander Repenning
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"
best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Drew Crampsie
2011-01-20 20:00:19 UTC
Permalink
Post by Alexander Repenning
Hi Drew,
perhaps the point of a mailing list for professional lisp developers is to
act, well ... professional?
Is it professional to publish what was intended as private
correspondence on a public mailing list?
Post by Alexander Repenning
Remember one of the points made in original article about the Lisp
community:  "The community isn’t nearly as blood thirsty as some people
might portrait it."
I can't speak for the entire community, only for myself.
Post by Alexander Repenning
Seems to me you just confirmed what many people appear to worry about. Well done.
I'm not going to get in this argument on this mailing list, i don't
think it's the place. If you'd like to have this discussion, please
feel free to email me privately.

Cheers,

drewc
Post by Alexander Repenning
Alex
Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead
of advancing it.
I participated in the creation of  this mailing list in part to get
away from trolling like this on the other lisp forums. Is there no
place on the interwebs safe from such bullshit?
The 21 century computer science world need no more essays explaining why
Common Lisp is the way it is (stale).
And i'm not convinced a mailing list for professional lisp developers
needs more diatribes explaining how _we_ should 'fix' Common Lisp to
make it 'cool' again.
Can we leave this sort of drivel on comp.lang.lisp where i have
plonk-ability, and keep this mailing list for "people who already know
and use Common Lisp and who don't want to discuss the
merits of it or how other languages are worse or better"?
Cheers,
drewc
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus
Common Lisp I can see a scary performance cross over point in the near
future (months). Already, in some of our benchmarks JavaScript running in OS
X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is
that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp
instead of advancing it. The result: flatline! As far as I can tell non of
the exciting JIT compiler technologies developed in the last couple of years
have made it into any CL implementation. If you follow this trend you may
conclude the right thing to do, if you want to continue to use Lisp, would
be to compile it down to JavaScript, yes, JavaScript, not C or direct to
binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of
LispWorks it appears that most Lisp programmers are just fine with Emacs.
Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of
Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure
CL. As far as I can tell most people, including some the developers perhaps,
are using SLIME too. Start using something new. For instance start using the
Cocoa based CCL IDE. Yes, still primitive but with real opportunities to
create some fine IDE tools that actually would look OK even to a 21 Century
computer science students. Nowadays, even browser (e.g., Safari and FireFox)
have debugging tools built in that make SLIME look like last century
technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century
computer science world need no more essays explaining why Common Lisp is the
way it is (stale). It is time to leap into action and to IMPLEMENT stuff
that is not just interesting to the Common Lisp community but to computer
science in general. Play with Clozure Common Lisp the IDE version (Mac and
Window). Do not just get frustrated and switch back to Slime but ask
yourself "what can YOU do for Common Lisp (or more specifically CCL) to make
it cool again"
best,  Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
Daniel Weinreb
2011-01-20 20:03:45 UTC
Permalink
Alexander,

Here's my own interpretation of what Drew said, which I admit
may or may not be what he had in mind. (I do agree that he
And i'm not convinced a mailing list for professional lisp developers
needs more diatribes explaining how _we_ should 'fix' Common Lisp to
make it 'cool' again.
This could be interpreted as "We don't need to do [those things]",
but I think (hope) what he really meant was that it's not
constructive to just *say* that we ought to do those things.
It's more constructive to discuss why.

For a long time, I've been saying:

- The languages that have been vibrant and for which tools
are flourishing are the ones that are (a) perceived as
exciting, and/or (b) used by a large and/or growing
community. It's hard to make this happen for Common
Lisp.

(Just for one example: consider why lisp.org still makes Lisp look like
a dusty historical artifact, as compared with python.org
or ruby.org. The reasons for this are somewhat complicated
and historical, but, for whatever reasons, the problem
persists.)

- Nobody is paid to create better open-source Lisp programming
environments. Doing a good IDE is hard. Even doing a Lisp
plugin for Eclipse (which lets you share some of its existing
mechanisms) is hard enough that the only one I know of
is still pretty basic. Even here at ITA where so many of
us use Lisp, I don't think we have one person assigned
to improve or supersede Slime. We are trying get better code
coverage checking so that we can improve our unit testing,
but that's the only such thing going on that I am aware of.

- There is a lot of obsolete stuff in Common Lisp. I and others
have written about this at some length. See
http://ilc2009.scheming.org/node/7.

As for me, if the Google acquisition of ITA happens, chances
are that I won't be allowed to use Common Lisp, and that
it's unlikely that I'll ever have a chance to use it for
a paid job ever again. Not impossible, but unlikely.
There are reasons for that.

So as much as we may agree with the problems you are
talking about, it's very hard to solve them for real.

-- Dan
Drew Crampsie
2011-01-20 21:02:57 UTC
Permalink
Post by Daniel Weinreb
Alexander,
Here's my own interpretation of what Drew said, which I admit
may or may not be what he had in mind.  (I do agree that he
said it in a rude way.)
In my own defense, i immediately followed up with this :

"Didn't quite mean to be so abrasive there, hadn't had my coffee and
was in no mood. Accept my apologies for the presentation, but i stand
by the content."

I also did not intend for the discussion to clutter the list. Since
the cat's out of the bag, i suppose i'll chime in publicly.
Post by Daniel Weinreb
And i'm not convinced a mailing list for professional lisp developers
needs more diatribes explaining how _we_ should 'fix' Common Lisp to
make it 'cool' again.
This could be interpreted as "We don't need to do [those things]",
but I think (hope) what he really meant was that it's not
constructive to just *say* that we ought to do those things.
It's more constructive to discuss why.
It's a bit of both, to be honest.

The fact that javascript JIT compiler technology comes within 10% of
CCL on some benchmarks isn't a problem that i personally run into, and
the lack of an IDE hasn't stopped me from delivering products in
Common Lisp. Nor has the perceived lack of vibrancy impeded my ability
to find paying work in CL. However, i'm willing to agree that these
problems exist.

I do, however, think that comparing the work produced by the open
source CL community to that produced by multi-billion dollar
corporations is both unfair and counter-productive. Apple and Google
have something to sell, and are aggressively attempting to sell it to
both users and developers. Their /raison d'etre/ is to produce tools
that are useful for the casual developer and used by the masses.

The same can not be said of the Clozure team, the SBCL devs, the SLIME
folk or us working slobs just trying to make a living using CL. If i
had the resources of a mega-corporation behind me, do you think cliki
would be held together with duct-tape and bubble gum, or
common-lisp.net would look old and tired? Would the ALU wiki crash
every few months and be generally a mess to work with? I'd like to
think otherwise.

The root of the perceived problem is a lack of resources, not a lack
of effort or desire on the part of the "lisp community". There are
many in the "lisp community" working to " IMPLEMENT stuff that is not
just interesting to the Common Lisp community but to computer science
in general", and there are plenty of folk playing with the CCL IDE,
among others. A call to arms such as the OP's sounds to me more like
an order to "work harder" rather then a productive solution or even a
motivating idea.

I suppose i am just tired of hearing, on every lisp forum everywhere,
someone's ideas about what's wrong with CL and how the "lisp
community" can work to fix it when "we're" already working as hard as
we can just to keep things running.

While my (private) reply was admittedly over-the-top rude, it was an
emotional response to feeling as if i'd (we'd?) been shit on for my
(our?) efforts. It's almost enough to make me want to take my toys and
go home.

Cheers,

drewc
Post by Daniel Weinreb
- The languages that have been vibrant and for which tools
are flourishing are the ones that are (a) perceived as
exciting, and/or (b) used by a large and/or growing
community.  It's hard to make this happen for Common
Lisp.
(Just for one example: consider why lisp.org still makes Lisp look like
a dusty historical artifact, as compared with python.org
or ruby.org.  The reasons for this are somewhat complicated
and historical, but, for whatever reasons, the problem
persists.)
- Nobody is paid to create better open-source Lisp programming
environments.  Doing a good IDE is hard.  Even doing a Lisp
plugin for Eclipse (which lets you share some of its existing
mechanisms) is hard enough that the only one I know of
is still pretty basic.  Even here at ITA where so many of
us use Lisp, I don't think we have one person assigned
to improve or supersede Slime.  We are trying get better code
coverage checking so that we can improve our unit testing,
but that's the only such thing going on that I am aware of.
- There is a lot of obsolete stuff in Common Lisp.  I and others
have written about this at some length.  See
http://ilc2009.scheming.org/node/7.
As for me, if the Google acquisition of ITA happens, chances
are that I won't be allowed to use Common Lisp, and that
it's unlikely that I'll ever have a chance to use it for
a paid job ever again.  Not impossible, but unlikely.
There are reasons for that.
So as much as we may agree with the problems you are
talking about, it's very hard to solve them for real.
-- Dan
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Sam Steingold
2011-01-20 21:16:10 UTC
Permalink
Post by Drew Crampsie
I do, however, think that comparing the work produced by the open
source CL community to that produced by multi-billion dollar
corporations is both unfair and counter-productive. Apple and Google
have something to sell, and are aggressively attempting to sell it to
both users and developers. Their /raison d'etre/ is to produce tools
that are useful for the casual developer and used by the masses.
The same can not be said of the Clozure team, the SBCL devs, the SLIME
folk or us working slobs just trying to make a living using CL. If i
had the resources of a mega-corporation behind me, do you think cliki
would be held together with duct-tape and bubble gum, or
common-lisp.net would look old and tired? Would the ALU wiki crash
every few months and be generally a mess to work with? I'd like to
think otherwise.
The root of the perceived problem is a lack of resources, not a lack
of effort or desire on the part of the "lisp community".
I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
I think the fact that none of them is paying anyone to maintain SLIME,
ALU wiki, common-lisp.net &c
is indicative of understandable but deplorable corporate myopia
("public goods cannot be produced by private businesses").
--
Sam Steingold <http://sds.podval.org>
Martin Cracauer
2011-01-20 21:20:21 UTC
Permalink
Post by Sam Steingold
I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
I think the fact that none of them is paying anyone to maintain SLIME,
ALU wiki, common-lisp.net &c
is indicative of understandable but deplorable corporate myopia
("public goods cannot be produced by private businesses").
From my perspective SLIME just doesn't work well enough that I would
have put some steam behind it.

Of course ilisp, which did work better for me, is now way too behind
the times to be rescued. So I guess I'm stuck unless I want to go
with Hemlock?

Franz and Lispworks all have their own Emacs and CL editor,
respectively. That might have to do with it :-)

Martin
--
Martin Cracauer, Programmer, ITA Software Inc, 617-714-2130
Edi Weitz
2011-01-20 21:40:50 UTC
Permalink
Post by Sam Steingold
I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
I think the fact that none of them is paying anyone to maintain SLIME,
ALU wiki, common-lisp.net &c
is indicative of understandable but deplorable corporate myopia
("public goods cannot be produced by private businesses").
All of those you mentioned have supported the CL community in various
ways, with money as well as with other resources. This includes
things like being a sponsor of the ALU (and thus at least indirectly
paying for the ALU website), sponsoring Lisp meetings and conferences,
helping open source projects with licenses and/or manpower, and other
things. It went even as far as Martin Simmons from LispWorks working
on SLIME himself although the company he is a director of sells its
own IDE.

Edi.
Drew Crampsie
2011-01-20 22:51:01 UTC
Permalink
Post by Sam Steingold
Post by Drew Crampsie
The root of the perceived problem is a lack of resources, not a lack
of effort or desire on the part of the "lisp community".
I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
I think the fact that none of them is paying anyone to maintain SLIME,
ALU wiki, common-lisp.net &c
is indicative of understandable but deplorable corporate myopia
("public goods cannot be produced by private businesses").
To be fair, i've never asked for financial contributions from anyone,
and perhaps that's something i should do. Perhaps a banner ad with my
sad face ala wikipedia. I've got a small team of developers with
experience doing web and systems apps in lisp, and we could be
convinced to work for peanuts given the glory involved ;).

In all seriousness, i think it's time i ask the community for some
help before i get (more) jaded and apathetic.

Cheers,

drewc
Post by Sam Steingold
--
Sam Steingold <http://sds.podval.org>
Daniel Weinreb
2011-01-20 21:54:47 UTC
Permalink
Post by Daniel Weinreb
As for me, if the Google acquisition of ITA happens, chances
are that I won't be allowed to use Common Lisp,
Sorry, what I meant was that it was unlikely
that we'd be able to use Common Lisp for
NEW projects. I am confident that Google
is not so brain-dead as to require us to
re-code what we have into, say, Java,
just for the sake of having it be in Java.

-- Dan
Post by Daniel Weinreb
and that
it's unlikely that I'll ever have a chance to use it for
a paid job ever again. Not impossible, but unlikely.
There are reasons for that.
So as much as we may agree with the problems you are
talking about, it's very hard to solve them for real.
-- Dan
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Pascal Costanza
2011-01-20 20:40:40 UTC
Permalink
Alex,

I think your approach is counterproductive. The Common Lisp community is not very large, and to the best of my knowledge, the majority of people _I_ know who are part of this community really try hard to improve the infrastructure, the libraries and the tools, to the extent they can afford to invest time and energy. Telling those people that they suck is not going to motivate them to do better and/or more.

One of the things you can also notice in the communities of more popular languages is that people get a lot more positive feedback, including for a lot more trivial contributions. I believe that this is one of the reasons (not the only one) why those other languages are popular in some cases.

You also have to take into account that most people invest time and energy into things they believe are important, or that are actually important to them. These things may not overlap a lot with the things that are important to you. But who are you to blame them, and who are they to blame you?

I would hope that the Common Lisp community becomes more positive and encouraging, rather than stay negative and discouraging. I believe that would be for the better.


Pascal
Post by Alexander Repenning
It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary.
Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum.
The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again"
best, Alex
This is a very nice essay to help people get over their
http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
--
Pascal Costanza, mailto:pc-***@public.gmane.org, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium
David Owen
2011-01-20 20:49:15 UTC
Permalink
Post by Pascal Costanza
One of the things you can also notice in the communities of more
popular languages is that people get a lot more positive feedback,
including for a lot more trivial contributions. I believe that this
is one of the reasons (not the only one) why those other languages
are popular in some cases.
This is an excllent observation! I've just added a task to my list to
identify and express gratitude for the libraries, &c that I use.

And, thanks to all on this list for good discussion!

Sincerely,
David
karol skocik
2011-01-20 21:22:18 UTC
Permalink
I would like to add, that in our community seems to be a very low
collaboration factor between random developers working on OSS
software, in comparison to other communities.
One would say, sure there are a lot of distinct interests, but this
happens even on common interests (decent utilities library for
example). So many half-baked efforts exists in utilities space, that
no one tries to merge together.
One would say - alexandria is the answer.
Some time ago, I tried to communicate on IRC channel about a very,
very simple addition:
string+, which is obviously a nice, small name for (apply
#'concatenate 'string strings).
I use it all the time in my projects, and basically copy such
trivialities all the time since I don't want to create yet another
my-half-baked-utils repository.
What happened on the channel had roughly this character:
- one person trying to persuade me, that writing (concatenate 'string
"a" "b") instead of (string+ "a" "b") is the way to go, even when I
explained it's verbose, and annoying when you do it a lot
- another arguing that HE don't have such needs (concatenating
strings), so he was negative (in a different way) about the addition
of this extremely simple, yet very convenient thing
- another was mildly ok about it, would't mind about it

The result, nothing was added. Recently, on alexandria mailing list,
the exactly same request arose. The result is the same. Some
developers clearly want to put themselves in the shoes on guarding
angels, and are intolerant to other people needs. CL has hundreds of
things, maybe I used 1/3 of them. Even in alexandria there is a lot of
stuff (at least 1/2 I didn't used yet, and probably never will. What's
the problem then?

Net result is - no collaboration in Lisp space. In Erlang community, I
fixed and extended about a dozen things, people care and are thankful.
In Lisp, I always have to argue with somebody.

Karol
Post by Pascal Costanza
One of the things you can also notice in the communities of more
popular languages is that people get a lot more positive feedback,
including for a lot more trivial contributions. I believe that this
is one of the reasons (not the only one) why those other languages
are popular in some cases.
This is an excllent observation!  I've just added a task to my list to
identify and express gratitude for the libraries, &c that I use.
And, thanks to all on this list for good discussion!
Sincerely,
David
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Tord Romstad
2011-01-21 10:20:25 UTC
Permalink
Post by karol skocik
Some time ago, I tried to communicate on IRC channel about a very,
string+, which is obviously a nice, small name for (apply
#'concatenate 'string strings).
Pet peeve: string+ is a *small* name, but it is not a *nice* name for
string concatenation. Additive notation for string concatenation is
extremely ugly and counter-intuitive for anyone who has studied
mathematics. It is extremely annoying that C++, JavaScript and a few
other languages have adopted this convention. Additive notation is
normally used for commutative operations, which string concatenation
is not.

There already is a standard notation for string concatenation, from
long before the days of computers and programming languages.
Mathematically, strings under concatenation is the free monoid
(http://en.wikipedia.org/wiki/Monoid) over the set of all available
characters. The single binary operation in a non-commutative monoid is
nearly always written as multiplication. And even if you don't know
anything about abstract algebra, multiplicative notation makes much
more sense: After all, even in elementary high school algebra, abc*de
equals abcde, but abc+de does not.

Therefore, if you really need a function for string concatenation and
want to share it with the world, please name it string*, not string+

Tord
Svante Carl v. Erichsen
2011-01-21 11:01:03 UTC
Permalink
Hi!

I should call it string-conc, conc-string, or conc->string. I should
not expect from first sight that either, string+ or string*, would
concatenate. From those names, it also would seem surprising that
they can take any sequences, not just strings, as arguments.

I see the main merit of creating such a function of reduced generality
in that you can pass it around as a simple #'string-conc instead of
(lambda (&rest sequences) (apply #'concatenate 'string sequences)).

Best wishes

Svante
Post by Tord Romstad
Post by karol skocik
Some time ago, I tried to communicate on IRC channel about a very,
string+, which is obviously a nice, small name for (apply
#'concatenate 'string strings).
Pet peeve: string+ is a *small* name, but it is not a *nice* name for
string concatenation. Additive notation for string concatenation is
extremely ugly and counter-intuitive for anyone who has studied
mathematics. It is extremely annoying that C++, JavaScript and a few
other languages have adopted this convention. Additive notation is
normally used for commutative operations, which string concatenation
is not.
There already is a standard notation for string concatenation, from
long before the days of computers and programming languages.
Mathematically, strings under concatenation is the free monoid
(http://en.wikipedia.org/wiki/Monoid) over the set of all available
characters. The single binary operation in a non-commutative monoid is
nearly always written as multiplication. And even if you don't know
anything about abstract algebra, multiplicative notation makes much
more sense: After all, even in elementary high school algebra, abc*de
equals abcde, but abc+de does not.
Therefore, if you really need a function for string concatenation and
want to share it with the world, please name it string*, not string+
Tord
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
- --
Svante Carl v. Erichsen
Wentorfer Str. 96
21029 Hamburg

+49-(0)40-34923721
+49-(0)160-6941474
Svante.v.Erichsen-S0/***@public.gmane.org
Tord Romstad
2011-01-21 11:39:39 UTC
Permalink
On Fri, Jan 21, 2011 at 12:01 PM, Svante Carl v. Erichsen
Post by Svante Carl v. Erichsen
I should call it string-conc, conc-string, or conc->string.
I actually agree. What I meant is that if you really want to use a
mathematical operator for this, multiplication is the natural choice.
Your suggestions above -- at least the first two -- are of course
better still.

Tord
karol skocik
2011-01-21 11:57:06 UTC
Permalink
I didn't really about the name that much (unless it's overly verbose).
The problem I tried to mention was the attitude of other developers to
such a simple addition.

Karol
Post by Tord Romstad
On Fri, Jan 21, 2011 at 12:01 PM, Svante Carl v. Erichsen
Post by Svante Carl v. Erichsen
I should call it string-conc, conc-string, or conc->string.
I actually agree. What I meant is that if you really want to use a
mathematical operator for this, multiplication is the natural choice.
Your suggestions above -- at least the first two -- are of course
better still.
Tord
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Stas Boukarev
2011-01-21 12:09:39 UTC
Permalink
Post by Svante Carl v. Erichsen
Hi!
I should call it string-conc, conc-string, or conc->string. I should
not expect from first sight that either, string+ or string*, would
concatenate. From those names, it also would seem surprising that
they can take any sequences, not just strings, as arguments.
I see the main merit of creating such a function of reduced generality
in that you can pass it around as a simple #'string-conc instead of
(lambda (&rest sequences) (apply #'concatenate 'string sequences)).
Scheme has string-append.
--
With Best Regards, Stas.
Daniel Weinreb
2011-01-21 12:48:50 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
I should call it string-conc, conc-string, or conc->string. I should
not expect from first sight that either, string+ or string*, would
concatenate. From those names, it also would seem surprising that
they can take any sequences, not just strings, as arguments.
I see the main merit of creating such a function of reduced generality
in that you can pass it around as a simple #'string-conc instead of
(lambda (&rest sequences) (apply #'concatenate 'string sequences)).
Best wishes
Svante
Post by Tord Romstad
Post by karol skocik
Some time ago, I tried to communicate on IRC channel about a very,
string+, which is obviously a nice, small name for (apply
#'concatenate 'string strings).
Pet peeve: string+ is a *small* name, but it is not a *nice* name for
string concatenation. Additive notation for string concatenation is
extremely ugly and counter-intuitive for anyone who has studied
mathematics. It is extremely annoying that C++, JavaScript and a few
other languages have adopted this convention. Additive notation is
normally used for commutative operations, which string concatenation
is not.
There already is a standard notation for string concatenation, from
long before the days of computers and programming languages.
Mathematically, strings under concatenation is the free monoid
(http://en.wikipedia.org/wiki/Monoid) over the set of all available
characters. The single binary operation in a non-commutative monoid is
nearly always written as multiplication. And even if you don't know
anything about abstract algebra, multiplicative notation makes much
more sense: After all, even in elementary high school algebra, abc*de
equals abcde, but abc+de does not.
Therefore, if you really need a function for string concatenation and
want to share it with the world, please name it string*, not string+
Tord
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
- --
Svante Carl v. Erichsen
Wentorfer Str. 96
21029 Hamburg
+49-(0)40-34923721
+49-(0)160-6941474
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk05Z28ACgkQFZBb0npmKszsaACfakZ+2dcC/DXGkB1sfbiNhEL4
CJEAn23exdW3M6E7LFGIFV539p2r6Tgv
=quCk
-----END PGP SIGNATURE-----
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Our utility library calls it "strcat". I think string-concat
is probaby better.

Dave Moon established the general ethic on the Lisp
machine of using longer, clearer names in general.
This may be because we were coming off the PDP-10
ITS system, in which many terms were in all caps
and six or fewer characters, which could be fit
into one PDP-10 word using "sixbit" encoding,
and we were particularly sick of short names.
But I don't think it really was because of that.
It was more like "computers are powerful
now and we write programs for people to
read, not to fit into tiny amounts of core".

-- Dan
Erik Winkels
2011-01-21 13:43:08 UTC
Permalink
Our utility library calls it "strcat". I think string-concat is
probaby better.
Dave Moon established the general ethic on the Lisp machine of using
longer, clearer names in general.
I generally prefer more descriptive (and hence usually longer) names
but for this specific case I settled on "mkstr" from Paul Graham's "On
Lisp" years ago, because this function is used so often and many times
used inline.
Scott McKay
2011-01-21 14:07:24 UTC
Permalink
Post by Erik Winkels
Our utility library calls it "strcat". I think string-concat is
probaby better.
I picked 'strcat' as a nod to C, but I wholeheartedly fall into
the Dave Moon camp: more descriptive is better, at least for any
exported names, almost always.
Post by Erik Winkels
Dave Moon established the general ethic on the Lisp machine of using
longer, clearer names in general.
I generally prefer more descriptive (and hence usually longer) names
but for this specific case I settled on "mkstr" from Paul Graham's "On
Lisp" years ago, because this function is used so often and many times
used inline.
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Luke Crook
2011-01-21 17:00:48 UTC
Permalink
Post by Tord Romstad
Post by karol skocik
Some time ago, I tried to communicate on IRC channel about a very,
string+, which is obviously a nice, small name for (apply
#'concatenate 'string strings).
Therefore, if you really need a function for string concatenation and
want to share it with the world, please name it string*, not string+
To my eye, string* would indicate a function that performs the same
function as string, but with a different set of args.

For example draw-rect and draw-rect-*

-Luke
Vladimir Sedach
2011-01-21 04:33:58 UTC
Permalink
I really didn't appreciate this whole discussion, but I think I can
contribute a few points about how to think about the problem so that
things like this will stop happening.

There are two assertions being made here:

* "Lisp is falling behind"
* "To stop Lisp falling behind, we need to do <X>"

No one has provided any quantitative evidence for either.

How is Lisp "falling behind?" Compared to what? And what effect does
that have? What effect does that have on you personally?

Why do you think doing <X> will be good? Did anyone ask for <X>? Is it
actually preventing people from doing things? How can you tell <X>
will work when you can't even quantify the "falling behind" thing <X>
is supposed to change?

What is the basic pattern behind this argument? Alexander, I will use
your original post as an example, please don't take it personally:
"Lisp is dying: some JavaScript implementation is slower than Clozure;
let's work on the Clozure IDE!" Where is the logic here? Most of these
arguments use "Lisp is dying" handwaving to promote a personal
project, and in most of these cases no one outside the current Lisp
community cares about the issue.

What does it mean to say "Lisp is falling behind?" There aren't enough
people using it? Have you tried listening to people who have tried and
failed to use Lisp? Do you understand the difference between a reason
and a rationalization?

There are people who rationalize not using Lisp by saying it has
parentheses, and there are people who have a reason for not using Lisp
because they can't find the libraries they need. Listening to the
former is a waste of time, listening to the latter will give you a way
to actionably decrease the "Lisp falling behind" and measure it.

Here are some things I notice people actually saying:

1. The #1 problem is that people (and this includes even people who
have been using Lisp for decades and post to this list, not going to
name names :)) have misconceptions about what current Lisp
implementations, libraries and tools can do. And this is just the
people that know about the existence of Lisp. Simply letting people
know about Lisp and how great it is is the most direct way you can get
more people to use it.

2. There are no libraries to do <X>/I can't find any libraries.
Improve and promote the existing libraries. Write new ones for some
service/software/function that isn't possible from Lisp yet. Put a
description of your library on CLiki, ask Zach to add it to Quicklisp.
Help improve the existing library listings in CLiki. Help with
Quicklisp, add metadata and search stuff to Quicklisp projects
(https://github.com/quicklisp/quicklisp-projects). Give Zach money.
Basically anything that makes Quicklisp better is good.

3. How do I deploy applications? Web apps (the story here is
incredibly bad -
http://stackoverflow.com/questions/2458805/nohup-sbcl-ubuntu-couldnt-read-from-standard-input/2459674#2459674)?
Work on cl-launch, lispx-proxy, cl-daemonize

This is today's list, it will change tomorrow. The important thing is
to understand what's really going on, and the psychology behind it.
Which is why the last thing I'm going to say is that saying "Lisp is
dying" is destructive. If Lisp experts are saying our community is a
loser, why would anyone want anything to do with Lisp? Stop doing it.

------

Now I'm going to reply to Dan.

I think ITA's attitude of "I wish we didn't write qpx in Lisp but it's
the only thing good enough" is bizarre. That no one was assigned even
part time to be a "Lisp evangelist" was a *strategic* mistake. It
would have saved ITA hundreds of thousands in recruitment costs, and
improved productivity through an improved Free Software Lisp
ecosystem.

Another thing is the "I won't be allowed to use Common Lisp" attitude.
This is the perfect opportunity to force Common Lisp into Google, and
you're walking in expecting to fail.

Vladimir
r***@public.gmane.org
2011-01-21 17:20:21 UTC
Permalink
Post by Vladimir Sedach
2. There are no libraries to do <X>/I can't find any libraries.
It may sound shocking, but there's non-programmers out there who
complain if there isn't a free-as-in-beer application to do what they
want. This argument is the programmer corollary. It always appears to
me as though the real argument is "No one else has already done my work
for me." But then, when I first learned C, we got stdio and stdlib, and
nothing else, really, so my view may be skewed.

I do find discussions that pit the syntaxes of Lisp vs. other languages
very amusing, and not for the reason most Lisp users might. Yes, many
new languages have long drawn out discussions about how their syntax
should change, while Lisp has had the same syntax for a very long time.
But here's where libraries come in...

It seems like an awful lot of Lisp libraries exist to wank about with
the language than libraries in other languages, rather than to actually
do the sort of tasks that programmers look to do. This may make it look
like Lisp is defective. After all, if you need a bunch of libraries to
'correct' the language, it can't be any good, right? And because there
seems to be several libraries to 'correct' the same problem in
different ways, it's pretty obvious that the 'community' can't even
agree on how to do it. In some people's minds, this is a problem.

(And yes, I know that it's a rather superficial view, but from someone
casually considering Lisp, a superficial view is all you're going to
get).

Neil Gilmore
raito-***@public.gmane.org
Nick Levine
2011-01-21 19:34:16 UTC
Permalink
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.

To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)

- nick
Pascal Costanza
2011-01-21 19:46:18 UTC
Permalink
Post by Nick Levine
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.
To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)
We're getting there. See http://www.quicklisp.org/

Especially, see http://www.quicklisp.org/beta/releases.html


Pascal
--
Pascal Costanza, mailto:pc-***@public.gmane.org, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium
Nick Levine
2011-01-21 19:59:39 UTC
Permalink
We're getting there. See http://www.quicklisp.org/

Especially, see http://www.quicklisp.org/beta/releases.html

It doesn't say what any one of them do. There's no way (am I right?)
to look up form what I want to do to what exists to do it.

- n
Zach Beane
2011-01-21 20:02:35 UTC
Permalink
Post by Pascal Costanza
We're getting there. See http://www.quicklisp.org/
Especially, see http://www.quicklisp.org/beta/releases.html
It doesn't say what any one of them do. There's no way (am I right?)
to look up form what I want to do to what exists to do it.
Very true, and something I'd like to add.

Right now it's mostly useful for the "I already know I want Hunchentoot,
but what a pain to get all the dependencies" group. I need to make it
more useful to the "I want to make a website, but what a pain to figure
out where to start" group.

Zach
Steve Morin
2011-01-21 20:12:34 UTC
Permalink
I have been a beginner lisp developer for years largely because the is just
a large problem with answering the question "I want to make a website, but
what a pain to figure
out where to start", I want to X. I would be down to contribute.

This lisp learning curve is large, and figuring out the exact resources that
are available is harder. Especially because it's hard to tell from the
outside what is being maintained and up todate, and what works on which cl
distribution.

This sounds like some thing that can be added to http://common-lisp.net/ or
http://www.cliki.net/
Post by Zach Beane
Post by Pascal Costanza
We're getting there. See http://www.quicklisp.org/
Especially, see http://www.quicklisp.org/beta/releases.html
It doesn't say what any one of them do. There's no way (am I right?)
to look up form what I want to do to what exists to do it.
Very true, and something I'd like to add.
Right now it's mostly useful for the "I already know I want Hunchentoot,
but what a pain to get all the dependencies" group. I need to make it
more useful to the "I want to make a website, but what a pain to figure
out where to start" group.
Zach
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
--
Steve Morin | Hacker, Entrepreneur, Startup Advisor
twitter.com/SteveMorin | stevemorin.com
*Live the dream start a startup. Make the world ... a better place.*
Zach Beane
2011-01-21 19:47:58 UTC
Permalink
Post by Nick Levine
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.
To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)
It's getting better with Quicklisp (I get frequent emails from people
who write to say "I am getting back into Lisp because of this!") but
there's still a long way to go. Things are improving, little by little.

Zach
Zach Beane
2011-01-21 20:00:19 UTC
Permalink
Not to sound like I'm complaining (quicklisp is awesome btw), but if http://
www.quicklisp.org/beta/releases.html had descriptions of what the packages
actually did (or links to their respective homepage, or docstrings, or
something), that would be wonderful.
That's one of the reasons why it's still in beta. I need to gather
useful, descriptive info about each project and make it easily
available.

Zach
Pascal Costanza
2011-01-21 20:09:19 UTC
Permalink
Post by Zach Beane
Not to sound like I'm complaining (quicklisp is awesome btw), but if http://
www.quicklisp.org/beta/releases.html had descriptions of what the packages
actually did (or links to their respective homepage, or docstrings, or
something), that would be wonderful.
That's one of the reasons why it's still in beta. I need to gather
useful, descriptive info about each project and make it easily
available.
What would you recommend to the library providers to make this job easier for you? Could we maybe add tags to ASDF defsystem forms that you could parse, or something along these lines?


Pascal
--
Pascal Costanza, mailto:pc-***@public.gmane.org, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium
Didier Verna
2011-01-21 20:22:03 UTC
Permalink
Post by Pascal Costanza
Post by Zach Beane
That's one of the reasons why it's still in beta. I need to gather
useful, descriptive info about each project and make it easily
available.
What would you recommend to the library providers to make this job easier for you? Could we maybe add tags to ASDF defsystem forms that you could parse, or something along these lines?
At least for human-readable descriptions, people should make the
effort to provide nice :long-description fields in their ASDF systems.
--
Resistance is futile. You will be jazzimilated.

Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
Drew Csillag (sounds like cheese-log)
2011-01-21 19:52:42 UTC
Permalink
Not to sound like I'm complaining (quicklisp is awesome btw), but if
http://www.quicklisp.org/beta/releases.html had descriptions of what the
packages actually did (or links to their respective homepage, or docstrings,
or something), that would be wonderful.
Post by Zach Beane
Post by Nick Levine
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.
To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)
It's getting better with Quicklisp (I get frequent emails from people
who write to say "I am getting back into Lisp because of this!") but
there's still a long way to go. Things are improving, little by little.
Zach
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Chris Perkins
2011-01-21 20:02:16 UTC
Permalink
Using (string-count-str (get-url-as-string
"http://docs.python.org/py3k/modindex.html") "#module")

I show that there are 291 projects listed on that python page.

But (string-count-str (get-url-as-string
""http://common-lisp.net/projects.shtml") "/project/")

tells me that there are 416 projects listed on
http://common-lisp.net/projects.shtml

And I don't have to scrape the Common Lisp Directory (
http://www.cl-user.net/asp/root-dir ), it lists 641 entries in
Libraries/Tools/Software.



So, yes, it would appear that the Python people are rather library
starved compared to us Common Lisp users. I can definitely see why
people would get frustrated using Python and be flocking to Lisp.


;-)

Chris
Post by Nick Levine
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.
To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)
- nick
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
Alessio Stalla
2011-01-21 20:50:38 UTC
Permalink
Post by Nick Levine
Post by Vladimir Sedach
I can't find any libraries.
I think this is one of the most serious issues which is blocking the
growth of lisp use. Speaking as someone who recently gave up trying to
write a book on how to use CL's libraries: locating them and knowing
in advance of downloading them what their purpose is are major
problems and not to be sniffed at.
To see what I mean, go to http://docs.python.org/py3k/modindex.html
and click on some stuff at random. What CL has to offer should be as
good as this. For all I know, maybe it is that good, but the
information isn't there. How would I know? (Or am I behind the times
and this has been fixed now?)
Just a dumb example, I don't want to put up any Lisp vs Python war or
anything, but in the Python list you posted, I see only one mention of
"user interface". A common complaint against Lisp is that it has no
GUI libraries. It's just one data point that means almost nothing, but
my feeling is that people have much higher expectations from Lisp than
from other comparable languages. Lisp just cannot be like Java or C#
without an Oracle or a Microsoft paying the cost. That's why many
languages, Lisp and Python included, end up having an implementation
on the JVM and/or the CLR.
Hans Hübner
2011-01-21 20:58:13 UTC
Permalink
People are beginning to complain that the pro@ list is becoming
similar to comp.lang.lisp, and there also have been several
unsubscriptions today and yesterday. Can this topic please be put to
a rest or taken where it belongs?

Thanks,
Hans

Loading...