From: David Pollak <pollak@...>
Date: 2006-05-04T03:08:03+09:00
Subject: Re: Sharp knives and glue

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

Ryan,

If you turn on the verifier for class loading, any incompatible libraries
get flushed out very, very early in the application run cycle.

This compares very favorably to some 3rd party module magically changing th=
e
behavior of String, Object, Module, or Class in such a way that makes my
application behave unpredictably.  Because Ruby Modules can and do change
system classes or my classes (and may change the order in which they do so
depending on load-order), there is a lot more problems than a method call
signature changing or method functionality changing.  Compound this with th=
e
the lack of namespaces and no errors being generated if my class Foo
comflicts with another class Foo (hey... we've got 1 class with a lot of
methods... let's hope the method names don't collide) you've got an
unpredictable mess.

Thanks,

David

On 5/3/06, Ryan Leavengood <leavengood@gmail.com> wrote:
>
> On 5/3/06, David Pollak <pollak@gmail.com> wrote:
> >
> > Well... what are the consequences?  For example, Instiki 0.11 works jus=
t
> > fine under WEBrick, but breaks running under FastCGI because of a load
> > sequence issue with the 0.8.x rails libraries that are shipped with
> Instiki
> > and whatever version of stuff is in my Gems directory.
> >
> > The consequences of this is I can't use a Rails app in my normal
> production
> > environment.  Sure, I could figure out what's going on... but that's a
> waste
> > of my time (I've already lost 3 hours of consulting revenue trying to
> > install Instiki as a FastCGI rather than a port-forwarded WEBrick app.)
> >
> > The consequences of this is I'm screwed.
> >
> > The consquences of this is I can't recommend Ruby to my enterprise
> clients
> > because they can't predictably deploy applications unless they have a
> > freeze-dried perfectly versioned system that will never change because
> of
> > the unpredictability and instability of changing library versions.
> >
> > Oh... BTW -- Instiki passes its unit tests because the load sequence is
> > correct for the unit tests... but it's not correct when Instiki is
> launched
> > as a CGI or FastCGI.  So... the consquences of this is that you can't
> trust
> > unit tests in Ruby because they can be impacted by Module/Class load
> > sequences.
>
> But of course in the Java world there are never any incompatibilities
> in different versions of libraries. I can take a Java 1.1 compiled
> application and run it fine in the latest Java 1.5.whatever. Sun and
> IBM and Microsoft Java VMs all run in exactly the same way. No one
> could ever have a older JAR file on their CLASSPATH which causes a
> normally fine application not to run because of library differences.
> Since it isn't always obvious over the email medium, I'm being
> sarcastic.
>
> Then of course in the C++ world there are plenty of problems with DLL
> incompatibilies as well.
>
> So, in other words I think your above example, while certainly an
> annoying situation, is not a valid argument against Ruby being used
> for big applications. Any application that relies on external
> libraries can have problems like this.
>
> Ryan
>
>


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

------=_Part_50006_32956308.1146679679545--