PyDev of the Week: Paul Ivanov

This week we welcome Paul Ivanov (@ivanov) as our PyDev of the Week! Paul is a core developer of IPython and Jupyter. He is also an instructor at Software Carpentry. You can learn more about Paul on his website. You can also see what he’s been up to in open source by visiting his Github profile. Let’s take some time to get to know Paul!

Can you tell us a little about yourself (hobbies, education, etc):

I grew up in Moscow and moved to the United States with my family when I was 10. I have lived in Northern California ever since. I earned a degree in Computer Science at UC Davis. After that, I worked on a Ph.D. in Vision Science at UC Berkeley.

I really enjoy a lot of different aspects of computing, be it tinkering with hardware (especially microcontrollers) and trying out different operating systems and programming languages. Outside of things involving a keyboard, my main hobby is endurance cycling. I have a touring bike with a front basket that I’ve ridden on for a dozen 200km, two 300km, two 400km and one 600km rides. I also write in my journal (the pen and paper kind), which sometimes turns into poetry, some of which I have posted on my website.

Why did you start using Python?

In college, my roommate, Philip Neustrom, and my brother, Mike Ivanov, started DavisWiki, which started off based on MoinMoin, Wiki software implemented in Python.. I remember pitching in with some minor patches and being able to make some progress despite not knowing the language. It was so intuitive and self-explanatory.

At the time, I was studying Computer Science, so I was used to “priesthood” languages that required a compile cycle, like C++, C, and Java. I had also been exposed to Perl through a Bioinformatics class I took, but there was a bunch of mysterious syntax in it that you couldn’t comprehend unless someone explained it to you. Python was so simple by comparison.

That was my first exposure to it, around 2004-2005, but I didn’t start using it regularly until grad school. I finished college early with two quarters of the academic year left and applied to a few grad schools which I’d only hear back from months later. In the interim, as a backup plan, I got a job at a Java shop.

While waiting for the big monolithic Java2EE project I was working on to start-up or reload (three to eight minutes spent grinding all those enterprise beans), I started playing with Ruby on Rails. Its interactive experience was so refreshing in comparison to a compiled language. Again, it was simple to use, though it had a little too much magic. For example, setting up a model for a “Person” created a table called “People”?!

I started grad school at UC Berkeley in 2006. My first lab rotation in Jack Gallant’s Neuroscience lab was my first real exposure to Matlab, far beyond the backslash solving I learned in an introductory linear algebra class. Again, it was a similar feeling of being able to whip up code and experiment interactively, particularly with matrices. But it was (and still is) quite a step backwards for interacting with the file system, trying to build a GUI, or interacting with a database — things like that. I was also frustrated with the out-of-memory errors that surprisingly cropped up, and its license requirement was a no-go.

I wanted to have skills that would transcend academia. Matlab licenses were cheap for students. I could get one through a campus deal at the time, but I knew that it would be a different story in industry. This was right when the first dual-core laptops started to come out, and I certainly wanted to take advantage of that. But for Matlab, I’d need a license per processor!

Someone in the Gallant lab had a PDF of Travis Oliphant’s “Guide to NumPy,” so I started using Python in my next rotation in the Redwood Center for Theoretical Neuroscience, where I ended up joining Bruno Olshausen’s lab. Luckily, there were a few other people embracing Python in the lab, and in the Brain Imaging Center, which we shared offices with for a while.

What other programming languages do you know and which is your favorite?

I’ve written serious code in C, C++, Java, Go, JavaScript, TypeScript, Elm, Idris, and Haskell. The ones that make me feel particularly giddy when I write code for fun are Elm, Go, and Idris.

I really enjoy Elm for finally providing a path into using functional languages regularly, as well as simplifying front-end code. The Elm Architecture has since been popularized by React with Redux. It’s a pattern I’ve used subsequently for developing personal user interface-based projects in Go, Idris, and Haskell. It’s also a deliberately slower-moving language. I view JavaScript, and now TypeScript, as “treadmill” languages – you have to stay on them and keep running forward just to keep up with current practices or you will fall off and get left behind. I appreciate being able to come back to Elm after six to eight months and not have the whole world shift under me in the meantime. It helps that it’s a smaller community, but I like that it feels quieter.

The Go language embraces simplicity and frowns upon clever solutions. The tooling that comes with it is fantastic – from formatting to fixing code to account for API changes, to being able to cross-compile binaries for multiple architectures *AND* operating systems by just changing some environment variables. There’s nothing else like it. Someone fond of JVM languages like Java (or Clojure or Scala) might pipe up with an objection because the same executable JAR compiled once can usually run anywhere using the Java runtime. However, the same is true for vanilla Python code – it will run anywhere there’s a Python interpreter. With Go, what you get as a result of running `GOOS=openbsd GOARCH=386 go build` will be an executable of your program that will run on OpenBSD on old 32-bit hardware. Period. It does not matter if you run that command on Debian, Windows, or macOS. And it doesn’t matter if your underlying architecture is 386, AMD64, ARM, or one of the other supported ones. This works because the binary doesn’t link against any C libraries; it just makes system calls directly to the kernel. So, what you get are true stand-alone binaries!

Idris is the most different. Writing code there is a dialogue between you and the computer. You get helpful feedback and boilerplate generation that is fractal: by writing down the type signatures, you can get the compiler to fill in a big picture sketch, zoom in on a chunk and ask the compiler to fill in more of the skeleton there as well. Dependent types gave me a new way to think about programming. It’s where I want the future of programming to go. But, in some ways, Idris is the least mature and most academic of the languages I know. Compile times can be slow (though the situation is apparently much improved with the work-in-progress Idris 2). And the community is fairly small, so there aren’t a ton of ready-to-use interfacing libraries.

So, for me, Idris can simultaneously be the most fun, yet the least productive way to code. But, there’s a good parallel here with my proclivity for cycling. There are many ways of traveling between points A and B. You can drive, you can take public transportation (be it by bus or train), or you can take your bike and get some exercise and hear the birds chirping with the wind blowing in your hair.

Apologies for the United States-centric nature of this travel analogy (and setting aside both the environmental footprint and the reality of traffic jams), but for me, in many ways, Python is like driving my own car. Frequently, it is the most practical choice for me to get from point A to point B. It will be fast, and I can go pretty far at a predictable speed. But, practical can get kind of boring. It certainly wasn’t at first. I got my driver’s license when I was 18, and I still remember how much fun it was to drive. The destinations were secondary to the journey.

What projects are you working on now?

With the help of my colleagues at Bloomberg, I’ve been organizing and hosting two-day events in our San Francisco Engineering Office every three months for the past year to encourage and facilitate experimentation in the Jupyter ecosystem. We’ve called them “Open Studio Days.” The current Wikipedia summary for ‘Open studio’ captures the spirit we want to make more prominent in the tech community: “A studio or workroom which is made accessible to all-comers, where artistic or creative work can be viewed and created collaboratively. An Open Studio is intended to foster creativity and encourage experimentation in an atmosphere of cultural exchange, conversation, encouragement, and freedom of expression.” Unlike a sprint or hackathon, where the goal is to produce something specific at the end, the point of our effort is to emphasize that sometimes we simply need to explore and participate by teaching one another, by having a discussion, or just by sharing some feelings and thoughts that we might have.

I’m also helping organize the NumFOCUS Summit this year. This is a chance for folks from the open source projects that are fiscally sponsored by the organization to get together to catch up and teach each other what we’ve been up to and figure out how we can grow our projects and our communities.

I’ve also had a commit bit for Matplotlib for a while. Though I haven’t been as active there lately, I did help Tom Caswell with a pair of releases earlier this year (2.2.4 and 3.0.3), and made my first solo release over the summer (3.1.1). Prior to that, Tom had been doing those releases single-handed for the past several years. The plan is for me to continue handling these, and I am the release manager for Matplotlib 3.2.0 which should be ready in September.

I also have a half-dozen personal projects that I haven’t released which I push forward on in the background. I say this not to tease or withhold them, but to let newer developers know that it’s okay, and even desirable, to have side projects that you don’t share with others. I consider it a public service that I haven’t released a bunch of my half-baked code over the years, though some did trickle out.

What non-Python open source projects do you enjoy using?

There are too many to name, but I suppose I have to start somewhere. Regardless of the operating system I’m on, I prefer the Vim text editor — though plain vi is fine in a pinch. I use Debian, OpenBSD, and FreeBSD operating systems, GIMP and Inkscape for creating graphics, and write code in Go, Idris, Elm, and Haskell.

How did you get involved in the Jupyter and Matplotlib communities?

A dozen years ago, using the tools in the Scientific Python (SciPy) ecosystem was definitely a counter-culture thing to do. Some of the edges were sharp, so “bleeding edge” would definitely have been an apt description at the time.

I mentioned how I started grad school in 2006 and started using Python in 2007. A year later, Fernando Perez, the creator of IPython, showed up on campus. By that point, the Redwood Center had moved to a different building on campus, so we no longer shared space with some of the other Scientific Python users on campus. One major benefit of this move was that we now had access to a premium, hard-to-come-by commodity: our own conference room. So, we started gathering together every week as a py4science group. We would teach each other how to write C extensions, different submodules of NumPy and SciPy, Matplotlib, SWIG, and Weave.

Before GitHub, Stack Overflow, and Discourse, mailing lists were where the majority of the community’s activity took place. For a while, I was very active on the Matplotlib mailing list. One time, someone had a question about whether it was possible to use the Matplotlib event handling code to support interactivity in multiple backends. I wrote a clone of Pong to illustrate that it is indeed possible — it’s crazy that pipong.py is now more than 10 years old!

Is there anything else you’d like to say?

Going back to my “Python is like driving a car” analogy, I hope I’m not dissuading anyone from learning Python or continuing to use it. By all means, please do, and I will continue as well. It’s just that I hope folks are reminded that there are other modes of transportation to leverage: you can steer a ship, pilot an airplane, fly a rocket, or just go for a walk. They all have value.

Thanks for doing the interview Paul!