Apparently enough of it wasn't built in that someone went ahead and created a Moose for Ruby[1]. I haven't done a lot of Ruby but I imagine it's nice as a day to day language. I enjoy Objective C's message passing syntax and dynamic runtime so Ruby is likely a good fit for me.
Personally the reason to use Perl over Ruby is the community. I gel a lot better with the members of the Perl community I've met compared to when I was poking my head around Ruby. I don't mean this in a bad/flamy way. No one was "mean" to me or anything. My brain is just damaged in the Perl kind of way rather than the Ruby kind of way.
Anyways, the actual question shouldn't be why Ruby over Perl, rather it should be "why don't we have Moose (or something like it) in every language." There's nothing about it that ties it to Perl. A dynamic runtime isn't a bad thing to have but I can't really see why most of the really nice parts couldn't be implemented in other languages at compile time.
Simply put, Moose is awesome. You can build so much functionality with not a lot of code and it actually glues together well. Type coercions are awesome and super useful in day to day programming. I've been doing a lot of API work where I need flexibility in terms of output (JSON, XML, RSS, etc) where a plain object dump to the specified format isn't enough. In the case of the XML there is an XSD it needs to match against and the structure isn't particularly amicable to sane JSON output.
Care of Roles, Type coercions, Attribute meta roles, and some preemptive thinking I basically just create objects with attributes and a few methods containing business logic and not a lick of serializer logic.
package My::Foo;
use MyCo::Moose; #Exports a few things I usually need like aliasing,
use My::Type::Exports qw(:all);
with 'My::Role::AwesomeSerializer';
has 'some_attribute' => (
is => 'ro',
isa => MaybeSuperComplexObjectType,
coerce => 1,
traits => ['UseMyJsonSerializer'],
json_name => 'someAttribute',
xml_name => 'My::SomeAttribute',
alias => 'some_call_it_this',
);
# yatta
__PACKAGE__->meta->make_immutable();
1;
In my types package I have various coerce methods that accept different data formats. The logic in the class doesn't have to change, nor do I need to write a new constructor/factory like I would in other languages, when the data I'm being given changes in some non-trivial way.
Really? Because although I came from Ruby (and before that, C, ASM), I spent 4 years in Perl with half of that doing Moose stuff. Now I'm doing Python, C, and hardware stuff.
I really miss Moose. Pythonistas generally can't believe I could possibly miss anything from the Perl world, and usually aren't interested in hearing my reasons why.
But honestly - I miss doing 75% of my work in bashing out an declarative specification with Moose, especially with the type system (as slow as that can be at runtime; the work-around is making objects immutable which leads to cleaner code anyway).
Python does have the traits package by enthought, which has some vaguely similar stuff in it but nobody seems to use it. Being out of the ruby loop for a while, what's ruby's answer to Moose?
An alternate perspective: I've used Perl for 10+ years, but switched to Python 5 years ago. Moose was a hack to bring Java patterns to Perl, but I feel Java patterns are not developer friendly these days.
Python patterns are still solid today, so I gladly choose doing things the Pythonic way over the Perl way. Not to mention the meta reasons to use a language (community, libraries, ecosystem).
Moose is the opposite of Java: it has a type system which actually does work for you and brings you amazing helpful stuff for free, whereas Java makes you go through rituals and pain to use a type-system that mostly only ever gets in your way.
I'm fine with the idea that you like perl but the way you present your statement, it's almost as if you consider not understanding how to use the java type system as a compelling argument.
That's an interesting observation (that being fine with the idea of someone using modern perl is a thing), but perhaps there's a grain of truth to my level of Java ignorance - the last Java project of my own was written in the 1.4/1.5 days and left me feeling that getting reusable code out of huge towers of inheritance and interfaces seemed like more work than it should be.
You might want to remember that moose came out in late 2005. Back then I remember plenty of blog posts titled similar to "You did what with Rudy!?" (typically an attack on ruby's general slowness and the strange things people were doing with the rails framework... errm twitter <cough>)
Perl is much faster than Ruby, and has a far, far better debugger. Also, CPAN libraries tend to be quite stable; you usually don't need hacks like Bundler to isolate incompatible libraries.
Check out this exchange here on HN a couple months ago following the comment "I have two programming tattoos: a Perl camel and a Ruby ruby": https://news.ycombinator.com/item?id=7866845
Ruby code wouldn't be as verbose as this, but still once you're used to building classes with Moose accessors, types, traits etc. in a mostly declarative manner, going back to hand-rolling checks and exceptions on bad attribute values, not to mention accessor methods and so on definitely feels like a step backwards.
In fact now that I'm doing a lot of Python these days I've come to the horrible realization that it's Moose which has made me yearn for a language with stronger emphasis on typing and correctness than Python can provide!
Edit: and I don't mean "like java", where it only ever seems to get in your way...
Moose does useful things and gives you stuff "for free" once you've told it what
type something should be. And allows you trivially inherit/override type
declarations, rather than jumping through hoops as in Java.
It's a full about-face compared to the liberation I felt going from C/C++/Java to Ruby back around 2006-2007.
Slowly working through Learn you a Haskell, but doubt I'll get a chance to use Haskell professionally.
Do you mean the optional type enforcement? Admittedly it's not built-in to ruby, but it's easy to replicate.. and a lot less verbose:
# Implementation:
module TypedAttrs
def attr_accessor_type name, type
define_method name do
instance_variable_get "@#{name}"
end
define_method "#{name}=" do |value|
raise ArgumentError unless value.is_a? type
instance_variable_set "@#{name}", value
end
end
end
# Example:
class Foo
extend TypedAttrs
attr_accessor_type :bar, Integer
end
a = Foo.new
a.bar = 5
p a.bar
a.bar = "hi" # ArgumentError
Sure. And just for attributes, there's also delegation, read-only attributes, builders, lazy init, roles, modifiers which are enforced at construction time (if `required` is true).
Moose isn't hard to implement, it's actually had quite a few alternate implementations even in Perl. Python has enthought's traits package, and I've just been pointed to https://github.com/frasertweedale/elk as well.
BTW it sucks to nit-pick, but the Moose version isn't any more verbose than yours:
package Foo;
use Moose;
has 'bar' => ( isa => 'Integer' );
has foo => (is => 'rw', required => 1);
has bar => (is => 'ro', lazy => 1, builder => '_build_bar');
sets up both accessors and the relevant constructor logic - and bar's accessor will call the _build_bar method on self to get the value if it wasn't provided to the constructor.
Method modifiers (before/after/around) are way more elegant than rename-the-method, and compose nicely from roles - and roles are substantially more powerful than mixins.
I've never used Moose, but in my limited experience, most of the cases where multiple inheritance is useful seem to be ones that basically amount to Ruby's modules/mixins system¹. Are there any examples of useful patterns that aren't covered by that?
¹in fact, under the hood, Ruby modules are classes, and mixins are multiple inheritance— it's an artificial, deliberate limitation.
That's true, when I saw Moose roles I immediately thought of Ruby's mixins. They're a little more expressive though; Moose gives you ways to interrogate roles and classes that use them in more meaningful ways (IMHO), and it's not uncommon for roles to use method modifiers (thus making roles co-exist more easily) rather than clobbering methods outright.
This is all achievable in Ruby of course, the Moose docs sort of codify it and provide sugar to make these patterns the path of least resistance.
Most cases of multiple inheritence I've seen is in non-Moose Perl code, where it's being used a little like a mixin. DBI classes and code making lots of use of meta-programming (Class::MOP stuff).
Personally the reason to use Perl over Ruby is the community. I gel a lot better with the members of the Perl community I've met compared to when I was poking my head around Ruby. I don't mean this in a bad/flamy way. No one was "mean" to me or anything. My brain is just damaged in the Perl kind of way rather than the Ruby kind of way.
Anyways, the actual question shouldn't be why Ruby over Perl, rather it should be "why don't we have Moose (or something like it) in every language." There's nothing about it that ties it to Perl. A dynamic runtime isn't a bad thing to have but I can't really see why most of the really nice parts couldn't be implemented in other languages at compile time.
Simply put, Moose is awesome. You can build so much functionality with not a lot of code and it actually glues together well. Type coercions are awesome and super useful in day to day programming. I've been doing a lot of API work where I need flexibility in terms of output (JSON, XML, RSS, etc) where a plain object dump to the specified format isn't enough. In the case of the XML there is an XSD it needs to match against and the structure isn't particularly amicable to sane JSON output.
Care of Roles, Type coercions, Attribute meta roles, and some preemptive thinking I basically just create objects with attributes and a few methods containing business logic and not a lick of serializer logic.
In my types package I have various coerce methods that accept different data formats. The logic in the class doesn't have to change, nor do I need to write a new constructor/factory like I would in other languages, when the data I'm being given changes in some non-trivial way.[1] http://pacman.blog.br/blog/2014/02/07/moosex-a-new-ruby-dsl-...