danb <firstname.lastname@example.org> wrote:
| email@example.com (Rob Warnock) wrote:
| > I use Lisp at work whenever I can get away with it, which
| > isn't much: basically, just one steadily-accreting-ball-of-mud
| > that's my user-mode hardware bringup/debugging tool
| You say your Lisp code is a BoM? Can't you maintain it?
The problem I'm solving *is* a ball-of-mud, so the Lisp code
merely reflects that. Consider the following work loop:
1. Somebody files a bug report about hardware X does task Y wrong
in situation Z on machine M.
2. I connect to machine M [either via SSH or a cnosole server,
depending on just how broken it is], and start up my user-mode
hardware debugging tool.
3. I poke around in the REPL trying to understand what the bug
reporter is talking about, trying to duplicate situation Z,
sometimes doing low-level peek/poke ops and sometimes calling
previously defined more complex display, scanning, or other
4. Any time I find that I'm typing the same thing into the REPL
over & over -- or a sequence of related things that could be
generalized into a canned function -- I write a canned function
to do "the thing" (whatever), compile it [hardware debugging
tends to b performance-sensitive], and also add it to the source
of the tool. Now it's available the next time I run the tool,
and also available to others.
"This is how we grow the mud, grow the mud, grow the mud."
The rate of accretion *does* decrease over time, but never
goes entirely to zero.
5. Loop back to step 3, or 2, or 1, as appropriate.
So for any given domain [that is, hardware platform, operating
system, set of chips/cards being developed/debugged/upported],
the tool starts out small, just an OPFR-based REPL and a few
key basics (mmap, peel/poke/dump functions), and rapidly grows
just that set of additional canned functions that are needed
to debug the problems that arise in that domain.
The world isn't clean. the world *is* a "ball of mud". So a tool
which models the world ends up resembling that world as well.
The good news is that the Lisp code -- even "ball of mud" Lisp
code -- is *much* more maintainable (IMHO) over the long haul
than the messes of C or Tcl I used for this before I switched
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607