EPISODE 1663

[INTRODUCTION]

[00:00:00] ANNOUNCER: Python is famed for its intuitive syntax, powerful standard library and rich ecosystem of packages and frameworks. It's also dynamically typed, which is part of what makes the language so accessible. Paul Everitt is the Python and Web Developer Advocate at JetBrains. He joins the show to talk about developing the PyCharm IDE, the challenge of static analysis in Python, browser-based IDEs and more. 

This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him. 

[INTERVIEW]

[00:00:45] SF: Paul, welcome to the show. 

[00:00:46] PE: Hey, Sean. Thanks for having me. This is going to be a fun thing to talk about. 

[00:00:49] SF: Yeah, I'm excited for this. 
Thanks for being here. I thought you had a pretty interesting background as I was kind of digging into LinkedIn stalking you as we were getting ready for this. But you were a materials engineer by training, US Navy, Python enthusiast. Now you're working at JetBrains on PyCharm and I'm sure other things as well. How did this variety of things happen? How did you go essentially from Navy to Python advocacy? 

[00:01:13] PE: You grow up – and I just loved computers back when they weren't really a thing. Didn't really know why I would love them. And had no concept whatsoever that there might be a career in it. So, I wanted to be a pilot, a Navy pilot and go to the University of Florida. 

I have three nightmares. One of them is I'm stuck in an airport. Number two is the university is going to call and ask for my diploma back because they're so embarrassed that they gave me a degree. Not a good engineer. Not a good Navy pilot. 

Wound up stumbling into a job with the Navy in 1991, '92. A guy who was the Navy internet manager. What's the internet was what everybody would say back then? And it was just like the perfect time, perfect job.

[00:02:02] SF: What was your involvement with the Navy internet project? 

[00:02:07] PE: It was an interesting little outfit that had to go and sell services to the rest of the Navy. Transferring money from the left pocket to the right pocket kind of thing. And so, we had to get people onto a big TCP/IP network that we had built. And so, we needed to provide services like email. And we were wiring up Navy hospitals with 56-kilobit dedicated lines. Smoking hot. 

And as the speeds were increasing, we were tasked with go find interesting things. And somewhere around 1992, the guy in the cubicle next to me ran navy.mil domain. And this totally, totally burned into my brain. I lean my chair back and I say, "Hey, Mike, can I have www.navy.mil?" He's like, "What's that?" 

From there, we started to go and get people to put their Naval organization on the web. Back then, two things I really remember about it. Late '92, early '93, not a lot of websites. And the way that you got onto the web so to speak was you – no kidding, you emailed Tim Berners-Lee. And he edited a file with a listing of websites. 

The other thing that's kind of funny is the number one way to get a naval organization on the web was to give a demo with a picture of the commanding officer's face on the homepage. After that, piece of cake.

[00:03:38] SF: And then how did you go from there to now at JetBrains? 

[00:03:41] PE: Around I'll say mid '92, I needed a scripting language for the web server. Back then, there were choices. Write it in C, write it in bash, write it in Perl. I went to the bookstore, got the Perl book, flipped through it, flipped through it and said, "Oh, hell no." And I put the book back on the shelf. Found this programming language called Python, scripting language. Had a printable Postscript tutorial. Printed it. Totally fit my brain. And so, that's how I got involved in Python. 

[00:04:11] SF: All right. Well, I think that's a good jumping-off point to start to talk a little bit about Python. As you mentioned, Python's kind of been around since the early 90s. And it was actually announced kind of the world nearly 30 years ago to the day of this recording. I actually have a snippet here from the forum announcement from Guido back on January 7th, 1994, which I'll read here. It says, "Tired of deciphering the Perl code you wrote last week. Frustrated with boring shell syntax. Spent too much time staring at core dumps lately. Maybe you should try Python, the next-generation object-oriented scripting and prototyping language with a readable syntax." Sounds pretty good. Happy birthday to Python, first of all. 

And then second of all, from those early days when you first started using Python in the 90s, what has kind of like changed and evolved with the language? And what would you say has led to its level of popularity that we see in the industry now? It survived a long time.

[00:05:07] PE: It's a good question. And probably some lessons that can be learned from it. That announcement that you just read, it's really fun to look back on it. But it's got these hidden keywords in there that explain a lot of the question. Back then, scripting and prototyping languages were really looked down on. It was like you write a program in a scripting language and the grown-ups will come later and convert to C or something like that. 

And Python had to fit into this environment of scripting languages or prototyping languages; Perl, Tcl Tk, things like that. And they weren't really considered serious programs. I'd say the way Python got around that was it was really easy to write a C extension. And so, you'd have a thin layer of Python for the humans and the big hard part in C for the computation. And that made it really easy for average people to do serious things with Python. And so, in the like first third of Python, I'd call that one of the biggest things.

[00:06:10] SF: Yeah. I've been programming personally in Python for about six years and never really sort of day-in, day-out. And I've grown to appreciate the language even though some parts of it kind of still feel foreign to me given that most of my background came from languages that directly evolve from C. C, C++, Java and so on. What are some of the aspects make Python unique to some of these other languages that are so popular and have been – there's many, many sorts of derivatives off of?

[00:06:37] PE: I'd say the biggest one – we talk about this a lot. What got Python kind of over the hill? Brett Canon, who's head of VS Code, Python, a long-time leader in the Python community, coined a phrase, "Come for the language. Stay for the community." That was a really big deal back in the beginning. Some of the competitors just weren't that fun to be around. 

And so, you have a scripting language which automatically is more accessible than some of those other languages. And people who didn't think that they wanted to be a programmer could do programmer kinds of things. Skip to the modern day, that's, with data science, a really, really big thing. 

It's friendly from a language accessibility perspective. But just the people involved were really friendly. Jim Fulton, my colleague back then, has a good expression, "Python is kind and human because Guido, the creator, is kind and human." And he kind of set this culture from the very beginning that I think really helped. 

The first two answers to that would be non-technical. Then after that, I'd say the C extensions that got plugged in helped Python scale out bigger than people would have expected a scripting or prototyping language to do. Especially important when Java arrived on the scene. 

And then the language facilities themselves scaled out so that you could do something like Instagram doing Django, which you really wouldn't have expected in the first third of Python but became a big thing in the middle third of Python finishing over to now. As you come out of the internet bubble, I should be more clear about which bubble I'm talking about, the first bubble, 1999, 2000, companies started to really value developer productivity. Computation became less important than developer performance. And so, Python became kind of a secret weapon for people. That's the big story about YouTube. Google had their own not YouTube with a big pile of C and C++ developers they were getting killed by these small Python shops. So, they bought them. 

I'll just close it out by saying now, the reason is Python's just gotten so big. It's everybody's second favorite language. And so, it becomes a very safe, from a career perspective, language to use. 

[00:08:54] SF: Yeah. I think you did a really good job of highlighting a couple sort of key things that happened. And I really agree that I think developer productivity, that we've seen that shift essentially over the last 15 years or so. Because we basically have access to bigger machines, bigger compute. And then of course with Cloud, we can scale horizontally, vertically without necessarily doing like huge investments in hardware up front. Then it becomes like how fast can you essentially like get the market and start learning, and testing and iterating? 

And we've seen languages evolve to kind of meet that need. Even languages that existed that maybe were perceived as a harder to learn language have shifted to reduce essentially that time to Holoworld or something like that to match some of the more modern approaches to that, like a Python or even things that we see in Go and other languages as well.

[00:09:46] PE: Yeah. And you've done a lot of these talks and you've gotten probably a very big bird's eye view of the entire industry and checkpoints over time. And I'll bet you've seen that, that developer experience and developer productive really have become such a big thing. There's an insatiable demand for programmers. There's just not enough anywhere in the world. And so, these languages have to adapt and evolve in order to be competitive.

[00:10:14] SF: Yeah. And stay relevant as well. Yeah. I also think it was interesting what you were saying about the shift sort of – I don't know, of the profile of the individual that was adopting Python versus Perl or something like that. And I do think that probably a lot of it did come from sort of Guido and his personality and the type of community he wanted to build up. But those early 90s, programming boards and communities could be quite toxic environment to try to learn as a beginner coder or something like that. Because there was a certain – I don't know, status symbol with you being amongst the few that could kind understand the super crazy detail, some of those languages and the sort of the hard to work with nature of them. It kind of gave you like a certain status symbol within the community that then sometimes led to problems from a power dynamic standpoint of not necessarily being the most friendly environment to try to learn how to code in.

[00:11:09] PE: I'd say you're exactly right. I'm going to date myself. That's the age I grew up in. People would print like Byte magazine. They'd go buy Byte magazine, print mag issues and retype these utterly obscure maybe assembly listings. And they would just be micro-obsessed with the innermost loop and things like that. But it's really exclusionary. That's just not a very social way to get involved in programming.

[00:11:36] SF: Mm-hmm. Yeah. And I think that's changed a lot, especially with the growth of the internet. One thing I wanted to ask you about is Python supports this offside syntax style for indentation that defines blocks of code. There's a few other languages that do this as well, like Haskell. But Python I think is definitely the most popular. But it's not a style that's all that common. Why do you think that style hasn't caught on more with other languages? 

[00:12:04] PE: I guess it's an interesting point. Let me answer with a question. Scripting language. Is that a phrase people use anymore? 

[00:12:11] SF: It's a good question. I certainly think that some people do use it and they're probably referring to – I think sometimes people talk about JavaScript as a scripting language. But also, anything that kind of runs in the shell. If you're running like a bash script or something like that.

[00:12:25] PE: Right. And I asked that question because it was such a big deal in the first third of Python. It was used as a pejorative. And the lack of braces and the use of indentation was used as a pejorative. It was just such a very obvious way to say that's not a serious programming language. Because the people who were saying that were serious programmers. They were serious programmers because they came from C. 

I'm looking at the most recent Python developer survey results from 2022. Is it okay if I give you some demographics? 

[00:12:58] SF: Yeah, sure. 

[00:12:59] PE: I like to joke that 101% of Python developers started coding yesterday. Because it feels that way. 37% in the 21 to 29 age range. Another 9% in 18 to 20. And professional coding experience, 33% are less than one year. And then the next biggest is 19% with one to two years. How many of those people came from C? 

[00:13:26] SF: Probably very few.

[00:13:28] PE: This whole it's missing the braces. We might have just kind of outgrown that as an industry. That the original hacker culture that you referenced in the beginning may have just aged out.

[00:13:40] SF: Yeah. Possibly. And it seems like from that demographic, Python is certainly a lot of people's first language that they're learning in as well.

[00:13:48] PE: Right. Right. 

[00:13:50] SF: Which probably also influences the syntax style and where they see success.

[00:13:54] PE: That's a good point, that as Python got adopted as a teaching language, with really became a thing I guess maybe 10 years ago or something like that, you're getting generations of people coming through who don't think indentation is, by default, bad. It's just another thing. 

[00:14:11] SF: What are some of the tasks that Python's maybe not well-suited for? There's been a lot of things that Python might have started in the scripting world. Now it's of course a very popular language with web application development. I'm sure many other things as well. But what are things that wouldn't make sense to use Python as your primary language? 

[00:14:30] PE: You made a reference to Go earlier, right? 

[00:14:32] SF: Yes. 

[00:14:33] PE: And so, I'll ask you a question. How much Go do you see in the last year when you're talking to people? 

[00:14:39] SF: I think there's definitely more and more companies using Go as their primary backend language.

[00:14:46] PE: I guess maybe two or three years ago at Reinvent, whatever was the first one after the pandemic, I started asking people coming up to the booth talking to them about Python. And the ones that had kind of graduated out of Python, because it wasn't meeting their needs, we're all going to Go. It seemed to be this good fit between C, C++, Rust, et cetera, versus Python. 

And so, that brings up the answer to the question. Computation speed is by far the biggest thing. Python isn't fast. It's not fast. I'm going to caveat a little bit. It's only single core. And so, those two things limit the tasks unless the things you're doing are really driven by a big pile of C underneath data science. 

Now it happens that both of those points are changing a lot right now. And we can get into that a little bit later if you'd like to. The second thing, again, back to Go, some of these system tools that people write for in-house stuff, they don't want to have to schlep a Python interpreter over there. Make sure that interpreter is set up. It's not set up correctly. It's on a different chip architecture, whatever. They want an executable. System tools were a really big thing for Python when it was competing with Perl. But there's this problem about, "Well, you got to have an interpreter over there." 

I guess the last one. I'd be interested in your opinion on whether this is a thing. There are some people who want a very high level of correctness. Also known as a compiler. And I'll say strong typing. Python people would say that we're strongly typed. We're just not explicitly typed. But a culture of declared typing and things like that. Would you say that there is a kind of high-end of the industry that really wants like provably correct programs? 

[00:16:34] SF: Yeah. I think that's my experience when I was at Google is certainly Python is one of the languages that they do use internally. Because they really only allow like a certain subset of languages. But I think Go is becoming more and more popular as well. Because, of course, they are the creators behind Go. But then I do think that there's generally a bias certainly towards languages like Java where you can – they want to have a certain amount of certainty with the compiler to reduce just the risk of – basically whatever they can do to manage risk, they're going to do. They're going to invest in those types of technology. So, they feel like an interpreted language potentially introduces more risk in terms of not knowing necessarily how it's going to run or around the types and so forth. Then they're going to maybe steer away from that for certain types of projects anyway. 

[00:17:22] PE: Fail sooner, right? 

[00:17:22] SF: Yeah, exactly. 

[00:17:25] PE: You were at Google, and sometimes I feel like Go was created to solve Google problems. 

[00:17:30] SF: Well, I think many things within Google were created to solve Google problems, right? Sometimes they translate well to other companies. But sometimes it doesn't translate as well because most companies aren't operating at that scale or even with 80,000 people contributing to the same code repository. There's problems that are very specific to Google. 

You mentioned a couple things in there in terms of like system and optimization. I think that's where now sort of the new kids on the block around Zig and Rust starts kind of stepping in as better versions of C++ and C to be able to do some of that optimization work. And they're really solving I think a different class of problems than what you might use Python for. 

And then another thing you mentioned was the sort of popularity of Python for data scientists. Why do you think that Python became so popular within that community? Is it because a lot of the things that are happening for data science are behind the scenes like power by these C libraries? But Python's kind of like a better interface into using those? 

[00:18:35] PE: Okay. Sean, you just asked an exquisite question. Something we at JetBrains and the PyCharm team have obsessed over. And I will frame it as a question back to you, data scientists. Do you think they want to be programmers? 

[00:18:52] SF: I don't think so. I think that they probably see programming as like means to do certain parts of their jobs. But I don't think that they're looking to be software engineers necessarily.

[00:19:04] PE: I totally agree. And when they create something, it's for the production of that output. And they may just never look at that code again. It might totally be a one-off.

[00:19:14] SF: Yeah. It's a completely different style of programming than working on an application that's going to be used by consumers, or a business, or something like that.

[00:19:21] PE: Yeah. Well said. And so, what they want is something that is their contact with the engine is like a super high-level, super friendly, super forgiving. Get in. Get out. Python is great at that. Python's also pretty good at writing extensions into the underlying super hard stuff. That was one of the things where Python really beat the other scripting languages back in the day. And might get some comments from people complaining about the CAPI and all the places I'm wrong on that. But history don't lie. Python did pretty good at that. 

And so, all these things combined for Python and the third-third, and hopefully there'll be lots of thirds after the third-third, the third-third of Python to explode. Two reasons. One, Python PSF and PyCon made a compelling effort at diversity in 2013. And second, the arrival of data science. I think that this is really something where the product fit with the audience for Python was great.

[00:20:30] SF: I think it's really interesting to bring up the point about the way data science is essentially using code as a tool. And what actually happens to that code afterwards, it's like you're putting something together for – capture some sort of result. And then most of the time it's probably going to be thrown away. You're not looking at it with the same sort of lens that maybe like a large software engineering team is going to be. 

I want to start to talk about IDEs. And of course JetBrains, very famous for IntelliJ. One of the most popular Java IDEs in the world. But we're talking about Python. What is hard about building an IDE for Python? 

[00:21:09] PE: Good question. I guess the first one is who wants an IDE? For some programming language communities like Java, people would not imagine using a text editor instead of an IDE. It's a very cultural thing. Other programming language environments traditionally haven't really thought in terms of IDE. It's really just people with really large projects, or long-term professionals, or stuff like that. 

As a note, that's kind of changed with the arrival of typing in TypeScript, and Python and PHP. As typing adoption has increased at least a little, that's a signal that people are more interested in tooling. The first question is it's hard because the market wants a level of tooling which might not be the same as IDEs for other languages. 

The second is Python has a lot of dynamic magic. IDEs need static analysis. Every single place that is innovative in a Python web framework is a friction point for the IDE. And you have to write some kind of special rule to understand, "In Django, that magic string should be converted to this symbolic structure. And then we index it." 

I'd say the second thing is dynamic magic. And then just the appetite in the Python market for tooling and static analysis. Last two or three years, it's come farther than I expected. Some really innovative things like Ruff, which is riding tooling in Rust, which is all static analysis. And seeing them expand the envelope for what value they can do.

[00:23:00] SF: Is it also tricky because there's sort of different language versions? There's Anaconda, PyPy and so forth, where if you're building an IDE for it, then you have to create these special rules. Or is that what you were sort of alluding to earlier?

[00:23:13] PE: There is some friction for us in supporting Conda versus CPython. Less in the language. More in the tooling. Conda has its own packaging story versus Python's packaging story. And then in the world of Python – I mean, okay, Python's old. And a lot of those decisions were either good decisions long ago or bad decisions long ago. And Python doesn't want to just break the universe on things. And so, packaging, and tooling, and installers and stuff still have to respect a lot of cruft that's out there. And so, for us as an IDE maker, we got to put up with a lot of crap just because of the historical weight that the ecosystem is carrying around.

[00:24:06] SF: Right. And then what is the typical IDE in Python written in? Because if you look at some of the best IDEs in the world, Eclipse IntelliJ, I think they're great for Java because they're basically written by Java developers for Java developers. Or if you look at something like C++ for Visual Studio, same thing. But in the context of C++. But I feel like lot of, historically, things that are used for developing in Python weren't necessarily written in Python by Python developers.

[00:24:36] PE: I'll name a couple of blasts from the past. Wing IDE and Komodo had some level of Python in them. Wing IDE – I don't want to use past tense for Wing IDE. But the ability to write a modern ID for a huge code base where the innermost loop goes through Python is going to be a challenge. And you're going to want static analysis and a bigger programming language for that. 

Now that notwithstanding, PyCharm is written in Java. VS Code is written in TypeScript. At least the surface area that people write things in is TypeScript. I don't have a good feel for how much is above the water or below the water computation-wise before they move something down to the platform. But I get the feeling they can do quite a bit TypeScript, which is kudos to them for that. But for both of us, as Python moves towards static analysis and more things being able to be analyzed that way, the bigger scale, the better performance we can do.

[00:25:43] SF: And then how are you addressing some of the challenges that you mentioned earlier with developing an IDE for Python in PyCharm? Well, the PyCharm team is growing a lot. It's been really fun and interesting in the last year. And Python, as a market, has proven itself to JetBrains. And JetBrains is responding accordingly. We now are able to do multiple things fully staffed in parallel at the same time rather than having to focus on this, focus on this, focus on this. 

Growing a lot is a big part while at the same time trying to keep our focus. We kind of know who are our customers. And our customers are a little bit more professional. A little bit more conservative. And they don't need us chasing the latest package manager with 20 stars on GitHub. We put our eggs in a smaller number of baskets. 

And one that's been interesting is Python has evolved pretty quickly in the last four or five releases on typing. Both expanding the vision of typing and refining the ergonomics on it. PyCharm, from my beginning at least, which is nine years ago with PyCharm team, they really try to stay very, very, very, very up-to-date on Python core language features, particularly typing. And so, our ability to do that helps us stay in sync with what people are expecting from an IDE for Python.

[00:27:17] SF: Does that help in terms of handling the dynamic nature of Python to support things like code completion?

[00:27:25] PE: It does. Except when it doesn't. The world of Django has been trying for a number of years to have a better type hinting story. And It's just tough. Because Django wasn't written to be type annotated. And so, as things come out, we still have to special rule stuff to get it into our indexing.

[00:27:48] SF: Okay. In the context of something like Django, or maybe Flask, or some web framework, are there specific features or capabilities that PyCharm supports to make it easier to develop with those frameworks?

[00:27:59] PE: Indeed. I'll focus on Django. It's, I'd say, mostly true for Flask and for FastAPI. One of the biggest is we've had for a long time a great debugging story. And I wish I could sit down and talk to you for an hour about debugging. Because I feel like I need, in 2024, to convince more people to use debugger. Not print statements. 

In Django the ability to put a breakpoint in a template and just stop there is fantastic. Because a lot of these places in these web frameworks, in all of the frameworks in Python, they have a little bit of magic and indirection and you're like, "How did you get here?" 

Well, when you stop at a breakpoint, you can see how you got there. And you can see all the values on all the stack frames that led to this path. And you can actually adjust things in real time stuff like that including in a template, which is this foreign universe that isn't Python. Has different scoping rules and all these other stuff. The ability for the IDE to get in there is just fantastic.

[00:29:06] SF: Yeah. I don't think I've seen that in any other IDE in terms of being able to put a breakpoint sort of in the template, essentially the front-end code and have it stop there. How does this work? Is this only for – if I'm running this locally, I can essentially attach to the web session and step through the code? Or can I also do this with a remote environment? 

[00:29:25] PE: Right. There is some remote support for it. And what's kind of fun about it is we're an IDE vendor. We have an IDE platform. We mentioned before, it's written in Java. And people may say, "Oh, my gosh. It should be written in Python." 

Well, the fact that it applies to every one of our products means our debugger has a rich set of features. Like you mentioned about breakpoints and stepping, conditional breakpoints, turning off different ways of branching, run to cursor, all these different features. For the most part, if they're in one of our IDEs, they're in all of the IDEs. 

[00:30:01] SF: Okay. And then what is the process if I'm using the IDE locally to actually go through and start one of these debugging sessions? 

[00:30:09] PE: Sure. Sure. Oh, Sean, I have a dream. And I'll tell you about the reality. Right now, you click a button, you run the Django server. You click the button right next to it, it runs the Django server under the debugger. Nothing different at all except the color of the button. Different things behind the scenes. But from a user experience perspective, it feels really similar. 

The debugger over the decade has gotten really fast. There are some Cython extensions to move some of the debugger machinery to C. And you don't pay that much of a price for running things out of the debugger. Python just shipped a PEP, Python Enhancement Proposal 669, for lower-impact monitoring such as debugging. And so, now you can get even more features without any noticeable impact. 

I now have a mantra, always be debugging. Just run under the debugger all the time, so that when you want to click a little breakpoint, you don't have to stop, start, breakpoint, stop, start go back to where you were.

[00:31:15] SF: Can I do a live code update? If, basically, I have the debugger attached and I'm running it locally, I make a change, can I just like refresh the page without restarting the debugger? 

[00:31:26] PE: In JavaScript, yes. In Python, no. This isn't a PyCharm thing. Python is notoriously hard to do hot module reloading, the expression in JavaScript. A lot of global state that is mutable, which has been getting ironed out, thanks to Eric Snow at Microsoft, over the last few releases in preparation for sub-interpreters. But it's not there. There's a plugin for PyCharm called Reloadium, a project that special cases a lot of things and has this kind of patching approach. But it's not general purpose. It's still very exciting to see what it could do to improve productivity for Python programmers. 

[00:32:09] SF: And then besides the debugger, what are some of the other unique features of PyCharm that basically make it easier to be a Python developer working within that tool? 

[00:32:19] PE: Sure. The number one thing that people say back to us is batteries included. It's all there in the box from us. I'd like to say, one throat to choke. If something goes wrong, you know who to go yell at. And that's a little bit like Python. One of the big things that Python had was the standard library was "batteries included". And that means that kind of the out-of-the-box experience. As an IDE, can be really good because we make all the different systems fit together really well. If you know one thing, you know another thing. Can I give you an example on that? 

[00:32:54] SF: Yeah. Absolutely.

[00:32:55] PE: Just before this, I was in a pair session with my colleague, [inaudible 00:33:00], and we were fixing a big JSX import kind of thing. And I did a find dialogue. And I brought up all the occurrences. And in each occurrence, I get a little panel. And in there, I've got the full IDE. And I can do autocomplete. And I can have it generate my imports for me and reformat using the style program. Instead of open the file, go fix it, come back to find. Open the file. 

That's the value of an IDE is all the things that would be written by separate people with different style approaches. No. You get something that brings all of your developer workflows; VCS, database, terminal, all these things into one consistent experience. 

I'd also say IDEs are a good value for people who value tooling. Who are going to spend a little bit of time learning their tool because they are professional with a career and that would amortize over time?

[00:34:00] SF: Yeah. I mean, I think like one of the things we talked about earlier was that some of the attractiveness of Python, especially as a first language or a learning language, is that it's just easy to get started. But I think historically, at least for my perspective, one of the reasons larger scale projects end up falling into a different camp in terms of programming languages like a – maybe there's a bias towards Java in an IDE environment is because, as the project grows and scales, there's a lot of tooling that allows you to kind of navigate the complexity and also restructure it. 

You can do global refactoring. And you don't have to worry as much about sort of the longtail implications of like moving a file that suddenly the references change because there's ways of automatically updating those in some of these other languages. It sounds like with some of the value that you can derive from PyCharm as an organization using Python is you're getting some of this tooling that allows you to scale Python projects maybe beyond what might have been done historically.

[00:35:02] PE: Very much agree. In kind of the first half of PyCharm, PyCharm's life, there was no Python 3.6 variable annotation. There wasn't the beginning of type hinting. And we had to infer everything. And we did it by using the indexing machinery that was available in the IDE platform. And everything was like magic. I could navigate from here to there. I could change the name here, it would find all the references and rename all of those things. It would red squiggly me to tell me that I messed something up. Those things that you felt like you would get from the industrial programming languages. 

But that had to be done by the IDE. And now with Python getting a little bit better to the degree that people will adopt it, the typing, and static analysis and stuff like that can be done below PyCharm at the language itself. 

[00:35:55] SF: Another trend that I think is starting to grow is more and more companies adopting remote development environments. There are new startups like Daytona that are focused specifically on this. There's a bunch of stuff in Microsoft that now in their suite that supports this basically. My code doesn't need to live locally on my machine. And even where I run it doesn't need to be running from my local host. I can essentially spin up this remote development environment that looks – is going to look and behave the same way that my production environments do so that I can stop having the problem of it runs on my machine but it doesn't run when I deploy it. Is that something that also is supported in PyCharm?

[00:36:34] PE: We've long had remote interpreters so to speak, where we would SSH, orchestrate an environment over there. And we would take care of moving the local source as you changed it over there and all execution would happen over there. But people really want like reproducible environments and hosted centrally by management or a cloud provider. 

Two years ago, we started releasing something called Gateway, which let the entire IDE experience be over there. And you had a very thick client locally that had a protocol between the front-end and the back-end really optimized towards IDE operations. During this year, we're really going to expand on that. 

And we also have released an IDE next generation called Fleet, which is built from the ground-up around these ideas of distributed systems. It just uses our IDE platforms, machinery for indexing, all the things that you know and love about refactoring and things like that. We got a lot of stuff coming, a lot of stuff that we're working on really aimed at what customers are telling us they want.

[00:37:43] SF: Is there any other interesting you know trends that you're seeing or other future Investments that you're making at PyCharm that you want to talk about?

[00:37:51] PE: I'll respond by asking you another question about that. How do you feel about development environments in browsers?

[00:37:58] SF: Yeah, it's a good question. And that kind of goes back to a little bit about what we were talking about in terms of the remote environments. Google and a lot of other larger companies, they don't want developers essentially having copies of the code running on their machine for obvious reasons. But someone could steal your laptop and steal core IP. At least at Google, they support both an in-browser IDE that they developed themselves. A very Google thing to do. And then they also – 

[00:38:28] PE: Wait. In the browser that they also built.

[00:38:31] SF: Yes. Yeah. In the browser that they also built. And then there's also of course IntelliJ where you can actually connect it to the remote repository. And I would say the majority of people are using IntelliJ to do that or some equivalent rather than using in-browser IDE. And people tend to use that more as like a fallback when they need to make a quick change and they don't have access to their normal to tooling or something like that. I've experienced both. 

I think, personally, I prefer basically an IDE of like a dedicated tool that I can do my development work in versus the browser. There's just something I guess that feels off to me about using the IDE embedded within the browser. I've done it. You can certainly you know build programs in it. But something just feels a little bit off to me. And maybe it's my bias because I grew up learning differently than that too.

[00:39:25] PE: Okay. Again, interesting point. Maybe you and I aren't the demographic.

[00:39:28] SF: Yeah. That's true. Not everybody's a dinosaur. 

[00:39:32] PE: Sure. But then again, maybe that demographic doesn't use web browsers. They use iPad apps. I completely sympathize with your point of view. I like it because it matches the way I think too. At the end of the day, people want a great seamless developer experience. It isn't clear that a browser-based solution could give them that. But there is emerging this hybrid world where you have something that is a regular old desktop application, but the logical back-end is cut out and moved over there somewhere.

[00:40:05] SF: Yeah. 

[00:40:05] PE: And you can't really tell that you're not executing locally. You can't tell that your files aren't local. But it still keeps that latency, and desktop performance, and look and feel and all that stuff.

[00:40:18] SF: Yeah. I do wonder – I do go back and forth on this. Because if you look at something like the office suite. I'm sure, 10 years ago, people would have thought – that worked in office all the time, that it would be impossible to have an equivalent web experience. But now more and more people are using the Google Suite for those things. And even Teams has moved to a lot of things within the browser. Maybe that is a trend that we'll also see with development environments or basically the front-end of the IDE. But I don't know. Maybe we need to ask somebody younger than us that's learning now. 

[00:40:51] PE: Interestingly, that's a very, very good example about office suites. And I completely agree with you. Nobody would have thought 10 years ago that you could put someone in front of a word processor, a spreadsheet and they would be satisfied with a browser implementation of that.

[00:41:08] SF: Yeah.

[00:41:09] PE: And maybe Jupytper Notebooks are proof that you can get a class of people who are perfectly satisfied living in a browser with all the compute somewhere else. 

[00:41:19] SF: Absolutely.

[00:41:21] PE: I have seen people who are I guess like more on the financial side still feel more at home using a spreadsheet directly as a dedicated application. And maybe it just goes to like how much are you living inside that application? It's the same thing with development work as well. You're living inside your IDE for multiple hours a day. And maybe that's just a different experience than the work that you might do with some of the office tooling or something like that. I'd say a spreadsheet is closer to coding than writing a blog post or a piece of content in a document.

[00:41:55] PE: Maybe there's another vector, which is sharing. If you're creating an artifact that's meant to live a long time with lots of fingers on it, you'll be a lot happier with a browser-based solution than a desktop solution.

[00:42:09] SF: Yeah. Perhaps. Well, this is really fascinating. I'm sure we could keep going on this topic. But as we start to wrap up, is there anything else you'd like to share? 

[00:42:17] PE: Value your tooling. To all my Python friends out there, let's make the next few years more tooling-friendly so that the next group of developers can get up to speed and write better programs faster. And kind of along those lines, something else I'm trying to talk a lot about is just joy. 

Python is such a joyful place. It always has been a joyful place. It continues to be a joyful place as this next generation of data scientists come in. They are all genders from all parts of the world doing great and wonderful leadership things. It's the job of people like me to help get into the driver's seat and take things like Python to the next level.

[00:43:02] SF: Awesome. Well, I think that's a great place to leave it. Paul, thanks so much for being here. I really enjoyed it. And hopefully, we'll get back down the road.

[00:43:07] PE: Thanks, Seann. Yeah. 

[END]