Saturday, September 29, 2007

Rant: Get Over It; Pluto Is NOT a Planet

Pluto is NOT a planet. Get over it.

For some reason, people seem to be offended that the International Astronomical Union stripped it of its ranks and recategorized it as a Dwarf planet.

And as a good scientist, I'm horrified how many people make their scientific decisions based off of raw emotions and no logics or fact!

That isn't to say that, in practice, science isn't driven by politics and emotions; but just because your immature little brother is being bad, doesn't mean you should as well.

So in order to set a good example to the emotionally driven ignorant masses, let's get to work on why Pluto cannot be a planet.

The Crux

The key to all of this is that there is no way to make a simple and impartial definition of a planet that includes Pluto with the other eight planets.

This is important enough to repeat:

There is NO simple, impartial definition we can apply to the word "planet" that includes the standard 9 planets, and only those 9 planets.

Lets Try Our Hand At This

Let's try our best to make a definition for planet that includes Pluto and see what happens:

So first thing first, let's try the most obvious definition. Let's try to limit by size. Since Pluto is about 2,400km in diameter, we'll try the following definition:

Definition #1: "A planet is any body bigger than 2,000km in diameter, whose primary gravitational influence is the Sun."

So now let's vet this one to see how it works out for Pluto.

If we consider the second part of the statement, "...whose primary gravitational influence is the Sun". As it turns out, depending on where Pluto is in its orbit, the gravitational pull between Pluto and Charon is somewhere between 40 and 110 times as strong as that of Pluto and the Sun! Thus the first thing we need to consider is a better definition of how the gravity of the Sun affects the orbit of the planet!

So let's try another definition.

Definition #2: "A planet is any body bigger than 2,000km in diameter, whose local system orbits the Sun, and who is not the satellite of another planet."

But whoops! It turns out that then we'd have to have 10 planets, because Eris--which was discovered in 2005--is a few kilometers bigger in diameter, and is almost 30% more massive--than Pluto!

Indeed, to put the size of things into perspective, it turns out there are seven moons of established planets that are bigger than Pluto, including our own moon!

Furthermore, there was no scientific reason why we chose a diameter of 2,000km as the minimum limit in the first place. It was just an arbitrary number that was pulled out of thin air in an effort to make Pluto a planet, but other similar objects not!

Indeed, if we tried to scientifically pick a minimum diameter, we'd probably want to pick the critical radius where gravity pulls the object into a spheroidal shape. This This diameter depends on the material of the body, but is often around 400km to 500km in diameter, which is about 5 times smaller than Pluto, and includes at least several Kupier Belt Objects, as well as the largest asteroid in the Asteroid Belt, Ceres!

Indeed, as we discover more and more Kupier Belt Objects, this definition could lead to dozens or even hundreds of planets!

So size (and mass) turned out to be a really bad way of defining what is and is not a planet.

So lets this another way entirely. What can we say about the orbits of the planets?

Well, let's look at how circular the orbit is; which is called its eccentricity. If we look at most of the planets, the eccentricity is such that the oribtal path is reasonably close to circular.

But this fails for Pluto. Pluto's orbit goes from around 30 AUs at its closest to the sun, to nearly 50 AUs at its farthest. Thus its orbit is nearly 1.7 times longer than it is wide making it pretty oval in shape.

But it gets worse. This test also fails for Mercury, whose eccentricity is almost as bad as Pluto's, while the asteroid Ceres has about the same eccentricity as Mars.

So if we try to use the shape of the orbit as a criteria, we endanger the planetary status of Mercury, while possibly allowing the asteroid Ceres as a planet!

So what if we look at the inclination of the orbit? Most of the planetary orbit's lie very nearly in the same plane as the Earth. In fact, most of the planets lie within 3.5 degrees of this plane.

However, this is very different for Pluto, whose orbit is inclined 17 degrees out of the Ecliptic Plane!

Even worse Mercury, at 7 degrees, has problems again!

It is inclined by over twice the amount of any other planet, and is getting pretty close to the orbital inclination of the asteroid Ceres, which is at about 10 degrees!

So once again, if we try to use an orbital parameter to define what is a planet, we endanger Mercury or include Ceres!

So it appears that we need to appeal to something else than orbit. Which leads me to wonder about Moons? Pluto has three moons, and all the other planets seem to have moons, while Ceres does not.

But wait; Mercury has no moons, while many other bodies in the solar system (such as some asteroids and Kupier Belt Objects) do. So this makes a horrible way of defining a planet as well.

An Analog From History

I keep bringing up Ceres for a reason. Ceres discovered in 1801, was the first asteroid found. However it was not always classified as an asteroid. Indeed, for about a half century, Ceres (along with the other three first found asteroids) were listed as planets in books and tables. Thus, for a good part of the 1800s, we had more than nine planets, and none of them were Pluto!

But as the number of astronomical bodies that all had nearly this same orbit grew, it became obvious that these were not best categorized as planets, but that they were best categorized on their own.

Indeed, this was a wise decision, as over the past 200 years the number of asteroids found has climbed over 100,000! Aren't we glad we don't have to learn about the 100,000 planets!

Kupier Has A Belt

So as it turns out, Pluto is smack in the middle of the Kupier Belt, and its only special attribute seems to be that it is one of the largest Kupier Belt Objects found so far.

Now since you are here, you probably don't know anything about the Kupier Belt. This is for good reason, because even though it had been conjectured to exist in the 1940's, it wasn't until the early 1990's that we were able to discover any object in it other than Pluto. Anyway, as a quickie overview, you can think of it much like an asteroid belt that is beyond the orbital distance of Neptune and upto 50 AU away. It contains thousands or even tens of thousands of objects, all in a similar orbit, and all with a similar chemical composition.

Indeed the composition of Pluto is much more like that of a comet, and the scientific evidence is mounting that many of the comets originated as Kupier Belt objects.

The Nail In The Coffin

Thus to continue considering Pluto a planet would be the same fallacy as having continued to cald the first four asteroids planets.

It would also mean coming up with an absurdly complicated definition of planet because we are too emotionally attached to what we knew

But since immediately after Pluto was found nearly 80 years ago, it has been conjectured that Pluto should not be called a planet because it doesn't belong with the others.

Good science is about progress, change, and admitting when we are wrong. And as we discover more about the structure of our solar system, we will have to continue to admit mistakes, change our definitions, and push scientific progress for the good of humanity.

Thursday, September 27, 2007

Anecdote: The Parable of Confused Direction

While sitting here enjoying my Moose Drool and trying to piece together an essay on how to keep from being one of those jerks that always needs to be right, I was reminded of an interesting skirmish I had with a friend over the stupidest thing.

Way Back In College

It was years ago, when we weren't even freshmen in college for a whole week. Now somehow it came-up, while sitting one night on the lawn outside our dorm, that we disagreed as to which direction was North.

Now, being academically inclined, I cannot let a disagreement go until it's come to a satisfactory resolution. So my first attempt to support my contradictory viewpoint was to point out the North Star and say "Look! See? That direction must be North!".

Unfortunately, we were both from a rural area where you could see an enormous multitude of stars, and so this brightly lit city sky, with its relatively few stars, obscured our ability to recognize the constellations. Thus, I was quite unperturbed when she disagreed with my assessment, and pointed at another star as being Polaris.

This led me to my second attempt: to have her recollect the companion we wandered about with all throughout those first wide-eyed days of college: a campus map. Now since we agreed on how the map oriented compared to where we were sitting, I tried to reason that maps almost always have North at the top. And therefore what she thought was North was actually West.

But since we did not have an actual map to point at a compass rose, my reasoning was rebutted by her with a simple: "Well, this map is different!"

So, after a little skirmish over the plausibility of her claim, in which she refused to budge on her position while finding no further arguments to support it, it dawned on me: I knew how to prove, beyond a shadow of a doubt, that her North could not possibly be North.

Now it needs to be noted that she was pointing in a direction perpendicular to mine, because she was using the local coast line, in accordance with her geographical experiences in other places, to discern which way was North.

So I pointed at the Moon, which was low on the horizon, and said "The Moon rises in the East and sets in the West. Therefore that direction is either East or West."

Now the Moon was in what was her "South", and so it became obvious that she was quite confused because her "North" was really either West or East, and either way it was clear that it could not possibly be North.

Now this was too much for her: she became entirely frustrated with the fact that she was proven wrong, and she jumped up with a face red with frustration and left in a hurried hissy!

Food For Thought

I was very annoyed with her reaction. I didn't want the discussion to end this way at all. All I really wanted was to find out the truth.

I was pretty certain I was correct, being that I have an obsession with maps (to which I think everybody should have an obsession with maps). But even though I knew the maps so well, that didn't mean that I was incapable of making a mistake. Everyone makes mistakes, and no one can know everything, so all I really wanted to do was discuss it out until we reached an agreement as to what was most likely the truth.

In fact, this was an exercise that one of my other great friends and I have always enjoyed. Most of our time together (mostly as teenagers) was spent tabling topics to hash out in search of a better understanding of the truth. His ability to put his ego aside--combined with his Spock-like calm logical approach--was often very frustrating for me because if you were wrong about something, he would slowly pin you down into a corner, never showing any sign of emotion the entire way.

But in the end, It was his Spock-like calm and logic that I can thank for having learned how to overcome my own ego and to admit when I am wrong.

Unfortunately, my good friend in this story was unable to do the same thing in her younger years, whch led to many unfortunate consequences including alienated friendships and stagnation of ideas.

More Beer?

So now that I've managed to throw this thought out onto the page, the real question I have for all of you is if there is another Moose Drool in the fridge.

Video: BNSF Speeding Through Crossing

Since before I can remember, I've loved trains. I grew up riding steam trains on vacations with my parents, and am now fortunate enough to live in an area where my good friend "rdw283" any myself can go railfanning when the wives let us.

And people wonder why I like Ruby on Rails!

About a half mile from my house is this fun crossing where the BNSF blasts through at 50+ mph on the tail end of their acceleration push out of the Yardly yards in Spokane.

I caught this one this summer:

If you are interested in seeing more, you can check out my YouTube page at

Wednesday, September 26, 2007

Tip: Emacs and Vim Suck; JOE to the rescue!

Being a software architect and developer at RedPine Services, I often find myself working from the command line for a variety of purposes and on a variety of hardware. Unfortunately, I find the standard compliment of command line text editors to be lackluster.

I've found that most systems come bundled with three major editors: Emacs, Vi/Vim, and Pico. Although I use vim as my primary editor, I wish I didn't have to. All thee of these editors have major drawbacks:

  • Emacs is very large, complex, and cumbersome. Sure, it is very powerful, but it takes a lot of time and a good memory to learn all the unnecissarily long, funky key combinations, and until you've learned them, using Emacs from the CLI is impossible. This kills its approachability and leads me to wonder how it ever gained popularity in the first place.
  • Vi/Vim is also very powerful, but its unique and strange input mode vs. command mode paradigm makes it hard to pick-up, and its non-standard key commands make it difficult to learn as well.
  • Pico is sort of the opposite. It is very easy to pick-up and learn, with the most important key commands being shown as help right on the screen. This is very helpful for any novice, as you don't have to go fishing for the key command to bring up help or to save or to quit like you do with Emacs and Vim. The downside, though, is that Pico was made for e-mail composition purposes (being the bundled text editor for PINE) and thus lacks many features (and wraps and destroys your carefully made code and config files if you don't provide the right option on the command line!)

Now I admit that I use Vim in my everyday life because it is on all the systems and servers I have to work with in my professional career, and because Emacs is the complete opposite of what I value in a text editor. But no matter how much I use it, I can't shake my wish that people would always bundle the text editor that I used in my younger years: JOE.

I came across JOE as a teenager when my family first signed up for internet access with the ISP It has much of the simplicity and accessibility as Pico, while having most of the power features people actually want.

The key to JOE is its accessibility. When you first open it, you are presented with a screen that is intuitive to use and navigate, and which has a prominent message displaying how to get to the inline help screens, which can be toggled on and off at any time during use.

Thus you can just jump right in and go with JOE!

Then, as you use JOE more and more, you can start moving deeper and deeper into the help screens to learn how to use functionality such as buffers and simultaneous multi-buffer display.

I recommend that everyone that programs, who is unhappy with emacs and vim, give joe a look. It is easily downloaded, compiled, and install with the standard ./configure && make && sudo make install routine on Linux and Mac OS X.

Check-out JOE on SourceForge to get your copy now.

Rant: Flame-War Fueling Language Reviews

One of my big pet peeves is people who start flame-wars over programming language choice. It is as if they think that they are righteous enough to force their one way of thinking about the narrow scope of tasks they solve, upon everyone else. Furthermore, it appears to me as if the majority of these arguments are fueled by the narrow-minded ignorance of those who do not take the time to actually understand the language that the proclaim to hate so much.

One example of this that sticks in my mind was a rant article I read in the early days of Java, which was written by a C++ aficionado. He spent a couple days learning Java and then proclaimed a long list of problems that Java had and why he would never use it. Although at the time his arguments seemed to make sense, I came back a year later to find that all his claims were actually based out of ignorance of Java, and that none of those problems actually existed if he took the time to learn how to think in Java instead of C++.

Now, one thing that seems obvious, but is frequently glazed over in language wars, is that not everyone is trying to perform the same tasks with the language they are using. This means that everyone requires something different out of the language they write in. Actually, now that I think about it, let me rephrase it: everyone requires something different out of the tools they write in, which would be the API. So just like you wouldn't use a hammer to plant your flowers or a rake to build a bookcase, different APIs are necessary to solve different problems.

Thus the way I see it, if you find a language that fits your personal style, you should be able to write anything in it, as long as there is a good API to support what you need to do. Thus a good API is the single most important place to discuss a lanuage, and only when it is in the context of accomplishing specific tasks.

So maybe what really is the problem is that people seem to have such strong opinions about a language when what they really should be discussing is the strengths and shortcomings of the API.

This would help keep away the all too often scene of petty complaints about the language itself, which are rooted in ignorance of how to leverage the language, and result in false arguments as to the righteousness of their own choice of programming language that are easily seen as flawed by those more knowledgeable of the other side.

But there is one other issue I'd like to discuss: if it is a matter of API only, why don't we implement Operating Systems in ruby, for example? Surely we could build a suitable base API for ruby and then build the rest of the OS in ruby itself?

Of course, the reason why we don't is that ruby is in a runtime environment that gives it the flexibility of platform independence and fast turn-around times, but lacks the speed necessary to accomplish such tasks efficiently.

But this isn't the fault of the language. No. This is the fault of the compiler/runtime. The langauge, which is just a grammar and rules for how to execute the basic constructs of said grammar, should be capable of performance at least on par with Objective-C, if not better.

Indeed, most languages, if they had a bunch of resources thrown at an optimized native machine language compiler, should achieve similar performance at runtime.

So when it comes down to it, when we review "languages", there are really three parts that need to be discussed, and each one needs to be discussed in the proper context:

  1. API - Both the strengths and shortcomings.
  2. Performance - As compared to other languages that can solve the same tasks.
  3. Language - The kinds of people and projects that benefit and determent from the features of the langauge at hand.

So this brings me to one thing I have not discussed: The language itself:

Which languages you like is a matter of taste, and reflects upon you as a person. It naturally reflects on how you think and how you solve problems. But it also reflects on your ability to learn and adapt. Good programmers should always be learning and pushing their bounds, which always involves learning and understanding new languages. Unfortunately, too many people become comfortable in the one langauge they use and don't want to take the time to understand other languages. These same people, then, seem to always be the most vocal in the language flame-wars, usually displaying their ignorance to everyone in the process.

Expressing one's opinion is good, but people need to be more aware of what is their opinion versus what is fact; to be careful not to let their ignorance drive their zealous verbosity; and to support their viewpoint with calm and poise. Everyone is different and that is what makes life so rich and interesting. And while sharing ideas about what can make one language more useful than another is good, attempting to force everyone to conform to one way of thinking is not.

Tuesday, September 25, 2007

So Who Is This Guy?!

Before I started rambling about things like you care, I thought it would be nice to give you a little background about myself.

I grew up in a strange family with strange friends, doing strange things. This is what makes life interesting. If I weren't a strange person who grew up in a strange family, doing strange things, then I'd be boring and I'd have boring friends and be a robot. So being strange is a compliment.

For that matter, being a geek is a compliment (whereby I consider a geek to be a nerd with social skills). I've always been a geek and I'm proud of it. Okay, I'll come clean. I was a nerd until college and then I became a geek.

Anyway, Before I could read I had memorized all the planets in order (including the asteroid belt). As I got older I realized I actually couldn't remember anything, and hence I was bad at math and spelling; but when it came to concepts I was a very fastlearner.

So not to toot my own horn or anything, but in high school, as the curriculum changed from memorization to problem solving, I suddenly excelled over other students of my class in subjects such as math, science, and history. (Okay, so I am tooting my own horn on purpose, but I feel ashamed that I'm doing it.)

It was at that time that I discovered my first love is Physics. (Howwever, If you are my wife, then you are my first love!) In high school I was the first student in the district to ever take the AP Physics C test, I got an 800 on my SAT II in Physics, and went on to be one of 13 students who enrolled in the College of Creative Studies, which offers an advanced physics program at UC Santa Barbara. Through UCSB I was able to study physics and astronomy, culminating in learning about my favorite topic: General Relativity.

UCSB also allowed me to excel at another love of mine , which is teaching. My passion and exuberance for what I know translates into a passion and exuberance to share this knowledge with others. Through UCSB I was able to be a teaching assistant for several classes which enabled me to hone my teaching skills.

Although my training is technically in Physics, I learned something far more important. What I learned primarily was the ever important skills of self-learning and problem solving, which prepares you to be successful and anything you feel passionate about.

Which leads me to computers. I have always loved computers. Couple that with my passion for learning and problem solving, and it should be obvious that I am a self-taught software whiz. (Once again, I toot my own horn and feel bad doing so.) I've taught myself many languages over the years, each time striving to completely understand the language--how it works and how to think in it--before coming to a decision about which languages are right for me.

Nearly all my employment has been computer related. I have had several stints at Optical Coating Labs as a Java programmer, combining science, math, and software to write major components of their in-house thin film engineering software. And currently I work at the start-up RedPine Services as a software architect and developer, working to see through our dream for a top-notch healthcare software package.

So now I live in Spokane with my wife and three wonderful (though cheeky) step-children, enjoying my many hobbies (which include, but are not limited to: eating, sleeping, painting, video games, reading, watching TV, drinking good scotch, photography, playing piano or trumpet, writing music, listening to music, playing with my children), and adoring my wife whenever I can.