I just saw this on /.:
http://ion.gluch.org.mx/files/Hacks/gallina/
It's a blog that uses your Gmail account. Seems kind of cool. Now if
there were only a Ruby version 
Phil
Phil Tomson wrote:
http://ion.gluch.org.mx/files/Hacks/gallina/
It's a blog that uses your Gmail account. Seems kind of cool. Now if there were only a Ruby version
See this is kinda silly. Whenever the ruby community finds something cool that is written they say "gee if only that were written in ruby". Other then having access to the libGmail or whatever the blog used to read out the mail from gmail what is wrong with working software that runs and has all necessary features, but is written in a different language?
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.
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.
Charles Comstock
In article <chid2k$32l$1@newsreader.wustl.edu>,
Phil Tomson wrote:
http://ion.gluch.org.mx/files/Hacks/gallina/
It's a blog that uses your Gmail account. Seems kind of cool. Now if
there were only a Ruby versionSee this is kinda silly. Whenever the ruby community finds something
cool that is written they say "gee if only that were written in ruby".
Other then having access to the libGmail or whatever the blog used to
read out the mail from gmail what is wrong with working software that
runs and has all necessary features, but is written in a different
language?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.
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".
Phil
路路路
Charles Comstock <cc1@cec.wustl.edu> wrote:
See this is kinda silly. Whenever the ruby
community finds something
cool that is written they say "gee if only that were
written in ruby".
Other then having access to the libGmail or whatever
the blog used to
read out the mail from gmail what is wrong with
working software that
runs and has all necessary features, but is written
in a different
language?
I can see a person wanting to write a library sure,
but not application(unless.. its not round -
development slow, buggy software, etc). Most of the
time you will see the newer programmers wanting to
port an application by language. I don't know why they
want it, but they just do. THen the development will
die and they won't ever touch it again. Oh boy.
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.
Right, there are plenty of other things to be done
here, not porting some application written in another
langauage. I think we need more applications and
science/math libraries 
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.
Many times I see it, I wonder if it is just to look
cool, OTOH we do need a ruby CMS. I was working on
something really neat, but I have to eat. Soo.. back
to money maaking with ruby shall we? 
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.
Your opinion is noted, and hopefully other people will
take some thought into your email than just brush it
off like some of the newer programmers will be doing.
Charles Comstock
--David Ross
路路路
--- Charles Comstock <cc1@cec.wustl.edu> wrote:
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Hi David,
Many times I see it, I wonder if it is just to look
cool, OTOH we do need a ruby CMS. I was working on
something really neat, but I have to eat. Soo.. back
to money maaking with ruby shall we?
Care to elaborate? I am working on one, too. Using Rails. But my first version is probably not beeing released for another 2-3 months.
路路路
--
Sascha Ebach
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
Phil Tomson wrote:
In article <chid2k$32l$1@newsreader.wustl.edu>,
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
路路路
Charles Comstock <cc1@cec.wustl.edu> wrote:
I will elaborate when my site is finished
--David Ross
路路路
--- Sascha Ebach <se@hexatex.de> wrote:
Hi David,
> Many times I see it, I wonder if it is just to
look
> cool, OTOH we do need a ruby CMS. I was working on
> something really neat, but I have to eat. Soo..
back
> to money maaking with ruby shall we?Care to elaborate? I am working on one, too. Using
Rails. But my first
version is probably not beeing released for another
2-3 months.--
Sascha Ebach
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
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.
(...)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.
ohhhhh yes indeed *shudders*
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.
(...)
聽聽
Sounds like a job for Ruby, and the idea of knowing that every Ruby app
cam be Jabber-enabled seems intriguing.
I'd be really interested in what people can imagine as uses for jabber
in the context of their apps.? Though I'm not sure there's enough of a
case to have it in the standard library, it does indeed sound enticing.
聽聽-Daniel
路路路
On Tue, 2004-09-07 at 01:43, James Britt wrote:
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
> Sounds like a job for Ruby, and the idea of knowing that every Ruby app
> cam be Jabber-enabled seems intriguing.
>I'd be really interested in what people can imagine as uses for jabber
in the context of their apps.? Though I'm not sure there's enough of a
case to have it in the standard library, it does indeed sound enticing.
An easy to set up distributed computing system, like dRb but with a
nice naming layer.
Systems monitoring
Data collection
An easy way to get a CLI on a daemon
Instant notifications of site updates.
Lots o' uses, most unimagined.
I have this feeling that XMPP/Jabber is going to be Very Important as
time goes on, though, as it's got RFC numbers, and has tentacles in a
lot of protocols -- there's talk of it replacing or extending SIP, and
there's already a mapping to the SIMPLE IM protocol. There's
Atom-over-Jabber in the works, too. It's just a useful system.
Ari