Hacker News Reader

Comment by srazzaque | Hacker News Reader

I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus the other.

Logging, done well, will inform (1) exactly what version of your code you were running 3 months and 12 days ago, and (2) where the potential issue may be.

Therefore it will inform you _where to place a breakpoint_ should you wish to repro the issue and debug locally.

Good luck getting started in a local debug session without having had adequate logging in place.

View on HN

There are a lot of contexts where debugging isn’t feasible, like rubbing your (flaky) test 600 times to figure out why it is failing 2 out of 600 runs. Since starting my job at Google a couple of years ago, I haven’t used a debugger once, it wouldn’t really work for what I’m doing. Couple that with remote development limitations (and not being able to run an emulator truly locally), and it doesn’t make sense to use a debugger even when it might be useful.

Also, when trying to reproduce an issue, adding logs can often be more helpful than using a debugger:

With the debugger, you can only see the application state at one specific point at the time.

With added print statements, you get a nice history of the application state.

If I already know where exactly something is going wrong: sure, I'll could a breakpoint there, if needed - often it's not.

If I don't know where exactly the problem is, I'll add print statements.

> With the debugger, you can only see the application state at one specific point at the time.

Really depends on the debugger. Some tools support “time travel” debugging, which essentially stores a structured log of memory state over time.

The Smalltalks are nearly unmatched on this. Pharo is a great representative of this tradition.

"One aspect which has not yet been focused upon is that in modern Smalltalks (forget about the block-fiddling in ST-80) exceptions are proceedable. This means, that the exception handler may decide to repair some malfunction and continue execution after the point where the original exception was raised."

https://wiki.c2.com/?SmalltalkAndExceptions

So it falls short of full fledged past time travel. It's more like you could stop the flow of time, fix whatever went wrong, and then restore time flow, as if nothing had happened. Short of what OP wanted, but still very useful. It avoids "Groundhog Day" debugging.

> Short of what OP wanted…

(That wasn't what I wanted to post; I should have waited.)

More like stop the flow of time, fix whatever went wrong, fix why it went wrong, go back before it happened, and then restore time flow, as if nothing had happened (so more restart before than resume after).

I don't know if that's what the OP wanted or not, I'll leave you to explain.

https://news.ycombinator.com/item?id=28361693

https://news.ycombinator.com/item?id=28361845

Sorry, I got confused.

About what the OP meant or about what I meant? :-)

Probably both.

This is also possible in common lisp.

Even better luck debugging in the enterprise without logging. You won’t even know which machine your code is running on and in which machine Splunk is spitting out the logs. Without printing time stamps and debug worthy information to the logs, you are fucked, period.

FOr multi/parallel issues, debuggers are practically worthless.

Logging + threadid + timestamps and something to organize/sort the output is about all you can do.

Debugging parallel/multithread code is a badly unsolved problem in programming, and something that TDD, which tends to focus on single thread units, also doesn't really address.

I think it would require something that can built on-the-fly visualized reconstructions of what happens, almost like a starcraft game where each unit is a process/thread and it replays events from the log in reversible forward/backward slo-mo. Interactions or message passing can be attacks on other "units".

Or some dynamic graph/process diagram builder that links together the processes when message passing occurs or flashes/changes color as interal process state changes.

Good news everybody! All your code should be built with the intent of multithreading or parallelism to some degree, since that is all that we can really do with the remaining scaling from Moore's law, and really has been for a decade now.

Edit: oh I forgot. Debugging multithread isn't even a single-VM issue now. Even more common is visualizing interactions across many many VMs thanks to microservices.

When writing multithreaded code I need some visualization of where everyone could be. It's expensive invariant management.

There is a partial order that is fine and there is a partial order that is not fine. If we could define the orders with a sorting function and apply them to events in real time that would be perfect.

In effect my partial order cannot overlap your partial order. This is the grounds of the YATA algorithm.

Happens before relation is really powerful. But it needs to be visible to other processes.

Sounds like code proofs and other things which I last saw in the 1990s in school.

But I see how once you have to cross the rubicon to parallel processing, to make it sane, you'll need to rethink the old ways from simpler serial execution programming.

I wrote a lock free algorithm.

Every thread monitors every other thread's thread Id and the lowest thread Id wins. When a thread finishes its work it updates the thread Id to Integer.MAX_INTEGER so someone else can have a go.

Readers block writers and writer's block readers so it's not very good. But it's a start.

It's hard to update a linked list as you could accidentally partially update it while it is being iterated. I could allow parallel edits and reads if the read is after the edit. So I would need to introduce a different variable for checking while reading. It needs to be logically after the write.

HTTPS://GitHub.com/samsquire/compare-and-swap-sort

I don’t think he’s talking about logging here. He’s saying that devs are more likely to print variable states, etc to their console rather than load up the debugger to step through.

> I don't quite understand the argument here. Logging statements and "using a debugger" are not enemies of one another, with tribes of people in one camp versus the other.

Just yesterday I debugged a problem starting with gdb and ending with print statements. I needed both to find the issue. This isn’t an emacs vs vi debate, I completely agree.

It's clear that he meant they are only using printf debugging. The most basic form of debugging. The point is that most developers don't use the tools that are available to them. They're stuck in the stone ages.

Nobody is saying that you should never use printf debugging. Sometimes it is the best way.

Reply on news.ycombinator.com