I'm not a fan of Microsoft Windows, but sadly I play video games that are best suited to running under Windows, and my laptop's Blu-Ray drivers don't play well with Linux, so I'm stuck running Windows in two places. Vista has been a chore, and from what I hear from my Windows-savvy friends, Windows 7 really improves on Vista. Call it "the apology," if you will (side note: I'm still waiting for my apology for Highlander II, which I saw on opening night with stratospheric expectations...)
So, now Amazon is offering something pretty sweet. You can pre-order Windows 7 from them and have it delivered to you on release day. They did this with World of Warcraft: Wrath of the Lich King as well, and I did get that delivered on release day, so I'm signing up for the same deal with Windows 7. The really nice bonus is that, being a Prime member, I get this option for free. No delivery charges!
Tuesday, June 30, 2009
Sunday, June 28, 2009
Weak Women of Sci Fi / Fantasy
Much has been made over the years of "strong women" in science fiction and fantasy and how they serve to elevate the genres and to promote an empowered view of women. I'm all for this, but when I think of science fiction and fantasy films, the first thing to pop into my head is Star Trek which elevated the time-honored role of demure, but leggy secretary to that of starship yeoman... one small step backwards indeed.
But are the weaker women of F&SF all negative stereotypes? I guess it depends on how you see "weak." One of my favorite science fiction women is Princes Leia whose combination of damsel-in-distress, love interest and wise-cracking heroine shaped my early impression of the paradox embodied in Hollywood's leading ladies. Later, I would discover that this paradox was part of the recipe for success in films like Superman, which featured a Lois Lane modeled almost directly on Leia's insecure-but-in-command mashup. Even moreso than Leia, Lois felt lost without her leading man, but in every other way she was in command of her life. It's as if men were her kryptonite, transforming the business woman of steel into a helpless schoolgirl. Again and again the 80s re-cast this new kind-of-super-woman in a variety of science fiction and fantasy. Karen Allen rounds out what I consider to be the top-3 in this lineup with Marion Ravenwood, the once-and-future lover of one Henry "Indiana" Jones.
Not all of Hollywood's weaker sex lead such double lives however. There's something fascinating to me about the noir flashbacks that maintain a cool dignity, while letting the leading man solve all of their problems. In Blade Runner, the replicant Rachel isn't even human, which might actually work to her advantage in this role.
Then we come to the younger characters who we might believe are being molded into strong women, but oscillate back and forth during the film. Labyrinth's Sarah, played by a young Jennifer Connelly, is bounced around like a pinball for most of the film's duration until she learns to take over and tell her fantasy world what to do. This would be a running theme in The Princess Bride and several other genre films.
An odd twist (and one that I'm sure isn't universally appreciated) is the reverse Labyrinth. This sort of film features a strong an independent young woman who finds that she must yield to her stereotype in order to get her man (and presumably the life she truly wishes to lead...) Oddly enough I've enjoyed the prime example of this type, Pleasantville. There's something irresistible about that film, and I found myself rooting for Reese Witherspoon's character throughout her transformation.
These films collectively demonstrate not just Hollywood's fascination with women who aren't exactly independent, but fandom's as well. Every one of these films were nominated for a Hugo Award for Best Dramatic Presentation, and several of them won. Still, none of these films draped their leading lady over a motorcycle in cutoff jeans. There are, after all, always lines to be crossed...
Saturday, June 27, 2009
The Python Platform
Update: I believe that the example for this essay on Python as an incompatible platform is incorrect. The bug report that I submitted was updated 3 months later to indicate that I'd read the documentation wrong. I think the core point here is still valid. There's a lot of "not invented here" applied to the UNIX and Linux conventions in Python, but I chose a bad example, and for that I should apologize to the Python community. I like Python. I like programming in Python. I don't want to make it sound like I'm dismissing the language, here, just a particular trope in the community.
When Java came out, I remember the promise that it would be the write-once-run-anywhere language. It was supposed to free programmers from the need to tie their code to a platform, and instead they could simply write it. This never really happened. Instead, what we got was the Java (or more accurately the JVM) platform. It wasn't really a great platform as these things go, and for a short time that confused me. I wasn't sure why the smart people at Sun would be unable to create a decent platform on which to write generic code.
Then it came to me... It was Windows. You see, Sun had a pretty decent little operating system called Solaris (né SunOS), but Java was supposed to work everywhere, so at a minimum, it would have to accommodate the world's most popular desktop platform at the time (and still, though it has less market share now): Microsoft Windows. Windows has its own ideas about how a system should manage users, permissions, networking and a host of other things that programs want to interact with, so Java couldn't allow the same code to run everywhere while exposing the powerful semantics of the Solaris operating system. More broadly, it couldn't expose those core Solaris semantics that came from its Unix heritage, embodied in the POSIX standards. These standards are what make C, C++, Perl and many other language's standard libraries so powerful, and because of that power they are also widely portable. So useful are these standards that they have molded operating system after operating system, all based to some extent on Unix. Today this includes Linux, MacOS and a plethora of lesser-known systems, all of which have important niches in various industries such as HP/UX and AIX.
So, in the late 90s a new language started to gain popularity: Python. It didn't fall for Java's trap entirely. It was mostly in league with the POSIX way of thinking. Process management, file IO and many other aspects of the language were all very reminiscent of POSIX. However, Python suffered from a new problem: it was the anti-Perl. Perl, you see, is a programming language that became very popular in the early 90s, and Guido van Rossum, Python's original author made his feelings about Perl fairly clear early on. He wasn't fond of it, and Python was going to avoid its mistakes.
While correcting the perceived mistakes of another language might seem a noble goal, it has several pitfalls which must be avoided. One of the most obvious of these is avoiding something only because the original language embraces it. Python has had a rocky relationship with POSIX for just this reason. You see, Perl is a deeply POSIX-based, and even more specifically, Unix-based language. Python, as I said, is mostly a POSIX-friendly language as well, but there's a silent mistrust within the community of the platform that Python's nemesis language so readily embraces, and this has lead to a number of almost-entirely-POSIX-friendly choices which, when seen as a whole, yield the Python Platform.
This platform is not entirely POSIX-compatible, which means that users of Python and Python programs on both POSIX and Windows systems must adapt to it, in the same way (but to a lesser extent) that they must adapt to Java's platform.
OK, so that's the generalities, but what about specifics? One must look no further for a simple example than the Python standard library's command-line processing module, optparse. This module has a simple documentation bug, but that bug illuminates the Python Platform in stark detail. Here's an excerpt:
This sounds reasonable, after all, why support oddball features? Well, it turns out they're not so oddball. The POSIX standard says that the compliant program "accepts any of the following as equivalent: 'cmd -ao arg path path', 'cmd -a -o arg path path' ..." notice that traditional Unix and POSIX programs such as the "ls" command will always accept these concatenated arguments. So why would Python tell us that this is non-standard on any environment? That goes back to the mistrust that Python has for POSIX. There's no compliance testing for the Python library's POSIX support because Python isn't a POSIX language. It's a Python language.
I decided to take the cautious approach here. I didn't want set anyone off, so when I submitted the following alternate wording to the Python folks:
... I kept it simple and factual. I didn't attempt to suggest a rationale, and I made it clear that I wasn't asking for Python's behavior to change, just the documentation. This bug report sat for three months and then was silently lowered in priority, even though it required nothing more than a cut-and-paste documentation change.
This is but one example of where Python chooses to go its own way, eschewing the wisdom of a platform that has suited the likes of Sun, Apple, HP, IBM and countless FOSS developers for decades now. I like Python. I think it's a great language for certain types of tasks. I'm also a fan of its nemesis, Perl, along with a host of other languages I've used over the years, but time and time again, I see the Python community embrace a culture of exclusion and "not invented here." For Python to truly reach the potential that I'm sure it has, it will have to be able to embrace the tools that have worked well and only discard features which have been carefully considered and understood.
There's hope, though, that this will be the case. Guido's distaste for Perl and some other Unix tools like it may have fueled this fire, but it turns out he's a very reasonable person for the most part. In a recent blog post, he says, "It's no wonder that users are switching to the web as the platform for everything that used to live on the desktop -- with all its flaws (which I will discuss another time), web development still feels like a breeze compared to Windows development." I take this as a sign that he understands the power of a platform which works with consistency at all levels, and that he will continue to improve the Python Platform so that it builds synergy with the POSIX platform, and doesn't fight against it as if it were an opponent to be conquered.
When Java came out, I remember the promise that it would be the write-once-run-anywhere language. It was supposed to free programmers from the need to tie their code to a platform, and instead they could simply write it. This never really happened. Instead, what we got was the Java (or more accurately the JVM) platform. It wasn't really a great platform as these things go, and for a short time that confused me. I wasn't sure why the smart people at Sun would be unable to create a decent platform on which to write generic code.
Then it came to me... It was Windows. You see, Sun had a pretty decent little operating system called Solaris (né SunOS), but Java was supposed to work everywhere, so at a minimum, it would have to accommodate the world's most popular desktop platform at the time (and still, though it has less market share now): Microsoft Windows. Windows has its own ideas about how a system should manage users, permissions, networking and a host of other things that programs want to interact with, so Java couldn't allow the same code to run everywhere while exposing the powerful semantics of the Solaris operating system. More broadly, it couldn't expose those core Solaris semantics that came from its Unix heritage, embodied in the POSIX standards. These standards are what make C, C++, Perl and many other language's standard libraries so powerful, and because of that power they are also widely portable. So useful are these standards that they have molded operating system after operating system, all based to some extent on Unix. Today this includes Linux, MacOS and a plethora of lesser-known systems, all of which have important niches in various industries such as HP/UX and AIX.
So, in the late 90s a new language started to gain popularity: Python. It didn't fall for Java's trap entirely. It was mostly in league with the POSIX way of thinking. Process management, file IO and many other aspects of the language were all very reminiscent of POSIX. However, Python suffered from a new problem: it was the anti-Perl. Perl, you see, is a programming language that became very popular in the early 90s, and Guido van Rossum, Python's original author made his feelings about Perl fairly clear early on. He wasn't fond of it, and Python was going to avoid its mistakes.
While correcting the perceived mistakes of another language might seem a noble goal, it has several pitfalls which must be avoided. One of the most obvious of these is avoiding something only because the original language embraces it. Python has had a rocky relationship with POSIX for just this reason. You see, Perl is a deeply POSIX-based, and even more specifically, Unix-based language. Python, as I said, is mostly a POSIX-friendly language as well, but there's a silent mistrust within the community of the platform that Python's nemesis language so readily embraces, and this has lead to a number of almost-entirely-POSIX-friendly choices which, when seen as a whole, yield the Python Platform.
This platform is not entirely POSIX-compatible, which means that users of Python and Python programs on both POSIX and Windows systems must adapt to it, in the same way (but to a lesser extent) that they must adapt to Java's platform.
OK, so that's the generalities, but what about specifics? One must look no further for a simple example than the Python standard library's command-line processing module, optparse. This module has a simple documentation bug, but that bug illuminates the Python Platform in stark detail. Here's an excerpt:
"... the traditional Unix syntax is a hyphen (“-“) followed by a single letter [...] Some other option syntaxes that the world has seen include: a hyphen followed by a few letters, e.g. "-pf" [...] These option syntaxes are not supported by optparse, and they never will be. This is deliberate: the first three are non-standard on any environment[...]"
This sounds reasonable, after all, why support oddball features? Well, it turns out they're not so oddball. The POSIX standard says that the compliant program "accepts any of the following as equivalent: 'cmd -ao arg path path', 'cmd -a -o arg path path' ..." notice that traditional Unix and POSIX programs such as the "ls" command will always accept these concatenated arguments. So why would Python tell us that this is non-standard on any environment? That goes back to the mistrust that Python has for POSIX. There's no compliance testing for the Python library's POSIX support because Python isn't a POSIX language. It's a Python language.
I decided to take the cautious approach here. I didn't want set anyone off, so when I submitted the following alternate wording to the Python folks:
"optparse has chosen to implement a subset of the GNU coding standard's command line interface guidelines, allowing for both long and short options, but not the POSIX-style concatenation of short options."
... I kept it simple and factual. I didn't attempt to suggest a rationale, and I made it clear that I wasn't asking for Python's behavior to change, just the documentation. This bug report sat for three months and then was silently lowered in priority, even though it required nothing more than a cut-and-paste documentation change.
This is but one example of where Python chooses to go its own way, eschewing the wisdom of a platform that has suited the likes of Sun, Apple, HP, IBM and countless FOSS developers for decades now. I like Python. I think it's a great language for certain types of tasks. I'm also a fan of its nemesis, Perl, along with a host of other languages I've used over the years, but time and time again, I see the Python community embrace a culture of exclusion and "not invented here." For Python to truly reach the potential that I'm sure it has, it will have to be able to embrace the tools that have worked well and only discard features which have been carefully considered and understood.
There's hope, though, that this will be the case. Guido's distaste for Perl and some other Unix tools like it may have fueled this fire, but it turns out he's a very reasonable person for the most part. In a recent blog post, he says, "It's no wonder that users are switching to the web as the platform for everything that used to live on the desktop -- with all its flaws (which I will discuss another time), web development still feels like a breeze compared to Windows development." I take this as a sign that he understands the power of a platform which works with consistency at all levels, and that he will continue to improve the Python Platform so that it builds synergy with the POSIX platform, and doesn't fight against it as if it were an opponent to be conquered.
Sunday, June 21, 2009
False Sun Over Cambridge
A "sun dog" over Cambridge, MA.
I've heard that under unusual circumstances including when volcanic ash is in the air, false suns can out-shine the real sun. I'd love to see something like that one day.
Wednesday, June 17, 2009
World of Warcraft: Lokholar the Ice Lord
A few weeks ago, I was involved in an Alterac Valley (AV) battleground in which Lokholar the Ice Lord was summoned. This doesn't happen very often, and I think it may be the first time I've seen it (though some of the multi-hour AVs I took part in back in the early days are a blur to me, now). Sadly, while this almost caused us to win on reinforcements, the Alliance used the cover of confusion to go kill our general while this was going on. But it was down to the wire, and a real blast.
If you want to know how to summon Lokholar in AV, bring 150 blood (looted from Alliance players and NPCs) to Primalist Thurloga back in your base. Once you turn in the quest, have 9 other players ready to assist you. Ride out with her to Galv's side of the Field of Strife and help her summon. Once he appears, he'll be fairly weak and will need you to kill Alliance players nearby. When you do this, he gets stronger and will eventually be nearly unstoppable.
Ideally, you will do this only in an AV where there's a turtle on the Alliance side, and everyone is fighting north of Icewing Bunker. In this case, as soon as he's summoned you want to pull your forces back to the Field of Strife and just make sure to snare or kill anyone trying to run past Galv. Lok will take care of the rest...
Monday, June 8, 2009
Same Sex T-Shirt
I'm off to Boston's Gay Pride this weekend and I thought I should make up a T-shirt this year, since I haven't done anything at all for Pride in ... well, a long time. I used Custom Ink for the shirts and the design came from a Wikipedia image that I was able to scale appropriately using The Gimp (my favorite tool for photo and design editing).
It's not that I expect people to be able to make out what the T-shirt is about at first. It's more a conversation starter and something colorful to wear and remember the event by. Long ago, the first shirts that I wore to an event like this were to Gaylaxicon. I wore an "I'm With Him" shirt, and what I remember most about it was the friendly and courteous service I got from the silk-screening place I went to... right up until the moment I told them what went on the shirt. I suppose it's not surprising that they weren't in business when I went to see if they still had the screen for those shirts a year later.
Anyway, back to this year. I'm sure it's going to be the most amazing Pride ever. Rhode Island is the only state in New England that hasn't made same sex marriage legal; Prop 8 was a blow, but has really served as a rallying point for the community; we have a President who has vowed (though so far not acted) to end the "Don't Ask, Don't Tell" policy in the military; and there's new news every day. It seems like the tide is changing, and while I won't hold my breath for everyone's attitudes to change, it's just wonderful to look back at my youth and imagine how shocked I would be to discover all of the progress we've made.
I'll see you all there!
Friday, June 5, 2009
Sad Ways To End an Acting Career
When you take on a new job as an actor, one of the things that probably doesn't go through your mind is, "what if this is my last film?" But perhaps it should be. Here, I present a list of some actors who deserved better as cap on their careers (I'm not counting post-mortem re-use of someone's likeness or archival footage).
DeForest Kelley - The Brave Little Toaster Goes to Mars
Orson Welles - The Transformers: The Movie (though he played a bit part in another film after)
Scatman Crothers - The Transformers: The Movie (had a narrator role after)
Raul Julia - Street Fighter
James Doohan - The Duke
Milton Berle - Storybook (though he was on TV quite a bit, after)
Jonathan Winters - Cattle Call (Winters had been in some unfortunate films, but this is just sad)
I'd like to think that I'm doing all of these actors a service. To a last one, I think they deserve to be remembered, and who knows... perhaps their unfortunate final projects will ensure that.
DeForest Kelley - The Brave Little Toaster Goes to Mars
Orson Welles - The Transformers: The Movie (though he played a bit part in another film after)
Scatman Crothers - The Transformers: The Movie (had a narrator role after)
Raul Julia - Street Fighter
James Doohan - The Duke
Milton Berle - Storybook (though he was on TV quite a bit, after)
Jonathan Winters - Cattle Call (Winters had been in some unfortunate films, but this is just sad)
I'd like to think that I'm doing all of these actors a service. To a last one, I think they deserve to be remembered, and who knows... perhaps their unfortunate final projects will ensure that.
Thursday, June 4, 2009
World of Warcraft: New Druid Cat Models Are Identical
Except for racial attributes like horns, ears and nose-ring, the models for the new cat forms for druids appear to be pretty much exactly identical to eachother, which is a fairly radical departure from the large racial differences (lion vs. puma) that existed before. Looking at the two side-by-side, you can see that there are some differences in the shape of the mane, but I suspect that's actually in the "skin" (coloration) where part of the model is marked as transparent. In fact, the models might actually be exactly identical with horns being slightly re-shaped with transparent regions to appear as ears and nose rings being marked as transparent for the night elf model.
It's kind of cool, but at the same time, I think it does remove some of the sense of individuality that these races had between their druids. Ah well, all change is bad and all change is good....
Wednesday, June 3, 2009
Himalountain of the Undercity
Anyway, here's the screenshot. I'll probably be backing off a bit on the Tournament for a while, and focus on PvP when I'm on. The arena has been calling to be lately, and I'm working on switching my gear over to dps from healing (my teammates just love me, I'm sure ;)
Tuesday, June 2, 2009
Spurious "iTunes could not connect to the iPhone because it is locked with a passcode" Error
I just updated iTunes to 8.2, and got this error when connecting my phone for the first time:
Anyway, don't freak out if you see this message. Just re-connect after going to the home screen on your phone.
"iTunes could not connect to the iPhone 'XXXX' because it is locked with a passcode"with XXXX being the name of my phone. It was easily fixed by waking up the phone first and then connecting, but it's clearly a bug since my phone was not locked at all. This may happen because iTunes can't tell the difference between a phone that is scheduled to lock after some period of time, but currently is just in idle mode and a phone that's actually locked.
Anyway, don't freak out if you see this message. Just re-connect after going to the home screen on your phone.
Monday, June 1, 2009
The Power of Perl's Data::Dumper
Update: sorry about the code formatting. I don't appear to be able to get Blogger to play ball with me right now. Use your imagination, especially with respect to the python examples which simply won't work with the indentation shown.
I've been doing a fair amount of work in Python recently, and there are some things I really like about the language. However, being an old Perl programmer, I find myself desperately wanting a few features of Perl in Python, and one of them is Data::Dumper. This module lets you print out the contents of a variable as Perl code. Now, Python has some similar features such as pprint and pickle, but neither of them quite gives you what Data::Dumper does.
For example, here's a class definition:
When we dump out an instance of this class, we get:
This is exactly the code you need in order to re-create the object (which you get from pickle), but it's a human-readable copy of all of the state contained within the object at the same time.
In Python, you might write:
But the pprint output just calls repr and you get:
This is because Python relies on each object to provide its own serialization method, called __repr__. If you don't define it (and sadly, many don't define anything useful, here), there's no way to know just what it is that's going on under the hood other than by writing your own introspection code. You could, for example, treat the object as a dict and peruse its attributes:
but there are limitations to such an approach, especially when it comes to encapsulation.
Anyway, the point is, this is one area in which Lisp, Perl and other languages that can represent arbitrary data as code have an ease-of-use advantage over languages that cannot. Hopefully this is being addressed in future versions of the language (I'm not using 3.x yet).
I've been doing a fair amount of work in Python recently, and there are some things I really like about the language. However, being an old Perl programmer, I find myself desperately wanting a few features of Perl in Python, and one of them is Data::Dumper. This module lets you print out the contents of a variable as Perl code. Now, Python has some similar features such as pprint and pickle, but neither of them quite gives you what Data::Dumper does.
For example, here's a class definition:
package Someclass;
sub new {
my($class, $param1, $param2) = @_;
return bless { param1=>$param1, param2=>$param2 }, $class;
}
When we dump out an instance of this class, we get:
$VAR1 = bless( {
'param2' => 2,
'param1' => 1
}, 'Someclass' );This is exactly the code you need in order to re-create the object (which you get from pickle), but it's a human-readable copy of all of the state contained within the object at the same time.
In Python, you might write:
class Someclass(object):
def __init__(self,param1,param2):
self.param1=param1
self.param2=param2
But the pprint output just calls repr and you get:
<__main__.someclass>
This is because Python relies on each object to provide its own serialization method, called __repr__. If you don't define it (and sadly, many don't define anything useful, here), there's no way to know just what it is that's going on under the hood other than by writing your own introspection code. You could, for example, treat the object as a dict and peruse its attributes:
>>> pprint.pprint(x.__dict__)
{'param1': 1, 'param2': 2}
but there are limitations to such an approach, especially when it comes to encapsulation.
Anyway, the point is, this is one area in which Lisp, Perl and other languages that can represent arbitrary data as code have an ease-of-use advantage over languages that cannot. Hopefully this is being addressed in future versions of the language (I'm not using 3.x yet).
Subscribe to:
Posts (Atom)