What Is a Computational Essay? (2017)

It seems that the computational essay is a step higher than ordinary literate programming, as the code is executable in the format being used to present the document.

Reading this submission reminded me of this interactive article on coeffects, which fits the description of a computational essay: http://tomasp.net/coeffects/

This article is from 2017 and Jupyter [0] is from 2014. I wish the article had spent more time explaining its relationship to jupyter/python/R/etc notebooks. Even though Mathematica has lots of cool proprietary functionality, I think the main benefit of computational essays (what I call a notebook that’s designed for narrative) is not Mathematica but the sort of fact and computation based story.

I like reading articles that include the data and computation behind them. It makes it less likely that they are full of shit, I think.

[0] https://en.wikipedia.org/wiki/Project_Jupyter

As usual, in this blog post he claims credit for things invented by others; in this case, I think the people who deserve the most credit include Alan Kay, Dan Bricklin, Bob Frankston, Fernando Perez, Bret Victor, Mike Bostock, Nicky Case, and Amit Patel.

Kay has been touting the benefits of computational simulations as a medium of expression since the 1970s.

Bricklin and Frankston were the ones who made it an everyday reality in the form of the spreadsheet, also in the 1970s.

Fernando Perez wrote IPython, now known as Jupyter, which is the most practical tool for sharing such a mix of expository text with executable code; http://nbviewer.jupyter.org/url/norvig.com/ipython/Advent%20... is an example notebook. To give credit where credit is due, though, IPython definitely did not originate the "notebook" concept, and in fact didn't even support it at first; Wolfram might be right that Mathematica in 1988 is the origin of the UI paradigm. Jupyter is where it's at, though — you can use Sympy for symbolic computations, Numpy and Scipy for numerical computation (including stuff big enough you have to farm it out to a cluster), TensorFlow for artificial neural networks, and LaTeX for equations in your expository text, thanks to the amazing MathJax. You can use non-Python languages in Jupyter, either in particular cells — some of my notebooks have %%bash cells for things that are most easily done in bash — or for the whole notebook, R being a particularly appealing language for this. (SageMath also supports a notebook interface, I think, but I haven't tried it.)

Bret Victor's work in the 2000s has explored a lot of different ways to create and share such simulations; his talk "Inventing on Principle" is a mind-opening collection of demos on the subject.

Mike Bostock wrote d3, one of the best tools for building such "explorable explanations", and put together https://bl.ocks.org/ as a way of sharing them.

Nicky Case came up with the term "explorable explanations" and has written a lot of the best examples of the genre; https://explorabl.es/ is their site for this.

Amit Patel has also written a number of really excellent explorable explanations (using the term "interactive illustrations"), largely about writing games, at https://redblobgames.com/.

A really enormous problem with the whole field is reproducibility, dependencies, and archival; if you do an SVD in Numpy, for example, you're invoking the SVD code in LAPACK, so the results you get depend on the particular Fortran compiler you compiled Numpy with. Someone attempting to reproduce your results in 2030, 2050, or 2119 is likely to get different results. This is fine for presenting finished results, but it is a huge problem for extending them further. Kay, again, has done some of the key work in this area with his paper with Nguyen on archival virtual machines (a much better followup to Lorie's flawed UVC work; the bootstrappable crowd (mescc, stage0, and the like) are making major progress on making the bottom layer of the stack reproducible; and Nix and Guix are solving the problem of reproducible software configurations.