The answer to the query above is that they both spend much of their time analyzing corpses. Pathologists analyze dead people; programmers analyze dead programs.

A live program is dynamic; it changes over time; it is animated. A program is alive when it's running. When you work on a program in a text editor, it is dead.

A live program has behavior, and that behavior is what we are interested in. It is very hard to discern the behavior of an organism on the basis of an autopsy. Did dinosaurs care for their young? If only we could look at some live dinosaurs and see.

Likewise, it is very hard to understand the behavior of a program just by looking at its code. You are forced to simulate the behavior in your head. As Shalabh Chaturvedi suggests, machines are much better at that, and so we should have them do it instead.

I discussed this problem back in 2012/2013. I proposed that IDEs should always present code in the context of live data. Every variable in the program should have a value; you can then evaluate code at any point and see how it behaves. I even built a simple prototype (here's an old demo and a shorter one).

Ultimately, I abandoned the prototype. The approach I was taking was too clever. It attempted to synthesize sample data automatically. One can do this in various ways, using tests, types, results of prior evaluations, program analysis etc. This involves a lot of hard work, which I find distasteful.

Recently, I had an inspiration: why not do this the easy way? Below is what you see in the latest Newspeak IDE when you click on class BankAccount.

The IDE runs in the browser; the view below is live, not a screenshot. You can play with it.

What you get is an object inspector on an instance of BankAccount. The code of the class is embedded therein. Now you can evaluate expressions in the code; self is bound to the instance being inspected; method parameters have plausible bindings as well.

To demonstrate this, open the withdraw: method by clicking on it. Select an expression in the method body and use the Evaluate Selection button; the result will display just below the method.

Caveats galore: not everything works yet - for example, the Start Live Evaluation button only works in the object inspector, not for methods.

If you press the Debug button above a method, you enter a debugger, stopped at the start of the method.

You can use the navigation buttons at the top of the embedded IDE to go back from the debugger to the object inspector.

What makes this work, and moreover, what makes it easy? Rather than synthesizing exemplars automatically, we ask the user to tell us how to create them. At the top of the class you can see its factory method, balance: (note the colon at the end). If you click on it you'll see a a comment:

(* :exemplar: BankAccount balance: 100 *)

This is a metadata comment. It is distinguished from an ordinary comment by the fact that it begins with a metadata tag, which is delimited by colons. Here the tag is :exemplar:. The tag identifies a metadata processor that looks at the rest of the comment and decides what to do with it. In our case, the metadata processor is the IDE, and it assumes the remainder of the comment is an invocation of the classes' factory method, which will yield a sample instance of the class, an exemplar.

I got the idea when looking at Tudor Girba's fabulous Glamorous Toolkit (aka GT). I noticed their extensive use of pragmas, which are basically a form of metadata. GT doesn't use metadata for this specific purpose - at least not yet; but they could probably make it work in short order.

There is a question of what scope to evaluate the expression in; the IDE uses its namespace for top level classes (since Newspeak has no global scope). For nested classes, it uses the scope of the exemplar of the enclosing class.

A similar trick works for methods. The exemplar metadata is a sample method invocation, which is sent to the exemplar of the class. You can have multiple exemplar metadata comments, and you can choose which one to use.

Obviously, if a method does not take parameters, one doesn't need to provide metadata. If we do require metadata but none is provided, or if evaluating the metadata fails, we revert back to showing dead code.

One criticism of this approach is that it may discourage people from ensuring that the code works for all possible values, and not just the exemplars. I'd argue that exemplar based IDEs are complementary to other techniques, such as testing and typechecking. You can use multiple exemplars, and that can be used to ascertain code coverage. One can infer types based on exemplars; this is very close to Hernan Wilkinson's excellent work on Live typing. Furthermore, nothing stops you from doing full formal verification if that's your thing.

The obvious downside here is that you need to write the metadata. That isn't very hard if you do this as you write your code, but when you have an existing code base, it's a bit tiresome and a lot of work.

Of course, you can apply various techniques to generate the metadata for you as I suggested above. Once you have some live methods, it gets easier; you can see what methods they send, and use the calls to create live data for the methods being invoked, recursively. I haven't yet pursued these options; the tooling is in its infancy right now.

There's a lot more one can do with this information. For example, we don't support name completion - but obviously, that is easy to do once you have live exemplar data.

Interesting to note that static types are not really needed for name completion in this scenario.

In fact, we can use the exemplar information in the opposite direction, to generate tests, or type information.

The current version still needs a lot of polish in terms of UI. I hope that over time, we'll gain more experience and fine tune the interface accordingly.

Nevertheless, the first step, as I've argued many times, is to choose life.