Coding in the Debugger (2007)

This is debugger driven development

In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly.

Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc.

Once you try this you'll never want to go back to print-debugging (except for specific cases)

For my job I work in Pharo. So I am still doing this all the time, haha.

What’s also really neat is to be able to work “inspector-driven”. By that I mean to inspect an object and send messages to it directly in order to understand how to interact with it. This becomes even more true if you need some temporary global data that has no permanent reference to hang around for a bit longer.

Question: I want to make a tutorial about creating a Selenium scraper with Pharo along with some data visualization and post it on here. I have noticed that Pharo is really strong on those things. Does anyone have an idea which site I should pick? Perhaps Hacker News itself? Also, the tricks I will be showing there would also be really handy for Selenium web tests. I wonder if people ok HN would be interested in that.

I've seen so much absolutely crap code that I bet would never have been written if the author had just taken the time to step back and think and look at the big picture before writing a single line instead of focusing on microscopic bits and being hand-held through writing it all. After seeing what typical Enterprise Java looks like, I'm not surprised when I read articles about doing things like this.

TDD gives programmers a false sense of correctness. The temptation to "mess around with it until it passes" is far too great.

Its funny, as I am still not good at step debugging in lisp, but https://malisper.me/debugging-lisp-part-1-recompilation/ is a great example of basically the same concept there. Really, that whole series was amazing fun to read through.

In Smalltalk this was always possible! In Java the default JVM implementation is able to do "hot code swapping" only for method bodies. Smalltalk was able to replace everything - even class restructuring. There was a research project at Sun/Oracle [1] to add JVM support for all possible changes in "hot code swapping"... but the implementation was not incorporated into JVM because of increased maintenance complexity so the author made a JVM fork and named it DCEVM and is maintaining it [2]. I thing this project is also connected with HotSwapAgent [3]. There is also a completely different commercial implementation of the hot-swapping capability for Java called JRebel [4] which is used on many software development projects...

[1] https://ssw.jku.at/dcevm/ [2] http://dcevm.github.io [3] http://hotswapagent.org [4] https://www.jrebel.com

When I was young, we programmed in the debugger all the time! And we liked it! https://everything2.com/title/Writing+.com+files+with+DOS+de...

I used to work with some ex-Smalltalkers who did this all the time, while complaining about his much worse Java's debugger was than Smalltalk's.

Here's a quote which I got from comp.lang.lisp, long ago:

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.

I love doing this in Python/Pycharm. I feel like there are three development modes:

1. Greenfield new development, on unknown parameters (complicated APIs, data frames). I like to use Jupyter Notebooks for that. I use them like a really powerful repl, nothing lives permanently in a Notebook.

2. Type Driven Domain Driven development. Either as a result of building a running MVP through 1, or on a domain you control / understand well. You start from frist principles and model out the flow in Types (usually DataClasses in Python).

3. Debugger driven "Adding Features/ Debugging". Obviously, we use the Debugger to debug, but it can also be very powerful to add a feature to a large system.

I still do this all the time with Java. Especially because the application is rather slow to start or setup whatever I want to debug. It can also influence how you structure the code. In my opinion to the better.

If you mutate state all over a method it is harder to "restart" the method after changing it. Instead I tend to either not mutate state and return the result or work with local variables and just change the object at the very end of the method.

Or might start to more separate a lock/transaction from what is processed within because when "restarting" the method you don't want to relock it.

I'm a big fan of repl driven development for some tasks but you do need to go back and refactor plus add tests.

I often write some code, and then edit and correct it as I step through it, since I know there is a 99% chance that there will be bugs in it

And this, boys and girls, is why you want to use a real IDE with an integrated debugger.