From: Charles Comstock <cc1@...>
Date: 2004-09-07T07:55:33+09:00
Subject: Re: Gmail-based blog

> 
> However, there are cases (and I'm not saying that this is one) where a Ruby 
> implementation is quite useful.  What if we had never come up with our own 
> wikis (ruwiki, instiki), blogs (rublog, diaria, etc.), webservers 
> (WEBrick), etc?  Sometimes (actually, most of the time) creating cool 
> things is an incremental, 
> evolutionary  process as opposed to exnihilo ("from nothing", a totally new 
> idea).  Also, sometimes it just helps Ruby adoption if we can say that some 
> feature is available in Ruby otherwise people can (and do) say "sure Ruby's a 
> very nice language, but it doesn't have (Perl|PHP|Python|Java)'s XYZ 
> package so I really can't make use of it in my work".
> 

Yes but I don't think of those as reimplementations, I think of those as 
someone didn't like the code base of the other project because it didn't 
do feature X the way they wanted it, so they re-implemented the core the 
way they saw fit in ruby and then modified from there.  That is a 
different issue then just reimplementing.  If your reimplementing in 
ruby so you can add features and modify it more easily that's different. 
  The problem is alot of time that is the intent, but then the new 
product doesn't do everything the old product does, and your stuck with 
alot of clones that don't do much and don't have alot of use beyond the 
author.

For instance, I remember a fair amount of complaining several times when 
the community has done things like use a perl wiki for something 
(rubyforge) or used a php CMS or whatever.  The point is those products 
worked, it's not a slap in the face to ruby to not use ruby code to 
present ruby things, and I think sometimes that is how some seem to take 
it.  The only way it could be a slap is if it was construed as proof 
that such an application wasn't possible in ruby.  Which is rediculous 
and I am sure there is a more useful way to prove it's possible other 
then rewriting said product in ruby.

As far as missing features available for <insert language>'s package, 
this is a mixed problem.  I for one think that far too many people try 
and use only one language.  Each language has it's uses.  I love ruby, 
it's my favorite language, but there is a time and place for each 
language.  There are a few I particularly avoid, but I think they all 
have there strengths and weaknesses.  I called the missing package 
problem mixed because most of the time you could figure out some way or 
another to interface it if you really needed the efficiency boost.  Most 
of the time the people are either too lazy to switch, or equally often, 
you haven't succeeded in convincing them they will be more efficient and 
quick at coding by switching.  If they have crusty old perl scripts 
depending on some perl libraries that all works let them continue to use 
them.  There is no sense in rewriting code that works, even if the new 
language makes you that much more efficient, your still wasting your 
time because it already worked.  Now if you need to modify said code and 
doing so is particularly tricky and it's more efficient to rewrite in 
another language then do so, but if you really depend on libraries X 
then take that cost into consideration.  It might make more sense to 
rewrite it in that language in that case.

If you want them to switch, don't suggest they rewrite the old ones, get 
them to write the new scripts in ruby.

Each language has it's coding style, and it's own tricks to do things, 
but some of those tricks overlap and if you learn them in one you can 
move them to another.  The XML builder objects from Groovy or whatever 
are an example of that, neat idea, works well here too, so port it over 
it's a good library and it's small, and it will make your and other ruby 
programmers lives more efficient by providing this as a native solution. 
  But ask yourself before you write something over again in a new 
language, does the old one really not do what I need?  Is it really less 
work to reimplement it?  Will the new version be that much better?

Everyone loves to have a favorite language, but just cause it's a 
favorite doesn't mean it means the others are useless or poorly written 
or whatever.  It just means it's different.  All too often we want to 
make out a competing language or product as the evil enemy.  Every 
person has a style of thinking, and I think coding exhibits that style 
of thinking very plainly.  If you can't work in a product or language or 
whatever it prolly means you have a different style of thought.  That 
doesn't mean there's is wrong it just means it's different.  Learn from 
there style, see what they get out of it, and then if it's really 
necessary re-express it in your own style.  But make sure it's 
necessary, and not just cause you kinda didn't feel like learning 
vaguely how they thought about things.

Blah, I seem to have written more then I intended, hopefully some of you 
will take some of it to heart.  Or maybe you won't.  Anyhow,

Charles Comstock