Rasputin wrote:

>* Pat Eyler <pate / eylerfamily.org> [0811 04:11]:
>  
>
>>hmmm, this doesn't mesh terribly well with my experience.  Anyone else car
>>to take a crack at answering it?
>>    
>>
>
>  
>
>>---------- Forwarded message ----------
>>Date: Wed, 06 Aug 2003 22:07:21 -0400
>>From: Anil R. Diwan <adiwan / snet.net>
>>Reply-To: devculture / lists.whirlycott.com...
>>
>>...I have not coded in either Ruby or Python, so all comments are based on
>>reading and learning the language.
>>    
>>
>
>How can you learn ('the language' - he doesn't specify which)a without
>writing some programs in it?...
>  
>
Well, I have "some" familiarity with Ruby and Python.  Don't brush off 
his comments lightly if you want Ruby to be more popular.  The only way 
for Ruby to be more popular is for more people to use it.  Which means 
for more peopel who are currently unfamiliar with it to use it.

Ruby has by far the best syntax of any language that I've encountered, 
and for many purposes it's semantics are as good as any.  And it *MAY* 
have good library support.  But many libraries seem to be either 
abandoned or only documented in Japanese (well, only *adequately* etc.). 

This is, perhaps, quite understandable given the history, but if I 
intend to do something, and I must choose between Ruby and Python, it 
will frequently resolve down to  "Which language can I most easily 
figure out how to do things in", and libraries can here be the 
determining feature.  I far prefer Ruby (I have this strong distaste for 
using white space as a program structure indicator, and I prefer that my 
indentation be done with tabs of width 3 rather than with spaces .  I 
know that using tabs this way doesn't really cause Python problems, but 
many people on the mailing list don't seem to.)  But, e.g., if I want to 
use SDL, I can use apt-get to import all needed libraries for Python, 
but  Ruby... I was still working on getting all the pieces straight 
after four hours.  (I told you I wasn't highly skilled.)  Then turn to 
the documentation.  Pygame doesn't have quite everything documented.  
The english documentation of the RubySDL package nearly left me with the 
C documentation of SDL (which I don't know...I' d prefer to use a higher 
level language and then only optimize the parts that need it).  And Rudl 
doesn't seem any better.  (I think that Rubysdl is the appropriate 
library. )

There are probably better ways to approach this, but I'm new, so I don't 
know them.  And the correct (or at any rate, reasonable) approaches are 
easier to find in Python.

A lot of this is probably because Ruby is more recent, and because the 
primary focus of development is in Japan.  But the result is the same 
whatever the reason.

Another thing is this wonderfully promissing thing called Pyrex.  This 
is a purportedly nearly transparent interface between Python and C.  It 
looks like it makes interfacing so much easier than Swig [or hand 
coding] that no comparison is reasonable.  I haven't yet tried it, so 
this may be overblown, but appearantly you can write a file [or 
routine??] that is a mix of Python and C, with automatic translation 
between the pieces. 

Another thing is distributable executables.  Very important for many 
purposes (though I haven't needed this recently).  Python has a 
(somewhat clunky) way to do this called distutils.  What does Ruby 
have?  (I mean by this that if Ruby has a library that can handle this, 
then I don't know about it...It's not a serious question as I don't have 
any need right now.)  Now it is true that the Python distributable 
executables seem to be exe files, so they may only work on MSWindows, 
but to many people that is the vitally important place to have it work.

Now these are just some lacunae that I have noticed.  But that I have 
noticed these seems to me to imply that there are many other areas that 
would have similar gaps, because I *don't* have a large acquantance with 
Ruby.  Nowhere near what I was hoping to have a year ago.  Because I 
couldn't figure out how to use in in the projects that I was working on 
in the time that was available.  AND NONE OF THESE PROBLEMS IS 
INTRINSIC!  These are all library issues.  (I didn't mention the many 
areas where I didn't have any problem.  That's not the problem.)