Hacker News new | ask | show | jobs
by breatheoften 2378 days ago
> The code must be written in a specific linear way to cater the format of notebooks.

This issue is super annoying. Notebook's _force_ you into that linear style -- which then packages up your code in a form that can't compose with anything ... Its not even a limitation of the notebook file format as if often thought -- its simply the case that notebook's work best when the majority of code in the notebook is in the same scope -- otherwise you can't interactively inspect intermediate variables ...

I was helping a friend of mine with some data science tasks and made a little library to restore some ability to compose a notebook written in that linear style into larger programs ...

https://github.com/breathe/NotebookScripter

Its relatively easy to take a notebook written normally, define a few parameters for it that can be configured externally, and turn that notebook into a callable function ...

I really think that the various notebook implementation's (jupyter, swift playgrounds) -- _need_ to add some sort of parameterization model to the notebook concept. Its not that hard to come up with a transformation that allows one to (1) work interactively in a notebook which has its parameters inferred from defaults (2) exposes a callable interface to that notebook that allows the caller to supply new values for parameters

A Notebook <-> function transformation is really all that is needed to create a real-programming model for Notebook's which would let one compose notebook's into larger programs while still writing the notebooks themselves in a way that's useful for data exploration ...

Going both ways Notebook <-> function and function <-> Notebook would be such a nice general purpose development feature... I'd love to take any function in a swift project and be able to interactively develop the function body in a 'playground like environment'. All that's required would be to supply values for the function's arguments -- and then there is no reason (aside from the limitations of the existing tools) why you couldn't compile the function into a form that supported a 'playground-like' experience for working on the function body.