An Interview with Guido van Rossum
During the O'Reilly Open Source Conference in August in Monterey, California, LJ interviewed Guido van Rossum, creator of the Python programming language. The first part of this interview will be published in the December, 1999 issue of Linux Journal.
At the end of the interview, Guido talked about a new effort to turn Python into the programming language taught to college students majoring in something other than computer science. He seems very excited about this project, and we are pleased to be able to share it with you here.
Guido: I have one thing I really want to tell you about—a project we currently call CP4E. I can't even pronounce it myself! And it is not related to R2D2 and C3PO, even though Python is very popular with Industrial Light and Magic and the Star Wars folk. CP4E stands for computer programming for everybody. We're sort of in the middle, trying to get DARPA funding for this project. We're fairly sure we will get a bit of funding for it in the next two years. We're hoping to get a lot of funding for the next five years, in which case we will do much more work, and we will also involve other researchers.
What is the goal of computer programming for everybody? There are basically two ideas; one is, we would like to teach programming—actual programming, not Excel macros—to as many people as are interested. The other idea is we want to make really good programming tools for those people who are going to be programming a bit. We think Python or something very close to Python is an almost ideal language for teaching this kind of audience.
We have a lot of anecdotal evidence that this is the case. I think the best evidence so far comes from the Alice Group at CMU, academic people who really like Python. They happen to have Windows as their web form, but mostly because it is what the majority of their students are using at the moment. They have made it programmable—a virtual reality system. There is a rendering engine written in highly optimized C++ that talks directly to the hardware—well, almost directly. All the control stuff is written in Python, so you build your entire virtual world in Python. How you fill in your models and your 3-D objects is a different story. The actual design of the object is done using other tools. But the control, all the effects in the 3-D world, are controlled by Python scripts.
Alice has done a lot of usability studies. They take actual users and tell them, “We are going to teach you a bit of programming. Here is a bunny, and you can use commands to move the bunny forward and backward.” They sort of try to see which syntax makes the most sense to those people who have never programmed before—people from Humanities. This is like a “freshmen in college” kind of thing—people who are absolutely not in the computer science department. They form teams and have a sort of friendly competition. Within two weeks, each team has produced a couple of minutes of animation or an interactive game using this system.
They have identified the two things wrong with Python—all that language, and there are only two things wrong with it! One, apparently, is that case sensitivity is something people don't expect. This may be because they are all Windows users, and case sensitivity is sort of unusual in Windows. In typical math, lower case a and upper case A are different variables—you do not mix them up. On the other hand, if you ask a typical person to write down their user name or their e-mail address, they'll write it all in uppercase because that is the only way they can write legibly. So, it is just from their observation that most of the mistakes their users make have to do with case sensitivity. They have learned the command “move”, so they will type “move” with an uppercase “m” or all uppercase letters. The other thing is a real minor nit, where Python borrows integer division from C; so, three divided by four is zero—not good. But with those two things fixed, Python makes an ideal language for teaching.
We are going to get in touch with schools, initially local schools, so we can actually pay visits frequently. First, we are going to produce teaching materials—a whole course. There aren't currently any programming courses using Python for people who haven't programmed before. There are a bunch of excellent tutorials, but even Learning Python assumes you already know how to program and your basic questions are, “What does a function look like in Python? What are the semantics variable in Python? How do I look over an array of data in Python?” It also assumes your questions aren't “What is a function? What is a variable? What is a name? What is a string? What is the difference between constants and variables?” So we are going to write a very different kind of tutorial that focuses on those things using Python, a language that doesn't get in the way of teaching concepts.
If you see what they are currently using in high schools—if they teach programming at all—it's C++! They used to have Pascal, which was a good teaching language, unfortunately, it was so completely extinct outside the schools that I think two years ago they changed to C++, because at least it has real-world relevance.
Phil: C++ is a scary thing to wave in front of someone who doesn't know how to program!
Guido: The teachers I have heard from so far all find it a disaster! Probably partly because they don't understand C++ very well themselves, and I don't blame them! It's not their job. Even if they are a computer science teacher, they are often more likely a math teacher who also teaches on computers.
Phil: That sure isn't going to move it into the Humanities department!
Guido: Yeah! So a language like Python, which actually has roots in educational languages, will do better. Python is very strongly inspired by a language called ABC; I worked on the ABC implementation designed by colleagues of mine in the early '80s. It was a wonderful language for teaching. The history of Python comes out of the frustration I had with that language when it wasn't being used for teaching, but for day-to-day ad hoc programming—but that's a different story. Python inherits a lot of that focus to make it very simple, easy to understand, easy to remember and easy to learn. It's a very good language to start teaching. We are very hopeful about that side of the CP4E effort.
The other side, which is possibly even more exciting, is tools. If you look at a typical programming environment, whether it is for Java or C++ or Visual Basic, they are all extremely complicated because they are aimed at the professional programmers who need so many different features. Programmers can deal with the complexity, because they've spent some time learning it and possibly even customizing it, so they have the feeling they own it and they can deal with all the different panels and menus and dialogs.
Phil: Sort of like me using vi. I've been using it since 1983, and I'm just starting to get comfortable!
Guido: Yeah! There is probably very little that anyone can teach you about vi. For the kind of casual programmers we are going to try to train here, their needs in a programming environment are very different. I mean, something like the old Turbo Pascal was probably a much better match. So, I actually have done something that might be the prototype for a typical development environment for Python, which is basically just the Python text editor doing colorization and automatic indentation of your source code. Also, it will have an interactive shell where you can type your Python commands, and it will use the same colorization and indentation and have a class browser and a few other features, including a half-finished debugger that needs a lot of work before it's usable. That could be the start of the kind of programming environment we are thinking about.
What I think will make it really interesting is program analysis tools. If you have a large program written by someone else in Python and there is some hope of understanding it, it's going to take a lot of time just to find your way around in it. We hope we can produce a bunch of program-understanding tools. The tools probably won't understand the program, but they will help you understand it by giving you a road map of the software, allowing you to focus on the part you are interested in changing.
My example of something where this doesn't work very well is Mozilla. It would be so wonderful if people could actually change the Mozilla source code so they could recompile it to have a Netscape that did something different. I have a lot of complaints about the Netscape I'm using on my system. But I'm not going to rebuild it from the Mozilla sources, because there is no way I can find the time to dig through the sources to actually fix what is wrong, even though it looks like some of the problems should be fairly simple to fix once you have found where to fix them. So we are designing tools that help you, and we focus on use by inexperienced programmers. The tools will give them a lot of hand holding, a lot of insight into the existing code and will help them get an idea of what the consequences of changes would be. That is, you can say, “Okay, now I have this code and I think I want to make this change. You tell me where this variable is used elsewhere in the program—what the dependencies are, what code is using this function. Maybe this function isn't being used at all!” Just like in our DNA, there are large pieces of software containing unused code. Nobody noticed it was no longer needed, so nobody bothered to take it out. Now, a section of code looks like the place where your font is being drawn, but it just so happens that a different font library has taken its place.
So, if we get the DARPA funding—that's part of DARPA's expedition into the future—CP4E will cause a lot of excitement in the Python world in the next five years.
Phil: It sounds cool to me. I've taught programming, and basically, I found if people learn Basic as their first language, they are much harder to teach than if they had never learned a programming language.
Guido: Basic is just about the worst language you can teach as a first language.
Phil: But with the death of Pascal, there isn't anything else. Maybe people like me are still employable because schools can't train programmers anymore.
Guido: I was just thinking: you may be a little too old, but you must know the story of all the retired Cobol programmers who are just now becoming instant millionaires by fixing old Y2K stuff? Can you imagine the demand for retired UNIX hackers near the year 2038?
Phil: Yeah, it's the same thing! I've told people, they've asked me, “Well is UNIX Y2K-compliant?” and I said, “No problem at all, but in 2038 I plan on being retired, because it is not going to be a good year for UNIX systems!”
Thanks for telling me about CP4E. Watching it develop should be most interesting.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide