New methods of debugging

if you were to create a new programming language, what kind of new/unknown debugging methods would you have for it?

Other urls found in this thread:

en.m.wikipedia.org/wiki/Delta_debugging
sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution
youtube.com/watch?v=KCWVusIztlY
twitter.com/AnonBabble

make the languega tell you what's wrong and how to fix it!

it might be possible to some extent if something like en.m.wikipedia.org/wiki/Delta_debugging can be fully automated. at least for the what went wrong part.

Probably just Common Lisp's debug methods together with checkpointing. This doesn't really require a new language though.

The field of debugging is complete. I can't imagine any new kind of print statement that one might need. Every existing language supports comprehensive string and number printing. More modern languages support printing of arbitrary data types, including arrays and structures. I've seen some languages that will even print out function definitions. Everything a person could need printed can already be printed, there is nothing new to add.

...

This, when a Common Lisp program crashes you are dropped right into the debugger. You can fix the source code, re-compile it and have your program running right at the point where it crashed. Not to mention that the debugger is running in Lisp as well, so you use the same language for debugging as for writing the code.

Don't forget *debugger-hook*.

I'd provide a graphical map of all instantiated objects that could be navigated.

Most IDEs provide both call and type hierarchy tree views.

Rewind/step-back.

Reverse execution is already a thing.
sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution

Bug driven development.
I would say more but I know this shithole is full of LARPers who'll pretend they came up with the idea first.

That's just threat modeling.

Even if you're right, you're wrong for not explaining your point.

Adorable.

Attached: 24b48d3a21055f13250bc48a61246c3a6c712521a9db01984a8dff28642da194.gif (200x250, 2.6M)

I don't want a tree or stack, I want a big diagram, where each object is a circle that is bigger depending on the memory taken up by that object and that I can zoom into to see the values of members as well as observe while the program is running.

You are probably thinking of bug chasing.
I'm talking about full on bug driven development. All I need is a good cover and I'm ready for that O'Reilly money.

If that's different than the existing BDD, you might need an original name too

What are the edges of the graph representing?

you want fast compile times for quickly testing changes
youtube.com/watch?v=KCWVusIztlY

I like to imagine this one guy responds to every incorrect post he sees with "Wrong" like this

How do you debug a compiled language though?

Here's another example for a place for improvement: visualization.

being able to visualize geometry and data structures would be very useful.
making it easy to do with the language will help a lot.

The compiler can leave debugging symbols in the binary. It bloats the file size a little, but it's generally negligible and the benefit of being able to debug on the user-end is worth it. In GCC or clang for example you have to pass the '-g' flag to the compiler.