What I’ve put together here are the few issues we ran into and changes we had to make to get the application working under Postgres. Overall the code changes are minimal as we mostly use ActiveRecord code for communication, and in the places we write SQL directly it was mostly standards compliant. That said here’s what we did have to change.

TEXT and :limit

With MySQL, TEXT fields have a maximum length, and as such MySQL offers multiple types of TEXT fields. ¹ PostgreSQL’s TEXT field will auto-scale the field to fit whatever data it needs to contain. ²

Fix: Remove any :limits on TEXT fields.

Type Conversions

MySQL is very loose when it comes to dealing with types. If a field is an integer, you can send in a string and MySQL will convert what’s needed, and vice-versa. PostgreSQL however will complain if you pass in the wrong type.

Fix: Make sure you’re using the write types in your queries.

SUM(boolean_filed)

When you ask MySQL to SUM() a boolean field in a query, it happily returns the number of rows that are TRUE. This is because MySQL stores TRUE and FALSE as 1 and 0 respectively, thus SUM is simply a mathematical accumulation. PostgreSQL has a dedicated BOOLEAN column type, so this no longer works.

Fix: Change your SUM to be explicit about TRUE and FALSE:

sum(CASE boolean_field WHEN TRUE THEN 1 ELSE 0 END)

AS operator

MySQL has an implicit “AS” operator in it’s query parser, e.g.

select alias.some_column from table_name alias

PostgreSQL wants you to use the AS operator.

Fix: select alias.some_column from table_name AS alias

TIMESTAMP fields

Postgres has much finer precision with TIME fields. Where MySQL works with seconds, Postgres saves down to the microsecond ³.

Primary Key Sequences and resets (for Tests mainly)

Postgres in some cases doesn’t auto-reset your primary key sequences. When this happens you’ll run into tests that die with a unique key constraint error. Still working on the best way to solve this but for now you can do the following for each table in which you need the sequence reset:

ActiveRecord::Base.reset_pk_sequence!(table_name)

SQL Function Equivalents

MySQL: WEEK(), MONTH(), YEAR()
PostgreSQL: EXTRACT({day, month, week, year} FROM TIMESTAMP ‘…’) ⁴

MySQL: LIMIT offset, row_count
PostgreSQL: LIMIT row_count OFFSET offset

GROUP BY

It appears that MySQL does extra work underneath when dealing with GROUP BY. I ran into an issue where Postgres was complaining about missing fields in GROUP BY clauses. After doing some research, it seems that Postgres is strictly following the SQL spec where MySQL is not, so where MySQL auto-fills in the required GROUP BY columns if they are missing and can be inferred, PostgreSQL requires that you specify every GROUP BY column required in the query.

ORDER

Where MySQL defaults an ORDER BY to be the ids of the rows found, Postgres has undefined default sort order. ⁵ If your tests or code expect a certain order and the query doesn’t have an ORDER BY clause, your code will be nondeterministic. Adjust accordingly.

Data Migration

The easiest way to move data over from MySQL to PostgreSQL is to use ActiveRecord. While MySQL does have a “–postgres” option in mysqldump, it doesn’t really do the job it needs to, requiring some text manipulation of the data before PostgreSQL will accept it:

Other than that, and changing to the postgres gem, the conversion to PostgreSQL has been relatively painless so far. I’ll update this post if more issues come up.

1. http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html#id816304
2. http://www.postgresql.org/docs/9.1/interactive/datatype.html
3. http://www.postgresql.org/docs/9.1/interactive/datatype-datetime.html
4. http://www.postgresql.org/docs/9.1/static/functions-datetime.html
5. http://www.postgresql.org/docs/9.1/interactive/queries-order.html

So with that, I’m putting together this post to help clarify exactly how the various parts of Rice work together, how the entire process flows and more importantly helping anyone who’s wanting to learn and work on Rice with a solid starting point (or at least officially crooked). After reading this, anyone should be able to understand the various classes in Rice, and have an idea on where certain functionality lives when looking to add features, or address any bugs. So with that, we’ll start at the top.

What is Rice?

Rice is a wholly remarkable piece of software that takes complicated C++ classes, methods, types, etc and exposes them into Ruby using as simple an API as can be made. In short, you can take a C++ class such as:

class Generator {
  public:
    Generator(int seed) : mSeed(seed) { }
    ~Generator() { }
 
    int getRandomInt() { return 4; } // chosen by dice roll, guaranteed to be random
 
    void setSeed(int seed) { mSeed = seed; }
 
  private:
    int mSeed;
};

and use in in Ruby seemlessly:

g = Generator.new(5)
g.random_int          # => 4
g.seed = 10

through a very simple Rice wrapper Ruby extension:

void Init_generator() {
   define_class<Generator>("Generator").
      define_constructor(Constructor<Generator, int>()).
      define_method("random_int", &Generator::getRandomInt).
      define_method("seed=", &Generator::setSeed);
}

Were this class to be wrapped using Ruby’s C-API, every method on Generator, and even the constructor would have to be wrapped in a C method with calls into Ruby’s API (particularly Data_Make_Struct and Data_Get_Struct), very tedious and time consuming work, and at times quite error prone. So how does Rice make this tedious process as simple as four lines of code? C++ templates, and lots of them. We’ll go through each line here and dive into Rice itself to see what’s happening, but first, a quick word on Rice’s file naming convention.

ipp, hpp, cpp, _defn … what??

Because Rice is so template driven, most of the code cannot be pre compiled. That which can gets put into cpp files and ends up in librice.a, otherwise the core of Rice is template code generation which means only the code needed for the given extension is generated and compiled when building the extension itself. Given this, Rice still tries to strongly adhere to the separation of definition and implementation code. The definitions of classes are normally placed in [class_name]_defn.hpp, with the implementation placed in [class_name].ipp (to keep it separate from compilable code which gets placed in .cpp files). These two files are then combined in [class_name].hpp which is meant to be used in Rice extensions when including various pieces of functionality. When working inside of Rice and you need class definitions, you’ll want to use #include “[class_name]_defn.hpp” in most cases or risk running into circular dependencies and “already defined” compiler errors. Otherwise, when writing an extension using Rice, you’ll #include “[class_name].hpp” to ensure that all functionality is available for the extension.

As for the .mustache files, a lot of Rice’s template code is very repetitive and so instead of using complicated macros like Boost.Python does, Rice simply uses Ruby to generate the C++ code. Rice currently uses the Mustache library for this and the code for this process can be seen in rice/code_gen.

Defining a class: define_class

To expose a C++ class into Ruby you first need to define the class, give it a name, and tell Rice which C++ type this class is (as a side note, you can create a Ruby class not hooked to a C++ type, just don’t give define_class a type). The prototypes of define_class are found in Data_Type_defn.hpp. The one we are particularly interested in is:

//! Define a new data class in the default namespace.
/*! The class will have a base class of Object.
 *  \param T the C++ type of the wrapped class.
 *  \return the new class.
 */
template<typename T>
Rice::Data_Type<T> define_class(
    char const * name);

Following the code into Data_Type.ipp, we can see the implementation of this method:

template<typename T>
inline Rice::Data_Type<T> Rice::
define_class(
    char const * name)
{
  Class c(define_class(name, rb_cObject));
  c.undef_creation_funcs();
  return Data_Type<T>::template bind<void>(c);
}

This method starts out creating a new Rice::Class with the given name, making it a subclass of Object (aka a top-level Class, emulating what Ruby itself does). A quick jump into Class.cpp shows us that define_class(char*, VALUE) simply forwards off to the Ruby API call rb_define_class, then takes the resulting VALUE and wraps it into a Rice::Class.

Rice then undefines #alloc and #initialize to prepare the class for Rice’s own type management (to be discussed later). The third line of this method is what actually binds this new class to the C++ type, binding it as a top-level class (Data_Type::bind is templated to the superclass type, so void in this case).

Data_Type binding

Probably the most confusing, and at the same time most important, aspect of Rice is how it manages C++ types and their link into the Ruby world. Every C++ class that’s to be wrapped into Ruby must be bound to a Ruby class which is done in the static method Data_Type::bind (implemented in Data_Type.ipp). This logic forms the core of how Rice does automatic conversions from C++ types to Ruby types and vis-versa.

To start, every Data_Type<T> has a static pointer to a Ruby class (Data_Type<T>::klass_). After checking that this C++ class isn’t already bound to another Ruby class, bind() registers the Ruby class with the Ruby GC and sets up a Caster between this C++ type and the Ruby class (to be discussed later).

We’ve now got our C++ class Generator properly bound to the Ruby class Generator and can continue.

Adding methods to a class: define_method

We’re now at the point where we can start wrapping the methods on our Generator class. We’ll follow the code execution of wrapping the method Generator::getRandomInt(), starting with Module::define_method found in Module_impl.hpp.

Quick side note: Rice’s C++ API attempts to mimic Ruby’s top level Object structure, so the interplay between Data_Type, Module and Class can get confusing. Suffice it to say, class-based objects in Rice are all Rice::Module-s at the top, which then itself is a Rice::Object.

The specific define_method we’re interested in here is as follows:

  //! Define an instance method.
  /*! The method's implementation can be any function or member
   *  function.  A wrapper will be generated which will use from_ruby<>
   *  to convert the arguments from ruby types to C++ types before
   *  calling the function.  The return value will be converted back to
   *  ruby by using to_ruby().
   *  \param name the name of the method
   *  \param func the implementation of the function, either a function
   *  pointer or a member function pointer.
   *  \param arguments the list of arguments of this function, used for
   *  defining default parameters (optional)
   *  \return *this
   */
  template<typename Func_T>
  Derived_T & define_method(
      Identifier name,
      Func_T func,
      Arguments* arguments = 0);

The Rice::Arguments object has to do with the implementation of default argument definitions and I’ll get to that later.

This method is the beginning of where the true template craziness (genius? probably) happens. As a warning, if you are not comfortable with templates, the following is either going to confuse you, or it will open your eyes to a whole new level of possibilities in C++.

Rice works directly with Function Pointers and template definitions tailored to react to specific function pointer definitions to generate the appropriate code for properly wrapping C++ methods into Ruby. As a refresher, a C++ function pointer looks like this:

ReturnType (ClassName::*methodName)(ArgT1, ArgT2, ...);

so if we were to print out the function pointer of Generator::getRandomInt we would see:

int (Generator::*getRandomInt)();

This is what Func_T ends up being, a function pointer type. It can be a method with any return type, and any number and type of arguments, all handled by this one method. Looking at the implementation of this in Module_impl.ipp, we can see that execution is simply forwarded off to detail::define_method_and_auto_wrap given the Module/Class/Data_Type (*this), the name, the function pointer, any defined exception handler (this->handler) and the arguments object.

From this point, Rice needs to make a very important distinction on the method being wrapped: is it a class method, or a static method? The method Rice::detail::define_method_and_auto_wrap, defined in detail/define_method_and_auto_wrap.{hpp,ipp} uses Wrapped_Function classes, via wrap_function (detail/wrap_function.{hpp,ipp}) to make this distinction and to set up the final method object before finally jumping into Ruby’s C-API for finally exposing this method.

Auto_{,Member}_Function_Wrapper

Opening up detail/wrap_function.ipp you’ll see a very long file full of very repetitive method definitions. The key here is this method uses templates to match the passed in function pointer to one of Auto_Function_Wrapper (static functions) or Auto_Member_Function_Wrapper (a class instance method). Due to how Auto_{,Member}_Function_Wrapper works, wrap_function also has to have template specifications for functions with a return type and functions with void, as well as specifications to handle const and non-const function pointers.

To continue from here we need to understand how Rice actually hooks into Ruby. Glancing in detail/Auto_Function_Wrapper.hpp we’ll find template-overload classes similar to what’s in wrap_function. These classes are the core that handle argument and return type management as well as taking execution from Ruby and passing it into the related C++ function or method. What we’re going to focus on here is the ::call static method, though we’ll get to the details of this method’s implementations later.

Ruby’s API will only take C-style functions with the signature VALUE(*)(…). The Auto_…_Wrapper classes are the glue that gives us a function with this signature:

static VALUE Auto_Function_Wrapper::call(int argc, VALUE *argv, VALUE self);

If you’re familiar with Ruby’s C-API, then this signature should look familiar, it’s the -1 arity signature used when you want to support a variable number of arguments (in Rice’s case, default arguments). So how does a static function on a templated class work with an instance of this class to call the correct C++ method or function? It’s time to dive into detail/method_data.cpp, which defines define_method_with_data() as seen in the second part of define_method_and_auto_wrap() (Rice::protect is a wrapper around rb_protect to catch any exceptions and handle them gracefully).

detail/method_data.cpp

I’ll start this section with the comment block describing define_method_with_data():

// Define a method and attach data to it.
// The method looks to ruby like a normal aliased CFUNC, with a modified
// origin class.
//
// How this works:
//
// To store method data and have it registered with the GC, we need a
// "slot" to put it in.  This "slot" must be recognized and marked by
// the garbage collector.  There happens to be such a place we can put
// data, and it has to do with aliased methods.  When Ruby creates an
// alias for a method, it stores a reference to the original class in
// the method entry.  The form of the method entry differs from ruby
// version to ruby version, but the concept is the same across all of
// them.
// 
// In Rice, we make use of this by defining a method on a dummy class,
// then attaching that method to our real class.  The method is a real
// method in our class, but its origin class is our dummy class.
// 
// When Ruby makes a method call, it stores the origin class in the
// current stack frame.  When Ruby calls into Rice, we grab the origin
// class from the stack frame, then pull the data out of the origin
// class.  The data item is then used to determine how to convert
// arguments and return type, how to handle exceptions, etc.

Bear with me here as I still have a hard time keeping this straight in my mind. To help understand what exactly is going on here, I’ve made a graph showing all the relevant links between Rice, C++ and Ruby as made by this method.

The steps define_method_with_data takes:

1. Create a new class inside of the class we’re exposing (called the origin class).
2. Build a new two-element array that has [ 0xDA7A, VALUE pointer to Auto_..._Wrapper class]
3. Give the origin class an easily recognized name (which is also an invalid Ruby constant name, preventing it from every being accidentally used in Ruby code, but it prints out in object dumps on occasion).
4. Set this origin class to be FT_SINGLETON which hides it from the user¹.
5. Set a hidden ivar on the class that’s the array built in step 2
6. Define a method on the origin class that links to Auto_…_Wrapper::call with the requested name

At this point we’ve got everything ready except for actually being able to call the method from Ruby. These next steps were hard to show right on the graph because Rice actually modifies the symbol table of the base class in question.

7. Create an alias on the origin class that aliases the method to “dummy”
8. Find this new alias entry in the origin class’ symbol table
9. Modify the symbol table of the base class to call “dummy” on the origin class on any call to the method being wrapped.

We’ve now got everything hooked up: we have the c-style function hooked into Ruby and we have a way to access the actual Auto_…_Wrapper class once call() gets called. Now, you may be asking why this is such a complicated process when it could be done with a simple rb_define_method on Auto_…_Wrapper::call(). The answer to this question is show in the image above, there’s data and information saved in this Auto_…_Wrapper object that Rice needs to be able to properly convert argument and return types, and handle any exceptions that may get thrown.

With that, we’re done with the wrapping and exposing path through Rice. Now it’s time to head back up the chain and see how Rice handles calls from Ruby and passing execution back up into C++.

Auto_…_Wrapper::call()

It’s time to take a detailed look at this method. In short, once execution enters this method, it’s now Rice’s job to convert VALUE arguments into the appropriate C++ types, execute the wrapped method / function, then do any required conversion of return values back to VALUEs for Ruby, while also making sure that any exceptions that throw along the way are properly caught and handled (an uncaught exception in C++ will give you a SegmentationFault or a BusError. Always fun to debug).

So, first things first, we need to get back the Auto_…_Wrapper object we saved when we wrapped this function. This is done with the detail::method_data() function, details of which are easily seen and understood in detail/method_data.cpp. With this we run our arguments list through rb_scan_args then run through each argument and check if there’s was a default set in the wrapper and if we should use it (Side note: the sanitize<> template is a no-op right now and can be ignored. It’s there to attempt to clean out any references or const arguments that may come in to get the base type, but this was causing crashes on other wrappers. For now I assume there’s a possibility of a small memory leak here related to reference types). Once all the types are converted it’s time to actually call the C++ method or function, and handle the return type.

The noticeable difference between Auto_Member_Function_Wrapper and Auto_Function_Wrapper is that Auto_Function_Wrapper has some special handling for the “self” parameter. This functionality is here to support the ability to wrap C functions that are written in an OO way, such as:

Jukebox* newJukebox();
void play(Jukebox* jukebox, Song* song);
void stop(Jukebox* jukebox);
void addSong(Jukebox* jukebox, Song* song);
// etc.

Because of the special self handling of Auto_Function_Wrapper, these methods can be wrapped into a Jukebox class very simply:

define_class("Jukebox").
  define_method("initialize", &newJukebox).
  define_method("play", &play).
  define_method("stop", &stop).
  define_method("add_song", &addSong);

Other than this, the two classes are identical in functionality.

Constructor

Because constructors aren’t accessible via normal function pointers, Rice has to implement special handling of wrapping class constructors for proper instantiation. This is done through the Rice::Constructor class and the define_constructor method. The path here is mostly equivalent to define_method. Opening up Constructor.{hpp,ipp} you can see the same ::call() static method, with a much simpler body. Every Ruby object has a free slot accessible through DATA_PTR. It’s in this slot that C++ class instances are saved and used for type conversions as described next. Constructor::call creates this object and saves it in DATA_PTR for later use.

Default Arguments

The code for handling and managing Default Arguments is pretty easy to read, but how the syntax work is definitely cause for confusion. Pulled from Boost.Python’s implementation of this exact feature, this functionality uses the comma operator to string together Rice::Arg objects into a single Arguments object that’s then passed into the Wrapped_Function object for that method. Due to the fact the comma operator doesn’t even come into play if there’s a single argument to a method, I was forced to copy some functionality around to make this feature work in all situations. So where you see two methods, one which takes a Rice::Arguments* and one which takes a Rice::Arg*, that’s what’s going on. I hope to clean this up drastically in the near future.

to_ruby / from_ruby

The last piece of Rice’s functionality is the type conversion system, exposed to the user through two methods: to_ruby(), which takes a C/C++ type and converts it to a VALUE, and from_ruby() which does the opposite. The signatures of these methods are simple:

template<typename T>
T from_ruby(Rice::Object x);
 
template<typename T>
Rice::Object to_ruby(T const & x);

For most basic and fundamental types, the to_/from_ruby implementations are very simple and can be seen in to_from_ruby.ipp, but this is only half of the story.

Rice’s real strength comes in handling custom-defined C++ types and seamlessly converting them from Ruby to C++ and back again, making sure to handle inheritance (both C++ <=> C++ and C++ <=> Ruby) appropriately. The core of this functionality is found in Data_Type::from_ruby in Data_Type.ipp, and in the Rice::Caster class found in detail/Caster.hpp, but it begins at the end of Data_Type::bind, which creates a new Caster for the newly bound type:

  detail::Abstract_Caster * base_caster = Data_Type<Base_T>().caster();
  caster_.reset(new detail::Caster<T, Base_T>(base_caster, klass));
  Data_Type_Base::casters().insert(std::make_pair(klass, caster_.get()))

Caster is at the core very simple. It’s a class that enables Rice to build a tree of Casters that define how to cast from a Ruby type into a custom C++ type. The code above is simply building a new Caster linking the new type to the Ruby class, specifying any superclass type as needed, then registering this Caster with Rice’s Caster tree. From here it’s time to look at how Rice uses this Caster list in Data_Type::from_ruby() (which btw is called through ::convert() in detail/from_ruby.{hpp,ipp}).

In the case that the C++ type we want is exactly the Ruby type we’ve been given, casting is easy, make a new Data_Object for that type and get the pointer. If this doesn’t match, then we need to start heading up the inheritance heirarchy (rb_mod_ancestors) looking for the lowest class in the hierarchy bound in Rice, get it’s Caster and attempt to cast into C++. This functionality allows any depth of inheritance to work seamlessly in Rice.

The Future of Rice

Rice is currently a very capable library, and is being used successfully by a couple of projects, but it does have a long way to go to be the SWIG replacement (along with my rb++ suite) I want it to be. For the next release of Rice I’m current planning on the following work:

• Refactoring Auto_{,Member}_Function_Wrapper, Constructor, wrap_function, et.al. to be much simpler. Going to try to abstract out the actual method dispatch into a class like Auto_Functor_Wrapper which will handle all the to_/from_ruby and argument management magic.
• Default arguments on Constructor. To do this Constructor needs to act more like an Auto_Function_Wrapper, and thus would be much easier to implement once the refactoring above is done.
• Beginning into a def_helper (from Boost.Python) feature. Right now the implementation of default arguments is pretty messy. As I need to handle multiple arguments as well as a single argument, I’ve resorted to two define_method implementations to take these two cases. With some template magic, I can make it work with a single argument, as well as opening up a single place for call and return policy functionality, instead of multiple places that would be required today.

As always, I’m available over Github messages / Issues, Email, comments here, or on Rice’s mailing list (rice AT librelist DOT com). I’ve also got a public tracker up on Pivotal: http://www.pivotaltracker.com/projects/48783, but not sure how well that’s going to work for a free-time project such as this, though keeping a some-what strict time line is probably good for me, but I digress.

1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/336728

http://www.telegraph.co.uk/news/worldnews/northamerica/usa/6173399/Charles-Darwin-film-too-controversial-for-religious-America.html

The article does make some very good points. In America, religion rules. This can be seen especially today with the massive political upheaval of the recent elections, where we’ve got the “religious right” (mainly Christian, which I’m most familiar with) against the “secular left” fighting it out to the bitter end. What I have been trying to understand is why do less than half of all Americans believe in Evolution and how can we solve this? Is there a glaring and unrecoverable conflict between Evolution and Christianity? Is there any scientific evidence supporting either side? Is this an irrational, fearful reaction in the face of the unexpected and the new? And more importantly, why is it most Americans are so against Evolution while almost everyone else in the world has happily accepted the theory?

What is Evolution?

To make sure we’re on the same page, I want to specify the definition of ‘believe’ here. I’m going with Webster’s second definition:

b : to accept as true, genuine, or real .”¹,

When I talk about belief in Evolution, I’m simply talking about the acceptance of the scientific evidence in favor of Evolution, nothing religious.

Also, this post will be mostly on Biological Evolution, but will touch on the general idea of Young Earth and the Big Bang Theory.

Lets start with a quick primer on what Evolution actually is. First laid out in Charles Darwin’s Origin of Species in 1859, it’s the theory that states (paraphrased):

Biological evolution … is change in the properties of populations of organisms that transcend the lifetime of a single individual. The ontogeny of an individual is not considered evolution; individual organisms do not evolve. The changes in populations that are considered evolutionary are those that are inheritable via the genetic material from one generation to the next.²

The Theory of Evolution is the theory that species change over time. This change manifests itself in random mutations of the DNA defining an organism, which is passed down to offspring. If these mutations are harmful, the offspring don’t survive. If these mutations are neutral, or even beneficial to the organism, it survives to pass down these changes to it’s offspring, a process known as Survival of the Fittest. Following this process over thousands and even millions of years results in the diversity of life we see today.

Evolution today is used to explain a myriad of observations we’ve made in the biological world, from why there are hundreds of different species of pigeons, some slightly different, others completely different, yet definitely all pigeon, to why virii are impossible to vaccinate against and why cancer is such a brutal and difficult disease to fight.

So if Evolution is so successful in describing the biological we live in, why isn’t it more accepted here in the States, and in some cases attacked as a tool of Evil? Lets look at the Christian counter-argument known as Creationism.

Creationism

I used to be a Creationist. I was brought up in a rather conservative Christian home, and as the prevailing view of the Beginning of the Universe was Creationism, I naturally accepted and followed these beliefs. What follows is what I used to believe, and what I know about the movement.

Creationism has very simple roots: Genesis 1:1 (NIV).

In the beginning, God created the Heavens and the Earth.

What follows in verses two to the end of the chapter is a day-by-day account of what God created on each day, creating the entire Earth and everything on it, in six days. Creationists take this account literally, in that it took six days, as we define “day,” for God to create the Earth and all living things. They also believe that, as each day starts with “and God said…,” we all appeared here one day by the whim and will of God. Picture it as a blank sheet of paper, and start drawing animals, plants, and people. There was nothing, then there was everything.

Creationism’s biggest beef with Evolution is that Evolution seems to take God completely out of the picture. They commonly argue that Evolution says we’re “all here by accident” or “we’re a product of random chance.” They claim that because of this, Evolution goes directly against the Bible and thus (in the most extreme of cases) claim that Satan introduced Evolution into the scientists’ minds to drive people away from Christ. Past this, the next most popular argument Creationists have against Evolution is the idea of a biological part being unevolvable, such as the eyeball, saying Evolution cannot be true because the eyeball is so complex that it has to either exist, or not exist, there is no half-way-point because, according to Evolution, the part would have been deemed bad and been phased out many generations ago.

Where do I stand in this?

I’m still a Christian, but I can no longer accept the Creationist claims. I owe this change-of-mind to two books: Language of God by Francis S. Collins and Only a Theory by Kenneth R. Miller. These books showed me that one can believe in Evolution, and still be a Christian. For anyone on the fence, these are great books to start with, and what follows is a quick run down of the major arguments for Evolution, and how they fit into the Christian world-view.

Problems with Literal Bible Interpretations

Christianity has a very poor track record when it comes to literal translations of the Bible. The most poignant, and relevant, example would be the stories of Copernicus and Galileo. They had the audacity to suggest that the Earth actually revolves around the Sun, contradicting a long standing teaching of the Church that the Earth is obviously the center of the Universe, because the Bible says so. We all know how that one turned out.

So following this, are Creationists making another mistake in taking the Bible literally? It would appear so, as the first two chapters of Genesis give two (arguably three) different creation accounts.

Genesis 1:1 –

In the beginning, God created the Heavens and the Earth.

Gensis 1:2-31 –

• Day 1 – Light and Dark
• Day 2 – Land and Air
• Day 3 – Sea and Land, Vegitation
• Day 4 – Sun Moon and Stars
• Day 5 – Water Animals and Birds
• Day 6 – Land Animals and Man
• Day 7 – Rest

Genesis 2 –

• Earth and Water
• Man
• Vegitation
• Animals
• Woman

While the comparison isn’t one-to-one, it’s easy to see that the order of events do not match up. If one is to attempt to take the Bible completely literally, this is a difficult contradiction to overcome.

Other arguments against literal interpretations of the Bible include discussions of the Hebrew writing style, mainly that they wrote more in poems and stories, and that the writers were less concerned about factual accounts, but as I am not knowledgeable in this I’ll leave it at that.

Evolution’s “Random Chance”

A major misconception that is proving very difficult to dispel is this idea that Evolution is a completely random process. This idea couldn’t be farther from the truth. Most Evolution nay-sayers completely forget about, or do not completely understand, the concept of Survival of the Fittest. All mutations are put through the most strenuous of tests: surviving and reproducing. When mutations pass this test, they get fully integrated into that gene pool and thrive. When the mutations fail the test, the organism(s) die off and the mutation is lost. The key point here is that most mutations fail the test due to the random nature of the process mixed with the very complex nature of DNA.

Due to this, were our evolutionary process to be done over, we most assuredly wouldn’t be exactly the same, but fish would still be shaped like they are (for efficient movement through water) and birds would have wings and probably hollow bones (for light-weight and moving through the air). The limits imposed on organisms by the world they live in are what drive evolution failures and successes, we are not the direct result of a few thousand random mutations, we are the result of a select subset of mutations that survived among the millions that allowed us to survive and thrive in our environment.

Unevolvability

Another common argument against Evolution is this idea of “unevolvability.” Creationists say that there are biological components (the eye and bacteria flagellum, to name two) that simply cannot have evolved because if a single part is missing, the component is useless. Useless parts, of course, are not favored in Evolution and thus, these parts should not exist.

This is actually a very true statement, which lends towards it’s strength in the Creationism world. However, there is a very pivotal assumption being made in this argument that Evolutionists have found to be a false one. This is the assumption that the parts of these components are only useful in the component they’re found in today. I’ll paraphrase the argument made in Language of God on how a bacteria’s flagellum actually did evolve to show this point.

Flagellum³ is a collection of proteins used to propel bacteria through it’s environment in a rotating and/or whip-like manner. This is obviously a very complicated system, and if any of the many parts were to be missing, this locomotion would not be possible. This does not disprove Evolution though, because scientists have actually found parts of the flagellum being put to completely different uses⁴. For example, scientists have found a similar sub-construct being used as a secretion system.

I’ll admit this can be hard to understand for those of us who aren’t medically versed, but the point is this: the process of Evolution periodically takes a working and capable part, and mutates it to be something completely different. There is a lot we do not know about this process, but there is very strong evidence that biological constructs previously thought to be unevolvable are in fact a direct product of the evolution of various other constructs. For further information, here’s Wikipedia’s page on the evolution of the eye.

What Evolution Does Not Cover

Given all this, there are still a few points that Evolution and Science in general does not yet have answers for. Among these are:

1. How did life itself get started from a lifeless ball of rock orbiting a burning ball of gas?
2. The Big Bang. Something exploded, but where did that something come from?

If we can figure out how to answer question #1, that would be the biggest breakthrough in all of Science: the ability to create life. This of course has some very far reaching moral, religions, and philosophical issues to work through, for if Man can create life from lifelessness, does that new life have rights like the rest of us? And what does that mean for Man itself, the ownership of a life form, etc?

As for question #2, I’m not sure if that question can be answered scientifically. As our viewing technology gets more sophisticated, we can see closer and closer to Time Zero, but how do you see anything before the Big Bang and is there anything to really see?

What I Believe

So given all this, how exactly does my Christianity work with current scientific knowledge? I believe that God used and continues to use Evolution in our Universe (even outside of the Earth? we may never know, but there’s nothing stopping God from such a thing). I believe that there had to be something that God created out of the nothing that was the Void, and that this thing eventually exploded in the Big Bang.

I believe that at a certain point in our Evolutionary history, God had on his hands beings that were advanced enough intellectually to understand Him and to worship Him. He embodied these beings with souls and named them Adam and Eve, starting what we know call the Human Race.

I believe that God gave us Science and infinitely inquisitive minds and as such it’s impossible for Science to in any way disprove the existence of God. We are simply learning about the world that He put us in. Any scientific finding that seems to go against my personal beliefs should be a cause of reflection on the discovery and on the beliefs I hold, not of immediate rejection of the science in question.

Going Forward

So what can I do to help fix the state of affairs in this country? I can educate people. Talk with friends, discuss with family, and encourage people to branch out. I’ve found that the best way for me to strengthen my faith is to doubt what I believe. With doubt comes uncertainty, and the mind hates uncertainty, and will crave resolution, which requires more information. When I can take this one further and can get other people to doubt their fundamental ideals, the discussions and debates that follow can only help to strengthen my beliefs. If I can get a few people to change their thinking, they’ll do the same with others.

I realize that fanatics and extremist will always exist, but the key to defeating them is to ignore them, to defuse their movements. If they’re yelling at people, and no-ones listening, they’ll eventually go away. This won’t be easy, but it’s necessary if this country is going to stay the leader in scientific advancements.

Evolution is the process God put in place to bring about life on this Earth.

1. http://www.merriam-webster.com/dictionary/believe
2. http://www.talkorigins.org/faqs/evolution-definition.html
3. http://en.wikipedia.org/wiki/Flagellum
4. http://en.wikipedia.org/wiki/Evolution_of_flagella

I have to say, I’m impressed. I was appalled at the atrocities perpetrated by the Bush administration, especially now as more information gets leaked out, but what’s going on now is mind-boggling at best, and at worst will decimate our country to where we’ll never recover.

I refer, of course, to the constant Republican QQ-ing and stonewalling about the choices the Obama administration is making.

Ever time I hear a prominent Republican talk on TV, on the radio, or read something on the Internet, I hear nothing but “waaah waaah I’m not getting my way anymore so I’m going to make life difficult for everyone who doesn’t see things my way, waaah waaah!” Ironic, this, as it’s the old-folks that are acting like 8 year olds who aren’t getting their way.

Aparently, some of these people need a refresher for what THEY had a hand in for the past EIGHT YEARS:

• DOUBLING our National Debt from ~$5 trillion to > $10 trillion
• TWO wars, one justified one not
• The justified war in Afghanistan has been under-manned and assumed to be a “quick romp” to clear out the Taliban. Guess who’s back in power and even stronger?
• The unjustified war in Iraq has destroyed the friendships we had with many countries around the world and has made even MORE people angry at America, leading to MORE terrorists. Iraq will fall into civil war between Sunni and Shiite as soon as we leave, just you watch.
• Decimation of personal liberties through acts like the Patriot Act and the Digital Millennium Copyright Act (What did Benjamin Franklin say about safety and liberty?)
• Secret prison camps. Torture guidelines, Guantanamo Bay, Detention without Trial
• … and who knows what else we’ll find out about in the coming years

You guys have done a TERRIBLE job at running the country. Why should we trust, or even listen to, anything you guys have to say? You complain about lack of bi-partisanship, but then you don’t ever budge on your stances on bills. You guys are going to fight the new Supreme Court nominee (well, you’re probably still pissed that the exiting justice, David Souter, made you guys look like idiots, but I digress), only because it’s Obama’s choice, not one from your party.

You guys might mostly disagree with Limbaugh, but come on, you are all working towards Limbaugh’s ultimate hope, the “failure” of Barack Obama.

Do you care about this country? Or do you only care about your personal “values” that get thrown out of the window anyway once you’re in power?

Congratulations on losing most of the young vote (like myself), that’s really going to help you get back into power in the future. Oh and grats on alienating the Hispanic vote, and most of the Black vote too. In fact, the women vote is going to the Democrats as well (thank you Limbaugh!)! If anything, the self-inflicted implosion of the GOP has been very entertaining to watch, but the delusion that the party is still as relevant now as it was 20 years ago is causing far more damage than good.

That said, there is a simple solution to this problem:

Grow Up.

So the choice of theme made, the name came down to two: Forty-Two, otherwise known as The Answer, or Slartibartfast, because the name really doesn’t matter. I was leaning towards Forty-Two, and with an extra vote from a good friend of mine, it became the name.

I’ll probably update other parts of the site to fit the theme, like the subtitle and the categories. All in all, feels good to have a solidly named site.

Now, what do you get when you multiply six by nine?