scripting in CL -- please comment
in [Lisp]
|
From: Tim X on 7 Dec 2009 01:57 Pillsy <pillsbury(a)gmail.com> writes: > 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? > All points I can appreciate. To some extent, its the having to learn another lisp dialect with its own odities that has me wondering if the benefits are worth it. Most of the scripts I'd be looking at would stay as fairly simple/small scripts. However, there is a feeling of using a sledge hammer to crack a walnut. I also work on many different systems, most of which will not have Cl installed, but nearly all of them have guile and most have rep. Looking at the APIs/libraries, they also all seem to have more extensive 'standard' support for the sorts of common things you would frequently do as part of scripting. I'm not saying you can't do this with CL, but rather how easily can I justify using CL if other alternatives come with much of what I would need as libraries/apis. There is also some appeal in using something different to get another viewpoint on how things are done in other lisp like languages. On the other side is the fact that Cl is a language I've used and am familiar with (at least more familiar than I am with the alternatives) and so the learning curve is less. Tim -- tcross (at) rapttech dot com dot au
From: Tamas K Papp on 7 Dec 2009 04:19 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
From: Tamas K Papp on 7 Dec 2009 04:26 On Mon, 07 Dec 2009 17:57:20 +1100, Tim X wrote: > benefits are worth it. Most of the scripts I'd be looking at would stay > as fairly simple/small scripts. However, there is a feeling of using a Haha. A lot of scripts start that way, and later the authors find that they have created a 1000 line monster in Bash :-) > sledge hammer to crack a walnut. I also work on many different systems, Don't think of CL as a sledge hammer. Rather as a kind of special putty that you can use to design the perfect walnut cracker for the job. The putty is cheap, and is easy to shape, but if required, it can become hard as steel. It can also be used to create factories that make walnut crackers customized to each walnut. And the putty is costless. The only disadvantage is that it gets under your fingernails, which you have to clean with a brush at the end of the day :-) Tamas
From: fortunatus on 7 Dec 2009 09:33 On Dec 6, 10:05 pm, Pillsy <pillsb...(a)gmail.com> wrote: > 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... > > ... with a few > common libraries and custom macros it's very capable of getting the > job done. I second this - a couple macros (really about five in my case), and from then on I've been scripting away for years... Scripting has domains, like any other programming. (eg, I work for a video processing company therefore I usually process video data.) That means even if you use a dialect specifically designed for scripting, you'll still add in your five macros (or fcns) that suit your needs. The CL basis also means that I can fuse my scripting with PortableAllegroServe and have a GUI that the whole office can access. (I'm sure many CL-ers would prefer Hutchentoot...) > A secondary reason is that if the script starts growing beyond simple > throwaway code, I know that CL is capable of coping... I second this, too - more than once a script has grown into an application that takes over fine grained data processing itself rather than calling out to other programs.
From: André Thieme on 7 Dec 2009 15:41
W. James schrieb: > 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 > COBOL 810 > ATLAS 790 > Fortran 77 430 > PL/I 420 > BASIC 360 > ADA 340 > Fortran 8x 300 > C 220 > Pascal 120 > DIBOL 90 > Scheme 50 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? I don't think so. What does this tell us about Ruby? André -- Lisp is not dead. It's just the URL that has changed: http://clojure.org/ |