danb  <sogwaldan@gmail.com> wrote:
+---------------
| rpw3@rpw3.org (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
   debugging functions.

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
to Lisp...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607