Ruby’s not ready - an indepth essay

Diego V. 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.
:slight_smile:

— Austin Z. [email protected] 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

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.

On Apr 8, 2008, at 4:22 PM, Phillip G. 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 G.
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 Apr 9, 2008, at 7:04 AM, Austin Z. 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 Z. 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 Wed, Apr 9, 2008 at 12:27 AM, Isaac G. [email protected] wrote:

— Austin Z. [email protected] 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

Chuck R. 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. :slight_smile:

On Tue, Apr 8, 2008 at 5:20 PM, Tim H. [email protected] wrote:

Kyle S. 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. :slight_smile:

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

On Wed, Apr 9, 2008 at 9:47 AM, Paul B. [email protected]
wrote:

On Wed, Apr 09, 2008 at 09:04:28PM +0900, Austin Z. 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 Z. [email protected] 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 [email protected] 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.

Ruby's not ready | glyphobet • глыфобет • γλυφοβετ

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 G. wrote:

everybody else not speaking English.
I think you’ll find disagreement that Japan wants it, or needs it.
Han unification (Han unification - Wikipedia) 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… :wink:
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 :wink:

2008/4/8, Phillip G. [email protected]:

|> The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) – Joel on Software
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 H. 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 S. 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

:wink:

On Wed, Apr 09, 2008 at 10:33:53PM +0900, Chuck R. 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

On Apr 10, 2008, at 6:31 AM, Gregory S. 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