Do you run an open source project? Does it seem like you never have enough time to support it?
Have you considered starting one but are unsure if you can commit to it? The challenge is real.
On this episode, we welcome back Philip Wu, who has been a solo maintainer of the very popular
PythonTutor.com project for over 10 years. He has some non-traditional advice to help
keep your sanity and keep your project going by holding down a busy full-time job.
This is Talk Python to Me, episode 247, recorded December 10th, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at,
and Kennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the
show on Twitter via at Talk Python. This episode is brought to you by Tidelift and Clubhouse. Please
check out what they're offering during their segment. It really helps support the show.
Philip, welcome back to Talk Python to Me.
All right. I'm super excited to be here. I think it's my third time here, I believe.
This, I do believe this is your third time here. The first time you came, we talked about the
CPython source code and we spent a lot of time talking about coval.c. You had been doing a
graduate student course, walking them through the, basically the source code of Python to talk about
interpreters, right?
Yeah, yeah. That was back when I was at the University of Rochester. That was, that was back in the Python
2.7 days. And I've heard recently on your shows, there've been people who've done updated versions
for Python 3, right? Updated versions of this interpreter walk.
Yeah, yeah, exactly. Yeah. We had Anthony Shaw not long ago. He wrote almost a book on it. So yeah,
we had a lot of time, a good time talking about that. And the other one was really well received
as well. And it was something like geeking out in your golden years or something like that,
like coming into programming, basically near retirement. You'd done some research on that,
right?
Yeah. So that was right when I came to UC San Diego, which is where I'm working now. And that was a research
study actually done on my Python tutor platform, which we'll talk about a lot today. And it was a survey
I deployed to a bunch of programmers who were, you know, explicitly, we want to find people over 60
years old and kind of trying to find, you know, these people who are, you know, 60 and plus who are
learning programming and all sorts of settings. And we found all these really interesting things about
them. So check out that episode.
Yeah, it was really surprising. And a lot of folks really enjoyed hearing it because I think they were
in that situation. And I think they felt kind of alone, or they felt like they were doing something
that was weird or was not going to work. And it turns out there's a bunch of people who
really appreciated getting into programming. One of the ones that touched me was the idea of I want
to get into programming so I can help my grandchild either do robotics or automate Minecraft or something
like that was a really interesting reason for it.
Yeah, it was such a cool, you know, intergenerational thing too. So that was awesome.
Yeah, yeah, for sure. So we're not going to talk about either of those things really today.
We're going to talk about, as you mentioned, your project called Python Tutor at PythonTutor.com,
right? Do I have the domain correct?
Yep, PythonTutor.com.
So you like to mix it up and keep things a little bit different because I can go tutor myself on C++
at PythonTutor.com, right?
Yeah, so the name is quite outdated, right? It started as a Python only tool and then it expanded to a bunch
of languages of which, you know, C, C++, Java and JavaScript are the most, you know, the most widely
used. And I really need to think of a better name, but for now it's just PythonTutor.
No, PythonTutor is fine. Yeah, keep the roots. It's kind of as if IPython notebooks didn't get renamed
to Jupyter, right?
That's right. Yes, that's right.
It's something to that effect. So yeah, super cool. Let's, before we dive into the topics though,
let's focus just for a moment on kind of what you do day to day. You've already told your story,
how you got into programming in Python, but you said you're at the University of San Diego,
where I also was a grad student for a little while. So yeah, it's a beautiful place to be.
And what do you do there?
Especially in the winter. Yeah. So I'm at UCSD or University of California, San Diego, and
I'm an assistant professor in the cognitive science department. So in our department, we actually,
it's a very interdisciplinary program where we have people from all sorts of backgrounds who are
interested in studying the mind, studying how people interact with technology,
studying, you know, building new technologies and such. It's a very kind of vibrant interdisciplinary
place. And my research and teaching interests are in a field called HCI or human computer interaction.
So that's more widely known in industry as UX or user experience. So I teach a bunch of courses on web
development, user experience, design, basically how to develop products that are very user focused.
And my research is on, you know, a topic that I think many of your listeners be interested in is
on, you know, how do you build new kinds of interactive technologies that teach people programming
and also increasingly now data science. So both of those are obviously super relevant to the,
to the talk Python audience.
Yeah, absolutely. It sounds like super interesting research. And for a long time,
I worked at a scientific company that was spun out of a cognitive science lab. And there's just a ton
of interesting technology stuff going on there. You know, we were using eye tracking, like EYE,
not the letter I tracking to understand how people interacted with software and other things. And yeah,
it's, it's a fun area to work, isn't it?
Yeah, it's really cool. I mean, I think we have, you know, in our cognitive science department,
we have professors from all sorts of different backgrounds from like neuroscience to psychology
to linguistics to computer science, artificial intelligence, and, you know, emerging kind of
interdisciplinary fields. And it's, it's this nexus of a lot of like you mentioned of kind of people
and minds and technology all together in one place. So it's a, it's a really unique field to be in.
Yeah, it's got a lot of kind of interdisciplinary cross pollination stuff more so than I don't know,
I don't want to put any discipline on the spot, but you know, more so than maybe a lot of them,
right?
Yeah, yeah, I think so. You're very diplomatic. Yeah. I mean, I originally was from a computer
science department, right? So my background, my degrees are in computer science. I was at the
University of Rochester in a computer science department, and that's much more, you know,
traditional single field, even though my work is clearly very interdisciplinary in education
and technology and UX and everything. So, you know, I feel, feel very at home in a very
interdisciplinary place.
Nice. Yeah, I can imagine. Yeah, I doubt that a C-Python,
Python code walkthrough would really be a big hit in a cognitive science type of thing,
but certainly in the computer science world. All right, so let's talk about Python Tutor.
Give us the quick picture. Like, what is this thing? I've actually been using it recently,
and I'll share my experience with it. But let's start by just the elevator pitch. I'm driving in a
car. I should not be pulling up websites while I'm doing so. Tell us what it's like.
All right, so if you're in your car, if you're in your Tesla, and you have your big touchscreen,
and while you're driving, you want to, you know, learn some code. So Python Tutor is a website. It's
basically like a very simple online IDE, a very simple IDE. So you just paste in code that you find
online, or you just type in code, very simple text box. And when you hit run, the really unique thing
about it is that it runs your code. It shows the output, just like many online coding environments do.
But what's really unique is that it steps you through step by step what's going on. And at
every step, it draws diagrams of what's going on in memory. So what the stack frames are, what your
global variables are, what your local variables, what the pointers are, what the, you know, values
are and such. And it basically tries to emulate what a teacher would draw on the board, right? So you
had a teacher explain, what does this little bit of code do? They'll start drawing on the board,
like here's some data, here's some variables, here's what they point to. And the Python Tutor tool
just tries to automatically render that, so that you could just either teach yourself, or you could
actually use that to show someone as an instructional tool.
Yeah, it's really interesting. And it does, I feel like it addresses the situation where someone's
pretty new to programming, they're starting to think about, you know, what is a variable? What is a list?
What is a data structure? What is a reference type versus a value type? What is passed by reference?
What is passed by value? And all that kind of stuff that you need to start to at least just get a bit of an
intuition for if you're not necessarily doing a computer science degree, but you still need to
have a sense of this thing is actually shared by multiple variables. And if I interact with it from
either, it affects all of them, stuff like that. And so you can do really simple things like create a
list, and then assign it to multiple variables, and just very clearly show how that works.
Yeah. And you know, the examples that we show, you know, the list aliasing is a great one, like,
you know, just always great to say code on the air, right? So it's, you know, say like x equals
bracket, you know, one comma two comma three, and then y equals x. So, you know, it's not clear exactly
what y equals x does, right? In some languages, it might actually call a copy constructor and make a
copy of the list one, two, three. But in Python, it happens that, you know, y equals x kind of,
it copies the reference, right? So after you do that, then x and y both point to the same list of
one, two, three memory. But then if we asked you, you know, what does y.append4 do? And if I do y.append4,
what does x printout as? And if you see a diagram, you know, it's very clear that x will printout as
one, two, three, four, because there's only one list. But if you show people a bunch of code, you know,
x equals one, two, three, y equals x, y.append4, what does printx do? It's not at all obvious,
because people actually, you know, they've done these research studies, which are fascinating,
basically, which is, it's quite low tech, right? So you actually just give students a bunch of code,
like introduction program students, and you ask them to either draw out what they think is happening,
or just say what's happening. And people have all sorts of misconceptions, they think like
all sorts of different mental models, right? But the nice thing about showing the diagram is like,
there's one right mental model there. And once people get it, it's like night bright as day,
right? Like, oh, yeah, clearly x and y point to the same thing. And that's going to happen. So
the diagrams really go a long way into, you know, helping people learn these
fundamentals.
Yeah, I think they really do. It's kind of the thing where it's hard to unsee it. Once you've
seen it, you can't unsee like, oh, well, obviously, this is what's happened in memory, here's the list.
And then all the things in the list are other things that are pointed to by the list, and so on. But
when you're new, you don't really know. And I think it's even more challenging when you're doing
something like a class or an object, some complex thing that is, you could easily imagine,
like, if I have a dictionary, a bunch of dictionaries in a list, those dictionaries are
in the list, right? They're allocated as part of the list. But obviously, as you put it together,
you have the cool diagrams there. And I think that helps a lot. I also think it actually helps
understanding memory management a little bit, if you go and explore, right? Because Python's core
memory management story is reference counting.
Yeah. And you know, it's interesting, because the tool is designed to keep the visualization simple,
you know, for beginners, but you can imagine augmenting it with, you know, if you want to
make a more advanced version, you know, maybe you put the ref counts next to everything, and you actually
see, you know, oh, if there's three pointers pointing, and the ref count is three, and maybe if there's like
a weak pointer, you know, or some other thing pointing, and this is not just for Python, for like C++
or something, you can see, oh, there's three real pointers and one weak pointer. So if, you know,
if every real pointer goes away, the weak pointer is still there, it can still be garbage collected or
deallocated and stuff. So I think there's a lot of stuff there. And the thing you mentioned before,
just as brief aside of this, can't unsee it. So in the CS education literature, that's sometimes
called what's called a threshold concept. So a threshold is like, you know, it's like you've
crossed this for threshold, right? So they have some, I'm not super familiar with all of them that
they've identified, but like, there are certain things that like, they're called threshold concepts.
So once you get it, like getting the concept of aliasing or something, you can't unsee it,
you always will get it. But it's so hard for students to get to that point, unless someone really
shows you well.
Oh, interesting. I didn't realize how formalized it was. Of course, it makes a lot of sense, right?
Because once you identify those, if you can get people over the gap, well, they're ready to just
proceed, right? Just start understanding what data structures do or understanding how reference counting
works. But before that, it's kind of this weird, fuzzy world that you don't really understand even
what refers to what else. And so how do you understand how?
Exactly. And there's all, I mean, I don't personally do this kind of research, but I've read up on a lot of it.
Just, you know, giving even small bits of code to beginners and just seeing what diagrams they draw.
And this is very like cognitive science, right? It's very much like what mental models are you,
mental representations are you building your head? And people have all sort, you know, they draw the arrows
backwards. They draw like boxes and other boxes. They draw like, you know, variables pointing to other
variables. And it's like, if you have the students explain to it, it all makes sense in their mind,
right? But like, because the thing with programming is it's all an artificial construct,
right? Like it's, you know, I think for people like us and your listeners who've been doing
programming for a while, it seems so natural to us, but it's all artificial, right? It's all just
made up a bunch of rules that are made up.
Yeah. I mean, our boxes and our lines, those are conceptual ideas, but at least they, the concept
isn't incongruent with the way the computer works, but the computer doesn't actually care about these
concepts to the large degree, right? It just has pages of memory and numbers and whatnot.
That's right. And I think that's another, you know, more rabbit holes that we might have time
to go down, but it's just, you know, what diagram should we draw, right? Like, should we draw the
bits of memory? Should we draw, you know, the quantum states of the atoms, right? And, you know,
obviously for Python, we want something a bit more abstract, right? And the whole point of abstraction
in these higher level languages, you don't have to worry about all the bits of memory. You just worry
about conceptual data structures and so.
It's interesting. It's all about finding the best conceptual model that is both accurate, but not too low
level that you get lost in the details, but not too high level that you don't understand the important
parts, right? I think that programming and computer science, there's a lot of just having the right
mental model.
Yeah. And from the machine side, it's the right abstractions, right? It's really like the
abstractions for your mind, right? And I'm sure, you know, because you teach a lot of these online
courses and you make your own materials and stuff, and we can talk about that, but like, I'm sure you
think a lot about, you know, in these domain specific things, if you're teaching async programming,
you know, what diagram should I draw, right? I don't know, you know, is it high level? Is it low level?
You know, what is enough of an abstraction so that people can actually understand it and do stuff
with it, but it's not too low level to get people confused?
Yeah. I think one of the challenges I see in teaching in general, also in like async, for example,
but in general is having the right levels. Often you want to have something that's easy to understand,
but if you give all the detail, it's just too much. If it's too easy, people go, oh, that's fake.
That's not real. I need to actually understand what's going on. And so you've got to walk this
tight line. That's also in the applications you present, right? Do you present something
that's easily understandable, but not real? Or do you rebuild Instagram? And people are like,
what is all this, you know, caching? And what is this database thing? And like, I just want to know
a little bit about web development. So yeah, it's definitely interesting. I actually, for a course
I'm working on, have been really diving into pythontutor.com.
Oh, cool. Yeah. So, so I'm working on a course called Python for absolute beginners or Python for
the absolute beginner. So it's kind of like what I'm hoping to be is a first year computer science
course for people who don't think they want computer science. What I mean is like, take away all the
abstract sort of theoretical stuff and just talk enough about data structures and pointers to
understand like the shared list concept and whatnot. And it turns out Python tutor is really good for
creating those pictures. I was thinking about how do I draw them? Maybe I could hook up my iPad with
my Apple pencil and I could do some stuff or I could obviously make some graphics, but it's really nice
to just walk people through, you know, let's throw this into pythontutor.com and see what, what it does.
Let's just step through it. And the other thing I think is interesting is it's not like you just drop
code in there and say, run this and out pops the resulting in memory structures and values and so on.
But you can step line by line and see how the pointers and the data structures evolve and you can
even step backwards.
This portion of Talk Python to Me is brought to you by Tidelift. Tidelift is the first managed open source
subscription, giving you commercial support and maintenance for the open source dependencies you use
to build your applications. And with Tidelift, you not only get more dependable software, but you pay the
maintainers of the exact packages you're using, which means your software will keep getting better.
The Tidelift subscription covers millions of open source projects across Python, JavaScript, Java, PHP,
Ruby, .NET, and more. And the subscription includes security updates, licensing, verification,
indemnification, maintenance and code improvements, package selection and version guidance, roadmap input,
and tooling and cloud integration. The bottom line is you get the capabilities you'd expect and
require from commercial software. But now for all the key open source software you depend upon,
just visit talkpython.fm/Tidelift to get started today.
A big part of this tool is that it's, you know, it's step by step. So let's say your code runs for 100
steps, and it brings you to UI that has a slider and a button, two buttons that goes forward and back, and you
can scrub back and forth to go forward and back on all the steps. And this works because all the code is already
run on the server, it runs all 100 steps. And the idea behind this tool is not meant for, you know, giant pieces of code.
So the code doesn't run for that many steps, if it's just a few lines of code, and we can exhaustively run it and then
collect the in-memory trace at every one of those hundred or thousand whatever steps.
And then we bring it back to the front end. And then every time you do a step, either forward or back, we just
render that in a visual form. So like you said, you know, people can go at their own pace and go back and forth and
try to see, oh, what just happened between this line and this line? Oh, why this thing do that? And, you know, hopefully
some people can figure out on their own, right, if they have some intuitions about it. But, you know,
even if they can't, then they can use this as a tool to show their friend and say, like, oh, can you
explain why this thing goes down? It doesn't copy it. And at least there's something to talk about rather
than just saying, my code doesn't work. Yeah, there's a lot of people just throwing code out onto
Stack Overflow or whatever, but you could permalink back into these examples, right? So you can actually
put it in there and you could say, you see this step five, this is where your conception has gone off the
rails. And my answer applies to that right there. See this picture, right? Yeah. And it's cool because,
you know, the nice thing about taking advantage of the web as a medium is that URL concept is so
powerful, right? So not only the code is embedded in the URL, the step number is as well. So if you're
at a diagram, you know, step 20 out of 50, and you see something funny, you can send someone a link.
And then when it goes that link, it'll run the code and it'll step to the step 20. And then they can,
you know, you can ask them about that. So people have posted on Stack Overflow and on,
you know, discussion forums for like a MOOC, like an online course and stuff. They just like,
here's a Python tutor link. Can you tell me what's going on here?
Yeah. And it's used in some textbooks and it's used in, like you said, some of the MOOCs,
massive online courses, whatever the MOOC stands for. I forgot.
Yeah. The massive open online courses. Yeah. So it's used by a few techs. So like Brad Miller,
who was on your podcast pretty early on, who has this Runestone interactive and interactive Python
textbooks. Also it's used in UC Berkeley's introductory course, which is I think one of
the biggest intro programming courses and probably in the world, right? It's over 1500 students,
a term, almost 2000. They can't even like fit in a lecture hall. They have to give several sessions.
And it's, you know, because UC Berkeley is a giant school for computer science and all their
students have to take intro Python and they're using the Python tutor all throughout their
course materials. And a bunch of other schools use it too, that I haven't even kept track of.
Yeah. That's gotta be a pretty rewarding feeling to have that many folks using it and benefiting from it.
Yeah. It's really nice. I mean, it's been, you know, we can talk about the organic growth and
everything, but you know, every day we have maybe, you know, over 10,000 probably active users a day.
And it's just on a site. The other thing that is relatively new since the last time we talked was
this live help mode. So there's a public help queue. So if you just press, if you're, you know,
brave enough to press a get help button, you actually put your, just your session on a help queue
and some, anybody on the site, whether they're like a tutor who are just hanging out on the site or just
another student who is just procrastinating or just, you know, stuck on their own problem,
they can click your name and you join a shared session. And it's as though you have like a screen
share in the browser and you can see each other's mice and you can walk through and write code
together and then also chat in a little chat box. So we have like a few dozen people a day
using this feature and like getting help from just absolute strangers around the world. And it's like,
it's basically like a, you know, a stack overflow like thing, except it's real time and it's,
it's private. So it's, you know, they're not, you know, shy about posting their questions and it's
private and it's chat based. And it's, that's been really successful.
Yeah. That was really interesting. I did see that in when I was messing with trying to visualize
the code that I was trying to explain, I did see, you know, so-and-so from Argentina or a user from
Argentina is asking for help on Python. So-and-so from Germany is asking for help on C++ or whatever.
And there's a little button that just says help them.
Yeah. And you can just jump in and it's all very self, you know, it's all self-moderating,
right? It's all voluntary. If you don't like it, you can just leave. There's no, you know,
no private information being exchanged. It's very kind of lightweight and it's,
it's worked really well so far just because it's, you know, the community is still relatively
modestly sized, right? So that the people on the site are, they're usually pretty well behaved
because they're there because they're trying to learn or genuinely wanting to help each other.
It really reminds me of, you know, the, the good parts of the internet in a sense, right?
Where people are actually, you know, helpful and friendly to each other.
Yeah. That is actually really nice. There's not the permanent snarkiness, right? You just go there
to help people or whatever.
Yeah. And there's no harm done. If you, if you can't help you say, sorry, you know,
good luck and someone else might jump in and stuff.
Yeah, for sure. So you talked about some interesting things that it does. Maybe we
could just talk a little bit about that before we get into the history and just the maintaining of it.
So I have this Python code or this C++ code, and I want to put it onto your server and run it.
That already seems a little interesting and risky. The other one is you've talked about it being
stateless. And yet there's all these interesting things. Like I can bookmark and share this code,
on step five with this visualization run, or I can have this interactive chat with these people
and so on. So how does that all work?
The blog post that I think you'll link to is about, you know, maintaining and scaling the system as just
one person, right? And we'll talk about that in later on the show. But one of the, I guess,
design principles or I guess inadvertent design principles is that I didn't want to have like
much permanent state at all. So, you know, for the most part, I call it stateless in the sense that
I guess the state is all explicit, right? So like if you visit the site, you know, for every URL you go to,
that state is completely in the URL. So if you go to the site, it's blank, it's blank code. You start
typing. And if you want to save your code, quote unquote, the only way to do that is to create a
URL and that your code is actually in the URL.
Is it like base 64 encoded or something like that?
Yeah, something. Yeah. I don't think it's even compressed, but you can imagine compressing it.
And yeah, it's probably base 64, some kind of encoded. It's all in the URL. And the thing is like
modern URLs are like, you can be up to, you know, a few megabytes and stuff. I mean,
it's not recommended, but you can fit a fair amount of code in there. And again, you know,
the tool isn't for a lot of code, right? So it's like, you know, a few lines of code.
It's in the URL. And then also the status of, you know, do you want to execute this code? Which step
do you want to be on? What options do you have toggled? They're all just, you know, parameters
in the URL. So the nice thing about that is that I don't have a database, right? There's no database
anywhere. There's no user accounts. Like you don't register. You know, we don't keep track of your
history of your code. There's none of the, you know, the frills of like an online editor.
Like what you mentioned about the chat is, of course, there is a chat server, right? There is a,
you need a chat server in order to maintain that. And I guess the chat server has in memory state,
but like that doesn't keep any on disk state, right? So like if my server gets rebooted or something
crashes, then at the worst that happens is your chat session dies. And then you hope to wait till the
server auto reboots and then, you know, you reconnect and stuff. So it's very, very janky like that.
Well, I think that's actually really interesting. It's all about the trade-offs, right? What do you
want to build? Are you trying to build a community around this thing? Are you trying to build a tool?
And one of the things we're going to dive into is this is something that you've grown quite a bit,
even though you have a full-time job and it's, you're not getting paid for it. And it's,
it's sort of focusing on one thing that you really wanted to build instead of just letting it grow and
grow, because there are so many knock-on effects from the stuff that you're talking about,
right? So once you have user accounts, well, now you have to have email because one of the very first
features of a website that gets used is I can't log in. I forgot my email. Click here to reset it. Like
within hours of launching my site, that thing got used right away, right? It means, you know,
as users were just signing up, that thing got used. And once you have email, you got to worry about
spam. And then you've got to worry about the American CanSpam Act. You've got accounts,
and now you've got to worry about GDPR policies and all these, there's, it just, the tentacles of it
just grow like crazy, right? And then there's the support stuff that goes on and just, it's so easy to
ask for these simple things. And we haven't even talked about patching databases and migrations and
backups and those kinds of things, right? So, and it's fine if that's what you want to build,
go do it. You know, I went and built something kind of like that with my, my platform, but it's not
your main job or your main focus, right? Yeah. That's a great, yeah. As you were talking about
all those things, it just made me, you know, have all these, I don't have to worry about any of that.
Either that or vicariously feeling, you know, cause you know, I, I know folks like yourself and I have
other friends who are building their own software businesses, essentially a software, you know,
their own SAS businesses. And of course, if you're building a business and you have users and not to
mention having money involved, right? You have payment processing.
Oh, right. We haven't even talked about bank accounts and merchant accounts and all that
kind of stuff. That's a whole nother level.
Yeah. And I like your framing of like, just from, you know, minute one of login, right? Like to say,
you know, let's say just let one have accounts from the minute people log in, people are going to forget
their password and then they need an email reset. And then you need to send out emails. So you need
to figure out how to not get on everyone's spam filters and like all these. And then if you keep any
user data, there's all these laws and you want to term the service and you want, and then we have
money involved and stuff. So yeah, so my goal with all this, I mean, this all started out as just like
a personal project in grad school, you know, many, almost 10 years ago. And like many, you know, I've,
I followed a lot of these independent creators and independent open source developers. And a lot of
these projects just start out like mine, right? There's someone's personal itch, you know, someone has a
personal interest, they start a project, it starts small, and then it organically grows. And then it just
depends on what people's goals are with it. And for myself, you know, I'm in a very traditional
academic role. You know, my day job is teaching and doing research and all the professorly things.
And, you know, it just happens that I have this thing that I keep running. And it's been beneficial
to me both in terms of my research and teaching, obviously, and also just publicity and just, you
know, general personal enrichment. But then on the other hand, I want to be very careful about scoping
it so that it doesn't, you know, take over my whole life.
Yeah, absolutely. That's sort of the blessing and the curse of popular things, be it a free website
website or an open source project like SQLAlchemy or something like that. All of a sudden,
all these people are asking you to help add this feature or do this thing, or I can't get it to
work. Can you help me with this? And yeah, it can just overwhelm, overwhelm me, right? A lot of people
get burned out trying to deal with that. Not even to mention the folks who come along, ask for help,
which is clearly uninformed sort of foundations. And then they're angry if you won't take an hour out of
your day to help them.
Right, right. Yeah, I think everyone has experiences of that. Yeah, I mean, everybody,
you know, we've seen a lot of blog posts and things on Twitter. And it's a very common, you know,
sentiment, you know, basically, I think if you've maintained any piece of software, whether it's
your own business, or it's a it's an open source one, you know, when you get thousands, hundreds of
thousands, millions of users, you know, even if 99% of the users are great, you know, that 1% or the
0.1% of bad interactions can just be really bad, just because kind of a large numbers thing,
right? And then those bad interactions really sour you, sour your mood for the whole day and such.
So, right. And it's not just that there's only just a couple of them, right? There might just be
one a week, but the human psychology of it is we feel the negativity much more than we feel the either
explicit, hey, thanks, this thing really helped me, or even just the satisfied people using it and not
saying anything, right? But that negative stuff that sticks with you, and it can really drag you down.
If you could somehow wash it away with the 10,000 other good experiences, you could drown it out. But
that's just not how people are.
Yeah, yeah. And I think Brett Cannon has talked a lot about that. So, you know, Brett is one of the
core Python developers, and he's written some great blog posts, giving some great talks and interviews
about that concept and others as well, right? I mean, my article, my blog post links to a bunch of
prior work from other people talking about, you know, open source maintenance and burnout and
this sort of volunteer labor, right? And I learned a lot from reading a lot of this stuff through the
years, and I explicitly want to design this project so that I hopefully don't suffer from that, right?
Because, you know, that's not my full-time job to do open source.
Right, right. And you want to have a healthy psychology and feel good about yourself and
not just feel beat up all day. That's great. So, in terms of the history of Python Tutor,
basically, this is something that you created in grad school, right? And it's just,
it's taken off, it kind of rode the wave of MOOCs and online education and interactive books and all
that. And since then, you've mostly been able to just sort of keep the lights on and add a few
features, not spend tons of time on it. Is that pretty accurate?
Yeah. So, I think it started around 2010. And then the first few years, you know, I would say 2010 to
2013, those first three or so years were very active in development, right? Both because I was still
in school, so I had much more free time. And then also the MOOCs, you know, the Mass Open Online
Courses, you know, MOOCs were coming online around the early 2010s Khan Academy. A lot of these paid
online courses, right, on platforms like yours and other, a bunch of other, Linda and Pluralsight,
and all these platforms are coming on. Also, like Hour of Code and a lot of this, you know,
teaching everyone programming and kids getting into programming. So, there's just so much energy in the
first half of this decade around online tools for programming. And then a lot of, fortunately, a lot
of the intro courses were taught in Python. So, then I had this tool that had very good organic Google
searches. They call it Python Tutor. And as more people use it, more people found it, and they linked
to it from their blogs and from online courses and online textbooks and lecture notes and stuff. And it
just really grew. And then, like you said, in the last five years or so, it's mostly been in maintenance
mode because I've been, you know, very busy with my early professor career and such.
Right. And that's a critical time in that career, for sure, to make it through to tenure and so on.
This portion of Talk Python to me is sponsored by Clubhouse. Clubhouse is a fast and enjoyable project
management platform that breaks down silos and brings teams together to ship value, not features.
Great teams choose Clubhouse because they get flexible workflows where they can easily customize workflow
states for teams or projects of any size. Advanced filtering, quickly filtering by project or team
to see how everything is progressing. Effective sprint planning, setting their weekly priorities
with iterations and then letting Clubhouse run the schedule. All the core features are completely
free for teams with up to 10 users. As Talk Python listeners, you'll get two free months on any paid
plan with unlimited users and access to the premium features. So get started today. Visit
talkpython.fm/clubhouse. That's talkpython.fm/clubhouse.
So you have an interesting quote in the article that I'll link to that you talk about maintaining this as a solo open source developer and so on. You say that Python Tutor is probably, as far as you know, the most widely used piece of open source software that's maintained by a single active assistant professor. That's quite an interesting statistic. I think you may be right.
Yeah. I mean, as far as I know, that's always good to say, as far as I know, because it's true. As far as I know, it's true. Yeah. So the quote there was about like, so an assistant professor, someone who's, you know, basically in the first five or six years of their career.
Tenure track, but not yet tenured, right?
Yeah. So tenure track means that, you know, I'm on a path to work toward getting tenure, but I'm not there yet. So, you know, you're basically at, you know, these big universities, a lot about publishing, getting grants, you know, writing research papers, you know, teaching well, all that stuff goes in your portfolio. And, you know, building open source software is not really part of that portfolio. Although there are people who do it because that's part of their research lab, right?
So, and I guess my, you know, I guess somewhat claim to fame is I think out of people who are early in their careers, I don't know of anybody who's really been maintaining software has been so widely used. And there's, of course, software projects that are much more widely used. You know, the Jupyter project is a great example, right? So Jupyter notebooks and the whole Jupyter ecosystem that has started out of academia. And now there's a lot of industry partnerships, but that's, you know, a big team effort with a lot of funding with, you know, it's a big team effort. It's not just one person in there.
In their home office hacking away late at night.
Yeah, for sure. There's a bunch of folks that work on that. Another example that came to mind was SageMath. Are you familiar with SageMath?
Yes, yes.
And William Stein's work? So yeah, he was at University of Washington near Seattle, and he worked on SageMath. I don't think he did it solo, but he actually left academics to just focus on SageMath and the platform. I interviewed him many years ago, and I hope, hopefully he's still doing well. But yeah, I mean, that's kind of the pressure, right? Is for him, he's like, I can't do both.
I'm going to just go work on this project, which, you know, seems pretty interesting, but you got to balance it, right?
Yeah, it just depends on priorities, right? Yeah. So William is a bit, quite a bit more senior than I am. I mean, he's a, he made tenure and a full professor. So he advanced quite a bit in the ranks and University of Washington as the math professor.
And all the meantime, you know, obviously his passion has been making the Sage project for computational mathematics. And that, you know, again, I think that started with him, right? Like many projects. And then it grew. And to the point where, you know, he wrote some great blog posts about this kind of over the years of how it's really hard to sustain this in academia, especially if it's growing, because that's not really your day job, right?
It's hard to get funding for it. It's hard to get students to work on it. But then, you know, he decided, at least as of, you know, a year or two ago, he decided to quit his professor job and full time just basically run his, run it as a business, right?
I think it's still open source, but there's, you know, a consultancy model and hosted and everything.
Yeah, there's paid hosting cloud version as well. That's interesting. Have you considered you are subject to the publish or perish segment of your career, right? So have you considered publishing things about Python Tutor on, say, Joss, the journal for open source software or something like that?
So far, actually, you know, this whole thing about Python Tutor in these past few years, it's not just, you know, for my own personal enrichment or benefit in the world. There was actually a great career benefit as well. So because the platform has a lot of users, I'm actually able to use it to do data analysis or to run experiments or to deploy these user surveys like for the older adults. So like, imagine like it's hard to reach thousands of older adults coding all around the world if you don't have a platform that you can just deploy.
Especially beginner coders, right? Like the advanced ones, you can go through the standard dev channels, but right, Stack Overflow or whatever. Yeah, it's really hard to reach the beginners, though.
Yeah, so I've actually been able to my students, I've actually been able to do a good amount of research on the platform. So we have a bunch of papers using the platform. But you're right, we haven't actually thought about writing technical papers about the system itself, per se. And part of it is just the lack of time and priorities. And, you know, the hope is in the future, if I have more time to think about these things,
I might transition that. But so far, you know, like you're saying, I've been down a much more traditional, you know, academic research route. So our papers are much more academic in nature, which is, you know, which is good, because I mean, I obviously like doing that, too.
That's right. That's right. Yeah, it's the right fit. All right. So let's talk a little bit about your article. And you basically laid out the various steps and tradeoffs.
I think tradeoffs is the under the key word or key underpinning here of how can you both keep this very popular thing going and yet focus on your academic career.
And, you know, you have a ton of students right at UCSD that need to come to office hours and you need to grade their papers or their code and work with them.
That already is, you know, draining. You probably don't want to go and then take care of a bunch of issues and bugs and stuff afterwards that you don't need to bring upon yourself. Right.
So you kind of laid out some of the steps that you went through. And it's a little bit of a counter example of what people say you should do to be a really good open source maintainer.
And it all comes back to where do you want this thing to lead you to? Do you want to create requests of a super popular library or do you want to create Jupyter?
Or do you want to keep this thing interesting and useful while not letting it consume your life? Right.
Yeah. And I've definitely chosen, you know, sustainability as the most as the highest priority. Right. It's like I like this thing. It's running. It's running well. You know, it could sustain itself.
But if I try to grow it in any way, really, you know, I feel like it's at a good equilibrium now. And if I try to do more stuff, it would just create more work. Right. Doing more stuff just creates more work and such.
So and I like your framing of it. It's kind of a counter example. I think the explicit framing of the article, which people can read, is that there's all these best practices that people talk about in open source, which I'm sure many people on your podcast have talked about, you know, building a community, being responsive to users, having good documentation, good tutorials, just inviting collaborators.
That's right. You know, inviting collaborators, you know, maintaining a community, both of users and of contributors and such. And I basically try to turn every one of these best practices, you know, and think about the opposite. Right. Because my use case is that I don't want to grow this. I want this to keep going, but I don't want to, you know, grow it.
I do think one of the key missing elements is or key assumptions is, of course, I want my open source project to be the most widely used and highest contributed to thing, period. Right. And that may be, but if it's not, then maybe that advice no longer applies.
Yeah, I like that. I like the framing, actually. And that's, it's on a related note, this is kind of, you know, you read these blog posts about in the technology world, right? There's always more technologies coming about, you know, you can do Kubernetes and you can do all these crazy setups and you have all these new cloud engines and all platforms and stuff. And then, you know, there's these people like framework.
So you can use the new async stuff and all that, right?
Yeah. And then people are just like, all right, you can just chill because you're not running Facebook or Google or Twitter. You know, if you're just starting a minimal viable product or small business, something, just pick something that works. It's fine. Just build your product out. And, and I feel very similar, right? I don't use all the new technologies. I don't, you know, my tech stack is pretty old and pretty crufty, but it kind of works. And as long as it keeps working and it's reasonable, I don't want to like, I don't want to poke it at all because, you know, I don't want to have to deal with anything breaking.
Right. Well, if you're trying to chase the most modern JavaScript front and framework, think how many times you'd rewrite that.
Right. Exactly.
Right. It's, it's Angular. No, we're angry. We're angry at Angular now. So it's Vue. Oh, Vue went to three and people are upset about something there. So now it's React. It's just, it goes and goes and goes. Right. So pretty interesting. So let me just take you through some of the key points in the article that you talked about, some of the steps you've taken to help keep this balance that you talked about.
The one that I think we've already hit on a lot is you hyper-focused on a single use case.
Yeah. So the, the main use case, or I guess the only use case is, you know, emulating what a teacher would draw on the board. Right. So I felt like that focus is great because that gets rid of a lot of the scalability issues. Right. Cause you're like, Oh, I need to run arbitrary code. And like, how do you render, you know, a bunch of code and a bunch of diagram stuff.
And it's like, no, you know, the way to use this is think about what would a teacher draw on the board. If the teacher can't draw on the board, you probably can't understand anyways, because, you know, that's not for the use case.
And also, you know, if you have too much code, if your code is too complex, you know, we just throw up our hands and, you know, we, we bring you to like an unsupportive features page and be like, all right, you know, this is really outside of the scope of this tool.
So focus really helps, you know, the eliminating feature creep.
Right. We already talked about databases, email, reset passwords, accounts, GDPR, all that kind of stuff. Right.
And just saying, look, we just need this really cool diagramming, this auto diagramming feature.
This is what we're going to focus on. It's been really successful.
And I think that leads pretty naturally into not listening to user requests, right?
People ask for accounts or social gamification or integration with GitHub or programmer, like autocomplete, like PyCharm or Visual Studio Code or an LMS, all these different things people are asking for, right?
Yeah. I mean, these are all great ideas.
If other people want to build them or if, if I had a team to build this, that'd be great.
But again, it's just, you know, there's, if it's only me, there's no way to, you know, there's no way to implement all those.
Yeah. They all do sound fun, but they all, it's one of those things where you want to ask,
could you just make this small change and let's focus it down, not just from a whole application,
but let's just take it down to a little library, right? Some open source library you got.
Could you just add this overload or this default value to this function?
Or could you just add one other function that does something slightly different?
It's probably only three lines to write. Please do that. Why won't you do that?
Well, because now I got to go write a bunch of tests and then I've got to go rewrite the documentation.
And then there was that screenshot that showed the output, but now the output is different.
So I've got to go regenerate screenshots for all these things. And then I've got to rewrite the
tutorial because now this would be an alternative way. And there's just this three lines blows up into
a week long experience, right? It's as it's super hard to see those knock on effects.
Yeah. It's like, you could have this whole hour, just you talking to yourself. Cause I mean,
there's like, you basically said all these things way better than I could, right? Yeah.
That's right. That, you know, these things just, just keep piling up. And,
I think that goes with the focus, right? Like if you're really focused on providing one thing and
an anecdote here is that, you know, I don't have any flexibility in how the diagrams are. I'm sure
you've run into this too. You're like, I really wish this diagram was drawn in a slightly different
way. And it's just like, the list go across and then stuff like behind.
So it's just like, yeah, too bad. Right. Cause, cause you know, to make it more flexible,
it's just a lot more work. And in a way, you know, I kind of view this tool as because it's
kind of pretty stable. I just said, you know, if as an instructor, you want to work around it,
you just basically would explain it. It's like, oh, this is a tool, you know, it works,
but just be careful that, you know, this thing actually should point backwards or whatever.
And early on, I actually, I have a little anecdote here. I actually did work with a few professors
way in the early days, right? And I actually customized several versions,
some version they wanted the pointer drawn this way. And then I had a few versions for
different classes just because these are my friends and colleagues. Right. And also it was
early on. So I wanted to help them out. But after a while, I'm like, all right, there's no way I can
do this for everybody. Right. Like, so this is a canonical graphic, the visualization, take it or leave
it. Yeah. Yeah. I think it's fine. You know, if you need a better picture, use a whiteboard or
manually draw it yourself. Yeah. That's what I mean. Yeah. Draw it on either on a chalkboard,
a whiteboard, like some sort of digital equivalent, right? You could,
here's the picture I want to draw. And this is actually how it should look, right? I think that's
probably just fine. Yep. Nice. The other, the next one up in the article was that you
resist talking to users. Yeah. Yeah. That's a very,
very blunt way to put it. Yeah. So like, you know, in the early days, you know, it was great
because I had my email address on the site and it was very helpful to talk to users and get bug reports
and feature requests because that was how I was able to iterate on the tool so well. So I'm very grateful
for the early users. I mean, this is like, you know, even though I put it so bluntly,
I put an asterisk, I'm like in the beginning, it was awesome. But then after, again, after the tool
stabilized after a few years, there wasn't anything obvious I wanted to add. Then, you know, the bug
reports just were corner cases or things that have already been said before, or like, could you do this?
I'm like, no, you know, this is way too complicated. So then instead what I do is I have a very
comprehensive kind of FAQ slash unsupportive features page. And I list out basically anything
people would ask, it kind of listed out. And if people actually ask something that's unusual,
I would add it to the, you know, the FAQ. And that seems to work reasonably well.
Yeah. That's really nice. Instead of just answering it privately over email, which is frustrating,
find a way to answer it in a public permanent form. So it can just stay. You could just either
just have an autoresponder that says, first, you need to look here, and then you can email me or
something like that, right? Yeah. And you're basically now where there's an error message on
the site for whatever reason, right? Either it's a user triggered error or just like the server went
down or something. I just put a little link to the page. They can just go read the page. Whereas
before I put my email address, so then obviously my email address, people would just email me a lot.
So again, this is like the thing with design, right? Like if you want to create less work for
yourself, then, you know, make yourself less available. Right, right. Absolutely. So another
one that you decided to do is not to go and explicitly try to do marketing to promote the thing,
but more somehow you just sort of grew organically in the MOOC era and have been going strong since then.
Yeah. And like, you know, I'm a really big fan of following, you know, a lot of these open source
conferences, you know, PyCon and others and watching their videos and, and seeing how people,
you know, promote and market and spread the word about the open source project. But again,
it's just a time thing, right? It's like, I have to spend my time giving talks and traveling on much
more academic, you know, and research conferences and stuff. It's actually something I would love to do
in the future. You know, when I have a bit more kind of freedom and time to, I would love to explore
this world of non-academic conferences because I, cause you know, it's like I've been to many
academic conferences, all pretty similar, right? It's all the stereotypes that you hear about.
And I would love to participate in things like PyCon and, you know, OzCon and all these things,
but it's just, again, it's just a priority for me at this point that I haven't, you know, really
prioritized it. Sure. Yeah. Trade-offs. The other one that you mentioned that we have covered fairly
deeply is keeping everything stateless. Yeah. So just briefly on that is that I don't have,
basically I don't have a persistent database. Yeah. I guess by, by stateless, I'd be, there's
no persistent data store. Right, right, right. Right. Sure. There might be in memory chat logs
to sync that up, but that's not the same as I need to migrate Postgres to the latest version
or had a failure. So we had to go over to the backup cluster. Like that's not a problem you worry about.
Yeah. There's, there's none of that. I mean, basically it's, I have, you know, I just reboot the
servers periodically if something, it's pretty bad. I mean, it's like, there's some weird memory leak
issues because maybe with Docker, maybe with something else. I don't know. That's the point,
right? I don't actually know. I don't bother debugs. I just have some cron job that just
checks my memory usage. And if the memory usage starts spiking too high for too long, I just reboot
the server and it's all, you know, and I think I have a few servers. So it kind of, you know,
load balances. So like, it seems to work like pretty well. And at worst, you know, it's a free thing.
People will just go try again a minute later and it works. It's been holding up for a few years.
This is not a way to run, you know, DevOps or sysbit at all, but it works.
Yeah. No, look, practicality definitely beats the purity of absolutely. You're saying this as like,
I'm just this guy. I got to just keep it working and I can't be debugging this weird Docker issue.
So you know what? Just forget it. We're just going to reboot it every now and then.
If you were a real company, you would definitely not do this. But on the other hand,
there's a really cool article from Instagram's engineering blog called dismissing Python garbage
collection at Instagram. And they, you can go import GC and say GC.disable in Python and it'll
turn off the generational garbage collector that catches the cycles. But because most of the stuff
is caught on reference counting, you can actually live for a long time. So they ended up doing that
in production and saving tons of memory usage because they got better memory sharing across like
the forked out processes. Yeah. Yeah. And then they just reboot it because eventually you got a bunch of
cycles. You got to get rid of it. So they just recycle the process. That's great. Yeah. So the
same thing, right? Like it's, it's not as crazy as it sounds, I guess. Yeah. And this is like,
that's great. That's, you know, that's an engineering hack in the, you know, in the truest sense of the
word, right? That it's like a simple and, you know, kludgy solution, but I'm sure it saves them all sorts
of time and money, you know, both the, you know, you can imagine calculating literally the savings of
money in the data centers from that efficiency and also the savings of money and paying engineers to
debug and maintain all that. You know, if they had implemented a more complicated custom memory
allocator scheme, it just takes all this money for highly paid engineers to maintain all that.
Right. It's like, no, we'll just reboot it. Yeah, exactly. It's, it's so weird that they get
actually better performance by just letting it leak memory, but apparently under the right use case,
they definitely do. So yeah, that's great. Yeah. Yeah. Another, maybe put two, a couple of things
together, like kind of in that bucket are that I'm not super worried about performance reliability
and not, we already mentioned, not super dedicated to staying up on the latest version of the hot new
web framework or whatever. Yeah. And actually, you know, the, the ironically, you know, me having a very
stable sort of setup is kind of good for reliability in a sense, because, you know, if I try to change
anything around, it might fail in some weird way. If I'm always upgrading the latest libraries or latest
framework, there might be some weird memory leak that's undiagnosed. Right. But if I stick with,
you know, super old, you know, sort of, you know, kind of a lamp stack, you know, super old setups,
those things are pretty, you know, patchy and those things are pretty well debugged and fairly stable.
But on the other hand, you know, I'm not trying to squeeze every ounce of performance out, right,
that it works well enough. Sometimes you have to wait a little longer if the server is busy or you have
to retry, but you know, this is not a, you know, wall street, you know, high speed trading or something.
Yeah. Maybe some, some large lecture is just finished. And, or they said, everybody open up
your laptop and try this. It's like all thousand of you go here now and try this. Maybe, maybe you run
into it. But my experience was it was super fast and it was totally fine. I had no latency issues. And I,
I think that's interesting because I feel like so much the trade-offs that we consider,
imagine a world where we're so successful that we can barely stand it. You know what I mean? Like,
there's, what if we're featured on the front page of Forbes or we're stuck to the top of hacker news for
like three weeks or, you know, product hunt and just the people come and they just crush it.
I think people really don't appreciate a lot of people, not everyone. A lot of people don't
really appreciate how much traffic, just simple pyramid flash Django on a $10 server can handle. I
mean, my server, we get millions of requests. We do like 15 terabytes of data traffic exchange. It's
ridiculous. And it's like the CPU usage is 5%. You know, it's, it's nothing.
Yeah. I think that, I mean, this goes back to the point earlier that we've mentioned, you know,
these blog posts about, you know, don't worry about designing for scale up front, right? This is,
I mean, it's a classic case, the modern instance of premature optimization, right? It's like,
you know, I think a lot of this premature optimization is, you know, as software developers,
you know, we often like to try on new technologies and try to, you know, they're intellectually
interesting, right? Like, Oh, if you can hook this up and this up, it's intellectually interesting.
And it's, I feel personally, it's sort of like procrastination from thinking about your product,
right? So it's like the hard thing when you're building either open source or a product or
anything is the actual product and talking to users and the, the real core of what you really,
well, whether you're building something people really want, right? Because then you have to
actually talk to people and face criticism, but right. Documentation or tutorials or other boring
stuff in your mind. That's not like cutting edge. Yeah. Yeah. But if you just yak shave, I'm building
the best tech stack, then, you know, no one's going to tell you no, but then, you know, you might
over-engineer that. So for me, you know, it's not that I'm some, you know, engineering genius. It's just,
I didn't have time to do any of this. I just stuck with, I stuck with whatever stuff was available 10 years ago,
right? So that's another thing that people ask like, Oh, you know, do you use all these things?
Like they didn't exist 10 years ago. So of course I didn't use it. I haven't really upgraded at all.
Yeah. Yeah. Super interesting. The other last two, I guess, kind of fit together as well as
the code is available on GitHub and I'll link to it, but you don't make it super easy for people to work
on and you don't have a lot of contributors. Yeah. Yeah. So this is kind of like the last part,
like, you know, when people talk about open source, another assumption that people have is that
open source projects have a community of both users and contributors, right? Like you think
about these projects with contributors and, you know, GitHub pull requests and issues and all this
very vibrant thing of open source. And for me, it's like, it's open source in the strictest sense is
that the source code is open and there is a, you know, a open source valid open source license on the
code. So you can use it, you can put in your products, whatever you want, according to the licenses.
It's not quote unquote open source in that I don't foster a community contributor. So I don't,
I explicitly don't spend time on documenting the code or telling people really into the instructions
for how to install it or run on their own servers or under different edge cases and stuff. And also,
I don't really solicit contributions, right? That anyone can fork the code and, you know, use it.
I'm sure people use it in all sorts of ways I don't even know. And that's the great part about it,
but I don't personally have time to, you know, merge the contributions and manage all of this
complexity around, you know, when you go from one developer myself to anybody who's more than one,
you're dealing with a team project you have to manage. And I just didn't want to deal with that.
Yeah. And it's another one of these knock on effects of, well, it would be great to have people
to contribute, but then your code has to be a little bit higher quality so that it's easier for
them to do so. Oh, and then also you got to make sure that you have proper test coverage
completely across the board. Cause if they contribute something and the Travis CI automation
says it passes, well, is it really broken? Now you got to go test it. I mean, like here we are again,
going down this rat hole, which if that's the direction, right? Like it's about where you want
to go. Like I said at the beginning, if that's the way you want to go, you definitely want to do that.
But if that's not the way you want to go, then maybe that's not the right thing.
Yeah, totally. And yeah, I think you summarize it really. It's funny because every one of these
points, you summarize the examples better than I could have.
Perfect. Well, I'm happy to do it. You wrote a good article that I read through and thought about,
I guess an interesting term that I've heard, I heard this from Scott Henselman first, but maybe he heard
it somewhere along the way. I don't know the original attribution, but I've heard of this type of project,
at least the way you described it at the end as source open instead of open source. It's like
the source is there, but it's not sort of participating in the whole PR flow.
That said, you do have people who have contributed, right? Like the Java run,
the Java visualizers was done by other people and so on. So it's not that nobody contributes. It's more
that you're not fostering it. So I think it probably counts as open source and maybe the little asterisk
like limited for special cases.
Yeah, it's very limited. And like the Java one is a great example because it was actually done by a
professor who taught in Java. So like funny to admit, I haven't done Java since I like the beginning of
college in one class because I've just never worked in Java. I just never worked in Java.
Let's go use something else.
Yeah. I mean, I just never happened. That just was never the world I worked in. I didn't work in,
you know, enterprise apps in the 2000s or widgets or applets or whatever. So he taught in Java and he
actually made a Java extension. He actually hosted it on his own site for a while. And then after a while,
I actually merged his thing into the main thing because it was well-contained, right? It's self-contained.
It was its own thing. It just interfaces my visualizer and it works great. It works great.
But the thing is, if anyone reports a bug in it, I'm just like, I have no idea what to do,
you know, because this guy has moved on to something else too. But I like that.
Software is as is.
It's as is. It's literally as is. I don't actually know Java. I don't know how to debug it. You know,
it's running some old version of Java. It's, you know, it works and I don't want to touch it.
All right. Yeah. It's the version of Java from six years ago, but that's what it's going to be.
It's all good. Nice. So at the end of the article, you said it's a bit of a fluke that Python Tutor is
doing so well that you've, you know, all these millions of users who have visited it and benefit
from it and so on. And the reason it's a bit of a fluke is your day job doesn't incentivize it.
So let me ask you, what do you think? Do you think it should? I mean, I did mention the Journal
of Open Source Software as a way to kind of like shoehorn it in a tad. But what are your thoughts on
things like this and academics and should academics get credit for these kinds of creations? I mean,
it's clearly a value to the world if 10 million people are understanding code better through it.
Yeah, that's a great, that's a great question. I mean, that could be its own hour. And I obviously
get that question a lot. I mean, the question is really about currently academic path, you know,
kind of research studies and publications and grants, all the more traditional metrics are the main
thing. And, and I think that things are, you know, broadening out in some fields, right? And, you know,
in fields like my own and HCI, human computer interaction, user experience, a lot of our things
are open source products that you write papers on, you do studies on, it's all very symbiotic.
I think my kind of most clear stance on this is that, you know, research is really about sharing
generalizable knowledge with the world, right? So like, an example is, if I made Python Tutor,
I just stuck the code on GitHub and said, here's the link, I think that by itself is not really any
much generalizable knowledge. It's just a bunch of stuff. But like you mentioned, if I wrote about
in detail, I showed how it works for users, if I have some general design ideas, you know, maybe these
blog posts and these things, I think that there is a way to work that into a more scholarly sort of
portfolio. And I see that in now that I'm in, you know, in a, in more disciplinary field, you know,
we have colleagues in, you know, in visual arts, right? So in UC San Diego, we have a great visual arts
department, you know, what is their portfolio, right? Their portfolio is, yeah, they write some
papers, they write some scholarly works, analysis, history, but a lot of the portfolio is my art
pieces and my film piece. If you're a film professor or music professor, you're doing performances and
stuff. So I think that the world of science is broadening out its definition more. And I,
I definitely do see that broadening in the future, but you know, universities and academia is a very kind
of traditional and slow moving sort of institution.
It's a big shift to turn. Yeah, that's right.
So for the time being, you know, I still think that, you know, like the ending of my
article, you know, I have a lot of students, especially, you know, very programming oriented
students are like, Oh, you know, I want to be able to build software and stuff. And then I,
I actually tell me what's your goal. If your goal is to be working in industry or working open source,
that's great. But if your goal is still to build up a more traditional academic career,
at least for the time being, the more traditional research and scientific studies are the way to go.
And if you can do your science in a way that can foster open science and open source, which,
you know, some people have done very well, you know, including some people we've interviewed,
that's probably the most sustainable way, right? That you do your work in the open,
but you also kind of adhere to more traditional scholarship as well. It's a lot of work, right?
But it, you know, that that's the most practical way now.
Yeah, it does seem like it's shifting a little bit, but yeah, I definitely hear where you're
coming from. I think some of the drivers are, Hey, we have this great paper about,
we just took the first picture of black holes, but Oh, by the way, we can't actually take the
pictures. We have to use artificial intelligence to interpret a bunch of different things to actually
compile the picture. And how can you possibly write your article without somehow talking about
what you built? There's probably a component that can be extracted out. I think as people are moving
away from things like MATLAB and other proprietary, you know, SAS and whatever proprietary systems,
they're starting to get into open source and it just draws them into building stuff that helps do
their research. And I think that that's eventually that's going to put enough pressure to turn the
ship a little. Yeah, I think so. And I think that people at the more senior levels can be,
can have more flexibility and in doing these sorts of things and advocating for that. And I think a lot
of this stuff works on the top down too. I already we've seen, you know, then the top down view is,
you know, if the funding agency, you know, if the funding agencies say that you must put your code
open, your data open and stuff, and which some funding, you know, the NIH and NSF, they're starting
to do that. I think those are great efforts because that at least gets people to think about, Oh, we
might need to like clean up our data and our code so that other people can use it. And eventually those,
you know, the stuff will percolate downward.
Yeah, I agree. And the reproducibility aspect that's becoming a bigger focus, it's always been
super important, but now it's easy to test whether it's reproducible. So, you know, I think that also
leads to more of the code being open and whatnot.
Yeah, exactly.
All right. Well, this has been a super interesting conversation, but you've got to answer the two
questions before you get out of here. So if you're going to write some Python code, what editor do you
use?
I still use Vim because I learned it in, you know, in grad school and I still use it, even though,
you know, everybody's on to Visual Studio Code by now. You know, again, just like with the old
technologies, right? I've passed several generations, right? There was, you know, Atom was big, Sublime
was big, and VS Code is now, you know, obviously really big. I still use Vim and that's just what I do.
We talk about these threshold concepts. There's probably some kind of theory about editors as well.
Yeah.
Well, interesting. And then notable PyPI package, something that
That's really funny. Yeah. I was trying to prepare for this, you know, last time I gave
this, you know, cop out answer, I'll just Anaconda or, you know, you know, just this package manager
and stuff. It's hilarious because I actually don't write a lot of Python code anymore, right? Because
you know, this Python tutor, it's all JavaScript, it's all web code.
That's right, that you've got to write the front end stuff. Like that's where all the magic is.
And it's not.
That's right. Yeah.
Ironically, I'll plug one thing. I was actually scrambling because I knew you were going to ask that
question, Dan. I was scrambling to look at this Python kind of wrote for something else. This code that I
wrote to, you know, inventory my file system. So I've been basically, you know, doing a lot of stuff
with basically kind of building my own personal archiving and R syncing Dropbox and kind of thing.
And one of the problems is how do you just crawl through a directory hierarchy super fast when you
have, you know, a million files. And I've actually found this is a plug for upgrading Python 3. I found
that this is not a package, but you know, the OS, the built in OS library, OS dot walk, and OS dot walk,
I believe is this thing that's only in Python, I think three, five or above. And it's super fast,
at least on the Mac. And I think, you know, it's because it probably uses some system calls or stuff.
And it's notably because I had, you know, a Python 2.7 version before using a scanner or some other
thing, right? And like, if you upgrade to Python 3.3.5 and use this, this function, you know, OS walk,
it just goes like, it's just like thousands of times faster. And this is, you know, we people talk about
this a lot, right? And like, that's one of the things that gets people to upgrade is that, you know,
if, if something just is slow, and there's a new version of the API, and a lot of things in the new,
in new Python standard library, in the standard library, I guess, are either drop and replacements,
or a slightly different API, but it just goes so much faster. I just encourage people to look at
that. So this is not a PyPI packet. It's just really just...
No, that counts. Yeah, like a useful library.
Yeah, just relooking at the standard library for, you know, things that they optimize. And,
and yeah, that was the first thing that came to my mind, because I was just working on that code.
Very nice. Very nice. All right, final call to action. People are either teachers or their students,
they're hearing about Python Tutor, they think it's maybe useful. What do you tell them?
I tell them that just go go try out the the site pythontutor.com. And to go participate in the
community of just, you know, helping each other out and, you know, asking for help and such. And it's
really community driven. So any help I can get on the site would be great. And also, if they want to
integrate it when they're teaching materials and stuff. And you know, despite what I say in my article,
I actually really do like hearing from instructors and students in the piles of emails that I get.
So I love hearing about how people are using it. So you know, if you have good user stories, or interesting
stories, I always write, you know, despite again, in my article, I say, Oh, I don't listen to users. But I actually
do listen to all the users, I actually write down all of their notes in the GitHub repo as notes of like,
these are cool future directions, I don't think I have time to do this. But these are awesome suggestions.
So I would just write that down. So it's once you get tenure, or you want to take you have a
sabbatical, and you want to come back and spend some time on it, you can actually harness all that
feedback. That's right. Yeah. I mean, that's just that's always a dream of like, Oh, someday I'll
get to make some of that. And then you just end up getting more busy over time. Because everyone
does. That's just the reality of life. That's how life is. All right, Philip, it's been great to chat
with you. As always. Thanks for being here. Awesome. Thank you so much, Michael. Thank you so much again.
You bet. Bye. This has been another episode of Talk Python to me. Our guest on this episode was
Philip Guo. And it's been brought to you by Tidelift and Clubhouse. If you run an open source
project, Tidelift wants to help you get paid for keeping it going strong. Just visit talkpython.fm
slash Tidelift, search for your package and get started today. Clubhouse is a fast and enjoyable
project management platform that breaks down silos and brings teams together to ship value, not features.
Fall in love with project planning. Visit talkpython.fm/clubhouse.
Want to level up your Python? If you're just getting started, try my Python jumpstart by building 10
apps course. Or if you're looking for something more advanced, check out our new async course that
digs into all the different types of async programming you can do in Python. And of course,
if you're interested in more than one of these, be sure to check out our everything bundle. It's like
a subscription that never expires. Be sure to subscribe to the show. Open your favorite podcatcher
and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes,
the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.