From: Carl Youngblood <carl.youngblood@...>
Date: 2004-09-10T04:19:09+09:00
Subject: Re: Gmail-based blog

Most of the time when I want to implement something in ruby it is
because I want to write something new in ruby but make use of a module
that is available in another language but doesn't yet exist in ruby. 
So I have to port the module over to ruby so that I can then write a
new app on top of it in ruby.

On Tue, 7 Sep 2004 07:55:33 +0900, Charles Comstock <cc1@cec.wustl.edu> wrote:
> >
> > 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
> 
>