Interactive Programming

By way of Joe Marshall in comp.lang.lisp:

Here's an anecdote I heard once about Minsky.  He was showing a
student how to use ITS to write a program.  ITS was an unusual
operating system in that the `shell' was the DDT debugger.  You ran
programs by loading them into memory and jumping to the entry point.
But you can also just start writing assembly code directly into memory
from the DDT prompt.  Minsky started with the null program.
Obviously, it needs an entry point, so he defined a label for that.
He then told the debugger to jump to that label.  This immediately
raised an error of there being no code at the jump target.  So he
wrote a few lines of code and restarted the jump instruction.  This
time it succeeded and the first few instructions were executed.  When
the debugger again halted, he looked at the register contents and
wrote a few more lines.  Again proceeding from where he left off he
watched the program run the few more instructions.  He developed the
entire program by `debugging' the null program.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Where did you hear this?

I've heard this general technique described quite often and have used it in Smalltalk liberally sometimes, and I wondered where it came from (googling for "squeak" and "debugger-oriented programming" yields only IRC comments by myself, but I swear there was a discussion on it in the Squeak mailing list). Is there a relatively definitive source to cite for this? It would help immensely in terms of the literature to generalize to establish where and how this practice arose.

Anatomy of Lisp

The earliest description of this style that I've personally seen in the literature is the "Interactive Programming" section of The Anatomy of Lisp (1978). I wouldn't be surprised if the MIT AI Lab archives had some similar stuff, and if so I'd like to read it, but I don't have any references.

"Programming in the debugger"

"Programming in the debugger"

That's where I first heard it.

Does this mean language doesn't maater?

I think this idea is even found in the Jargon file. But does this story mean this technique is applicable and useful for all languages? I think not.

Dynamic languages

Certainly not. This is the distinguishing feature of dynamic languages.

Not that term again....

Is Hskell dynamic? Because to me what you want is interactive shells, interpreted style execution etc. And not necessarily dynamic typing which is what most people mean when they use the term "dynamic languages".

Dynamic = Interactive

Absolutely right.

I'm perfectly comfortable with the term "dynamic language." To me it
means "language that supports interactive programming". I find this
definition consistent with the popular usage, though I've only read
what comes through LtU.

When people try to distinguish dynamic languages based on type systems
they seem to be talking about roughly C and Java vs. Python and
Ruby. From that set the statically typed languages don't support
interactive programming and the dynamically typed ones do, so their
conclusions are understandable. But the real point is interactiveness.

Is Haskell a dynamic language? In my very limited experience it is:
I've found Hugs a comfortable interactive programming environment. But
having only written single-file Haskell programs I really haven't
pushed it, and intuitively I think a lot of the things I do in my
daily interactive Erlang/Lisp programming wouldn't be possible with
Hugs, or with any statically typed language. But that's intuition.

Perhaps I can turn the question back to you: to what extent is Haskell an interactive
programming language like Lisp and Smalltalk?

Personally, I think dynamic=i

Personally, I think dynamic=interactive is the only definition that makes sense, and I would judge Haskell as dynamic in this sense, when one uses a Haskell interpreter.

I think type system issues impact the expressiveness and usability of interactive languages (think about local vs. non-local type checking; type systems for modularity; type information at runtime; code mobility etc.) I don't this the relevant issue is type safety and/or soundness. Contrary to what some people propose, I don't think that the only way to create good interactive languages is to eliminate type safety of static guarantess on code behaviour.

Great site

We've made some agreement over "dynamic languages"? I like this new LtU! :-)

I hope its jus the two of us

I hope its jus the two of us and not a general trend. It would make life too boring not to have these holy wars...

"Dynamic implementation", not "dynamic language"

I'm perfectly comfortable with the term "dynamic language." To me it
means "language that supports interactive programming".

I don't like this usage for the same reason I don't like "interpreted language": it confuses a property of the implementation with a property of the specification.

You are right

It's more a property of the implementation than of the language. I should have stressed that myself.

However, I think it is important to realize the language features can impact implementation choices (and the other way around), so things are slightly more complicated than they may seem on first look.

Given the right light, can I call C++ interactive?

Indeed, but at the extreme, it is possible to implement even languages such as C++ in an "interactive" manner. As one example, see Edit & Continue support in VC 6.

Is a strongly-typed language with fully-interactive environment the holy grail of programming?

Good question

That's exactly the question needed to move discussion fwd. The answer is "yes, but..." The "but" signifying that the dynamic/interactive nature of the implementation isn't all you want from a language. C++ is still longwinded, comes with ultra-complicated libraries, requires low level programming techniques etc.

Is a strongly-typed language with fully-interactive environment the holy grail of programming? I don't think so. Personally other issues like rich programming constructs, good libraries etc. seem more important...

Implementation choices

Features impact implementation choices, but making a language more "dynamic" is always easier than making it more "static". An interpreter is always easier to write than a compiler. A dynamic analysis is easier to write than a static analysis. An online partial evaluator is easier to write than an offline partial evaluator. A procedure is easier to write than a macro.

Even C has interactive implementations.

Evanescent TDD

The anecdote reads like an early example of Test-Driven Design, except that you don't end up with a set of unit tests.

Yes, that's exactly...

...what I thought when I first read about TDD. Basically, my reaction was "What a great idea! How come I never thought of sticking the expressions I feed into the REPL into a file and calling them my test suite?"


In fact, this was my facetious comment on reddit to this anecdote:

It sounds almost like test-driven development, except that there is no test suite as such, just "does the program crash" or not.

As such, it should probably have been considered a spike solution, thrown out, and rewritten with genuine test-first methodology in place.


My view all along was that the main contribution of TDD was automation (e.g, jUnit) and IDE integeration. The rest of it is just things you did ayway. If you were a half decent programmer that is...


The rest of it is just things you did ayway. If you were a half decent programmer that is...

I think this depends on what you understand by TDD.

As a design philosophy, TDD is much more than just writing unit tests (which unfortunately is what most people understand by the term).

If you read Kent Beck's TDD book and follow along faithfully with the approach, I think you will find that it creates quite a distinct programming experience and results in a cleaner style of code.

If you read Kent Beck's TDD b

If you read Kent Beck's TDD book...

I did. I also read Wirth on stepwise refinement all those years ago. And I think stepwise refinement, and coding unit tests brings you very close to Beck's TDD.

Only major difference is their insistence on doing the simplest things even when completely trivial and coding tests and running them even when you know you haven't written the code to pass them yet. I can understand this insistence, but I find it a big dogmatic and inessential.

Does anyone have a cite for

Does anyone have a cite for this?