Chat Notebooks

One of the nice advantages of a notebook interface to LLMs is that you can easily go back and edit and rearrange the chat history in the normal ways that any cell in a notebook can be edited, moved, deleted, etc.

So e.g. if you want to go back to an earlier point, you can simply move your cursor between cells at an earlier position in the "physical" chat history, insert a new chat cell, and you're done.

[1]: https://writings.stephenwolfram.com/2023/06/introducing-chat...

[2]: https://github.com/WolframResearch/Chatbook#generate-immedia...

Jupyter notebooks were inspired by Mathematica notebooks: that's widely known and has been explicitly said in blog posts and elsewhere by the creators of Jupyter. It's no secret… And as the designer and developer of Mathematica notebooks I am flattered and honored that my ideas are now so widely used, even if it is in a product other than the one I wrote myself.

Time for a trip down memory lane. There were several notebook-adjacent products around at that time (1987) but none of them implemented notebooks as we know them today.

At the time I was using Xcode, which had a terminal-like interface that was a plain text document in which you could put all the shell commands you needed to build your app. This could include calls to the compiler, linker, or just any generic shell commands. To evaluate a given command (which could be one or more lines long) you had to manually select the exact range of text you wanted to run, which was kind of irritating. Any output would be placed directly below the input line. Because the document was pure plain text, it had no way of knowing what was input and what was output, or distinguish new output from old. So all the outputs accumulated, and you had to manually select and delete them periodically. It was an improvement over a glass teletype terminal interface, but I thought I could do better for Mathematica (code name Omega at the time).

The solution I came up with was to create a text document that was annotated with “zones” delimited by vertical bars along the right side of the screen (where cell brackets are now). Initially I used different black and white texture patterns on 4 or 5 pixel wide vertical bars. One texture for input and another texture for output.

This immediately gave two huge advantages: first, you didn’t have to manually select the range of a multi-line input. Just putting the cursor anywhere within an input zone and evaluating would evaluate the whole input. Second, because the system was keeping track of what was output, old output could be deleted automatically and replaced with new output.

Initially I called these things zones, but Steve Jobs suggested I use large close-square-bracket symbols instead of patterned bars, and think of them more like cells in a spreadsheet than like zones in a text document. Once you have brackets instead of bars, it’s immediately obvious that you could have larger brackets that encompass two or more cells. So I created cell groups, initially just to group input/output pairs, but of course it’s not a big leap to also have sections and subsections, then different cell types, styles, graphics cells, etc.

These key defining features of notebooks did not exist in any other system at the time, and to the best of my knowledge were not independently developed by other people. All the current notebook systems that share these broad features, definitely including Jupyter notebooks, derive from the original Mathematica notebooks I developed in 1987-8. (There are other styles of user interface, including some used by Maple and Matlab around the same time, that are called notebooks, but they did not share the key features I’ve described. They were and are fine products that I’m sure have both advantages and disadvantages compared to our Notebooks, but unlike our Notebooks, they are not the precursors of Jupyter.)

So can Stephen Wolfram personally claim to have invented notebooks? No, and he doesn’t: he claims that Wolfram Research did, which is true, since I was one of the co-founders of that company, and I invented that form of notebook.

Theodore

Why do I, who would have been the one to implement such a feature, not even remember whether it exists or not? Because if it does, it's horribly useless. It's just rarely what you actually want, and if you do want to do that, you can simply select the cell group, or command-A select the whole notebook, and use shift-return to evaluate everything. That's something I do regularly, but only when I need to, and it would be horrible if it tried to do that every time. I think it was Maple that tried such an interface. (Except their's was 2-dimensional: you could move equations/definitions around on the screen, and anything below or to the right would use definitions from above or to the left of it. This interface was one of the things that convinced me that this was a bad idea.)

The situation with GPTs is different: they do not have the equivalent of kernel state. It took me a while to believe it's actually true, but they have infinite amnesia: every time you send an API call, or submit a new prompt in their web interface, the model is starting completely from scratch with no state or memory whatsoever of anything that's happened before.

That fact that it looks like you're having an interactive conversation in which it knowns what you said before is an illusion created by the fact that the entire conversation all the way back to the start is re-submitted with every new prompt.

Given that reality, and the way people seem to want to interact with these things, the use of a physical context rather than a temporal one seemed most natural. We did talk about implementing our own temporal context mechanism to artificially make the LLM appear to have time-based internal state, like a kernel, but I personally hated the idea, and we never implemented it.

Now, it's possible that at some point these systems will in fact start having internal state (i.e. you have your own personal LLM running on a wad of gum stuck behind your ear, and as you interact with it it constantly fine tunes its weights, or something). At that point we might regret the decision, but I feel like this whole world is so unstable and rapidly evolving that it made sense for us to do what's right now, and worry about the future, if there is one, during that future.

Theodore

A surprise win was as much luck I had talking through an issue and getting correct, functional one-shot time grid and 3D plots including extra complications for the calculation of the axes.

A recent lose was trying to get it to generate a script that could optimize the gravity coefficient in the Reddit algorithm based on target timeframes and historic data. It offered salvageable output, if you pieced together several attempts and reframes, but never pulled it over the finish line.