It would be amazing if someone could design a programming language around debugging. There are many languages that are designed around preemptively catching bugs using a type system, and I do use static type systems, but this in no way oblivates the need for a debugger.
The way I want to write code is directly as it is executing. I think the distinction between writing code in an editor and debugging is arbitrary - I want to edit programs as they are running and see the data as it flows through beside the code. I want to be able to browse the object graph as if it were a filesystem like I could in Objective-C (I think Smalltalk invented this?).
This does require a different code architecture to be effective: more pure functions and less tangled state, but those are usually considered to be good things. Improving debugging might have a positive effect on code quality.
Clojure is both a good and bad example of this. Live hot-reloading means that you really are editing programs as they are running. This is especially visceral if you're working on something with a GUI component as you can see the GUI change before your eyes as you work on it. And if you're really adventurous you can open up a REPL connection to a running program in production and edit your production service as it's running (don't worry you can disable this so that random folks can't start modifying your production code)!
On the other hand, running a debugger in Clojure is a bit of a mess. Generally I just don't and end up creating "watchdog" atoms that hold bits of state that I think are relevant to the situation at hand and evaluate those with a live REPL connection. See e.g. https://eli.thegreenplace.net/2017/notes-on-debugging-clojur.... Although the article ends on an optimistic tone, I've found using a debugger with Java or Scala more rewarding than using one with Clojure.
I would like if existing languages allowed you to "level up" your code.
examples that have worked for me: "use strict" in perl, "tainting" in perl, assertions in C (runtime and compile time), -Wall -Werror in shared codebases, and similar.
the idea would be to incrementally make everybody's code a little better in manageable increments.
> The way I want to write code is directly as it is executing. I think the distinction between writing code in an editor and debugging is arbitrary - I want to edit programs as they are running and see the data as it flows through beside the code.
I do something like that every day, especially when I'm dealing with weird and arbitrary APIs (which is most of them). I write as much of a function as I know how to do, set a breakpoint on the next line, and run what I have until it hits that breakpoint.
Then I can write the next few lines of code while looking at actual data.
If it happens to be Python code and I'm using IntelliJ, I can also open a Python console - a REPL running in the context of my breakpoint.
This helps me understand the libraries and APIs I'm working with in a way that just editing static non-running code doesn't.
Counter-intuitively, I wonder if this has contributed to jupyter notebooks' popularity. You write your program in pieces (cells) that you can run independently; modifying, going back, rewriting, and rerunning bits on the fly. Which is hilarious to me, since the usual kind of debugging is so painful in jupyter. You could imagine an alternate history where we had amazing debugging and jupyter never got quite as popular. Hell, maybe even REPLs wouldn't be as popular.
Elm has some of this built in. Not a debugger per se (you cannot add breakpoints and step through the code), but since everything is pure and there is only a single state, you have a single source of truth and a function from that truth to your view. One can replay the different transitions, and see the whole state of the program at those times.
elm/browser was recently updated. If you compile in dev modus it gives you a small button to press in the webapp, that opens a new window where actions and state can be replayed.
Visual Studio lets you do some of this in a clunky way with ‘Edit and continue’, where you can edit code after a breakpoint in the same method. I believe most browser JS debuggers let you edit the JavaScript, though it can be quite buggy.
What is clunky about it? It even allows you to drag back the current program pointer to a previous line in your program, change the code and run the section.
One problem I found was it doesn't work with generic methods though, not sure if MS is working on making that work. To me "Edit and continue" is a great tool.
Somewhat opposite direction is languages features that increase the need for more debugging tools.
As c++ is getting more and more features for compile time code evaluation it raises need for debugging them. One language that gets it right is Haxe. It allows executing arbitrary code at compile time for AST manipulation. Official implementation comes with a debugger that can debug it just like regular code.
Does anyone knows something similar in other languages or build systems? Does any of LISP environments provide such debugging functionality?
The compile-time code evaluation in Lisp usually is just normal Lisp code evaluation, since the compile-time environment is also just Lisp. Thus the usual debugging tools apply.
Julia does this. You can run the code and you get the output right next to it in an expandible dialog. You can write your while program this way, executing a line of code, tweaking it until it is correct. It can be quite nice. My one complaint is that VSCode doesn't have support for this, so it runs in Atom, and I find Atom to be quite slow and buggy.
The way I want to write code is directly as it is executing. I think the distinction between writing code in an editor and debugging is arbitrary - I want to edit programs as they are running and see the data as it flows through beside the code. I want to be able to browse the object graph as if it were a filesystem like I could in Objective-C (I think Smalltalk invented this?).
This does require a different code architecture to be effective: more pure functions and less tangled state, but those are usually considered to be good things. Improving debugging might have a positive effect on code quality.