From: Don Geddis on 6 Dec 2009 13:34 "W. James" <w_a_x_man(a)yahoo.com> wrote on 6 Dec 2009 13:44: > Guy L. Steele, Jr., July 1989: > I think we may usefully compare the approximate number of pages > in the defining standard or draft standard for several > programming languages: > Common Lisp 1000 or more [...] > Scheme 50 What is useful about that comparison? _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don(a)geddis.org
From: mpeever on 6 Dec 2009 15:11 On Dec 5, 10:35 pm, Tamas K Papp <tkp...(a)gmail.com> wrote: > On Sun, 06 Dec 2009 11:44:43 +1100, Tim X wrote: > > mpeever <mpee...(a)gmail.com> writes: > > >> I've been experimenting with CL scripting for about a year now. We've > >> got a significant amount of SBCL code working in our Legato Networker > >> environment. We've started small, but so far we're really happy with > >> it. I'm currently considering the benefits of replacing some > >> significant Perl processes in CL. There are some pending changes that > >> are much more daunting in Perl than CL. > > >> We wrote a quick-and-dirty toolkit to clean up some of the OS > >> interfacing: we've more or less tried to imitate Perl's operators. Our > >> toolkit appears to work on SBCL, CCL, and ECL. Making it support > >> multiple implementations was important, as we're still very much in > >> pilot mode: we may yet have to make some drastic changes and we need to > >> be able to move quickly. > > >> We've been taking advantage of the core-dump facilities in CL > >> implementations for code roll-outs. It makes updates and changes very > >> simple, especially once we hit a critical mass point. > > >> I'm very interested to hear about your experiences. > > > While I can see the appeal of using CL for scripting, I'm interested in > > why people choose this approach rather than using one of the lispy > > dialects that have been specifically designed for this type of purpose. > > I'm thinking of things like guile, lush, rep etc. > > For me, it takes a lot of time to learn all the nooks and crannies of > a language, and doing this for the occasional script doesn't justify > the investment. Maybe all those dialects are "lispy", but they have > different names for standard functions, slightly different semantic > conventions, etc, all of which would lead to minor annoyances. So I > chose to roll the thing in CL, and I was pleased, it took very little > time. I will continue to do these things in the future. > > Tamas > > BTW, lush sucks bigtime, eg it doesn't have lexical scoping. I tried the > it a while ago and it was a major disappointment. For us, it was somewhat an historical accident: I had an SBCL REPL open when I was thinking about what I needed, so I started modeling it there. I intended to port it to Perl, but we decided just to install SBCL on the target system and see how it worked. It's not broken, so we haven't fixed it. From a political standpoint, using anything other than Perl has been a bit of a risk for us. It's silly, but it's the old "it's to hard to find someone how knows Lisp" argument. While that may be true, it's pretty hard to find people who actually know Perl too. A lowest-common- denominator approach doesn't work very well in ANY language. When we replace this system, it'll be time to re-examine our use of CL. Until then, we really need to either stick with CL or go back to Perl.
From: Pillsy on 6 Dec 2009 22:05 On Dec 5, 7:44 pm, Tim X <t...(a)nospam.dev.null> wrote: [...] > While I can see the appeal of using CL for scripting, I'm interested in > why people choose this approach rather than using one of the lispy > dialects that have been specifically designed for this type of purpose. > I'm thinking of things like guile, lush, rep etc. The main reason for me is that it's not clear that the advantage they provide is sufficient to make up for the learning curve. It may not be that steep, but I know CL now, I have CL installed now, and with a few common libraries and custom macros it's very capable of getting the job done. A secondary reason is that if the script starts growing beyond simple throwaway code, I know that CL is capable of coping. It has good compilers, a powerful and flexible object system, and conditions, which I prefer to any other error-handling system I've used. Why not stick with a language I know and like that I'm confident can get the job at hand done well, and will still be useful if the job at hand grows into something more involved? Cheers, Pillsy
From: Tim X on 7 Dec 2009 01:31 "W. James" <w_a_x_man(a)yahoo.com> writes: > Tim X wrote: > >> While I can see the appeal of using CL for scripting, I'm interested in >> why people choose this approach rather than using one of the lispy >> dialects that have been specifically designed for this type of purpose. >> I'm thinking of things like guile, lush, rep etc. > > I cannot see "appeal" of Commune-Lisp for anything. Fine, I didn't ask if you liked it or not. I asked those who do why they chose it rather than one of the other lisp dialects. I'm not interested in your unoriginal re-hashing of uninteresting irrelevant quotes in an attempt to either start a flame war or push your own boring agenda. -- tcross (at) rapttech dot com dot au
From: Tim X on 7 Dec 2009 01:39
Tamas K Papp <tkpapp(a)gmail.com> writes: > On Sun, 06 Dec 2009 11:44:43 +1100, Tim X wrote: > >> mpeever <mpeever(a)gmail.com> writes: >> >>> I've been experimenting with CL scripting for about a year now. We've >>> got a significant amount of SBCL code working in our Legato Networker >>> environment. We've started small, but so far we're really happy with >>> it. I'm currently considering the benefits of replacing some >>> significant Perl processes in CL. There are some pending changes that >>> are much more daunting in Perl than CL. >>> >>> We wrote a quick-and-dirty toolkit to clean up some of the OS >>> interfacing: we've more or less tried to imitate Perl's operators. Our >>> toolkit appears to work on SBCL, CCL, and ECL. Making it support >>> multiple implementations was important, as we're still very much in >>> pilot mode: we may yet have to make some drastic changes and we need to >>> be able to move quickly. >>> >>> We've been taking advantage of the core-dump facilities in CL >>> implementations for code roll-outs. It makes updates and changes very >>> simple, especially once we hit a critical mass point. >>> >>> I'm very interested to hear about your experiences. >> >> While I can see the appeal of using CL for scripting, I'm interested in >> why people choose this approach rather than using one of the lispy >> dialects that have been specifically designed for this type of purpose. >> I'm thinking of things like guile, lush, rep etc. > > For me, it takes a lot of time to learn all the nooks and crannies of > a language, and doing this for the occasional script doesn't justify > the investment. Maybe all those dialects are "lispy", but they have > different names for standard functions, slightly different semantic > conventions, etc, all of which would lead to minor annoyances. So I > chose to roll the thing in CL, and I was pleased, it took very little > time. I will continue to do these things in the future. > > Tamas > > BTW, lush sucks bigtime, eg it doesn't have lexical scoping. I tried the > it a while ago and it was a major disappointment. thanks Tamas. I'm interested as I'd prefer to write scripts in a more lisp like environment. I've been debating which direction to go. To be honest, I've been leaning towards using guile over common lisp as it seems a bit more suited to the types of things I often need to do in a script, is more commonly found already installed on GNU Linux based systems and possibly is a little 'lighter' than many of the CL implementations. Lush was another one I was wondering about. Lack of lexical scoping is possibly an issue, not sure. need to give it some thought. Would certainly be an issue for anything larger/complex, but possibly not a big issue for many smaller tasks. What I really want is something fairly light-weight that I can use to do fairly simple scripts in. While shell, perl etc all work fine - I'm interested to see what benefits there may be in not having to switch between different paradigms as much. Tim -- tcross (at) rapttech dot com dot au |