 Okay. Welcome to the next session after dinner or whatever your time zone had. Our next speaker is William Horton. He will talk about Jupyter Notebooks, even better, a brief history of Jupyter Notebooks. Please go on. Great. Thank you for the introduction. My name is William Horton. This is a brief history of Jupyter Notebooks. I'm excited to be speaking at Europe Python. This is my first virtual conference and you might be able to tell from the background here that I'm not in Europe. I'm in New York wearing my Cli Gotham t-shirt to represent our community here, but I'm excited to have the chance to present to you all today. So the first question you might have is why this talk? What is so interesting about Jupyter Notebooks and particularly the history of Jupyter Notebooks? Where this talk comes from is really my observation that there's increasingly two different worlds of Python. There's a world in which Python looks like this and there's another world in which Python looks like this. For those of you who are maybe more familiar with the first world than the second, I'll give a little bit of background on what a Jupyter Notebook is, what it can do. The code goes into these things called cells and those cells are able to be executed with Python code. The other interesting thing you can do with cells is you can put in markdown. So it actually is able to format text using markdown and display that in the notebook as well. So that's just a little bit about the Jupyter Notebook. This isn't really an explanation of how it works, but I just wanted to make sure we were all on the same page in terms of what we're actually talking about when I say Jupyter Notebooks. And for those of you who are familiar with Jupyter Notebooks, you can see that I kept to the standard naming convention for Jupyter Notebooks untitled one, if I had another one untitled two, untitled three, and so on. And another inspiration for this talk was my own personal journey. When I first started learning Python, it was mostly in the context of web applications, maybe some data processing. And so all the Python I wrote was, you know, edited in an IDE. It was in .py files. It looked like that kind of Python. But then a couple years back, I got very interested in machine learning through the FAS AI courses, which makes sense of uses of notebooks. So for a while, I was in this scenario where everything I was doing professionally was in .py files, and I was spending a lot of my time learning these other things exclusively through notebooks. And so that kind of led me to observe this split. Now, my current role, I work on machine learning. So I find myself kind of working on a mix of things, still working with Python files for applications and service code, but then increasingly having to read other people's notebooks from data scientists and understand those, as well as write some of my own notebooks for data analysis, feature exploration. So even in my experience as just one developer, I've increasingly seen this kind of confluence of different ways that people write Python. And if you're familiar at all with this ecosystem, you might know that there have been some tensions between these two worlds. Kind of a major example is Joel Groose went to JupiterCon, the conference for Jupiter, and gave this whole talk called, I don't like notebooks, and kind of laid out the reasons why he does not like this interface. And that spawned a lot of back and forths that this one talk called the first notebook war. A lot of tweets and blog posts were written about loving Jupyter notebooks or hating Jupyter notebooks. And there's a lot of material out there on that topic. But I was kind of thinking, is there some other way that we can approach this instead of lobbing yet another volley in this notebook war? Is there a different way of looking at things? And when I came across this tweet by Jeremy Howard, the founder of FastAI, it kind of inspired me to start thinking about things in this way. And he wrote, I do think Mathematica doesn't get the credit it deserves for pioneering notebooks. And this was in response to a hacker news comment about the development of notebooks through not only Mathematica, but Sage, and some of these other tools that I'm going to talk about in my talk. And so this kind of got me thinking, what if instead of fighting about why we love or hate Jupyter notebooks, we seek to understand the history, both for people who are using notebooks already, maybe get an interesting look in how the tool came to be for those people who don't use them, maybe get some empathy for users of the tool and understand that Jupyter notebooks are not something that data scientists invented a couple of years ago just to annoy engineers. There really is a rich history to this. And I hope to show you some of that in the presentation. It didn't come out of nowhere. The Jupyter notebook, and in fact, I go far as to say, no significant piece of software comes out of nowhere. Every program that gets developed really brings together different threads and ideas that have been circulating, not only for years, maybe even for decades, as we'll see. And I think this is a really important point to understand, not just about Jupyter notebooks, but about all the tools that we use. And so in the particular case of Jupyter notebooks, you can identify, I think, several long term trends, there's others you could point out, but these are the ones that I've organized the talk around. One, the most obvious maybe is scientific computing. So this is where these tools come from the desire to use computing and programming for scientific endeavors. Another trend or kind of thread is literate programming. And we'll talk a little bit more about that idea. Another major factor that played into Jupyter notebooks was proprietary versus open source. And finally, since this is zero Python, obviously, we'll talk about Python and where that comes in. This talk is organized in three parts, past, present, and future. Since it is a brief history, I'll spend most of the time talking about the past. But I do want to take some time to consider what that means to the present, the last few years, and also what it might mean looking into the future of what Jupyter notebooks could be. So to start off with the past, and I start with an apology to any former science PhD. I know a lot of you got into Python, specifically to avoid some of these tools that I'm going to be talking about today. But be warned that I'm going to be talking about some of these things that you might have thought were in your past. So the story of the notebook in some ways starts with this man, who you might know as the guy who helped you with your high school algebra homework through the Wolfram Alpha interface. But before Wolfram Alpha, he created this tool called Mathematica in 1988. Stephen Wolfram created it. And it really was an all-in-one system for Imperial Algebra and other kinds of scientific computing. It included a language which he modestly named Wolfram, a whole execution environment as well as many useful libraries. And another important point, and what brings Mathematica into the presentation today, is it contained a notebook interface designed for Theodore Gray, and it was really one of the first popular tools to embed this kind of notebook interface. And at the time, Mathematica was very well received. And this magazine, Bite Magazine included it in an annual set of awards. And you can see that it says Mathematica was very useful for students and for doing these kinds of mathematical operations. The interesting thing is this magazine is archived. So we can see what other things won these awards at the same time and understand a little bit about the computing environment that Mathematica came out in. So you can see next computer. So Steve Jobs kind of comeback project won an award at this time. Some of you might recognize this. Some of you might not. This is HP Deskjet printer, state of the art of the time, and it could be yours for the low price of $995. That's $995 at the time. And an advertisement for Advanced MS-DOS Programming second edition. So if you wanted to brush up on your MS-DOS skills, this was also in that magazine. So that sets the stage a little bit about what kind of was going on at the time that Mathematica came out. And we can understand also a little bit about the technical implementation of it. There were two parts of the system. And this becomes a very key part of the history of notebooks. There was a kernel and a front end. And so the front end was designed to accept the user's input, which could be Mathematica commands and other things and send it to the kernel. The kernel was responsible for doing all the computation and then returning output to be displayed in the front end. Another interesting thing, Mathematica notebooks were objects that themselves could be manipulated by Mathematica programs. And you'll see that kind of going forward that the actual representation of the notebook document becomes also important in addition to the kind of kernel and front end setup. So we can actually look at some archived photos of what this notebook interface looked like. So here's one example. I'm not a mathematician, but it seems to be doing some kind of series expansion. And you can see some things that if you're a regular user of Jupyter might seem familiar to you. So you have this in-out organization. You enter the command and it outputs the computational results. Another really cool thing that you can see, and I remind you this was like late 80s, early 90s, is the ability to do these 3D plots in the Mathematica notebook. And so this is a really powerful feature and something that drives notebook adoption, I think, across many decades. But the story of the notebook interface doesn't really start with Mathematica and Stephen Wolfram. To really understand the root of it, we have to go even further back. Further back to a man, you might know as the author of a book that every engineer claims to have read, but nobody has actually finished the art of computer programming. So this is Donald Knuth. And he not only wrote the art of computer programming, he came up with this idea of literate programming. And literate programming implemented a system he called web, which I think turned out to be unfortunate naming on his part. But the web system embedded these concepts of tangled and woven. And those are in fact the two main commands that made up the system. And so the idea was you would create this source text, and the source text contained both code, as well as just normal text and documentation. And the tangled part would take that whole text and generate just compilable code from the source. The weave part would take that whole thing and generate a formatted documentation from that exact same source, total kind of source text that you had. And so these were kind of two of the main functionalities that made up the web system, the way that he implemented his idea of literate programming. And this wasn't just say an abstract exercise or a theory on his part. He actually used liter programming and web to implement tech, which is a very popular type setting system that is still used today. So this is an early example of how some of these ideas of literate programming can be applied to build complex systems. So returning to kind of our history of scientific computing tools, the next major one to look at after Mathematica in terms of the notebook interface was Maple. Maple, similar to Mathematica, embedded these scientific computing libraries in its own language. And the first GUI came out in 1989, and then a few years later in 92, it came out with the worksheet interface, which is the same kind of interface as a notebook allowing you to combine text and code and graphics. So we can look at a couple of screenshots to see what did Maple look like? And you can see a familiar pattern, input, computation of code, as well as the ability to do these more complex mathematical operations like factorizations. And again, you can see a very cool example where it can actually do a 3D plot. And in this case, even a 3D plot with color graphics. And so you can see that from the kind of start, the ability to do these kinds of plots was a very important component of these notebook interfaces. So Maple versus Mathematica was was an important question. And these tools were kind of competing in the early 90s. Now, what I'm about to present came from a Maple published document on things that it thought were clear advantages. But I think it actually provides an interesting kind of pro and con for the ways you could define these systems. So the first thing is the use of math notation. So you look on the left, and you can see that Maple used a much more familiar to mathematicians syntax. But the funny thing is to me as kind of a more of a programmer, the Mathematica syntax looks much preferable. It has the familiar double equals, the function calls look more recognizable as function calls. And so this is one thing that kind of starts to be some kind of tension in is who are these tools for? Do we represent it in a more mathematical way? Do we adopt a more kind of coding or programmer style? Another interesting thing Maple could do is actually reevaluate code that you embedded in the text. And so this case, you have a function, it computes something off of that function. In this case, the discontinuity, if you actually update the function, it can basically recompute that and come up with a new result that gets embedded in your text. And finally, I think this is just an interesting historical point. When Maple came out, they thought that Mathematica's use of shift enter was just totally wrong and the user should always just be able to hit enter in order to execute a cell. And those of you who used your notebooks know that in this case, historically Maple ended up losing and the shift enter pattern was adopted by later interfaces. So Maple and Mathematica were both very powerful tools, but there was one big problem and that was cost. These were both proprietary tools and they had expensive licenses sometimes paid for by institutions. And you can see that these are still available and those are the costs for personal licenses. So this is where the notebook interface coincides with another major trend in software history, the rise of open source. And particularly in this case, we'll look at a couple of important scientific computing libraries that came out around the early 2000s. And so this includes SciPy, which were open source scientific libraries, as well as iPython, which basically provided improved Python terminal experience compared to the normal Python command, as well as additional functionality for distributed computing. So this is one example of iPython, still very widely used today. I almost always default to iPython compared to regular Python. It gives you some nice functionality. And so this ends up being a very important tool in the story we're telling of Jupiter notebooks. The last library that kind of is part of this group is Matplotlib. And there was a very funny anecdote I found while researching this talk, where basically Matplotlib was originally conceived as a patch for iPython. But Fernanda Perez, the creator of iPython, didn't have time to review the patch. And so the creator Matplotlib created it as a separate library, and that's still very widely used to this day. So I mentioned Fernanda Perez and in the story of Jupiter notebooks, his name is probably the most important to remember. He created iPython in 2001 as a grad student. He's currently an associate professor at Berkeley as well as a founder of the Berkeley Institute for Data Science. And he's received many awards for his work on these open source scientific tools. And so he plays a large role in this kind of later history of notebooks, as we'll see. And this is a very interesting thing. He actually has put up a gist of the initial commit to iPython. And it's very interesting because in kind of tracing these histories, sometimes we have to rely on inference or saying this kind of interface resembles this interface. But you can see from one of the comments, he actually says the prompts, the in and out prompts for iPython are similar to Mathematica. So he's kind of mentioning that influence. And I'll also say thank you to Pablo Andreschenko. He actually posted this in the channel for the talk today. And I thought it was so cool that I wanted to make a slide out of it. So the next kind of step toward the Jupiter notebook in this history is a tool called SageMath or Sage. And this really brought together a lot of these threads that were kind of converging, which is the need or want to do scientific computing as well as the use of these open source packages and wanting to do that in a nice web interface. And so basically Sage said we're going to provide an open source tool that will embed a lot of these scientific packages. It's written in Python. It's released with an open source license. And you can see even that they're saying this is supposed to be an open source alternative to some of these other tools that we've talked about Maple and Mathematica. And this gives you a little bit of a look at what the Sage notebook looked like. This is from around 2012. And one cool thing I wanted to point out is the Sage notebook actually embedded rich text editing, which is something I found out when working on this talk that I think is so cool and not something that I've seen in a Jupiter notebook. So if that functionality doesn't already exist, maybe there is an opportunity for an open source contribution. I'll also say Sage further cemented this shift enter pattern as the winner in notebook user experience. So you have Sage to thank for continuing shift enter, shift enter. Finally, we get to the ipython notebook. So this was an interface that was initially embedded in the ipython library. You could start it up by running ipython notebook and basically it contained two main components. There is the web application, which actually allowed you to interact and run your code and embed visualizations as well as the document itself, the notebook and the representation of it. And eventually ipython notebook gets spun out into Project Jupiter in 2014. And another cool thing I learned when I was working on this talk is where the name Jupiter came from. It actually comes from the three languages that were supported originally. So Julia, Python and R. And like I mentioned, Project Jupiter was spun off of ipython by Fernando Perez. It included the notebook interface as well as other language agnostic parts of ipython. So coming to Project Jupiter, this brings us to the present. And I wanted to talk about a few key trends that I see driving adoption usage of the Jupiter notebook today. And these trends are data science and machine learning, sharing an interaction and growing ecosystem around notebook tools. So this one, again, might be one you're familiar with. You might even be here because you work on data science and machine learning. And I think one kind of thing that highlights how this is driven adoption and usage of the notebook is a tool called Google Colab. Basically, it is a notebook in the cloud that you can open up. You can use it with Google Drive. And a key point is you can actually use it to access free GPU and TPU computation. So this has become a very popular tool for machine learning researchers. And I think that's part of a broader trend of posted solutions or notebook as an interface to specialize computation. So the Colab lets you connect to GPUs and TPUs. AWS has a similar offering Sage Maker and notebooks are also very popular part of Sage Maker. The competition platform Caggle lets you also spin up notebooks and run computations on their platform. And so this is kind of a logical conclusion of this separation of the front end and the kernel, where now the front end can just be on my laptop and the kernel can actually be executing, say in one of Google's data centers on a specialized advice. So I think this is a really cool use of notebooks and one that's seeing increased adoption. And even in things that I work on, we use Kubeflow as a platform for machine learning in Kubernetes. And it contains a bunch of functionality for machine learning like things like machine learning pipelines and hyper parameter tuning and distributed execution, all sorts of things, model serving. But the one functionality that actually drives the most use of Kubeflow is a hosted notebook server. So it's a really key part of these machine learning use cases today. Another key area, I think, that is driving a lot of tools today is sharing an interaction. A really important one in that area is Binder. And this is a super cool tool. Basically, it allows you to take a Git repo. It bundles the dependencies of your repo into a Docker container and then spins up a version of your notebook that someone else can run from their own browser. And so this goes from notebooks being something that I couldn't execute on my machine. Maybe I can share the document with you. But now this is kind of another step further. It makes it really easy to say, I can give you my notebook and allow you to run it. Another kind of tool in that area is Voila. And this is saying I want to take my notebook and turn it into a web application just from the notebook itself with interactive components. And so this is another really cool tool. And finally, Ipi widgets. So I was at the SciPy conference recently. There was a whole tutorial on these Ipi widgets. They're interactive HTML widgets for Jupyter notebooks. And it makes it really easy to share with people. And again, like, bring external interactivity to your notebook. It's not just something that you can code interactively. It's something that once you're done, other people can also interact with. And finally, a growing ecosystem. And so, like I mentioned, it started out supporting Julia, Python and R. And eventually you see it growing to an increasing number of languages. So JavaScript, PHP, Java, Swift, I think, can even be running notebooks now. Even some of these tools that we talked about before. So SageMap can now be executed in a Jupyter notebook, as well as even the Wolfram language. So finally, the last section, I want to consider some points about the future of the Jupyter notebook. So where it may be going. And the major trends here, I think, are around developer experience, real-time collaboration and productionizing. I think these are all open questions that are going to be solved in the next coming years. So right now, we have JupyterLab. And this was released as an alternate UI to the regular notebook that provides more IDE-like features. And I think moving forward, we'll see even more IDE-like features in JupyterLab, as well as more support for Jupyter in IDE. So VS Code shipped native support for Jupyter notebooks, for example. So it might not have to be a question of, do you edit your notebook in something like JupyterLab or your IDE? I think there's going to be increased convergence of these experiences. Next is kind of around the experience of using Git and GitHub. So you can render notebooks in GitHub. It's a lot better than what you had to do before and work on the raw version. And moving forward, there's some very useful tools. So this is one called ReviewNB. They can actually show you a visual diff of the notebook. But this is not very widely adopted now. And I think there's a lot more work to be done around this experience. GitHub is actually working on some of these things. So GitHub Code Spaces now lets you edit Jupyter notebooks on GitHub. And there's also support for dropping links to Binder in your PR. So you can actually send some on an interactive version of the notebook. Another trend I think is being worked on is real-time collaboration. So not just can I share my notebook, not just can I make it interactive, but can we actually work on it together at the same time? There's a couple companies working on this. Deep Note is one to look up. And then Co-Calc, which is actually started by the creator of Sage. So he is working on making notebooks, real-time collaboration. Finally, productionizing. A really open question, even in terms of what does it mean to put Jupyter notebooks in production? So I wanted to share two use cases that I think are kind of illustrative of different approaches. One is Netflix. They've gone all in on notebooks. You can read this blog, notebook innovation and Netflix. They're doing things like notebook templating parameterized notebooks. So you can actually run a notebook as a script. And finally, scheduling notebooks as workflows. So they're not saying I'm going to take the parts of this notebook, turn it into a workflow I can run. I'm just gonna, I'm just gonna, I'm just gonna schedule my notebook. And you should look up open source tools like Interact and Papermill. And finally, FAFSAI. So they wrote their whole v2 library in notebooks with a tool they developed called NB Dev and they mentioned Donald Knuth's ideas of literal programming. So to conclude, I think there's two main points I'd like you to take away from the talk. First, the history of Jupyter notebooks is not linear. It's easier to present it in 30 minutes like this. This is not the real story of the notebook interface. The story is very twisted. It involves many timelines. I'm not a great artist, but this show is kind of the interaction of different ideas from all these interfaces. And second, the history of Jupyter notebooks is not over. I presented kind of like this, where Jupyter is the main idea in this timeline. But if you zoom out, you can see Jupyter is actually one part of this timeline. It extends further back in the past and into this unknown future. So I would say the history of Jupyter notebooks is not over. It still be written by you and me. Thank you. And I posted the Discord channel if you have any questions and also my Twitter. So feel free to reach out. Thank you very much. Very interesting talk. I actually learned some things too. I never made the connection between Matlab, Maple and Jupyter. Are there any questions? Please use the Q&A button. Or you can also use Discord to ask questions. The channel name is Talk History Jupyter Notebooks. So you can join this one. You can press Command or Control K and then search for Jupyter notebooks and you will find the channel. If you are on YouTube, for example, then you can only ask questions using this Discord. So I don't see any questions at the moment. So while there are no questions, I do have one. It's a little bit about the future of Jupyter Notebooks. I mean, we know Jupyter Lab, which really changed the user interface. And there are also things like adding more languages. What do you think is the real future of Jupyter Notebooks or Lab or whatever? Yeah, that's a good question. I think there's going to be always some people who prefer notebooks, like even me personally, like I haven't totally adapted to Jupyter Lab, just because it's a somewhat unfamiliar interface. But I think eventually, especially some of the users who are coming more from an engineering background, they're going to prefer something like Jupyter Lab as it includes more of these features that they're used to in an IDE. So I think that I think down the road, we're going to see a lot more people using Jupyter Lab. But I think the notebook will always be there. It's simple. It's easy. You spin it up. You can run it. So I think they'll continue to coexist. Okay, I see there are two more questions. Unfortunately, we are really running out of time. So please, I'll post them in the channel. Yes, please, please copy them to the Discord channel. And I'm sure William will answer all your questions. I would have many more questions too, but unfortunately, I have to moderate here. So maybe I will come back to you too. So thanks again. And yeah, thank you so much.