From: Tanner Burson <tanner.burson@...>
Date: 2006-05-04T23:17:48+09:00
Subject: Re: Sharp knives and glue

------=_Part_3255_11375811.1146752262474
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 5/4/06, David Pollak <pollak@gmail.com> wrote:
>
>
> My premise is that Ruby is not ready for enterprise use because the
> inability to predict the behavior of programs.  If one cannot predict the
> behavior of programs, one cannot test the programs.  If one cannot test
> the
> programs, one cannot deploy the programs into environments that have
> significant regulation (e.g., financial services, health care, insurance,
> etc.)
>
> I gave as an instance of this issue, Instiki.  So... let's drill down.
>
>    - Instiki was written by someone who was not an 'idiot chef' but a
>    skilled Ruby programmer.
>    - Instiki was written using Rails... the "way" to write web apps in
>    Ruby.
>    - Instiki is not a complex app (the application itself is < 2,000
>    LOC).
>    - Yet Instiki has somehow fallen into this issue of unpredictability
>    because of the order of class loading.
>    - If a non-complex Ruby app written by a skilled Ruby developer using
>    standard Ruby tools breaks, how can a large company trust that a very
>    complex Ruby program that has passed QA won't fall into the same issue
> if
>    the first user opens the "latest transaction" rather than the "account=
"
> page
>    first thus causing a different order for class loads.
>
> We can take two approaches to this issue:
>
>    1. Not worry about and 3 years from now sit around saying, "Ruby
>    coulda woulda shoulda"
>    2. Discuss the issues in a way that leads to solutions being found so
>    we can all improve something that we're all passionate about.


The majority of your argument seems to center around the fact that poorly
written software, or code that relies heavily on re-opening classes (which
you seem to lump in with meta programming), can break in certain
circumstances.  And I don't think anyone would argue that at all.  But to
say that Ruby is not ready for "the enterprise" (I'm sure ara t howard and =
a
few others would argue this one), because you can't trust that code added
later won't break existing code is ridiculous.  So, because in C/C++ I can
gain direct access to memory, and modify objects IN memory, it isn't
enterprise ready either, as depending on what order the code is run, things
will act very differently.

And a very, very good programmer such as yourself, must welcome the ability
to re-open the classes of existing code, to provide patched functionality,
on a per-library, or per-application basis, without needing to add your cod=
e
to a list of "approved" classes to be able to modify it.  Oh wait, that's
dangerous and can't be tested and shouldn't be allowed in "the enterpirse",
nevermind.


Ruby may not be ready to fill the "enterprise" nitch that Java currently
sits in.  The right tool, for the right job.  Ruby is great at what it does=
,
and I'd hate to see it become the bloated beast that Java is.

Of course you neglect the fact that no open-source language ever gains
significant market in "the enterprise" as PHB's want a specific someone to
hold accountable for everything, you won't get that with Ruby.

--------
> David Pollak's Ruby Playground
> http://dppruby.com
>
>


--
=3D=3D=3DTanner Burson=3D=3D=3D
tanner.burson@gmail.com
http://tannerburson.com   <---Might even work one day...

------=_Part_3255_11375811.1146752262474--