A place to be (re)educated in Newspeak

Thursday, April 04, 2013

Making Methods Live


A few months ago, I suggested that IDEs should ensure that code is always “live” in the sense that it is associated with runtime data so that any part of the code can be immediately executed. I proposed that tightly integrating editors and debuggers would be reasonable way to pursue the idea.

I’ve put together a prototype, an extension of the Newspeak IDE.  I demonstrated an early version at the WGLD meeting in December. Since then there have been some improvements, though a lot of work remains to be done. Nevertheless, the system is already usable, at least by an experienced Newspeaker.

In Newspeak, one typically edits individual methods in a class browser, as opposed to monolithic files. The prototype modifies the method browsers to present the method along with a view of a live stack frame. This is essentially the same view one sees in the debugger, where a series of activations are available; each such view shows a single stack frame along with the corresponding code

I plan to show the latest version at the upcoming Live 2013 workshop. I’ve prepared a short video illustrating some of the capabilities of the system.  The video is cut short because of time limitations of the workshop, but it shows something roughly similar to one of Brett Victor’s demos of editing and interacting with general purpose code.

It is possible to select any subexpression in the code and evaluate it. In Smalltalk, it is customary to insert code snippets that illustrate how to use an API inside comments. This is possible here as well, but unlike Smalltalk, the snippets can make use of local variables and instance methods. It is also possible to step through code as in a debugger (in the interest of full disclosure, that bit is a tad flakey at the moment; this is very much a work in progress).

There are many things that need improvement, some of which you can see in the demo. Combining the debugger and method editor brings challenges. If you hit return, is that just a newline, or do you evaluate the code, and/or save it? In a classic REPL, you are not editing permanent code and so neither formatting nor saving are a concern, and each return evaluates the current line and moves to a new one. In contrast, in an editor, return is just formatting, and saving is a distinct operation. Our current approach is to keep all three operations distinct. However, it would be convenient to have keyboard shortcuts for evaluation and for evaluate and return. That would make the kind of interaction shown in the demo smoother. So would maintaining the selection across evaluations.

There are also various nice features that aren’t illustrated in the demo due to lack of time. When an evaluation prints out its result the printout is a link to an object inspector on the result, where further evaluation can take place in the context of that object.  This is a feature inherited from the existing Newspeak object inspectors.

It is important to understand that you can do all this on any method of any class, whether you view it in a class browser, or in a list of senders or implementors etc. The goal of this effort is to completely eradicate any code view that does not support such live interaction. There are still some parts of the system where this has not yet been done, but a few more weekends and this will be addressed.

If you get the latest Newspeak VM and the experimental image you can play with the extension I’ve described, though you need to be comfortable with Newspeak. Otherwise, you will probably provoke some of the many bugs in the prototype.

The goal is to get this into the production Newspeak IDE in the not too distant future. There is a good deal of work before we get there, and huge potential for improvement. Issues include efficiency (each method browser is potentially a thread) and the quality of the exemplar data displayed. There are interesting ways to improve the quality, including bidirectional linkage with unit tests and type annotations. There is probably scope for a masters of PhD thesis depending how far one wants to take it all.

While it is a lot easier to do this sort of work in the Newspeak environment,  the lessons learned pertain to other systems as well. 

8 comments:

Carl Gundel said...

This is a fun area of research, and if you do it really well it will give you an excuse to demo Newspeak to more crowds than might ordinarily be interested, and give people a reason to link to you.

Gilad Bracha said...

Carl,

Everything about Newspeak is fun, but getting people to realize it is frankly challenging. Many are just too conservative and set in the old ways.

theodora said...

I love this page, everything about New speak is just too fascinating, keep the good work up.

Sean McDirmid said...
This comment has been removed by the author.
Sean McDirmid said...
This comment has been removed by the author.
Sean McDirmid said...

(having the trouble with Blogspot and comment editing)

Hey Gilad, I've written up my WGLD idea in paper form on...combining the editor and debugger :) Also a short video was published with the paper also; this are a bit confusing outside the context of the paper.

The UI looks much better now! I can see the contrast in our approaches, and also the similar problems we are facing.

Also, when cutting videos for youtube, I find it useful to make the UI exactly 854 by 480 and crank up the font size to around 20px if possible. Otherwise the code can be a bit hard to read.

Gilad Bracha said...

Hi Sean,

I finally got round to reading your paper and seeing the video. Nice. Probes are great and can carry over to other systems quite easily, so I may steal that. Traces are more demanding in terms of scale, and closely tied to time travel debugging in my view. Will you be at LIve2013?

Sean McDirmid said...

Traces only involve time travel if your program involves time :) I get around this in my paper by focusing on batch programs that are time free, conceptually at least, but its something to figure out in the future.

I'm not attending Live2013; it just doesn't make sense given the distance involved.