Thanks a lot for taking the time to reply, Benjohn!

benjohn / fysh.org:

> I'd go with prototype in Ruby, probably.

And then...? I hoped a bit for the dream solution of "actually, dear
professors, it works - if slow - for the scope of this thesis, and
further speed improvements can be achieved by replacing more parts
with C/C++ code". ;)

> You could jump in to c++, and I think you may find useful Boost
> libraries for the work you're going (there is a graph librarby in
> there, I'm sure)

Yeah, I heard good things about Boost, and also that wrapping one's mind
around C++ templating is a requirement these days. Of which, the latter
scares me (and I seem to know my limits quite well)...

> but I honestly think you'll suffer if you're not a c++ Guru

My thoughts exactly. The catch is my supervisor codes in C++ all his
life, while not having any idea about script languages, so he doesn't
really seem to easily buy mine 'I'll code both faster and be way more
happy with Ruby/OCaml, and the finished libraries will be more-or-less
universal anyway.'

> After prototyping, a fourth way that I would strongly suggest in
> this case, is to considder a functional language if you need speed.

The catch with going OCaml (where did today go? all these
easily-googlable tutorials and opinions were so nice to read...)
is that I'll have to learn yet another language (and, more importantly,
design paradigm).

What I forgot to mention, my supervisor suggests I could re-use a lot of
his C++ base classes; I wonder how well (objective) C++ integrates with
Ruby/OCaml (if at all).

> It's almost certainly very well suited to the kind of work you're
> talking about (symbolic manipulation), and your brain may enjoy
> molding to the mind set if it's already got Ruby nestled in there.

I'll give it an afternoon or two, thanks a lot for the suggestion! The
catch is that my supervisor's brain would also have to mold accordingly,
and that might be the tricky part for a C++-only person ('functional
programming? in 2007?! can't you just code in C++ like all the normal
people?').

> P.S. You may also find that there are languages or tools out there
> that are very well focused to your domain, in which case I'd very
> strongly advise you to make use of them if at all possible.

Definitely. Part of the problem is that I'm not yet
sure what domains will the final alogrithm cover... :)

> Is your PhD about writing code to solve this problem; or about
> exploring the complexity and implications of algorithms; or even
> about actually making use of the algorithm?

It's about (a) coming up with an algorithm (so far it seems it'll
be mostly based on blanket algebra, so set-based operations) and
(b) implementing the algorithm in any way I see fit (although one
that's graspable and reusable by others is expected, so I'm a bit
affraid with going OCaml here; still, any non-C++ solution will be
a slap to the face, I guess).

-- Shot
-- 
> Templates and generic programming: they are as close to duck typing
> as you can get - implement the required signature and you're off.
> The Vigra toolkit I've been using is a great example of this.
I first parsed this as 'Viagra toolkit', and thought, won't that just
make things harder?        -- Ara.T.Howard and James Britt, ruby-talk