scripting in CL -- please comment
in [Lisp]
|
From: Rob Warnock on 14 Dec 2009 00:18 Tim X <timx(a)nospam.dev.null> wrote: +--------------- | rpw3(a)rpw3.org (Rob Warnock) writes: | > 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. .... | 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. +--------------- I've been able to get away with it pretty much unopposed in a lot of marginal areas, places that don't directly challenge the expertise of others in their preferred languages. For example, at my most recent PPoE I got CMUCL included in the approved binaries that build tools could use, since I had a couple of CL scripts that parsed ad-hoc documentation (produced by others) to generate C headers & data initializers for a certain Linux kernel device driver. Nobody had a problem with that, since it was an automatic part of the system build process that they didn't have to look at (as long as it "just worked", which it did). Another area (as I've written about here previously) is user-mode debugging tools for hardware: there just aren't any "standard" tools for such things, so nobody cares that I write mine in CL. Yes, some of that *did* end up "leaking" into "core areas", but only indirectly, e.g., I coded the hardware debugger script so that its internal pre-compiled functions could be evoked from the shell command line, and the Manufacturing & Support folks ended up using some of those functions when testing/diagnosing the product, e.g., $ hwtool ecc-scan 0 0x40000 ...[Scan a range of NVRAM for ECC errors]... $ hwtool i2c-reset ...[Do a brute-force sledgehammer reset of the I2C bus.]... $ hwtool pcix-strength 1 8 32 32 ...[Tweak the drive strength of the PCI-X bus interface]... Note that "hwtool" *needed* the speed of compiled code [since it was frobbing hardware bits directly!], so it couldn't have been done in, say, Tcl or other "interpreted" languages. [At least, not without writing a bunch of special C code to load into the Tcl image.] +--------------- | 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. +--------------- Again, if you develop your skills doing stuff that, while it needs to be done to get the main product out the door, is in areas that don't directly challenge the expertise of others, your skill & confidence in CL will naturally progress. In any case, the definition of "production quality" can vary wildly depending on the situation. My *first ever* major piece of CL code [a web application server and SQL-based app behind it] ended up going into production simply because there wasn't any other viable way to get the job done in time. [It was a volunteer effor for a non-profit, but still...] I'm not suggesting you ship stand-alone commercial software products that you don't feel comfortable with, only that there are aspects of commercial enterprise where some risk with new tools is acceptable [e.g., "infrastructure" stuff]. -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Tim X on 14 Dec 2009 02:09
rpw3(a)rpw3.org (Rob Warnock) writes: > Tim X <timx(a)nospam.dev.null> wrote: > +--------------- > | rpw3(a)rpw3.org (Rob Warnock) writes: > | > 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. > ... > | 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. > +--------------- > > I've been able to get away with it pretty much unopposed in a lot of > marginal areas, places that don't directly challenge the expertise of > others in their preferred languages. For example, at my most recent PPoE > I got CMUCL included in the approved binaries that build tools could > use, since I had a couple of CL scripts that parsed ad-hoc documentation > (produced by others) to generate C headers & data initializers for a > certain Linux kernel device driver. Nobody had a problem with that, > since it was an automatic part of the system build process that they > didn't have to look at (as long as it "just worked", which it did). > > Another area (as I've written about here previously) is user-mode > debugging tools for hardware: there just aren't any "standard" tools > for such things, so nobody cares that I write mine in CL. > > Yes, some of that *did* end up "leaking" into "core areas", but only > indirectly, e.g., I coded the hardware debugger script so that its > internal pre-compiled functions could be evoked from the shell command > line, and the Manufacturing & Support folks ended up using some of those > functions when testing/diagnosing the product, e.g., > > $ hwtool ecc-scan 0 0x40000 > ...[Scan a range of NVRAM for ECC errors]... > > $ hwtool i2c-reset > ...[Do a brute-force sledgehammer reset of the I2C bus.]... > > $ hwtool pcix-strength 1 8 32 32 > ...[Tweak the drive strength of the PCI-X bus interface]... > > Note that "hwtool" *needed* the speed of compiled code [since it was > frobbing hardware bits directly!], so it couldn't have been done in, > say, Tcl or other "interpreted" languages. [At least, not without > writing a bunch of special C code to load into the Tcl image.] > > +--------------- > | 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. > +--------------- > > Again, if you develop your skills doing stuff that, while it needs to > be done to get the main product out the door, is in areas that don't > directly challenge the expertise of others, your skill & confidence > in CL will naturally progress. > > In any case, the definition of "production quality" can vary wildly > depending on the situation. My *first ever* major piece of CL code > [a web application server and SQL-based app behind it] ended up going > into production simply because there wasn't any other viable way to > get the job done in time. [It was a volunteer effor for a non-profit, > but still...] > > I'm not suggesting you ship stand-alone commercial software products > that you don't feel comfortable with, only that there are aspects of > commercial enterprise where some risk with new tools is acceptable > [e.g., "infrastructure" stuff]. > > thanks Rob. Your points are all good ones and your approach very much mirrors how I plan to proceed. If nothing else, it will make the job more interesting! Tim > -- tcross (at) rapttech dot com dot au |