I've recently come down with a case of asthmatic bronchitis. This is worse than acute bronchitis, but not as bad as pneumonia (meaning I don't think it will kill me).
"So what is asthmatic bronchitis?" you ask, or google. I had asthma as a child, but had forgotten what that was really like until this hit me. It's a combination of an asthma attack and a powerful cough reflex. It's like someone is simultaneously giving you a punch in the solar plexus and a swirlie.
This goes on for a minute, while a detached voice at the back of my mind says, "Perhaps I will finally get to see an inverted lung." That hasn't actually happened, and I'm betting if it did, it would be a disappointing sight, what with all the inflammation, mucus and blood.
But aside from these intense moments, the rest of the time this illness is pretty boring. I'm usually too worn out to focus on anything more intellectual than say, a bad SF novel, or a bad SF show on Hulu. Which I did for a while. But eventually I couldn't even concentrate on that.
And that's when I started missing TV. I do own a TV, it's just not connected to anything besides an XBox and a DVD player. No cable, no antenna. I don't like television programming. "Cable" means "hundreds of channels with nothing to watch". But then I got to thinking about this correlation between me feeling sick and stupid, and wanting to watch TV. Maybe this is an indicator of a larger trend, that one of the other beneficiaries in the growth in chronic diseases is the television industry. There are few chronic diseases that rob you of the ability to watch TV, and they often give you time to do not-much-else, because of the effects of the illness and the side effects of many drugs.
So this leads us to an explanation for the popularity of the Jerry Springer Show. You'd have to be sick to be on the show, and you'd have to be sick to watch it. The crisis in health care ensures that there are plenty of people who now qualify.
2009/09/04
On Health Care
I consider myself totally unqualified to comment on health care, more so on its reform. And that my friends, is the purpose of blogs and talk radio -- to comment on those things about which you are unqualified.
Moving on, it seems to me that there is one single, driving force in health care that leads us to the mess we have today: there's no money to be had from a healthy population.
"Oh that's not true," you say. "The insurance industry wants a healthy population. Keeps their costs down." To a degree, that's true. But imagine for a moment that the entire nation was in excellent health, not a dialysis machine or a stent needed from sea to shining sea. Who among us would pay for health insurance? At best, they could get a fraction of their current income for what amounted to accident insurance. Even if they could still get -- what is it thirty percent of every health dollar spent -- fat lot of good it would do them if the number of dollars slid down to teensy. No, having sick people around provides several positive benefits to the insurance industry. First and foremost, it scares healthy folks into thinking they need insurance, for someday "that could be me." Second, when you get a decent slice of the pie, having sick people in the pool makes the pie that much bigger. Having too many sick people would become an unmanageable problem for the insurance industry, I suppose, but we're probably not yet near that upper limit. (The phrase "supply-side sickonomics" keeps rumbling through my head, but I've no idea what the practical interpretation of that would be.)
Once you get past the insurance industry, the rest is easy. The best customer for the health care industry is one that is in need of its services for that person's entire life. Preferably, whatever the person has shouldn't significantly shorten their lifespan (not more than five or ten percent), or be so debilitating that they can't earn enough to cover premiums. From this, it's obvious that people with diabetes, arthritis, asthma, obesity, depression, or even allergies are all the health industry's best customers. And guess what? These are exactly the kinds of diseases that we've seen steadily increase in the last several decades, in lockstep with the growth of the health care industry itself.
This is not a coincidence. We've put the health care industry into a (somewhat) free market, and that market has done what markets do: find growth strategies. I'd like to think that no one in the world said out loud, "...and if we push more corn sweeteners on Americans, the income from our medical arm will rise proportionately with obesity", or at least I hope that no one in any position of power was saying that, but marketplaces have a way of finding efficiencies that are beyond the ken of the average human or the most sophisticated economic model. (I believe economics is a matter of vast numbers of interactions combined with huge stochastic, psychological and often irrational components that are either largely ignored and/or misunderstood. To talk about the efficiencies of the marketplace is somewhat misguided. A marketplace is efficient the way an ant colony is efficient at constructing burrows or foraging. It's an illusion of patterns and order arising from an enormous number of events, most of which are random. In other words, a marketplace will usually be more efficient than chaos. Conversely, since a planned economy can't actually take into account all the variables involved and is thereby constrained to using gross simplifications, it will always be less efficient than chaos. This may be why Somalia rolls on while the Soviet Union has collapsed.)
I think there's a way to correct this situation, but I'm not bright enough to find an implementation. All the same, here's the general notion. Restructure the market to place value on people being healthy. One possibility would be to place future contracts on the health of individuals. These contracts would pay premiums based on the projected quality and length of life for the individual. Everyone would have buy-in on the future, and the payout is the best for everyone (health providers and providees) when the person is living a long an healthy life.
Unhealthy individuals would benefit when someone takes it upon themselves to buy up their futures and increase their value, say by finding a cure for their disease.
I don't know how to make such a market work. Most futures markets don't look out that far, and this market would have to look forward four score and ten, give or take a decade. I don't know how we'd make trading on the options work, either. And I can certainly see some grim possibilities for abuse of such a market. The mafia don who's first inkling that he has a problem is when his own health futures start to plummet; the meat inspector that passes a load of contaminated hamburgers headed to the public schools, and then shorts the futures of the kiddies.
Well, maybe there's an alternative out there that could make some sort of market incentive work, and invert the setup we currently have. Otherwise I don't see how any market-based reform is going to work. Instead, we're going to have to remove market influences from the health care industry.
Moving on, it seems to me that there is one single, driving force in health care that leads us to the mess we have today: there's no money to be had from a healthy population.
"Oh that's not true," you say. "The insurance industry wants a healthy population. Keeps their costs down." To a degree, that's true. But imagine for a moment that the entire nation was in excellent health, not a dialysis machine or a stent needed from sea to shining sea. Who among us would pay for health insurance? At best, they could get a fraction of their current income for what amounted to accident insurance. Even if they could still get -- what is it thirty percent of every health dollar spent -- fat lot of good it would do them if the number of dollars slid down to teensy. No, having sick people around provides several positive benefits to the insurance industry. First and foremost, it scares healthy folks into thinking they need insurance, for someday "that could be me." Second, when you get a decent slice of the pie, having sick people in the pool makes the pie that much bigger. Having too many sick people would become an unmanageable problem for the insurance industry, I suppose, but we're probably not yet near that upper limit. (The phrase "supply-side sickonomics" keeps rumbling through my head, but I've no idea what the practical interpretation of that would be.)
Once you get past the insurance industry, the rest is easy. The best customer for the health care industry is one that is in need of its services for that person's entire life. Preferably, whatever the person has shouldn't significantly shorten their lifespan (not more than five or ten percent), or be so debilitating that they can't earn enough to cover premiums. From this, it's obvious that people with diabetes, arthritis, asthma, obesity, depression, or even allergies are all the health industry's best customers. And guess what? These are exactly the kinds of diseases that we've seen steadily increase in the last several decades, in lockstep with the growth of the health care industry itself.
This is not a coincidence. We've put the health care industry into a (somewhat) free market, and that market has done what markets do: find growth strategies. I'd like to think that no one in the world said out loud, "...and if we push more corn sweeteners on Americans, the income from our medical arm will rise proportionately with obesity", or at least I hope that no one in any position of power was saying that, but marketplaces have a way of finding efficiencies that are beyond the ken of the average human or the most sophisticated economic model. (I believe economics is a matter of vast numbers of interactions combined with huge stochastic, psychological and often irrational components that are either largely ignored and/or misunderstood. To talk about the efficiencies of the marketplace is somewhat misguided. A marketplace is efficient the way an ant colony is efficient at constructing burrows or foraging. It's an illusion of patterns and order arising from an enormous number of events, most of which are random. In other words, a marketplace will usually be more efficient than chaos. Conversely, since a planned economy can't actually take into account all the variables involved and is thereby constrained to using gross simplifications, it will always be less efficient than chaos. This may be why Somalia rolls on while the Soviet Union has collapsed.)
I think there's a way to correct this situation, but I'm not bright enough to find an implementation. All the same, here's the general notion. Restructure the market to place value on people being healthy. One possibility would be to place future contracts on the health of individuals. These contracts would pay premiums based on the projected quality and length of life for the individual. Everyone would have buy-in on the future, and the payout is the best for everyone (health providers and providees) when the person is living a long an healthy life.
Unhealthy individuals would benefit when someone takes it upon themselves to buy up their futures and increase their value, say by finding a cure for their disease.
I don't know how to make such a market work. Most futures markets don't look out that far, and this market would have to look forward four score and ten, give or take a decade. I don't know how we'd make trading on the options work, either. And I can certainly see some grim possibilities for abuse of such a market. The mafia don who's first inkling that he has a problem is when his own health futures start to plummet; the meat inspector that passes a load of contaminated hamburgers headed to the public schools, and then shorts the futures of the kiddies.
Well, maybe there's an alternative out there that could make some sort of market incentive work, and invert the setup we currently have. Otherwise I don't see how any market-based reform is going to work. Instead, we're going to have to remove market influences from the health care industry.
2009/02/18
Would Rezoning Help the Housing Crisis?
As millions of homeowners face foreclosure, the government is (slowly) moving forward with a combination of aid packages, mostly aimed at attempting to help people stay in the homes they are in and scale down their mortgages to something they can afford.
In many cases, this will be a losing battle. For example, in California I'm sure that many people who bought homes in the last five years kept up with the non-mortgage costs of ownership (CA's notorious real estate taxes plus upkeep and insurance) by drawing on the rising equity of their home. But that line of "cheap" credit has dried up, as home prices continuing to wilt. Even if their mortgage payments go to zero, many people won't be able to cover their remaining costs because they were borrowing against the future, and presumably infinite increase in the value of their home.
In other words, the hole is so deep that the billions committed to fill it will hardly matter. In six months it will have made as much difference as the money that was poured into the auto companies last December.
So are there other alternatives that are not being discussed that could help alleviate this situation? Say, rezoning neighborhoods that have high default rates?
Most neighborhoods (and I'm willing to bet most of the neighborhoods that are in real trouble today) are zoned as single-family dwellings, often with strict limits on the number of unrelated occupants, and the types of businesses allowed, if any are allowed at all.
If these zoning laws were relaxed to allow reasonable numbers of boarders into homes, or to allow subdivision of McMansions into duplexes or triplexes, and if small businesses like restaurants and convenience stores were allowed to operate, jobs would be created, incomes generated, and owner costs lowered as owners made legitimate business deductions against their property. On the state's side, that reduction in real estate taxes would probably be offset by the other gains in sales and income taxes.
Another possibility would be to allow selective homesteading of foreclosed and abandoned homes. I hear that this is already happening, unhindered, in some parts of the country.
Of course, when markets collapse another way to prop up prices is to reduce the supply, in this case bulldozing a significant number of houses. That doesn't really look practical.
In many cases, this will be a losing battle. For example, in California I'm sure that many people who bought homes in the last five years kept up with the non-mortgage costs of ownership (CA's notorious real estate taxes plus upkeep and insurance) by drawing on the rising equity of their home. But that line of "cheap" credit has dried up, as home prices continuing to wilt. Even if their mortgage payments go to zero, many people won't be able to cover their remaining costs because they were borrowing against the future, and presumably infinite increase in the value of their home.
In other words, the hole is so deep that the billions committed to fill it will hardly matter. In six months it will have made as much difference as the money that was poured into the auto companies last December.
So are there other alternatives that are not being discussed that could help alleviate this situation? Say, rezoning neighborhoods that have high default rates?
Most neighborhoods (and I'm willing to bet most of the neighborhoods that are in real trouble today) are zoned as single-family dwellings, often with strict limits on the number of unrelated occupants, and the types of businesses allowed, if any are allowed at all.
If these zoning laws were relaxed to allow reasonable numbers of boarders into homes, or to allow subdivision of McMansions into duplexes or triplexes, and if small businesses like restaurants and convenience stores were allowed to operate, jobs would be created, incomes generated, and owner costs lowered as owners made legitimate business deductions against their property. On the state's side, that reduction in real estate taxes would probably be offset by the other gains in sales and income taxes.
Another possibility would be to allow selective homesteading of foreclosed and abandoned homes. I hear that this is already happening, unhindered, in some parts of the country.
Of course, when markets collapse another way to prop up prices is to reduce the supply, in this case bulldozing a significant number of houses. That doesn't really look practical.
2008/01/11
On the Largeness of Code
Stevey's Blog Rants contained a nice rant about code size. This resonates with me in a big way. Stevey characterizes statically typed languages (meaning Java et al) as being overly verbose, and dynamic languages as being much more concise. Among the reasons for this, Stevey points at the static type system as adding a lot of overhead. But he didn't go into a lot of detail as to why this is so.
I think there are at least three reasons:
Over one thousand lines of code for a dlist! Everyone who has taken a class in data structures has probably hand-coded a one-off dlist, but they didn't need a thousand lines of code to do it.
So what is the dynamic language equivalent of a dlist, and how big is it? Truthfully, I don't know. I've never seen a doubly linked list in a dynamic language. Perhaps my experience is too shallow, or perhaps its because all these languages come with built-in lists that are good enough 99.9% of the time. The programmer doesn't have to worry about the underlying functionality, whether its doubly linked, singly linked, blocks of arrays, or whatever. The lists just work, you can easily rearrange things on both ends, and performance isn't usually an issue. So in this competition to implement dlists we have:
Static languages: 1,100
Dynamic languages: zero
And in this case as in golf, small numbers are are better. So why should we be concerned about this? Well, I have a feeling that as goes the dlist, so goes the rest of the program. If it takes a thousand lines of code to implement a simple algorithm, then every trivial little thing is going to take a lot of code, and before long, we're talking megalines.
Another really interesting aspect of this is not just the bulk of code needed to implement a dlist. It's the fact that the class exists at all. Browse a popular C++ library (boost comes to mind) or if you have a taste for obscure languages, the Eiffel library. There are a plethora of classes that define algorithms and data structures. Linked lists, trees, hash tables, hashed sets, queues, dequeues, stacks and so on. In the current distribution of the Eiffel compiler, there over 120 classes with the word "list" in the name.
Now browse the standard distribution for Perl or Python. There are broad categories for protocols, frameworks and interfaces, things like SOAP, xmlrpc, SMTP, Apache mods, test rigs, and so on. In the 5.8 Perl distribution on my machine, there are only 3 modules with "list" in the name. These libraries all exist for the statically typed languages too, but they're piled on top of all the algorithms and data structures mentioned above. This leads to more problems that I'll discuss below.
So where are all the data structure libraries for Perl and Python? They are out there, but they're not needed for most day to day coding. If you need a tree in Perl, you make do with a list of lists, since that's a natural enough way of representing a tree. You don't need a tree class implemented with thousands of lines.
All of these classes that focus on algorithms and data structures are interesting -- to a software technogeek. And at one time when memory and processor cycles were at a premium, they were highly relevant (they still are in specific applications). But today for the majority of programmers and applications, I think they just get in the way and obfuscate the problem that's being tackled. After parsing an XML file, I just need an interface that lets me easily traverse it. I don't want a boatload of classes between me and the actual data.
So I think this is the first reason for code bloat with statically typed languages: an overemphasis on algorithms and data structures. This is a permanently embedded feature of the territory. Certainly you couldn't take the average C++ list class and expect to get very far shoving arbitrary lists of lists into it to emulate a tree.
The second thing that adds to code bloat is that these classes, combined with design patterns, leads to a proliferation of intermediate state. It has to, because all those algorithms and structures need to track a lot of information to handle what they're doing. Contributing to this, the data used by their higher libraries are often in the "wrong" container, say an arrayed list instead of a linked list, and more code is needed to mesh different representations.
So you've got all these data structures that aren't needed in a dynamic language, and all this state to help manage them, and all this code to manage all this state. This also means that the client of these classes has to manage a lot of their own internal state about the objects they're working with (hence the need for things like type-specific iterators for C++ container classes, and so on).
The ironic thing is that all of these algo-structures are meant to provide some performance gain or convenience for manipulating data. A dlist is more efficient than an array for some operations; a tree is more efficient than a dlist for others. But in most applications, it doesn't matter. Other constraints, like disk I/O or network traffic or user input often dominate. Or the performance difference isn't really noticeable; computation is cheap these days.
Brief digression: at one company a few years ago, the performance of a data processing program had slowed to a crawl. Another rather arrogant programmer spent several months re-implementing the B-Tree algorithm at its core using a combined heap and splay tree. The result was a marginal performance improvement. Months later, I found a horribly inefficient sort algorithm at the bottom of the program, replaced it, and got a 90% increase in performance. The focus on data structures was entirely misplaced and significantly increased the complexity of the code.
So these are two reasons for statically typed language bloat. There's a third reason: there are just some things you can't do in a statically typed language that you can do in a dynamic language. I'm thinking in particular of metaprogramming and declarative programming. When I first started working with these notions I was very leery of them. It felt a bit like putting the crazies in charge of the insane asylum. I can barely control what's going on in my program now, and I'm going to have the program write code for itself? Crazy indeed.
Yet these are incredibly powerful concepts that can lead to very a concise solution to a problem. An example of this (and where I cut my teeth on metaprogramming) can be seen in the bOP library from Bivio. Intended for developing Web sites, bOP makes extensive use of metaprogramming metadata and code generation. If you look at the Petshop example ( you can view the source for each page online), you won't see much HTML, and in fact a lot of the pages look like large data declarations (lists of lists). The data is just the relevant attributes for a given page, perhaps with references to data objects for populating fields, controls and tables.
The whole thing is very sophisticated and very concise. It's also challenging to read if you're not a Perl aficionado. Yet the point remains that Bivio is able to implement large, real-world applications with very small teams, and very small software artifacts, especially when compared to the Java equivalent.
A few years ago AOP was making a big splash in the Java world. AOP is really just a very constrained form of metaprogramming. After the initial splash, interest in it seems to have died down, I think in part to anti-competitive practices of proponents of AOP, but that's a separate rant. I think another reason it faded is precisely because it is limited. It was too easy to hit those limitations, and AOP didn't provide a way of overcoming them.
I think there are at least three reasons:
- Libraries for static languages tend to focus on data structures and algorithms over protocols
- Because of this emphasis on structures and algorithms, the code ends up shuffling a lot of data around, for no net benefit
- By their nature, static languages wall off an entire domain of programming techniques that can drastically reduce source code overhead
Over one thousand lines of code for a dlist! Everyone who has taken a class in data structures has probably hand-coded a one-off dlist, but they didn't need a thousand lines of code to do it.
So what is the dynamic language equivalent of a dlist, and how big is it? Truthfully, I don't know. I've never seen a doubly linked list in a dynamic language. Perhaps my experience is too shallow, or perhaps its because all these languages come with built-in lists that are good enough 99.9% of the time. The programmer doesn't have to worry about the underlying functionality, whether its doubly linked, singly linked, blocks of arrays, or whatever. The lists just work, you can easily rearrange things on both ends, and performance isn't usually an issue. So in this competition to implement dlists we have:
Static languages: 1,100
Dynamic languages: zero
And in this case as in golf, small numbers are are better. So why should we be concerned about this? Well, I have a feeling that as goes the dlist, so goes the rest of the program. If it takes a thousand lines of code to implement a simple algorithm, then every trivial little thing is going to take a lot of code, and before long, we're talking megalines.
Another really interesting aspect of this is not just the bulk of code needed to implement a dlist. It's the fact that the class exists at all. Browse a popular C++ library (boost comes to mind) or if you have a taste for obscure languages, the Eiffel library. There are a plethora of classes that define algorithms and data structures. Linked lists, trees, hash tables, hashed sets, queues, dequeues, stacks and so on. In the current distribution of the Eiffel compiler, there over 120 classes with the word "list" in the name.
Now browse the standard distribution for Perl or Python. There are broad categories for protocols, frameworks and interfaces, things like SOAP, xmlrpc, SMTP, Apache mods, test rigs, and so on. In the 5.8 Perl distribution on my machine, there are only 3 modules with "list" in the name. These libraries all exist for the statically typed languages too, but they're piled on top of all the algorithms and data structures mentioned above. This leads to more problems that I'll discuss below.
So where are all the data structure libraries for Perl and Python? They are out there, but they're not needed for most day to day coding. If you need a tree in Perl, you make do with a list of lists, since that's a natural enough way of representing a tree. You don't need a tree class implemented with thousands of lines.
All of these classes that focus on algorithms and data structures are interesting -- to a software technogeek. And at one time when memory and processor cycles were at a premium, they were highly relevant (they still are in specific applications). But today for the majority of programmers and applications, I think they just get in the way and obfuscate the problem that's being tackled. After parsing an XML file, I just need an interface that lets me easily traverse it. I don't want a boatload of classes between me and the actual data.
So I think this is the first reason for code bloat with statically typed languages: an overemphasis on algorithms and data structures. This is a permanently embedded feature of the territory. Certainly you couldn't take the average C++ list class and expect to get very far shoving arbitrary lists of lists into it to emulate a tree.
The second thing that adds to code bloat is that these classes, combined with design patterns, leads to a proliferation of intermediate state. It has to, because all those algorithms and structures need to track a lot of information to handle what they're doing. Contributing to this, the data used by their higher libraries are often in the "wrong" container, say an arrayed list instead of a linked list, and more code is needed to mesh different representations.
So you've got all these data structures that aren't needed in a dynamic language, and all this state to help manage them, and all this code to manage all this state. This also means that the client of these classes has to manage a lot of their own internal state about the objects they're working with (hence the need for things like type-specific iterators for C++ container classes, and so on).
The ironic thing is that all of these algo-structures are meant to provide some performance gain or convenience for manipulating data. A dlist is more efficient than an array for some operations; a tree is more efficient than a dlist for others. But in most applications, it doesn't matter. Other constraints, like disk I/O or network traffic or user input often dominate. Or the performance difference isn't really noticeable; computation is cheap these days.
Brief digression: at one company a few years ago, the performance of a data processing program had slowed to a crawl. Another rather arrogant programmer spent several months re-implementing the B-Tree algorithm at its core using a combined heap and splay tree. The result was a marginal performance improvement. Months later, I found a horribly inefficient sort algorithm at the bottom of the program, replaced it, and got a 90% increase in performance. The focus on data structures was entirely misplaced and significantly increased the complexity of the code.
So these are two reasons for statically typed language bloat. There's a third reason: there are just some things you can't do in a statically typed language that you can do in a dynamic language. I'm thinking in particular of metaprogramming and declarative programming. When I first started working with these notions I was very leery of them. It felt a bit like putting the crazies in charge of the insane asylum. I can barely control what's going on in my program now, and I'm going to have the program write code for itself? Crazy indeed.
Yet these are incredibly powerful concepts that can lead to very a concise solution to a problem. An example of this (and where I cut my teeth on metaprogramming) can be seen in the bOP library from Bivio. Intended for developing Web sites, bOP makes extensive use of metaprogramming metadata and code generation. If you look at the Petshop example ( you can view the source for each page online), you won't see much HTML, and in fact a lot of the pages look like large data declarations (lists of lists). The data is just the relevant attributes for a given page, perhaps with references to data objects for populating fields, controls and tables.
The whole thing is very sophisticated and very concise. It's also challenging to read if you're not a Perl aficionado. Yet the point remains that Bivio is able to implement large, real-world applications with very small teams, and very small software artifacts, especially when compared to the Java equivalent.
A few years ago AOP was making a big splash in the Java world. AOP is really just a very constrained form of metaprogramming. After the initial splash, interest in it seems to have died down, I think in part to anti-competitive practices of proponents of AOP, but that's a separate rant. I think another reason it faded is precisely because it is limited. It was too easy to hit those limitations, and AOP didn't provide a way of overcoming them.
2007/06/24
Riding in the California Coast Classic
It was with a great deal of excitement that I participated in the California Coast Classic, a bicycle tour from San Francisco to Los Angeles that benefits the Arthritis Foundation. I've recently signed up to participate again for 2008.
The tour covers 500 miles in eight days. I began training for this ride back last March. When I started out, a 40 mile ride was an ordeal, and I'd have to get off my bike to walk it up the steeper hills. Training for this ride is an enormous time commitment, and I'm especially grateful to my family for supporting me in this, especially to my wife who has been encouraging me to continue and who was extraordinarily helpful in my fundraising.
The tour covers 500 miles in eight days. I began training for this ride back last March. When I started out, a 40 mile ride was an ordeal, and I'd have to get off my bike to walk it up the steeper hills. Training for this ride is an enormous time commitment, and I'm especially grateful to my family for supporting me in this, especially to my wife who has been encouraging me to continue and who was extraordinarily helpful in my fundraising.
2006/10/12
Chinese Job Title
A while back I attended a dinner with some people from a university in mainland China. The headmost honcho gave me a business card with the following job title embossed upon it.
Vice Party Secretary -- Secretary of Discipline Inspection Commission
Now there's a title to ponder. Indeed I'm pondering the fact that I can't think of any possible equivalent title within the United states
Vice Party Secretary -- Secretary of Discipline Inspection Commission
Now there's a title to ponder. Indeed I'm pondering the fact that I can't think of any possible equivalent title within the United states
2006/10/11
I Hate Karaoke
Not long after we was married, my wife and I spent an evening in a sushi restaurant on a Saturday night -- karaoke night -- and this was back when it was a rockin'place to hang out before this anal japanese american smoothboy took over management of the place and sucked out all the fun. Anyway, people are getting up and banging out one silly-assed out-of-tune song after another, and I'm thinking my gawd I could get a better sound by hurling cats into a pile of broken ukuleles (I thought about making the analogy a pile of guitars but ukuleles are funnier and should be broken but I digress), I don't have perfect pitch, but apparently it's less imperfect than the pitch of people who enjoy karaoke, and my new wife insists that I get up and sing a song, so I do the smart thing, I pick a song that can be shouted and not sound bad: Bob Seeger's "Old Time Rock and Roll", and right after my pick is announced whoo boy this hot young blond babe runs up to stand next to me and in her babe-giggly way says "I'm going to sing this song with you!"
Okay I'm thinking somebody standing up here has serious bad timing, like maybe I should have tried singing karaoke when I was still single and not after I've married the greenest-eyed killer babe on the planet so I do the only thing I can think of, I treat this woman like she's got this horrible wart disease and to even glance at her is to get horrible warts and I focus really hard on the teleprompter lyrics as if it's a really hard song to follow but that only looks stupid because it's hard to follow the way a garbage truck is hard to follow along highway 101 during rush hour.
Then there was the time I had to listen to karaoke in a Chinese Army Officer's club (that's Communist China buddy), and what do you say to a colonel in the Chinese Army who's probably used to shooting noncoms and citizens who squint bad at him, when he asks you how you like his singing and the honest answer is to compare it unfavorably to the sound of chainsaws cutting up airplane wings?
Okay I'm thinking somebody standing up here has serious bad timing, like maybe I should have tried singing karaoke when I was still single and not after I've married the greenest-eyed killer babe on the planet so I do the only thing I can think of, I treat this woman like she's got this horrible wart disease and to even glance at her is to get horrible warts and I focus really hard on the teleprompter lyrics as if it's a really hard song to follow but that only looks stupid because it's hard to follow the way a garbage truck is hard to follow along highway 101 during rush hour.
Then there was the time I had to listen to karaoke in a Chinese Army Officer's club (that's Communist China buddy), and what do you say to a colonel in the Chinese Army who's probably used to shooting noncoms and citizens who squint bad at him, when he asks you how you like his singing and the honest answer is to compare it unfavorably to the sound of chainsaws cutting up airplane wings?
Subscribe to:
Posts (Atom)