From: Francis Cianfrocca <garbagecat10@...>
Date: 2008-01-05T00:05:28+09:00
Subject: Re: Don't write your own X (was: Zed Shaw - Ruby has dodged a bullet)

------=_Part_25998_30300003.1199459124231
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Jan 4, 2008 8:54 AM, Eivind Eklund <eeklund@gmail.com> wrote:

> On Jan 4, 2008 2:10 AM, Michael Schuerig <michael@schuerig.de> wrote:
> > On Friday 04 January 2008, Jay Levitt wrote:
> > > The very same arguments people use about "write your own
> > > authentication system so you know what it does" can be extrapolated
> > > to "write your own framework" - and, from there, to "write your own
> > > language", "build your own computer", and "don't believe anything you
> > > haven't seen with your own eyes". It's all of a piece.
> >
> > I'd consider it bad advice to tell people to "write your own X so you
> > know what it does." It encourages people to ignore work that has
> > already been done and particularly ignore the thinking that has gone
> > into that work already. What's the point of having your homebrew X that
> > you fully understand, but that is broken-as-designed? Write your own X
> > if you understand the existing alternatives and they can't be made to
> > do what you need.
>
> My opinion: You often cannot do this evaluation until you have written
> your own or have been badly bitten by existing alternatives.  For
> instance, in the web application framework I work in (which is written
> by one of the guys I work with and modified quite a bit by me) we have
> a few external dependencies, and they bring us an inordinate amount of
> grief.
>


There's a great deal of merit in both points of view. But there may be a
basic architectural consideration at work here too.

It's axiomatically a good thing to leverage the good thinking (and
debugging)  done by others. Any number of Unix heavyweights have made the
point about "standing on the shoulders of giants."

But the task of debugging and maintaining a production-quality piece of code
is correlated strongly with its size and even more with its heterogeneity.
Adding in a lot of external libraries, no matter how well designed and
executed, is going to create problems simply by virtue of the number of
points of contact.

But I don't necessarily think the whole answer is to develop local solutions
to standard problems. For really standard pieces of basic functionality,
tightly-focused small external libraries are usually the right answer. (You
probably won't roll your own XML parser, for example.) But sbove that level,
things get very fuzzy, very fast.

The world still hasn't found a really good solution for creating
loosely-coupled applications that can leverage external functionality
without incorporating it in-process. And there are many reasons for this:
impedance mismatches, performance problems, lack of integration standards,
and many others we've discussed many times already.

The enterprise world, which has strong economic motivations to solve this
problem, is finally creeping tentatively toward a commitment to SOAs, after
talking about it for years. The problem in this space is that the discussion
has been driven by vendors, who all want to control the network standards
used for loose-coupling. But none of the standards (XML-RPC, SOAP, REST,
many others) is really ideal. As a result, people have been focusing on all
the wrong things, and there is a lot of home-grown mish-mash out there.

We're still years away from a real solution.

------=_Part_25998_30300003.1199459124231--