Suggestions to the Ruby community

lisp has a similar feature, which emacs uses to produce its documentation
(http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_358.html#SEC361)

It seems this sort of thing would be less painful than having to write the
entire documentation at once for an API.

···

On August 31, 2002 02:44 pm, Harry Ohlsen wrote:

This is just a thought, but, Python has a standard (discussed in this forum
some time back) that if there’s a string before the first executable line
of code in a class then it’s intended to contain some documentation about
that class.


To call me “awesome” is an understatement.

instead of everyone writing your own documentation, wouldnt a wiki
documentation better? everyone could just ‘fix’ what is wrong, add
exemples. japanese documentation could just be put there and then
somebody else who knows japanese and english could translate it later.

just a wierd idea.

This comment is relevant to this thread, but has no particular place it
should
be. Anyway…

I need a temp file. I vaguely remember that Ruby can do temp files. It’s
not
in ri, but I wasn’t expecting that because it’s a standard library thing,
rather than a built-in.

PickAxe doesn’t have it for some reason, which surprised me.

I lent “The Ruby Way” to a friend, and I’m sure that discussed it
somewhere.

“Ruby in a Nutshell” is at work.

So I’m reading tempfile.rb!

Try the online pick-axe book.

Jim

That’s exactly where I couldn’t find it! Searching for “temp” in the relevant
chapters revealed nothing (relevant).

tempfile.rb had a sufficient description in it.

Gavin

···

----- Original Message -----
From: “Jim Freeze” jim@freeze.org

On Sun, Sep 01, 2002 at 08:36:54PM +0900, Gavin Sinclair wrote:

I was surprised just now to find that there is no absolute requirement
that you have perldoc to post software on CPAN. If it’s not a
requirement, it is certainly more deeply ingrained in the Perl culture
than it is in Ruby’s. I have never encountered a Perl module that
did not include perldoc. Not even once.

    • You haven’t been doing Perl very long then. It took YEARS to
      get everybody to write perldoc and it didn’t really take hold
      until CPAN was created and perldoc was distributed with the
      core perl distribution.

Still, hasn’t the Perl experience shown that bundling documentation with the
code distribution is a good idea? Does every language have to go through
the same evolutionary steps? Can’t we have a bit of Lamarckianism?

    • At least in the US Ruby is still in very early development and
      there are very few people actually working ON it rather than
      with it. To take examples from the history of Perl, for a very
      long time the only documentation was the man page. Perl was in
      use for a long time before the Book[1] appeared. Much like the
      state of Ruby today. Perl documentation really didn’t
      standardize until the CGI boom of the late 90’s. What happened
      was that being a module author created so much demand for
      answers, that a standard documentation system was created
      in self-defense. In the long run it’s much easier to write
      it once than deal with thousands of emails.

Exactly true. Yet there is the idea that one can just post to ruby-talk as
a substitute for having clear documentation. Or that leafing through
multiple books is a good way to find out what some method parameter is for.

    • For it’s stage Ruby has some pretty amazing online
      documentation, but it has no real documentors. It has book
      authors ( which is a very good thing), but nobody committed to
      the dirty thankless task of documentation management.

Why isn’t documentation considered part of coding? If you write some code
you are (or should be), by definition, its documenter. I’d be willing to
look after documentation management, but regardless of who does it, it won’t
get far unless there is an understanding that, if you write the code, you
have to write the base documentation as well. Native-language issues aside,
the Ruby culture needs to adopt the Perl culture’s attitude towards docs.
There should be an accepted standard for what constitutes minimal
documentation of a lib/class/module, and the tools for using this
documentation should be part of the standard distribution.

The absence of adequate documentation should be considered as much of a
problem as any code bug.

    • Expecting the current developers to take on this project is
      unrealistic. There have been a couple abortive “Ruby
      Documentation Projects” already and I suspect we will see
      a couple more before the demand is truly there. Ruby has
      it’s “Larry Wall”, we need a “Tom Christiansen”.

I’m unclear why it’s unrealistic to expect a developer to write a few
paragraphs of documentation for their own code. The hard part might be
getting people to translate Japanese to English, and vice versa. Besides,
writing documentation is a good way to check your own code. If you have a
hard time explaining it in plain language, then maybe there’s a problem.

    • IMHO, the Ruby document debate is focused a bit too much on
      the tools and format[1] and not on the quality and quantity.
      Rdoc is a great “tool”, but it’s not documentation. Just
      write it and worry about the format later…

That’s not a bad suggestion, since doc tools without docs are sort of
pointless, but I think writing the docs becomes easier if everyone has a
clear idea what format to use. But some matters seem as if they should be
fairly simple to resolve. For example, where does documentation (in any
format) go if it’s not embedded in the code? Can we just agree that every
lib distribution has an immediate subdirectory called ‘docs’, and avoid the
‘lib/dbi/doc/DBI_SPEC’ problem?

James

···
    • Booker C. Bense

Ground control to major tim, can you hear me? I don’t think so. I do
believe your personal communicator has gone haywire and you are
receiving my messages backwards and sideways. Please report to your
nearest space post and exchange your personal communicator for a working
model. Over and out.

···

On Fri, 30 Aug 2002 03:00:07 -0400, Tim Hammerquist wrote:

stibbs graced us by uttering:

That is to say, what is it that is changing between the
currently-available Perl 5.x and Perl 6 that will suddenly nullify
the things that have drawn large numbers of “converts” from the Perl
and Python camps?

Every person that i know of who “converted” to ruby has since long
converted back to using python as their main language due to the
documentation issue, and i have quite a few online friends i have kept
in contact with for quite some years that did this.

THAT won’t happen.

I’m sorry, but if Ruby ever went downhill (God forbid!), I’m goin’ back
to Perl. If there was ever a language that made it difficult to do some
of the simplest things imaginable, well, it’s Java. But after that,
it’s Python. :wink:

And i find most people that i know do like perl but they use python for
the more clean/realistic OO.

I’ve started to use Ruby for general system scripting in addition to
larger projects.

I think that rather than read through my original post and look at what
you can pick apart about it, it might be a good idea to just try and
see where i might be coming from. Judging from your reply to my
original post, it seems you assume i’m just some newbie who has been
looking at ruby for a few days and didnt put much effort in finding
what online documentation is actually available for ruby (even though i
stated the opposite in my original post).

As far as taking you for a newbie, you asked the same exact question
most newbies who don’t know how to use Google or ri would ask. It was
most likely a mistake, and it certainly wasn’t personal.

I think that rather than simply criticizing the community’s efforts so
harshly, it might be a good idea to offer to aid in the documentation,
especially since Ruby and her documention is an open source endeavour
relying on volunteers rather than complaints. Feedback is always
important, but people can only do so much for free.

Would you be willing to help a more detailed documentation project?
Obviously we can’t develop a doc project equivalent to Perl’s perldoc
overnight, but it can happen with enough hard work. Do you have enough
free time from your job to help in this regard?

Tim Hammerquist

Cool. Any language that has LART as a real token in the
language can’t be /that/ bad after all. :wink:

– Dossy

···

On 2002.08.30, ts decoux@moulon.inra.fr wrote:

There is a french expression for this

La critique est aisee mais l’art est difficile


Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

ts wrote:

There is a french expression for this

La critique est aisee mais l’art est difficile

Feel free to translate it in “anglois” if someone want to do it.

Those who can do,
those who cant teach (or critisise - much of a muchness)

At one school I attended I wasn’t allowed to do technical drawing
because I failed Latin!

OK, so what kinds of topics should future Ruby books (of either the
dead-tree or online variety) cover that are not covered (or only
superficially covered) in current Ruby books?

I can think of a few topics that might make good articles or perhaps
chapters in a book:

  • Ruby and SWIG (although this is covered somewhat in the Ruby
    Developer’s
    Guide it would be nice to have a more in-depth treatment)
  • REXML (perhaps a whole Ruby and XML book would be in order, I believe
    Perl and Python both have similar books)

I’m sure there are others, what else?

There is a RubyGarden Wiki page meant to track book suggestions:

It may be a god place to list these ideas.

James

general. All you have to do is look at the english documentation on the
modules to see that they are severely lacking in thorough explanation
of
their use and methods.

There is a french expression for this

La critique est aisee mais l’art est difficile

Feel free to translate it in “anglois” if someone want to do it.

The only French I know is “French fries” and
“Brigitte Bardot”… but I think I can get
the essence of this one. :wink:

“The critique is easy, but the artistry is difficult.”

Guy, I think this is the highest ratio of
natural-language-to-Ruby I have ever seen
in one of your posts.

Hal

···

----- Original Message -----
From: “ts” decoux@moulon.inra.fr
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Cc: ruby-talk@ruby-lang.org
Sent: Friday, August 30, 2002 4:30 AM
Subject: Re: suggestions to the Ruby community

In article pan.2002.07.31.02.21.23.199006.6766@nothanks.com, stibbs

stibbs wrote:

Hi, first i would like to state that i absolutely love Ruby more than
any other language i use (perl, python, PHP, javascript, and now
ruby). Others i work with also have taken a look at Ruby and most have
the same feeling about it i do. That being said, we found that there
is a huge lack of english documentation and therefore would consume to
much of our time to learn it and apply it for use in our work.

The Ruby book list:

http://www.rubygarden.org/ruby?RubyBookList

lists a considerable number of English-language books. “Programming
Ruby”, the one that most Ruby users consider to be a “must-have”, is
freely available on-line here:

http://www.rubycentral.com/book

It’s also included in the Windows installer for Ruby. Some of the
other books, such as the “Ruby Developer’s Guide”, focus more on
contributed modules for GUI development, database access, XML and web
services.

Not to sound rude, but as i stated in my first post “Please take into
considera tion my co-workers and I do know how to use google and ri, we
have found all the documentation and articles that are out there on
Ruby.” We have read through the Documentation and online books you refer
to in this post, we also know about the dead-tree books that are out
there on Ruby. I am sharing our overall point of view with the community
after having done some thorough research. It’s an opinion and we all
know what opinions are comparable to, so take it or leave it.

OK, so what kinds of topics should future Ruby books (of either the
dead-tree or online variety) cover that are not covered (or only
superficially covered) in current Ruby books?

I can think of a few topics that might make good articles or perhaps
chapters in a book:

  • Ruby and SWIG (although this is covered somewhat in the Ruby
    Developer’s Guide it would be nice to have a more in-depth treatment) *
    REXML (perhaps a whole Ruby and XML book would be in order, I believe
    Perl and Python both have similar books)

I’m sure there are others, what else?

In my original post i thought i made it clear that i am referring to the
overall online english documentation for modules/methods and ruby in
general (since that is what i specifically stated in my original post). I
don’t want to get side tracked or off topic on what seems to be a not so
pleasant subject for discussion in this newsgroup. Personally, books would
be a second concern for me until the online english documentation got up
to par organizationally and with the thoroughness and clarity of
python.org’s documentation. This is something the community as a whole can
take part in, where as compared to a book which is usually dictated by one
person or a very small handful of people.

I was just trying to give an inside look at one companies decision dealing
with Ruby. I also happened to mention on a personal note that i know
people that have tried ruby and even though they liked it a lot, they
all eventually made the decision to go back with their prior scripting
language within a few weeks with their reason being an overall lack of
clear and thorough (english) documentation.

So, i got up the balls and decided to make the post just to make sure
people in the community realized that people and possibly companies who
would otherwise be adopting ruby are not due to the english documentation
issue.

If the community already realized this issue to the same extent that i
have observed, I apologize for my original post.

Most, if not all, of Ruby’s built-in modules are documented in
“Programming Ruby”.

is it that is changing between the currently-available Perl 5.x and
Perl 6 that will suddenly nullify the things that have drawn large
numbers of “converts” from the Perl and Python camps?
Every person that i know of who “converted” to ruby has since long
converted back to using python as their main language due to the
documentation issue, and i have quite a few online friends i have kept
in contact with for quite some years that did this. And i find most
people that i know do like perl but they use python for the more
clean/realistic OO. I think that rather than read through my original
post and look at what you can pick apart about it, it might be a good
idea to just try and see where i might be coming from. Judging from your
reply to my original post, it seems you assume i’m just some newbie who
has been looking at ruby for a few days and didnt put much effort in
finding what online documentation is actually available for ruby (even
though i stated the opposite in my original post).

So again, could you give us some specific examples of actual

I feel that in my original post i was specific as i could be. If people
here feel that the the overall online english ruby documentation does not
need improvement, great.

documentation you would like to see for Ruby that doesn’t currently
exist? This could help us prioritize. I’ve done a good bit of Ruby
programming in the last couple of years and I’ve seen the documentation
situation improve greatly during that time, however I’m sure there is
still room for improvement. Also, please consider this newsgroup as a
source of information as well - you’ll find that answers come pretty
quickly here.

Phil

I took into consideration this newsgroup and also perl’s and python’s, all
seem to have a very helpful user community. The same with the mailing
lists for each language.

I think the overall best idea would be to look into the the cpan offer.
The post is a thread under this topic and can be found here:

http://groups.google.com/
groups?hl=en&lr=&ie=UTF-8&selm=a05111b24b9945650a3ff%40%5B63.120.19.221%5D

···

On Fri, 30 Aug 2002 05:23:23 -0400, Phil Tomson wrote:

stibbs@nothanks.com wrote:

On Thu, 29 Aug 2002 20:12:24 -0400, Lyle Johnson wrote:

I agree with the closing sentence :wink: Wikis are cool, but as the primary
form of Ruby documentation? Please, no!

Wikis appeal to the geek world, and a subset of it at that. I believe
the original poster’s main argument was that Ruby needs better
documentation to be accepted by businesses. You show me a suit who can
get his head around a Wiki, and I’ll show you my pet Triceratops.

···

On Sun, Sep 01, 2002 at 10:37:52AM +0900, yct wrote:

instead of everyone writing your own documentation, wouldnt a wiki
documentation better? everyone could just ‘fix’ what is wrong, add
exemples. japanese documentation could just be put there and then
somebody else who knows japanese and english could translate it later.

just a wierd idea.


Matt Gushee
Englewood, Colorado, USA
mgushee@havenrock.com

Care to venture a guess as to how many Ruby modules use RD, vs. those
that use rdoc, an ordinary README, or nothing at all?

Just use modules which give you documentation, or send a patch to the
author.

Guy Decoux

From: "Jim Freeze" <jim@freeze.org>

> So I'm reading tempfile.rb!
>
Try the online pick-axe book.

That's exactly where I couldn't find it!

Well, there is a problem

  http://www.rubycentral.com/book/lib_standard.html#Tempfile.new

Guy Decoux

···

On Sun, Sep 01, 2002 at 08:36:54PM +0900, Gavin Sinclair wrote:

My search found it on page 403 of the pdf version.

···

On Sun, Sep 01, 2002 at 09:35:43PM +0900, Gavin Sinclair wrote:

Try the online pick-axe book.

Jim

That’s exactly where I couldn’t find it! Searching for “temp” in the relevant
chapters revealed nothing (relevant).

tempfile.rb had a sufficient description in it.


Jim Freeze
If only I had something clever to say for my comment…
~

I’d like rpkg to help in this. I am designing it around the concept
of well formed' or policy compliant’ package. The policy I’m using
right now for the Ruby dist states that a package is made up of one or
more directories chosen from [‘bin’, ‘lib’, ‘doc’, ‘ext’, ‘test’].

The content of each gets copied on the end users’ system according to
a configuration specified by the users themselves (so you can have a
completely user managed package base, no need to bug Mr. root).

If we can agree that rdoc generated class documentation is held in
“doc/foo/html” or “doc/foo/ri”, then it will be a trivial matter to
add:

rpkg doc foo

or:

rpkg ri foo

Massimiliano

···

On Wed, Sep 04, 2002 at 04:31:22AM +0900, JamesBritt wrote:

Can we just agree that every lib distribution has an immediate
subdirectory called ‘docs’, and avoid the ‘lib/dbi/doc/DBI_SPEC’
problem?

Yes! Yes! Some Lamarckianism please! :slight_smile:

Gavin

···

----- Original Message -----
From: " JamesBritt" james@jamesbritt.com

Can’t we have a bit of Lamarckianism?

In article CIELJOOMCFBDNHLICOEFCENECGAA.james@jamesbritt.com,

I was surprised just now to find that there is no absolute requirement
that you have perldoc to post software on CPAN. If it’s not a
requirement, it is certainly more deeply ingrained in the Perl culture
than it is in Ruby’s. I have never encountered a Perl module that
did not include perldoc. Not even once.

    • You haven’t been doing Perl very long then. It took YEARS to
      get everybody to write perldoc and it didn’t really take hold
      until CPAN was created and perldoc was distributed with the
      core perl distribution.

Still, hasn’t the Perl experience shown that bundling documentation with the
code distribution is a good idea? Does every language have to go through
the same evolutionary steps? Can’t we have a bit of Lamarckianism?

    • I think it’s a good idea, particularly in a language as
      readable as Ruby. I’m just trying to introduce a bit of scale
      into the problem. As I see it, there are a lot of people
      complaining and very few doing. It won’t just happen
      overnight. Standards are nice, but usable standards require
      a tremendous amount of work.

    To continue your biology metaphor

    “ontogeny recapitulates phylogeny”

    Every language needs to go through the stages, it’s just a
    question of how fast. I think Ruby could go through this
    stage fairly quickly, but I don’t expect to see a standard
    document format until at least a year after raa.succ ( whatever
    that turns out to be ) is well in place.

    • At least in the US Ruby is still in very early development and
      there are very few people actually working ON it rather than
      with it. To take examples from the history of Perl, for a very
      long time the only documentation was the man page. Perl was in
      use for a long time before the Book[1] appeared. Much like the
      state of Ruby today. Perl documentation really didn’t
      standardize until the CGI boom of the late 90’s. What happened
      was that being a module author created so much demand for
      answers, that a standard documentation system was created
      in self-defense. In the long run it’s much easier to write
      it once than deal with thousands of emails.

Exactly true. Yet there is the idea that one can just post to ruby-talk as
a substitute for having clear documentation. Or that leafing through
multiple books is a good way to find out what some method parameter is for.

    • Well, that works fine until you reach a certain scale of
      use. IMHO, the demand for perl-style documentation is
      getting the horse in front of the cart. There is a chicken
      and egg problem here, once consensus is reached then
      most people will fall in line, but people are reluctant
      to put much effort into documentation until consensus
      is reached.
    • For it’s stage Ruby has some pretty amazing online
      documentation, but it has no real documenters. It has book
      authors ( which is a very good thing), but nobody committed to
      the dirty thankless task of documentation management.

Why isn’t documentation considered part of coding? If you write some code
you are (or should be), by definition, its documenter.

    • In practice this almost never works. Writing good code and
      writing good documentation are separate skills. Even if you
      can write documentation as the code’s author, you often have
      many things that are “just obvious” that you never even think
      to document.

I’d be willing to
look after documentation management, but regardless of who does it, it won’t
get far unless there is an understanding that, if you write the code, you
have to write the base documentation as well. Native-language issues aside,
the Ruby culture needs to adopt the Perl culture’s attitude towards docs.
There should be an accepted standard for what constitutes minimal
documentation of a lib/class/module, and the tools for using this
documentation should be part of the standard distribution.

    • In my experience, when you start saying “should” in the open
      source world you’re generally wasting your time. I don’t think
      you’ll get any real disagreement with the above statement, the
      problem is picking the standard.

The absence of adequate documentation should be considered as much of a
problem as any code bug.

    • Expecting the current developers to take on this project is
      unrealistic. There have been a couple abortive “Ruby
      Documentation Projects” already and I suspect we will see
      a couple more before the demand is truly there. Ruby has
      it’s “Larry Wall”, we need a “Tom Christiansen”.

I’m unclear why it’s unrealistic to expect a developer to write a few
paragraphs of documentation for their own code. The hard part might be
getting people to translate Japanese to English, and vice versa. Besides,
writing documentation is a good way to check your own code. If you have a
hard time explaining it in plain language, then maybe there’s a problem.

    • If it was this simple, it would already be done. Documenting
      the Ruby core has already be done once, the problem is
      integrating that in such a way as to keep it current. The
      standard library has never been documented in this fashion.
    • IMHO, the Ruby document debate is focused a bit too much on
      the tools and format[1] and not on the quality and quantity.
      Rdoc is a great “tool”, but it’s not documentation. Just
      write it and worry about the format later…

That’s not a bad suggestion, since doc tools without docs are sort of
pointless, but I think writing the docs becomes easier if everyone has a
clear idea what format to use. But some matters seem as if they should be
fairly simple to resolve. For example, where does documentation (in any
format) go if it’s not embedded in the code? Can we just agree that every
lib distribution has an immediate subdirectory called ‘docs’, and avoid the
‘lib/dbi/doc/DBI_SPEC’ problem?

    • These are not “fairly simple to resolve”, they are exceedingly
      complex and require a lot of community thrashing and
      competition between competing ideas/models before consensus
      is reached. Standards emerge from the documentation,
      documentation does not emerge from standards. I’m not saying
      we should not tackle these problems, I’m saying it’s a lot
      more complicated that most people seem to think.
    • Booker C. Bense
···

JamesBritt james@jamesbritt.com wrote:

[ top-posting fixed ]

stibbs graced us by uttering:

Tim Hammerquist wrote:

I think that rather than simply criticizing the community’s
efforts so harshly, it might be a good idea to offer to aid in
the documentation, especially since Ruby and her documention
is an open source endeavour relying on volunteers rather than
complaints. Feedback is always important, but people can only
do so much for free.

Would you be willing to help a more detailed documentation
project? Obviously we can’t develop a doc project equivalent
to Perl’s perldoc overnight, but it can happen with enough
hard work. Do you have enough free time from your job to help
in this regard?

Ground control to major tim, can you hear me? I don’t think so.
I do believe your personal communicator has gone haywire and
you are receiving my messages backwards and sideways. Please
report to your nearest space post and exchange your personal
communicator for a working model. Over and out.

So we should take that as a no? I’ve already gotten one
volunteer willing to help. A shame to have to count you out…

Tim Hammerquist

···


If only the Earthlings appreciated life as we
do, I would not have to kill so many of them.
– Jovian soldier, “Martian Successor: Nadesico”

So again, could you give us some specific examples of actual

I feel that in my original post i was specific as i could be.

OK, I’m not flaming you. I’m just trying to communicate.

Phil’s request is reasonable. And you have not been as
specific as you could be, because you have not named
even ONE item that needs improved documentation.

If people
here feel that the the overall online english ruby documentation does not
need improvement, great.

No one said that! There’s a huge need for improvement. But
there’s also a huge amount out there.

OK, I myself will be specific.

Here are (some) things that I think ARE documented
adequately in English:

  1. Core classes: Array, Bignum, Binding, Class, Continuation,
    Dri, Exception, FalseClass, File, File::Stat, Fixnum, Float,
    Hash, Integer, IO, MatchData, Method, Module, NilClass,
    Numeric, Object, Proc, Range, Regexp, String, Struct,
    Struct::TMS, Symbol, Thread, ThreadGroup, Time, TrueClass

  2. Core modules: Comparable, Enumerable, Errno, FileTest,
    GC, Kernel, Marshal, Math, ObjectSpace, Process

  3. Standard libraries: Complex, Date, English, Find, Ftools,
    Getoptlong, Mkmf, Parsedate, PStore, Tempfile, Mutex,
    ConditionVariable, Timeout, WeakRef

  4. OOP libraries: Visitor, Delegation, Observer

  5. Networking Libraries: BasicSocket, IPSocket, TCPSocket,
    SOCKSSocket, TCPServer, UDPSocket, UNIXSocket, UNIXServer,
    Socket, Net::FTP, Net::HTTP, Net::HTTPResponse, Net::POP,
    Net::APOP, Net::POPMail, Net::SMTP, Net::Telnet, CGI,
    CGI::Session

  6. Other stuff: RDOC, REXML, DRb, eRuby, irb, debug.rb,
    and so on.

Which of these do you consider underdocumented? Or is it
something else entirely?

Hal

···

----- Original Message -----
From: “stibbs” stibbs@nothanks.foo.web-hosting.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Friday, August 30, 2002 4:55 PM
Subject: Re: suggestions to the Ruby community

In article pan.2002.07.31.23.56.23.344521.11118@nothanks.foo,

In my original post i thought i made it clear that i am referring to the
overall online english documentation for modules/methods and ruby in
general (since that is what i specifically stated in my original post). I
don’t want to get side tracked or off topic on what seems to be a not so
pleasant subject for discussion in this newsgroup. Personally, books would
be a second concern for me until the online english documentation got up
to par organizationally and with the thoroughness and clarity of
python.org’s documentation. This is something the community as a whole can
take part in, where as compared to a book which is usually dictated by one
person or a very small handful of people.

I was just trying to give an inside look at one companies decision dealing
with Ruby. I also happened to mention on a personal note that i know
people that have tried ruby and even though they liked it a lot, they
all eventually made the decision to go back with their prior scripting
language within a few weeks with their reason being an overall lack of
clear and thorough (english) documentation.

So, i got up the balls and decided to make the post just to make sure
people in the community realized that people and possibly companies who
would otherwise be adopting ruby are not due to the english documentation
issue.

If the community already realized this issue to the same extent that i
have observed, I apologize for my original post.

Most, if not all, of Ruby’s built-in modules are documented in
“Programming Ruby”.

So again, could you give us some specific examples of actual

I feel that in my original post i was specific as i could be. If people
here feel that the the overall online english ruby documentation does not
need improvement, great.

All you’ve said is that the online docs for “modules and methods” was not
complete or thorough - Personally, I think the online Pickaxe book is as
good as any book for any other language in it’s descriptions of the
various built-in classes, modules and methods in the Ruby library.

So I’ll try one more time: Can you give us a specific example where you
found that you needed more information or the information wasn’t clear?
For example, you could say: “The explanation of the foo method in the
module Fooable didn’t tell me anything about how instance variables of the
class it is being mixed into will be affected”.

Again, I ask this because the various Ruby documentation out there (the
PickAxe book and online version, Ruby In a Nutshell, The Ruby Way, etc)
all seem to offer a very complete, thorough treatment of the language and
it’s libraries so I really don’t understand your statement about
documentation being incomplete or unclear. Now, perhaps, since I’ve been
using Ruby for a couple of years now and I was used to digging a little
deeper on my own for information before all this wonderful documentation
was available, I don’t see what the problem is now that
documentation seems to be readily available. By way of analogy, if I’ve
always had to walk to get anywhere and someone gives me a bicycle and
then sometime later someone with a car comes a long and says “Hey, your
mode of transportation isn’t as good as it could be, get a car!” I’m
likely to answer “What do you mean, I’m getting around great on this
bike!”. So since you were kind enough to point out an apparent lack
of documentation and want to enlighten us and help out the community it
would be helpful if you could give us a few specific examples of where
you felt the docs were lacking, cases where you and your colleagues were
scratching your heads wondering how you would actually use some class or
or method (and it actually kept you from getting anything done).

No personal attack on you is intended. Look at it this way, you said
in an earlier post that you have an open source project. I suppose that
your project includes docs for how to build, install and use your code.
If someone sent you an email that said: “Dude, I think your program is
great, but your docs suck!” and you asked for some specifics and all you
got back is: “Dude, the docs for how to use your system are lacking and
I’m gonna use a different program because of it.” wouldn’t you find that
a wee bit frustrating?

Phil

···

stibbs stibbs@nothanks.foo wrote: