Page Comparison

Jupyter notebooks can encourage bad software development practices.

• Can discourage software written for modularity, reproducibility

• Without knowing the original notebook creators environment, you cannot reproduce their their results

• Linters (tools that check code for correctness) are difficult to use in jupyter’s disjointed cell interface.

It’s somewhat counterintuitive to object oriented programming and can discourage OOP practices.

• As part of that, it can discourage modularity.

• Classes cannot be defined across multiple cells

Most jupyter notebooks and their output are not easily reproducible due to hidden cell states.

• Each cell is in it’s current state due to the order it was run in the notebook. This is not always straightforward.

• Even if you don’t have cells that use randomization, if the original creator ran cells maintaining their states, then adjusted their order when running or skipping a cell in subsequent runs, the next person who runs it won’t be able to reproduce it running it from scratch.

• You may run a notebook always skipping a cell, while the next person to run it doesn’t skip that cell. In these situations, you’ll end up with different output.

• Cells executed in different orders give you different output. You can override the linear run of cells in jupyter.

• Being able to run snippets of code in arbitrary order can be unintuitive.

Jupyter version control can be an issue.

• There’s no easy way to determine whether a cell has been edited and when.