[Camps-users] Integration with related projects

David Christensen david at endpoint.com
Wed Dec 17 04:22:09 UTC 2008

>>> I've taken a look at Camps' Perl code, and also I've been working on
>>> Ruby projects for the past few months, and the 'niceness' of Ruby  
>>> code
>>> compared to Perl is becoming more and more obvious to me. I've  
>>> come to a
>>> point where I'm preferring Ruby over Perl any time.
>> Ruby's nice, but I still like Perl a lot. But my main concern here is
>> about Camps themselves, what they do, their interface, and their
>> documentation. The actual implementation is less crucial, just as I  
>> don't
>> much worry about how Git, PostgreSQL, bash, or many other things I
>> regularly use are implemented, as long as they work well and are free
>> software.
>>> Btw, we've been developing an application in Ruby 1.8, and hoping  
>>> that
>>> we'd be able to use Ruby 1.9 by the time the software is shipped
>>> (problem were some library bindings not available in Ruby 1.9).  
>>> Anyway,
>>> long story short, we got it working on Ruby 1.9, and worth noting,  
>>> 1.9
>>> gives 4 to in some cases 20 times better performance over 1.8.
>> That's great news. Startup time for many Ruby tools really is  
>> noticeably
>> and annoyingly slow, so if 1.9 improves that, hooray!
>> Jon
> I'll advocate Perl for much the same reason Ethan mentioned a couple  
> of
> times, aka my passion for it. A better argument however is that nearly
> every Unix based system in existence installs *and* requires Perl to  
> be
> installed, the same can't be said about Python and even less so about
> Ruby. This runs from Linux all the way to something like Mac OS X, and
> although we may not care about non-Unix at the moment, I think the  
> Perl
> world is still more developed and oft available on Windows than either
> of the other two. I'd be okay with Ruby, but what little I've done in
> Python I pretty much despised, unless we are going to throw a GUI on  
> it
> (for some reason). The other big plus is always CPAN.
> On the Moose front, I think with Perl 6 being an eventuality  
> (granted I
> may have retired by then), I think it is safe to use, and will also
> re-mention that we can start out with anything to boot strap, if we  
> find
> the need to switch object systems later because of dependencies then
> that is always possible, and one of the reasons to use an OOP
> architecture to begin with. As far as start up costs, I've recently
> played with this quite a bit and found a tidbit in the Moose cookbook
> suggesting that a way to reduce the costs is to make the classes
> immutable once you've finished with the Moose portions. Also no need  
> to
> prematurely optimize something we've not shown to be a problem.
> Just a couple of thoughts,

Apparently there's also a module called "Mouse" which is an almost- 
identical API to Moose with a few minor differences, with the intent  
of being a lighter-weight object system.  It might be worthwhile to at  
least look at; the developer has wanted to keep API-compatibility to  
the point that you could perl -i -pe s'/Mouse/Moose/g' and have  
everything still work.



David Christensen
End Point Corporation
david at endpoint.com

More information about the Camps-users mailing list