Mastering Ruby debugging: From puts to professional tools | Hacker News Reader

Mastering Ruby debugging: From puts to professional tools

blog.jetbrains.com

70 pointsthunderbong12 comments

It's a bit silly to claim that any debugger comes with zero performance "overheads".

And somehow they failed to think of any drawbacks for the debugger they ship in their paid software...

I use nvim-dap with nvim-dap-ruby; it's excellent.

Every benefit the post ascribes to RM's debugger applies to nvim-dap (modulo the user's ability to do basic neovim customization), with the added points that:

- nvim-dap is protocol-based, so you can use the same configuration with many languages

- it's completely free

https://github.com/mfussenegger/nvim-dap

https://github.com/suketa/nvim-dap-ruby

I spend most of each working day debugging with binding.pry. A colleague who is much smarter than me rarely uses it. He just stares at the code and figures it out. Forty years of coding and I still can't get away with that enough to put down the debugger. I've been playing chess longer than that and still can't play without the board, which I think of as a similar skill.

So I think of the debugger and the chess board as prosthetics that allow people who like me who are handicapped by a lack of brilliance to perform at a useful fraction of the truly talented.

Plus it's fun. The fast feedback and rapid iteration has the same kind of psychic reward as a good video game.

Sometimes I just end up staring at the debugger instead. After enough staring and maybe a good night's sleep I figure out it was a silly mistake like copying and editing a line of code but forgetting to update some parameter.

Debuggers are great, right up to the moment they aren’t. Conditional break points can be slow enough that you may be better off putting the condition in the code and hitting a normal breakpoint on the rare occasions the condition is true. Concurrency can be tricky as well, there’s nothing quite like discovering everything works because the brief pause from you looking at a breakpoint is enough to change the behaviour.

Yeah I still can't figure out how to use a debugger with async or concurrent code.

I understand neither way, cause I’m staring at the extensive stdout/log.txt instead. Why pause, watch, evaluate or search for branches with conditionals if you can just see it all at once, search, go back and forth and distill by grepping. Using a debugger feels like walking through a maze over and over instead of just looking from above. (And not using anything is imo just a waste of time and your employers money, if you have one.)

I missed seeing what the developer experience of the RubyMine debugger would be for this specific problem. Mentioning its advantages is good, but you have the perfect chance to putting it into action in front of your audience!

My favorite ruby debugging tool is pry. When the code "binding.pry" is executed in ruby, you get a irb like shell.

pry is what I miss most when using other languages. I've used all kinds of debuggers all kinds of hardware with many different languages, and pry is by far the best tool for development and debugging. People talk about the REPL in Lisp for good reason, but pry takes that concept to infinity and beyond. When I think about the future of AI assisted programming, it's something much more like the pry interactive development loop than a code editor's suggestions.

Can you say more about how pry goes beyond the REPL?

pry-byebug (combines pry and byebug together) is my favorite tool these days

binding.irb all day

Reply on news.ycombinator.com