Guido and Bruce Eckel Discuss Python 3000 305
Phoe6 writes "Leading author and programmer, Bruce Eckel, posted some of his concerns on Python 3000 stating that the Python community is failing to address some of the important issues with this major, backward incompatible release. Problems he mentions are concurrency support on multi-core CPUs, easy deployment support, and a standardized user interface, amongst others. He expresses his dissatisfaction at the post titled "Python 3K or Python 2.9?. Guido van Rossum addresses the concerns in a very pragmatic way with his response to Bruce Eckel and calls for more developers to contribute to Python to improve it further. Bruce Eckel concludes with his thoughts that he wants his favorite language to be better with his reply to Guido's reply."
Re:Bruce, Just a Make a New Language Then (Score:4, Insightful)
While I agree, if he wants something that's fundamentally incompatible, but wants to still call it Python, that's silly.
On the other hand, they're saying 'We need more devs to work on Python' and pushing people away that -care- is exactly the opposite of that. If they want new devs, they'd better be resigned to the fact that the newcomers WILL have a different vision, just as this guy does. Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible. You have to pay people to make them go through pain like that. (Coding in someone else's style is just as hard as painting in someone else's... Initially it's almost impossibly hard, and it gets easier with time... And there's always the alternative of working on something else without all that pain.)
documentation (Score:2, Insightful)
BS argument (Score:5, Insightful)
Re:Bruce, Just a Make a New Language Then (Score:4, Insightful)
Good point! Managing developers is hard enough in a company where the devs are paid. Managing volunteers is much, much harder. I strongly believe that half of the success of many open source projects is not the brilliant ideas or the super cool code, but the personality of the lead developer. Linus and Guido have proven to be such personalities that managed to galvanize hoards of developers around them. That is quite impressive. How many managers out there would be able retain employees without any pay?
One distinctive feature of these open source project leaders is that they have to act like assholes sometimes. I proves that they are tough, have a vision and won't budge. At first it seems counter-intuitive that being disagreeable will accomplish more but it works because even if it pushes one developer way, it might attract others or make the ones who are left work harder. It's like a medieval army. Decimating 1% of the army is worth it because it will make the other %99 percent work harder.
Re:documentation (Score:3, Insightful)
i dunno, every piece of documentation is just a starting point. I only use docs.python.org to find a suitable module and then just look around it in IPython shell (import module; module. etc.).
As for PHP.net, it's full of buggy, halfassed examples written by morons and more often push you wrong way than not.
both are right, sort of (Score:5, Insightful)
But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
Re:Syntactic whitespace (Score:5, Insightful)
Those aren't the real problems with Python (Score:5, Insightful)
Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.
Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.
One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.
The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so. Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.
The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
Why do people pile on Guido (Score:3, Insightful)
He's not that different from Linus. He does things in ways that some people seem to really dislike. When they complain, he doesn't mind. "Tough cookies." I guess when Linus does it, it's a noble independent spirit, when Guido does it he's being an asshole.
I use Python as a test, actually. Hating the language is okay by me, we've all got tastes. Lucky for you, we don't write our code in Python so you won't suffer. But saying you hate it because of enforced whitespace? That fails your interview, right there. Ohhhh boy. You've got a problem with having to make things line up the way their supposed to? Just wait until you hit some actual PROJECT REQUIREMENTS.
Strange Guido's reply (Score:4, Insightful)
- using whitespace for indention remove 'visual noise' at the cost of 'language magic'
- using self adds 'visual noise' with the (dubious IMHO) benefit of language 'simplicity'.
IMHO removing self would be a big plus for Python, sure self makes things more explicit but if developers really wanted to use explicit language, they would stay with C instead of using Python, Ruby..
Re:losing the print statement (Score:1, Insightful)
Why? I was a Python programmer for 3 years, and the print statement was one of the most obvious warts.
I think the dumb simplicity of python's print statement is one of my favourite python things. It makes the language friendly (and I am a pepper-print debugger).
Is print("hello, world") unfriendly? I don't see why. Plus, if you're new to the language, it'll save a lot of explaining later when you ask "Why do I not need parens for print?".
There needs to be tools that are %100 reliable that can convert code from 2.6->3.0.
In general, it's impossible to convert code from one language to another 100% reliably, unless the differences are truly trivial. And if the differences between 2.6 and 3.0 were truly trivial, there'd be no reason to break compatibility and call it "3.0".
Otherwise, there will just be too much code mass, and it will take a long long time for 3.0 to be accepted. Such a stall is bad news for an OSS project.
Oh darn? It's happened before, and they lived. I'm sure Guido would be interested in your ideas on how to run a successful open-source language implementation, 'mathgenius'.
Re:documentation (Score:3, Insightful)
There are a few under-documented libraries that I've run into before, but largely I've been happy with the python docs.
I could swear you were talking about Ruby, because that's exactly the way I feel about Ruby (a language I love, but the docs are disorganized, decentralized, and generally poor).
Re:Bruce, Just a Make a New Language Then (Score:3, Insightful)
Also, his main goal, changing the language to be more productive on multi-processor systems, is an extermely valid one in a "design for the future" sense. Right now it makes marginal sense, but multi-core & multi-processor systems are becoming more common...and the predictions is the trend will not only continue but intensify.
OTOH, I've seen arguments that a data-flow architecture is inherently better suited for that environment, and I've seen at least one decent language to program in that was data-flow. (Prograf. It showed up for the Apple][ lc, which only had one processor and not threading capability to speak of. It died attempting to transition to MSWind95. It had problems as well as a lot of promise.)
Perhaps Python could add a dataFlow library? The library would need to be coded in C or some such (C is traditional for Python libraries). Perhaps it would need to be an "along side" langauge, like Pyrex. That would tend to have the problem of never having the syntax match that of Python...quite, but there might be compensatory advantages.
At all events, I'm not sure HOW the problem should be solved, merely that it NEEDS to be solved. And this is the reasonable time to address any necessary changes.
P.S.: I also agree that threads, and processes that are handled like threads, are an inappropriate solution. This doesn't mean that I know what the best solution is, merely what it isn't.
N.B.: This is a more than trivial problem, because of all the different levels of parallelism that are out there. Some of them don't HAVE any shared ram. (Think computer clusters.) Some of them have LOTS of shared RAM (think multi-core machines). Some don't share cache ram, but share system ram (multi-processor). And a good solution will need to handle these cases transparently. When you write on one system, you can't be expected to know the environment in which you'll be running. (Perhaps clustered computers could be split out to be handled separately. Those who are running computer clusters are still expected to be knowledgeable at the hardware level.)
Re:losing the print statement (Score:4, Insightful)
Interesting. Where other languages have print statements that do exactly what you tell them, Python's print statement has at least two ways of adding unexpected characters. Not what I'd call "dumb simplicity".
While most experienced programmers can predict what a print statement will output, they won't be able to do this with Python's
print "Hello, World!" # One extra character is added here.
print "Hello", "world" # Two extra characters are added here.
print "Hello", # Guess how many extra characters are added here? Hint: not zero.
Quiz:
* How can you use Python's print statement to print some text without a newline? No fair firing up the interpreter!
* Name three languages whose print statement only prints characters that the programmer explicitly passes to it.
Re:losing the print statement (Score:2, Insightful)
Instead of:
>>> print "Hello World!"
you now have to do
>>> print("Hello World!")
just two extra paretheses, and no more of this >> stuff.
Re:Why do people pile on Guido (Score:3, Insightful)
Not if you tell the language what size tabs you're using, it can't. Or just stick to the standard of 8 spaces. Or use an editor which has whitespace normalization, or whitespace character display. Sure, it's a problem if you're trying to use the tools wrong. But if you stop trying to fight it and go with the flow you'll be fine.
Re:Bruce, Just a Make a New Language Then (Score:3, Insightful)
You know, I said something similar to this about Larry Wall, Perl, and Perl 6.
Performance... CPU vs Programmers (Score:3, Insightful)
Python is slower than C, C++ and Java... Guess what? So are PHP, Ruby, Perl, and every other interpreted language.
However, if it takes me 10 programmer hours to create a python program (or PHP, Ruby, Perl) program, and the program takes 10 seconds to process 50,000 records from my database while the C version of this program takes 500 programmer hours and takes 1 second to process 50,000 records.... how long does it take before the C program is faster?
about 9.8 billion records... well, at our current rate of record growth, I'll be there in about year 2500, even assuming 50% growth/yr (completely unsustainable for any enterprise past 10 years) its still 2100 before the time saved by the program equals the time saved on programming time... Not to mention CPU time costs less than 1 cent/hr, and programmers are much more expensive.
And for the record, we have done this. We recently re-wrote a C application in python, the original application took 5 programmers 3 years to create, we recreated it in python with 2 programmers in 6 months, it is feature complete vs the C implementation, it is slower, but not outside of what would be considered reasonable. We also haven't even tried to optimize it at all... which we could do and probably at least get 10-20% improvements in performance.
Now, in saying this am I saying interpreted languages are the answer to every problem? No! Sometimes, you need C, sometimes there are problems that can't be solved well in any specific language. If there was a be all end all language, we'd all be using it. Python, Perl, PHP, and Ruby all have their place, in general I prefer Python because I find it much more intuitive than Perl, I find generally better programmers advertising Python jobs than advertising PHP jobs, and I just like it better than Ruby