Slashdot Mirror
Interview With Python Creator Guido Van Rossum (techrocket.com)
The online programming school Tech Rocket just published a new interview with Guido van Rossum, the creator of Python. "Looking back I don't think I ever really doubted Python, and I always had fun," he tells the site. "I had a lot of doubts about myself, but Python's ever-increasing success, and encouragement from people to whom I looked up (even Larry Wall!), made me forget that."
He describes what it's like being Python's Benevolent Dictator for Life, and says that the most astonishing thing he's seen built with Python is "probaby the Dropbox server. Two million lines of code and counting, and it serves hundreds of millions of users." And he leaves aspiring programmers with this advice. "Don't do something you don't enjoy just because it looks lucrative -- that's where the competition will be fiercest, and because you don't enjoy it, you'll lose out to others who are more motivated."
He describes what it's like being Python's Benevolent Dictator for Life, and says that the most astonishing thing he's seen built with Python is "probaby the Dropbox server. Two million lines of code and counting, and it serves hundreds of millions of users." And he leaves aspiring programmers with this advice. "Don't do something you don't enjoy just because it looks lucrative -- that's where the competition will be fiercest, and because you don't enjoy it, you'll lose out to others who are more motivated."
Because he understands the problem Dropbox is trying to solve better than you do.
He meant to say 2 million functions in one line of code.
We're talking about python, not perl.
#DeleteChrome
What I'm most curious about is why the Python community is so much nicer to deal with than the Rust programming language's community.
In my limited experience in the VFX world it's because people using Python are focused on actually creating usable products that solve people's problems. And I use the word "people" not "developers" in this instance because a lot of them are "non-programmers" solving problems that they themselves face. Python is a tool to them to make their lives better.
I was just talking to an old Co-Worker from a C++ company I worked at a few years back. He asked "So what are you doing lately" and I told him I'm working on my thesis, which is titled "Ruby's a Terrible Programming Language, And You're A Terrible Programmer For Liking It". Then I cited a number of my complaints -- being able to add arbitrary functions to a live object, never knowing where to look for the interface definition of parameter objects, need to extensively test all execution paths of production code (Which no one ever does,) odd syntactic quirks and changes in syntax between language versions. He laughed and said he had exactly the same complaints about Python. You see, Object Oriented Programming was invented to reduce maintenance costs for completed projects, because that's where 90% of your expenses with the project will be. Ruby, at least, and apparently Python as well according to my friend's complaints, were invented to make the cheap part of the development process "easier", while at the same time letting the language fanboys pat themselves on the back about what clever programmers they are. This is exactly the opposite of software "engineering".
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Comment removed based on user account deletion
The Kernel is written in C - a language designed for brevity, while python is much more verbose. ... So the exact same algorithm is likely to use more lines in python than in C
I dunno, YMMV, but to me the opposite seems to pretty much always be the case - for any non-trivial chunk of code, the Python version tends to require far fewer lines than the C equivalent. At several different companies we've ported various C modules to Python and it's common for the Python version to have only 20% (or fewer) LOC vs the C original. The reason is just the usual stuff: Python, being a much higher level language, introduces a lot of overhead but in exchange you get powerful built-in data types and have to do basically zero manual memory management.
This tends to show up in not just large libraries or apps, but even in small chunks of code. For example, below is a function from one of our network monitoring agents; as background, basically there are a bunch of different server clusters and a job monitor spits out an hourly file that lists on each line the IP address of each server and the number of errors it encountered (this is part of some legacy thing we're hoping to replace, it's kind of goofy). Anyway, those files get aggregated to a central monitor, that in turn looks for various conditions and alarms if e.g. the error rates are too high.
Anyway, here's a function that reads those files and tells you which servers are seeing the most errors (it returns a list of server IP address and number of errors encountered, in descending order of number of errors):
def ServerErrorRates(reportFiles):
counts = {} # ip addr --> total errors
for filename in reportFiles:
for line in open(filename):
ip, errors = line.strip().split()
counts[ip] = counts.get(ip, 0) + int(errors)
return sorted(counts.items(), key=lambda x:x[1], reverse=True)
Nothing fancy, but doing that in straight C is likely going to take far more than 7 code statements. There's just no way to perform the same work in C in anything close to 7 statements. It's not a knock on C, the two tools are just optimized for different things.
As another example, I just took a peek at our HTTP server library. The whole thing is a single file of less than 800 LOC, and that handles all HTTP request/response handling including header reading/writing, file uploads, cookies, websocket support, request routing, etc., etc. without using any of the HTTP stuff from the Python standard library. The C equivalent would certainly be several times as many lines of code.
I think you could maybe argue that individual statements in Python are more verbose than C, but it's common for each Python statement to be the equivalent of several C statements (and/or many statements in C are simply not required in Python), so on the whole Python programs end up being way more concise. Occasionally I'll see an exception, but it's just that - an exception.