It may not be viable for "real" programming, but what I like these days is to just write some code without even trying to think too clearly about what I am doing or the details, and sprinkle asserts that encode how things should be if I was following what I am doing.

Then I run it interactively with source debugging and when anything goes wrong, I do some editing and more than half the time I don't even have to restart the program from the beginning.

And the more subtle the things I "assert" the more direction I get when they are violated. It eliminates a lot of effort in sorting out incorrect ideas when I can just encode my incorrect ideas and let the computer find the problem.

I've always shied away from Lisp and similar, but I'm definitely reminded of how advocates describe the benefits of developing in an interpreted environment. When I was a kid, I always had the sense that only compiled languages were prestigious, industrial strength, professional, whatever.

Lisps are compiled, generally. It's just that you can add new compiled functions to a running image, and replace existing compiled functions. The running time of compiled Common Lisp can approach that of compiled C code, and sometimes be better.

The dividing line between compiled and interpreted languages has become permeable these days anyway. Perhaps the better dividing line is between languages that are designed to compile to efficient code, vs. languages whose design precludes that. In some cases this may just mean we need smarter compilers. And this is where I really like this kind of language fuzzing: it's a great way to test compilers, and can be extremely helpful at firming up implementations of complicated optimizations.

"Lisps are compiled, generally"

The environment I was working in is compiled also, but like you say, you can modify it while running.

That's roughly how I write Erlang programs, which is probably not how it should be done but it is surprisingly effective. First write your base cases, then add exceptions until it works.

Author here. Functional languages indeed avoid many code defects from its own design, and it is also easier to locate the problematic code. That's why we originally chose Rust rather than C++ to develop the TiKV project in PingCAP.

It's hard to implement a bot to do auto-debugging. The purpose of this Hackathon project was to develop a tool to improve debugging efficiency. Check out our progress on https://github.com/fuzzdebugplatform/fuzz_debug_platform.

I totally agree with that, mate. I wonder how efficient we developers would be if we can mix good designing techniques with good toolchains like those.