Lisp as a crucible

Scheme and Lisp force you *think* from the get-go. Most engineers and programmers hate to do that and it makes them uncomfortable. Starting a program in Java or C is easy. There’s a pile of boilerplate you can type without thinking about it, and it `feels’ like you’re programming. Then you have to haul out the bag of tools like the compiler and the linker and makefiles or ant. There’s a lot of busy work needed just to get going, and you feel like you’ve accomplished something.
In Scheme or Lisp, you start it up and there you are at the REPL. You have to decide what your program is going to do. You can’t waste time writing boilerplate (it’s unnecessary), designing data structures (just cons one and specialize it later), figuring out how to build complex inheritance hierarchies (do that once you know what you are doing), you have to dive into the problem right away. If you are willing to make mistakes and learn from them, then the REPL is a great place to play. If you prefer to plan ahead so you don’t make mistakes, a REPL is a very uncomfortable place to be.

— jrm
Having experienced the “discomfort” myself, I recognize now that this development approach acts as a mirror to your strengths and weaknesses. It reveals, very very quickly, whether or not you really have got a grasp both on the problem and how you plan to solve it. There is no where to hide! It is great.
(via R6RS)

13 thoughts on “Lisp as a crucible”

  1. I hardly ever use the REPL, except perhaps to use it as a calculator (when I don’t want to use “dc”).
    I keep writing code in my editor(s), and then sending it to the interpreter.
    Am I missing something?
    I just don’t get the point “just the repl”.
    I can’t have a persistent program through the REPL, can I?

  2. You can have a persistent program through the REPL if you save an image. Your implementation should support that; in SBCL, it’s sb-ext:save-lisp-and-die. Admittedly, this is an alien concept to C++ and Java programmers: It breaks the whole notion of a program being distinct from its compiler, and it isn’t entirely friendly to the notion of source code, either.
    As for not using the REPL, I don’t know your environment. If you’re using SLIME on Emacs or something similar and you’re incrementally sending forms to an inferior Lisp process, you have something arguably better than a REPL if you expect to create source code for a traditional package. If you’re using an editor without support for interactive development, you should consider switching to one that supports it: It is an entirely new and, in my opinion, better way of working, especially in a language like Lisp.

  3. You are always using a REPL when interacting with a computer. It does not matter what you are actually using. You are speeking to the computer, it reads your commands, evaluates them and prints you the result in a loop. The difference is between the degree of freedom, being able to combine things, tools, etc. The REPL is always there.

  4. Chris: thanks, but I use my editor(s) when I write code, and let them handle the REPL πŸ™‚ The fact is I don’t do the converse. I would never fire up the REPL as it to start programming…
    And an image, how good is it for editing again?
    Levy: Then I should say “the REPL of the language I’m programming in” for a better description, because my Scheme REPL is the same on any OS, while the interactions I have with different OSs is far from equivalent.

  5. Adrian: Where the REPL fits for me is while working with DrScheme I can define some structures in the Definitions window and start working with them in the Interactions window (REPL). When I am happy with the code, I move it from the REPL into the editor.
    From what I have seen, you have do the hard work sometime; and most people really do hate that and spend most of their time playing with object hierarchies, third party libraries, and project configurations until they are finally forced to actually solve the problem at hand (if ever).

  6. Levy: Agreed and most people don’t look at their favorite language working in that manner.

  7. I think in the end it is not about the REPL as a way for entering code, but having a running process that you can let grow.

  8. Adrian: And an image, how good is it for editing again?
    Load up the image and start redefining stuff. Then you can save it again later. It’s like editing a file in some editor, just that you’re editing a program sort of while it’s running.

  9. The REPL is always there. SLIME/EMACS is just a really, really fancy REPL with editing. The quote is very accurate. The distance between thought and action with Lisp is very small.

  10. The REPL is for informal testing. Formal unit tests are all the rage these days, but if you haven’t quite planned out what you’re making, it’s hard to come up with proper tests. The REPL makes it very easy to see what’s going on.
    It’s only for throwaway code – anything you’re planning to keep should go in a file buffer and be incrementally evaluated.

  11. Bob: The image is the state, not the code. I can read and edit code I find on the web without any comments. I’m definitely not sure that I can get back the source or fix a function that calls function “distplay” instead of “display”.
    Also, the image does not contain everything: it dumped all that has been done. If the first thing I wrote was “(display 42)” then it’s not in the image you build after that. OTOH, it’s still in my source code. You can’t either rename FOOs in BARs with an image.
    blah blah, you get the idea.
    To *write* modifiable code, it takes an editor. To run code, it takes an REPL.
    The fact is Lispers often mix the two.
    But to me, writing a Lisp program with just the REPL is like writing assembly with cat. Stupid. (though ASM&cat earns extra 2^8 Guru points if the program is correct)

Leave a Reply to Grant Cancel reply

Your email address will not be published. Required fields are marked *