> 1. I like the interactive console, a la IDLE and PythonWin. Mainly because
> I'm prototyping as I go, I like to test things before I commit them to a
> code in script. I know there's IRB, but it doesn't seem as robust on Win32
> as Python's interactive environment (I'm mostly a Win32 guy) -- I'm using
> the Win32 install 1.6.5 from Rubycentral.com. For some reason, it works on
> my desktop but not on my laptop. Ruby also doesn't always seem to give
> helpful error messages, comparatively speaking. I also have in mind using
> this interactive environment in the software I'm developing, which is sort
> of an admin console gluing together a whole bunch of apps via whatever
> interface they provide (whether by COM, by command line, or API
extension).

Initialy I used RubyWin, but after not very long I found that not as good as
perhaps it should be.  Now I am using IRB from am cmd session and SciTE for
general edit / run. It works well, but all things considered I would still
like an IDE.  And no matter what people want to say about unit testing it
would save time.

> 2. I like that I can use Visual C++ to write Python extensions. I'm not
sure
> I have enough room on my laptop to get the whole cygwin environment
> installed that Ruby seems (again, based on the documentation) to mandate
for
> writing extensions, which are *.so files even on Windows. Also, the Visual
> C++ extension API is fairly well thought out, I'm not yet comfortable with
> the Ruby API, mainly because I'm only functional (not proficient) with
GCC.

Compiling ruby with VC++ is easy, as is doing extensions in VC++. See the
readme in the win32 directory. For me one of the nice things is that
everything *hasn't* already been written! There's plenty of interesting
projects out there.

> 3. Python's Windows extensions are all VERY WELL written and implented in
> the ActiveState distro, it's very robust, and a breeze to both use and
> create COM objects in Python. I used Ruby's win32ole package to play with
> automating word and excel, and it takes much longer for the win32ole
package
> in Ruby to load the first time you use it than it does Python's win32com
> module. I also like the fact that Python's Win32 ole extensions let you
> generate a module based on a type library for "early binding" COM objects.
> But anyway.

I have been working with Win32ole and have also added the ability to create
com objects using ruby.  It's the easiest way I have found of creating com
object thus far. I have some thoughts on using native interfaces in the
future (all happens with IDisaptch at the moment).  However all things
considered, untill there is a really good VM the IDispatch overhead is
probably much compairable to a standard ruby function call.

> 4. I find Python's module/package architecture to be easy and intuitive.
All
> I need is a silly little __init__.py (with or without package
initialization
> code) in subdirectories of the Python21 root (which represent the
hierarchy
> of the API I'm writing), and viola, I've got a package of modules that I
can
> instantly test using the interactive console. I like the ability to import
> specific modules from a package, and not the whole thing, if I want to.

Prehaps I'm misunderstanding here but
require "package"

> 5. I also like the fact that any Python script can be written so as to be
> included as a module in another script, via the
>
> if __name__ == '__main__':
> # get command line args and off we go
> else:
> # loading the module and all the classes and stuff in the callee namespace
>
> trick. Is there a comparable way to do this in Ruby?

if __FILE__ ==$0

> 3. I like Ruby's terse but elegant minimalist syntax. Oddly, it's no
harder
> to read it for as easy as it is to type it. Mind you, I do like Python's
> indentation scheme -- if the target audience consists of relative
scripting
> newbies, which does apply to portions of what I'm building, Python's
> approach seems to me easier to convey and thus to train people in. On the
> other hand, any halfway decent software engineer should have no difficulty
> with Ruby.

I love this also, although it tends to waste my time.  When write the ruby
code, and I am never statified with it so I end up making it smaller and
smaller.  I hope this will wear off once I my coding style in ruby has
settled and I have decided the best way to do the things I commonly do.

> 4. I like the fact that Ruby can be extended in C, but I'm leary of the
GCC
> thing vs. being able to use my familar VCPP environment (No, I don't have
> pictures of Bill Gates in place of crucifixes in my home, I actually can't
> stand Bill Gates, but my work demands Win32 predominantly, and aside from
> one under-equipped Linux box at home, all my machines are Windows of some
> 32-bit variety, and I do have Visual Studio 6.0, and am proficient at
using
> it.) Python lets me use Visual C++ very easily.

There is a bit of a religious war going on about this one.  I am on the VC++
side, and I think it is going that way. To me it really opens up the pool of
professional window programmers.  One must remember however that ruby has a
UNIX background and they are as likely to want to use VC++ for it, as you
are to want to use AutoConf , make and all those other tools that you
probably know little about.

Ralph