Hacker News Reader

Comment by jacquesm | Hacker News Reader

I love all these developments. The hard part is to define what failure looks like, that can sometimes be as hard as the rest of the work of partitioning the code until the bug has too little room to hide.

The best protection against bugs is still not found in debugging fast or automatically but by reducing scope right at the design stage, the smaller the scope the easier it is to find bugs. This is one of the reasons why I think in the very long term functional languages will win out, they reduce scope in a very natural way because they tend to be almost side effect free unless you explicitly code that in.

Languages that make it easy to access stuff that is out of scope tend to feel very productive in the beginning of a project but you get bogged down quickly because everything starts to interact with everything else and soon it is too much to keep in your head at once.

View on HN

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.

Reply on news.ycombinator.com