You're already proposing several solutions, as others are as well -- SDL (probably most accessible through PyGame), PIL,
Numeric,
some extensions available through SciPy, and eventually moving into things like PyTables or even lower-level functionality like array or ctypes,
there's also the possibility of coding in C or another compiled language, or using Pyrex. for some easy-Python-integration goodness, or
Psyco which can do some pretty magic stuff in select situations.
No, it's not like MATLAB -- Python is a general-purpose language. If you want MATLAB, then you're looking for a more specialized environment, like SciPy (maybe using iPython to provide a nice interactive environment). As a MATLAB replacement, Python is probably a work in progress.
If you want homogeneous collections with fast transformations, you must do it with somewhat opaque containers like Numeric, where anything that runs inside the inner loops of transformations is written in a very fast language. (Oh, I just remembered Weave)
This is true in Lisp as well, though Lisp has also had compiled forms which are pretty quick.
Anyway, lots of options. Stop complaining and enjoy what you got!
So, is Java really better? I honestly don't know the scientific or image processing domain, so I don't know where Java's at there.
There's a lot of people doing stupid things in Manhattan because there's so many people -- there's lots of people doing everything. Even if the throughput isn't terribly high because of the traffic patterns (I expect expect vehicle-miles driven in Manhattan aren't exceptionally high), because of the density you still will perceive there to be a lot of accidents, because each accident is near such a large number of people.
When you increase the population density I think it is very hard to get an idea of statistical things like accident frequency. Someone might think, say, that there are an exceptional number of homeless people, because they see one every couple minutes. But if they are seeing twice (or more) as many people everywhere, it's only reasonable they'll see more homeless people, and that doesn't mean that there is relatively more in the community. You see lots of traffic, but you notice accidents, and in the same way you might not be aware of the relative frequency of accidents.
I've worked with Firebird a bit (some software I develop supports it), but I'm not quite sure what it offers over PostgreSQL. It's difficult to work with from an administrative level, and not terribly well documented -- certainly PostgreSQL beats it on these terms. In terms of features they are mostly on par, with PostgreSQL supporting some fancy OO features that most people won't use, and Firebird perhaps having a few small features of its own (though few). PostgreSQL has much more momentum -- in large part because it's a historically open source codebase, and the code reflects that development methodology. It's accessible to outsiders and maintainable. Firebird doesn't have this, and I don't know if it will ever be very accessible. Look what happened to Mozilla... (though OpenOffice maybe is doing better?)
Then, just to mix things up, you have SAP DB, which is open source with a very proprietary background, much like Firebird. And probably with a lot of the same problems in terms of administration and code accessibility.
I certainly wish the developers no ill will, or to disparage their efforts -- but I've yet to see the argument for using Firebird outside of legacy projects. It's easy to argue MySQL vs. Firebird, but PostgreSQL is the real competitor.
...and if memory serves me correctly, does O(1) branching and tagging.
I don't think that's very exciting. It's more exciting that it does O(1) copying, including O(1) copying of entire trees. They build branching and tagging on top of that functionality, which is the clever part.
In theory the WebDAV interface could be used in this way, and the filesystem client would be much more general than just Subversion. Unfortunately, there's not generally support for versioning in WebDAV clients (versioning itself is part of another standard which extends WebDAV). While you can use it without the versioning (e.g., with Windows Web Folders, or Mac's WebDAV support), you don't get all the version control goodness, like atomic multi-file commits, log messages, etc.
There is an Explorer extension for Windows, which might be somewhat akin to filesystem support. I don't think you'd need quite as much filesystem support for Subversion, because it handles all the tags and branching in filesystem terms -- a branch or tag is just a copy of the tree (literally copied to another location in the repository), so it's naturally exposed as a filesystem-like interface (unlike, say, CVS, where the branch is a separate concept from the filesystem layout).
Copies and deletes still require tool support, but that can be solved in the UI (e.g., Explorer, Konqueror, Nautilus), instead of at the kernel level.
I've had no problems installing Subversion under Debian. The version currently in there is perfectly functional (I think it's the release candidate), and while it's only in unstable it doesn't bring in many dependencies, and doesn't require a whole upgrade (as well as Subversion having a woody port).
You also don't have to have apache2 or any of that -- svnserve works perfectly well, and ssh access doesn't require any server at all (similar to CVS).
It's also just been revealed that the Chicago Police have been spying on several local peace activist groups, starting in 2002. Previous to 2002, there was a consent decree from a case against the CPD, for their efforts in the 70s and 80s to suppress dissent or the exercize of free speach. The consent decree was recently largely invalidated by a appeals judge, and it was only months before police informants were infiltrating groups. The FBI, which of course has its own similar history (COINTELPRO) also appears to be back in the political-suppression game.
FWIW, the Balkans had as much to do with WWII as with past conflicts. Of course, alignments in WWII reflected alignments in past conflicts, and so on continuing back. Modern analysis of the Balkans has often ignored WWII, because it's an awkward subject and doesn't offer the bias the West would prefer (since our alignment has followed the Nazis).
There's lots of ways to compare conflicts -- obviously there's no objective way to compare the last 60 years to some other point in history. But it doesn't require a stretch of the imagination to appreciate the importance of the wars we have seen since WWII. Lessee... this page says around 8 million died in WWI. Vietnam had around 1 million deaths. That's only an order of magnitude for a huge international war, compared to a more modern single-nation war (that was only diplomatically a police action).
I found this page which gives a lot more statistics for deaths in modern wars and conflicts. The statistics are kind of scattered, but I think that's because the sources are themselves so scattered. Anyway, it offers something more concrete to think about.
eval $string compiles the string to bytecode, then runs it. I'm sure this is how Perl already works, as do most bytecode-based "interpreters". eval would not be available to a runtime that was shipped with bytecode but no compiler -- however, that would be an uncommon deployment (and certainly never the default), and you'd simply have to make sure your code didn't use the eval function in that case.
The most peaceful? What the hell are you talking about? War has been ravaging the world for the last sixty years. Not in the US or (most of) Europe, but elsewhere in the world -- nearly all of Africa, most of South and Central America, South and Southeast Asia have all seen significant conflicts in the past 60 years. Is it more than in the past? It's hard to say -- there's more people and more activity. There's less "war", but that's largely meaningless, it only reflects on modern diplomacy and current definitions of war.
War has a tremendous effect on our world. Every famine you hear about in Africa is caused by war -- not by drought. I think history will identify both halves of the 20th century as times of war, not peace.
BTW, if someone has a cool feature that Ports handle that Debian doesn't, I'm all ears. Or a sticky situation that Ports resolve where Debian can't. Just don't obsess over architecture-specific compiler flags and optimizations, please -- for almost all applications I use, even just ten minutes of my time isn't worth a 5% boost in performance.
I don't really think the BSD ports system has anything on Debian. It's a nice system and all, but Debian is larger and (IMHO) more reliable and usable. Gentoo is similar to BSD, but Debian lets me get stuff done without worrying about source code or compilation at all. (I'm a programmer, but the only source code I want to think about is the code I'm working on)
I agree -- as an example, how do you represent package dependencies? In Debian they are represented as package names. These names are not portable to other distributions and require centralized management to ensure there are no conflicts. And the same goes for version numbers on these packages. You could decentralize it -- say, provide dependencies as URLs -- but that would mess things up as well, because you couldn't indicate conflicts safely, and you couldn't indicate that a package fulfilled a dependency whenthe URLs don't match.
Of course, you could create an ever-growing matrix of compatibility information, mapping packages between different schemes, identifying conflicts and dependencies... but that's obviously unfeasable.
And if you can't deal with those problems, why bother? What makes Debian's all-inclusive, centralized system so great is that it deals with these problems, and there's no way in hell I'm going back to something more primitive and fragile.
Some of these issues can be dealt with architecturally. For instance, making multiple versions of installed packages work in a more friendly way. But this typically requires concerted efforts from the software writers, not the packagers, and it's an ongoing process with no silver bullet. We can work towards it, but if the packaging system is broken for that software that's not there yet, then the packaging software is deficient.
The contrast might not be as great between, say, Kentucky and New Zealand, as opposed to San Francisco and New Zealand. There's a lot of areas where there's a high demand for services -- land costs more, rent costs more, shipping costs more, average wages have to be higher, and it the costs spread out to everything, making for a higher cost of living.
So maybe the US isn't as uncompetitive in some of these things as it might seen, because places like the Bay Area and New York are our "front face", but aren't indicative of the rest of the nation (at all).
Not that there aren't some inefficiencies. We manage to spend more on health care than anyone else (by something like a factor of two, I think), and we get a pretty shitty system out of it. The amount of money we dump into the military -- even on a per capita basis -- is pretty insane as well, and that's pretty much a big waste. But anyway, it's still possible to live a thrifty life in the US, but people have a very hard time cutting back. Once a person increases their income, they seem to forget they ever lived on less or that it's even possible to do so.
* More security flaws than any other distro
[To parent: Really? Please provide links to back that up, I'm interested]
I don't have the numbers, but I think it gets referenced more than any other distribution on several security lists.
Of course, this is because it has more software than any other distribution, and many multiple supported versions of MTAs, web servers, inetds, and so on. So if any piece of software has a security flaw, Debian has a security flaw.
There aren't that many kinds of security flaws that really apply to a distribution in particular, as opposed to the software that it uses -- I suppose if a package was created with the wrong permissions it could be considered a distribution security flaw. I don't think that's a particularly common problem, and most actual Debian systems don't display a large number of security flaws relative to other distros.
It probably also says something about how Apache was installed. If you install from (non-distro) source you are unlikely to get the distro name in your config.
Which maybe means that Debian also has a well-packaged Apache, and people don't feel a need to tweak it. Or the Debian systems are newer, and the compiled-from-source Apache installations are often in systems that date from a darker day in packaging, or a time when there was otherwise more incentive to compile your own Apache. (But it seems like it's been quite a while since it was worth it to compile your own Apache)
It was called Python 3000 -- first as a real idea, then as a haha, yeah we'll do that in Python 3000 kind of way. A sort of Shangra La.
Anyway, now the discussion seems to have shifted a bit more toward the practical, and Guido is talking about Python 3.0 as a real release. It still looks like it's going to be fairly conservative -- which is good for all of us doing real programming in Python -- but some of the stuff like the changed division semantics look like they are going to wait until that release.
Many of the problems you identify -- which I agree can be problems -- are because Python is a language that people use to write real programs, and it has a history and a lot of backward compatibility to provide. So to override len you have to use the magic __len__ method. Is that such a big deal?
Python also isn't a purely OO language, which I think is one of the really important parts of Python. It uses functions a lot, and those functions are often more clear than an OO approach would be. People in Smalltalk spend too much time creating frameworks, and not enough time getting stuff done -- because the language rewards that. Python is not a conceptually clear language like Smalltalk, but it's way more practical as a result. (Not that I don't like Smalltalk -- I really do, but ultimately Smalltalk was too insular for me)
There are issues with Python, but really not that many. join as a string method is annoying, and magic methods seem somewhat arbitrary, but there's no perfect solution there either. Operators aren't methods, and some form of translation is necessary, in C++, Ruby, or Python. Python's translation isn't particularly bad (and once you know the names, it's very transparent).
And Python has the arrogant, Perl-like community now, that thinks jamming list comprehensions and generators into everything makes you "cool".
I'm sorry, but that's just not true. Sure, any group of programmers is going to make a few puzzles or playfully minimal programs, but in the Python community these are generally presented as toys or novelties. Cleverness is not worshipped, and especially not at the expense of clarity and simplicity. This isn't true in the Python standard library, most third party libraries, nor in comp.lang.python.
Of course, people generally ask questions about hard things, because they don't need to ask about the easy things. And some hard things in Python require cleverness, or doing odd things with Python's object model (which is very flexible). Sometimes people want Python to be like whatever language they know best (e.g., C++, Java, Common Lisp, etc), and so people come up with mechanisms to do what they want (and then usually append "but that's not the Pythonic way to do it" and present a clearer way to get the same effect).
The Python Cookbook didn't amaze me either. I'm not sure what would have -- the best documentation is not needing documentation at all, and for what the Python Cookbook covered I didn't really need documentation.
Ditto! The keyboards are compact and symmetrical (no stupid number pad hanging off the right), they are really good for typing accuracy (which is very important as a programmer), they are good for RSI, they are Linux-friendly (since they don't really require any special drivers -- all programming is done independent of the keyboard), you can use them in your lap (or not), and they keep people from messing with your computer;)
I'm of the strong suspicion that the Strategic Defense Initiative is really a (thin) cover for the militarization of space as well. The idea of effective SDI is rather absurd... so maybe it's just a way to funnel off money to corrupt defense contractors. But if it was, why would other countries care? We wouldn't be wasting their money. I think they care because we'd be putting large weaponry into space, and because while missiles are very hard to hit, there are many other targets that could be hit from space. Is it really all that far off to imagine assassination from space? We probably have the spy satellites to sufficiently identify and target someone from space, we just need the weapon to fire.
So, I'm not surprised that this would be another attempt to militarize space. However, it is not inevitable. Maybe the spy satellites are inevitable, maybe conventional weapons proliferation is inevitable, but there's nothing predetermined about putting offensive weaponry in space. An offensive satellite isn't something that happens without a huge amount of infrastructure. It's not something that happens in secret -- even if the US wants to do it, we still have to make up a story (this case in point).
A firewall only seems to make sense when your right hand doesn't know what your left hand is doing. In a multiple-computer setup this can often be the case, of course -- especially with computers running Windows where even if you do know what you're doing you're not necessarily empowered to fix it. But with a single machine, where you have complete control, what does a firewall accomplish? So that user programs can't set up high-port servers (e.g., something on 8080)? I just don't get it.
Hell, on a Debian system you should be able to mostly accomplish the same thing with a virtual package that conflicts with all "unnecessary" servers.
Slashdot Mirror
No, it's not like MATLAB -- Python is a general-purpose language. If you want MATLAB, then you're looking for a more specialized environment, like SciPy (maybe using iPython to provide a nice interactive environment). As a MATLAB replacement, Python is probably a work in progress.
If you want homogeneous collections with fast transformations, you must do it with somewhat opaque containers like Numeric, where anything that runs inside the inner loops of transformations is written in a very fast language. (Oh, I just remembered Weave) This is true in Lisp as well, though Lisp has also had compiled forms which are pretty quick.
Anyway, lots of options. Stop complaining and enjoy what you got!
So, is Java really better? I honestly don't know the scientific or image processing domain, so I don't know where Java's at there.
Maybe they would have if Darl had given lots of money to the Democratic party. (Or maybe not) It all reminds me a little of Nixon, though...
When you increase the population density I think it is very hard to get an idea of statistical things like accident frequency. Someone might think, say, that there are an exceptional number of homeless people, because they see one every couple minutes. But if they are seeing twice (or more) as many people everywhere, it's only reasonable they'll see more homeless people, and that doesn't mean that there is relatively more in the community. You see lots of traffic, but you notice accidents, and in the same way you might not be aware of the relative frequency of accidents.
That's the life of a sharecropper.
Then, just to mix things up, you have SAP DB, which is open source with a very proprietary background, much like Firebird. And probably with a lot of the same problems in terms of administration and code accessibility.
I certainly wish the developers no ill will, or to disparage their efforts -- but I've yet to see the argument for using Firebird outside of legacy projects. It's easy to argue MySQL vs. Firebird, but PostgreSQL is the real competitor.
There is an Explorer extension for Windows, which might be somewhat akin to filesystem support. I don't think you'd need quite as much filesystem support for Subversion, because it handles all the tags and branching in filesystem terms -- a branch or tag is just a copy of the tree (literally copied to another location in the repository), so it's naturally exposed as a filesystem-like interface (unlike, say, CVS, where the branch is a separate concept from the filesystem layout).
Copies and deletes still require tool support, but that can be solved in the UI (e.g., Explorer, Konqueror, Nautilus), instead of at the kernel level.
You also don't have to have apache2 or any of that -- svnserve works perfectly well, and ssh access doesn't require any server at all (similar to CVS).
Some coverage: Chicago Police case, Google News on the recent Iowa/Drake U thing
There's lots of ways to compare conflicts -- obviously there's no objective way to compare the last 60 years to some other point in history. But it doesn't require a stretch of the imagination to appreciate the importance of the wars we have seen since WWII. Lessee... this page says around 8 million died in WWI. Vietnam had around 1 million deaths. That's only an order of magnitude for a huge international war, compared to a more modern single-nation war (that was only diplomatically a police action).
I found this page which gives a lot more statistics for deaths in modern wars and conflicts. The statistics are kind of scattered, but I think that's because the sources are themselves so scattered. Anyway, it offers something more concrete to think about.
eval $string compiles the string to bytecode, then runs it. I'm sure this is how Perl already works, as do most bytecode-based "interpreters". eval would not be available to a runtime that was shipped with bytecode but no compiler -- however, that would be an uncommon deployment (and certainly never the default), and you'd simply have to make sure your code didn't use the eval function in that case.
War has a tremendous effect on our world. Every famine you hear about in Africa is caused by war -- not by drought. I think history will identify both halves of the 20th century as times of war, not peace.
BTW, if someone has a cool feature that Ports handle that Debian doesn't, I'm all ears. Or a sticky situation that Ports resolve where Debian can't. Just don't obsess over architecture-specific compiler flags and optimizations, please -- for almost all applications I use, even just ten minutes of my time isn't worth a 5% boost in performance.
I don't really think the BSD ports system has anything on Debian. It's a nice system and all, but Debian is larger and (IMHO) more reliable and usable. Gentoo is similar to BSD, but Debian lets me get stuff done without worrying about source code or compilation at all. (I'm a programmer, but the only source code I want to think about is the code I'm working on)
Of course, you could create an ever-growing matrix of compatibility information, mapping packages between different schemes, identifying conflicts and dependencies... but that's obviously unfeasable.
And if you can't deal with those problems, why bother? What makes Debian's all-inclusive, centralized system so great is that it deals with these problems, and there's no way in hell I'm going back to something more primitive and fragile.
Some of these issues can be dealt with architecturally. For instance, making multiple versions of installed packages work in a more friendly way. But this typically requires concerted efforts from the software writers, not the packagers, and it's an ongoing process with no silver bullet. We can work towards it, but if the packaging system is broken for that software that's not there yet, then the packaging software is deficient.
So maybe the US isn't as uncompetitive in some of these things as it might seen, because places like the Bay Area and New York are our "front face", but aren't indicative of the rest of the nation (at all).
Not that there aren't some inefficiencies. We manage to spend more on health care than anyone else (by something like a factor of two, I think), and we get a pretty shitty system out of it. The amount of money we dump into the military -- even on a per capita basis -- is pretty insane as well, and that's pretty much a big waste. But anyway, it's still possible to live a thrifty life in the US, but people have a very hard time cutting back. Once a person increases their income, they seem to forget they ever lived on less or that it's even possible to do so.
Of course, this is because it has more software than any other distribution, and many multiple supported versions of MTAs, web servers, inetds, and so on. So if any piece of software has a security flaw, Debian has a security flaw.
There aren't that many kinds of security flaws that really apply to a distribution in particular, as opposed to the software that it uses -- I suppose if a package was created with the wrong permissions it could be considered a distribution security flaw. I don't think that's a particularly common problem, and most actual Debian systems don't display a large number of security flaws relative to other distros.
Which maybe means that Debian also has a well-packaged Apache, and people don't feel a need to tweak it. Or the Debian systems are newer, and the compiled-from-source Apache installations are often in systems that date from a darker day in packaging, or a time when there was otherwise more incentive to compile your own Apache. (But it seems like it's been quite a while since it was worth it to compile your own Apache)
Anyway, now the discussion seems to have shifted a bit more toward the practical, and Guido is talking about Python 3.0 as a real release. It still looks like it's going to be fairly conservative -- which is good for all of us doing real programming in Python -- but some of the stuff like the changed division semantics look like they are going to wait until that release.
Python also isn't a purely OO language, which I think is one of the really important parts of Python. It uses functions a lot, and those functions are often more clear than an OO approach would be. People in Smalltalk spend too much time creating frameworks, and not enough time getting stuff done -- because the language rewards that. Python is not a conceptually clear language like Smalltalk, but it's way more practical as a result. (Not that I don't like Smalltalk -- I really do, but ultimately Smalltalk was too insular for me)
There are issues with Python, but really not that many. join as a string method is annoying, and magic methods seem somewhat arbitrary, but there's no perfect solution there either. Operators aren't methods, and some form of translation is necessary, in C++, Ruby, or Python. Python's translation isn't particularly bad (and once you know the names, it's very transparent).
I'm sorry, but that's just not true. Sure, any group of programmers is going to make a few puzzles or playfully minimal programs, but in the Python community these are generally presented as toys or novelties. Cleverness is not worshipped, and especially not at the expense of clarity and simplicity. This isn't true in the Python standard library, most third party libraries, nor in comp.lang.python.Of course, people generally ask questions about hard things, because they don't need to ask about the easy things. And some hard things in Python require cleverness, or doing odd things with Python's object model (which is very flexible). Sometimes people want Python to be like whatever language they know best (e.g., C++, Java, Common Lisp, etc), and so people come up with mechanisms to do what they want (and then usually append "but that's not the Pythonic way to do it" and present a clearer way to get the same effect).
The Python Cookbook didn't amaze me either. I'm not sure what would have -- the best documentation is not needing documentation at all, and for what the Python Cookbook covered I didn't really need documentation.
Anyway, I like mine a lot.
The new USB keyboards come in black and silver, too.
So, I'm not surprised that this would be another attempt to militarize space. However, it is not inevitable. Maybe the spy satellites are inevitable, maybe conventional weapons proliferation is inevitable, but there's nothing predetermined about putting offensive weaponry in space. An offensive satellite isn't something that happens without a huge amount of infrastructure. It's not something that happens in secret -- even if the US wants to do it, we still have to make up a story (this case in point).
You are right. While Debian's one unblinking eye has been gazing steadily on this script, it has ignored all other paths. To shame!
Hell, on a Debian system you should be able to mostly accomplish the same thing with a virtual package that conflicts with all "unnecessary" servers.