Programming In The Debugger

From http://www.object-arts.com/Lib/EducationCentre4/htm/programminginthedebugger.htm

The ability to restart methods that have been recompiled in the Debugger allows for an approach to programming which is virtually impossible in any other programming language. Imagine doing most of your development work in the Debugger rather than the Class Hierarchy Browser. This is not only possible but often very desirable and leads to high development productivity.

Many or most Lisp systems and every real Smalltalk have supported this since 1980 (EnfinSmalltalk was not real).

I do this in MS Visual C++ (Edit-and-Continue) but I always look over my shoulder to make sure nobody is watching me. Feels like a bad thing to do. But then C++ isn't SmallTalk.... -- AndrewQueisser

There was a Z80 assembly development package for the CPC464 called Laser Genius (part of a suite of tools - there was also Laser Basic that added a ton of extra commands to Basic to do graphics and sound stuff and Laser Compiler which was a Basic->machine code compiler. Which bit. Sorry, but it did. There were two of them; Laser Compiler and something else written by the guys who wrote Maxam. That one bit as well. Laser Compiler generated poo code and the other one only did integer maths.. ) Laser Genius wasn't bad. The assembler included a low level C syntax for doing stuff IIRC, which was nice. Although the editor was, erm, a pain... Anyway, the debugger that came with Laser Genius included a whole ForthLanguage implementation. People allegedly wrote games in it that ran alongside the actual code they were debugging... -- KatieLucas

VisualBasic 6 supports this; you can change code and continue while debugging. This commonly leads to a most amusing spectacle when, after hours of debugging and writing code, the VB6 IDE crashes, losing all the changes the coder has made since the start of the run. (I've heard plenty of screaming over that one! ;-)

VB7 (VB.NET) does not support this functionality. -- JeffGrigg

Smalltalk records the changes just as if they had been made from elsewhere in the environment. The (bad) behavior described for VB6 is just bad code.

Marvin Minsky apparently employed DebuggerOrientedProgramming?:

"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." -- Joe Marshall in http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&selm=3c53v53t.fsf%40ccs.neu.edu