36 ms·

It seems to me like this is just a debate over what words mean. Essentially when you say the phrase “treat notebooks like first-class citizens” you’re baking i

by mlthoughts2018 8y ago

It seems to me like this is just a debate over what words mean. Essentially when you say the phrase “treat notebooks like first-class citizens” you’re baking in all kinds of statements about the design-level thinking that should be used for good craftsmanship when coding in the notebook. This still won’t address the intrinsic mixing of concerns (especially units of display), but overall it roughly means that “treating notebooks as first class citizens” translates to “treat the notebook like a thin execution environment / IDE, but develop code in exactly the way you would in more standard settings.” To me this falls flat because that’s not why people want to use a notebook. Generally they want to use it because it’s superficially easier to jumble all concerns into a single context and not think about coupling or separation, and just disregard testing and other best practices. The notebook is optimized for this way of working, and I’m trying to call into question the underlying claim that it’s ever worthwhile to write code that way if there’s even slightest need for re-use or reproducibility. Separately, a huge bunch of this sort of notebook usage specifically is for expressly presenting the notebook, almost like interactive slides, to other people (in which case the goals are completely antithetical to good software practices, implying implementation units should be factored out if the priority is presentation). Basically I’m saying you’re sweeping a bunch of stuff under the rug by lumping testing, linting, tooling, and software craftsmanship all under the term “first-class citizen.” The other reality is that notebooks aren’t first-class units, at least in Python. You can’t import a notebook like a module, unless you do a lossy export to a .py file (in which case, why weren’t you just writing the .py file to begin with and only putting units of display in the notebook that imports the .py file?) — not to mention that you’d need custom tooling instead of mature tooling to apply linting, testing, packaging, etc., like we discussed above.

joshuamorton 8y ago
>To me this falls flat because that’s not why people want to use a notebook. Generally they want to use it because it’s superficially easier to jumble all concerns into a single context and not think about coupling or separation, and just disregard testing and other best practices. But this is not unique to notebooks. You can very easily do the exact same things with raw python files, its just that in the ecosystem you work in, raw text files are treated more maturely. I find notebooks very useful as a form of main method. You don't generally go importing your main methods anyway. You shouldn't go developing all your code in notebooks, much as you shouldn't go developing all of your code in main methods that don't have classes. Shared infrastructure should be factored out no matter what. Your complaints appear to come down to "people can apply bad software development practices in notebooks, therefore notebooks shouldn't be used". And my point is that no, you can just not apply the bad software practices, and that solves the problem too.
- mlthoughts2018 8y ago
  > "You can very easily do the exact same things with raw python files, its just that in the ecosystem you work in, raw text files are treated more maturely." This is non-sequitur to the whole discussion. You can write bad code in any tool. That has no bearing on this. Instead we should ask, "what does it require to write good code in a given tool." In plain source files, we know the answer, with lots of theory of design, decoupling, architectural rules, refactoring etc. As well as mature tools for code review, viewing diffs easily, automated testing. In notebooks, the answer is that you have to jump through a lot of hoops to write things in a non-notebook-way -- that is, specifically in a way where you factor things out into the text files anyway -- if you want those good patterns. For example, you mention: > "I find notebooks very useful as a form of main method. You don't generally go importing your main methods anyway." I totally agree. Viewed this way, the notebook-based "main" method is just a driver of other code. Meaning, you don't do much work in the notebook at all. You factor things out into other modules, etc., and then put as little as is needed to drive the code into the notebook. Which is what I have been saying all along. It reveals the notebook to be an anti-pattern (because that driver code doesn't need or benefit from any aspects of the notebook environment that are expressly designed to act like a messy linear script of ad hoc implementation units mixed with ad hoc display units). I would say your suggested way of using notebooks is exactly an example of what reveals that notebooks aren't very good for the intended use cases (like people defining global variables for experiment parameters at the top, and then "running an experiment" becomes changing those values and re-running the cells of the notebook). This is among the most commonly advertised and praised ways of using a notebook, so it's not like some extremely rare situation that only arises in a place with bad software practices. It's practically the intended use of notebooks. That's why I'm saying they are self-defeating. Once you take an approach where you factor things out and leave the notebook to be just a simplistic driver script, it's immediately clear that driver scripts can just be scripts, not notebooks, and don't benefit from all the intended ad-hoc-ery that is a first-class, intended workflow of the notebook design.
  - joshuamorton 8y ago
    >In notebooks, the answer is that you have to jump through a lot of hoops to write things in a non-notebook-way -- that is, specifically in a way where you factor things out into the text files anyway -- if you want those good patterns. I guess I still consider this a "notebook-y" way. Its just good practice, instead of bad practice. But still notebooky. You seem to be using notbooky to mean sloppy and disorganized, whereas I mean it as interactive and literate. Those need not be correlated, and I think that "driver scripts" still benefit a lot from the interativity and literateness

joshuamorton 8y ago

>To me this falls flat because that’s not why people want to use a notebook. Generally they want to use it because it’s superficially easier to jumble all concerns into a single context and not think about coupling or separation, and just disregard testing and other best practices. But this is not unique to notebooks. You can very easily do the exact same things with raw python files, its just that in the ecosystem you work in, raw text files are treated more maturely. I find notebooks very useful as a form of main method. You don't generally go importing your main methods anyway. You shouldn't go developing all your code in notebooks, much as you shouldn't go developing all of your code in main methods that don't have classes. Shared infrastructure should be factored out no matter what. Your complaints appear to come down to "people can apply bad software development practices in notebooks, therefore notebooks shouldn't be used". And my point is that no, you can just not apply the bad software practices, and that solves the problem too.

mlthoughts2018 8y ago
> "You can very easily do the exact same things with raw python files, its just that in the ecosystem you work in, raw text files are treated more maturely." This is non-sequitur to the whole discussion. You can write bad code in any tool. That has no bearing on this. Instead we should ask, "what does it require to write good code in a given tool." In plain source files, we know the answer, with lots of theory of design, decoupling, architectural rules, refactoring etc. As well as mature tools for code review, viewing diffs easily, automated testing. In notebooks, the answer is that you have to jump through a lot of hoops to write things in a non-notebook-way -- that is, specifically in a way where you factor things out into the text files anyway -- if you want those good patterns. For example, you mention: > "I find notebooks very useful as a form of main method. You don't generally go importing your main methods anyway." I totally agree. Viewed this way, the notebook-based "main" method is just a driver of other code. Meaning, you don't do much work in the notebook at all. You factor things out into other modules, etc., and then put as little as is needed to drive the code into the notebook. Which is what I have been saying all along. It reveals the notebook to be an anti-pattern (because that driver code doesn't need or benefit from any aspects of the notebook environment that are expressly designed to act like a messy linear script of ad hoc implementation units mixed with ad hoc display units). I would say your suggested way of using notebooks is exactly an example of what reveals that notebooks aren't very good for the intended use cases (like people defining global variables for experiment parameters at the top, and then "running an experiment" becomes changing those values and re-running the cells of the notebook). This is among the most commonly advertised and praised ways of using a notebook, so it's not like some extremely rare situation that only arises in a place with bad software practices. It's practically the intended use of notebooks. That's why I'm saying they are self-defeating. Once you take an approach where you factor things out and leave the notebook to be just a simplistic driver script, it's immediately clear that driver scripts can just be scripts, not notebooks, and don't benefit from all the intended ad-hoc-ery that is a first-class, intended workflow of the notebook design.
- joshuamorton 8y ago
  >In notebooks, the answer is that you have to jump through a lot of hoops to write things in a non-notebook-way -- that is, specifically in a way where you factor things out into the text files anyway -- if you want those good patterns. I guess I still consider this a "notebook-y" way. Its just good practice, instead of bad practice. But still notebooky. You seem to be using notbooky to mean sloppy and disorganized, whereas I mean it as interactive and literate. Those need not be correlated, and I think that "driver scripts" still benefit a lot from the interativity and literateness