Monday, October 11, 2004
Medical breakthrough of the day
Scientists in California have found a way to “turn off” a gene that makes cancerous cells lethal. They eliminated aggressive, incurable liver tumours in laboratory mice in four weeks, they report in an advance paper in Nature today.
The study, based on a gene called Myc, could lead to new ways of treating cancer.
Via Vidicon, S cientists find way to 'turn off' cancer
This is incredible news and I wish the scientists luck in applying this to humans. My Mom died ten years ago of cancer and while this won't help her any, it may help those with cancer now, and possibly those of us in the future who may get it.
Medical scare of the day
And speaking of medical issues, The Older had a medical emergency today—being on the business end of a chisel and all that. He's fine now, but it was a busy day today, driving to and fro, hurrying up and waiting.
Tuesday, October 12, 2004
“Oh! You meant DUTTON, not DAYTON!”
I'm currently working on a website where one of the requirements is to obtain the latitude and longitude of the user. This was something I was dreading not from a programming perspective (since just asking for the latitude and longitude is dead simple) but from a user interface perspective (since from the user end, it's not quite so dead simple). It'd be nice if I could just ask the user for the city they're in, and get the latitude and longitude from that.
But where could I get that type of information?
From the US Census Bureau.
D'oh!
Granted, that still leaves me asking the rest of the world to locate their own latitude and longitude, but since this site is initially geared towards us Murkins I'm not that concerned about it yet.
Now it's a simple matter of getting the city and state from the user, then looking up the latitude and longitude of the city. Easy.
Until a user misspells a city. The easy thing (for me) would be to print
an error like, “City Cininatee, OH not found—try again” and
have the user try spelling Sinsinati Cininatee
Cinsinati Cincinnati (there we go!) correctly
(or give up and say they're in Bratenahl as
it's easier to spell). The harder thing to do is figure out what they're
trying to spell and use that.
Only it's not that much harder. I've used both Soundex and Metaphone in another project to correct misspellings and it seems easy enough to apply that here. Lookup the latitude and longitude with the city and state supplied. If not found, then filter the city through Soundex, and look up the correct spelling based on that. If that doesn't return a result (or too many results) then fall back to Metaphone.
Sounds good in theory.
Not so great in practice.
In setting up the appropriate datafiles, I went through the list of city latitude/longitude I picked up from the US Census Bureau and marked where Soundex and Metaphone clashed on multiple city names (each state is treated seperately, so I'm only concerned with clashes within a given state). There, I hit a problem:
conflict(soundex/AL): D500 = [DOTHAN] [DAYTON] conflict(soundex/AL): D500 = [DUTTON] [] conflict(metaphone/AL): TTN = [DUTTON] [DAYTON]
Dothan, Dayton and Dutton (all in Alabama) have a Soundex
code of D500. Falling back to Metaphone, Dutton and Dayton have
a Metaphone code of TTN. So what to do here if a user types in
“Daytun”?
I think the correct thing to do at this point would be to list the posibilities and have the user select the proper one. But this will necessitate a change in how I store the data.
It's not easy to create an easy to use interface. In fact, it's downright hard.
Wednesday, October 13, 2004
The Quick-n-Dirty Ad-Hoc Location Targetting System, on the cheap
I dropped support for Soundex in the project I'm working on. In going over the diagnostic output when importing the data, I found that Soundex had over 6,000 collisions, while Metaphone had less than a 1,000, and shorter collion chains (i.e. most Metaphone collisions have only two possibilities). It just wasn't worth the disk space to use Soundex at that point.
Then it was on to work doing a mock up on the web. The logic is pretty much:
if city exists in latlong.database
then
fetch data from latlong.database using city
print data
exit
end
tag = metaphone(city)
if tag exists in metaphone.database
then
fetch cities from metaphone.database using tag
if count(cities) is 1
then
fetch data from latlong.database using cities
print data
else
print "select one from the list:"
for each city in cities
print city
end
end
end
exit
The mockup is quite plain in appearance, but that can be easily changed as most of the output is template based anyway. And it only works for the United States.
Next up, code in time zone and Day Light Savings Daylight Saving Time information for each
city.
Thursday, October 14, 2004
“Programmically dealing with time can lead to madness … ”
I quickly decided not to include Daylight Saving Time and timezone information for each city. In looking over what needs to be done, I realized that it's just way too much work for so little in return.
I'm not trying to handle the timezones automatically since ther's no clear-cut method to determine where a timezone is. While nominally the timezones are all 15 degrees apart, one just can't use that fact to determine the timezones since there are regional variations. For instance, Mountain (which is seven hours west of Greenwich) is located between 97°30′W and 112°′W and while it would be nice if one could say, “Yes, White Bird, Idaho, which is located at 116°17′56″ is in the Pacific Time Zone.” But you can't because White Bird is in Mountain, while 28 miles south is Riggins, at 116°18′53″ which is in the Pacific Time Zone (I think—according to my map, the time zone border runs just along the northern edge of Riggins).
It'd be a lot of work to work out which town is in which timezone for a given state if said state actually straddles two timezones (which looks to be about thirteen states).
Daylight Saving Time is a bit easier. Most of the United States follows DST and given that it starts on the last Sunday of April and ends on the last Sunday of October, it's easy enough to check.
But the following areas in the US do not follow DST: Hawaii, Indiana except for Jasper County, Lake County, LaPorte County, Newton County, Porter County (which are in Central Standard Time or Central Daylight Time depending upon the time of year), Dearborn County, Clark County, Floyd County and Harrison County (which are in Easter Standard Time or Easter Daylight Time), Arizona (with the exception of the Navajo Indian Reservation, given it spans three states), American Samoa, Guam, Puerto Rico and the Virgin Islands.
But the history of Daylight Saving Time is interesting and yet maddening (and yes, I do have to track Daylight Saving Time in the past unfortunately). Daylight Saving Time has not always been around although the idea was first presented by Benjamin Franklin. England was the first county to formally encode into law Daylight Saving Time (went into effect May 21, 1916) followed a few years later by the United States (into effect March 31, 1918), and over the following few decades went into and out of law several times. In researching this, I did create the following table of DST dates:
| Year(s) | Start | End | Notes |
|---|---|---|---|
| Year(s) | Start | End | Notes |
| 1776–1917 | — | — | US did not have DST at this time. |
| 1918 | Mar 31 | Oct 31 | Instituded by Woodrow Wilson for World War I. |
| 1919 | Mar 31 | Oct 31 | |
| 1920–1941 | — | — | DST Repealed by US, with the exception of Massachusetts, Rhode Island, New York City, Philadelphia and Chicago |
| 1942 | Feb 9 | — | Franklin Roosevelt signed into law “War Time” which put the US into Daylight Saving Time from Feb 9, 1942 until Sep 30, 1945. |
| 1943 | — | — | |
| 1944 | — | — | |
| 1945 | — | Sep 30 | |
| 1946–1965 | — | — | No US law at this time; states and municipalities were free to use DST as they saw fit. |
| 1966–1973 | last Sunday of April | last Sunday of October | |
| 1974 | Jan 6 | Oct 31 | Due to the OPEC crisis of 1973, Congress passed the DST Energy Act, which mandated a longer period for DST for the next two years |
| 1975 | Feb 23 | Oct 31 | The DST Energy Act was repealed and DST went back to the normal schedule |
| 1976–1986 | last Sunday of April | last Sunday of October | |
| 1987-present | first Sunday of April | last Sunday of October | In 1986, Regan signed into law a modification of the DST Act, moving the start of Daylight Saving to the first Sunday of April. |
Determining whether a location observed DST in the past is not easy (unless you know from personal experience) so again, this is left to the user to indicate such information (although from 1987 onwards can be done through software).
Friday, October 15, 2004
Placeholder until I get them finished
The entries I had originally planned for today have been postponed until I finish writing them.
And if you thought the entry on Daylight Saving Time was geeky …
Update on Tuesday, October 19th, 2004
Saturday, October 16, 2004
A blisfull morning's sleep
At last, a full morning's rest. A change from the past two weeks as the renovation work on unoccupied units continues unabaited, and two of the units here in the Facility in the Middle of Nowhere are unoccupied, thus leading to a crew starting somewhere around 7:30 in the morning to drill, hammer, saw, tear, crash and otherwise not at all silently renovate said units.
The crew must have wondered off to some other unit to raze this morning, for which I am eternally grateful.
Sunday, October 17, 2004
Yet another blissful morning's sleep
Yet another morning of blissful sleep. Could this mean they are now finished with ripping out the guts of the other units here in the Facility in the Middle of Nowhere?
One can only hope so.
Monday, October 18, 2004
Medical scare of the day, redux
As I was going to sleep last night, I reflected on the turn of events last Monday and hoping that we could get through this Monday stitch-free.
I reflected too soon.
I got up to find the Facility in the Middle of Nowhere empty. No one else was around. Then my cell phone rang.
“Hello?”
“Yes, this is Wlofie,” said Wlofie. “Spring wanted me to call you to inform you that The Older's wound re-opened, so we're on the way to the hospital to get him restitched up.”
“I hope this won't become a re-occuring phenomenon (do doo be-do-do!).”
“I hope so too!”
So, until the stitches are out for good, The Older is now grounded from going outside, rough housing, or otherwise engaging in any activity with his brother that could cause his fingers to split wide open again.
Tuesday, October 19, 2004
Rambling about programming
The two major forms of programming, Procedural and Object Oriented, approach the problem of programming from opposite directions; those directions being a code centric view (“verb oriented” if you will) and a data type centric view (“noun oriented”).
Procedural, being the older of the two, is code centric, since that's the primary view of computers when they were first built—how do we get this expensive box of electronics to do something? Procedural is more concerned with the steps of solving a problem—step one, step two, step three. Actions. Verbs. When you have very few data types, it's easier to program the nouns to the verbs (if you will). That is, a program will tend to look like:
add(one,two) if one and two are ints, then do the add this way if one and two are floats, then do the add this way if one and two are strings, then do the add this way sub(one,two) if one and two are ints, then do the sub this way if one and two are floats, then do the sub this way if one and two are strings, then it's an error, bub!
Adding a new verb is easy, given the limited number of nouns present. But, as the number of nouns (remember, in this rather twisted metaphore, a noun is a data type) increases in a program, this starts to get unwieldy, which leads us to—
Object Oriented, developed in the 70s and gained industry wide acceptance during the 80s, is a more data-type centric view of programming. If you have lots of data types, but relatively few verbs, it then becomes more convenient to program the verbs to the nouns, something like:
int(op) if op is add, do this if op is sub, do this float(op) if op is add, do this if op is sub, do this string(op) if op is add, do this if op is sub, then it's an error, bub!
Sure, there's still a sequence of steps done to do anything, but it's the nouns that do the work themselves (if you care to view it that way). You simply tell the datatype, “do this.” And if it can, it does.
But as the number of verbs increase, then this too become unwieldly which leads us to—
Nothing that I know of.
Granted, if the number of verbs is significantly large to the number of nouns, then a Procedural method works well, while the opposite, if the number of nouns is significantly large to the number of verbs, then Object Oriented is the way to go. But what if both nouns and verbs are significantly large? What if you have a hundred different data types and a hundred different actions that can be applied? (One hundred of each ever after you tried reducing the number of both?)
Either approach will lead to a mess.
And when will you even have a large number of nouns and verbs in a program?
Well, think of the Massively-Multiuser Online Role Playing Games, like EverQuest or Star Wars Galaxies. Thousands of objects, and possibly thousands of different actions. A player can walk, run, skip, jump, jog, crawl, skulk, stumble, dance, turn, parry, dodge, spin, thrust (thwack! ouch!). That's just movement, and I'm sure I'm leaving out plenty of other movement actions. They can also carry, throw, chuck, up-chuck, heave, shoot, fling, place and lay items.
Sure, you can cut the number of actions down by making some of them more abstract, like “use” an object (the “use” of an object like a camera being different than the “use” of an object like a key) but we humans are creative (or stupid, take your pick) and while you can't use a key to take a picture, you can attempt to use a camera to open a lock (although you may end up with a mangled camera and a still locked lock) and it would be nice if the program would allow us to attempt this (even if it is stupid).
It'd be nice if there was a way to manage both a large number of nouns and verbs within a program, but as of yet, there doesn't seem to be a way to do this.
But even with this limitation, I think one can still build programs with tons of objects with tons of actions.
Or it may end up being one large mess.
I'd be interesting to see.
The Wikimud
While sleeping last night [which was actually Thursday night/Friday morning—Sean] I had a rather odd thought pop through my head—a WikiMUD. I then spent some time pondering that and how one would go about implementing such a thing.
A what?
A WikiMUD.
It's applying the principles of a WikiWikiWeb with that of a MUD.
I can hear you blinking out there.
Okay, for those who might otherwise not know, a WikiWikiWeb (or “Wiki” for short) is a website where every page is editable by anyone. See a typo? Fix it. See a mispelling? Fix it. Don't agree with what you read? Add your two zorkmids. A very egalitarian approach to web content, and it can lead to some wonderful things.
A MUD, which stands for “Multi-User Dungeon” or “Multi-User Domain” (take your pick) is a multiplayer verion of a text adventure, where instead of you just walking through a twisty little maze of passages all alike, there are scores of people all waking through a twisty little maze of passages all alike. Just as Adventure was the single player forerunner of a MUD, a MUD (and there are still plenty around) was the forerunner of todays MMORPG, or “Massively-Multiuser Online Role Playing Game” like EverQuest or Star Wars Galaxies (these tend to be graphical in nature).
So, a WikiMUD is a MUD where anyone can edit anything and even change the nature of the game play as it's being played.
The WikiNature scares some people; not only can anyone edit anything, they can also delete anything. MUDs scare others; people (often college students) emersing themselves into a game 10, 12, 16 hours per day to the detriment of living in the real world (this has happened to friends of mine—the results are not pretty). A WikiMUD should therefore be downright horrifying!
Now, besides the potentially horrifying nature of a WikiMUD, how could one implement such a beast? Obviously there is going to be a programming language available, and some form of online editor so that on-the-fly changes can be made to the game. But the underlying implementation? The framework that can support such a thing? That's challenging.
In the few MUDs I've looked at, source code wise (and yes, I did toy with them briefly in college but I was more interested in writing a MUD, not in playing a MUD; I never did get around to writing one though) is usually structured around rooms, objects, monsters (or mobile-object, aka MOB) and players, which generally lend themselves to being written in a object-oriented manner, even if that ultimately may limit them.
Some thought on this lead me to a possible implementation. It may not be a good implementation, but it's more than nothing. And it allows great freedom to the users to extend the game in ways the game designer (or implementor) might not have thought otherwise.
Everything in a MUD can be broken down into two things: objects and actions. We'll go into actions later. An object can be something like a room, which may have a name, and have a list of items it has—an inventory if you will. Or an object can be something like a player, which may have a name, and have a list of items it has—an inventory if you will, and a location within the game map. Now, in a traditional object oriented design, one might then be tempted to make a person a subclass of room, but that doesn't really work here since a person ISnotA room, even if they share some commonality. It gets even worse if you want to include a bag-like object, which may have a name, and have a list of items it has—an inventory if you will, and a location, either a room or a person; a bag is a kind of portable room, but again, a bag ISnotA room.
[I'm making a rather bad pun in the previous paragraph. The ISA Principle of OOP states that a relationship between an object A, and a derived (or based off of) object B, is that object B ISA object A. What I'm saying here is that even though the implementation of object B is similar to (or the same as) object A, that does not mean that object B is derived, nor should it be derived, from object A.]
[I also suspect I'm loosing more and more of my readers at this point … ah well.]
So we have three objects so far, all of which are similar (name, inventory, a location in two of the three objects) but none of which really follow the ISA principle of OOP, although they certainly have plenty of HASA relationships between them all. And we haven't even gotten to monster objects yet. But each of these objects do have one thing in common—they all have some form of attribute. Be it a name, or a list if things it has, or its location, these are all attributes of the object.
[A HASA relationship between object A and object B, such that object B HASA object A, does not mean that object B is derived from object A, but that it uses or contains within its definition an instantiation (or “fully initialized and ready to use”) of object A. Sorry for the digression.]
So what, instead of having distinct objects we simply attach attributes to objects as we need them? You create (or “instantiate” in OOPspeak) an object. This object is … well … there is no real metaphore for what this object is, other than … an inherent object with … objectness to it. It is an object with which anything else can be created. It is the urObject in our WikiMUDian universe and is nothing until one attaches attributes to it.
Want a person? At a minimum, it's an object with a name and a location. Want a room? At a minimum, it's an object with things in it, and exits to other room-like objects. Want a bag? Again, just an object with things in it, and a possible location (even if that location happens to be a person object, or another bag object). A minimal WikiMUDian universe may look something like:
# this is a comment # numbers represent object ids object-id: 0 south: 1 inventory: 2 object-id: 1 inventory: 3 north: 0 object-id: 2 name: bag location: 0 object-id: 3 name: Sean location: 1
When I move (as object #3, “Sean”) north, the location attribute would change from a 1 to 0, and the inventory list of object 0 would change to now include object 3—me. When I pick up the bag, the bag's location would change from object 0 (a room) to object 3 (me) and I would then gain a new attribute, inventory, with the object-id of the bag.
Simplistic yes. Flexible yes. And it can certainly lead to very surreal things, where as it stands now, I can “pick up” room 0 and “drop it” in room 1. There really isn't anything built into the code to prevent such wierd occurances as this.
And I'm not sure if there should be. Yes, as people add objects and actions (which we'll get to) certain conventions will probably come out, and code added to prevent people from picking up rooms and dropping them here and there. But it certainly will allow someone to create, say, a dollhouse that can be carried about, but that also contain actual rooms that people can move about in, if they were so sized (which is just another attribute one can add, after all).
And speaking of picking up rooms … we need actions. We've already mentioned a few, such as creating an object (or “urObject” as the case may be), adding and modifying attributes, moving ourselves around, picking up bags and rooms. While we're at it, we might also want to remove attributes, destroy objects, and even copy objects (because you can never have too many bags, or zorkmids once someone gets around to creating one). Now, while I've been currently envisioning objects as being global (in the programming sense, which makes sense to me but explaining why it makes sense would take as long as a semester of Philosophy 101, which I'm not about to do here), actions on the other hand, can be global (available to be applied to all objects whether it makes sense or not) or local to just an object (and copying an object will copy those actions local to the object).
[In thinking this through, I may have inadvertantly reinvented SmallTalk.]
So, the action of going “north” would be applied to the player, and the code may look something like this:
(to north (target)
(let room (object-by-id target/location))
(if (object-by-id room/north)
(
(modify target/location (object-by-id room/north))
(say target "You move north.")
(say (allbut room target) target/name " moves away to the north.")
)
(
(say target "You silly git! There's no way to move north!")
(say (allbut room target) target/name " stumbles into the north wall.")
)
)
)
[Yes, the code looks like Lisp. Since Greenspun's 10th Law of Programming states that any sufficiently complicated program will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp, I thought I'd go ahead and cut to the chase—besides, it's dead simple to write a Lisp-like parser.]
And it would be a global action, available to all objects (or all players). An example of a localized action might be:
(to stick-head-in-bag (bag target) (modify target/description (+ target/description " Plus there's this " "rather large and unsightly bag over the person's head, for " "some unearthly reason." ) (to target/see (target) (say target "You silly git! You can't see! You " "have a large and unsightly bag over your head!") ) )
Basically, we modify the description attribute of the target (in this case, the idiot putting the bag on their head) to indicate such, and also add a local action to the target—in this case the “see” action, to say to the player that they can't see because they have a bag over their head.
The attributes and actions I've described so far are not cast into stone—in fact, except for a few actions that manipulate objects and actions, there are no baked in commands. There are no baked in objects either (with the possible exception of a minimal, if even that, player object). Everything (and I mean everything) is up to the players. The rules (or lack thereof). The rooms. The genre.
Everything.
What are the implications of this?
Well, dup bugs (that allow the duplication of objects that shouldn't be duplicated) aren't a problem. Heck, duplication of objects is a feature; I find a zorkmid, it's easy enough for me to duplicate it a thousand times (“Look at me! I'm a counterfeiter!”). Heck, I could duplicate myself a thousand times if I wanted to. Sustaining an economy in such an environment is … interesting, to say the least.
Leveling? What's that? Oh, you're level 40? Well, let me just modify my level attribute to 70! No wait, 1,000! No, how about 50,000! Take that you puny 40th level … player … you. Here, let me throw this Ninja zorkmid at you! Oh wait! No throw action. Hold on … <hack> <hack> <hack> … there we go! Ninja zorkmid throwing action! Which leads to interesting combat when I can make anything a weapon that does a hundred points of damage. Or a thousand. Or a million. Or instant destruction.
The Ninja Dandelion of Instant and Utter Death, anyone?
Drat! Your Shield of Formica +1 blocks it!
If there's no leveling, nor any meaningful concept of an economy, and everyone can cheat by changing things they don't like (if you can call it cheating if the system allows it), then why would anyone actually want to play one?
Because of the creativity that would ensue. A certain class of people would play just to create experiences that others can enjoy, and another class of people would play just to experience those experiences. Over time, I'm sure, conventions will be developed over what is allowed and what isn't, but that still doesn't prevent someone from creating their own “world” within the WikiMUD universe. I can see people creating multiply different worlds within a single WikiMUD. Some open to all, some open by invite only, some good, most probably horribly bad (Sturgeon's Law: 90% of everything is crap). Much like what happened in Roger Williams' novel, The Metamorphosis of Prime Intellect (where a computer gains self-sentience and enough power to literally create worlds to anyone's design, although I don't see the WikiMUD actually gaining sentience).
I for one would love to see something like this—to see what people would do with such an open ended and extensible system where anyone can add to it. While I'm sure there are MUDs out there that allow people to extend them, I suspect the additions are mostly limited to rooms and maybe objects. To allow the editing of everything though …
Would definitely be interesting.
Thursday, October 21, 2004
Some more musings on the WikiMUD
Told you those posts were rather geeky.
The WikiMUD entry has garnered some attention (and quickly too! I'm surprised anyone reads this anymore). But it was wlofie who brought to my attention the concept known as a MUSH.
I was aware that there did exist some MUDs that allowed players to create rooms, but imagine my surprise when I found out that there exist MUDs (or a MUSH, as they're called) that allow for the creation of objects as well as actions (just proving that there really are no new ideas in this industry, just fresh approaches) although the creation is limited to a certain class of player and there appear to be some restrictions in what you can and can't have objects do (and in the MUSH I'm trying out, you can't copy yourself—how restrictive!).
In discussing how I envision the WikiMUD working, and how easy it would be for a player to make a nusance of themselves, wlofie asked, “How easy would it be for my to flood all the rooms with cyanide gas?”
I thought for a second. “It'd be easy enough to flood a room with cyanide gas. Just add the appropriate attribute to each player in the room, and add the action of gassing anyone else that comes in to the room. But to do the entire WikiMUD?” Thought for anothe second. “Just make an object that travels from room to room, adding cyanide gas to each as it passes through.”
“So I would have to do it manually?”
“Well, in a manner or speaking. Any rooms you create could be set to go off at the same time, but for rooms you didn't create, you would have to add that to each room.” And in looking over the MUSH stuff, while it looks like you could add cyanide gas to a room you created, you certainly couldn't to a room you didn't create, nor could you create an object that moves and add cyanide gas to each room it goes through.
We also discussed security, or rather the lack of security. Which explains why Wikis can work (one reason: there's no challenge to destroying a Wiki) but this is a game. There's a level of interaction in a WikiMUD that you don't get in a WikiWikiWeb, and thus more enjoyment out of flooding the place with virtual cyanide gas. But I think that the things that make a Wiki work (anyone can edit anything) might keep the level of maliciousness down. Yes, I can write an object that wanders around filling each room with permenent cyanide gas, until someone else hacks themselves to be immune, and hacks the cyanide adding object to remove cyanide (and hack any other cyanide adding objects to remove cyanide). Which, to tell the truth, sounds interesting!
And guess what? We now have Core Wars taken to another level (and this is just one unintended, but interesting, consequence of a WikiMUD).
“I'd buy that for a dollar!”
Since listing the tickets I've been contacted by quite a few people who think they're going to the same wedding. As it happens, 3 of you are and want to sell your tickets too. So this auction is now for 5 tickets to the wedding of a mate to a dog that we don't want to go to. Getting five of you into a wedding might be a bit of a gamble, so I'll keep the buy it now price the same, but you're now looking at at least £400 worth of free booze, good food. Even if you have to listen to her dad do karaoke, and watch her mum try to get off with the ushers.
Via Marginal Revolution, 2 invitations to a wedding I don't want to go to
And with a current bid of £413, proof that anything can be sold via eBay.
Hmmm … I wonder …
I wonder how several score of small, genuine imitation conflict-free
diamonds, pre-mounted in cheap plastic easily adaptable
mounting casing would go for? I'll include the plastic transparent
case and magnifying lens visual amplification module in with the
deal …
Friday, October 22, 2004
You mean there's a subtext in rock music?
Lately I've been retuning in to 88.5 WKPX, a radio station broadcast out of a local high school. It tends to have much better programming than commercial stations and absolutely no annoying car commercials. Then again, it has no commercials whatsoever, being publically funded. On the gripping hand, the PSAs do wear a bit thin, especially the ones done by the high school staff (editing people! Just tightening up the timings would do wonders!).
But hey, it's high school, and there is a wide variety of music.
So anyway, I tune into WKPX and I happend to catch the end of a “Classic Rock” show showcasing all the hits of the late 60s/70s. Brought me back to when I first heard “Hotel California” by the Eagles:
On a dark desert highway
Cool wind in my hair
Warm smell of colitas
Rising up through the air
Up ahead in the distance
I saw a shimmering light
My head grew heavy, and my sight grew dim
I had to stop for the night
As a kid, I wasn't aware of subtext, or the extended use of metaphore (you mean that the Vapors' Turning Japanese isn't about overt love of Nippon? Shocking!) that is commonly used in rock songs, so here I thought, for years that Hotel California was about, you know, a haunted hotel in California. It's a common thing in America, right? Why else would Hollywood make a movie about a haunted hotel?
There she stood in the doorway
I heard the mission bell
And I was thinking to myself
“This could be Heaven or this could be Hell.”
Then she lit up a candle
And she showed me the way
There were voices down the corridor
I thought I heard them say
As I slowly became aware of such double meanings behind words, it slowly sank into me that this song wasn't about a haunted hotel—no, when I thought about what the lyrics were implying, listening close whenever I happened to catch it on the radio (which wasn't hard as this, Stairway to Heaven, and Satisfaction was on constant rotate on the “Classic Rock” station here in Lower Sheol), I woke up and my naïve interpretation crumbled before me.
Her mind is Tiffany twisted
She's got the Mercedes bends
She's got a lot of pretty, pretty boys
That she calls friends
How they dance in the courtyard
Sweet summer sweat
Some dance to remember
Some dance to forget
Why … this is … this song … is about sex with a minor!
Mirrors on the ceiling
Pink champagne on ice
And she said
We are all just prisoners here
Of our own device
So now we have a temptress, living out her waning years at some Californian hotel, inviting in impressionable young men to keep her entertained, using them like himbos and discarding them, but only after making sure they're there of their own free will (for “plausible deniability” I'm sure of it—“Honest Officer! He said he was eighteen!”).
But in the years since, it has come to my attention that not even this interpretation is correct and that the subtext not spoken aloud yet clearly visible to anyone with an ounce of clue can see, is that it's about heroine addiction!
And in the master's chambers
They gathered for the feast
They stab it with their steely knives
But they just can't kill the beast
Last thing I remember
I was running for the door
I had to find the passage back to the place I was before
“Relax,” said the nightman
“We are programed to recieve
You can check out any time you like
But you can never leave!”
I still like the ghostly sex with a minor interpretation myself.
Although, what if one were to combine all three interpretations into a video of the song? A ghostly apparition of an older female heroine junkie that lures in young impressionable men to damn them for all eternity listening to a classic rock station playing nothing other than
Welcome to the Hotel California
Such a lovely place
Such a lovely place (background)
Such a lovely face
Plenty of room at the Hotel California
Any time of year
Any time of year (background)
You can find it here
You can find it here
Sunday, October 31, 2004
Happy Halloween!
The past week I've been sitting around not doing much other than fighting a cold and dreading the upcoming days. First the weekend (which is, for the most part, over) because of Halloween; kids hyped up on sugar and all that entails, and the oohs and ahhs of November 2nd turning to running and screaming on the 3rd and wondering what the October Surprise would be, and when it would be.
Imagine my surprise when it was Osama bin Laden throwing his endorsement to Kerry, and without the usual Islamic apocalyptic rhetoric he usually uses. And here I thought Bush would have announced his capture, not have him endorsing Kerry.
I've stopped looking at the polls—they change way too often and when the difference between the candidates is below the margin of error, then what's the point? Especially when the error margin can swing upto 100 electoral votes one way or the other.
Stop! Stop the polling! Stop! Stop. Stop hurting America. Just say, “We won't know until Nov. 3rd.” Heck, we don't really need to know until 12:01 pm, January 20th but enough of politics … it's also the day before National Novel Writing Month and sadly once again, I shall attempt a novel. Who knows, maybe one year I'll actually finish one.
