Re: plugin dependencies

Jay Levitt
Wed, 19 Sep 2007 17:22:37 -0000

On Wed, 19 Sep 2007 16:46:50 +0100, Pratik wrote:

> I release Plugin A. Joe release Plugin B which uses "your"
> functionality to depend on my Plugin A. One fine morning I get
> enormous motiviation  to improve performance of my Plugin. So I take a
> day off at work and rewrite the entire damn thing and release it. Poor
> Joe has no clue what I did. So every person installing his Plugin B,
> will have broken functionality because noone has a goddman idea about
> what I did with Plugin A last night.

I see what you''re saying, and I don''t disagree.
There''s always going to be
a tension between reuse and incompatibility; it''s been true with UNIX
shared libraries, it''s true for Windows "DLL hell", I imagine
it''s true for
managed .NET and Java applications, and it will be true in Ruby and Rails.
It''s why we freeze gems and Rails into our apps, and it''s why
3rdRail comes
with not only its own copy of Eclipse but its own copy of Java.

And that''s the problem with the nothing-shared rule - just how much of
your
dependencies do you include?  What stable, sane environment can you count
on?  Should plugins include Ruby?  After all, 1.8.5 to 1.8.6 broke quite a
few things.

But packaging everything can destabilize you too, because you won''t
pick up
bug fixes to the core libraries.  On Windows, nearly everything includes
its own "gdiplus" DLL.  Well, when Microsoft found a security hole in
gdiplus, the world went crazy trying to release new versions of everything
with an updated gdiplus.  I''m pretty sure there''s something
somewhere on my
hard drive that''s vulnerable.

These aren''t new problems, and we''ll do well to learn from
past mistakes
and experiments as we carve out solutions.

> If I were you, I''d refrain from personal attacks.

I didn''t intend my post to be a personal attack, and I''m sorry
that it made
you feel attacked.  I didn''t make any statements about your person;
it''s
your position that I questioned.

Perhaps it was a bit hyperbolic to suggest we all invent our linked-list
libraries, but in fact 15 years ago that''s exactly where we were.  It
took
ages (and IIRC several core language improvements!) for the C++ STL to
become adopted and truly standardized, because reuse, versioning and
efficency (developer AND system) are huge hairy issues.  I''m sure the
same
happened before that with stdlib, and after that with Java, and it''s
happening here now.

Java was born in an age where complex programs solved complex problems, and
the idea of perfect portability and modular object reuse was going to save
us all.  It didn''t.

Rails comes at the problem a different way, and perhaps as a result, Rails
developers have a strong cultural bias against reuse.  Maybe it''s
because
it''s often as easy to write something from scratch as it is to reuse
it.
Maybe it''s because we''re learning and reinventing so quickly
that any
rewrite is going to be a huge improvement.  Maybe it''s a rebellion
against
the idea of "one true way" to do something.  Maybe it''s
because we haven''t
started building complex Rails apps yet; maybe it''s because we
*shouldn''t*
build any.  Or maybe it''s because we just haven''t hit the pain
point, but
we''re about to.

What I find really fascinating is that Perl, which comes from a very
similar TIMTOWTDI perspective, has begat CPAN, which (from what I can tell)
very often has One Good Library for a given function.  I would love to
understand more about how that evolved, and see what we can borrow.

Sorry for the novel.  Executive summary: These aren''t new problems.
Let''s
learn from at old solutions.

--
Jay Levitt                |
Boston, MA                | My character doesn''t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm         | - Kristoffer