<div dir="ltr">Larceny (a Scheme) supports images. I had another dance with them awhile back playing around with Gilad Bracha's Newspeak. I hear the Dart folks have debated support for platform independent images of Dart programs to be served out for executing in Chrome. They'll probably do it. They are certainly experimenting with the idea.<div>
<br></div><div>The problem I hit with images was knowing the state of the state of the image and ability to recreate that known state if necessary upon loss of an image.<div><br></div><div style>With Typed Racket, immutable structs etc. I really do focus on writing pragmatically Functional code, in the sense of referential transparent code. As a result there is very little state to capture other than exploratory interactions at the top level or within a namespace via the REPL. Those explorations I'm more than happy to throw away as I've lost track of the mutating sequence of steps I've been binding in there anyway.</div>
<div style><br></div><div style>How much value is there in creating an image of a purely functional program? How far from a persisted image is the persisted code?</div><div style><br></div><div style>Compare and contrast with an OO language like Smalltalk or Newspeak which are encapsulating state and evolving that state. Snapshotting the current state of that evolving state in a persistent image has more utility there I think, modulo, the mentioned issue of a perfect understanding of the current state, and confidence in a 100% reproducability, back to that state.</div>
<div style><br></div><div style>With Git, for example, one has very granular state of source code evolution and given a primarily purely Functional code base, the source code offers a fairly close approximation of an image. </div>
<div style><br></div></div><div style>At the function/procedure definition level incremental compilation at the REPL is a bit more of loss for me. But I'm finding that is also lessening. These days (re)launching a REPL into a fresh namespace is almost immediate.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 1:39 PM, mikel evins <span dir="ltr"><<a href="mailto:mevins@me.com" target="_blank">mevins@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Mar 5, 2013, at 12:12 PM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
<br>
> A few minutes ago, mikel evins wrote:<br>
>><br>
>> On Mar 5, 2013, at 11:55 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
>><br>
>>> An hour and a half ago, Matthias Felleisen wrote:<br>
>>>><br>
>>>> I have empathy for your perspective, because I have worked with<br>
>>>> images and -- at the time -- found them useful.<br>
>>><br>
>>> I think that *most* of Mikel's long post was about the advantages<br>
>>> of having a live REPL,<br>
>><br>
>> Then I didn't express myself clearly enough. Sorry about that.<br>
><br>
> So let me clarify a bit more (though this is obviously my very<br>
> subjective opinion)... I loved doing the kind of live-REPL-based<br>
> debugging that you're talking about, but every once in a while things<br>
> would get messed up in a way that made it much easier to just restart<br>
> the whole thing. I've also used images, but the main thing that<br>
> bothered me about them is that they're heavily oriented in the other<br>
> direction: instead of restarting the application from scratch where I<br>
> know that the code is only what's in the source, it encourages<br>
> continuous tweaking of the live REPL where you continue to tweak and<br>
> try to fix it to later dump a new image.<br>
><br>
> Eventually, I concluded that images are a cute thing in theory, but in<br>
> practice they were too limited in the reduced ability to deal with the<br>
> source code. Maybe Emacs is a good example of this: even though it's<br>
> image-based, developement happens on the source, with the image<br>
> feature being pushed to just another step in the compilation chain.<br>
><br>
> (Disclaimer: the systems that I used with images were the common ones<br>
> where there's no support for editing the live source -- not the fancy<br>
> lisp machine or smalltalk things.)<br>
<br>
</div></div>The problem you're describing is real, and is one of the prices paid for image-based development. It doesn't cancel out the advantages, but it's something you have to learn to deal with appropriately. One of the ways you deal with it is through process: we kept reference images and checkpoints, so that we could roll back troublesome changes. That wasn't burdensome precisely because saving and loading an image was so fast and easy.<br>
<br>
Another way you deal with it is to develop the kinds of tools you mentioned--tools that give you greater power to identify and change the things you want to change. Some of the tools that working programmers take for granted nowadays were invented in that context, and I think it's reasonable to expect that more of them will be, as long as we don't forget how to make and use image-based environments.<br>
<br>
I had to think some more about how my remarks might have led you to think I was talking about REPLs. Let me take another stab at it by mentioning things that REPLs don't provide.<br>
<br>
I don't in any way want to discount the value of a live REPL; it's indispensible. It's not what I was talking about, though.<br>
<br>
By itself, a live REPL doesn't grant me the power to preserve the incremental dynamic state of my work-in-progress with a single quick action, nor to equally quickly recover that state. When I have that power, I use it constantly.<br>
<br>
It doesn't make delivery of incremental release candidates as quick and simple as saving a word-processing document.<br>
<br>
It doesn't offer me a bog-simple, quick, and convenient way to preserve snapshots of my progress on a task, nor to provide snapshots I can use to reproduce *exactly*, and with all its dynamic details, a pathological state.<br>
<br>
It doesn't offer me a way to package a whole dynamic machine state to give to someone else, so that they can see what I see, nor an equally quick and simple way to illustrate proposed changes by making them directly in their intended context in a way that another person can see and interact with them immediately.<br>
<br>
It doesn't give me a way to checkpoint the space of changes and use the checkpoints to zero in on the change that introduced a bug.<br>
<br>
It doesn't give me a quick and simple way to roll back an unfortunate change, and without that ability, experimentation carries a higher cost. Maybe lowering the cost of experimentation seems a small advantage; it isn't.<br>
<br>
REPLs don't do any of these things, though they complement them nicely. If you have these abilities, they're better if you also have a REPL, and the reverse is also true.<br>
<br>
REPLs are a dime a dozen nowadays. Clojure has one. So do FORTH, erlang, Ruby, Python, the various flavors of ML, and Haskell. The REPLs in Lisp and Smalltalk systems are different. TO a much greater degree than in other systems, you can use them to incrementally build up state that provides a progressively closer approximation to what you're trying to build. An image-based Lisp or Smalltalk is better still, because you don't have to recapitulate the groundwork every time you start the REPL; instead, having achieved a congenial state, you can just save it, and then resume it later, just as easily.<br>
<br>
Naturally, you don't always want that. Sometimes a reference state, free of accumulated deltas, is what you want. Image-based systems don't in any way prevent you from having that. On the contrary, they make it easy to provide yourself with several different ones for different uses. You do, of course, have to realize that you're going to want that, and take appropriate steps to ensure that you have it when you want it. That's one of those things that comes with experience, or with good advice from an experienced colleague.<br>
<br>
But not having the capability to save and load an image provides no advantages. Anything you can do without that capability, you can do with it. The reverse is not true.<br>
<span class="HOEnZb"><font color="#888888"><br>
--me<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_________________________<br>
Racket Developers list:<br>
<a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
</div></div></blockquote></div><br></div>