Hacker News Reader

Comment by collyw | Hacker News Reader

I disagree.

I have my IDE setup with some scripts to copy a database from production. Set some breakpoints and press the play button and I am debugging.

With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging. I personally don't find it anywhere near as efficient as an IDE that has been setup. Plus with the IDE I can stop at a certain point in the code, have numerous variables populated then run "evaluate" in PyCharm, which gives most of the benefits of a REPL as far as I can tell.

Admittedly the IDE does take a fair bit more effort to get to a state where it is set up to be useful, but dealing with the whole system as opposed to a small part of it is incredibly beneficial for development. Though I guess a lot depends on the type of problem you are solving.

View on HN

>With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging.

No, you absolutely do not. You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc.

Just make sure you've shoved an import IPython ; IPython.embed() in there and you're good to go. No additional imports necessary.

I agree that having your environment set up with production data (or as close an approximation as you can get) is a good idea, but I'd rather script that with a test framework where it can be used for regression testing rather than bodge it together using an IDE.

"You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc."

This is generally a lot less effort than populating objects in the REPL to reproduce the same set of conditions.

That's basically an admission that you're not writing enough realistic tests or your dev environment is set up wrong.

For me, it's way way easier the other way around.

Ahh the classic "you're doing it wrong" reply with no advice on why it is wrong.

Do you need advice on why creating a code base not surrounded by realistic & reliable tests is a suboptimal approach?

Or did you think that once they're there it would still be a lot of effort to use them to populate objects?

Doesn't mean that its going to catch the bugs that are present. An IDE when properly setup is closer to a production system than a load of unit tests and as such will be able to fix far more bugs in my opinion.

But you are welcome to do what works for you. Maybe you work on something more suited to your approach. My approach works better for what I do.

I write integration tests, as I mentioned in the first post and realistic ones as mentioned in the second. I try not to write unit tests because, as you mentioned, they are unrealistic (among other reasons), and unrealistic tests tend not to catch bugs.

That said, a high level 'unit test' (e.g. one that manufactures a request and checks its response) is often realistic enough and works pretty well with IPython.embed().

> I have my IDE setup with some scripts to copy a database from production.

Can't you just run those scripts as the first thing in your REPL session?

That just copies the data, its doesn't do imports or initial fetching of data - which running the application in and IDE does for me.

Having an IDE setup is pretty essential to my job, so I am going to need that for debugging certain errors anyway. Once that is setup, I rarely see the need to start scripting things for a REPL as a debugger feels far more useful to me.

The "Open Debug Prompt" in Pycharm is the best of both. Breakpoint at the point of interest, enter the REPL, and continue writing at the prompt. Also good in Matlab. I hope I can see this feature in Rust someday, although it seems like a tall order for a non-interpreted language.

Reply on news.ycombinator.com