Ruby Forum Ruby > Ruby’s not ready - an indepth essay

F.Y.I

Not sure if you guys have read this article, I am going to re-post it 
here.

http://glyphobet.net/blog/essay/228

2008/4/7 Song Ma <songmash@gmail.com>:
>  http://glyphobet.net/blog/essay/228

The piece can be summarized in two brief quotations:

First, near the beginning:

    I promise we'll be as objective as humanly possible

then, about 500 pages later:

    TMTOWDI is bad

In other words, I'll be objective, so long as objective means judging
things according to my own lack of imagination.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Song Ma wrote:
| F.Y.I
|
| Not sure if you guys have read this article, I am going to re-post it
here.
|
| http://glyphobet.net/blog/essay/228
|

"It's not ready, because it isn't Python". That sums the article up in a
sentence.

I could say the same in reverse about Python, or any other language.

Two major fallacies:
1) The issues the article touches on are already known, and partially
addressed in libraries (Regexen with Oniguruma (sp?)) and/or different
implementations (speed in JRuby, for example, where you could farm out
to Java's Strings or regexen).

2) (And this breaks the whole premise of the article:) The basis for the
comparison is humbug. Porting libraries and applications isn't a valid
test of languages, since the original implementation shapes 
preconceptions.

If Ruby and particularly Rails weren't ready, it wouldn't see adoption
by major players.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

Rule of Open-Source Programming #4:

If you don't work on your project, chances are that no one will.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf646IACgkQbtAgaoJTgL8PwwCglpbFBS9fqm+/6q8WTGdeliC7
0IAAn3YcFu1ATbfo4C58mbuyccgGLlEb
=Xush
-----END PGP SIGNATURE-----

Well he seems to hold everything to the standard of Python, so of
course anything that follows the TMTOWDI approach rather than Ivory
Tower Driven Development (ITDD) is going to be bad.

--Jeremy

2008/4/7 Avdi Grimm <avdi@avdi.org>:
>  then, about 500 pages later:
>
--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

Interesting. But what I am thinking about is not the attitude of the 
author,
but the points he was trying to make. The deep review and discussion 
will
benefit the language insights.

2008/4/8, Avdi Grimm <avdi@avdi.org>:

Song Ma wrote:
> F.Y.I
>
> Not sure if you guys have read this article, I am going to re-post it here.
>
> http://glyphobet.net/blog/essay/228
>
>   
Warning: only read if you feel like being really irritated to gain maybe
a tiny bit of insight, probably on things you already know. At least,
that's my opinion on this article.

-Justin

Damn!

Our whole coding business has been built on a language and framework
that's just not ready yet?? <sigh>

LOL!

<tongue out of cheek>

That's just silly. I don't understand why he'd write something like
that, but honestly it doesn't really matter.

If he wants to not use Rails and Ruby, then so be it. I use it, and
I've used it for years, we've done numerous apps (over 10), some of
our them Enterprise-level, and it works a treat.

I looked at Python, but writing it is a pain in the neck. It just
sucks (for me).

This is my preference.

Julian.

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Song Ma wrote:
| Interesting. But what I am thinking about is not the attitude of the
author,
| but the points he was trying to make. The deep review and discussion will
| benefit the language insights.

Two years ago, it might have. But not anymore.

And it is not about attitude. It's credibility. And the first two
paragraphs of the article blew *that*.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

Never buy what you do not want
because it is cheap; it will be dear to you.
~ -- Thomas Jefferson (1743-1826)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf66msACgkQbtAgaoJTgL/U2wCgkHjcu+D9JU7o5BQxSHVW4Y55
14AAnRUDvsB6d1XnyEUPz0guIMBxxmR6
=JGAj
-----END PGP SIGNATURE-----

The points he was trying to make are incredibly biased.

Ruby works like people do. That's why I like it. That's why it's
faster to program in.

If people aren't open to programming in a more natural way, Ruby will
just "get in the way". So, it's not for them.

All of the "downsides" are worth this. It's pragmatic.

Julian.

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

2008/4/7 Song Ma <songmash@gmail.com>:
> Interesting. But what I am thinking about is not the attitude of the author,
>  but the points he was trying to make. The deep review and discussion will
>  benefit the language insights.

There's no deep review here. It's a shallow review written in a
shallow way. The author is completely and wholly incorrect that:

  "The options for Ruby 1.8 users are to install 1.9 or the third-party
   Oniguruma package... In general, it's a bad sign when a third-party
   reimplements a large chunk of functionality in an existing piece
   of software."

This represents pure ignorance. Yes, Ruby 1.8 users must install
Oniguruma for the features that Oniguruma provides. But it's not a
"third-party" product as such; it *is* the Ruby 1.9 regexp engine.
This fact has been known and stated for at least three years, and
Oniguruma is made available as an option for people who need the
additional features. (Free clue: not many. Those who do need it really
need it. Most people don't.)

The author is similarly wholly ignorant of Ruby 1.9 and Ruby 2.0
discussions and assumes that "lack of English documentation" is the
same as "lack of documentation." The author is a fool for believing
the claim that Ruby 2 has been in development longer than Perl 6. Perl
6 was ramping up as I switched to Ruby in 2002 and Ruby 1.8 was
released a bit after that (I got my Ruby 1.8 Pickaxe at the 2005
RubyConf in San Diego). Matz has been talking about the next
generation of Ruby (Ruby 2.0) for a while, but that's no different
than the discussions and experiments surrounding Py3k.

Worst of all, the author treats both the Alioth shootout and the Zed
Shaw rant as things worthy of positive attention, when both are, well,
worthless. The Alioth shootout has been known to be worthless for
years yet periodically some idiot treats it as serious. Zed's rant was
a *rant*. It too had things that are known to be false, things that
are probably libellous, and things that were simply taken out of
context.

All in all, the authors pretend to be objective when they are anything
but. They've drunk the Guido-ade and as the resulting article shows
had no interest in showing Ruby in a positive light. Most of the
things that they've mentioned are *differences* from Python (neither
positive nor negative) or have little importance to most applications.
(Yes, Virginia. Most people don't need full-on Unicode munging in
their code. It's necessary when you do need it, but most people don't
need it.)

This article deserves to be buried with great prejudice.

-austin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Austin Ziegler wrote:

| (Yes, Virginia. Most people don't need full-on Unicode munging in
| their code. It's necessary when you do need it, but most people don't
| need it.)

http://www.joelonsoftware.com/articles/Unicode.html

I need it. Most of Europe needs it. Not to mention Arabia, Japan, and
everybody else not speaking English.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~   "Endorsing products is the American way of expressing 
individuality."
- -Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf67xsACgkQbtAgaoJTgL8EsQCfS8P7nsE9JFbcHpwzbbpPQGvq
7LIAnRMf/jqxjnTHbun779NQuhBQ0mKm
=9M0o
-----END PGP SIGNATURE-----

I'm pretty sure this was simply a bullet point review on a client's
list of requirements for a project's RFP/spec.

"We want you to use Ruby/Rails because we've heard you get things done
faster.  If you want this project, you need to use Ruby or tell us why
you won't use it."

"We don't know how to use Ruby, so let me give you a list of stupid
reasons we aren't using it.  It has nothing to do with the fact that
we don't have any clue how to use it.  Nope.  The biggest killer for
us is all of these minor things, especially having to remember THREE
WHOLE WAYS to print text to the screen.  Whew!  Ruby isn't ready."

I think your assessment is basically spot on of its bias.

--Jeremy

2008/4/8 Austin Ziegler <halostatue@gmail.com>:
>    Oniguruma package... In general, it's a bad sign when a third-party
>
>  Worst of all, the author treats both the Alioth shootout and the Zed
>  things that they've mentioned are *differences* from Python (neither
>   * austin@halostatue.ca * http://www.halostatue.ca/feed/
>   * austin@zieglers.ca
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

Austin Ziegler wrote:
> There's no deep review here. It's a shallow review written in a
> shallow way.

Indeed. Just one shallow point that showed up when I scrolled about 2/3
down and read a couple of paragraphs from the essay:

> What is the difference between the length and size methods on
> String, Array, and Hash? There is none. Hashes have update and
> merge methods. What's the difference? None.
> 
> These are particularly atrocious synonyms, because the English
> words they are based on aren't synonymous. What if you have a
> class representing a geometric object, and you want length and
> size to return different measurements?

Sure, so on your geometric class you define length and size to be
different. It happens that they are the same for strings (and why not).
They don't have to be the same for other things.

On Apr 8, 5:05�am, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
>
> I need it. Most of Europe needs it. Not to mention Arabia, Japan, and
> everybody else not speaking English.
>

Bullshit. I've done localization for Chinese sites in Ruby without
ever
having to think about unicode issues. SOME things require you to take
care. Such as not making stupid assumptions about the length of
strings
in bytes vs. characters. But most of the time people can do a lot of
string mangling with UTF-8 without ever needing to think about it.

ALL my work involve international character sets in one way or the
other,
because I refuse to not deal with i18n. NONE of my work involves "full-
on
unicode munging". It involves a tiny subset of support at most.

That applies to most people, and most of what they'll ever need is
trivial to implement.

Reading/writing UTF-8 is easy. Splitting UTF8 into characters, or
converting it to 32 bit codepoints is easy (surprise, surprise,
#pack and #unpack supports it).

Once you have it in 32 bit, the length calculation problems go away,
and slicing and  splicing strings without thinking about it becomes
easy.

That's almost everything _most_ people ever need in order to work
with Unicode. If there was such a burning need, most people would
use ICU bindings for Ruby (do they exist? I've never even bothered to
look, but if they don't they'd be trivial to write if I ever need
them)

Vidar

[Unicode]
> I need it.

I keep on reading people that need Unicode, and in your case it may very 
well be true and for many others as well.

But personally I never had a need to use Unicode and it may be true for 
many others as well.

======================================================

But about the blogger in question - it is easy to see he is an avid 
python user.
Personally I have no big objection to python as a language (much less 
than against perl or php), I think projects using python instead of perl 
do a big improvement in general for various reasons, and I think anyone 
choosing python can as well choose ruby.

But the blogger seems to make extremely BAD points:

Point 1
"The language and its implementation are incomplete and immature."
"A project loses time when it must implement missing or incomplete 
functionality."

This is a statement. He does not give points to illustrate this 
statement.
I can only laugh about unbased statements. What functionality is 
missing?
Should viewers try to understand how you think?

Point 2
"The language is inconsistent and needlessly complex. Inconsistency and 
complexity confuses people and confusion breeds bugs."

It is true that ruby as a whole is a _complex_ language. So is haskell.
"Complexity" alone is nothing inherently bad. If you want an euphemism 
for "complexity", you could use "powerful". And if we use the word 
powerful the
language suddenly no longer appears "bad". But it is true - ruby is 
complex. There is a lot to learn and know for a newcomer to ruby 
(normally, but ruby is A LOT easier than haskell)

When i went from php (yes, laugh...) to ruby there was a lot to learn. 
There is still a lot to learn but the situation has changed. I have 
since then entirely got rid of all my php (which means yes, all my web 
stuff is powered by ruby).

For several reasons, ruby is a much better language than php. And ruby 
is more suited to outside-www tasks than php ever will.

Ruby as a language is not inconsistent though.

As said I partially agree about the complexity stuff as in "a lot to 
learn and know", but this does not really matter for a given project. 
For example I do spend more time aggressively thinking if I really need 
to use something in a ruby program or not.
@@class_vars I really never need, global vars I do sometimes use but 
they arent needed that much. Metamagic is sometimes fun but I dont think 
there are that many use cases for it. (I am just in love of objects 
which seem to solve pretty everything ...)

Point 3
"The documentation is incomplete. Incomplete documentation breeds bugs 
as you might misuse a feature."

That documentation could be improved in ruby - agreed. I am in total 
favour of this, and I hope people do not recommend _only_ ri as 
"solution". Often the ri was equivalent to "RTFM". This is what php for 
a long time had better solved than ruby due to webpages _about_ php and 
the php-homepage docu (the situation has changed in the recent years for 
ruby due to some websites and efforts improving online docu of ruby, so 
I am not complaining here really)

That "incomplete docu breeds bugs" is total and utter bullshit.


Last but not least, I think everyone that visits the blog knows what
"Comments are closed." means:
  He is only interested in presenting his (IMHO incorrect) view to the 
visitor.

A blog that disallows comments yet makes many unfound and incorrect 
statements is just wasting time of the visitor.

Marc Heiler, 08.04.2008 13:24:
> [Unicode]
>> I need it.
> 
> I keep on reading people that need Unicode, and in your case it may very 
> well be true and for many others as well.
> 
That's precisely the ignorant attitude that caused the issues we 
currently have with differen character sets. I'm pretty sure that if 
computer systems had been emerged from a non-english speaking country at 
the beginning we wouldn't need to still fight character set issues 
(there are still too many applications that even have problems with 8bit 
character sets)

There are definitely more users in the world who *need* Unicode than 
users who don't need it and therefor don't care.

You can not even get away with a 8bit character set for a european wide 
application, let alone a world-wide application.

I'm a newbie with Ruby and until I read this discussion I simply assumed 
it would fully support Unicode "out of the box" especially given the 
fact that is originates from Japan. I'm actually very confused (not to 
say shocked) that there *is* a discussion if Ruby needs (or supports?) 
Unicode.

Unicode (and a relevant encoding such as UTF8) should be the *standard* 
for all (new) programming languages and not an exception.

Thomas

Why is everyone getting so worked up? It's a critique. Biased it may
be, but that in itself does not make it worthless. In fact, it can be
very constructive b/c it uncovers "attack points" with the language.
With each point we can ask ourselves objectively is this a
misconception or a fair point? In either case we have an opportunity,
to address misconceptions in our Ruby evangelizing blogs and to work
to improve Ruby where a point has merit.

Bias can work both ways. But I think the Ruby community can rise above
it, and Ruby will be all the better for it.

T.

From: "Thomas Kellerer" <YQDHXVLMUBXG@spammotel.com>
>
> That's precisely the ignorant attitude that caused the issues we currently have with
> differen character sets.

"Let me tell you something about You that YOU don't know. . . ." <grin>

> I'm a newbie with Ruby and until I read this discussion I simply assumed it would fully
> support Unicode "out of the box" especially given the fact that is originates from Japan.
> I'm actually very confused (not to say shocked) that there *is* a discussion if Ruby
> needs (or supports?) Unicode.

My understanding was that in Japan, character encodings such as EUC-JP 
or Shift_JIS
were widely preferred over Unicode.

> Unicode (and a relevant encoding such as UTF8) should be the *standard* for all (new)
> programming languages and not an exception.

Apparently not, as One Character Encoding to Rule Them All is not 
considered
satisfactory to many people.

Here's a long thread on the subject from the archives: 
http://tinyurl.com/ge2kp

Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box." 
(See also
post #9 in that thread by Matz talking about 1.8.)

Ruby 1.9 has much broader support for handling multiple character 
encodings.


Regards,

Bill

On 8 Apr 2008, at 03:53, Song Ma wrote:
> F.Y.I
>
> Not sure if you guys have read this article, I am going to re-post  
> it here.
>
> http://glyphobet.net/blog/essay/228

If an article of similar tone were published comparing French and
English we would all see it for the daft nonsense it is.

Python and Ruby fill a certain niche and present different ways of
handling problems in that niche. I much prefer Ruby to Python, and I
have friends who much prefer Python to Ruby. Arguing over which is the
better language is pointless.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Bill Kelly, 08.04.2008 14:51:
>> Unicode (and a relevant encoding such as UTF8) should be the *standard* for all (new)
>> programming languages and not an exception.
> 
> Apparently not, as One Character Encoding to Rule Them All is not considered
> satisfactory to many people.
But Unicode/UTF8 would at least satisfy a *lot* more people than plain 
ASCII or 8bit encodings (such as ISO-8859-x)

> Here's a long thread on the subject from the archives: http://tinyurl.com/ge2kp
> 
> Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box."  (See also
> post #9 in that thread by Matz talking about 1.8.)
Ah! Good to know that.

> Ruby 1.9 has much broader support for handling multiple character encodings.
Is there any release plan for 1.9?

Thomas

Err, to point a fact:

Ruby itself does not support Unicode, in the way that Intel quad core
processors aren't really quad core.

Those are true statements, but they are misleading.

Ruby can mimic enough Unicode to get by in the areas where you need
it.  Otherwise the original Japanese author probably wouldn't have
been able to use it quite as much, and then it wouldn't have caught on
in Japan, and wouldn't have moved over to the US and Europe.

Heck, the fact that you can type this into vi and the two output lines
are the same should be enough to convince anyone.
#!/usr/bin/ruby
#an example shamelessly pulled from a ruby mailing list question
a="\xD7\x90"
b="א"
puts a
puts b

Probably the fact that ruby's lack of Unicode support still lets you
do this is why there hasn't been more of a push for full blown
Unicode.

--Kyle

Bill Kelly, 08.04.2008 14:51:
> Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box."  (See also
> post #9 in that thread by Matz talking about 1.8.)

Hmm. After reading the thread, I simply tried:

puts "öäü".length

and it returns 6 if the source file is saved with UTF8, which is plain 
wrong.
(it returns 3 if saved in ISO-8859-1 encoding).

String#size returns the same values.

In case your mail reader does not display the string correctly - it's: 
öäü

Thomas

2008/4/7 Song Ma <songmash@gmail.com>:
> F.Y.I
>
>  Not sure if you guys have read this article, I am going to re-post it here.
>
>  http://glyphobet.net/blog/essay/228

The only good point in that whole mess is that the current state of
docs for Ruby is poor, and could use a lot of love.

- Rob

http://robsanheim.com
http://thinkrelevance.com

>     TMTOWDI is bad
>
> In other words, I'll be objective, so long as objective means judging
> things according to my own lack of imagination.
>
Ok, don't kill me for this, and I do disagree with most of the article
(I personally found Ruby more coherent and therefore simple, and I see
many things are improving (speed, regexp, etc...) so I am happy with
that).

However I did sympathise with the author's comment on having too many
ways to do the same thing. They pretty much mirror my feelings: that
you either learn them all (in which case you lost in simplicity) or
you'll have a very hard time reading other people's code. I admit
though that it makes _writing_ code easier.

I know however that the Ruby community is strongly in favour of this
"feature", so I was wondering why.

Diego

Rob Sanheim wrote:
> 2008/4/7 Song Ma <songmash@gmail.com>:
>> F.Y.I
>>
>>  Not sure if you guys have read this article, I am going to re-post it here.
>>
>>  http://glyphobet.net/blog/essay/228
> 
> The only good point in that whole mess is that the current state of
> docs for Ruby is poor, and could use a lot of love.

Well ... I guess that depends on which docs you are talking about.
There's plenty of documentation on Rails, three of the major GUIs --
Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two
major Ruby "cookbooks", the documentation on Ruport and RSpec is
excellent, etc.

A week or so ago when the Ruby Mendicant was considering working on the
docs, I expressed the opinion that the documentation is the
responsibility of the creator -- someone shouldn't have to do it for
them. Now if the creator is a better coder than tech writer, perhaps the
project can take on someone. But my experience has been that it's very
rare for someone to be an excellent coder and a poor tech writer.

I read the essay and all of the posts about it here so far, and my own
personal opinion is:

1. Everything he said has been said before -- it's basically a rehash of
old criticisms.

2. My main concern is not with the documentation. My main concern is
that both the syntax and semantics of the language seem to be more fluid
than "pragmatic" considerations would dictate. I more or less grew up
with FORTRAN, although I missed FORTRAN I. So I'll use its evolution as
an example.

Ten years into its evolution, an ANSI committee was formed to
standardize the language. Users and vendors sat around a huge table and
thrashed out what would break the least code, what was easy to
implement, what kinds of programs people wanted to write in the language
that they couldn't, etc. The result was FORTRAN 66. 11 years later there
was FORTRAN 77, etc.

Now FORTRAN is 50 years old, there's a FORTRAN 95 standard, and the
language is still in use (I think -- I haven't written any since 1990).
Ruby is a tad older than ten years, and I think maybe it's time for some
standardization on the syntax and semantics.

I think there are enough "killer apps" now that we know what we can't
take out of Ruby without breaking Rails, RSpec, Ruport, etc. And from
MRI, KRI, jRuby and Rubinius, I think we know what's easy to implement
and what isn't. But what I have no clues about is what programs people
want to write in Ruby that they can't write now.

On 08/04/2008, Thomas Kellerer <YQDHXVLMUBXG@spammotel.com> wrote:
>
>  and it returns 6 if the source file is saved with UTF8, which is plain
> wrong. (it returns 3 if saved in ISO-8859-1 encoding).
>  String#size returns the same values.
>
>  In case your mail reader does not display the string correctly - it's:
> &ouml;&auml;&uuml;
>

It's completely correct. length in 1.8 means number_of_bytes. You can
get 3 by using regexps in utf-8 or a special extension which is
mentioned in many threads on Unicode as well.

Thanks

Michal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| However I did sympathise with the author's comment on having too many
| ways to do the same thing. They pretty much mirror my feelings: that
| you either learn them all (in which case you lost in simplicity) or
| you'll have a very hard time reading other people's code. I admit
| though that it makes _writing_ code easier.
|
| I know however that the Ruby community is strongly in favour of this
| "feature", so I was wondering why.

Learning Ruby as my first language, I can emphasize with this issue.

But: The TMTOWDI approach helps with productivity. A lot. I switch
between the different idioms and methods as the situation requires.
Sometimes it is more natural to use #match, sometimes it is more natural
to use #scan, depending on the situation.

The only problem I've had is the less than optimal documentation for
Ruby, so it is rather difficult to find what a method does or,
sometimes, where it comes from.

And lets face it: Most code in the world is write-only: It's written
once, and becomes instant legacy code. How often is code completely
revisited, and has to be re-factored in an amount of time that makes it
impossible to wrap one's head around it again? Not much, and it doesn't
happen often (mostly in languages that are used in the enterprise, where
refactoring tools are available, and IDEs are more useful than with Ruby
at the moment).

Besides, it helps with problem solving, I've noticed, the more Ruby I
pick up. It's a matter of using the right tool for the right job within
the language itself.

However, I've not yet formalized my IT knowledge, so take it with a
grain of salt. My view is an opinion. Treat it as such.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

Write first in an easy-to-understand pseudo-language; then translate 
into
whatever language you have to use.
~            - The Elements of Programming Style (Kernighan & Plaugher)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7guQACgkQbtAgaoJTgL93AACgmigzprUIZJD87pcNyae5IO+7
W6AAn02u5jVsqJ3+2rYNB9xN5hOG88lX
=FPEN
-----END PGP SIGNATURE-----

On Tue, 2008-04-08 at 23:20 +0900, Diego Virasoro wrote:

> However I did sympathise with the author's comment on having too many
> ways to do the same thing. They pretty much mirror my feelings: that
> you either learn them all (in which case you lost in simplicity) or
> you'll have a very hard time reading other people's code. I admit
> though that it makes _writing_ code easier.



> I know however that the Ruby community is strongly in favour of this
> "feature", so I was wondering why.


You answered your own question here.  It makes writing code a joy.  And,
unlike, say, Perl (or even more extremely, K), Ruby isn't quite a
write-only programming language.  (If you use all the idiot Perlisms you
can make it that way, but almost nobody uses those thankfully!)

Ruby is by no means a perfect language.  But as a former Pythonista (I
started with Python at v1.3), Ruby, despite its warts (and this includes
the UNICODE issue, the lousy performance, the bad threading model and
the whole host of other things people have ranted about for ages now)
remains my first and favourite language I reach for when I'm starting a
project.  As things move along in the project I reach for other
languages to supplement or replace it (recently Erlang has grabbed my
imagination for certain key application elements), but Ruby's my first
choice and is usually in the final product in some form or another.

On Tue, Apr 8, 2008 at 3:15 PM, Thomas Kellerer
<YQDHXVLMUBXG@spammotel.com> wrote:
>  But Unicode/UTF8 would at least satisfy a *lot* more people than plain
> ASCII or 8bit encodings (such as ISO-8859-x)

Would it?

It comes with a very significant hit in the speed of Regex processing,
at least with the current implementation.

Enough to, for many applications, negate the speed benefit everything
that has been optimized from 1.8 to 1.9.  This has been shown with
speed reports on this mailing list previously


I'll note that I work in a non-US character set, and in my experience,
UTF support in a programming language has only been in the way.  So
far, what has been useful to me has always been to have strings be
lists of bytes.

I do not doubt that there are usecases where the support is useful; it
is just that so far I haven't come across them, or the support that
has been there has been unobtrusive enough that I haven't noticed that
it was useful (but I don't think so - all data I have fit nicely in
ISO-Latin-1, because all I work with comes from western Europe or is
in english.)

Note that this sounds like I am against transparent UTF-8 support -
that's not necessarily so.  I just want to make sure that people are
(many) usecases where the support isn't just neutral, it is actually a
drawback (loss of speed, extra complexity, not knowing that the result
of string.length actually means you can put string in a field of
length length), so the upsides had better be worthwhile.

Eivind.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

M. Edward (Ed) Borasky wrote:
| Well ... I guess that depends on which docs you are talking about.
| There's plenty of documentation on Rails, three of the major GUIs --
| Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two
| major Ruby "cookbooks", the documentation on Ruport and RSpec is
| excellent, etc.

I shouldn't have to buy a book (like the PickAxe), to get decent
documentation. A book should be one option, among many, to get to the
documentation. I'll elaborate on that in the next paragraph.

| A week or so ago when the Ruby Mendicant was considering working on the
| docs, I expressed the opinion that the documentation is the
| responsibility of the creator -- someone shouldn't have to do it for
| them. Now if the creator is a better coder than tech writer, perhaps the
| project can take on someone. But my experience has been that it's very
| rare for someone to be an excellent coder and a poor tech writer.

While I agree, that the project is responsible for its own documentation
~ (its rather obvious, is it not?), the tools we have in the Ruby
community to create documentation are limited to RDoc, a rather hacky
solution (Correct me if I'm wrong, but Dave Thomas said as much),
intended as a stand-in until a more useful tool comes around.

Sadly, as it is so common in the world, the temporary solution becomes
the permanent solution, with all its short-comings (see a discussion on
the mixup of Ruby Core and Ruby StdLib documentation on
ruby-doc.org/core). And that is a big obstacle, making it unnecessarily
difficult for newbies like me (I still am a newbie to Ruby, despite
using it for more than a year, the language is just that complex in its
simplicity, which is a major appeal for me, but that is a rant for
another time).

We, as a community, have to provide tools that make it easy and painless
to generate documentation, and generate it in different formats. In my
most humble opinion, we should take a look at Javadoc, and see what we
can steal^H^H^H^H^H implement for Ruby. I fully recognize that Javadoc
is great for Java, and less so for Ruby, but that doesn't mean it
doesn't have useful ideas that make it a breeze to generate 
documentation.

Anecdotal evidence: When building the gem for Gondor Library I was
struggling in including the README and LICENSE files in RDoc. The files
were included in my Rake task's FileList for gem generation, as well as
standalone doc generation.

However, the gem didn't include the files in ./, only ./lib, much unlike
the RDoc task. I had to explicitly tell the gem, to include extra files.
I lost more than an hour to that. The outdated RubyGems documentation
didn't really help. Fortunately, I found other Rake tasks, and could
eliminate the problem.

But it shouldn't be this way, and I have the feeling it is a shortcoming
of RDoc (maybe not, I haven't looked at RDoc itself, so my assessment of
the reason maybe wrong, but my point still stands).

Also, that RDoc generates frames for usage isn't the ideal solution,
IMO, as it makes search difficult (via a browser's search, anyway).

And AFAIK, RDoc cannot spit out PDFs, PostScript, or LaTeX, or something
other than ri. And that makes it unnecessarily difficult to generate
non-RDoc documentation without third party tools (and I don't really
want to learn Yet Another Tool that is not directly related to
increasing my productivity in writing Code (that's what I want to do,
not write comments or documentation).

| 2. My main concern is not with the documentation. My main concern is
| that both the syntax and semantics of the language seem to be more fluid
| than "pragmatic" considerations would dictate. I more or less grew up
| with FORTRAN, although I missed FORTRAN I. So I'll use its evolution as
| an example.
|
| Ten years into its evolution, an ANSI committee was formed to
| standardize the language. Users and vendors sat around a huge table and
| thrashed out what would break the least code, what was easy to
| implement, what kinds of programs people wanted to write in the language
| that they couldn't, etc. The result was FORTRAN 66. 11 years later there
| was FORTRAN 77, etc.

C and C++ went the other way, with the STDLIB growing steadily, and new
features being added. Yet, C/C++ are more in use.

However, both FORTRAN and C are anecdotal evidence. The scope of the
languages is not really the same, and neither is Ruby's.

|
| I think there are enough "killer apps" now that we know what we can't
| take out of Ruby without breaking Rails, RSpec, Ruport, etc. And from
| MRI, KRI, jRuby and Rubinius, I think we know what's easy to implement
| and what isn't. But what I have no clues about is what programs people
| want to write in Ruby that they can't write now.

For the power that Ruby gives me: I want to write everything in Ruby.
It's good at pretty much everything I can throw at it, except
number-crunching. But I can farm that out to C or Java, or maybe .NET
once IronRuby is "production ready".

Personally, I haven't reached the point where I feel that Ruby isn't up
to the task at hand, or severely limited. That's anecdotal, though. I'm
sure that people who have to do some heavy lifting and datamunging to do
have a different opinion on that (but more related to Ruby's speed, than
Ruby's syntax and expressiveness, or am I mistaken?).

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you dream that your SO and yourself are icons in a GUI and you can't 
get
close to each other because the window manager demands minimum space 
between
icons...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7iQIACgkQbtAgaoJTgL8aVgCgjWbCoZyKVMfxGJS0nMOwE9+P
dfgAoJA1nYY99kKFqU68aNS9KO8ca+6G
=Mf9d
-----END PGP SIGNATURE-----

> Now FORTRAN is 50 years old, there's a FORTRAN 95 standard, and the
> language is still in use (I think -- I haven't written any since 1990).

Most definitly. In my office we is it constantly. There's only one
serious contender for number crunching here and it's C, but then C is
much more of a pain to use, and you need to use the correct flags to
get the kind of optimisations that Fortran gives you out of the box.
Oh, and Fortran has now moved to Fortran 2003 standard (and they are
working on 2008). It's a really nice language to write in... though
it's not suitable for that many jobs.

But this is totally OT, sorry. (it's just rare to find another person
with a good opinion of Fortran ^_^)

Diego

On Apr 8, 2008, at 10:02 AM, Phillip Gawlowski wrote:
> While I agree, that the project is responsible for its own  
> documentation
> ~ (its rather obvious, is it not?), the tools we have in the Ruby
> community to create documentation are limited to RDoc, a rather hacky
> solution (Correct me if I'm wrong, but Dave Thomas said as much),
> intended as a stand-in until a more useful tool comes around.

I said it's a hacky _implementation_. I believe the concept is just
fine.

> of RDoc (maybe not, I haven't looked at RDoc itself, so my  
> assessment of
> the reason maybe wrong, but my point still stands).

Sounds like a configuration issue with the gem, to me.

> Also, that RDoc generates frames for usage isn't the ideal solution,
> IMO, as it makes search difficult (via a browser's search, anyway).

The frames are just one option. Have you looked at api.rubyonrails.com?

> And AFAIK, RDoc cannot spit out PDFs, PostScript, or LaTeX, or  
> something
> other than ri. And that makes it unnecessarily difficult to generate
> non-RDoc documentation without third party tools (and I don't really
> want to learn Yet Another Tool that is not directly related to
> increasing my productivity in writing Code (that's what I want to do,
> not write comments or documentation).

Actually, I have it generating all three, as well as plain text, chm,
and our in-house PML markup.

I'm not defending RDoc. But I think that if the situation is to
improve, it should be through informed discussion.

There are a couple of underlying issues. Firstly, much of the basic
Ruby infrastructure is not well documented. Many standard libraries in
the base distribution have minimal documentation, for example. Many
gems are only minimally documented (for example, having just API-level
documentation).

Second, there's no good place to go to see documentation.

I think we have the basis for a great set of documentation. What is
needed now is for someone with vision to take the next step. It
needn't be a big one. In the same way that the RubyGems initiative set
down some simply packaging guidelines that we all follow, I think that
someone could drive through the same for documentation. It needn't be
more than a few conventions. For example, we are used to seeing README
and INSTALL in the top-level of an application. Change Gems to include
these by default. If it sees a HOWTO file, include that. If it sees
GUIDE, do the same. These are just suggestions--someone needs to take
ownership of this and flesh it out properly.

We have the API documentation nut cracked. We need to do the same for
the non-API documentation. And, if we set the conventions in place
now, the tools will be able to use them to build a raft of different
styles of documentation sites.

I'm looking forward to it.



Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Thomas wrote:
|
| On Apr 8, 2008, at 10:02 AM, Phillip Gawlowski wrote:
|> While I agree, that the project is responsible for its own documentation
|> ~ (its rather obvious, is it not?), the tools we have in the Ruby
|> community to create documentation are limited to RDoc, a rather hacky
|> solution (Correct me if I'm wrong, but Dave Thomas said as much),
|> intended as a stand-in until a more useful tool comes around.
|
| I said it's a hacky _implementation_. I believe the concept is just fine.

Err, yes. I like the idea of RDoc myself. I like it very much, almost to
the level of fan boy. It is very easy to generate API docs. But that is
the only thing it can do, it seems.

| Sounds like a configuration issue with the gem, to me.

Yes, it was. I had to tell the gem specifically to find these extra
documents. My chip on my shoulder is, that this shouldn't be necessary,
especially when the RDoc task in my Rakefile actually generates the
documentation without declaring these documents explicitly.

|> Also, that RDoc generates frames for usage isn't the ideal solution,
|> IMO, as it makes search difficult (via a browser's search, anyway).
|
| The frames are just one option. Have you looked at api.rubyonrails.com?

Which is still a frameset. The layout's different, but that's it.

| Actually, I have it generating all three, as well as plain text, chm,
| and our in-house PML markup.
|
| I'm not defending RDoc. But I think that if the situation is to improve,
| it should be through informed discussion.

Yes, of course. I'm not shouting to purge RDoc from the Rubyist's
toolkit, not at all. However, it stopped progressing at some point, and
no body has taken over to expand it.

(However, I have found a github repository that seems to tackle the
issue. And I'm waiting for the source code to take a look at it.)

| There are a couple of underlying issues. Firstly, much of the basic Ruby
| infrastructure is not well documented. Many standard libraries in the
| base distribution have minimal documentation, for example. Many gems are
| only minimally documented (for example, having just API-level
| documentation).

The hashing functions in the STDLIB have no documentation. Having looked
at the STDLIB documentation for Ruby in the past, I'm looking at the web
first, and spend my time tweaking search-engine queries, and find some
sort of tutorial on how to use it. Which makes me sad.

And since I'm not good at reading C, or other people's code just yet, I
can't contribute with documentation patches, and *that* makes me an
unhappy camper: Not being able to contribute in correcting issues I see,
and help out a great community. :/

| Second, there's no good place to go to see documentation.

Indeed. If there were, the Rails API wouldn't be on 5+ websites to look
at. Similar for Ruby's documentation. That it isn't very searchable is
another issue, IMO. (OTOH, neither is Javadoc from what I've seen. Well,
there's no silver bullet, is there?).

| I think we have the basis for a great set of documentation. What is
| needed now is for someone with vision to take the next step. It needn't
| be a big one. In the same way that the RubyGems initiative set down some
| simply packaging guidelines that we all follow, I think that someone
| could drive through the same for documentation. It needn't be more than
| a few conventions. For example, we are used to seeing README and INSTALL
| in the top-level of an application. Change Gems to include these by
| default. If it sees a HOWTO file, include that. If it sees GUIDE, do the
| same. These are just suggestions--someone needs to take ownership of
| this and flesh it out properly.
|
| We have the API documentation nut cracked. We need to do the same for
| the non-API documentation. And, if we set the conventions in place now,
| the tools will be able to use them to build a raft of different styles
| of documentation sites.

To put my money where my mouth is, I'm willing to contribute to this
effort in any way I can. Be it coding, writing documentation, or
evangelizing it..

What I'd like to see, is something like RDoc, which grabs formatted
files (In Textile, Markaby, RDoc's variant,..), and emits documentation,
from files that are in some way specified (a .document extension, maybe.
Something that is convention over configuration, to make the transition
as easy as possible).

I think I can hack up a simple tool that demonstrates what I mean (after
all, there's RedCloth, and Rake's FileList to accomplish what I mean).

Once I have that running, I'm perfectly happy to hand it to anyone who's
more qualified than me to work on this tool.

| I'm looking forward to it.

So am I.

As a personal note: I did not mean to criticize you or your work, Dave.
In fact, if I could find my copy of the Pickaxe again, I'd drag it along
to have you sign it. It was a great help to me in picking up Ruby, and a
very valuable reference for the documentation. Thanks for the effort by
you and all who contributed to it. :)

And I'd go nuts without RDoc to generate API documentation.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you "woke up" this morning and thought, "I'll checkpoint here, snooze
a bit more and then revert to checkpoint."  A while later you go up
another consciousness notch and realize that you hadn't checkpointed
successfully
~ - "Oh, of course.  I didn't have the keyboard."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7lycACgkQbtAgaoJTgL8WjgCgkdQ+8JTKfPj3FoYllVffiVDs
DgkAn28WmpugQ/yH+LyqCpVDcZH0XUnp
=RXLi
-----END PGP SIGNATURE-----

I agree about the API docs.  There has been talk recently about
working on them, but there are some snags we need to get around (I
don't know that you've been privvy to those conversations or not but
if not you should be :)).

As an aside, I'm working on re-implementing RDoc using ruby_parser.
It's in very bad shape right now (transitioning from using RDoc's
CodeObjects stuff to ruby_parser), but you can monitor my work at
http://github.com/jeremymcanally/docr .

The basic plan is to get the parser/normalization stuff in place and
tested this week.  Then I'll try to put a really lightweight bin
script/library in front of it next week.  Most of the same code should
work in that part with minor modification.  Sometime in there I'll be
extracting the markup stuff from RDoc into its own gem/library so it's
more separated from the mainline DocR stuff.  I believe I along with
others have plans to hack in some additions to the markup to give it
some more powerful structures.

Hopefully when this is in decent shape, it will be a well-tested,
nicely implemented Ruby documentation tool.

--Jeremy

On Tue, Apr 8, 2008 at 11:37 AM, Dave Thomas <dave@pragprog.com> wrote:
>  I said it's a hacky _implementation_. I believe the concept is just fine.
> > of RDoc (maybe not, I haven't looked at RDoc itself, so my assessment of
>
> >
> minimally documented (for example, having just API-level documentation).
> sees a HOWTO file, include that. If it sees GUIDE, do the same. These are
>
>
>  Dave
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

On Apr 8, 2008, at 11:04 AM, Jeremy McAnally wrote:
> As an aside, I'm working on re-implementing RDoc using ruby_parser.
> It's in very bad shape right now (transitioning from using RDoc's
> CodeObjects stuff to ruby_parser), but you can monitor my work at
> http://github.com/jeremymcanally/docr .

Could ripper be used for this? Given that 1.9 has it built in, it
would reduce dependencies (on of the goals of RDoc was to have zero
external dependencies, and that still seems like a good idea).

>
> Hopefully when this is in decent shape, it will be a well-tested,
> nicely implemented Ruby documentation tool.

Are you talking to Eric, who's currently working on RDoc for 1.9?


Dave

On Tue, Apr 8, 2008 at 12:05 AM, Phillip Gawlowski
<cmdjackryan@googlemail.com> wrote:
>  Austin Ziegler wrote:
>  | (Yes, Virginia. Most people don't need full-on Unicode munging in
>  | their code. It's necessary when you do need it, but most people don't
>  | need it.)
>  http://www.joelonsoftware.com/articles/Unicode.html
>
>  I need it. Most of Europe needs it. Not to mention Arabia, Japan, and
>  everybody else not speaking English.

You didn't read what I said. I said "most people don't need full-on
Unicode munging." This is true. There are some cases where it's
absolutely necessary, but most people just need to know that they're
not going to screw up things when they work with Unicode.

You can write Unicode-safe applications without needing full Unicode
string munging. Easily. Most Rails apps should probably be doing
exactly that.

And yes, I do know Unicode. Maybe not as well as Tim Bray, but well
enough to know what's actually needed and what isn't. (I just wrote an
app that deals with UTF-8 Unicode strings; I don't modify them at all,
so I've got a Unicode-safe app in Ruby because I'm not mucking with
things that I don't need to muck with.)

Joel's article is oversimplistic on this, really. I stand by what I
said: most people don't need Unicode munging. But when you need it,
you *really* need it and Ruby can fall down flat for you, pre 1.9.
(And yes, if you look above, that *is* what I said.)

-austin

On Tue, Apr 8, 2008 at 7:40 AM, Thomas Kellerer
<YQDHXVLMUBXG@spammotel.com> wrote:
> Marc Heiler, 08.04.2008 13:24:
> > [Unicode]
> > > I need it.
> > I keep on reading people that need Unicode, and in your case it may very
> > well be true and for many others as well.
>  That's precisely the ignorant attitude that caused the issues we currently
> have with differen character sets. I'm pretty sure that if computer systems
> had been emerged from a non-english speaking country at the beginning we
> wouldn't need to still fight character set issues (there are still too many
> applications that even have problems with 8bit character sets)

Unfortunately Marc didn't keep *my* quote which has a lot more
important context than was kept. I never argued that people don't need
Unicode. I said that most people don't need Unicode munging of their
text. Think operations on the strings rather than the existence of the
strings themselves.

>  I'm a newbie with Ruby and until I read this discussion I simply assumed it
> would fully support Unicode "out of the box" especially given the fact that
> is originates from Japan. I'm actually very confused (not to say shocked)
> that there *is* a discussion if Ruby needs (or supports?) Unicode.
>  Unicode (and a relevant encoding such as UTF8) should be the *standard* for
> all (new) programming languages and not an exception.

No, they shouldn't. Yes, Ruby needs Unicode support. But Unicode has a
big problem: legacy data. There's more legacy textual data than there
is Unicode textual data at this point. That will change, yes, but it
isn't so now. Languages that assume that their strings are Unicode
(and make it harder to deal with legacy data) are much harder to work
with for legacy data.

Also, look at the Han Unification discussions regarding Unicode and
you'll see why the lack of Unicode support from Japan through early
this decade isn't surprising. Unicode isn't very friendly to Asian
texts, in terms of storage size. It's not a big deal now that we're
dealing with massive hard drives and our textual data is a minuscule
fraction of our overall data storage (audio, images, video).

Ruby 1.8 has limited (too limited, but there's good historical reasons
for this) support for Unicode; Ruby 1.9 has good support for Unicode
and it's getting better.

History is good to know. It would have prevented this blogger from
being ignorant.

-austin

On Tue, Apr 8, 2008 at 7:54 AM, Trans <transfire@gmail.com> wrote:
> Why is everyone getting so worked up? It's a critique.

critique |krɪˈtiːk| noun
  a detailed analysis and assessment of something, esp. a literary,
  philosophical, or political theory.
verb ( -tiques |krɪˈtiks|, -tiqued |krɪˈtikt|, -tiquing |krɪˈtikɪŋ|) [ 
trans. ]
  evaluate (a theory or practice) in a detailed and analytical way :
  the authors critique the methods and practices used in the research.

The only thing detailed about the blog posting is the author's
ignorance. There's no analysis, just mindless bashing.

-austin

On Tue, Apr 8, 2008 at 9:15 AM, Thomas Kellerer
<YQDHXVLMUBXG@spammotel.com> wrote:
> Bill Kelly, 08.04.2008 14:51:
> > > Unicode (and a relevant encoding such as UTF8) should be the *standard*
> > > for all (new) programming languages and not an exception.
> > Apparently not, as One Character Encoding to Rule Them All is not
> > considered satisfactory to many people.
> But Unicode/UTF8 would at least satisfy a *lot* more people than plain
> ASCII or 8bit encodings (such as ISO-8859-x)

> > Here's a long thread on the subject from the archives: http://tinyurl.com/ge2kp

Please read the thread that Bill pointed you to. It explains a lot
more than you'd think there would be. (And yes, that's a thread that I
was heavily involved in.)

> > Ruby 1.9 has much broader support for handling multiple character
> > encodings.
>  Is there any release plan for 1.9?

When it's ready. 1.9.0 has already been released and there's ongoing
patches to make it better. Follow ruby-core if you want more
information about Ruby 1.9. Matz still recommends Ruby 1.8.x for
production because there may be other incompatible changes with Ruby
1.9, but most of the breakers should be fixed. But it's running on a
(newish) VM, so it's something to work with for exercising the
language. I think that when 1.9.1 comes out, it'll be much closer to
production quality.

-austin

On Tue, Apr 8, 2008 at 11:02 AM, Phillip Gawlowski
<cmdjackryan@googlemail.com> wrote:
>  M. Edward (Ed) Borasky wrote:
>  | Well ... I guess that depends on which docs you are talking about.
>  | There's plenty of documentation on Rails, three of the major GUIs --
>  | Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two
>  | major Ruby "cookbooks", the documentation on Ruport and RSpec is
>  | excellent, etc.
>
>  I shouldn't have to buy a book (like the PickAxe), to get decent
>  documentation. A book should be one option, among many, to get to the
>  documentation. I'll elaborate on that in the next paragraph.

Used to be that was the ONLY way to get documentation.

-austin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Austin Ziegler wrote:
| On Tue, Apr 8, 2008 at 12:05 AM, Phillip Gawlowski
| <cmdjackryan@googlemail.com> wrote:
|>  Austin Ziegler wrote:
|>  | (Yes, Virginia. Most people don't need full-on Unicode munging in
|>  | their code. It's necessary when you do need it, but most people don't
|>  | need it.)
|>  http://www.joelonsoftware.com/articles/Unicode.html
|>
|>  I need it. Most of Europe needs it. Not to mention Arabia, Japan, and
|>  everybody else not speaking English.
|
| You didn't read what I said. I said "most people don't need full-on
| Unicode munging." This is true. There are some cases where it's
| absolutely necessary, but most people just need to know that they're
| not going to screw up things when they work with Unicode.

Without Unicode support, a string operation in a non-English alphabet
will work as expected. Any language with more characters in the alphabet
that English, needs full Unicode support.

|
| You can write Unicode-safe applications without needing full Unicode
| string munging. Easily. Most Rails apps should probably be doing
| exactly that.

Without Unicode support, you can't be Unicode safe. That's a tautology.

Also: Rails rolls its own Unicode support.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you are looking at an ASCII core dump of your OS project which has 
many
O's and &'s in it (among other things), and you shout:
"I see the problem.  Orcs are attacking my demons."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7rNMACgkQbtAgaoJTgL9VggCgpgHK+7+yLEitYjlG0+71Ahkw
otAAn2/jKZS3RmAnMp0sLcyYVGQQzREI
=CSoC
-----END PGP SIGNATURE-----

Someone has suggested that but I haven't looked at it.  I haven't
gotten far with the whole ruby_parser port (it's in place but didn't
take long to write), so switching to something would be fine.  I'll
look into that tonight then, since I didn't know 1.9 had it built in.

I spoke to Eric via mailing list who said he wanted to use ruby_parser
for a new RDoc, but ripper seems like a more logical choice to me.

--Jeremy

On Tue, Apr 8, 2008 at 12:10 PM, Dave Thomas <dave@pragprog.com> wrote:
> reduce dependencies (on of the goals of RDoc was to have zero external
> > extracting the markup stuff from RDoc into its own gem/library so it's
>
>  Dave
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

On Apr 8, 2008, at 12:05 PM, Jeremy McAnally wrote:
> Someone has suggested that but I haven't looked at it.  I haven't
> gotten far with the whole ruby_parser port (it's in place but didn't
> take long to write), so switching to something would be fine.  I'll
> look into that tonight then, since I didn't know 1.9 had it built in.
>
> I spoke to Eric via mailing list who said he wanted to use ruby_parser
> for a new RDoc, but ripper seems like a more logical choice to me.

It's easy to beat up the documentation. It's a time-honored tradition.
Still, the fellow's post zeroed in on digest, and the fact that it's
not documented at all. If you go to php.net (ick) and type 'sha1' in
the search box, you get this: 
http://us.php.net/manual/en/function.sha1.php
  (or maybe something else if you aren't in the US). The point is, the
answer is relevant and if you knew why you needed SHA1, you would
probably have your answer including an example.

For whatever reason, PHP has quite usable documentation. Now, for a
different experience, go to http://msdn.microsoft.com and type
'sha1' (assuming you have no objection to installing Silverlite). You
will get tons of information, but you have to do a lot of wading to
find what you're looking for. Ruby can do better.

My opinion (FWIW). Good documentation should be:

Fast to load
Cross browser
Cross platform
Downloadable as an alternative
Extremely searchable (consider typing "encryption" in PHP's search box)
Commentable by the community

It should:

Contain specific information about a module's "purpose", a class's
"overall description", and specifics on argument types, defaults, and
return types, as well as exceptions raised. Examples are extremely
useful.

Having pontificated for some time, I recognize that this is a tall
order and that the main problem is not that the Ruby documentation is
"not there", but rather that the coverage is not uniform --
particularly in the standard library. As an example, pretend you don't
know much about YAML and want to figure out how to load a YAML
document from a file. What is your search strategy and how many clicks
does it take you to arrive at sufficient information using the current
API docs.

Just my $.02

Php's docs are good, really good.  But I always felt that it's because
it's a domain specific language.

It lives, breaths and is a web language.  Sure, you can use it as
general purpose, but it was designed for the web.
With that mindset they made possibly the best web-friendly docs I've 
ever seen.

Ruby on the other hand was developed because some hacker got an itch,
and wanted something kindof like lisp, only better.
It's definitely documented like a hacker language.  Good docs are
eventually written, but very rarely updated, because hackers generally
have something better to do than document: hack their language and
make it better.

There needs to be something like a ruby-illumination (see
http://en.wikipedia.org/wiki/Illumination_(manuscript) ) going on.
Maybe at the big ruby conferences a bunch of ruby hackers can be paid
in pizza to spend 8 or so hours on a mass documenting session.  Make
the docs beautiful in every way: correct, complete, elegantly written,
indexed, and, of course, aesthetically.
For fun have them all in monks robes, and bring them dark German
beer.....but no more than 1L per hour.

Just my thought.
--Kyle

We're probably going to do something like that for Rails at RailsConf
at the community code drive, but there's no saying that we couldn't
work on Ruby too (or even more so, work on them at Cabooseconf).

--Jeremy

On Tue, Apr 8, 2008 at 4:00 PM, Kyle Schmitt <kyleaschmitt@gmail.com> 
wrote:
>  eventually written, but very rarely updated, because hackers generally
>  beer.....but no more than 1L per hour.
>
>  Just my thought.
>  --Kyle
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

Complete with the monk robes, pizza and 1 liter of dark beer per hour?

Sounds like something that'll be really good for everyone.


On Tue, Apr 8, 2008 at 4:10 PM, Jeremy McAnally

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Schmitt wrote:
| Complete with the monk robes, pizza and 1 liter of dark beer per hour?
|
| Sounds like something that'll be really good for everyone.
|

If it doesn't produce documentation, the beer will at least produce
alcoholics. :P


- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

At these prices, I lose money--
but I make it up in volume.
~ -- Peter G. Alaquon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf74Y8ACgkQbtAgaoJTgL9hMgCfS4OK49X0ZaZJv4ZZ7+Psdmos
MqQAnRk89uWma8u0UMDblW+/NbOipHE9
=zpa1
-----END PGP SIGNATURE-----

Phillip Gawlowski wrote:
> Kyle Schmitt wrote:
> | Complete with the monk robes, pizza and 1 liter of dark beer per hour?
> |
> | Sounds like something that'll be really good for everyone.
> |
> 
> If it doesn't produce documentation, the beer will at least produce
> alcoholics. :P

That, or a pissing match. Which is what discussions of why ruby docs
"aren't good enough" usually degenerate into.

Hoping this turns into a constructive effort....

On Tue, Apr 8, 2008 at 2:00 PM, Kyle Schmitt <kyleaschmitt@gmail.com> 
wrote:

> Php's docs are good, really good.  But I always felt that it's because
>  it's a domain specific language.

If PHP's docs are good, then Perl documentation must be qualified as
simply extraordinary (and that's true for most modules at CPAN, too).

That's the one thing where I still feel that Ruby doesn't even begin to 
compare.

Perl documention is wonderfully intergrated to the environment where
it's installed (at least that's true for UNIX, I don't know for
Windows), it's very informative (man perl), very complete and very
simple to use.  I actually learned Perl when I was a student and the
Camel and Llama books where in the "too expensive" category, which
means I learned from the documentation shipped with Perl itself.  I
don't think I would be able to say the same thing for Ruby (which I
learned from the Pickaxe, but I would have probably preferred the
current edition of TRPL if it had been available back then).

And yes, I have been thinking about contributing patches around this.
What stops me is that I don't like ri that much, to be honest, which
probably means that I have to submit patches against ri first.

Marcelo

Kyle Schmitt wrote:
> Php's docs are good, really good.  But I always felt that it's because
> it's a domain specific language.
> 
> It lives, breaths and is a web language.  Sure, you can use it as
> general purpose, but it was designed for the web.
> With that mindset they made possibly the best web-friendly docs I've ever seen.

I'm curious. Who is "they"? Who wrote these docs? The PHP developers?
The PHP community? Professionals? What was their incentive? What was
their reward?

El Martes, 8 de Abril de 2008, Joel VanderWerf 
escribi�:
> different. It happens that they are the same for strings (and why not).
> They don't have to be the same for other things.

Very good example ;)

They were most likely written by those paid by Zend and Yahoo.

--Jeremy

On Tue, Apr 8, 2008 at 6:20 PM, Tim Hunter <TimHunter@nc.rr.com> wrote:
>
>  I'm curious. Who is "they"? Who wrote these docs? The PHP developers? The
> PHP community? Professionals? What was their incentive? What was their
> reward?
>
>  --
>  RMagick: http://rmagick.rubyforge.org/
>  RMagick 2: http://rmagick.rubyforge.org/rmagick2.html
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

On Apr 7, 9:00 pm, Austin Ziegler <halosta...@gmail.com> wrote:
>    Oniguruma package... In general, it's a bad sign when a third-party
>
> The author is similarly wholly ignorant of Ruby 1.9 and Ruby 2.0
> discussions and assumes that "lack of English documentation" is the
> same as "lack of documentation." The author is a fool for believing
> the claim that Ruby 2 has been in development longer than Perl 6. Perl
> 6 was ramping up as I switched to Ruby in 2002 and Ruby 1.8 was
> released a bit after that (I got my Ruby 1.8 Pickaxe at the 2005
> RubyConf in San Diego). Matz has been talking about the next
> generation of Ruby (Ruby 2.0) for a while, but that's no different
> than the discussions and experiments surrounding Py3k.




> Worst of all, the author treats both theAliothshootoutand the Zed
> Shaw rant as things worthy of positive attention, when both are, well,
> worthless. TheAliothshootouthas been known to be worthless for
> years yet periodically some idiot treats it as serious.

Once upon a time, you made a specific complaint that the execution
environment, on what used to be called the computer language shootout,
stopped a Ruby Ackermann program from doing it's stuff - that problem
was fixed.

Unfortunately, since then your comments about what is now called the
benchmarks game don't amount to more than name calling.

On Apr 8, 2008, at 3:42 PM, Jeremy McAnally wrote:
>>> it's a domain specific language.
>> PHP community? Professionals? What was their incentive? What was  
>> their
>> reward?

And there are no similar companies who would either profit from or be
helped by superior Ruby documentation? Everyone from IBM to Sun to
Apple to (even) Microsoft now have stakes in Ruby. All the Rails-
centric hosting services are stakeholders. Surely they are as invested
if not more so than Zend and/or Yahoo in the early days of PHP.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

s.ross wrote:
| On Apr 8, 2008, at 3:42 PM, Jeremy McAnally wrote:
|
| And there are no similar companies who would either profit from or be
| helped by superior Ruby documentation? Everyone from IBM to Sun to Apple
| to (even) Microsoft now have stakes in Ruby. All the Rails-centric
| hosting services are stakeholders. Surely they are as invested if not
| more so than Zend and/or Yahoo in the early days of PHP.

Not really, no. Their interests are different than that of Zend or
Yahoo!. Zend benefits from sales of their PHP runtime (or benefited,
it's been awhile since I was looking at the state of the PHP ecosystem),
and Yahoo can recruit developers easier (their services run on PHP).

Sun, IBM, etc. profit by providing tools to developers. However, only
indirectly, since the runtimes, connectors, or IDEs offered are open
source, and not directly sold, or the projects were acquired to benefit
the core business (.NET/Java in case of MS/Sun, DB2 in case of Java).

And the Rails hosters? How do they profit from a better Ruby
documentation? They only have to care about Rails' API, and the Rails
blogosphere covers that, too (see Railscasts, for example). These folk
care about easy hosting of Ruby. And IronRuby or JRuby make that easier,
as well as the new mod_rails by Phusion will help in that area, too.


- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you send email to somebody who's three terminals down the lab.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7/igACgkQbtAgaoJTgL8BEACfdxhFV1e4tKP5psF1bclaFTEP
m3AAoIKQkI7lFKu0RyJV4kviUq9CNQnb
=uwrM
-----END PGP SIGNATURE-----

2008/4/8 Rob Sanheim <rsanheim@gmail.com>:
>
>  The only good point in that whole mess is that the current state of
>  docs for Ruby is poor, and could use a lot of love.

That, and that it'd be useful to have a backtrace that shows the lines
of code in question. Should be implementable as a postprocessor.

martin

I thought it did.

require 'jcode'

Julian.



Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

We have to be a little careful here...

Can I ask you - do you think life is perfect?

Perhaps it is, perhaps it isn't, it depends on perspective, don't you
think?

Ruby is NATURAL.

Julian.


Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

On Tue, Apr 8, 2008 at 7:00 PM, Isaac Gouy <igouy2@yahoo.com> wrote:
> On Apr 7, 9:00 pm, Austin Ziegler <halosta...@gmail.com> wrote:
>  > Worst of all, the author treats both theAliothshootoutand the Zed
>  > Shaw rant as things worthy of positive attention, when both are, well,
>  > worthless. TheAliothshootouthas been known to be worthless for
>  > years yet periodically some idiot treats it as serious.
>  Once upon a time, you made a specific complaint that the execution
>  environment, on what used to be called the computer language shootout,
>  stopped a Ruby Ackermann program from doing it's stuff - that problem
>  was fixed.

I haven't gone back to the Alioth shootout web site in a long time,
because the problem was originally reported at least a year before it
was fixed.

>  Unfortunately, since then your comments about what is now called the
>  benchmarks game don't amount to more than name calling.

No, it's a lot more than name calling. It's still treated far more
seriously than it deserves to be treated.  Since I haven't looked at
the "benchmarks game" in a while (I don't visit places that are
useless), I don't know if your text is any better than it was two
years ago (the last time I wasted any time there) to make it clear
that no one should take anything presented on the "benchmarks game"
seriously. I'll assume for the moment that you have improved it and
that now it's because people like this author are stupid and take
something like the "benchmarks game" seriously when it never should
be.

-austin

Diego Virasoro wrote:
>> Now FORTRAN is 50 years old, there's a FORTRAN 95 standard, and the
>> language is still in use (I think -- I haven't written any since 1990).
> 
> Most definitly. In my office we is it constantly. There's only one
> serious contender for number crunching here and it's C, but then C is
> much more of a pain to use, and you need to use the correct flags to
> get the kind of optimisations that Fortran gives you out of the box.

Right around the time I stopped writing Fortran (not by choice -- I got
laid off) C compilers were just starting to appear that could compete
with Fortran. The way people wrote C in those days was so infested with
pointers and mallocs that a lot of code was simply hopeless. Then again,
people wrote compilers, operating systems, text processors,
interpreters, etc., in C, and they wrote number crunching in Fortran.

I used to work with the people who developed the second usable C
compiler for number crunching (the first was developed by a competitor. 
:)

> programs people wanted to write in the language that they couldn't, etc. The
> But what I have no clues about is what programs people want to write in Ruby
> that they can't write now.
>
>
> This is the insightful point I was expecting after following such a  long
mail chain. Now I am implementing one Rails application which requires 
to be
supported by both MRI (1.8.5) and JRuby (1.0.3, compatible with MRI 
1.8.5).
I found so many inconsistencies between these two "Ruby". (Or Rubies?). 
Even
the MRI test cases can not pass in JRuby. That's painful.  I remembered
Charles Nutter asked Matz in RubyConf 2007 if there is going to have any
specification for Ruby. But apparently it doesn't happen.

Song Ma wrote:
> This is the insightful point I was expecting after following such a  long
> mail chain. Now I am implementing one Rails application which requires to be
> supported by both MRI (1.8.5) and JRuby (1.0.3, compatible with MRI 1.8.5).
> I found so many inconsistencies between these two "Ruby". (Or Rubies?). Even
> the MRI test cases can not pass in JRuby. That's painful.  I remembered
> Charles Nutter asked Matz in RubyConf 2007 if there is going to have any
> specification for Ruby. But apparently it doesn't happen.

There are partial test suites/specs out there, but probably no single
one that's "definitive". I haven't heard much about the BFTS (Big Formal
Test Suite) recently.

The last rumor I heard was that the "canonical" Ruby test suite was most
likely going to come out of the Rubinius project. Can someone confirm or
deny that? I haven't been tracking Rubinius recently.

--- Austin Ziegler <halostatue@gmail.com> wrote:

> shootout,
> >  stopped a Ruby Ackermann program from doing it's stuff - that
> problem
> >  was fixed.
> 
> I haven't gone back to the Alioth shootout web site in a long time,
> because the problem was originally reported at least a year before it
> was fixed.

It was fixed at the end of October 2005, your mailing list complaints
were in June 2005 - although you were still wrongly claiming it was
broken April 4 2006.


> seriously. I'll assume for the moment that you have improved it and
> that now it's because people like this author are stupid and take
> something like the "benchmarks game" seriously when it never should
> be.

Bad mouthing something you haven't even looked at in 2 years, seems
like you already have the material for - an indepth essay.


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster 
Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

On Apr 8, 2008, at 4:22 PM, Phillip Gawlowski wrote:

> | to (even) Microsoft now have stakes in Ruby. All the Rails-centric
> | hosting services are stakeholders. Surely they are as invested if  
> not
> | more so than Zend and/or Yahoo in the early days of PHP.
>
> Not really, no. Their interests are different than that of Zend or
> Yahoo!. Zend benefits from sales of their PHP runtime (or benefited,
> it's been awhile since I was looking at the state of the PHP  
> ecosystem),
> and Yahoo can recruit developers easier (their services run on PHP).

Sun (apparently) benefits when the Java runtime is distributed. All
the hardware vendors benefit when more applications are written for
their platforms. When I say these vendors have embraced Ruby, what I
really mean is that they've latched onto Rails. They see the benefit
of Rails and how people deploying more applications is a path to
selling more platforms (either OS or hardware). Right now, there are
fewer good Ruby programmers available than most other segments of the
programming community. Good developers tend to be good learners, and
the better the material, the more quickly they can learn. More
programmers implies more applications, which may mean more indirect
sales for IBM, Sun, etc. So, while they are not selling proprietary
Ruby runtimes, there are many companies who profit if the people who
write Rails apps can "speak the language," as it were.

> easier,
> as well as the new mod_rails by Phusion will help in that area, too.

I think we're going to have to agree to disagree on this one. Rails
hosters do not benefit from managing servers in a constant state of
meltdown from rogue Ruby processes. Is this the fault of the
documentation? I don't think so, but again, I believe it's possible to
convince yourself you can write a Rails application without grokking
much of Ruby.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

s.ross wrote:

| Sun (apparently) benefits when the Java runtime is distributed. All the
| hardware vendors benefit when more applications are written for their
| platforms. When I say these vendors have embraced Ruby, what I really
| mean is that they've latched onto Rails. They see the benefit of Rails
| and how people deploying more applications is a path to selling more
| platforms (either OS or hardware). Right now, there are fewer good Ruby
| programmers available than most other segments of the programming
| community. Good developers tend to be good learners, and the better the
| material, the more quickly they can learn. More programmers implies more
| applications, which may mean more indirect sales for IBM, Sun, etc. So,
| while they are not selling proprietary Ruby runtimes, there are many
| companies who profit if the people who write Rails apps can "speak the
| language," as it were.

Sun brought the JRuby project into its fold Java fold after it had
proven that it was viable. Without the docs. Same for IronRuby: MS
brought IronRuby into the .NET fold after it had proven itself capable
(and after Sun started to support JRuby, too).

To MS and Sun Ruby is a tool to sell *their* services, to lock you into
*their* platforms.

Don't think that corporations act out of the goodness of their hearts,
especially not publicly traded companies like MSFT and JAVA.

To these companies, open source, and open source projects, mean
outsourcing of development, and minimizing the risks they face, since
next to none of their developers are tied up in something that might
turn out to be a bust (Ruby is far, far from being a major player).

And what does that have with documentation: Nothing. As far as I can
see, there is little to no contribution by the JRuby or IronRuby project
to contribute to the documentation. And that isn't their scope, either.

And as far as documentation goes: Sun, Java, IBM, etc. are not
interested in supplying documentation. Why should they? We all picked up
Ruby with less than satisfactory documentation already. Why should they
infest money in something, that stops weeding the grain from the chaff?
When they get to pick those who have *shown* that they can dig into Ruby
without help?

Besides, why should Sun, MS, IBM, Oracle sink money into something, that
The Pragmatic Bookshelf, O'Reilly, and Addison-Wesley already provide?

Who here doesn't have either A) Programming Ruby, B) The Ruby
Programming Language, C) The Ruby Way, D) all of the above?

And why should we, as people who's skills are in high demand destroy our
own market by supplying good documentation? If Ruby and Rails skills are
in short supply, I'll see to it that I can extract as much money out of
clients as is possible. Especially because I *can* demand that much
money, because I *am* that much more productive in Ruby than in other
languages. It is illogical for me to destroy my own income.

However, I am illogical, and want a good documentation across the board,
because I think that not the language and its documentation matters, in
the end, but what is between my ears.

Still, no corporation has a particular incentive to provide
documentation if it costs them money.

Heck, they only need to get those of us into their boat, that are
already there. They don't need to actively increase the pool of Ruby
programmers, when we do the marketing much more effectively (who's
trustworthier: Sun's Ruby Evangelist on CNET, or you, when you talk to
friends how awesome Ruby is, because you can do all kinds of nifty stuff
with it?).

|> Sun, IBM, etc. profit by providing tools to developers. However, only
|> indirectly, since the runtimes, connectors, or IDEs offered are open
|> source, and not directly sold, or the projects were acquired to benefit
|> the core business (.NET/Java in case of MS/Sun, DB2 in case of Java).
|>
|> And the Rails hosters? How do they profit from a better Ruby
|> documentation? They only have to care about Rails' API, and the Rails
|> blogosphere covers that, too (see Railscasts, for example). These folk
|> care about easy hosting of Ruby. And IronRuby or JRuby make that easier,
|> as well as the new mod_rails by Phusion will help in that area, too.
|
| I think we're going to have to agree to disagree on this one. Rails
| hosters do not benefit from managing servers in a constant state of
| meltdown from rogue Ruby processes. Is this the fault of the
| documentation? I don't think so, but again, I believe it's possible to
| convince yourself you can write a Rails application without grokking
| much of Ruby.

Damn straight it is possible. It doesn't produce good apps, but since
when did quality matter? PhpBB2, anyone? NukePHP?

Sure, for good Rails apps that go beyond the CRUD application, you need
programming skills that go beyond has_many :through.

But don't overestimate the power of Ruby, compared to Rails abilities to
shield its users from writing more Ruby than is needed to get the job 
done.

Heck, with Rails plugin system, there is no need to write a particular
piece of code, unless on has to!

The work has already been done, and continues to be done, by the OSS
community. Why sink money into that? Why provide something for the
community, when the community puts up with (self-inflicted) abuse?

Why? It only costs them money and resources, they can spend on making
their core business attractive to us.

And know what: JRuby enables me to use the *existing* Java
infrastructure. To use the *existing* JRE and leverage Sun's *already
existing* investment.

JRuby helps sell Sun SPARC servers, and *that* is what interests Sun.
Not that Ruby is so much better than Java. It's a tool to give folk a
taste of the Java stack.

The same goes for IronRuby and IronPython.

And I love the irony that we are doing that ourselves. That we have this
adorable naivety, that Ruby matters because it is better.

I'm making myself a victim of Sun, MS, IBM, and Oracle. Again. And
again. But hey, Ruby makes for a very good carrot, doesn't it?

And hosters want to solve the hosting problem, not the documentation
problem. And, if possible, they only want to solve it for themselves.
Heck, with an unsolved hosting problem on the market, and demanding a
viable 200 USD per slice per month, a certain corporation recoups the
costs they have to invest handily, by solving that problem for
themselves, and getting a reputation for being the most stable host
among dozens for unstable ones. A Unique Selling Proposition handed to
them by DHH and the Rails community. Ain't live grand?

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you want to wash your hair and think:  awk -F"/neck" '{ print $1 }' |
shower
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf8UG0ACgkQbtAgaoJTgL8gYwCZAVguINB/nohsS24WcxIwrpdL
PswAniOBjmBvBCxpP0B0Y3mQ87P4cQCa
=9boU
-----END PGP SIGNATURE-----

On Wed, Apr 9, 2008 at 12:27 AM, Isaac Gouy <igouy2@yahoo.com> wrote:
>  --- Austin Ziegler <halostatue@gmail.com> wrote:
>> I haven't gone back to the Alioth shootout web site in a long time,
>> because the problem was originally reported at least a year before it
>> was fixed.
>  It was fixed at the end of October 2005, your mailing list complaints
>  were in June 2005 - although you were still wrongly claiming it was
>  broken April 4 2006.

I wasn't wrong, in that case. Your text was still taking itself far
too seriously as of April 2006. Frankly, the runtime-problems have
been minor issues compared to the seriousness with which people take
the shootout. Look: we all know that benchmarks without context are
crap, and the way that the Perl submissions for some of the synthetic
benchmarks were written proves that. The one thing that something like
the "benchmark game" can't do is provide context, since the context of
benchmarks is a person's specific application needs.

The single benchmark I pointed out was symptomatic, but the problem
was ALWAYS that the shootout took itself too seriously, which
encouraged idiots to take it too seriously. And yes, *that* message
has been constant in my criticisms of your pet project, Isaac.

>  Bad mouthing something you haven't even looked at in 2 years, seems
>  like you already have the material for - an indepth essay.

I didn't actually badmouth the shootout this time, Isaac. I said that
the authors of the posts were idiots for using the shootout in a
serious comparison.

I'd say the same thing about Rubyists who wanted to use the shootout
to prove their point in the positive. It is, after all, just a
worthless game and not worthy of any time wasted on it.

-austin

On Apr 9, 2008, at 7:04 AM, Austin Ziegler wrote:
>> It was fixed at the end of October 2005, your mailing list complaints
>> were in June 2005 - although you were still wrongly claiming it was
>> broken April 4 2006.
>
> I wasn't wrong, in that case.


/me is tempted to invoke Godwin at this point...

On Apr 8, 2008, at 10:55 PM, M. Edward (Ed) Borasky wrote:
>> remembered
> confirm or deny that? I haven't been tracking Rubinius recently.
The specs being created as part of the rubinius project are being spun
off to a separate project called rubyspecs. I don't think there's a
website yet, but chatter on irc indicates it will be launched within
the next few months.

These specs are already heavily used by both rubinius and jruby. Rumor
has it that the IronRuby project is also using them. There is hope the
Sapphire Ruby fork project will use the specs too.

The only major project which has shown no interest in using them is MRI.

cr

On Wed, Apr 09, 2008 at 09:04:28PM +0900, Austin Ziegler wrote:
> The single benchmark I pointed out was symptomatic, but the problem
> was ALWAYS that the shootout took itself too seriously, which
> encouraged idiots to take it too seriously. And yes, *that* message
> has been constant in my criticisms of your pet project, Isaac.

Sounds like a case of the pot calling the kettle black.

> I didn't actually badmouth the shootout this time, Isaac. I said that
> the authors of the posts were idiots for using the shootout in a
> serious comparison.

I think you called the shootout "worthless."

The shootout is a metric, and it is a useful metric, just like the
benchmarks jruby and rubinius use to improve performance are useful
metrics.  You're right that some people apply the metrics beyond where
their scope, and they are wrong to do that.  However, your melodramatic
wording makes it difficult to take this point seriously.

Paul

On Tue, Apr 8, 2008 at 5:20 PM, Tim Hunter <TimHunter@nc.rr.com> wrote:
> Kyle Schmitt wrote:
> > With that mindset they made possibly the best web-friendly docs I've ever
> seen.
>  I'm curious. Who is "they"? Who wrote these docs? The PHP developers? The
> PHP community? Professionals? What was their incentive? What was their
> reward?

I suppose I'm using they as the amorphous PHP
developers/community/whoever wrote them. :)

One thing to remember about the PHP docs, is that there is a post
section associated with each page of the documentation.  People who
write PHP code for a living, and people who write PHP itself often
post bugs, possible gotchas, more detailed examples, and corrections
in that area.  Newbs and amateur PHP coders often pose questions as to
the usage of those functions in that same area, and often get
responses.  I was under the impression that all those get rolled into
the main docs periodically.

--Kyle

Chuck Remes wrote:
> The specs being created as part of the rubinius project are being spun 
> off to a separate project called rubyspecs. I don't think there's a 
> website yet, but chatter on irc indicates it will be launched within the 
> next few months.
> 
> These specs are already heavily used by both rubinius and jruby. Rumor 
> has it that the IronRuby project is also using them. There is hope the 
> Sapphire Ruby fork project will use the specs too.
> 
> The only major project which has shown no interest in using them is MRI.

And KRI, since the syntax and semantics are different from Ruby 1.8. :)

On Wed, Apr 9, 2008 at 9:47 AM, Paul Brannan <pbrannan@atdesk.com> 
wrote:
> On Wed, Apr 09, 2008 at 09:04:28PM +0900, Austin Ziegler wrote:
>  > The single benchmark I pointed out was symptomatic, but the problem
>  > was ALWAYS that the shootout took itself too seriously, which
>  > encouraged idiots to take it too seriously. And yes, *that* message
>  > has been constant in my criticisms of your pet project, Isaac.
>  Sounds like a case of the pot calling the kettle black.

Whatever. If people are willing to treat this thing with any
seriousness, far be it from me to stop them from being stupid.

>  > I didn't actually badmouth the shootout this time, Isaac. I said that
>  > the authors of the posts were idiots for using the shootout in a
>  > serious comparison.
>  I think you called the shootout "worthless."

That's because it *is*. Its latest name change makes that clear: it's
a game. It doesn't actually provide comparative value. It's not
badmouthing to say something that the thing says about itself. My
biggest beef with it (aside from people who take it seriously) is that
it took itself too seriously for far too long. Yeah, there was a page
buried four links deep that said "this shouldn't be taken seriously",
but that's not what the majority of the pages said. For a LONG time.

If, in fact, it doesn't take itself seriously anymore, I have no
problem with the shootout (or "benchmark game") as such anymore. I
instead have a problem with the fools who take it seriously.

-austin

--- Austin Ziegler <halostatue@gmail.com> wrote:

> 
> a game. 
"3 a (1): a physical or mental competition conducted according to rules
with the participants in direct opposition to each other"

On Apr 8, 10:53 am, Song Ma <songm...@gmail.com> wrote:
> [Note:  parts of this message were removed to make it a legal post.]
>
> F.Y.I
>
> Not sure if you guys have read this article, I am going to re-post it here.
>
> http://glyphobet.net/blog/essay/228

I have read most of the comments in this forum. Most of them are
helpful while some key points in the blog were not touched.
This is an example:
"In another incident in the same article, the original Rails author
admits that the original Rails code required about four hundred
restarts a day, or six to seven restarts per thread per day. Four
hundred restarts a day means four-hundred chances for a database
transaction to fail...."
The question is:  Is the statement true?
Why should I concern this? Because my next project will be a
webgame(for thoese who don't know webgame, please visit 
www.travian.com).
I'm considering use Ruby on rails to develop this web app. For such
application, beging stable is extremedly important or the player will
leave with anger when data was lost, data being inconsistency or
something like that.
If the statement is true, then should I turn from rails to Pylons?

On Apr 7, 2008, at 21:05 PM, Phillip Gawlowski wrote:
> everybody else not speaking English.
I think you'll find disagreement that Japan wants it, or needs it.
Han unification (http://en.wikipedia.org/wiki/Han_unification) is one
reason why there is discomfort with it, and if you search around the
archives for emails from Matz containing Unicode, you should find a
couple others that describe why Ruby 1.9's M17N features are taking
the path they are.

I think it would be simpler to just switch everything to be Unicode-
only than to take the path of Ruby 1.9.  Instead, Ruby 1.9 supports
many character encodings, and I have to believe that there's a good
reason behind that.

> I have read most of the comments in this forum. Most of them are
> helpful while some key points in the blog were not touched.
> This is an example:
> "In another incident in the same article, the original Rails author
> admits"

Chris,
I understand you here. But what others should also understand - namely a 
very few Python hackers, or other people that take a habit to jump 
bandwagons - is that there is the language Ruby, and the framework Ruby 
on Rails. I have nothing against RoR, but I have something against 
people that put all things in the same bag. (I recommend people to read 
more objective blogs like the one that talks about python and ruby 
filling the same niche in a software ecosystem)
I guess anyone could rant for hours how horrible "language x" with 
"framework y" is and I am sure if this is hyped again and again in a 
blogosphere, some "language x" people would feel unhappy. (Not to excuse 
the RoR folks, who hyped RoR a lot too.)

I am rather tired to see blog posts where the two (Ruby, and Ruby on 
Rails) are intertwined and confused. Sure, one needs Ruby to use RoR, 
but some people write as if the two are the same.
The "coolest" people are those that write "Ruby and Rails" - but they 
clearly mean "Ruby on Rails", not Ruby and RoR ... makes you wonder if 
they cant even get the name right.... I mean the homepage alone should 
give one a clear hint about the name -> www.rubyonrails.org but may they 
never visited. Anyway...

Now to your other point [about speed]:
> If the statement is true, then should I turn from rails to Pylons?

You see, if people only use app solutions and ditch languages happily in 
favour for app x or app y (which is a perfectly fine attitude IMHO), 
then I would be in agreement that switching makes sense if you find 
specific drawbacks in an app. You can even read a comment about DHH 
praising php (for its ability for www usage), though this is of course 
not my opinion, because I think php needs to go away...  ;)
But lets be honest - often you just trade in one disadvantage with 
another if you switch frameworks. And sometimes you trade in more 
disadvantages.

RoR is also not the only web framework for Ruby.
(And Pylons not the only one for Python.)

I dont think anyone can recommend _YOU_ here to switch to a totally 
different language if your use scenario already depicts a way to a 
framework _outside_ of ruby. Because after all you will be writing 
either python, or ruby code, right? So I dont think its fair to 
recommend a framework in ANOTHER language - I mean, I would recommend 
people to use ruby over python. Ok let's put it bluntly...

Go use Ramaze. http://ramaze.net/

But even more importantly, decide if ruby as a language is for you, or 
whether you want to pick up python. Then these questions can more 
readily be addressed - besides I believe python and ruby are still 
filling a very similar use scenario/ecosystem. The common enemy should 
be PHP and its www dominance ;)

On Wed, Apr 09, 2008 at 10:33:53PM +0900, Chuck Remes wrote:
>>> apparently it doesn't happen.
> off to a separate project called rubyspecs. I don't think there's a
> website yet, but chatter on irc indicates it will be launched within the
> next few months.
>
> These specs are already heavily used by both rubinius and jruby. Rumor
> has it that the IronRuby project is also using them. There is hope the
> Sapphire Ruby fork project will use the specs too.
>
> The only major project which has shown no interest in using them is MRI.

I'm pretty sure I remember Matz having good things to say about them at
RubyConf 2007. I think the main issue is that very little time or effort 
is
being put into MRI in favor of YARV-based 1.9 development. Since Ruby 
1.9
(the language) is not compatible with 1.8, and hasn't been 100% nailed 
down
as I understand it, the test suite would need some revising before it 
could
be used for what is actually being developed right now.

> cr
--Greg

2008/4/8, Phillip Gawlowski <cmdjackryan@googlemail.com>:
>  |>  http://www.joelonsoftware.com/articles/Unicode.html
>  will work as expected. Any language with more characters in the alphabet
>  that English, needs full Unicode support.

This is wrong. My native language is German, and although the
situation is not ideal, the provided UTF-8 support in
combination with iconv was sufficient for me.

There are a number of features that seem to be little known:

* Just because Ruby doesn't have full (whatever that means)
  Unicode support, it does not throw away bytes not in ASCII.
  A Ruby string can hold _any_ byte sequence.

* Ruby comes with the Iconv library for encoding conversion.

* UTF-8 is backwards compatible with ASCII. Any byte in an UTF-8
  string that looks like an ASCII character _is_ that character.
  Thus you can safely split any UTF-8 strings on ASCII
  characters. You can safely split UTF-8 strings on UTF-8
  strings, search for UTF-8 strings, safely concatenate
  UTF-8 with UTF-8 or ASCII strings, etc.

* Ruby's regex engine has some support for UTF-8.

* As Vidar Hokstad pointed out, you can turn UTF-8 strings into
  arrays of unicode code points via unpack.

  "����".unpack("U*").length  # => 4
  "����".unpack("U*").reverse.pack("U*") # => 
"���"
* In some cases, like case-insensitive comparison, you can let
  your database work for you.

Not to mention that what I've seen so far of Ruby 1.9's encoding
and Unicode support looks good. (In contrast to say, Java.  I
wonder how many Java methods deal correctly with surrogate pairs
and how many Java programmers know that the char type has little
to do with characters.)

Stefan

Gregory Seidman wrote:

> I'm pretty sure I remember Matz having good things to say about them at
> RubyConf 2007. I think the main issue is that very little time or effort is
> being put into MRI in favor of YARV-based 1.9 development. Since Ruby 1.9
> (the language) is not compatible with 1.8, and hasn't been 100% nailed down
> as I understand it, the test suite would need some revising before it could
> be used for what is actually being developed right now.

There are de facto test suites for 1.9.

1. Programming Ruby, 3rd Edition
2. Rails
3. Rspec
4. ZenTest

...

;)

On Apr 10, 2008, at 6:31 AM, Gregory Seidman wrote:
>>>> pass
>>> Test Suite) recently.
>> next few months.
> I'm pretty sure I remember Matz having good things to say about them  
> at
> RubyConf 2007. I think the main issue is that very little time or  
> effort is
> being put into MRI in favor of YARV-based 1.9 development. Since  
> Ruby 1.9
> (the language) is not compatible with 1.8, and hasn't been 100%  
> nailed down
> as I understand it, the test suite would need some revising before  
> it could
> be used for what is actually being developed right now.

Greg,

while he may have made some positive noises, the core team hasn't been
very interested in the concept even for 1.9. Also, the 1.8 branch is
still under development. We should see 1.8.7 released in a few weeks.

Regardless, no specification exists for the language beyond the actual
implementation. Unfortunately for us, the implementation changes
behavior even between patch releases (1.8.6 patch 111 versus 1.8.6
patch 114). This really needs to be nailed down. I imagine this is
partially the impetus behind the Sapphire Ruby fork.

cr

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Guo wrote:
|
| I have read most of the comments in this forum. Most of them are
| helpful while some key points in the blog were not touched.
| This is an example:
| "In another incident in the same article, the original Rails author
| admits that the original Rails code required about four hundred
| restarts a day, or six to seven restarts per thread per day. Four
| hundred restarts a day means four-hundred chances for a database
| transaction to fail...."
| The question is:  Is the statement true?
| Why should I concern this? Because my next project will be a
| webgame(for thoese who don't know webgame, please visit www.travian.com).
| I'm considering use Ruby on rails to develop this web app. For such
| application, beging stable is extremedly important or the player will
| leave with anger when data was lost, data being inconsistency or
| something like that.

So, instead of examining solutions and deployment of applications
yourself, to see if they fit your need, you instead rely on what amounts
to hearsay to make your decisions?

"It must be true, I read on the internet"?

If you are that concerned, shouldn't you instead go and see for
yourself? (And yes, load-testing is difficult, if you want to simulate a
heavy load, I fully recognize that).

And AFAIK, Passenger, JRuby, and Mongrel pretty much solved the
stability issues. That may not be true for your situation, though.

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~   Life is full of surprises but never when you need one.
        -- Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf+SB0ACgkQbtAgaoJTgL+BRQCgn8GvjdrV7ztMqb0Vr2liUILY
j0EAnRmcbSkv9qX3q8WmRTabIc1ZXAlR
=5H3q
-----END PGP SIGNATURE-----

On Thu, 10 Apr 2008, Chris Guo wrote:

> "In another incident in the same article, the original Rails author
> admits that the original Rails code required about four hundred
> restarts a day, or six to seven restarts per thread per day. Four
> hundred restarts a day means four-hundred chances for a database
> transaction to fail...."
> The question is:  Is the statement true?

True, but there is some important contextual information that is 
missing.

> Why should I concern this? Because my next project will be a
> webgame(for thoese who don't know webgame, please visit www.travian.com).
> I'm considering use Ruby on rails to develop this web app. For such
> application, beging stable is extremedly important or the player will
> leave with anger when data was lost, data being inconsistency or
> something like that.
> If the statement is true, then should I turn from rails to Pylons?

The information about the original Rails, running the original BaseCamp,
requiring 400 restarts per day lacks a great deal of context, and 
context
is important.

First, regarding the actual issue of the restarts, it is very important 
to
note that this was the _original_ Rails (which was changing very
frequently -- go back and check the logs for release announcements from
back then; they were often only a few days apart), which was running on
fastcgi.

Additionally, one thing that I have never seen mentioned is just what
those 400 restarts a day really were.  Since the code was running on
fastcgi, were they just restarts originating in mod_fastcgi's management
of external processes?  If so, there's nothing really incriminating 
there.

Also, bear in mind that fastcgi is not the prefered way of deploying 
Rails
apps these days, and in fact isn't even common.  This information about
restarts just isn't particularly relevant to today's Rails.

I know that Rails gets intermixed with Ruby in many people's minds these
days, but consider, too, that Rails != Ruby.  There are several good,
capable ways of doing web app development using Ruby today that don't
involve Rails at all, and which have different sets of strengths and
shortcomings than Rails.  If you are concerned, maybe you should be
looking at some of the alternatives?


Kirk Haines

On Thu, Apr 10, 2008 at 1:25 AM, Chris Guo <guoxianghao@gmail.com> 
wrote:
>  "In another incident in the same article, the original Rails author
>  admits that the original Rails code required about four hundred
>  restarts a day, or six to seven restarts per thread per day. Four
>  hundred restarts a day means four-hundred chances for a database
>  transaction to fail...."

>  The question is:  Is the statement true?

The answer to that is both "yes" and "no". I didn't address it in any
of my comments because it was part of the section dealing with
"criticisms" provided in Zed's rant. They're completely out of context
and DHH *did* clarify the context in his own blog, IIRC. IMO, anyone
who relies on Zed's ghetto rant for their context is not worth
listening to. (Zed's ghetto rant is marginally worth reading on its
own, but it's not a suitable basis for others to base their arguments
on.)

>  Why should I concern this? Because my next project will be a
>  webgame(for thoese who don't know webgame, please visit www.travian.com).
>  I'm considering use Ruby on rails to develop this web app. For such
>  application, beging stable is extremedly important or the player will
>  leave with anger when data was lost, data being inconsistency or
>  something like that.

That won't happen.

>  If the statement is true, then should I turn from rails to Pylons?

Nope.

-austin