[taeric]

You want to share the outputs so that you can share the results while showing your work. That jupyter also inlines everything, such that even charts are stored in the document, makes that even more necessary.

Though, I can see your point, I think. Why not include a build step that moves from your document to the generated output? My gut there is a large part of why the system got popular is that they worked hard on removing the friction that that would add.

As a comparison and to your point, I've seen people try to build "literate test suites" that were in a notebook, very happy with how the output looked. Only to find later that if they had used some of the more common test frameworks, those already create very nice reports. And moving the report format/creation out of the specification allowed a ton of flexibility.

[cauthon]

> You want to share the outputs so that you can share the results while showing your work.

What's wrong with rendering to HTML?

[abdullahkhalids]

You often share with people who want to play with the inputs or the code, while at the same time you want them to share what your choice of inputs outputted.

[cauthon]

right, so what's the issue with sharing a notebook (code) and rendered html (results)?

If someone starts playing with the inputs, they're going to lose the outputs you've created unless you have a saved rendered copy anyways

[taeric]

Depends what you mean by "whats wrong?" Conceptually, absolutely nothing. In practice, many of the folks we are talking about have been bitten by mismatched files already. Why add one more set of files to juggle?