funkyj <funkyj@gmail.com> wrote:
+---------------
| During the day I work as a C programmer at a networking company.
| I don't see much opportunity to use Lisp professionally in the
| near future.
+---------------
I worked for a number of years at a [then-]large computer systems
company doing networking stuff, and now work at a storage appliance
startup. Here are just a few of the things for which I've used Common
Lisp [and Scheme before it] at work, despite the fact that Lisp is
not an official part of my job:
- Code-generating scripts for reducing the labor of creating
and maintaining large, messy C programs and/or Verilog designs.
[Also see Kenny Tilton's & others' past articles about using
CL to generate C++ & Java source code.]
- Data-generating scripts for creating input data and expected output
for hardware simulation test suites.
- Programs to grind through console terminal logs and/or kernel log
files ("syslog") looking for "unusual" patterns, when chasing obscure
or very intermittent bugs. [I also use such a script at home to look
for penetration attempts on my servers.]
- Whipping up a quick web-based multi-question "survey" form and
backend data reduction program when a former boss needed data
"right now!" from all of Engineering (several hundred people)
about their remote-access usage patterns [during one of those
typical tugs-of-war between Engineering & I/S!].
- A user-mode interactive program for doing hardware debugging
which supports mmap'ing the hardware and then lets you do peeks
and pokes to device registers, perform DMA, etc.
This one I've done multiple times at multiple jobs: in Tcl, SCM,
MzScheme, and most recently CMUCL. For the MzScheme one I even
wrote an infix parser as a layer of syntactic sugar on top of
the usual Lisp REPL, so that the other hardware guys who used
the tool didn't get freaked out by "all those parentheses".
[Google for articles by me that mention "P'Lite Scheme".]
But for the CMUCL one I'm doing something much simpler [that came
from an earlier time], and even *thinner* layer of syntactic sugar
on top of the REPL that I call OPFR (Outer Parenthesis-Free REPL),
which is just a slightly-extended READ-LINE which READs the "words" of
a (possibly-continued) line, stuffs them into a list, and calls EVAL.
[Oh, and also implements a "0x" readmacro, for the C/Tcl/Perl crowd.]
As long as people are mostly calling pre-defined functions with
numeric or pre-defined arguments, they don't know or care that it's
really Common Lisp underneath, e.g.:
hwtool> dump32 sdram 0x80
0x00: 0xE59FF018 0xE59FF018 0x00000000 0xE59FF018
0x10: 0xE59FF018 0x00000000 0xE59FF018 0xE59FF018
0x20: 0x00000000 0x00000000 0x00000000 0x00020328
0x30: 0x00020344 0x00000000 0x00020444 0x0002040C
0x40: 0x600DDA7A 0x11FEBEEF 0x87654321 0xFFAA5500
0x50: 0x00000000 0x00000000 0xFFFFFFFF 0xFFFFFFFF
0x60: 0x00000000 0x00000000 0x00000000 0x00000000
0x70: 0x00000000 0x00000000 0x00000000 0x00000000
hwtool> dcache-off
:OK
hwtool> icache-off
:OK
hwtool> r32 (+ sdram 0x3c)
132108
hwtool> hex *
"0x2040c"
hwtool> w32 (+ sdram 0x60) 0x1234 0x5678 0x9abc 0xdef0
hwtool> dump32 sdram 0x80
0x00: 0xE59FF018 0xE59FF018 0x00000000 0xE59FF018
0x10: 0xE59FF018 0x00000000 0xE59FF018 0xE59FF018
0x20: 0x00000000 0x00000000 0x00000000 0x00020328
0x30: 0x00020344 0x00000000 0x00020444 0x0002040C
0x40: 0x600DDA7A 0x11FEBEEF 0x87654321 0xFFAA5500
0x50: 0x00000000 0x00000000 0xFFFFFFFF 0xFFFFFFFF
0x60: 0x00001234 0x00005678 0x00009ABC 0x0000DEF0 <== Note changes
0x70: 0x00000000 0x00000000 0x00000000 0x00000000
hwtool> expt 2 200
1606938044258990275541962092341162602522202993782792835301376
hwtool> loop for i from 0 below 16 collect (expt 2 i)
(1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768)
hwtool> lisp-implementation-type
"CMU Common Lisp"
hwtool> lisp-implementation-version
"19a"
hwtool>
- A little script to go grab the company's stock price off various
web sites and filter out all the HTML and just show the numeric
value of "Last trade". ;-}
The point is that we all have "non-production" or "auxiliary" work
that we do along the way when doing our "real" jobs, and there's
(usually) nothing stopping you from using Common Lisp for any of
that "other" stuff.
+---------------
| back in the 90s I started with bourne shell for scripting...
| Looking for something better I gave TCL a try... [then] decided
| to give that wildly popular language Perl a try ... [then] Python.
+---------------
My path was somewhat similar, except Perl before Tcl [and never made
it to Python], but the main reason for moving to Tcl was because the
"commandloop" command nicely supported interactive operation ["perlsh"
is not "nice", IMHO], the FFI to C code was very simple, and you could
load C-based DSOs at run-time. So the Tcl version of the "hwtool" script
could just do a dlopen() of the C code, and there was my "mmap", "peek",
"poke", etc.
But doing 'scope loops in Tcl was so *slooowwww* [I sometimes had to
turn the room lights off to see the trace], so I switched to Scheme,
and then later still, to a Common Lisp with a native code compiler.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607