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
