[pro] Learning Lisp the Bump Free Way
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
One point made:
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 On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote:
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
Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning <ralex@cs.colorado.edu> wrote:
One point made:
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
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning <ralex@cs.colorado.edu> wrote:
One point made:
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
On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer <cracauer@itasoftware.com> wrote:
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning <ralex@cs.colorado.edu> wrote:
One point made:
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 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
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:46:15PM +0100:
On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer <cracauer@itasoftware.com> wrote:
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning <ralex@cs.colorado.edu> wrote:
One point made:
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
On Thu, Jan 20, 2011 at 11:38 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:
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@gmail.com http://treerex.blogspot.com/
Alex: I realize this isn't your central point but I'm curious what benchmark(s) you're citing? On Thu, Jan 20, 2011 at 11:04 AM, Alexander Repenning <ralex@cs.colorado.edu
wrote:
One point made:
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
On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote:
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
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 pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
On Jan 20, 2011, at 10:08 AM, Brian Taylor wrote:
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
On Thu, Jan 20, 2011 at 11:04 AM, Alexander Repenning <ralex@cs.colorado.edu> wrote: One point made:
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
On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote:
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
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 pro@common-lisp.net 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
[Forgot to reply all, so this went as a private mail to Alexander] On Thursday 20 January 2011 09:34 PM, Alexander Repenning wrote:
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/
Alexander Repenning wrote:
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
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 On 20 Jan 2011, at 17:04, Alexander Repenning wrote:
One point made:
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
On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote:
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
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 pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
-- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium
On Thu, 20 Jan 2011, Pascal Costanza wrote:
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
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 On Thu, Jan 20, 2011 at 9:49 PM, David Owen <dsowen@fugue88.ws> wrote:
On Thu, 20 Jan 2011, Pascal Costanza wrote:
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 pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
On Thu, Jan 20, 2011 at 10:22 PM, karol skocik <karol.skocik@gmail.com> wrote:
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).
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
-----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 Am 21.01.2011 11:20, schrieb Tord Romstad:
On Thu, Jan 20, 2011 at 10:22 PM, karol skocik <karol.skocik@gmail.com> wrote:
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).
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 pro@common-lisp.net 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@web.de -----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-----
On Fri, Jan 21, 2011 at 12:01 PM, Svante Carl v. Erichsen <Svante.v.Erichsen@web.de> wrote:
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
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 On Fri, Jan 21, 2011 at 12:39 PM, Tord Romstad <tord.romstad@gmail.com> wrote:
On Fri, Jan 21, 2011 at 12:01 PM, Svante Carl v. Erichsen <Svante.v.Erichsen@web.de> wrote:
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 pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
"Svante Carl v. Erichsen" <Svante.v.Erichsen@web.de> writes:
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.
On 1/21/11 6:01 AM, Svante Carl v. Erichsen wrote:
-----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
Am 21.01.2011 11:20, schrieb Tord Romstad:
On Thu, Jan 20, 2011 at 10:22 PM, karol skocik<karol.skocik@gmail.com> wrote:
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). 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 pro@common-lisp.net 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@web.de -----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 pro@common-lisp.net 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
On Fri, Jan 21, 2011 at 07:48:50AM -0500, Daniel Weinreb wrote:
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.
On Jan 21, 2011, at 8:43 AM, Erik Winkels wrote:
On Fri, Jan 21, 2011 at 07:48:50AM -0500, Daniel Weinreb wrote:
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.
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 pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
On Jan 21, 2011, at 2:40, Tord Romstad <tord.romstad@gmail.com> wrote:
On Thu, Jan 20, 2011 at 10:22 PM, karol skocik <karol.skocik@gmail.com> wrote:
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).
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
participants (16)
-
Alessio Stalla -
Alexander Repenning -
Brian Taylor -
Chaitanya Gupta -
Daniel Weinreb -
David Owen -
Erik Winkels -
karol skocik -
Luke Crook -
Martin Cracauer -
Pascal Costanza -
Scott McKay -
Stas Boukarev -
Svante Carl v. Erichsen -
Tom Emerson -
Tord Romstad