The Traveling Astronomer Problem

Apropos of something I’m not quite ready to talk about, here is an interesting challenge:

How do you optimize your time at the telescope if you have a set of objects that you’d like to observe?

For instance, if you want to see as many Messier objects as you can in a single night, a portion of your night might use this sequence, suggested in the book “Messier Marathon Observer’s Guide

screen-shot-2010-09-16-at-104738-am

On the other hand, it looks like there’s a wasteful jog near Serpens Cauda — near the label “18h30m” in the image. That jog is the recommended sequence “M24-M25-M23” but if minimizing the path were the only criterion, it looks like it would be quicker to visit M25 “on the way” between M7 in Scorpius and M11 in Scutum.

Now, by no means do I want to be so presumptuous to suggest that Machholz “made a mistake” in his recommended order. Minimizing the path is not the only or even overwhelmingly-dominant criterion — if you’re really doing the Messier marathon, it’s customary to do it without the help of a computerized “goto” system and using easy-to-find objects and straight line “star hops” is a big deal.

Similarly, in the real world you’re going to be battling light pollution, clouds, and terrestrial obstructions.

But this visualization that I made using Google Earth and some Ruby code does suggest that it might be worth using the power of a computer to help you plan your evening’s viewing.

The bad news is that there are lots of possible paths one can take between all 110 Messier objects — 1588245541522742940425370312709077287172441023447356320758174831844456\
7162948183030959960131517678520479243672638179990208521148623422266876\
757623911219200000000000000000000000000 paths. Most of those paths are impossible for an Earth-based scope (as a matter of fact, there are only brief windows during the year when all the Messier objects are visible at night from a given location). And most paths could be rejected very quickly. But still, no matter how quickly you evaluate a path, there’s no way to use a computer to find the absolute shortest path between this many cities… er … graph nodes … er … sky targets.

The good news is that there are all sorts of wicked cool ways to find “pretty good” paths.

"The Ruby Programming Language" Gets Thumbs Up

Andrew Binstock says:

Ever-dependable O’Reilly just released Ruby Programming Language, which is without a doubt the definitive Ruby reference. Not only is it co-authored by Yukihiro “Matz” Matusmoto, the inventor of Ruby, but it is superbly well edited, so that every page is full of useful information presented clearly. And at more than 400 pages, that’s a lot of information. Couple this book with The Ruby Cookbook, which I reviewed on this blog, and you have probably the best 1-2 combination for learning and using Ruby.

I haven’t seen the book myself, but I trust Andrew’s judgment. I certainly agree on the value of The Ruby Cookbook.

Ruby 1.9 Available

Ruby 1.9, which involves a number of significant upgrades, is now available. This is development code, probably not ready for use in upcoming sprints / development cyclese, but I will be downloading it if for no other reason than to experiment with its Fibers implementation.

BS On Rails

Kurt Schrader wonders if he’s the first person to hit a point in a Rails app where he wonders if he’s “finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place?”

He says that:

  • He misses the refactoring tools of IDEA, and
  • Although it may have taken longer to reach, he feels he’s on “the same old curve to all of the standard problems you run into when programming a webapp in any language.”

Of course, he’s not the first person to see such problems. As I write about in a forthcoming column in SD Times, basically as soon as you start getting into professional-level complexity in Ruby, you start seeing that it’s no silver bullet. A great language, yes, but not a silver bullet.

Rails, too, is a very nice framework / DSL, but has huge shortcomings — contorting it to work with the naming not-quite-conventions of legacy databases is enough to make me consider it a “new projects only” tool.

Of course, refactoring IDEs have not been around for very long and it’s undoubtedly the case that people are striving to build refactoring Ruby IDEs. The challenge is making refactorings bullet-proof in a language with a dynamic type system. You can’t have a “press the button” refactoring that works 95% of the time. This is a mistake that even today’s refactoring IDEs make: the “review these changes” dialog they pop up. They’re about as useful as “Are you sure you want to delete that?” in file dialogs. No one actually considers the question, they just hit “OK” and see if it breaks.

First IronRuby Drop Available

John Lam details the first public availability of IronRuby. Couple reasons why I’m interested in this:

  • It’s Ruby
  • It’s the CLR
  • It’s a second data point for how to code for the DLR

I don’t think I’m going to be able to resist the temptation to write a compiler for the DLR. I know I should resist, but I spend so many cycles thinking about programming languages and the DLR seems to have so much promise to language implementors.

Argh, I can’t believe I have such a busy week in front of me.

Ruby’s ObjectSpace: A Challenge for the Managed Platforms

The Ruby language contains the built-in module ObjectSpace, which provides programmatic access to the entire world of living objects. For instance, in Ruby you can write:

ObjectSpace::each_object(Class) do |c|
p c if c < Test::Unit::TestCase
end

which will iterate over every instance of Class in the system and do something (in this case, print it out if it is a subclass of TestCase).

John Lam has mentioned to me that ObjectSpace is a particular challenge to IronRuby, as the obvious way to implement ObjectSpace is to hook into the garbage collector, which is not something that is allowed in the world of the CLR. Or in the world of the JVM, as Ola Bini discusses in this interesting post. Implementing ObjectSpace on the managed platforms (using WeakReferences) involves a huge performance hit (Bini talks of measuring several dozen percentage points worth of penalty). He additionally shows some code that works around the obvious ObjectSpace use-case.

Why Ruby’s The Mansion of Bliss

Scott Hanselman weighed in on the Ruby buzz, saying that no language is all things to all people at all times.  I agree, but think that there are a couple things about Ruby that don’t require us to get into language design philosophies. Let me quickly state that these things are not unique to Ruby, but may take the appearance of The Mansion of Bliss to those with backgrounds in more statically-defined languages. (“The Mansion of Bliss” was, I learned on my flight to Panama last night, a phrase used in the early 19th century to mean “tits.”)

The first thing that I like about Ruby is that it has an interactive console / REPL loop. For instance, let’s say you’re trying to divvy up a bunch of data into bins, but don’t know the exact cut you want. With Ruby, you can instantiate a database connection, retrieve this table’s data, that table’s data, apply this filter, that filter, etc., interactively. Of course you can do this with a static language, but every time you make a step of progress, you have to recompile, start the system, retrieve the data, stitch up the joins, and then check to see if your new filter moves you a step forward (which is the much-to-be-admired test-driven way, but sometimes keeping that line green takes a lot of time off the clock). Or, I imagine, you could do it in an interactive SQL Explorer, if your SQL is better than mine.

The other thing I quite like about Ruby is that while everything’s an object, there’s an implicit receiver. So if you have:

puts ‘Hello, world!’

alone in a file or alone in the console, you can do without the likes of:

public static void main(String[] args) { … }

and, y’know, that’s just nice. Object-orientation is the Mansion of Bliss, to be sure, but sometimes there’s something to be said for a block of imperative code.

Further, after 10 years trying to remember what combination of decorators with which to read a file, there’s something awfully blissful about File.Open(“foo.txt”), much less File.open(http://www.knowing.net), which you do for the price of require ‘open-uri’

It does make me pine, though, for two other things that it could have:

What if every line of code you ever wrote were available, perhaps organized in some form of browser?

What if as you worked in that interactive shell, you could just shut down the system and return to it later, having the exact objects, in all their complex state, restored to their former glory?

I suppose that such capabilities are impossible or someone would surely have implemented them by now.

IronPython, IronRuby Discussion with Jim Hugunin and Jon Lam

I’m dying because I’ve just had a long talk with two of Microsoft’s heavy hitters on the Dynamic Languages Runtime (DLR) team and have much to discuss, yet I am in a frenzy preparing for a business trip and cannot yet take the time to do the discussion any kind of justice.

The single-most important quote, I think, was the statement that “no one will take [our implementations] seriously until we can run– / We aren’t done until we can run–” [Django | Rails]. That was contrasted with important libraries that were heavily dependent themselves upon C-based libraries (Zope, in particular). It was also contrasted with libraries that rely on unusual language quirks or implementation details; the touchpoint on that was Ruby’s … shoot, I thought Lam said “objectspaces” but I don’t see that in the standard library … maybe he said “ObjectSpaces-like ability to traverse the entire in-memory object graph” (Anyone know what lib that would be?) … Anyway, the point was that this was an example of something that would be very difficult to implement within the constraints of the CLR.

I’ll update this entry when I can report in more detail…