[throwaway5752]

This isn't data science. The output of a playbook is dependent on a huge amount of external dependencies and state, and the execution can conditionally depend on that. Maybe programmers should use notebooks more (and I have no opinion on that) but this isn't a situation where they would confer much benefit.

[1996]

I have more of an opinion there: Maybe programming should be more like data science. Prototypes are thrown away, but must exist at one point. They should be encouraged - like versionning, it is part of a core of good practices that admit few exceptions

External dependencies, state etc will all be handled, once excution is ironed out

[throwaway5752]

Sure, but that's not super different that series of commits along a feature branch. I think they accomplish the same goal. But am not dismissing notebooks as a way of doing that. I'm more familiar with ipython than jupyter, but particularly for more algorithmically complex programming tasks I think notebooks are a good tool.

I disagree with you only that this might be a good way of prototyping for something like ansible playbooks/modules, chef recipes, puppet manifests, etc. So much of the state is external (and intrinsic to what is being built) that I don't think it's a match of the rhythm of development there. But just my two cents, the best process is what works for you.

[1996]

I agree with you, ansible may not be the best showcase of the notebook (much is external) but I think it still remains practical for prototyping: I consider the notebook as a giant notepad, that shows you at the same time your code and the results of the code - in multiple versions, as many as tabs. Better than tabs, or terminals