[Camps-users] Integration with related projects

[Ethan Rowe]

[snip]
>> Brian Miller sez:
>> 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.

I'll let Jon (or someone else) address this in greater detail, but note
that Red Hat uses Python for much of its toolset.  I believe the same is
true of Debian, though I'm less confident.  Multi-platform support for
Python and Ruby is quite good, to my knowledge (particularly Python).

Perl is all over the place.  Python is definitely well-supported,
well-known, and widely used.  Ruby is perhaps less ubiquitous, but its
usage in Puppet and Capistrano alone makes it an interesting
possibility, since Jon is rightly identifying those projects as
fulfilling a separate but related need in the general software
infrastructure space.  Furthermore, if you have a project that is in
Perl and for some reason you're contemplating a language switch, Ruby is
a natural choice/fit, given its evolutionary relationship with Perl.
Python is a more jarring change for Perl folks, generally speaking.

CPAN is great (except for when it isn't).  Python has a huge set of free
libraries too, as does Ruby.  Ruby's is considerably developed than
Perl's or Python's, as far as the total set of available, supported
packages is concerned.  But it's growing.  Consequently, I don't think
that CPAN alone gives Perl an advantage over Python, and perhaps only a
minor one over Ruby.

But it's rather beside the point, IMO.  One of the main reasons I would
give serious thought to doing the next generation camp system in Ruby or
Python is specifically because I don't want to deal with extra modules
for fundamental things like the object system.  To go for the leanest
possible dependency set while still having the all the development tools
we need readily at hand.  I'd rather not have to rely on CPAN at all (or
the Ruby/Python equivalents thereof), though there's naturally a limit
to that (we need DBI, for instance).

>> 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.

A few things.  Let me say first that some months back I started some
refactoring in my local repo, using Moose, and the time associated with
using any of the new, simple Moose-based modules is unpleasantly
noticeable.  For reasons that are readily understandable with a cursory
consideration of the situation.  It is not, in my opinion, at all
premature to look at this as problematic.

My initial comment on this subject from earlier in this thread:

> For a family of command-line tools like the basic
> camp interface, however, the idea of having a dependency like Moose
> begins to smell; it means your command-line tools will probably never be
> very snappy, because the compilation cost is paid every time and the
> Moose module family is not insignificant.

The problem with Moose performance for camps is not the runtime
performance, it's the compilation phase (and the BEGIN phase).

The immutable class feature denormalizes attributes and whatnot within a
class and results in faster performance; most noticeably, it results in
markedly faster instantiation.  This is very helpful for things like
webapps, where you're compiling stuff once at appserver startup; you
increase the cost of the compilation phase (by adding extra
calculations/operations in making the classes immutable) and reap the
reward of faster runtime operations.

Unfortunately, it wouldn't help us here with command line utilities; it
would actually exacerbate the problem.  Again, compilation (and class
definition) is the problem. Making your Moose-built classes immutable
has a clear positive impact on runtime performance, assuming you're
instantiating sufficient quantities of objects for the performance gain
to have any overall significance.  It is only helpful if the compilation
and subsequent immutability happen once and are reused thereafter, which
is of course not the case for the command line tools.

Also, since Perl 6 was mentioned, I feel the need to say that if Perl 6
in any way factors into the do-we-switch-languages discussion, then the
doors really must be wide open; therefore, I move that we do everything
in Erlang.

> David Christensen sez:
> 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.
> 
> http://search.cpan.org/~sartak/Mouse-0.13/

Yeah, this has been discussed a bit before in other contexts (i.e.
outside this list).  It's an interesting possibility, though I think the
"few minor differences" aren't actually that minor.  Specifically: no
equivalent to Moose roles; that's not a deal-breaker but it's a
significant departure.  Moose roles are very useful, since they let you
favor composition over inheritance (which can result in more
maintainable, less brittle code).  The Mouse::Role looks like it just
offers the basics of class definition rather than being in any way like
a Moose role, but I may be wrong.

Anyway, I don't want to appear down on Perl, but doesn't this seem a
little absurd?  We're batting around object system possibilities in
Perl.  Yet there are these other major, popular, well-developed,
interesting, useful, solid languages at our disposal that can do the
same stuff Perl does with similar levels of developer productivity (i.e.
they're similarly expressive; this is definitely true for Ruby, while
Python is perhaps a bit less so but not necessarily badly less so), and
yet have fully-developed native object systems.  Moose is a great thing
for Perl and I like it a lot, but it can't do the full range of things
that Ruby and Python object systems can do, because classes are not
first-class objects in Perl the way they are in Ruby and the modern
Python object system.

The object system is only part of the discussion, but it's the one I
feel most strongly about and most qualified to opine upon, so that's why
I'm focusing on it so much.  Perl, Python, and Ruby are all wonderful,
free, expressive, flexible, multi-paradigm languages that can solve our
problems effectively.  The "next generation" camp system discussed many
moons ago assumes OOP.  It's a set of command-line utilities that need
to be snappy (slow startup costs are not acceptable, IMO).
Consequently, I think the choices are:
* Perl: use our own simple object system, because Moose (and quite
possibly Mouse) are likely too much when considering startup costs.
* Ruby: great native object system!  Installing the camp system package
(when one is ready) may require installing the distro's Ruby packages too.
* Python: similarly nice native object system.  Similar modest
distribution downsides to Ruby, except that many Linux systems (our
primary consideration at present, I think) will very likely have Python
installed already.

And since we have a big tent:
* Perl 6: we're right on schedule to get the next generation camp system
implemented with Perl 6.
* Erlang: A totally different paradigm.  You can run 10000 camp systems
on a single server!  Yay!

We can also say: the OOP decision really doesn't matter that much, so
factor that out of any discussion; we're still left with potential
factors to consider a different language (namely, the ones with which
Jon started the whole thread).

Thanks.
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com