Object::Tiny vs Moose(::Tiny)

Alias on 2007-11-04T11:48:00

When I wrote Object::Tiny, I didn't bother to write a comparison to Moose because I saw them as being in a completely different ballpark.

One is a fully featured MOP implementation with all the goodies of the Perl 6 object model... and the other makes trivial accessors to save typing.

I saw it as more of a compliment, because obviously we're comparing apples and oranges here.

So then Moose::Tiny shows and I of course assume it's a joke by some random person unrelated to Moose itself.

A little annoyed that they are taking some liberties with the ::Tiny suffix, I write a review suggesting Acme::Moose::Tiny would be a vetter name.

Much to my surprise, Moose supremo Steven Little turns up in defense of Moose::Tiny suggesting it is a "Hilarious social commentary on the absurd concept of second level namespace ownership".

On the one hand, I don't see a problem with "ownership" (in a sense) of a suffix... there's no difference in the level of protection available. I could easily walk all over DBI:: and there's nothing in PAUSE to stop me.

BUT, if the Moose people do indeed feel that they want to be included in a comparison, well fair enough.

So, how does Moose::Tiny compare to Object::Tiny?

Well, in favour of Moose::Tiny is that it saves one additional character of typing, with an otherwise identical interface.

Installation: Moose::Tiny has a number of recursive dependencies (and a few more build_requires deps not shown) with non-perfect cpan testers results (72% aggregate success installing).

Memory: Moose::Tiny uses 4.5 megabytes of memory. This is around 550 times larger than Object::Tiny, or a more impressive sounding 55,000% larger :)

Startup: Moose::Tiny takes around a second to load up on the virtual I'm currently working in. Granted that's also in the debugger, so it's WAY slower than it could be, but Object::Tiny does not take any noticable time to load, even in the same scenario.

That's just what I had time to test when I first saw Moose::Tiny uploaded.

I'm not on a computer with a working Perl atm to complete the comparison (Intarweb cafe to check mail), so I'll leave it to someone else to do the rest (accessor speed, et al) but suffice it to say Object::Tiny and Moose really ARE completely different beasts.


moose

dagolden on 2007-11-04T12:06:30

A moose once bit my sister...

Re: ::Tiny

Stevan on 2007-11-04T17:15:34

When I wrote Object::Tiny, I didn't bother to write a comparison to Moose because I saw them as being in a completely different ballpark.
Obviously.

So then Moose::Tiny shows and I of course assume it's a joke by some random person unrelated to Moose itself.
Well, your 1/2 right. It is a joke, but the author is heavily involved in the Moose community.

A little annoyed that they are taking some liberties with the ::Tiny suffix, ... [snipped other stuff about reviews and such]
You see, this is the joke we are trying to make (and with which my review is taking said joke one step further). While I understand the idea of your ::Tiny modules, I think it is a little excessive that you feel the need to "officiate" and judge all other ::Tiny modules which are uploaded to the CPAN. It is just rude to step on first level namespaces, and most CPAN authors respect this. But a second level namespace (under my first level namespace) is my own, and should not need to stand up to your criteria.

BUT, if the Moose people do indeed feel that they want to be included in a comparison, well fair enough.

So, how does Moose::Tiny compare to Object::Tiny?

... [ snipped unflattering comparions ] ...

First of all, have you ever seen a Moose? They are not tiny creatures at all. A full grown moose can grow to be over 3 metres (8 to 10 ft.) in length and a shoulder height of over 2 metres (5 to 7 ft.). The males can weigh 600 kg. (over 1200 pounds) and have antlers anywhere from 120 to 150 cm. across (4 to 5 ft.). So while 4.5 megs of memory may seem large to you, when you compare that against a half-ton animal which smells more horrible than you can possibly imagine, it's not all that much :)

So you see, (at least in IMO) the whole joke of Moose::Tiny is that ...

size is relative.

Love and Kisses from the Frozen North,

- Stevan :)

Re: ::Tiny

jmcnamara on 2007-11-04T18:38:43

If it takes that long to explain it the joke probably isn't that funny.

John.
--

Re: ::Tiny

perigrin on 2007-11-04T19:38:28

All of the people I wanted to get it ... got it.

Re: ::Tiny

Alias on 2007-11-05T02:53:39

See, I originally thought it was a joke because it was an oxymoron...

And I got confused with that versus the joke of trying to apply standards for suffixes.

Thank You

perigrin on 2007-11-04T20:07:11

When I wrote Object::Tiny, I didn’t bother to write a comparison to Moose because I saw them as being in a completely different ballpark.

One is a fully featured MOP implementation with all the goodies of the Perl 6 object model… and the other makes trivial accessors to save typing.

I saw it as more of a compliment, because obviously we’re comparing apples and oranges here.

So then Moose::Tiny shows and I of course assume it’s a joke by some random person unrelated to Moose itself.

Well I’m not unrelated, I’ve worked on lots of pieces in the Moose world. But your assumption was right, it was a joke. Acme::* would have ruined that joke…

A little annoyed that they are taking some liberties with the ::Tiny suffix, I write a review suggesting Acme::Moose::Tiny would be a better name.

Well no more annoying that finding lots of ::Tiny stuff lying about in people’s packages that is purporting to be a smaller/faster/better solution to whatever problem they’re solving. Part of the joke is that Moose as a full MOP would loose a ton by trying to reduce it to the 80/20 rule that ::Tiny tries for. (That said mad props to sukiria for doing exactly that with Coat.).

Much to my surprise, Moose supremo Steven Little turns up in defense of Moose::Tiny suggesting it is a “Hilarious social commentary on the absurd concept of second level namespace ownership”.

On the one hand, I don’t see a problem with “ownership” (in a sense) of a suffix… there’s no difference in the level of protection available. I could easily walk all over DBI:: and there’s nothing in PAUSE to stop me.

You’re a smart guy, I’m sure you could get away with murder too … but that doesn’t make it right.

BUT, if the Moose people do indeed feel that they want to be included in a comparison, well fair enough.

So, how does Moose::Tiny compare to Object::Tiny?

[snip]

Thank you, I will release a 0.02 release with the updated POD, and be sure to give you the proper credit. More patches welcome via RT or the standard Moose patching process.

Re:Thank You

perigrin on 2007-11-04T20:10:30

lying about in people’s packages
Sorry I meant "Namespaces" not packages.

Re:Thank You

Alias on 2007-11-05T02:16:34

Lying about in people's namespaces?

Name one.

So far I'm not aware of any modules that are doing that...

Nobody "owns" Config:: or XML:: or even YAML::

Occasionally people specifically ask that a namespace be kept clear for the exclusive benefit of that project, like DBI or PPI or (I assume) Moose.

And neither I or any other ::Tiny authors have violated that (although I dearly want to release DateTime::Tiny).

If Moose:: has indeed asked to remain clear, you are the only person that has violated a namespace in the way you suggest.

Re:Thank You

perigrin on 2007-11-05T03:40:49

Well ... except first I didn't release until I had cleared it with Stevan first. Actually I asked him if I should release at all, and then again if he felt that it belonged in the Moose namespace. If he'd said no, or was unsure at any point I wouldn't have released ... MooseX::Tiny is no better than Acme::Moose::Tiny for parody purposes.

Second I think a case can be (and has been) made that there is disagreement on the merits of the Tiny naming scheme. Though in those cases I suppose it isn't the To be honest until I looked again just now I thought you *had* stomped on other people's project names because the names are so similar (for example Date::Tiny ... *especially* when Date::Tiny objects can inflate to DateTime objects ... tell me that isn't confusing?). But you are right they are not, I retract that spurious comment modulo my misgivings stated here.

Finally I have to thank you because all of this has helped immensely with my understanding of the position of Moose relative to other things in the world. I now have benchmarks of Moose against a self-professed *fast* object builder (thank you again ... the benchmarks will be in the 0.0.3 aka "Bonfire Night" release), we lose horribly in object creation (about a 200% hit ... because of the MOP I'm sure) but don't fare too badly in accessor access (only about a 20% hit and we support method modifiers and several other decidedly non-tiny features). I also have a wonderful example of extending Moose that is small and focused. Last as someone pointed out, we got publicity. I honestly think that Moose::Tiny has added more than it ever could have to the Moose project as "just a joke module".

TagSoup::Tiny

chromatic on 2007-11-04T21:32:50

A little annoyed that they are taking some liberties with the ::Tiny suffix...

I seem to recall that it wasn't the ::Tiny suffix that really annoyed people earlier this year (but they seem to mind less now that the documentation of said module explains what exactly it doesn't).

Re:TagSoup::Tiny

Alias on 2007-11-05T04:05:51

Indeed, pretty much every ::Tiny module has initially annoyed people that care a lot about doing some particular job the correct way.

XML people generally don't like XML::Tiny, Ingy doesn't like YAML::Tiny and so on.

Actually, I'm not a huge fan of XML::Tiny either and wouldn't use it myself, but I still think it is necessary and understand why it should exist.

I can see why Moose people might not like Object::Tiny :)

Ohhh...I get it

sigzero on 2007-11-05T02:11:16

It is a ::Tiny pissing match going on. : )