Kaz Kylheku
8/28/2015 6:25:00 PM
On 2015-08-28, Blake McBride <blake1024@gmail.com> wrote:
>
> A popular development scenario that I term "disk based" looks like the
> following:
>
> A. A program is created / edited with a text editor (like emacs)
>
> B. The code is saved to a disk file (like myprogram.lisp )
>
> C. A language interpreter / compiler loads (from disk or a socket)
> and runs the code where the programmer evaluates its performance
>
> D. Go back to A.
>
> ---
>
> There is another development scenario that is old, but may be worth
> looking into. I term this other method "image based" and it looks like
> the following:
>
> 1. Code is added and edited right in the environment where it is being
> used (like CCL, SBCL, CLISP, etc.). Editing the code could be done
> with an editor like a structure editor written in Lisp rather than a
> text editor.
>
> 2. Run the code right in the environment it was created in.
>
> 3. Go to step 1 in order to continue development.
Purely image based is stupid, because the image is some binary cruft
that you canno version control, or port to other systems.
In some Lisps, images require a separate executale which loads them,
and sometimes newer versions of that executable wont' load old image
sor vice versa.
The hybrid approach is this:
1. Run one image.
2. Edit important code in a text editor, saving to a file.
3. Load modified files into the image to replace definitions with
new ones. (Perhaps using a build system like ASDF).
4. Directly, in the image, write only throwaway functions for testing,
and use the REPL for exploring and debugging. If anything is
to be retained, paste it into a file.
5. Optionally save the image to checkpoint the state or other reasons.
Lisp environments like Slime try to make it mostly seamless, because
you can evaluate code into the image out of the editor.
Speaking of image saving, it is important even if you don't use it
for development, because it's one of the ways of creating standalone
applications.
Also, your Lisp probably loads fast, even though it is loaded with functions,
because it's actually restoring an image, and not actually evaluating hundreds
of defuns and defmethods.
Emacs starts from an image, using a low-level C technique of
dumping memory and then reloading it.
I worked on a project which had a Make rule tree that too 30 seconds to read
and process. So even the tiniest incremental build took 30 seconds from the
time you typed "make" to the one-file compile, and link (which themselves took
a fraction of a second)!
I got sick of it and ripped the undumping code out of GNU Emacs, transplanting
it into GNU Make. I then had something like "make --dump file" which produced
a core dump in file, and a "make --restore file" (load the dump and build
without reading Makefile).
It became virtually instant to do incremental builds. Of course, if you
changed the rules, you had to re-do the dump: 30 seconds once in a while
was better better than 30 seconds every time.