Think about how you learn most technical or detail-oriented subjects.
You start at the bottom, lowest level, and you create building blocks and work your way into the thing
that eventually you get to that you actually care about.
This happens in engineering. This happens in math. This even happens in programming.
Our guest this week, Dr. Allen Downey, believes that computation and programming can help us turn this inside-out way of teaching right-side-out again.
Join Alan and me as we discuss programming as a way of thinking and physical modeling and engineering in Python.
This is Talk Python to Me, episode 119, recorded May 30th, 2017.
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 @mkennedy.
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 Linode and Rollbar.
That's right. Welcome to Linode, who has joined Talk Python to Me as a major sponsor.
Be sure to check out what both of them are offering during their segments. It really helps support the show.
Hey, everyone. I have a quick announcement before we get to our conversation.
I'm super excited to announce the availability of my next course, and this is one I've been wanting to write for a long time.
It's MongoDB for Python developers.
This is one of the most practical and real-world courses on document databases in MongoDB.
You'll learn the native query syntax PyMongo and the ODM Mongo engine.
We'll also cover performance tuning and production deployments.
Get the MongoDB course right now at training.talkpython.fm.
Alan, welcome to Talk Python.
Thank you. It's a pleasure to be here.
It's an honor to have you on the show.
I'm really excited to bring this engineering aspect of Python to all the listeners.
It'll be really fun, I think.
I hope so.
Indeed, indeed. It's really cool to see the different ways that people are using programming in Python
and certainly to see how it's slowly eating away at the big commercial monolithic type things like MATLAB and Mathematica and so on.
Right, right.
Yeah, very fun.
We're going to dig into that for sure, but let's start at the beginning.
What's your story?
How did you get into programming in Python?
I got to Python in, I think, the year 2000.
I have a great story, which is I actually was working in Java.
I was teaching at Colby College up in Waterville, Maine.
I was unhappy with the books.
I was using, so I started writing a free open source textbook, and I wrote it in Java because that's the language I was teaching in.
I didn't know Python at the time.
I'm not sure I had even heard of Python.
But there was a snake thing, and there was some kind of movie that British make that's kind of funny.
And then, right, exactly.
Exactly.
But I put my Java book out under a free license, and Jeff Elkner, who was teaching high school in Virginia at the time, kind of took me up on the offer.
I said, you know, you can take this book.
You can modify it.
You can do anything you want.
And he translated it from Java into Python and sent it back to me.
So I actually learned Python by reading my own book.
Wow.
Most people don't learn Python by reading their own book.
That's a really crazy story.
That's amazing.
It's a strange experience because it sounded like me.
It's my writing style, but it's telling me things I don't know.
Oh, no.
That is weird.
It's like in movies where the future you comes back from the future and tells you things that you don't know.
It's just like that.
Yeah.
Oh, my gosh.
That's really, really interesting.
It was a pretty unique thing to do back in the year 2000 to release books kind of open source, right?
Like now it's pretty standard that many books have some online open source component to it.
But that was not common then, was it?
I don't think so.
And I had no idea what I was doing.
In fact, the first version, because I was writing in LaTeX, and LaTeX is almost a programming language,
I released it under the GNU general public license because I thought of it as being source code.
So that was the first license I used.
This was before the Creative Commons licenses didn't exist yet.
I switched at one point to the GNU free documentation license because that made more sense.
And now I'm mostly using Creative Commons licenses.
Okay, which Creative Commons?
Because there's a bunch of variations, right?
Yeah, different ones for different books.
Part of it, most of mine are, I don't have the non-commercial clause on most of them.
But for the ones that I'm publishing with O'Reilly, that's kind of the compromise that we've settled in on,
which is that the versions that are on my webpage have the non-commercial clause.
Right.
And then O'Reilly has the exclusive commercial license.
That seems like a pretty fair deal.
I think it's not bad.
What I've done a couple of times, when people have made a substantially modified version,
I can give them another license.
I can grant it to them under a license that does not have the non-commercial clause.
So if someone makes a really small change, then that's still covered.
But if they make a bigger change, then I've got some flexibility.
Right.
Okay.
Yeah, very interesting.
I think this way of learning Python is quite amazing.
And, you know, it's probably not entirely new, given how many people there are in the world, but it's got to be pretty rare.
So tell me, what was your experience?
What was the impression of the language as you learned it?
Were you like, why did they take away all the curly braces?
This is so weird.
Or were you like, oh, this is actually kind of amazing.
What was your thought?
Oh, no, I was hooked immediately.
Again, I was coming from Java.
And so I knew the frustration of teaching Java, which is all the stuff that you have to explain on the first day, just to write hello world.
There's public, static, void, main, string, bracket, bracket, and all that.
And in Python, of course, it's print hello world.
Exactly.
It's amazing.
I feel like people that work in those languages like Java, and I consider myself among them.
I did for a long time C++ development and some C# development.
And they're highly structured with symbol type languages, not structured in format, but structured with many, many symbols around it.
And you just feel like those are required.
Those are the right way to do it.
Everything must have curly braces and extra parentheses and whatnot until you realize that it doesn't have to be there.
You can actually have a nice, clean language that's just equally expressive.
And it's really liberating when you get there finally, I think.
Right, because you end up having to do the indentation anyway.
Yeah, exactly.
So at that point, if you have to indent, you might as well take away the squiggly braces.
Exactly.
Fully embrace it.
Great.
So you said you wrote the book when you were teaching in Maine.
And now you're still teaching at a university, right?
But you're doing it a little farther south?
Yes.
I'm at Olin College, which is just outside of Boston.
And it's an engineering school.
So it's a little bit of a different environment.
I used to do computer science in the context of a liberal arts education.
And now I'm doing computing in the context of an engineering education.
So is it a little more exploratory?
Let's try to model these things and less learn how to write operating systems, learn how to create web apps or things like this.
How's the difference?
Right.
Yeah.
Part of it is that maybe less emphasis on theory, less emphasis on getting very deep into how things work, and more on using what's there and using it to solve the problems that you're trying to solve.
Sometimes it's about engineering.
Sometimes you are modeling physical systems.
Other times it's developing software systems, but maybe more like software engineering and less like computer science.
Right.
People may disagree with me, but just coming from my background where I just minored in computer science, I didn't go all in.
I feel like computer science and programming and software development kind of are the same thing, but the true computer science part of it is much more theoretical than what a lot of people do day to day, even though they might call themselves CS folks.
And so I think you guys might have this more explicit here in your program, right?
Yeah, I think that's right.
I mean, computer science as a field is kind of a historical accident.
It came out of math departments, and then it combined with some parts of engineering.
I mean, there are pieces there that are mathematics.
They are just, that's, they're discrete mathematics.
There are parts that are the engineering of working with software.
And then there are parts that are applications, you know, using computation in science and engineering and other fields.
Those are three kind of different things that don't necessarily belong together in one department.
Yeah.
I suspect that in 50 years, they won't be one department anymore.
Yeah.
Okay.
So in 50 years, would you imagine there might be an artificial intelligence department?
Oh, interesting.
I don't know.
That might.
Or data science where that AI is a big section of it or something?
Yeah.
Data science might make more sense as a field.
I don't know.
I can't even begin to think about what this will look like.
It's hard to predict that far out, isn't it?
Yeah.
Sure.
All right.
So you teach a number of classes there, which is really cool.
We'll dig into some of the learnings and takeaways from those around sort of fixing engineering education through programming.
But let's start a little bit farther back.
You wrote a really cool article called Programming as a Way of Thinking in Scientific American, right?
Yes.
It was on their blog.
Yeah.
That's an honor, right, to be on Scientific American, a pretty cool place.
So I recommend people check that out.
I'll put a link to it.
But could you maybe give us the synopsis?
Sure.
I mean, it's the idea.
And it's not just Python, but other modern programming languages are now so expressive that I think we can move away from programming as translation.
It used to be that you had to write everything out using mathematics and then translate it into executable code.
And you see things like, you know, the name of, you know, Fortran is formula translation.
That's what programming was.
It's right in the name.
I remember, yeah, I remember learning Fortran.
I actually did a little bit of engineering work in college as well.
And they told me, Fortran's the most important language you'll ever learn.
Wait, see where that went.
But I remember that, you know, when they would teach programming to some degree it was, and you make this flow chart, and then you translate it into the language.
And that just seems so in the way these days, right?
Why would you ever do this?
It just, you write it out in the language, right?
Right, right.
And you see this now in the history of pseudocode, which is if you look at early pseudocode, it looks like mathematics notation.
And then gradually it starts to look more and more like Python.
Until you get to the point where it is Python.
That you realize that the pseudocode is more readable if you just write it in Python.
And furthermore, it's executable.
And of course, being executable is huge.
Not only because that's, you know, the purpose of code, but also now it's debuggable.
So now you're taking these ideas that are in your head.
You're expressing them directly in code without going through all these translation steps.
And now while you're debugging that code, you are debugging your understanding of the ideas that you're expressing.
You're debugging your own brain.
Yeah.
It's really, it really is amazing.
And the fact that you can push a button and get the answer means some of these conceptual debates about things are often instantly solved.
Right.
I think of a lot of mathematical proofs.
Like I'm thinking of particularly one in topology where I sat there for days working on this problem.
And you can work out the proof and you can write it down.
And it seems very much like programming, very much logical step, step, step, do this.
You come to a conclusion, but you're never really sure.
You're not a hundred percent sure.
Right.
Whereas if you can do this with a program, the cool thing is you can push a button or hit the inner key and see, you know, do I actually have this right?
Right.
There's this great story about Paul Erdős.
And I don't know if you've heard this.
This is the Monty Hall problem, which is this notorious problem in probability that almost everybody gets it wrong when they first hear this problem.
And even once somebody tells you what the right answer is, most people don't believe it.
It's just so counterintuitive.
So Paul Erdős, when a friend of his told him this problem, this is one of the greatest mathematical minds of the 20th century.
Yeah, he was truly amazing.
And he lived in the world of mathematics.
Unlike so many people, he didn't even really have possessions.
He just went from department to department, right?
Oh, I mean, he's a great story in his own right.
But this particular problem just, it did not click with him.
He refused to believe what is actually the correct answer until his friend showed him a computer simulation.
And exactly as you said, the power of writing code and seeing it happen is what it took.
There was no amount of mathematical proof that was going to be as persuasive.
Yeah, that's really, really amazing.
And so one of the things that really resonated with me from this program is a way of thinking.
And I think anybody who presents ideas to other people, maybe you're working at a company, you're leading your team, you want to tell them about something.
If you're a public speaker or if you're a teacher or whatever is traditionally, I feel like we've taught things in the reverse order, in the wrong order.
Like, what I'm going to do is I'm going to spend three weeks teaching you a billion little details.
And then in a month, you'll see that what you've actually learned is kind of cool and we'll see what we can do with it.
Right.
That's such a problem, isn't it?
Yes.
And this is now, this is a major theme of these textbooks that I'm working on, which is exactly as you said, put the fun stuff first.
Show me that it works.
Show me why it's useful.
What can I do with it?
And now I'm interested.
Now I want to know how it works and we can start going top down.
We don't have to start with all the details and work our way up.
Right.
And what's interesting, basically what makes this really possible is we can execute the ideas and understand them from the outside in.
Right.
Like if you're going to teach math, like you can't solve a fast Fourier transform unless you literally like learn all the steps.
Right.
But if you're doing programming, you could grab like a simulation library or you want to teach threading.
You could just use the simple async and await stuff and just start from the outer shell.
Like how does this look?
How do we use it?
What's amazing about it?
And then now let's dig in one layer and then another layer and another layer, like basically in reverse.
Right.
And in fact, your Fourier transform example, that's exactly what I do in Think DSP, which is chapter one.
I'm using Python and I'm using SciPy.
It's all in Jupyter Notebooks.
So right away, you can grab, download a sound, download an MP3 or make your own recording.
Look at the Fourier transform.
Look at what that spectrum looks like and understand what the Fourier transform does, how you're breaking a sound up and expressing it as a sum of frequency components.
At the end of chapter one, you understand 90% of what you need to understand.
And then the last 10% is how the Fourier transform actually works.
Right.
Yeah.
I remember learning that stuff and it was always just like, wow, this is so in serious integration.
What is going on here?
But you don't actually see like amazing signals being extracted from some noisy environment or, you know, some signal or something.
Yeah.
That's really cool.
Right.
You can start with auto-tune and work your way down.
Exactly.
One of the quotes you ended that article with that I wanted to share with everyone I thought was pretty cool is was basically that modern programming languages are quantitatively different from their predecessors.
And we're only beginning to realize the implications of that difference.
You want to add a little to that?
That's a pretty amazing, pretty awesome thought, I think.
I agree with people are just beginning to realize.
Yes.
So if we do translation, if we start out thinking in natural languages and then we express it in mathematics and then we have to translate it into code, we're limited to the set of things that we can express in all three languages.
And we lose something at each step of the translation.
So my conjecture is if we don't have to do the translation, if we work directly in code, potentially we will start writing things that look very different.
We will start writing things that we would never have come to if we approach them mathematically.
But I don't think we know yet what that's going to look like because that's not how we've been trained to think.
I think it'll have to be the next generation who start out in Python, who start out using programming languages for exploration.
And we'll see what they do that ends up being different from what we do.
That's for sure.
You know, I talk to people about how they got into programming or what was exciting to them all the time.
And a lot of times it's, well, I first, you know, wrote my simple basic program and it did something on the screen, like echoed my name a hundred times.
Or I made this turtle draw a square or something.
I can easily see a world in 10 or 15 years where people start answering that question.
Like the first thing I did was, well, I pulled up this Jupyter notebook and I typed in these things.
And then I understood something totally different than before, right?
Yes.
Or if they're going through grade school and every class that they take involves an element of computation.
I mean, right now there's kind of obvious stuff.
Like when, if people are doing trigonometry, then maybe they'll do some computing along the way.
But they're probably not doing things like analysis of word frequencies when they study a text.
But you could do that.
You could have students in middle school take a couple of different authors and look at the distribution of sentence lengths or the number of different words that people use in different types of articles or different authors.
They could do that kind of analysis.
Yeah.
That's really interesting.
I can imagine a world where the study of literature somewhat involves sentiment analysis on the text using machine learning or something like that, right?
Right.
And where that's not something that's unusual, but it's just, look, we've got computation as a tool.
We're going to apply it to everything that we study.
This portion of Talk Python to me is brought to you by Linode.
Are you looking for bulletproof hosting that is fast, simple, and incredibly affordable?
Look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
So no matter where you are, there's a data center near you.
Whether you want to run your Python web app, host a private Git server, or even a file server, you'll get native SSDs on all the machines, a 40 gigabit network, 24-7 friendly support, even on holidays, and a seven-day money-back guarantee.
Want a dedicated server for free for the next four months?
Use the coupon code python17 at talkpython.fm/Linode.
There's this big push for all kids around the world sort of learning to code.
And I think what we're touching on definitely highlights some of the amazing reasons why that is.
I don't feel like we need more programmers per se, although there's going to be a need for more programmers.
I think we need more people with these skills that can, like you say, apply a little bit of computation to everything.
Whatever it is they're doing, bring a little computation to it, right?
I agree.
I'm not trying to make everybody be a software engineer.
We don't need that, and they don't want that.
But I do think if people have basic programming skills, that becomes a pedagogic wedge.
You use that as a lever to learn everything else.
I don't know if it's a wedge or a lever.
I might be mixing my metaphors.
But it gives you a tool for learning.
Yeah, for sure.
And you have a pretty interesting place to apply that, or at least see that in action, at an engineering school where most people probably aren't programmers.
But they really kind of need some computation, right?
Right.
We have a range of students, both when they come in, not everybody has programmed when they get here.
So we are the first contact for many of them.
And then when they leave, not everybody's going to do software.
We have some who love it, and that's going to be their career.
And others, especially, not to stereotype, but the folks doing mechanical engineering are not necessarily the ones who love software.
But the chances are they're going to do something with software at some point in their careers.
Yeah, if even it's just to write some Python script to automate something that actually is the application they're modeling with, right?
Right.
At the very least, they can automate the boring stuff.
Exactly.
All right.
So maybe that's a good place to segue into your physical modeling stuff.
So let's talk about physical modeling in Python.
You're doing a course there.
You've got some cool libraries and stuff that you're working with.
You said you're basically trying to fix engineering education.
Maybe we could start with that.
That's the Olin mission.
So Olin College was founded because the founders thought that engineering education is broken.
Why is it broken?
A couple of ways.
You know, one of them is that it's divorced from the people that we're designing for.
So engineers, I use this analogy that it's as if the engineer is sitting in a box.
Somebody comes and slides a well-formulated problem under the door.
And you have no idea where it came from, but you craft a beautiful engineering solution and you slide it under another door with no idea where it's going.
And that doesn't work.
Engineers have to understand the people they're designing for.
They have to identify opportunities.
They have to formulate those beautiful problems and figure out, first of all, is there an engineering solution?
Because not always.
Is there going to be one?
And then if there is, great, let's do the engineering.
Let's craft a beautiful solution.
But now there's a ton of work to get that idea out of the lab and make it real in the world.
So engineering education has to hit all three parts of that, designing for people and then crafting an engineering solution and then getting it out into the world.
Yeah, that sounds like a really nice way to structure everything.
You also talked about the science and math death march.
What is this?
Well, that's the other big problem with engineering education is that there's not enough engineering.
Students don't see anything that really looks like engineering, that looks like the practice of engineering, at least for the first two years.
Very often they're doing math and science and other prerequisites.
And they treat engineering as if it's the reward that you get for surviving past all those hurdles.
But even then it tends to be, even in the second and third and fourth years, it tends to be very theoretical.
So students often graduate with a lot of ability to solve the problems that are in the textbook, but very little ability to do real engineering.
Yeah, that was my experience in college.
So I feel like taking programming and simulations and letting you sort of start before you fully understand all the way down is a way you could maybe move the engineering up.
Yeah.
So this is the course that I'm working on right now is called Modeling and Simulation.
And this is part of the first semester at Olin.
We have three classes that go in parallel.
Modeling and Simulation is about doing physical modeling.
So you've got a physical system.
You make a model of what are the important parts that you have to include?
What are the things that you can leave out and simplify?
And then do either mathematical analysis or computational simulation to use that model to either predict something.
You know, what will this system do in the future?
Explain why the system behaves the way it does.
Or to design something to do some kind of optimization.
Okay.
And this is like, welcome to the university.
Here's your dorm.
Here's where you get textbooks.
We'll see you on Monday in this class.
Like that early?
That is, yes, that's exactly right.
And it's, we do some programming.
So of the first year classes, this is the one that has the most software in it.
And, but again, I mentioned most people are coming in, they haven't programmed before.
So we are simultaneously learning a little bit of programming, but with the immediate goal of modeling physical systems.
That carves it down.
We can teach a very small subset of the language because it's not general purpose programming yet.
It's really application focused.
It's not a full multi-tier web application with a database back in the scale.
No, no, no.
Just, we're going to run this math problem against this data and go, right?
Exactly.
Right.
So, you know, some of the first examples are just four loops where you're updating a variable that just measures, you know, the quantity of something.
We're doing a bike sharing example.
Probably one of the first examples is, you know, you've got three different stations and your customers are moving bikes from one station to another.
And we're going to simulate that process and figure out, is there going to be an equilibrium?
Or are we going to run out of bikes?
Do we have to move the bikes around?
So, with a very simple model, I mean, we're talking about three variables and addition and subtraction.
But we can get some interesting questions.
We can see equilibrium.
We can see non-equilibrium.
We can evaluate different strategies.
Like, should I move the same number of bikes every day?
Or should I measure something and make decisions dynamically?
All kinds of things.
Yeah.
And that definitely ties back to the real world.
I just heard today, I think it was today, maybe a few days ago, that Uber is running some program where or feature where it's cheaper to get cars where there's too many cars if your destination is in a place where they need to basically move a car to effectively.
Ah, yes.
So, here it is, just on a much larger scale, right?
Right.
So, almost the opposite of surge pricing.
It'll be a discount if you happen to be going where we want you to go.
Yeah, I think that's what, yeah, they called it like a power zone or something.
I think it was Uber.
It could have been Lyft, but I'm pretty sure it's Uber.
Ah, interesting.
Yeah.
So, okay, you come in and you have them do these models and they can do it computationally.
Do they do that in Python?
Until this coming year, everything has been MATLAB, which has worked okay.
It's got some nice tools built in.
So, there are things like there's an ODE solver, there's a root finder, there's an optimization tool.
And those are great.
Again, thinking about going top down.
We can use those tools before we understand how they work.
So, that's been good.
But we're switching to Python starting this fall.
Oh, that's exciting.
So, you guys are getting ready over the summer and then it's going to launch in Python for the next set of students, huh?
Yes.
So, this is my big project this summer is rewriting a lot of the materials that we have, switching over from MATLAB to Python.
Okay, excellent.
And this time, you're going to be writing the Python, not someone sending it back to you.
Exactly.
Oh, that sounds really great.
Do you think that this would be, I'm sure it would be possible.
Would this be a likely thing without IPython notebooks and Jupyter and all that kind of stuff?
It certainly could.
I think it would be less good.
I think one of the nice things about Jupyter is the students can just check out a notebook.
And there's a nice pedagogic process there where the first time through, they can just read the code and execute it and see what it does.
And maybe on the second pass, they're just making small changes, like try and experiment, change a parameter, put a couple of extra statements here or there.
And I think you're modifying code.
You can learn a lot from doing that before they get to the third step, which is really, okay, now you're going to create code from scratch.
Sure.
I think that's nice to start that way.
Especially this is almost like their first programming course, at least for some of them.
So they come in and say, well, what if we moved three bikes a day instead of just two?
How does that change the equilibrium and play with it?
And you have the nice pictures.
Yeah, it's pretty cool.
And there's a lot of room for the students who are just learning to program.
We're going to have kind of the lower bound that says, okay, we want to make sure that everybody gets to this level.
At the same time, people who are coming in with experience or people who just pick it up quickly, they can go crazy.
I mean, there's a ton that they can go and do.
Yeah, cool.
So what are some of the libraries you're planning on using for this?
So a lot of it is SciPy.
I mentioned some of the tools in MATLAB.
We need an ODE solver, and there's a good one in SciPy.
A root finder, optimization tools.
That's basically it, and that's coming straight out of SciPy.
And then the other library that I'm looking at is called Pint.
And this does units, units and dimensions.
This, I think, if this works, will be really good.
Because we're doing physical modeling.
And in physical modeling, everything is a quantity.
If you tell me that the answer is five, my question is going to be, five what?
Five meters?
Five seconds?
Tell me the units.
Tell me the dimensions.
So one opportunity here is to do computation where every quantity has its units attached
to it, and they carry through the computation.
So if you try to add two things, it's going to check to see if they have the same units.
And if they don't, it's going to give you an error.
You can't add joules and kilograms.
What are you doing?
Exactly.
And if you look at the number of real scientific and engineering projects that have run into
problems because the units got messed up, including, I think it was at the Mars climate probe that
was destroyed because they had, I think, both feet and meters.
And that was the end of that.
Yeah.
That's really unfortunate.
We in the U.S. probably have a little bit of blame to take for keeping the feet, the imperial units
still around.
Oh, yeah.
The rest of the world has tried to move on.
And we're like, nope.
We love our feet.
Still measuring things in drams per fortnight.
Exactly.
But even so, you still have centimeters versus meter.
I mean, there's certainly room for this error, even in the unit system, the metric system,
rather.
You'd mentioned Pite earlier when we were getting things set up, and I'd forgotten.
I did check this out.
This is really cool.
So you can, say, create one of these Pite-type things, and you can say, like, three times meters
plus four times centimeters, and it will, you know, make that 3.04 meters, right?
Things like that.
It really makes it obvious and easy.
Yes.
Yep.
So it'll do error checking, or if you multiply two things together, the result will have the
right units, and it'll reduce units.
So if you express something as some crazy combination, it'll say, oh, that's Jules.
Yeah.
Really?
Yeah, Jules is a crazy unit.
So I think this highlights one of the things where, say, MATLAB or one of these package systems,
it's kind of nice in that it's self-contained and whatnot, but I don't think MATLAB has this
concept of this Pint library.
And if it has the Pint, there's, you know, a thousand other Python such libraries that
are really cool to bring in to just sort of make it more expressive, right?
Right.
And it also, when you're comparing languages, there's theoretically, all languages are equivalent
in the sense that they can compute all computable functions.
But there are pragmatic things.
There are, you know, some things are hard or easy, but there's also culture, which is around
MATLAB culture.
People tend to write fairly simple programs that are mostly script-like in the sense that
you're just combining existing features.
You're not often writing functions or functions that use other functions.
You're not writing objects.
You're not building up layers of abstraction.
Right.
You're not building reusable concepts.
You're taking other people's reusable concepts and making it like a final product, right?
Maybe not a well-factored one, but something that like, this is done when this runs.
I'm not going to like open source this in a way that other people can easily build on, probably.
I think that's often true.
And not because it's impossible.
I mean, I think there is object-oriented MATLAB out there, but it's not commonly used.
When you come to the Python cultural ecosystem, it's more of a software engineering world.
There's more abstraction, more functional decomposition, more object-oriented programming.
So at the risk of starting a programming language war, the overall level of software engineering
tends to be higher.
So the tools you're working with are more abstract.
And then from my point of view as an instructor, now I can build abstraction to put between
the students and the tools that they're using.
So what I'm planning to do, I'm making a library that's called modsim.py.
Most of what the students do, at least when they're getting started, is they're going to
use things from my library.
So I can put wrappers around things.
I can hide the details that they don't need to know about yet.
If I see them making the same errors over and over, I can generate really good error messages.
I can do argument checking.
I can just help them get over what I know the rough spots are going to be.
I think that's a great, great point.
I've had a couple of people who were teaching classes and then they've had students teaching
classes that were somehow computational and using Python said, why do I need to learn Python?
Can't I just learn MATLAB or Mathematica and just go on?
Like I've asked Jake Venderplass what he thought about this, like what he would respond.
What would you tell a student who comes and says, I don't really want to learn Python or
programming.
Can we just use MATLAB for this example or this class?
Well, you could.
And I'm not trying to say I'm not a total zealot.
And we've been teaching MATLAB for this class since 2009.
It's not impossible.
It's not terrible.
I think it's an okay first language, but I think Python is better.
I think it's a better first language.
Just I think the rough spots are smoother.
It's easier to get started.
And it's a general purpose programming language, which means that all of the effort that you
put into learning it will pay off not just for this class, but for any other class that
you're taking.
So you get a little bit more reward from that investment.
Yeah.
I think that's, that's really interesting.
And I think Jake Vanderplass maybe even touched on this on his keynote at PyCon last week
and that not everybody who goes through an engineering program or astronomy program or whatever is
going to be just an astronomer or just an engineer on the other side.
And so learning something like Python gives you a super marketable and flexible skill.
Learning something very focused in that discipline makes it less, right?
So it's also, also good job diversification possibilities, I guess.
Yeah, I think that's right.
I'm teaching at an engineering college.
So in some sense we are focused, but not all of our students are going to be engineers.
One of the things that we say is that engineering education is great preparation for a lot of things,
not just engineering.
Sure.
And you could go work at somewhere like Autodesk and work on AutoCAD, for example, right?
Or something like some company that makes software for engineers, but you could end up only using
a little of engineering and a lot more programming skills, right?
Sure.
Yeah.
Hey everyone, Michael here.
Let me take just a moment and thank one of our sponsors who makes this show possible.
This portion of Talk Python to me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files, trying to debug them,
or a million alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you get the context, insight, and control you
need to find and fix bugs faster.
Adding the Rollbar Python SDK is just as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Rollbar works with all the major languages and frameworks, including the Python ones like
Django, Flask, Pyramid, as well as Ruby, .NET, Node, iOS, and Android.
You can integrate Rollbar into your existing workflow.
Send error alerts to Slack or HipChat or automatically create new JIRA issues,
pivotal tracker issues, and a lot more.
They have a special offer for Talk Python to me listeners.
Visit talkpython.fm/Rollbar.
Sign up and get the bootstrap plan free for 90 days.
That's 100,000 errors tracked for free.
But, you know, just between you and me, I hope you don't encounter that many errors.
Give Rollbar a try today.
Just go to talkpython.fm/Rollbar.
You talked at the beginning about your book.
What was the title?
Did you say the title?
Thinking?
Think Python, right?
Think Python.
Yes.
Right.
So that's a really great book.
And it's almost like Computer Science 101 getting started with programming, right?
It is.
It's meant for people who have never programmed before.
So it really starts from X equals five.
This is a variable.
This is a value.
But it's meant to be mostly language agnostic.
So the principles are the same across lots of different programming languages.
Certainly the family of imperative programming languages.
In fact, there are now, there are translations of the book in, you know, Java and Python.
And actually the most recent one is Perl 6.
The book, Think Perl 6, just comes out, just came out this week.
Oh, that's pretty cool.
Yeah, very nice.
Okay.
So what other books have you written?
I know you talked about your digital signal processing one, right?
Right.
So that's ThinkDSP.
And then the two, the data science books are ThinkStats, which is mostly about exploratory
data analysis.
And then ThinkBase, which is specifically about doing Bayesian statistics.
All right.
Are those open source in the same sense that ThinkPython was?
Yes.
Yeah, they all are.
So those are all, my webpage is greenteepress.com.
Or if you just Google my name.
Yeah, I'll link to all the, I'll be sure to link to them as well in the show notes.
Great.
And so, yeah, all the books are there.
As I said, not all under exactly the same licenses, but they're under free licenses.
And then Think Complexity is the other one, which is about complexity science.
I'm working on the second edition of that one now.
So that's a work in progress.
That sounds interesting.
Give us a sense of what complexity science is.
It's kind of an odd set of topics.
One way to think about it is it's the physics of complex systems, systems where you have components
that interact with each other.
Like a three-body problem and gravity, something like that?
Yeah.
So that would be an example of a system that gets chaotic.
And among continuous mathematics, those are interesting systems too.
And then in discrete math world, there are things like grids and cellular automata.
So things like Conway's Game of Life and Stephen Wolfram's work in CA's cellular automata.
And then also graph models.
So things like small world networks and scale-free networks and agent-based models, one of the
big topics.
So boids, things moving around in three dimensions.
Or there are some economic models like sugarscape and Schelling's model of segregation.
So those are some of the topics.
Yeah.
Oh, that sounds really interesting.
I just need an excuse to study them, but it sounds cool.
It's great stuff and they're fun.
They tend to have a lot of leverage, like a small amount of computation for a lot of very
interesting results.
And there are philosophical implications to almost all of it.
So almost every chapter ends with, here's some reading that you might want to do from
the philosophy of science, because we've just come face-to-face with instrumentalism and
reductionism and all kinds of other isms.
Yeah, cool.
It seems to me if there are parents out there listening who have to help their kid with a
science fair presentation, you could probably take something pretty interesting from there
and put a little simulation on it and make that a science fair presentation.
It's pretty good.
It's not as good as the volcano with the baking soda, but Game of Life is pretty good.
Yeah, for sure.
So another one that you are working on is called ThinkOS, right?
Yes.
That one looks interesting.
And this takes people who you sort of assume the reader knows Python and says, all right,
let's write an operating system and see.
Yes.
So this is filling a gap that I think has opened up in the computer science curriculum,
because it used to be that the intro classes were often in C or Java or languages that are
similar, so that when people get to the operating systems class, they already know a low-level
language.
And now they're ready to find out how to implement an operating system.
Yeah.
I think you're right that this is changing.
And it's for the better in the large scale that people are starting with higher-level languages.
I think even with Java, if you learn Java and you stay in a managed language or you learn
Python, which is more common these days, understanding malloc and all these sorts of low, low, low-level
things is pretty new, right?
Right.
And that's a good example.
I think memory management is one of the gaps.
So now when students get into a second or a third computer science class, now maybe they need to learn C,
but they need to learn memory management.
They need to learn a lot about that kind of system level.
What do the operating system calls look like?
What are those APIs?
So ThinkOS is an attempt to fill in some of that space with, on the one hand, we're going to
learn system level programming in C. And on the other hand, we're going to learn about
operating systems. But what we're going to learn is the stuff that you need to know in order to be
a good application level programmer.
Right. I think you need to know C to be a good professional programmer. I don't think you need to
do it all the time, but I think knowing really what happens down at that level, really what does
it mean for pointers to do their thing? What does it mean for memory management and so on? And have
that experience is pretty important, even if you spend 99.9% of your time in Python or something.
Yeah, I think I agree. Although I tend to be skeptical about people telling me what everybody
needs to know.
Yes, of course, of course.
But I think you're right. At the very least, one of the things that you're going to have
is a mental model of what's happening while your program is executing.
Right. Yeah. And I'm not necessarily, I said C, but I'm more thinking like just a language that
you need to have a concept of like how the thing actually runs. That's more what I'm trying to say.
And I think C is probably where most people get that model.
Yeah, I agree. And maybe it used to be assembly language. So we're still moving up. But I think
you're right. And you're going to have a performance model as well of what's fast and what's slow. So
when you start writing at the application level, if you are surprised, if things are slower than you
expected, maybe you can debug that because you know what's going on one level down.
Right. Enough tools to go and explore that and go, oh, I see why this is happening rather than,
that's weird. Didn't know that would be slow. I just guess that's just won't do that anymore.
Interesting. Okay. So I think that is a really cool book. So if you come in from Python and you
want to like get some, some experience and see sort of tailor, tailor made to take you from that one
step to the next, that's cool. And certainly understanding operating systems is good as well.
So let's see, where, where are you going with courses in this whole area? What do you have other
courses that you're teaching? Do you have other areas you're trying to explore this? Like let's use
computation to help people understand stuff in the right order, not the reverse order.
Right. I've got a bunch of projects that I work on in parallel. So I mentioned complexity. That's,
that's the immediate project. Sort of medium to long-term, I'm still thinking about linear algebra.
I think there's a big opportunity there for people to really understand that in a way that lets them
do things with it. I think a lot of people who've studied linear algebra,
they walk away with the vague notion that they can prove things about matrices, but not necessarily a
lot of skills for really using the entities of, of linear algebra to do work, to solve problems by
expressing them in that vocabulary. Right. I could tell you if a matrix is singular, I could do various
other things to it, but I can't apply. There's like no useful skill I take away from this. Right.
Basically is a way a lot of people end up experiencing it. I suspect. Yep. That's another
place where doing things computationally can flip the order. You can go top down starting with
applications and gradually understanding how they work. All right. Well, that all sounds really fun.
Do you think that we should be trying to get this computational stuff in middle school or like,
like 10, 12, 13 year old kids, like maybe a little bit less math, a little bit more programming or
something, or how do you think we could take this in and make it more? So it's not something they
experience when they get to college, but sort of everyone gets a chance to see it.
Oh yeah. No, I think everybody should see it. And earlier than that, I think you can do it in
elementary school for some definition of do it. What I'm talking about is using computational tools in
the context of whatever it is that you're studying at a level that's appropriate for where the kids
are. It can't be another class. You can't go and study English for an hour and then math for an hour
and then computing for an hour. I think the computing just has to be embedded everywhere. Just in the same
way that we use paper and pencil as a tool, we should be using computation as a tool,
but not just using applications that other people wrote. There should be a gradual process of
programming for some definition of programming for basic things, languages like Scratch that are
block-based where you're just organizing computational elements, gradually working up to general purpose
programming languages. Yeah, I totally agree. I think, I think it'd be great to see that.
And I suspect we will see that over time, but who knows when it really kick in at that level.
That's a pretty big battleship to turn the curriculum up for children.
Oh yeah, no question.
All right. Well, Alan, we're getting sort of near the end of the show. So let me ask you the
two questions I always ask everyone. One, first, if you're going to write some Python code,
what editor do you open up?
I do most of my programming in Emacs. And then more recently I'm writing more and more of it in
Jupyter notebooks while I'm exploring. And then at some point I end up taking that code out of the
notebooks and putting it into modules and then either Emacs or other IDs.
Sure. All right. Excellent. And most notable or favorite PyPI package? We're over a hundred thousand
by quite a ways now.
Right. I guess pandas is probably the thing I'm spending my most of my time working with. I love
it. I did a lot of statistics using my own tools for a while. And I ended up just writing a whole lot
of pointless code that I never should have written because 90% of what I was doing would have been a
one line pandas method. Yes.
And then the other package I mentioned is pint that I'm very interested in. Again, for doing
computation with quantities that have units.
Pint is really simple. Pandas is something that's very powerful, but definitely takes some study and
to really leverage it. But it's great as well. All right. So for the educators, for the students,
or even professional programmers listening, what's the final call to action? How can they
take these ideas and do more with them?
Well, so the physical modeling project, as I said, I'm working on that this summer.
We're going to be developing that course. And I'm really interested to hear from people who are doing
physical modeling of lots of different kinds. In particular, we're probably going to start with
population models and other discrete things where you've got either animals that are breeding,
or I mentioned bicycles moving from place to place. So discrete things moving in discrete spaces.
And then probably some first order systems like thermodynamics and chemical kinetics,
maybe some pharmacokinetics. So just looking for examples that are interesting because the
applications matter. So real world problems that have consequences. And really examples where
you have a simple model that does a lot of work for you, that you can take a complex physical system
and describe it with a model that is just the right amount of simple.
Right. The interesting problems that are not so complex, they're too daunting, right?
Right, right. And really do something with it that you're either making predictions that are
real predictions that people care about, or explaining something that's genuinely an open question,
or doing design where you can actually optimize something by modeling it, finding an optimum,
and then building that product or whatever the system is.
Yeah, that's really cool. You said you're going to be working on a thing called modsim.py
for this class. Is that going to show up on GitHub? And could people come give you feedback and stuff
on it?
Yeah, I'll probably start the GitHub repository soon. In fact, I might already have, we'll have a link to that.
Yeah, there's a little bit of time shifting. So whenever you get it done, even if it comes out after
the podcast, send it to me and I'll put it in the show notes. People can then go and check it out.
All right, Alan, thank you for being on the show. It's really great to chat with you.
Thank you very much. It's been a lot of fun.
Yep, you bet. Bye.
This has been another episode of Talk Python to Me. Today's guest has been Allen Downey. And this
episode has been brought to you by Linode and Rollbar. Linode is bulletproof hosting for whatever
you're building with Python. Get your four months free at talkpython.fm/Linode. Just use the
code Python17. Rollbar takes the pain out of errors. They give you the context and insight you need to
quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash
talkpythontome. Are you or a colleague trying to learn Python? Have you tried books and videos that
just left you bored by covering topics point by point? Well, check out my online course Python
jumpstart by building 10 apps at talkpython.fm/course to experience a more engaging way to learn
Python. And if you're looking for something a little more advanced, try my Write Pythonic code course at
talkpython.fm/pythonic. 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, Google Play feed
at /play and direct RSS feed at /rss on talkpython.fm. Our theme music is Developers,
Developers, Developers by Corey Smith, who goes by Smix. Corey just recently started selling his tracks
on iTunes. So I recommend you check it out at talkpython.fm/music. You can browse his tracks
he has for sale on iTunes and listen to the full length version of the theme song. This is your host,
Michael Kennedy. Thanks so much for listening. I really appreciate it. Smix, let's get out of here.
Outro Music.
you
Bye.
you