scripting in CL -- please comment
in [Lisp]
|
From: Kaz Kylheku on 7 Dec 2009 16:18 On 2009-12-07, André Thieme <address.good.until.2009.dec.14(a)justmail.de> wrote: > If Ruby would have a standard which documents all functions in > detail that ship by default with Ruby, how many pages would that > fill? Less than 3000? That's not measured in pages, but Kloc's. :)
From: mpeever on 8 Dec 2009 12:14 On Dec 7, 1:19 am, Tamas K Papp <tkp...(a)gmail.com> wrote: > On Mon, 07 Dec 2009 17:39:41 +1100, Tim X wrote: > > 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. > > Guile could be OK, if you make use of the extended features. > Nevertheless, I think that you should consider CL too. It is a much > more mature language, and the current free implementations are really > good, producing fast programs. "Lightness" is not really an issue: CL > is about the same size as a mature Scheme implementation with all the > bells and whistles, except that you won't be able to change > implementations so easily. This is an important thing: I have been > playing around with ECL in the past few days and found that most of > the code I used on SBCL runs with a few modifications (changing some > implementation-dependent stuff, and correcting some false assumptions > I had about CL :-). This is a big advantage. And installing a Lisp > on most modern distros takes a few seconds (eg apt-get install sbcl). > > > 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. > > Lush is really an archaic language. From the Lush FAQ: "The design of > the interpreter is pre-Scheme/pre-CommonLisp, and it shows." I think > it is a dead end, and it is a waste of time to learn things like that. > > > 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. > > I never really understood what people mean by "light-weight". Small > memory footprint? Small standard library? Few language features? > Ease of deployment? The way people use the phrase suggests that they > are thinking of some trade-off, ie "non-lightweight" languages having > some disadvantages. I don't really see any issues with CL. > > Cheers, > > Tamas I tried Guile, but it was very difficult to get it to install on my Mac. That's essentially a deal-breaker for me, as I work on Mac and Linux more-or-less interchangeably. Gambit Scheme is very promising as a "scripting language", and it may eventually gain enough support around here to end up as the lisp of choice. There is interest in Gambit outside my team, and that sort of thing might make it gain some traction. I've used it some on my personal machines, and it's really a very good language for hacking out solutions. But CL works fine as a scripting language with a little investment up front. And as others have pointed out, a very little attention to portability makes it a snap to get it to run more or less uniformly on several platforms. The ability to ratchet up a script iteratively helps too. E.g., in one place, we started out passing around plists; once we had a better feel for what we wanted, we started replacing plists with structs. The code got more formal as the "project" went on, and CL kept up. Perl could have kept up with it, but it would taken more effort to refactor. Those changes just seemed natural in CL.
From: Rob Warnock on 11 Dec 2009 22:16 Tamas K Papp <tkpapp(a)gmail.com> wrote: +--------------- | Tim X wrote: | > 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. | | I never really understood what people mean by "light-weight". Small | memory footprint? Small standard library? Few language features? | Ease of deployment? The way people use the phrase suggests that they | are thinking of some trade-off, ie "non-lightweight" languages having | some disadvantages. I don't really see any issues with CL. +--------------- Ditto, especially once I found out how well Linux & FreeBSD cache mmap'd files such as CMUCL's executable and core image files -- the startup times [except maybe the very first one after a reboot] are plenty fast for "simple scripting": $ cat test_cmucl #!/usr/local/bin/cmucl -script (format t "Hello, world!~%") $ time ./test_cmucl Hello, world! 0.006u 0.006s 0:00.01 0.0% 0+0k 0+0io 0pf+0w $ time-hist ./test_cmucl Timing 100 runs of: ./test_cmucl 92 0.012 8 0.013 $ IMHO, 12 milliseconds is an acceptable penalty for getting to use full Common Lisp for my scripting. CMUCL has one more feature that makes "simple scripting" even more "light-weight": lazy parsing of function bodies. That is, when you do a top-level DEFUN, the body isn't "converted" [macroexpanded and then parsed into tree code for the interpreter] until you call it the first time [or reference it as a function value]. This means that scripts that define a whole bunch of functions but only call one or two of them [depending on command-line args] run faster than if the whole script were converted [or worse, *compiled*!] before anything is executed. And for any really heavy lifting a script can always REQUIRE previously- compiled code. [Or even *be* previously-compiled code, see "p.s." below.] As a result, I've been using CMUCL for almost all my miscellaneous "scripting" for a number of years. At any point in time, I generally have ~60 CMUCL "script" in my "$HOME/bin/" directory. -Rob p.s. True, stock CMUCL doesn't support the "-script" option demonstrated above. See <http://rpw3.org/hacks/lisp/site-switch-script.lisp> for a plugin that adds that [and also supports slapping a "#!" line on CMUCL compiled FASL files to make *them* "executable" as well]. ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Tim X on 12 Dec 2009 23:10 rpw3(a)rpw3.org (Rob Warnock) writes: > Tamas K Papp <tkpapp(a)gmail.com> wrote: > +--------------- > | Tim X wrote: > | > 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. > | > | I never really understood what people mean by "light-weight". Small > | memory footprint? Small standard library? Few language features? > | Ease of deployment? The way people use the phrase suggests that they > | are thinking of some trade-off, ie "non-lightweight" languages having > | some disadvantages. I don't really see any issues with CL. > +--------------- > > Ditto, especially once I found out how well Linux & FreeBSD cache > mmap'd files such as CMUCL's executable and core image files -- the > startup times [except maybe the very first one after a reboot] are > plenty fast for "simple scripting": > > $ cat test_cmucl > #!/usr/local/bin/cmucl -script > (format t "Hello, world!~%") > $ time ./test_cmucl > Hello, world! > 0.006u 0.006s 0:00.01 0.0% 0+0k 0+0io 0pf+0w > $ time-hist ./test_cmucl > Timing 100 runs of: ./test_cmucl > 92 0.012 > 8 0.013 > $ > > IMHO, 12 milliseconds is an acceptable penalty for getting to use > full Common Lisp for my scripting. > > CMUCL has one more feature that makes "simple scripting" even more > "light-weight": lazy parsing of function bodies. That is, when you do > a top-level DEFUN, the body isn't "converted" [macroexpanded and then > parsed into tree code for the interpreter] until you call it the first > time [or reference it as a function value]. This means that scripts > that define a whole bunch of functions but only call one or two of them > [depending on command-line args] run faster than if the whole script > were converted [or worse, *compiled*!] before anything is executed. > > And for any really heavy lifting a script can always REQUIRE previously- > compiled code. [Or even *be* previously-compiled code, see "p.s." below.] > > As a result, I've been using CMUCL for almost all my miscellaneous > "scripting" for a number of years. At any point in time, I generally > have ~60 CMUCL "script" in my "$HOME/bin/" directory. > > > -Rob > > p.s. True, stock CMUCL doesn't support the "-script" option demonstrated > above. See <http://rpw3.org/hacks/lisp/site-switch-script.lisp> for a > plugin that adds that [and also supports slapping a "#!" line on CMUCL > compiled FASL files to make *them* "executable" as well]. > > ----- Thanks Rob. Actually, it was some of the stuff you posted a while back re: using Cl for scripting that provided the seed for me to consider using Cl in such a way. At the time, I was quite impressed to see how clear and straight-forward some of it was. Most of the replies in this thread pretty much confirmed the way I was leaning already. In some of my home projects, I've used CL where once upon a time, I would have used perl or a shell script. I'd now like to start using CL at work more. I've done so in a limited way with a couple of application prototypes that worked quite well. However, using it for some scripts may be a harder battle to win, so I was really looking for some counter arguments. Not sure if it will do any good - its still mainly FUD I run into rather than anything of real substance. The difficulty with using it for scripting is that a lot of others will see what I'm doing. With theprototypes I've done, CL was OK because if it all whent badly, it was just my head that would roll. However, letting CL get into core areas is another story. My other concern is my CL skill level. While I've been using CL fairly regularly for a few years now and have done some successful prototyping, I've not yet done anything that needs to be 'production' quality. the rate at which I continue to learn new stuff makes me think I've still got a long way to go. At the same time, this is also part of what makes me enjoy CL - unlike other languages I've worked in, CL continues to both challenge me and still gives me at least a couple of 'aha!' moments a week. this can be a little dangerous. While I'd enjoy spending weeks or months or possibly even years working on something and building my knowledge of CL, I'm still expected to deliver something of real quality within a limited time - a balancing act I'm not always good at. Unfortunately, I also live in a rural area with no lisp user groups, which means nobody to discuss ideas and problems with in an informal relaxed environment, which I think can often help keep a good perspective. Tim -- tcross (at) rapttech dot com dot au
From: Paul Wallich on 13 Dec 2009 08:52
Tim X wrote: [...] > > Most of the replies in this thread pretty much confirmed the way I was > leaning already. In some of my home projects, I've used CL where once > upon a time, I would have used perl or a shell script. > > I'd now like to start using CL at work more. I've done so in a limited > way with a couple of application prototypes that worked quite well. > However, using it for some scripts may be a harder battle to win, so I > was really looking for some counter arguments. Not sure if it will do > any good - its still mainly FUD I run into rather than anything of real > substance. The difficulty with using it for scripting is that a lot of > others will see what I'm doing. With theprototypes I've done, CL was OK > because if it all whent badly, it was just my head that would roll. > However, letting CL get into core areas is another story. Depending on what kinds of scripting you're talking about, it's probably unlikely that you'll be doing much that stresses CL or your expertise in it. You'll need a good layer of arg-parsing and OS-interface stuff so you don't keep bashing the same corner cases again and again, but otherwise... One big advantage of CL for scripting, in my experience, is that the performance is often sufficiently improved over perl or shell scripts to make a qualitative difference in the kinds of things you can do. You might want to look at something where perl currently takes too long. paul |