On 2/20/06, Dave H. [email protected] wrote:
Or you could ignore him. I certainly found comments like “It takes at
significant majority of Ruby users on any platform in my opinion.” Youwhat
it’s worth, I think your point “Programming languages and tools are not
end-user software.” is quite wrong.I agree. I have and use Ruby because I want to build programs and tools
for myself…in Ruby. The time I spend having to poop around with
recompiling Ruby, reinstalling Ruby, re-downloading source for Ruby,
debugging Ruby’s installers, is wasted time. I wasted something like
three or four hours trying to get readline support working with irb,
IIRC.
Did you document this struggle (for success or failure)? To complain
about
a lack of documentation is fine. To be presented with an opportunity to
help the situation, but instead just complain, that I find a bit rude.
And if I have to spend time sending
messages to Ruby-Talk trying to find out how to get Ruby to work
instead of programming, then Ruby’s not very good.
Actually, then Ruby’s documentation would not be very good. The whole
not
judging a book by its cover and all. That isn’t to say people’s
perceptions
of Ruby are not influenced by the quality and availability of its
documentation, but that doesn’t make it right either
Pointing out weaknesses in something to its fan base doesn’t always
make you friends, but that doesn’t mean it isn’t worth doing. Thanks,
Glenn; hopefully your observations will help Ruby grow even stronger.
Pointing fingers is fine, lending a hand will make you friends. I don’t
mean this is a flame, or a personal attack, as I have been guilty of it
myself but I’m always amazed at the people who complain about the
quality of
documentation specifically in open source software. I’ve seen it on a
good
dozen projects, new users spend pages and pages of writing complaining
about
something missing from the documentation, without ever submitting a hard
suggestion to fix. And especially without providing a bit of
documentation
themselves.
So please, if you find rough spots, places that you spend hours that you
think you should only spend minutes, document the steps you took, the
errors
you received, the problems you hit, and submit them. At the very least
you’ll get a better informed answer, and at the best you’ll have helped
produce new documentation.