Python 25 times as popular as Ruby !?

Michael campbell wrote:

No one said that.

Yes, I was exaggerating for effect. :slight_smile:

If it doesn’t grow, it will eventually die.

Will it? Is Smalltalk still growing today?

Squeak seems to be building some excitement…

It probably hasn’t grown
for quite some time, yet it’s still around if you want to learn it.
How about Eiffel? People are even moving away from C and C++, but I
doubt they’ll be dead for many years to come.

In any case (and this is a reply to several posts, not just yours),
Ruby will get popular some day. Or maybe it won’t, and we’ll either
continue to talk about it here and use it from time to time just
because it’s a nice language, or we’ll move on to something else.
The world will go on.

Yes it will.

What we don’t need to do is organize a big campaign to get Ruby
awareness up.

So Ruby awareness will just grow on it’s own without any effort from us?
It’ll just happen? I don’t think so.

We don’t need to contact big players like IBM and
whoever to push Ruby for all sorts of programming – “Look, it
was made for scripting but you should use it for OS programming and
high speed graphics too!”

I don’t think anyone is contacting big players and proposing that Ruby be
used for things it’s not suited for, and they shouldn’t.
But what about proposing Ruby for things that it is good for?

We don’t need to go into Slashdot stories
or forums about other languages and post messages going “Ruby rox!
Go check it out!”

No, but why not visit other forums and make intelligent comments about
Ruby (backing them up with facts about the language). I think there are
many opportunities to do this in an appropriate way. Nobody’s going to
pay much attention to a post on a forum that says “You should use Ruby
because it rox!”, but if you suggest why Ruby makes sense for the given
application space it will be received positively.

Everyone hates evangelists except for those who are already in the
religion. They get offended that you’re implying your beliefs are
better than theirs. If someone’s curious about Ruby, or wants a
language suggestion, tell them to check it out, but don’t become
an evangelist.

It all depends on how the evangelizing is done. I would submit that we
do need Ruby evangelists, but they need to evangelize ‘nicely’ and
intelligently. I know that a few years back there was an article going
around about how language evangelism is just terrible bad and must be
avoided at all costs, but I wonder if it caused us to go too far in the
other direction. “I’m not going to even mention Ruby as an option because
I don’t want to be seen as an evangelist”. The more people hear about
Ruby, the more likely it is that they’ll try it.

We’ve all seen plenty of examples of superior commercial products that
died due to poor marketing.

So please do write articles, post messages to other forums and even to
Slashdot. If we aim to be invisible, we will be.

In the mean time, posts like, “Python is 25 times more popular than
Ruby” or “Ruby needs Python indenting to be popular!” just waste time.
Ruby will either get there, or it won’t, based on whether it’s worthy
or not. Don’t worry so much about how long it takes.

Some of us have been waiting longer than others…

bottom line:
I’d like to be able to recommend Ruby for work projects and not get
‘never heard of it’ comments and questions about where would they find
Ruby programmers if I were hit by a bus. I’d like to hear, “Ruby,
excellent suggestion, go with it”. Right now that’s not the case - it’s
an uphill battle, but sometimes we do win.

Phil

¡¡¡

In article 401D4F5E.70704@po.cwru.edu, Dan Doel djd15@po.cwru.edu wrote:

Hello Dan,

Monday, February 2, 2004, 6:00:37 AM, you wrote:

Okay, we'd like to use Ruby at work. For this, Ruby needs
critical mass.

Threads like this don't really help Ruby gain mass. What
should we do? I don't think an aggressive Ruby marketing
campaign is in order, unless someone wants to spend lots
of money.

What can the Ruby community really do except continue to
write Ruby code? RubyForge says it hosts 152 projects.
As people write more Ruby code, more people will come and
write more Ruby code and so on. Ruby may gain critical
mass in the future. It just isn't there yet.

Whats about cooperation instead of competition in the ruby world ?
The raa-installer vs. ruby-gems is one of the places where energy is
spend that could be used better. I also see lots of libraries in
competition to each other but not in competition to some python/perl
libraries, simply because they are to weak to be a competitor.

If ruby is so a superior OO language, why is it so complicated to
extend/change an already existing library ?

The Ruby-Gem thread was one of the reasons why i started looking at
the statistics on sourceforge.

¡¡¡

--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com

I have 2 suggestions:

  1. Host your Ruby projects on RubyForge. That gives folks 1 place to look
    for Ruby code, and supports the efforts of those who support Ruby.

  2. Buy Ruby books. Hal, Dave, etc. have mentioned that publishers are not
    interested in bringing out new Ruby books when the current ones aren’t
    selling. I’m told that if you want to know where a man’s heart is, look in
    his checkbook. If we want Ruby to grow, spending a little money won’t
    hurt.

¡¡¡

On Mon, 02 Feb 2004 14:00:37 +0900, Dan Doel wrote:

What can the Ruby community really do except continue to write Ruby code?
RubyForge says it hosts 152 projects.

don’t forget the ability to make the definition of a class in two
different places :slight_smile:

¡¡¡

il Sun, 01 Feb 2004 16:34:46 -0600, Charles Comstock cc1@cec.wustl.edu ha scritto::

I certainly would probably rather do it in C# then Java. It’s
interesting in the 2.0 spec for C# they are adding yield symantics,
anonymous method blocks and generics.

Peter Hickman wrote:

Maybe I should go over to comp.lang.python and see if you have written
‘Perl is 25 times as popular as Python’. Which of course you should
write as Perl has vastly more libraries of high quality software than
python.

Go Perl! Ooops. Sorry. :wink:

Lothar Scholz wrote:

As the only one who uses GNU Eiffel for a program > 200.000 LOC i must
say that eiffel is dead. Two vendors stopped there support (Visual
Eiffel, Halstenbach), GNU Eiffel is becomming more and more unuseable
for real development (everything after the great renaming SmallEiffel
=> Smarteiffel) and ISE raised there prices by a factor of 3
(it’s now 5000 USD for a not very good system).

On my Windows partition, I have the free student/trial version of a
commercial Eiffel development environment installed. They seem to think
Eiffel isn’t dead.

Smalltalk is also dying or better becaming less and less attrictive.

Smalltalk is still out there, though. I’m sure Squeak will be around for
many years teaching interested parties what real object oriented languages
should be like. Even if it’s not used directly, I hope Smalltalk will be
influencing the latest generation of “buzzword compliant” languages
for years to come.

Same as lisp where only Franz Lisp is still competitive in some areas.

You should go tell the people at comp.lang.lisp, c.l.scheme and
c.l.functional that Lisp is dead. :slight_smile:

No but the spirit of people hacking a library should maybe move from a
“it’s good enough for me” attitude to a “i want good quality” way. For
most libraries the additional overhead won’t be so much. But this is
still a real problem.

I’m sure the people working on code at RubyForge and the like – that is,
the people writing code/libraries for public consumption – already have
this mentality.

Like much other posting on this newsgroup, for example about indenting
styles. I posted it because i think a few people didn’t recognize the
real world situtation. And this is always not good. I’m just bored
about threads that everything is fine with ruby and working well.

I didn’t mean that as a personal attack against you (we get lots of
posts here that say such things), so I hope you didn’t take offense.
However, saying that Ruby needs Python indenting or C++ braces isn’t
the real world situation. It may be the real world situation that
Python is more popular than Ruby, but how popular was Python 5 years
ago? It’s just been exposed to more of the world for longer. Ruby
will get there when it gets there. It is doing fine. Matz is working
to make it better with Rite, and people discussing here is helping
him along (I hope).

Not all threads here are lovey dovey. There’s debate about which
directions Ruby should go. But merely posting “Python is way more
popular” isn’t constructive toward making Ruby better.

In any case, we should wrap this discussion up soon. I’d rather not
see it turn into one of the 300+ message threads with lots of flame
wars (which it has a high potential of doing).

  • Dan

Phil Tomson wrote:

So Ruby awareness will just grow on it’s own without any effort from us?
It’ll just happen? I don’t think so.

Ruby awareness has already been growing without any specific advertising
plans, as far as I know.

I don’t think anyone is contacting big players and proposing that Ruby be
used for things it’s not suited for, and they shouldn’t.
But what about proposing Ruby for things that it is good for?

Apologies, I was taking a jab at a language I used to like a whole lot,
before I learned Ruby. Java had lots of advertising and big corporate
muscle behind it, which is partially why it’s as big as it is today.

No, but why not visit other forums and make intelligent comments about
Ruby (backing them up with facts about the language). I think there are
many opportunities to do this in an appropriate way. Nobody’s going to
pay much attention to a post on a forum that says “You should use Ruby
because it rox!”, but if you suggest why Ruby makes sense for the given
application space it will be received positively.

It all depends on how the evangelizing is done. I would submit that we
do need Ruby evangelists, but they need to evangelize ‘nicely’ and
intelligently. I know that a few years back there was an article going
around about how language evangelism is just terrible bad and must be
avoided at all costs, but I wonder if it caused us to go too far in the
other direction. “I’m not going to even mention Ruby as an option because
I don’t want to be seen as an evangelist”. The more people hear about
Ruby, the more likely it is that they’ll try it.

We’ve all seen plenty of examples of superior commercial products that
died due to poor marketing.

So please do write articles, post messages to other forums and even to
Slashdot. If we aim to be invisible, we will be.

I’m not saying we shouldn’t talk about Ruby to other people. I think if
it’s appropriate, you should bring it up. I myself have brought up Ruby
in forums I’ve posted to, like comp.lang.functional, and probably even
Slashdot.

I suppose when I said we dont’ need evangelists, I really meant that we
don’t need zealots. When there’s a story about Java and someone goes in
and posts a random comment about how Python is better than Java, all it
does it make people angry. Feel free to evangelize as long as it’s
appropriate, just don’t go overboard and make people hate Ruby for its
evangelists/zealots. :slight_smile:

Ruby will gain mass through people writing code and, of course, through
light evangelism. But I’m sure many of us already do that, so it’s more
of a matter of time.

  • Dan

Lothar Scholz mailinglists@scriptolutions.com wrote in message news:7516975309.20040201203323@scriptolutions.com…

Smalltalk is also dying or better becaming less and less attrictive.
Same as lisp where only Franz Lisp is still competitive in some areas.
In fact in commerical areas Smalltalk is much more dead then Eiffel.

Those of us (and there are quite a few) who use Smalltalk for
commercial development daily find such statements very amusing. As a
simple data point, there are currently at least five commercial
Smalltalk vendors (IBM, Cincom, Object Arts, Gemstone, Exept). That’s
an awful lot of companies to be selling a dead language - I wonder how
they support all those development teams if nobody is buying their
product?

Ruby is not going to die just because it’s not #1 most popular
scripting language, any more than Apple is going to die because they
only have a couple of % of the PC market. Network effects matter, but
Ruby is well beyond the critical mass it needs to survive. In fact,
Ruby is now too popular for my personal taste - I prefer the energy in
slightly smaller communities than Ruby’s has become. The price of
success…

Avi

“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message news:64119.203.185.214.34.1075684452.squirrel@webmail.imagineis.com…

[Charles Comstock:]

I fully agree on all counts. I’ll just mention, though, that RDoc
actually encourages introductory/usage/example documentation, so long as
the developer wants to write it
. For example:

An idea I was wondering was if it might be possible to link unit tests
and RDoc.

It would work like this:

  • The developer creates unit tests for their class, starting with the
    simplest usages and then testing each facet of the code with unit
    tests.

  • There may be some extra, optional, notation for expressing how a
    test would appear in the documentation. For example, a test may be
    marked to be included in the main body of the documentatation, while
    others are linked in a separate document. You could also categorise
    the unit tests, and add other meta language.

  • RDoc then processes these unit tests, formatting and indexing them,
    and includes them with the final documentation.

I think this approach could make it easier for class writers to
produce extensive examples whithout much additional work.

I have no problem with several projects exploring the same ecological
niche. What I do find mildly depressing is the number of ruby cookbook
projects out there, in various stages of development. (I even wrote to a
couple to see if they needed help, but never heard back from one, and
was told the other was on hiatus at the moment). Surely we should be
able to finish such a well-defined project within a month or two, with a
concerted community push.

Which brings up an interesting tangent - is there any ruby software that
would help coordinate such an effort?

martin

¡¡¡

Lothar Scholz mailinglists@scriptolutions.com wrote:

Whats about cooperation instead of competition in the ruby world ?
The raa-installer vs. ruby-gems is one of the places where energy is
spend that could be used better. I also see lots of libraries in
competition to each other but not in competition to some python/perl
libraries, simply because they are to weak to be a competitor.

The next time they ask you about the bus, you’re welcome to give them
my email address :slight_smile:

Seriously, I know so many excellent programmers that would jump at
the chance to get paid for Ruby coding. I don’t think buses (or trains
for that matter) are really a problem. Sure, they’re not going to be
able to grab some “I coded a little app in VB” joe off the street, but
I see that as a feature of Ruby, not a bug. I find Ruby ability to be a
great measure of practical (pragmatic?) programming skills.

Nathaniel

<:((><

¡¡¡

On Feb 2, 2004, at 00:09, Phil Tomson wrote:

bottom line:
I’d like to be able to recommend Ruby for work projects and not get
‘never heard of it’ comments and questions about where would they find
Ruby programmers if I were hit by a bus.

Gavin Sinclair wrote:

[…]

We definitely more complete docs on lots of things though, that is my
main problem with Ruby. There are lots of things I know I can do,
without duplicating work, but since I can’t find docs on it, it’s
difficult to do. The push for RDoc is great, but I still have the same
complaints about it that I have of Javadoc, it generally doesn’t give
some sort of example for each function, class in the library. I learn
far more from an example of code use that encompasses a wide part of the
library then a list of functions I can call in the library. The 2nd is
great, but it only works if you know how to use it already. Fix the
documentation and I think ruby will certainly spring ahead.

I fully agree on all counts. I’ll just mention, though, that RDoc
actually encourages introductory/usage/example documentation, so long as
the developer wants to write it
. For example:

I wasn’t really trying to criticise RDoc or even Javadoc as a method of
documentation, I was trying to point out that they are oft misused.
Many times the developer decides against writing examples, and instead
just lightly explains each function.

I think the problem with class/library documentation in RDoc or Javadoc
style, is that it’s harder when you first dive in to get a coherent
picture of how the library interacts. And that’s the key component to a
library, knowing what it does and how to do it. Functions tell how to
set and check state, and generally how to start things and whatnot but
it doesn’t describe the core philosophy of how the library works. It’s
often very difficult to determine that from documentation that focuses
on each function/field, and not on the grand scope of the library.
Unless each function/field shows a good example on how to use it in the
total context of the library. It would be nice to have a tutorial in
each library to get your feet wet, and while it’s certainly there in
some, it’s missing in lots, or difficult to find.

There are certainly excellent examples of documentation in this format
which do a good job of describing exactly what I want above, but there
are many examples where it feels like the documentation is a couple
remarks strewn throughout the source. In that case I prolly will get
more from reading the source then looking at the rdoc.

Sorry, I certainly think it’s great that we have what we have, but I
still feel like we can go alot further.

The first thing you see (an important consideration for people looking
at an RDoc screen for the first time) is a description of the project,
installation, usage, technical information, links, etc.

Here, the first thing you see is a brief description of the ‘pathname’
Ruby standard library. It could use a one-paragraph description and usage
example to help the casual browser (person, not software) decide whether
they’re interested. However, the most important thing is the prominent
“For documentation, see class Pathname [linked]”, which contains intro,
examples, and a method catalogue.

That’s the style I like, particularly if the method catalogue shows how
each function is used in an example.

RDoc was certainly not a hinderance to creating decent documentation for
the ‘pathname’ library!

Sorry didn’t mean to say it was a hinderance, just that perhaps not all
were as diligent in writing documentation for there libraries as they
could be.

They say a picture is worth a thousand words, well I say a nicely
commented example that illustrates how the library is supposed to
interact is worth the same as all the single function documentation that
can be thrown at me.

Many thanks to all who have documented, and also to all those who have
written libraries, I guess I just get frustrated when I find a library
that does what I need, but I don’t know how to use it.

Charlie

Robert wrote:

Peter Hickman wrote:

Maybe I should go over to comp.lang.python and see if you have written
‘Perl is 25 times as popular as Python’. Which of course you should
write as Perl has vastly more libraries of high quality software than
python.

Go Perl! Ooops. Sorry. :wink:

But Perl is dead. Go PHP! :slight_smile:

Seriously, some software are “destined” (read: designed) to be popular
and some are not. PHP and Python, for example, are designed with the
goal to be easy to learn and comes with as many batteries as it can.
Thus it will be used by as many people as it can.

Ruby is designed with a different goal I think, and I’m glad it is.
Would you be content if every kid in the block used Ruby? Where’s your
edge then? :slight_smile:

¡¡¡

–
dave

Martin DeMello wrote:

Whats about cooperation instead of competition in the ruby world ?
The raa-installer vs. ruby-gems is one of the places where energy is
spend that could be used better. I also see lots of libraries in
competition to each other but not in competition to some python/perl
libraries, simply because they are to weak to be a competitor.

I have no problem with several projects exploring the same ecological
niche. What I do find mildly depressing is the number of ruby cookbook
projects out there, in various stages of development. (I even wrote to a
couple to see if they needed help, but never heard back from one, and
was told the other was on hiatus at the moment). Surely we should be
able to finish such a well-defined project within a month or two, with a
concerted community push.

Which brings up an interesting tangent - is there any ruby software that
would help coordinate such an effort?

martin

The TCL crew have a wiki in which various snippets and document can be
found. Quite a lot of the queries in the c.l.t news group get pointed to
wiki.tcl.tk/WhatEver which can be a very interesting source of information.

What is the problem with the cookbook sites? What is the stumbling
block, the effort to organise it, the lack of submissions, hosting?

Maybe if we knew why they failed then we could address that rather than
start yet another project.

¡¡¡

Lothar Scholz mailinglists@scriptolutions.com wrote:

I started one such effort with submissions from the Sydney group,
which was never really advertised. It was based on PLEAC (which is
based on the Perl cookbook). I didn’t like the PLEAC “code only”
approach, so thought another effort was justified (besides, all code
is sharable).

My effort has been dead for ages. I’d love to donate it to a good
home. Left alone, one day I would probably make a RubyForge project
out of it, but I’m waaaay too busy on other Ruby stuff to think about
that atm.

It’s not a community push that would finish it; it’s devotion from a
few core people and proofreading from a few more.

Cheers,
Gavin

http://www.soyabean.com.au/gavin/ruby-cookbook/ruby-cookbook/html/index.html

¡¡¡

On Monday, February 2, 2004, 11:29:49 PM, Martin wrote:

Lothar Scholz mailinglists@scriptolutions.com wrote:

Whats about cooperation instead of competition in the ruby world ?
The raa-installer vs. ruby-gems is one of the places where energy is
spend that could be used better. I also see lots of libraries in
competition to each other but not in competition to some python/perl
libraries, simply because they are to weak to be a competitor.

I have no problem with several projects exploring the same ecological
niche. What I do find mildly depressing is the number of ruby cookbook
projects out there, in various stages of development. (I even wrote to a
couple to see if they needed help, but never heard back from one, and
was told the other was on hiatus at the moment). Surely we should be
able to finish such a well-defined project within a month or two, with a
concerted community push.

Which brings up an interesting tangent - is there any ruby software that
would help coordinate such an effort?

Right on; seems like there’s are opportunities for these things. If
there’s a Slashdot article on Jabber, post a note about Jabber4R. If
there’s an article on ImageMagick, post about RMagick, etc.

Yours,

Tom

¡¡¡

On Mon, 2004-02-02 at 00:33, Dan Doel wrote:

I suppose when I said we dont’ need evangelists, I really meant that we
don’t need zealots. When there’s a story about Java and someone goes in
and posts a random comment about how Python is better than Java, all it
does it make people angry. Feel free to evangelize as long as it’s
appropriate, just don’t go overboard and make people hate Ruby for its
evangelists/zealots. :slight_smile:

Nathaniel Talbott nathaniel@talbott.ws wrote in message news:013A62D9-5595-11D8-99FF-000A95CD7A8E@talbott.ws…

bottom line:
I’d like to be able to recommend Ruby for work projects and not get
‘never heard of it’ comments and questions about where would they find
Ruby programmers if I were hit by a bus.

The next time they ask you about the bus, you’re welcome to give them
my email address :slight_smile:

:wink: Are you still in Oregon?

Seriously, I know so many excellent programmers that would jump at
the chance to get paid for Ruby coding. I don’t think buses (or trains
for that matter) are really a problem.

I totally agree and I would add that any good programmer that has
experience in other languages and some OO background can pick up Ruby
and be productive in a few days. I was talking about management
perceptions of the language. We both would agree that these
perceptions are inaccurate, but they’re still a barrier.

Phil

¡¡¡

On Feb 2, 2004, at 00:09, Phil Tomson wrote:

I think it was Paul Graham who defined a really attractive language as
one that you’d take a job coding in irrespective of the actual project.
It was someone in the lisp community at any rate, but ruby definitely
fits the bill :slight_smile:

martin

¡¡¡

Nathaniel Talbott nathaniel@talbott.ws wrote:

Seriously, I know so many excellent programmers that would jump at
the chance to get paid for Ruby coding. I don’t think buses (or trains
for that matter) are really a problem. Sure, they’re not going to be

I always felt Knuth’s “literate programming” was an interesting idea, even
though IMO it would be nearly impossible to implement with modern RAD
environments, and takes a special kind of software engineer/literati to
remain disciplined enough to use this approach.

Put simply, you write an essay of sorts in a sort of markup language like
TeX (for which of course Knuth was famous), organizing your code in a
fashion suitable more for human reading than code organization, per se. But
every line of code is in there, and there is special syntax for referring to
more granular code blocks below as you work your essay from high-level
design discussions into low-level implementation dissertations. A translator
then pulls the code out and compiles (runs) it, while the human readable
version is transformed into something more permanent and readable/viewable -
i.e., PostScript, html, etc. Sort of the inverse of what JavaDoc and RDoc
do, which pull the comments out.

As for the special kind of software engineer required to make it work - I
suspect there are very few out there who aspire to the Pulitzer when trying
to write a script that gets an urgent job done well enough to move on to the
next task. Not every interesting programming task is necessarily something a
programmer wants to turn into a treatise. More than that: not every
programming task is interesting.

Alas, code documentation is fanciful. So writing code in a language that is
(more or less) self-documenting like Ruby is the only sane way to go… and
even that (as this discussion proves) doesn’t solve the general problem of
good, explanatory documentation - the kind that helps a consumer of code
crawl inside the head of the original designer to grasp his/her frame of
reference fully.

I suspect someone eager to provide that level of documentation can do so
simply - the issue is that most developers don’t have the urge to do so.
Rather, we avoid doing it like the plague.

  • Bob
¡¡¡

-----Original Message-----
From: Charles Comstock [mailto:cc1@cec.wustl.edu]
Sent: Monday, February 02, 2004 8:05 PM
To: ruby-talk ML
Subject: Re: Documentation approaches

Gavin Sinclair wrote:

[…]

We definitely more complete docs on lots of things though, that is my
main problem with Ruby. There are lots of things I know I can do,
without duplicating work, but since I can’t find docs on it, it’s
difficult to do. The push for RDoc is great, but I still have the same
complaints about it that I have of Javadoc, it generally doesn’t give
some sort of example for each function, class in the library. I learn
far more from an example of code use that encompasses a wide part of the
library then a list of functions I can call in the library. The 2nd is
great, but it only works if you know how to use it already. Fix the
documentation and I think ruby will certainly spring ahead.

I fully agree on all counts. I’ll just mention, though, that RDoc
actually encourages introductory/usage/example documentation, so long
as
the developer wants to write it
. For example:

I wasn’t really trying to criticise RDoc or even Javadoc as a method of
documentation, I was trying to point out that they are oft misused.
Many times the developer decides against writing examples, and instead
just lightly explains each function.

I think the problem with class/library documentation in RDoc or Javadoc
style, is that it’s harder when you first dive in to get a coherent
picture of how the library interacts. And that’s the key component to a
library, knowing what it does and how to do it. Functions tell how to
set and check state, and generally how to start things and whatnot but
it doesn’t describe the core philosophy of how the library works. It’s
often very difficult to determine that from documentation that focuses
on each function/field, and not on the grand scope of the library.
Unless each function/field shows a good example on how to use it in the
total context of the library. It would be nice to have a tutorial in
each library to get your feet wet, and while it’s certainly there in
some, it’s missing in lots, or difficult to find.

There are certainly excellent examples of documentation in this format
which do a good job of describing exactly what I want above, but there
are many examples where it feels like the documentation is a couple
remarks strewn throughout the source. In that case I prolly will get
more from reading the source then looking at the rdoc.

Sorry, I certainly think it’s great that we have what we have, but I
still feel like we can go alot further.

The first thing you see (an important consideration for people looking
at an RDoc screen for the first time) is a description of the project,
installation, usage, technical information, links, etc.

Here, the first thing you see is a brief description of the ‘pathname’
Ruby standard library. It could use a one-paragraph description and
usage
example to help the casual browser (person, not software) decide whether
they’re interested. However, the most important thing is the prominent
“For documentation, see class Pathname [linked]”, which contains intro,
examples, and a method catalogue.

That’s the style I like, particularly if the method catalogue shows how
each function is used in an example.

RDoc was certainly not a hinderance to creating decent documentation for
the ‘pathname’ library!

Sorry didn’t mean to say it was a hinderance, just that perhaps not all
were as diligent in writing documentation for there libraries as they
could be.

They say a picture is worth a thousand words, well I say a nicely
commented example that illustrates how the library is supposed to
interact is worth the same as all the single function documentation that
can be thrown at me.

Many thanks to all who have documented, and also to all those who have
written libraries, I guess I just get frustrated when I find a library
that does what I need, but I don’t know how to use it.

Charlie

Gee,

THis whole discussion reminds me of ones we used to have on
comp.lang.python about 10 years ago, 'cept then it was
Python vs. Tcl instead of Ruby vs. Python.

Moral of the story – if it works for you, keep coding in
it. If enough people agree with you (like the lang too)
it will catch on. People thought I was crazy ten
years ago writing stuff in this obscure Python language
nobody ever heard of. Now my colleagues are asking me
for recs on Python books.

Good luck to you guys, Ruby looks pretty cool!

			JT