[edwinnathaniel]

I've been using Python for a while for fun and Ruby (Rails) on and off.

I've always find it interesting how the Python/Ruby community debug your code both during development (coding or writing unit-tests) and perhaps in production as well (for the record, I use "print" as my debugging tool).

I'm a long time Eclipse user who has recently converted to IntelliJ (almost a year) and the debugger that comes with these editors is something I can't live without hence I have not moved to Emacs or VI(m) or whatever the UNIX hackers use because it would crippled my productivity significantly (or so I thought, feel free to criticize my point of view).

So sometimes I'm wondering how productive Python/Ruby + VIM/Emacs users. Just an honest question really.

PS: most Java IDE debuggers can do local AND remote AND has some support for hotswap code.

[gknoy]

I've used "println debugging" more than I have used an IDE's debugger, and am more comfortable with the former. I think it revolves around a different way of using them, and is likely very heavily influenced by having spent a lot of time developing with a REPL handy.

When I did mostly Java coding, I would tend to use println debugging rather than dive into the IDE's debugger, as I tended to be able to zero in more easily on what was going on when I took a holistic "Let's print out each item's id and name ..." approach to start.

Now that I do most of my code in Python, I use the interactive debugger almost exclusively.

With an IDE, I can look at variables' contents. What do I do when I want to check the result of a method call, though? It is likely tool unfamiliarity, but it's never been clear how to check that as something to inspect. (If you know how to do this, then you're a much more savvy user of the IDE's debugging tools than I am.) If I don't have the right breakpoint, or the right questions, I often glean little.

Println debugging is an easy way to see that you're looping incorrectly, or that All Your Data is bad in a way you didn't expect.

With a REPL-style debugger, I can treat it as an interactive question/answer session that lets me check things like contents of the database, or the values that helper methods return:

  > print len(foo.items)
  0
  # why??? Maybe the objects don't exist?
  > print Foo.objects.filter(bar=42)
  [foo1, foo2, foo3]
  # Let me place a new breakpoint then in 
  # my JsFoo.from_db_item() method, and try again ....

I think the nicest thing about an interactive debugger is that it lets me construct arbitrary expressions -- print lists of things, look at nested data, etc -- in the language I am already developing in. I always had a hard time doing something quite as powerful in Eclipse.

[edwinnathaniel]

I used to do "println" debugging trick during my early days of programming until more senior people around me slap my hand and told me to use the debugger efficiently and effectively.

In Eclipse/IntelliJ you can set "Conditional Breakpoint" (only stop/break when certain conditions is met) very handy when debugging a loop. In addition to that, you can also set "breakpoint on any Exception".

Also, in Eclipse/IntelliJ, when the debugger hits the breakpoint, you could execute Java code within the context of that breakpoint (of course, java.lang is given by default in addition to the context of that breakpoint).

I've never done more complex debugging than that but I'm guessing you can write almost anything you want within the "evaluate window" in those IDEs.

[cgh]

Yes, the ability to connect to and debug a remote, running JVM is a killer feature. And it is well supported by IntelliJ and Eclipse. But it's a function of the JVM and not the debuggers themselves - if the Python runtime offered remote debugging then I'm sure Python debuggers would support it too.

[tejaswiy]

I was about to bring up the exact same thing. I see some positivies in the the text editor not IDE approach that linux / unix folks take, but I don't find this approach so amazing that programmers need to trade intellisense / auto complete / In-IDE debugging / Refactoring features for this.

[dima55]

The emacs debugger infrastructure (gud) is pretty great, and is common for a multitude of languages. Add on top of this other fancy pants emacs features (for instance remote anything, including debugging via TRAMP) and emacs users do better than most.

[pjmlp]

> So sometimes I'm wondering how productive Python/Ruby + VIM/Emacs users. Just an honest question really.

As much as a UNIX System V user.

[puller]

You are doing it wrong, and you are making generalizations about these languages on the basis of your doing it wrong?

[vdaniuk]

Yeah, it would help if you would point out what exactly this person is doing wrong.

[pekk]

This person who is holding forth on the deficiencies of $language debugging uses 'print' as the favored debugging tool. IN PRODUCTION. That's completely disqualifying