I'm working a C++ project for a contract I'm doing.  Originally, the 
client was thinking that they would like to have a scripting language embedded 
into the application eventually (and of course I've been advocating Ruby 
for this and they have been receptive since Ruby is used elsewhere within the 
organization).  Yesterday I needed to begin to define a configuration file 
format and the thought of parsing the config file in C++ was not 
pleasant...

Then it hit me... we alreay wrap all of our C++ objects with Swig so that 
we can do unit testing in Ruby using Test::Unit so why not take it a step 
further and use Ruby to tie together all of our C++ objects.  The idea 
being that instead of embedding Ruby into our C++ application we'll use 
Ruby to manipulate the objects defined by C++.  All of the comutationally 
intensive stuff is already done in those C++ classes so there won't be any 
performance hit.  We won't define a main() function on the C++ side, we'll 
just create the shared library from the swig wrappers and instantiate 
those objects in Ruby.

So, I wrote the parser for our input file in Ruby in about an hour (it 
would have taken substantially longer in C++) and started creating the 
frontend for the C++ part of the application in Ruby.  I actually think 
this will give us a lot more flexibility when compared to the alternative 
of embedding Ruby into the C++ app.  And since we were already using Swig 
for testing purposes it's not costing us any extra time and we don't need 
to take any extra time to embed Ruby.

So, why embed when you can swig? (hoping to start a philosophical 
discussion :-).

Phil