Phil Tomson wrote:
> In article <chid2k$32l$1 / newsreader.wustl.edu>,
> Charles Comstock  <cc1 / cec.wustl.edu> wrote:
>>
>>We should ask ourselves instead (if we want to see more things like that 
>>in ruby) what cool thing we could do that hasn't yet been done.  For our 
>>own customization we would all probably prefer code written in ruby, but 
>>if we want to make a name for ourselves it won't be through code we find 
>>easy to customize.  It will be through code that does something amazing 
>>that hadn't been done before, or at least not quite that way.
>>
>>So that's what we should aim for, not recreating someone elses cool 
>>inventions, but making our own that are impressive in there own right.
> 
> 
> Quite true, though in this case I don't have php installed and didn't feel 
> like installing it just to try this gmail-blog-thingy out.  If there were a 
> Ruby package available, I'd try it out right away.

Same here, more or less.  The other side is that many "cool" apps
written in SLOTR (some language other than Ruby) do not lend themselves
to pleasant, productive hacking.  Many times I've installed apps in
perl, PHP, whatever, and find it nice but lacking in some way, and want
to hack it up.  But more often than not the code is a mess of terse
expressions, each geared to some quirky task.

So, if I like enough of what the SLOTR app does, I'm inclined to just
rewrite it in Ruby.

Other things never make it to my hard drive because I can see the 
laundry list of dependencies and just give up from the start.
> 
> 
>>Anyhow, i'll jump off my soapbox now.  Don't mean to offend anyone, it 
>>just seems to be a kneejerk reaction the community often has, to 
>>reimplement or fill a niche that is already nicely filled when we should 
>>be finding new niches that are more difficult for some other languages. 
>> Not that some of the community aren't but it's just kinda silly 
>>sometimes I think, for what we wish for.
> 
> 
> 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".

I think the best cases for having a Ruby clone are when, by virtue of
the code being in Ruby, it becomes much easer to use or extend or 
configure or whatever.  But if it's just a line-for-line port (or the 
functional equivalent), then there is little gain.

For example, although Instiki is not my cup of tea, I can see it being a
good marketing tool for Ruby because of the ease of set up and the use 
of WEBrick for the server, and of Madeleine for persistence. No messing 
with Apache or CGI permissions.

These are features that are less likely to be found in SLOTR wikis.

Now, for me, I'd rather see Ruby establish itself in some new 
info-ecosystem, rather than playing "me too."  For example, 
circumventing the bloat of J2EE in a service-oriented architecture 
framework.  I suspect that dynamic languages have an upper hand for 
these sorts of things, so long as they don't simply mimic existing, 
MVC-based architectures.

An excellent Ruby project (and please don't get on my back for 
suggesting something I have no intention of contributing too; it's time, 
not interest that holds me back) would be a pure-Ruby, protocol-complete 
  Jabber server.

And then get it added to the Ruby standard library.

Peter Saint-Andre is, I believe, in the midst of writing a Python 
version.  Beating him to it might be nice. :)

<quote src='http://www.saint-andre.com/blog/jabber.html'>
As anyone who subscribes to the JADMIN mailing list can tell you, the 
existing server options all have issues, from difficulty of installation 
to lack of documentation to missing protocols to inability to run the 
existing gateways to non-Jabber IM services. As anyone who talks with 
Jabber users knows, there are hundreds of Jabber clients but almost all 
of them are close to useless. I chat with server admins and end users 
all the time, so I hear these complaints in abundance. I'm beginning to 
think that it's time to do something about it.

What's the solution? I see two critical pieces:

    1. A modular, hackable, well-documented, cross-platform, 
easy-to-use, protocol-compliant server.
    2. A modular, hackable, well-documented, cross-platform, 
easy-to-use, protocol-compliant client.

Let's go over those adjectives, shall we?

     * Modular -- designed so that people can contribute to it without 
having to grok the entire codebase.
     * Hackable -- written in a language that lots of developers 
understand and can productively code in.
     * Well-documented -- including a complete architectural 
description, user/admin guide, and in-depth comments in the code (see 
hackability above).
     * Cross-platform -- works on Linux/Unix, Windows, and Mac OS X.
     * Easy-to-use -- no more difficult configuration or installation, 
good user interfaces, and lots of help files.
     * Protocol-compliant -- wouldn't it be cool if you could actually 
make use of protocols like pubsub, XHTML, and file transfer?
     * Server | Client -- Jabber is a client-server system, so we need both.

</quote>
	
Sounds like a job for Ruby, and the idea of knowing that every Ruby app 
cam be Jabber-enabled seems intriguing.


James