8 ms·

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was corre

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the same time. When one run finished, I would verify its behavior, look at the binary's hash, and then know that my code change was safe. It was a very slow process, but effective. After doing this kind of development for a while I'm weary of claims like this that imply that feedback with a latency <10s is actually a good thing. High latency feedback forces you to be more methodical in your development and think about the changes you're making.

darthdeus 10y ago
> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical and able to solve much complicated problems when they arise.
- userbinator 10y ago
  This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency feedback only encourages this behaviour more. The same phenomenon also happens if you give them a debugger --- they spend plenty of time just stepping through the code without any good sense of the bigger picture. Maybe it feels productive, but it's not. Their attention is too preoccupied with the feedback that they do not think deeply enough about their solution, and as a result, overall code quality often also suffers. Instead, I believe in thinking carefully about the problem. Close your eyes and visualise the program and its data and control flow in your mind, then write the code. Use a whiteboard or even pencil and paper to collect your thoughts and get a good mental model of what you're trying to accomplish. Block out all other distractions and focus on the problem. Many others I've talked to are in disbelief when I tell them I can spend an hour writing several hundred lines of code that compiles and works flawlessly the first time, but this is what careful thought will allow. Even with a very fast feedback loop you may spend several times longer fiddling with the code until you get something that seems to work, but actually doesn't in all cases precisely because you did not ever think about those cases while you were fiddling with it and had your attention focused on getting that next dose of feedback.
  - WhitneyLand 10y ago
    >>"I quite strongly discourage teaching programming by starting with IDEs..." >>"...also happens if you give them a debugger..." 1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations? 2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could be in the minority right? For these reasons I don't think there is enough data to make blanket recommendations against IDEs and debuggers.
    - RandomOpinion 10y ago
      Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?
      - Veedrac 10y ago
        WhitneyLand is probably not arguing against the claim you make in the large, but against the unsubstantiated argument that using IDEs and debuggers is more likely to lead you to that style of thinking than high latency variants. One could just as easily hypothesize that these tools let you avoid thinking in the small, and help you form a big picture overview that would otherwise be difficult to understand.
      - WhitneyLand 10y ago
        Those were not my words. I said to discourage all students from using IDEs and debuggers doesn't make sense. I went quite a while with no tools other than a hex editor to type in op codes. I don't think it did anything except hurt productivity. Maybe you learn or work better that way. I don't. And I don't see how you justify assuming all new programmers would.
        yarou 10y ago
        Discouraging someone to use an IDE is more a symptom of the target language's shortcomings. Xcode provided me with beautiful compile-time errors for both Objective-C and Swift, and forced me to really think about what I was doing. Incidentally, I learned both languages from the IDE. Would I recommend an IDE for a low level language like C? Probably not, because it forces a kind of laziness on the programmer. Maybe an IDE isn't the solution, but a starting point to build upon. Something that's an interactive environment like LightTable has, where you can quickly eval blocks of code and see the end result without having re-compile your entire program. Certain languages are better suited to this, and certain paradigms (reactive programming comes to mind).
- nine_k 10y ago
  One thing that helps is having short, self-contained, composable pieces of code that are easy to run in a repl or compile. This also helps testing and general understanding.
StavrosK 10y ago
> High latency feedback forces you to be more methodical in your development and think about the changes you're making. So does not having tests.
- castratikron 10y ago
  Right. If I would have worked on this again, the first thing I'd do is come up with some way of automatically testing the code.
  - StavrosK 10y ago
    Sure, but my point is that being forced to be more methodical isn't a good thing. Not needing to be methodical is better (because your tools will catch your mistakes for you).
    - lttlrck 10y ago
      Doesn't that also remove the need for discipline? So the last vestiges of 'engineering' that so many programmers aspire to vanish, they can blame their tools, and the only development challenges are found in the tools themselves (perhaps already true to some extent). This sounds depressing.
      - na85 10y ago
        > the only development challenges are found in the tools themselves (perhaps already true to some extent). Definitely true on the web side of things. Bootstrap+React+Angular+jQuery+whatever else, minify, deploy on docker, done.
      - comex 10y ago
        See it another way: you can spend the mental effort instead on solving harder and more interesting problems. That is, if you can find harder problems to solve...
    - flaviojuvenal 10y ago
erikschoster 10y ago
> High latency feedback forces you to be more methodical in your development and think about the changes you're making. There is also an attitude in computer music that low latency audio and realtime systems are simply part of the march of historical progress and ultimately represent a step forward from the days when composers could wait a week to hear 15 seconds of music rendered. I found that I like the think-write-render-listen-repeat loop that comes from a compiled music workflow. (I discovered this when writing a -- initially very slow -- nonrealtime python computer music system which in the early days would sometimes have me waiting a few hours to render a couple minutes of music.) Realtime computer systems enabled all sorts of new forms of live improvisation, interactive algorithmic systems, etc but sometimes it's very nice to have to sit in a quiet room with a text editor or notebook and think your way through the next long render.
fantispug 10y ago
Being methodical is good when your problem is intricate and well defined. Fast feedback won't be helpful in implementing a complex algorithm like a compiler or a numerical simulation (although I would argue it will help you debug it). When what you're doing is simple but error prone, or not well defined fast feedback can make you much more efficient. If you're using an underdocumented API/dataset, the best way to understand it is to probe it with code, quickly iterating. I used to write a lot of LaTeX and make lots of simple mistakes (missing backslashes typically). I found having an environment where I found my mistakes as soon as I made them more efficient than searching through the output for all mistakes, and then for each mistake finding the corresponding source and correcting them.
- Retric 10y ago
  The problem is fast feedback means you tend to create more bugs. It's faster in the short term, but very quickly produces unmaintainable code. In the end you can write code to be read (aka maintainable), to be run (aka fast), or to be written (aka cheap). PS: Sure, in theory it's simply better. However, people get lazy make some change and assume if it's passing their tests it works.
- btbuildem 10y ago
  > When what you're doing is simple but error prone That just means the problem is deeper than your understanding of it.
  - WalterSear 10y ago
    Or deeper than you >can< understand it without probing, because documentation is simplistic, wrong or non-existent.
    - darthdeus 10y ago
      In that case you have a much bigger problem :P
bonniemuffin 10y ago
I'm in a similar situation -- I write a lot of long-running hadoop jobs where I won't know the results for an hour or more. I try to "think twice, run once". When I'm debugging, I'll kick off several variants to test different ideas, and write myself notes on what I expect to learn from each one when it finishes. Then I can go off and work on something else until it's done, and use the notes to get myself back into the debugging groove. Without the notes, I'd find myself an hour later struggling to remember why I even ran a particular variant.

darthdeus 10y ago

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical and able to solve much complicated problems when they arise.

userbinator 10y ago
This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency feedback only encourages this behaviour more. The same phenomenon also happens if you give them a debugger --- they spend plenty of time just stepping through the code without any good sense of the bigger picture. Maybe it feels productive, but it's not. Their attention is too preoccupied with the feedback that they do not think deeply enough about their solution, and as a result, overall code quality often also suffers. Instead, I believe in thinking carefully about the problem. Close your eyes and visualise the program and its data and control flow in your mind, then write the code. Use a whiteboard or even pencil and paper to collect your thoughts and get a good mental model of what you're trying to accomplish. Block out all other distractions and focus on the problem. Many others I've talked to are in disbelief when I tell them I can spend an hour writing several hundred lines of code that compiles and works flawlessly the first time, but this is what careful thought will allow. Even with a very fast feedback loop you may spend several times longer fiddling with the code until you get something that seems to work, but actually doesn't in all cases precisely because you did not ever think about those cases while you were fiddling with it and had your attention focused on getting that next dose of feedback.
- WhitneyLand 10y ago
  >>"I quite strongly discourage teaching programming by starting with IDEs..." >>"...also happens if you give them a debugger..." 1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations? 2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could be in the minority right? For these reasons I don't think there is enough data to make blanket recommendations against IDEs and debuggers.
  - RandomOpinion 10y ago
    Are you genuinely attempting to argue that thinking ahead and fully understanding the problem isn't preferable to tweaking one's way to a solution?
    - Veedrac 10y ago
      WhitneyLand is probably not arguing against the claim you make in the large, but against the unsubstantiated argument that using IDEs and debuggers is more likely to lead you to that style of thinking than high latency variants. One could just as easily hypothesize that these tools let you avoid thinking in the small, and help you form a big picture overview that would otherwise be difficult to understand.
    - WhitneyLand 10y ago
      Those were not my words. I said to discourage all students from using IDEs and debuggers doesn't make sense. I went quite a while with no tools other than a hex editor to type in op codes. I don't think it did anything except hurt productivity. Maybe you learn or work better that way. I don't. And I don't see how you justify assuming all new programmers would.
      - yarou 10y ago
        Discouraging someone to use an IDE is more a symptom of the target language's shortcomings. Xcode provided me with beautiful compile-time errors for both Objective-C and Swift, and forced me to really think about what I was doing. Incidentally, I learned both languages from the IDE. Would I recommend an IDE for a low level language like C? Probably not, because it forces a kind of laziness on the programmer. Maybe an IDE isn't the solution, but a starting point to build upon. Something that's an interactive environment like LightTable has, where you can quickly eval blocks of code and see the end result without having re-compile your entire program. Certain languages are better suited to this, and certain paradigms (reactive programming comes to mind).
nine_k 10y ago
One thing that helps is having short, self-contained, composable pieces of code that are easy to run in a repl or compile. This also helps testing and general understanding.

StavrosK 10y ago

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. So does not having tests.

castratikron 10y ago
Right. If I would have worked on this again, the first thing I'd do is come up with some way of automatically testing the code.
- StavrosK 10y ago
  Sure, but my point is that being forced to be more methodical isn't a good thing. Not needing to be methodical is better (because your tools will catch your mistakes for you).
  - lttlrck 10y ago
    Doesn't that also remove the need for discipline? So the last vestiges of 'engineering' that so many programmers aspire to vanish, they can blame their tools, and the only development challenges are found in the tools themselves (perhaps already true to some extent). This sounds depressing.
    - na85 10y ago
      > the only development challenges are found in the tools themselves (perhaps already true to some extent). Definitely true on the web side of things. Bootstrap+React+Angular+jQuery+whatever else, minify, deploy on docker, done.
    - comex 10y ago
      See it another way: you can spend the mental effort instead on solving harder and more interesting problems. That is, if you can find harder problems to solve...
  - flaviojuvenal 10y ago

erikschoster 10y ago

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. There is also an attitude in computer music that low latency audio and realtime systems are simply part of the march of historical progress and ultimately represent a step forward from the days when composers could wait a week to hear 15 seconds of music rendered. I found that I like the think-write-render-listen-repeat loop that comes from a compiled music workflow. (I discovered this when writing a -- initially very slow -- nonrealtime python computer music system which in the early days would sometimes have me waiting a few hours to render a couple minutes of music.) Realtime computer systems enabled all sorts of new forms of live improvisation, interactive algorithmic systems, etc but sometimes it's very nice to have to sit in a quiet room with a text editor or notebook and think your way through the next long render.

fantispug 10y ago

Being methodical is good when your problem is intricate and well defined. Fast feedback won't be helpful in implementing a complex algorithm like a compiler or a numerical simulation (although I would argue it will help you debug it). When what you're doing is simple but error prone, or not well defined fast feedback can make you much more efficient. If you're using an underdocumented API/dataset, the best way to understand it is to probe it with code, quickly iterating. I used to write a lot of LaTeX and make lots of simple mistakes (missing backslashes typically). I found having an environment where I found my mistakes as soon as I made them more efficient than searching through the output for all mistakes, and then for each mistake finding the corresponding source and correcting them.

Retric 10y ago
The problem is fast feedback means you tend to create more bugs. It's faster in the short term, but very quickly produces unmaintainable code. In the end you can write code to be read (aka maintainable), to be run (aka fast), or to be written (aka cheap). PS: Sure, in theory it's simply better. However, people get lazy make some change and assume if it's passing their tests it works.
btbuildem 10y ago
> When what you're doing is simple but error prone That just means the problem is deeper than your understanding of it.
- WalterSear 10y ago
  Or deeper than you >can< understand it without probing, because documentation is simplistic, wrong or non-existent.
  - darthdeus 10y ago
    In that case you have a much bigger problem :P

bonniemuffin 10y ago

I'm in a similar situation -- I write a lot of long-running hadoop jobs where I won't know the results for an hour or more. I try to "think twice, run once". When I'm debugging, I'll kick off several variants to test different ideas, and write myself notes on what I expect to learn from each one when it finishes. Then I can go off and work on something else until it's done, and use the notes to get myself back into the debugging groove. Without the notes, I'd find myself an hour later struggling to remember why I even ran a particular variant.