4 ms·

When I learned about the repl. For me 90% of debugging is about figuring out how to break at the crucial line and then shining the repl light on it. 75% of writ

When I learned about the repl. For me 90% of debugging is about figuring out how to break at the crucial line and then shining the repl light on it. 75% of writing new code is about trying stuff in the repl and then stepping through the code in the repl and testing everything. For me that quick feedback loop makes coding as fun as gaming.

debuggingnoob 6y ago
Would love to see a video of what this actually means. I'm not sure I've ever written code for which I can use a REPL in any meaningful way so I must be doing it wrong. Videos of actual real world coding/debugging (not examples that are too simple and therefore not real world) would probably be very enlightening. I mostly do graphics stuff and there are 70 lines of setup until I get to the 1 line that executes something based on the 70 lines of setup. But even in non graphs code my program 1000s of lines, all of which have to execute where as a REPL is one line at a time so yea, a video would really help see how to apply this.
- ladberg 6y ago
  It's easier in some languages than others, but I would say the most common case is in Python (partially due to ease of dropping a REPL, partially due to lack of compile-time checks). The one line of code you always should have at your disposal is: from IPython import embed; embed() Basically, if you have an error and can't figure out what's happening within a few seconds, stick that line in before the error and Python will give you a REPL to play around with. It's like GDB but way better.
colecut 6y ago
Out of curiosity, what language(s) are you working with?
quickthrower2 6y ago
Aka interactive window for c# devs using VS
dusted 6y ago
When I'm in the middle of my program and in need to change or implement some kind of algorithmic behavior, I often find that trying stuff out in a repl (node) help me understand and examine the problem much faster and in a more flexible way.
EastSmith 6y ago
That is my Aha moment too, but I have generalized to: Never start real work, until you can set a breakpoint in your IDE, where you can try things in the console. I know there are people that can write code for couple of days without running it (seen this with some java colleagues I've had), and then it all almost always works when run, but I am just not that kind of developer.

debuggingnoob 6y ago

Would love to see a video of what this actually means. I'm not sure I've ever written code for which I can use a REPL in any meaningful way so I must be doing it wrong. Videos of actual real world coding/debugging (not examples that are too simple and therefore not real world) would probably be very enlightening. I mostly do graphics stuff and there are 70 lines of setup until I get to the 1 line that executes something based on the 70 lines of setup. But even in non graphs code my program 1000s of lines, all of which have to execute where as a REPL is one line at a time so yea, a video would really help see how to apply this.

ladberg 6y ago
It's easier in some languages than others, but I would say the most common case is in Python (partially due to ease of dropping a REPL, partially due to lack of compile-time checks). The one line of code you always should have at your disposal is: from IPython import embed; embed() Basically, if you have an error and can't figure out what's happening within a few seconds, stick that line in before the error and Python will give you a REPL to play around with. It's like GDB but way better.

colecut 6y ago

Out of curiosity, what language(s) are you working with?

quickthrower2 6y ago

Aka interactive window for c# devs using VS

dusted 6y ago

When I'm in the middle of my program and in need to change or implement some kind of algorithmic behavior, I often find that trying stuff out in a repl (node) help me understand and examine the problem much faster and in a more flexible way.

EastSmith 6y ago

That is my Aha moment too, but I have generalized to: Never start real work, until you can set a breakpoint in your IDE, where you can try things in the console. I know there are people that can write code for couple of days without running it (seen this with some java colleagues I've had), and then it all almost always works when run, but I am just not that kind of developer.