
What Is a Computational Essay? (2017) - tosh
https://blog.stephenwolfram.com/2017/11/what-is-a-computational-essay/
======
TheAsprngHacker
See also literate programming, in which the source code is contained inside
some kind of prose and the entire file is a valid program:
[https://en.wikipedia.org/wiki/Literate_programming](https://en.wikipedia.org/wiki/Literate_programming)

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/](http://tomasp.net/coeffects/)

------
prepend
I love reading Wolfram essays and wish I could afford Mathematica.

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](https://en.wikipedia.org/wiki/Project_Jupyter)

~~~
AlotOfReading
Mathematica's notebooks were released with v1.0 in 1988 and are the earliest
notebook implementation I'm aware of. Jupyter isn't directly related except
that they were a spinoff of a project partially inspired by Mathematica,
IPython.

I've been running Wolfram in my Jupyter environment lately, which is a nice
setup to do quick analysis without the hell is Mathematica licensing.

~~~
prepend
I thought I read something about how notebooks were based on Mathematica, but
couldn’t find the article or source.

I think it’s fine that wolfram invented it, but it would be more impactful how
more common and certainly more approachable techniques could further the
computational essay.

~~~
delhanty
See this [0] historical retrospective of IPython (the forerunner of Jupyter)
in 2012 by its originator Fernando Pérez:

>Let's go back to the beginning: when I started IPython in late 2001, I was a
graduate student in physics at CU Boulder, and had used extensively first
Maple, then Mathematica, both of which have notebook environments. I also used
Pascal (earlier) then C/C++, but those two (plus IDL for numerics) were the
interactive environments that I knew well, and my experience with them shaped
my views on what a good system for everyday scientific computing should look
like. In particular, I was a heavy user of the Mathematica notebooks and liked
them a lot.

[0] [http://blog.fperez.org/2012/01/ipython-notebook-
historical.h...](http://blog.fperez.org/2012/01/ipython-notebook-
historical.html)

------
kragen
I like the overall idea, but Wolfram wants to own everything you do in
Mathematica (the "Wolfram Language" largely written by people he hired and
then renamed after himself), and he has a litigious history:
[http://bactra.org/reviews/wolfram/](http://bactra.org/reviews/wolfram/)

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...](http://nbviewer.jupyter.org/url/norvig.com/ipython/Advent%20of%20Code.ipynb)
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/](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/](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/](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.

~~~
TeMPOraL
I'd add that Mike Bostock teamed up with Tom MacWright and Jeremy Ashkenas to
create Observable (observablehq.com), which is kind of like Jupyter notebooks,
except as SaaS, in JavaScript, and both editable and executable in the
browser.

Observable documents are a bit less convenient to author than Jupyter
notebooks because you have to write in the browser, but they're much more
convenient to share around, and it's easier to make highly interactive
notebooks and "explorable explanations" with them.

~~~
kragen
I've been meaning to try Observable! However, I have the impression that, in
its current form, it exacerbates the archival problem enormously, because the
explorability of your explanation is conditional on the continued viability of
the Observable web site. I can reproduce and generalize the mathematical proof
in Plato's _Meno_ today, 2500 years later; I probably won't be able to
reproduce and generalize the computation in your Observable notebooks in 2029,
10 years later.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=15769054](https://news.ycombinator.com/item?id=15769054)

