Well, it seems to be what companies want, so it looks like PHP is bound for "success",
Sure, the same companies that have gaping security holes and lose your credit card numbers to hackers. The fact that there is a lot of stupidity out there shouldn't give people an excuse to contribute to it.
and languages like LISP are frowned on by CEO's.
Yes. Lisp was a hacker language that got adopted from the bottom up, then it was overhyped and oversold. And when it turned out to be not so great in real-world software projects, it got dropped. And it was features like "eval" and poor scoping rules that made Lisp such an incredible mess.
And that's pretty much the same path that PHP is following: the same reliance on poorly thought out primitives and scoping rules, the same kind of "we can hack it together somehow" mentality. The only question is whether PHP will learn from history and clean up its act before it gets a bad reputation or whether it will be "frowned on" by CEOs as well when their projects start falling apart.
But you could do the same thing with eval. One just sends it a string to evaluate for each compare:
No, you cannot do "the same thing". The code you wrote does something entirely different. In fact, it may well open up a gaping security hole.
Like I said, such techniques may not be technically superior to closures, but they are conceptually easier for most programmers,
Closures were in Pascal, for God's sake, one of the simplest teaching languages ever used. Pascal was trivial compared to the complexities of PHP.
and situations where closures are used are perhaps not common enough to justify the extra learning curve.
There is no learning curve--you just don't have to know about them if you don't want to know about them.
Closures appear to scare people away. I am just the messenger. It is an observation about human behavior, not so much technology.
What it is is an observation about is the state of the PHP community and the PHP implementors. And that, frankly, scares me away from PHP, and it should scare anybody else away, too, because that state of mind and skill level is bound to result in poor software quality and lousy security.
Google has become so flooded with internet crap that it's quickly losing its status as a useful tool. Google needs some form of moderation to move out the superfulous blog entries and advertising fronts so it can someday become as useful as it always was.
Ah, right. Then the various zealots that you already get on Slashdot can moderate pages they don't like out of existence. You know, the people who have a pet platform and will call anybody a "Troll" that is critical of their pet platform.
This really isn't a big deal and it happens all the time when building large systems. I don't know how their system works specifically, but you just change the transient in-memory representations to 64bit by recompiling, and for the on-disk stuff you create a new format using 64bits but still recognize the old format. That way, you have to convert nothing and you will be migrating to 64bit representations as needed. I'm sure Google has managed to deal with much more complex engineering problems than that.
It's probably not you personally, it's that the game industry isn't innovating much. Many games that are coming out are just graphically nicer versions with basically the same gameplay as older games. They still succeed in the market because a new generation picks them up as their first exposure to the genre, but to you, they naturally seem boring.
Furthermore, many computer games are not very replayable. How often can you play through the single player versions of even a comparatively good game like Half Life before you know all the tricks and "surprises"? A humble little game like Frozen Bubble or Alchemy, or a game like Nethack, for that matter, has much more replayability than any fancy single-player FPS. And, of course, with games like Chess and Go, you keep learning as you play them, which is why many people can play them their whole life and not get bored.
Long term success with games means creating games that are replayable and innovating; the mainstream game industry doesn't know how to do that--they just lose themselves in ever more graphics technology.
Closures improve things every time you pass a function/method as an argument to another function/method. The reason is that they make it clear which environment the function argument is going to be evaluated in.
They also happen to let you nest functions in the obvious way, as in:
That simplifies code significantly and removes the need for global variables that can get trashed in unexpected ways.
It's not that this is a hugely important feature, it's that closures are obviously the right thing to do and they are so easy to implement that there is no reason to stick with the current system. The only impression that the current language design gives is that its authors are somehow afraid of doing the right thing because they don't know quite how to implement it or what it means.
But how is keeping the display and chorded-keyboard apart going to keep it from being patentable?
Because Bluetooth keyboards and Bluetooth HMDs already exist; what would there be to be patented?
The main patents they can have on the DataEgg is the precise chording and design patents.
And what is really wrong with it being patentable? I understand being pissed off at abuse of the patent process, but shouldn't it be more important that it works well than that no one is patenting it?
For a data entry method, it is indeed important that it not be patented. It takes years to get really fast at any data entry method; do you want to spend years learning something only to put yourself in the dependency of a single vendor?
The other thing that is wrong with it is that there is nothing innovative about one-handed data entry devices. You have one already, one that millions of people use every day to enter information with one hand: your cell phone. For historical reasons, it uses a less convenient keyboard layout, but that's all.
I mean, if its so non-unique that its not patentable, then is it really going to be useful to anyone.
Let's see. Toilet paper isn't patentable, and I would guess that it is indeed really useful to almost everybody. Maybe there are just a few counterexamples to your statement?
Another chorded one-handed input device, like we didn't have enough of them already.
What would be nice to have would be a chorded one-handed keyboard with Bluetooth. A small display would then go into the glasses or into a wrist watch. That's a much more convenient arrangement than putting everything into a single "data egg" (with a proprietary and patented layout to boot).
You should realize that some branches of linguistics have notions about how language and the brain are related that are not exactly shared by many cognitive scientists. So, when Harrison says something like, "each language lost leaves a gap in our understanding of the variable cognitive structures of which the human brain is capable. Studies of different languages have already revealed vastly different ways of representing and interpreting the world", take it with a grain of salt. Language loss is regrettable for many reasons, but cognitive science would probably continue to do just fine even if we only had a dozen different languages around the globe.
The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context.
Closures aren't "used for anything", they just give the language straightforward and sensible semantics, as opposed to the mess that results when you name functions by strings, like PHP does.
Although they may not be as "clean" as pure closures, eval and execute are conceptually simple and will do the job for the occassional times dynamic execution is needed.
What does dynamic execution have to do with resolving variable references correctly?
Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it":-)
Actually, if you are talking about impressions, the main impression the current language leaves is that the PHP language designers just don't know what they are doing. There is no conceivable technical or practical reason for not implementing lexical closures correctly.
The matter is that (1) you are referring to functions by their name, not as an object, and (2) that you can only write functions that refer to global variables.
Maybe I'm missing something, but it seems defining the function inline makes the code less readable,
Lexical closures have nothing to do with whether the function is written in-line or not. It has to do with functions being data objects rather than strings, and it has to do with variables being resolved correctly.
Does every little scripting language have to repeat the same mistakes? Lisp 1.5 thought it could get by without. Perl did. Python did. Lua did. In the end, they all added them.
Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.
Not really, actually I have had the opposite experience with Solaris running much better on desktop sparc machines than linux.
Well, SPARC hardware isn't exactly mainstream software for running Linux or GNU utilities anymore.
Also most of the software out there that can be compiled in linux can also be ported over Solaris with minimal grief.
I have lived with Solaris and Linux side-by-side for a few years. It's wrong to say that "most" software can be ported over [to] Solaris with minimal grief; the fact that it requires any porting at all is already a lot of grief. Even for software using autoconf, compiling on Solaris fails frequently.
And I do not particularly feel like spending 2 days compiling in order to have a stable machine.
So, why do you tell people that it's a good idea to run Solaris and then spend days recompiling all their favorite GNU or Linux software? Because that's what it amounts to: every Solaris machine I have ever used, I had to spend days installing GNU software on it because it came with so little, and what it came with was usually far inferior to the OSS equivalents.
A solaris install with the extra software CD provides most of the functionality than a linux install. But if you like linux by all means go and use it. Saying that linux is somehow better or makes more sense than solaris just because is just plain dumb.
Spending money on SPARC hardware seems "plain dumb" to me, given its price/performance ratio, in particular if you are going to run Linux anyway.
in the solaris shop we had a dramatic failure of a storedge sena array. i called the sun support line and a guy in tweed jacket was at my door in 40 minutes with a grocery bag full of spare parts (gbic cards, if you care). the problem was solved in a total time of one hour.
And if you had bought Linux machines for the same amount of money, you could have bought so many extra machines that you could have just pulled that machine, dumped it in the trash, and gone on merrily with your work.
in the linux shop i made a web support request for a very simple question (that being: is stronghold bundled with rhel es like the marketing material says? it doesn't seem to be... anyone know?).
Well, how much money are you paying RedHat? Anywhere near what you are paying Sun? Even within two decimal orders of magnitude? I suspect not. For what you are paying Sun, you could get stellar Linux support if you wanted to. But somehow, you have concluded that it's OK to pay a lot of money to Sun for service, but that it's not OK to pay a lot of money for Linux service.
Also consider yourself lucky that you have not experienced Sun at their worst yet: yes, they, too, sometimes have less than stellar service even though you pay them a bundle.
By using run-time optimizations, it might be possible for code written in a high-level language like Python to actually run faster than C code. That's still a long ways away, though...
Not realistically given Python's semantics. People didn't even manage to do it for Smalltalk or Self, languages with much simpler semantics.
The best stab at making dynamic languages work with comparable efficiency to languages like C/C++/C# is perhaps the Stalin compiler for Scheme, but even it has many limitations.
Furthermore, it's not clear that it's desirable. The static type checking and semantics resulting from value classes and other C# features are actually in and of themselves desirable.
Sun's JVM/JIT is about as fast as it's going to get. The remaining possible optimizations are in areas like libraries (there is a lot of room in Swing on X11) and startup times (shared libraries). But as far as raw performance is concerned, Java's performance is limited by the specification of the JVM; for example, if the Java byte code can't express value classes, the JVM can't implement them efficiently.
The Mono JIT is fairly feature-complete (generics are still missing); adding the remaining features will not slow it down. In the end, there is no reason for the Mono JIT to work any slower on the subset that is equivalent to the JVM, and it already runs rings around Sun's JVM for the features that the JVM doesn't have support for and has to emulate.
it works both ways
on
Cyberchondria
·
· Score: 3, Insightful
I'm not sure what the article is implying. Are they saying that it would be better if people were medically ignorant so that they couldn't talk themselves into having horrible diseases?
Sorry, but I don't buy that. People with anxiety disorders always could go to the library or worry about something else.
But there is real and useful medical information on the Internet. If you worry about your risk of HIV after a sexual encounter, for example, you can find data quickly that lets you assess your risk rationally on the Internet, and that may well reduce more people's anxiety than increase it; in the past, you might have had to go to the library and go through stacks for many hours to find a simple answer, something most non-hypochondriacs would never have bothered with.
Furthermore, doctors themselves are so prone to making mistakes that having access to such a wealth of medical information on the Internet can actually save your life. I think doctors are quite unhappy that they are losing the information monopoly they traditionally enjoyed. Patients are now questioning their judgement, pointing out their mistakes, and generally are more informed. Perhaps that is the real reason why the medical community keeps raising this non-issue.
Is the mono CLR even close being as fast as java or C++?
It's hard to say for sure, but it seems to be getting there. On some tasks, it already clearly beats even the latest JVM hands down because the JVM has some limitations, while on some other microbenchmarks, it does a few times worse. One thing is clear: the Mono CLR is a lot further along performance-wise (and feature-wise) than the Java JVM was after two years in existence.
It's that they have them in places where they wouldn't have a loud conversation with another person at all...very inappropriate places.
Well, why are people complaining about cell phone use in restaurants then? Or walking down the street?
And the ringtones, goddam the fucking annoying ringtones that are constantly going off in any venue where silence and attention are expected. (a lecture for instance)
Now, that complaint, I am completely in agreement with. People should turn off their ringers just about everywhere. But that's an entirely different matter--almost all phones these days have vibrating alerts and do not need ring tones.
With another person, you can talk quietly and not disturb what's going on around you. You HAVE to talk at at LEAST a moderate level on cell phones, often louder than that.
No, you don't. Maybe you think you do, but you don't. A cell phone next to your mouth needs no more volume to talk to than you would use for a normal conversation.
Re:If people used better judgement
on
Cell-Phone Wars
·
· Score: 1
People are allowed to talk face to face in museums and libararys but only when necessary. I would say that a cell call in these places is probably not necessary. This is also true in most really nice restaraunts as most usually keep the volume down unless they get a few too many drinks in them
You've got to be kidding. Museums and nice restaurants are social places; of course, you can talk there (at an appropriate level, with some exceptions for some special museum exhibits that do demand silence). That's the whole point of going.
Libraries are different: they really are for quiet reading and studying, so one should indeed avoid talking there.
What will never happen, but would be awesome, would be for IBM or somebody to pump a load of money into increasing the performace/memory footprint of wxPython. Bring it up to the level of C#.
Sorry, but that can't be done: Python is a nice language, but it is not designed to be compiled as efficiently as C#. If you want C#-like (or C++-like) performance, you need C#/C++-like language features, and Python just doesn't have them.
It's Free and doesn't have all that Java baggage.
So is C#.
The next step to Utopia would of course be a wxQt port...
Why in the world would anybody want to bother? Just use wxX11.
Slashdot Mirror
Well, it seems to be what companies want, so it looks like PHP is bound for "success",
Sure, the same companies that have gaping security holes and lose your credit card numbers to hackers. The fact that there is a lot of stupidity out there shouldn't give people an excuse to contribute to it.
and languages like LISP are frowned on by CEO's.
Yes. Lisp was a hacker language that got adopted from the bottom up, then it was overhyped and oversold. And when it turned out to be not so great in real-world software projects, it got dropped. And it was features like "eval" and poor scoping rules that made Lisp such an incredible mess.
And that's pretty much the same path that PHP is following: the same reliance on poorly thought out primitives and scoping rules, the same kind of "we can hack it together somehow" mentality. The only question is whether PHP will learn from history and clean up its act before it gets a bad reputation or whether it will be "frowned on" by CEOs as well when their projects start falling apart.
But you could do the same thing with eval. One just sends it a string to evaluate for each compare:
No, you cannot do "the same thing". The code you wrote does something entirely different. In fact, it may well open up a gaping security hole.
Like I said, such techniques may not be technically superior to closures, but they are conceptually easier for most programmers,
Closures were in Pascal, for God's sake, one of the simplest teaching languages ever used. Pascal was trivial compared to the complexities of PHP.
and situations where closures are used are perhaps not common enough to justify the extra learning curve.
There is no learning curve--you just don't have to know about them if you don't want to know about them.
Closures appear to scare people away. I am just the messenger. It is an observation about human behavior, not so much technology.
What it is is an observation about is the state of the PHP community and the PHP implementors. And that, frankly, scares me away from PHP, and it should scare anybody else away, too, because that state of mind and skill level is bound to result in poor software quality and lousy security.
See what I mean? You don't even have to name the platform--the people in question already know who they are and react completely predictably.
Google has become so flooded with internet crap that it's quickly losing its status as a useful tool. Google needs some form of moderation to move out the superfulous blog entries and advertising fronts so it can someday become as useful as it always was.
Ah, right. Then the various zealots that you already get on Slashdot can moderate pages they don't like out of existence. You know, the people who have a pet platform and will call anybody a "Troll" that is critical of their pet platform.
This really isn't a big deal and it happens all the time when building large systems. I don't know how their system works specifically, but you just change the transient in-memory representations to 64bit by recompiling, and for the on-disk stuff you create a new format using 64bits but still recognize the old format. That way, you have to convert nothing and you will be migrating to 64bit representations as needed. I'm sure Google has managed to deal with much more complex engineering problems than that.
It's probably not you personally, it's that the game industry isn't innovating much. Many games that are coming out are just graphically nicer versions with basically the same gameplay as older games. They still succeed in the market because a new generation picks them up as their first exposure to the genre, but to you, they naturally seem boring.
Furthermore, many computer games are not very replayable. How often can you play through the single player versions of even a comparatively good game like Half Life before you know all the tricks and "surprises"? A humble little game like Frozen Bubble or Alchemy, or a game like Nethack, for that matter, has much more replayability than any fancy single-player FPS. And, of course, with games like Chess and Go, you keep learning as you play them, which is why many people can play them their whole life and not get bored.
Long term success with games means creating games that are replayable and innovating; the mainstream game industry doesn't know how to do that--they just lose themselves in ever more graphics technology.
They also happen to let you nest functions in the obvious way, as in:That simplifies code significantly and removes the need for global variables that can get trashed in unexpected ways.
It's not that this is a hugely important feature, it's that closures are obviously the right thing to do and they are so easy to implement that there is no reason to stick with the current system. The only impression that the current language design gives is that its authors are somehow afraid of doing the right thing because they don't know quite how to implement it or what it means.
But how is keeping the display and chorded-keyboard apart going to keep it from being patentable?
Because Bluetooth keyboards and Bluetooth HMDs already exist; what would there be to be patented?
The main patents they can have on the DataEgg is the precise chording and design patents.
And what is really wrong with it being patentable? I understand being pissed off at abuse of the patent process, but shouldn't it be more important that it works well than that no one is patenting it?
For a data entry method, it is indeed important that it not be patented. It takes years to get really fast at any data entry method; do you want to spend years learning something only to put yourself in the dependency of a single vendor?
The other thing that is wrong with it is that there is nothing innovative about one-handed data entry devices. You have one already, one that millions of people use every day to enter information with one hand: your cell phone. For historical reasons, it uses a less convenient keyboard layout, but that's all.
I mean, if its so non-unique that its not patentable, then is it really going to be useful to anyone.
Let's see. Toilet paper isn't patentable, and I would guess that it is indeed really useful to almost everybody. Maybe there are just a few counterexamples to your statement?
Another chorded one-handed input device, like we didn't have enough of them already.
What would be nice to have would be a chorded one-handed keyboard with Bluetooth. A small display would then go into the glasses or into a wrist watch. That's a much more convenient arrangement than putting everything into a single "data egg" (with a proprietary and patented layout to boot).
These people rediscovered clustering methods from the 1950's.
You should realize that some branches of linguistics have notions about how language and the brain are related that are not exactly shared by many cognitive scientists. So, when Harrison says something like, "each language lost leaves a gap in our understanding of the variable cognitive structures of which the human brain is capable. Studies of different languages have already revealed vastly different ways of representing and interpreting the world", take it with a grain of salt. Language loss is regrettable for many reasons, but cognitive science would probably continue to do just fine even if we only had a dozen different languages around the globe.
The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context.
:-)
Closures aren't "used for anything", they just give the language straightforward and sensible semantics, as opposed to the mess that results when you name functions by strings, like PHP does.
Although they may not be as "clean" as pure closures, eval and execute are conceptually simple and will do the job for the occassional times dynamic execution is needed.
What does dynamic execution have to do with resolving variable references correctly?
Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it"
Actually, if you are talking about impressions, the main impression the current language leaves is that the PHP language designers just don't know what they are doing. There is no conceivable technical or practical reason for not implementing lexical closures correctly.
The matter is that (1) you are referring to functions by their name, not as an object, and (2) that you can only write functions that refer to global variables.
Maybe I'm missing something, but it seems defining the function inline makes the code less readable,
Lexical closures have nothing to do with whether the function is written in-line or not. It has to do with functions being data objects rather than strings, and it has to do with variables being resolved correctly.
Just think about this snippet for a moment:That's how things should work.
Doing function pointers right isn't hard and the current design only has disadvantages. Why is this still not fixed in the fifth major version of PHP?
Does every little scripting language have to repeat the same mistakes? Lisp 1.5 thought it could get by without. Perl did. Python did. Lua did. In the end, they all added them.
Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.
Not really, actually I have had the opposite experience with Solaris running much better on desktop sparc machines than linux.
Well, SPARC hardware isn't exactly mainstream software for running Linux or GNU utilities anymore.
Also most of the software out there that can be compiled in linux can also be ported over Solaris with minimal grief.
I have lived with Solaris and Linux side-by-side for a few years. It's wrong to say that "most" software can be ported over [to] Solaris with minimal grief; the fact that it requires any porting at all is already a lot of grief. Even for software using autoconf, compiling on Solaris fails frequently.
And I do not particularly feel like spending 2 days compiling in order to have a stable machine.
So, why do you tell people that it's a good idea to run Solaris and then spend days recompiling all their favorite GNU or Linux software? Because that's what it amounts to: every Solaris machine I have ever used, I had to spend days installing GNU software on it because it came with so little, and what it came with was usually far inferior to the OSS equivalents.
A solaris install with the extra software CD provides most of the functionality than a linux install. But if you like linux by all means go and use it. Saying that linux is somehow better or makes more sense than solaris just because is just plain dumb.
Spending money on SPARC hardware seems "plain dumb" to me, given its price/performance ratio, in particular if you are going to run Linux anyway.
Yes, you can get similar functionality for Linux.
From a security standpoint, it's a bad idea. But it markets itself well because everybody thinks that more security features mean more security.
in the solaris shop we had a dramatic failure of a storedge sena array. i called the sun support line and a guy in tweed jacket was at my door in 40 minutes with a grocery bag full of spare parts (gbic cards, if you care). the problem was solved in a total time of one hour.
And if you had bought Linux machines for the same amount of money, you could have bought so many extra machines that you could have just pulled that machine, dumped it in the trash, and gone on merrily with your work.
in the linux shop i made a web support request for a very simple question (that being: is stronghold bundled with rhel es like the marketing material says? it doesn't seem to be... anyone know?).
Well, how much money are you paying RedHat? Anywhere near what you are paying Sun? Even within two decimal orders of magnitude? I suspect not. For what you are paying Sun, you could get stellar Linux support if you wanted to. But somehow, you have concluded that it's OK to pay a lot of money to Sun for service, but that it's not OK to pay a lot of money for Linux service.
Also consider yourself lucky that you have not experienced Sun at their worst yet: yes, they, too, sometimes have less than stellar service even though you pay them a bundle.
By using run-time optimizations, it might be possible for code written in a high-level language like Python to actually run faster than C code. That's still a long ways away, though...
Not realistically given Python's semantics. People didn't even manage to do it for Smalltalk or Self, languages with much simpler semantics.
The best stab at making dynamic languages work with comparable efficiency to languages like C/C++/C# is perhaps the Stalin compiler for Scheme, but even it has many limitations.
Furthermore, it's not clear that it's desirable. The static type checking and semantics resulting from value classes and other C# features are actually in and of themselves desirable.
Sun's JVM/JIT is about as fast as it's going to get. The remaining possible optimizations are in areas like libraries (there is a lot of room in Swing on X11) and startup times (shared libraries). But as far as raw performance is concerned, Java's performance is limited by the specification of the JVM; for example, if the Java byte code can't express value classes, the JVM can't implement them efficiently.
The Mono JIT is fairly feature-complete (generics are still missing); adding the remaining features will not slow it down. In the end, there is no reason for the Mono JIT to work any slower on the subset that is equivalent to the JVM, and it already runs rings around Sun's JVM for the features that the JVM doesn't have support for and has to emulate.
I'm not sure what the article is implying. Are they saying that it would be better if people were medically ignorant so that they couldn't talk themselves into having horrible diseases?
Sorry, but I don't buy that. People with anxiety disorders always could go to the library or worry about something else.
But there is real and useful medical information on the Internet. If you worry about your risk of HIV after a sexual encounter, for example, you can find data quickly that lets you assess your risk rationally on the Internet, and that may well reduce more people's anxiety than increase it; in the past, you might have had to go to the library and go through stacks for many hours to find a simple answer, something most non-hypochondriacs would never have bothered with.
Furthermore, doctors themselves are so prone to making mistakes that having access to such a wealth of medical information on the Internet can actually save your life. I think doctors are quite unhappy that they are losing the information monopoly they traditionally enjoyed. Patients are now questioning their judgement, pointing out their mistakes, and generally are more informed. Perhaps that is the real reason why the medical community keeps raising this non-issue.
Is the mono CLR even close being as fast as java or C++?
It's hard to say for sure, but it seems to be getting there. On some tasks, it already clearly beats even the latest JVM hands down because the JVM has some limitations, while on some other microbenchmarks, it does a few times worse. One thing is clear: the Mono CLR is a lot further along performance-wise (and feature-wise) than the Java JVM was after two years in existence.
It's that they have them in places where they wouldn't have a loud conversation with another person at all...very inappropriate places.
Well, why are people complaining about cell phone use in restaurants then? Or walking down the street?
And the ringtones, goddam the fucking annoying ringtones that are constantly going off in any venue where silence and attention are expected. (a lecture for instance)
Now, that complaint, I am completely in agreement with. People should turn off their ringers just about everywhere. But that's an entirely different matter--almost all phones these days have vibrating alerts and do not need ring tones.
With another person, you can talk quietly and not disturb what's going on around you. You HAVE to talk at at LEAST a moderate level on cell phones, often louder than that.
No, you don't. Maybe you think you do, but you don't. A cell phone next to your mouth needs no more volume to talk to than you would use for a normal conversation.
People are allowed to talk face to face in museums and libararys but only when necessary. I would say that a cell call in these places is probably not necessary. This is also true in most really nice restaraunts as most usually keep the volume down unless they get a few too many drinks in them
You've got to be kidding. Museums and nice restaurants are social places; of course, you can talk there (at an appropriate level, with some exceptions for some special museum exhibits that do demand silence). That's the whole point of going.
Libraries are different: they really are for quiet reading and studying, so one should indeed avoid talking there.
What will never happen, but would be awesome, would be for IBM or somebody to pump a load of money into increasing the performace/memory footprint of wxPython. Bring it up to the level of C#.
Sorry, but that can't be done: Python is a nice language, but it is not designed to be compiled as efficiently as C#. If you want C#-like (or C++-like) performance, you need C#/C++-like language features, and Python just doesn't have them.
It's Free and doesn't have all that Java baggage.
So is C#.
The next step to Utopia would of course be a wxQt port...
Why in the world would anybody want to bother? Just use wxX11.