Slashdot Mirror
Guido Goes Google
revividus writes "It seems that Python creator Guido van Rossum has received an offer from Google, and accepted it. Here is also some confirmation."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
So is google becoming the new Xerox Parc?
This is a well-founded assumption. Much of Google's internal development is done in Python. Thus, it is important that Python development continue quickly and continue in a direction that benefits Google. They cannot risk that Guido find himself unable to afford to continue as Python project leader.
No, they are most certainly hiring Guido to continue Python development. It would be a disaster for Python, and thus for Google, if they diverted his talent toward some random Google project.
AJAX is working for Google fairly well right now, but it's probably not an end-all answer. Javascript is fine for writing small apps, but it's not that great of a language. And even with the distance diminishing between browsers, it's still a pain to write cross-browser code. One of the great accomplishments I've seen of javascript (besides maps.google) is the FCK editor, but even that can be slow, and takes large amounts of memory.
Looking ahead, I suspect Google knows that Javascript will eventually have to dumped. M$ already has an answer, .net. They have their browser, and they can afford not to have to worry about being cross-platform.
In the end, the web browser is not a great for doing things besides browsing the web. On top of that, with EOLAs legal suit against embedded applications, full fledged internet apps seem to be the only way to go. If Google is to survive, they need the tools and framework in order to deploy such apps.
No, we would call it static typing. The "strength" of the type system is orthogonal to the time when the checks take place (and often a poorly defined concept).
Hasn't Perl already done 80-90% of that for years?
Perhaps I omitted having a sane syntax. ;-)
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I think this flaw means that Python cannot really compete with Java or C# on big server systems.
.so from it except with per-object locks instead of using the GIL.
You mean like Google? Oh wait...
It really depends on what you're doing. If your process is I/O bound, Python is just as fast. If your process is CPU bound, and the work you are doing is in pure Python code (i.e. not a Python library implemented in C, such as for text or image processing, which is fast -- remember Python is largely implemented in a compiled language underneath), then it won't matter that there's a GIL because it will be too slow anyway!
If you ARE calling out to external C functionality, you can release the GIL in the C code as long as you aren't mucking with Python objects inside it (e.g. release GIL, do a bunch of calculations, then get GIL and return Python object).
If you are using C objects and just want Python to control it, you can embed Python into C, and then just use a small number of C functions for synchronized object access (mutexes, etc.). Then you can have multiple C threads each with their own Python instance, and the Python code can chug along and just make the calls to the C locking/unlocking before modifying whatever C objects you want. Essentially you just make your own http://docs.python.org/lib/module-Queue.html in C and use that for access. You can also use multiple processes and shared memory. You could probably extend this to Python objects too, by making them "external", basically copying the underlying C implementation code and making a new
For what you're worried about, there is a much smaller subset of problems that would be fast enough in Python EXCEPT for the GIL. Usually the interpreter speed is the issue -- there aren't too many situations where running 1/20th the speed of C is too slow but 1/10th is acceptable (due to a second CPU).
You have to document the function arguments. Static typing doesn't change that, it just hides some of the most immediate problems from not doing so. (An int still needs documentation saying what values it can have). I feel dynamic typing is such a timesaver and improves flexibility so much that its benefits outweigh the costs. But whatever works for you.
I am trolling
Usually the first saying is applied when someone has decided on the language, say C, and on their hardware. But when programming, instead of thinking of the algorithm and how to correctly write it, they think about how many registers can they use at the same time first and start with inlining of assembly code. I think though, that the same principle can be applied to the choice of language and hardware. In this the mistake would be to choose a lower level language just because of speed, even though the problem can be solved _much_ faster (in terms of developing time) in a higher level language.
For example I had to write a little project to process text (about 2 million articles including some pdf files) then to do some scientific computation and finally design a reasonable GUI. The languages I new were C/C++/Java. I started with Java but I realized the project was just going to slow. I new what I wanted to get done, it is just it took a long time to write in Java. I looked around and tried a number languages Ruby, Perl, Python, even Matlab, tried to move some of the processing into MySQL as stored procedures. The best choice was to switch to Python. I didn't know Python at all but within a week I was fairly proficient with it. It is just as good of a OO language as Java and comes with a good set of supporting libraries. My project took about a couple of months and I wrote it in about 10K lines. I am estimating but I think I would have taken me twice as long to write it in Java and it would have been at least 15K or more lines long. The added problem with more code for the same problem is support and quality control. I can browse much faster through a 10k lines than through 20K lines to look for a bug or to some refactoring.
But all this doesn't mean that everyone, including you, should switch to Python immediately and drop C and C++. I acknowledge that Python is slower on average that other compiled (even JIT compiled) languages and some domains of application require speed most of all. As it turns out though, it is usually a vrey small part of code that needs to be sped up. In other words it is the good 'ol 80/20 rule (80% of the time the program is in the 20% of the code). What this means is that you could write the project faster in a higher level language like Python then choose certain critical part of your code (this requires having a head on the shoulders to know which parts are those and to know a little about algorithmic complexity O(n) stuff...) and optimize just that. This can be done beautifully in Python. As of now there at least 2 methods to do it: you can inline C code in Python using weave (hosted on the SciPy project page) or you can use a language extension to manipulate C data in Python using Pyrex. (I know there are other, but these are the most stable ones I think). I will use weave to inline some C code to speed up some of the computation. The result actually might be _faster!_ than Java.
In the end it all comes down to cost analysis, because you have a trade-off: for example, you can pay your developers twice as much and expect to pay twice for support and patches and have them develop in Java or you can achieve the same speed by allowing them to use Python (if they are smart enough they'll know how to optimize the critical regions after the program is runnig correctly) and you can buy extra(newer) hardware to compensate for the constant speed difference. If they can both optimize their Python code with C (in the end!) and buy faster hardware you might get a double benefit. But, of course, it is up to you (the company) to decide.