5 ms·

Notebooks are not much better than copy-pasting from a notepad or editor into an interpreter. They’re great for reports, but dangerous for presenting the illusi

Notebooks are not much better than copy-pasting from a notepad or editor into an interpreter. They’re great for reports, but dangerous for presenting the illusion of reproducibility. At best you’re constantly restarting your kernel and clearing output. More likely, output from cell #7 has modified output [138] but you haven’t updated the chart produced in cell #17 (or some similar craziness). Not much better than programming with GOTOs. “But they’re great for reporting and visualization!” you might say. If you’re building any report of value, though, it will influence important decisions. That’s the reason your code shouldn't live in a notebook. It should be in a library, covered by unit tests, so that those decisions aren’t based on faulty logic.

minimaxir 9y ago
Notebooks (and this command-line ebook) assume that the input data is static (i.e. an ad-hoc analysis) which is a more typical use case. Dynamic data/reporting is a different thing entirely, at which point things like business intelligence software and dashboards come into play, and outside the scope of a command line anyways.
- IanCal 9y ago
  Notebooks however let you run code blocks in arbitrary orders, delete ones but keep their results in memory, change them without rerunning and change code with none of the downstream dependencies updating. It's possible (actually very easy) to have code which works as you're making it but not if you run it from scratch.
  - minimaxir 9y ago
    Which is why notebooks typically a) declare all imports/dependencies in the first block and b) the entire notebook is rerun from a fresh session before publishing (and notebooks have a keyboard command for doing that too). In all my years of work with Notebooks, I've never had an issue with downstream dependencies.
    - achompas 9y ago
      Important distinction: the notebooks themselves don't do this. The notebook authors, by convention, are supposed to do this. This is no different than engineers who are, by convention, supposed to write bug-free code. Even with this convention, however, devs still rely on testing to decrease the likelihood of bugs. No similar tooling exists for notebooks, which is why I recommend moving re-used logic into a tested codebase.
- achompas 9y ago
  I might have needed to edit down my comment, but you locked on to the least important part of my argument. If reproducibility is important, like you say, then a notebook is the last thing you want. Your code needs to be tested and designed like the software it is, instead of tossed into some notebook that does not fit into classic software practices.

minimaxir 9y ago

Notebooks (and this command-line ebook) assume that the input data is static (i.e. an ad-hoc analysis) which is a more typical use case. Dynamic data/reporting is a different thing entirely, at which point things like business intelligence software and dashboards come into play, and outside the scope of a command line anyways.

IanCal 9y ago
Notebooks however let you run code blocks in arbitrary orders, delete ones but keep their results in memory, change them without rerunning and change code with none of the downstream dependencies updating. It's possible (actually very easy) to have code which works as you're making it but not if you run it from scratch.
- minimaxir 9y ago
  Which is why notebooks typically a) declare all imports/dependencies in the first block and b) the entire notebook is rerun from a fresh session before publishing (and notebooks have a keyboard command for doing that too). In all my years of work with Notebooks, I've never had an issue with downstream dependencies.
  - achompas 9y ago
    Important distinction: the notebooks themselves don't do this. The notebook authors, by convention, are supposed to do this. This is no different than engineers who are, by convention, supposed to write bug-free code. Even with this convention, however, devs still rely on testing to decrease the likelihood of bugs. No similar tooling exists for notebooks, which is why I recommend moving re-used logic into a tested codebase.
achompas 9y ago
I might have needed to edit down my comment, but you locked on to the least important part of my argument. If reproducibility is important, like you say, then a notebook is the last thing you want. Your code needs to be tested and designed like the software it is, instead of tossed into some notebook that does not fit into classic software practices.