[Catalyst] Is Catalyst large enough to sustain a book?

[John Beppu]

On 4/28/06, Matt S Trout <dbix-class at trout.me.uk> wrote:

> Prototype is a complete joke technically. It's inflexible, a pain to extend
> and does the equivalent of stuffing UNIVERSAL:: which means it doesn't
> co-operate with other libraries sanely in a lot of cases.

If prototype is so bad at cooperating, why are so many people building
libraries on top of prototype?  You've got script.aculo.us (
http://script.aculo.us/ ), OpenRICO ( http://www.openrico.org/ ),
moo.fx ( http://moofx.mad4milk.net/ ) , and prototype javascript
windows (http://blogus.xilinus.com/pages/javawin) for starters.  If
any Ruby people are lurking, I think they'll be able to cite a few
more examples, but the point I'm trying to make is that prototype
doesn't seem to be making life harder for people.  To the contrary,
it's serving as a strong foundation for people to build bigger and
better things upon.



How could that be possible if they're doing the "equivalent of
stuffing UNIVERSAL::" ?



Perhaps the dangers of this technique are being overstated.  Maybe if
you looked at it as "using mixin classes to extend the standard
library" it wouldn't sound so bad.

I've been a fan of mixins ever since I read about them in the
Objective-C manual years ago, and it seems like a lot of Ruby
programmers like mixins, too.  It's a technique that's fully accepted
in the Ruby culture, so it should be no surprise that they've applied
mixins to Javascript.

I like what they've done, too.  Enumerables (
http://encytemedia.com/blog/articles/2005/12/07/prototype-meets-ruby-a-look-at-enumerable-array-and-hash
) are the kind of thing that make Javascript a nicer language to
program in.


> It's the sort of
> awful honey trap that formmail.pl and friends from Matt's Script Archive were
> for perl programming.

That's just disrespectful, because Matt (of Matt's Script Archive)
lacked skill whereas the people who work on prototype are very skilled
programmers.  Just because you disagree with their approach doesn't
mean there isn't immense value in what they've done.

A lot of people found Javascript's standard library to be lacking, so
the prototype people decided to fill some of those holes. 
Furthermore, the only practical way to do it was by using mixins, so
they did what they had to do, and I think we're better off for it.

The main problem with this approach is that other people will try to
fill the same holes with methods with the same name but slightly (or
wildly) different semantics.  Admittedly, this can fuck you up, but in
practice, it doesn't happen that often.




I think what's lacking right now in Javascript is JSAN.  If JSAN were
a stronger entity with more clout in the Javascript programming
community, problems like this could  at least be managed a little
better.

When mixins start stomping over each other, the question becomes: Who
has authority over this particular object prototype.  The de facto
answer right now is Prototype, because they are the ones who have
clout right now.  However, something like JSAN could provide a more
"official" answer to these kinds of questions.  It's too bad JSAN has
not achieved the kind of popularity necessary to allow it to have this
kind of positive impact.

(If JSAN is to ever become popular, we're going to have to reach out
to the Ruby people at the very least.)