Debug Mode is the Only Mode

[Gilad Bracha]

Hi,

Last month I wrote a blog post with the same title as this thread,  discussing issues of live programming. One of the key points was that the distinction between editing, debugging and interacting with an object introduced hidden modes that should perhaps be eliminated.

Essentially, the IDE should always ensure that code is associated with live data.  I spent a few hours prototyping a version of this notion in Newspeak.  In this version, everywhere you view code, you are viewing it along with exemplar data for the scope of that code. 

Attached are some screenshots. In the first, you can see that we are viewing a method in a class browser, but the view is of an activation record. This gives you access to values for the  arguments and locals, and allows you to step through the code just like you would in the debugger.

The activation record view also differs from the one we use in the current system: There is no evaluator on the right hand side. Instead, the evaluate button (in the button bar above) allows evaluation in the main method text.

You can see that the expression 'nothing' is selected and was just evaluated  using the Evaluate button, yielding a result, in the style of a workspace or object inspector.

There are of course numerous issues at present. There a number of nasty bugs and deficiencies, and the UI itself is debatable. The quality of the data is often poor. For example, in this case, the value of self is an instance constructed using basicNew, so the slots are nil and you can't really do much with the object itself.

The second screenshot illustrates this - you can see that the slots are all nil, and you can also see the stack trace that resulted from trying to step over a method call (availableViews) that depends on the state of the instance. However, this also illustrates the fact that we have both debugger and workspace in one place.

Finally, the last screenshot shows an example method being developed. The example is derived from one used by Bret Victor (I referenced his talk in my blog).

Making this a standard part of the Newspeak IDE will require a lot more work, especially with respect to getting better quality exemplars. There are several ways we could get such exemplar data. There is academic research on that topic (e.g., Robert Hirschfeld's team at HPI in Potsdam), and I have some ideas of my own.

I wanted to share this with you and get your reactions.

[Ryan Macnak]

On Sun, Dec 16, 2012 at 9:10 PM, Gilad Bracha <gbr...@gmail.com> wrote:

Making this a standard part of the Newspeak IDE will require a lot more work, especially with respect to getting better quality exemplars. There are several ways we could get such exemplar data.

Perhaps a narrow case, but when creating a method in the debugger in response to a MNU, the new method's exemplar context could have its parameters filled from the MNU. I had changed the default implementation provided by the debugger to include a halt, so one could quickly hit continue and re-enter the debugger with this context available.

[Gilad Bracha]

On Mon, Jan 14, 2013 at 1:50 PM, Ryan Macnak <rma...@gmail.com> wrote:

On Sun, Dec 16, 2012 at 9:10 PM, Gilad Bracha <gbr...@gmail.com> wrote:

Making this a standard part of the Newspeak IDE will require a lot more work, especially with respect to getting better quality exemplars. There are several ways we could get such exemplar data.

Perhaps a narrow case, but when creating a method in the debugger in response to a MNU, the new method's exemplar context could have its parameters filled from the MNU.

Absolutely. Other sources of information (for other cases) are test suites (and of course, it goes the other way, creating tests from live interactions is very useful as well) and operations like someInstance.

--
Cheers, Gilad

[Brian Rice]

Ah, now I'm reminded to reply, and I think I have a perspective to share at this point.

It would be instructive to take an idea like QuickCheck which generates random test data based on type definitions, and decide that this debug mode fits into that. There are dynamic language versions of QuickCheck, but a NewSpeak version should be easy to derive with a number of designated "safe constructor" selectors plus inferred or otherwise argument types. Then it's a matter of making suitable composers of these example values to get a "full enough" sandbox environment running to edit the code within.

--
-Brian T. Rice

[Frank Shearar]

I hacked something up for Smalltalk about a year ago [1] and wrote a short tutorial [2] on the matter, where I do something like JUnit's Theory stuff: parameterised tests driven by data, only the data is randomly generated from a set of classes determined by the messages sent to the test parameter (and its class). As a last tweak, any counterexamples were stored by generating a testMangledCounterexampleSelector method driving the theory with the counterexample.

Generating random data's easy. The real utility comes in _shrinking_: taking a generated counterexample to your theory and automatically producing a simpler counterexample.

Even though I didn't implement shrinking (I should get back to the project, actually), it was quite fun writing the monadic laws in test form and knowing that any monad-like classes would end up getting tested.

frank

[1] http://www.squeaksource.com/SqueakCheck/

[2] http://www.lshift.net/blog/2012/01/31/duck-finding-for-testing-your-theories

[Gilad Bracha]

Static type information is another potential source of data; and again, it goes both ways - given real dynamic data, one can use it to generate annotations (we do that now when adding methods in the debugger in response to doesNotUnderstand.

--
Cheers, Gilad

[Gilad Bracha]

So after a longish hiatus, I've integrated this experiment into the current bleeding edge repo. This is probably the biggest single change to the IDE we've done since we introduced Hopscotch. 

It certainly needs a lot more work to be truly useful; I hope to improve the quality of the exemplars, integrate with unit testing etc.  

On the other hand, it is reasonably stable, and it won't move forward unless it is in the daily workflow of multiple Newspeakers. Moreover, I don't want to have to play catch-up as the environment moves forward.

[Frank Shearar]

I just stumbled across someone else's work in this area:
http://www.subtextual.org/OOPSLA04.pdf - "Example Centric
Programming", by Jonathan Edwards.

Actually, it's quite funny reading this. Lightable tends to blow
people's minds when they try out the instarepl and see their Clojure
example forms being evaluated as they type, and yet here's a guy
writing about this 9 years ago already!

frank

[Gilad Bracha]

Hi Frank,

I know Jonathan and he is a very original thinker, which explains why he has such difficulty gaining traction. He has a blog where he discusses such things.  I confess Light Table did not impress me that much - but that is the secret I suppose. You need to keep enough things familiar to a broad audience so they can focus on the liveness itself.  Alas, this does not bode well for efforts in the Smalltalk tradition.

I am also much less concerned with "instant evaluation" since in an imperative language, that may not be what you want. Having the data to enable evaluation is what is critical.

In the meantime, this work is now gated by an experimental preference in the latest sources on bleeding edge, mainly because Cadence cannot digest it at the moment. I hope we get it in better shape in the foreseeable future. Unfortunately, I have almost no time to put into it, so progress is slow.

I wonder if you saw the blog post from last Thursday, and the associated Youtube video. 

--
Cheers, Gilad

[Frank Shearar]

On 6 April 2013 23:44, Gilad Bracha <gbr...@gmail.com> wrote:
> Hi Frank,
>
> I know Jonathan and he is a very original thinker, which explains why he has
> such difficulty gaining traction. He has a blog where he discusses such
> things. I confess Light Table did not impress me that much - but that is
> the secret I suppose.

Ah, but being seasoned in the ways of liveness, I wouldn't expect you
to be impressed. There _is_ a qualitative difference between being
_able_ to evaluate expressions whenever you want and having the
expressions evaluated for you all the time, but as I mentioned on
squeak-dev I haven't actually used Light Table in anger so I can't say
how its instarepl might change how I program. And the natural response
is that I should try out your latest experiments in Newspeak!

> You need to keep enough things familiar to a broad
> audience so they can focus on the liveness itself. Alas, this does not bode
> well for efforts in the Smalltalk tradition.
>
> I am also much less concerned with "instant evaluation" since in an
> imperative language, that may not be what you want.

Indeed, and also because there's no way to identify side-effectful
code from purely functional code from launch-the-missiles code. There
are quite a few things one can do to mitigate the problem without
reaching for a type/effect system, like supplying a base library of
apparently functional code. Light Table has a mild advantage here in
that Clojure does have such a collection of libraries out of the box.

> Having the data to
> enable evaluation is what is critical.

Agreed: having a means of producing examples of some class allows one
to do all sorts of things.

> In the meantime, this work is now gated by an experimental preference in the
> latest sources on bleeding edge, mainly because Cadence cannot digest it at
> the moment. I hope we get it in better shape in the foreseeable future.
> Unfortunately, I have almost no time to put into it, so progress is slow.
>
> I wonder if you saw the blog post from last Thursday, and the associated
> Youtube video.

I read the post, but I haven't yet watched the video. It is kicking me
back into working more on making the Squeak debugger more alive,
though.

frank

[Frank Shearar]

Right, I see now what you're doing: it's like a merging of debugger &
editor: you supply some initial values (so the typical
debugger-inspector becomes a current-context-environment-manipulator),
and you use the debugger machinery to play the computation. The editor
supplies the usual code editing interface.

frank