There is a disconnect:
- Most non-trivial machine learning projects I've seen involve more than one person and have stakes.
- Most people do not work on non-trivial machine learning projects with stakes
The map becomes the territory: many people then develop "ML project lifecycle management" or improve the "notebook experience" with better stylesheets for that kind of experience. i.e: the experience of one person working on a toy project for a YouTube video or a Medium blog post on "production machine learning" from someone who's never done it before.
I'm not pissing on those who produce this kind of content; they're likely doing it for feedback. I'm selfish in that it is part of my job to stay up to date but the low signal to noise ratio gives the feeling of being rickrolled with every piece of content about machine learning.
It's used to build all of fastai's libraries, and with nbdev, the notebooks ARE the docs and tests.
I use pytest and standard IDE for most projects, but have used nbdev/jupyter on a few work projects and been astounded at the productivity boost.
Git issues with notebooks, producing pip modules, two way syncing between notebooks and code, if there is a problem that naked jupyter has for development, Jeremy Howard and team have solved it with nbdev.
Check it out.
For these reasons, formal tests rarely make sense in notebooks. If the code expands its use to being used repeatedly then clearly the notebook should be refactored into scripts and packages that have tests for the glue code and maybe some attempt at boundary the behavior of the numerical code.
Edit: is there anyway of doing this? I am happy to compile a whole browser with custom shortcuts, if it's not too much work.
https://orgmode.org/ https://github.com/nnicandro/emacs-jupyter
One minor critique: the vim stuff looks like a red herring given the topic. I'm personally not particularly interested in vim but am interested in jupyter notebook-alternative setups - I'd either remove it or explain why it's relevant here or contextualise it in some other way.
In the context as described it's not obvious why it's relevant (especially to a non-vim user).
Constructive feedback was being offered, is all.
