|
Re: Moose - my new religion
by moritz (Cardinal) on Nov 24, 2011 at 12:59 UTC
|
| [reply] |
|
|
The problem is that right now the choice is between:
- A good programming language (p5) plus all of CPAN; or
- An awesome programming language (p6).
In almost all cases CPAN wins that fight.
An interpreter for Perl 5.x code (even if it only works on a very large subset of CPAN), that runs in Parrot, and allows Perl 6 code to call Perl 5 libraries, instantiate objects defined in Perl 5 classes, etc, could massively swing those scales, but right now that doesn't exist.
| [reply] |
|
|
| [reply] |
Re: Moose - my new religion
by sundialsvc4 (Abbot) on Nov 24, 2011 at 14:00 UTC
|
++
I, too, use Moose a lot these days. Someday, Perl-6 might be mainstream on the systems that I deploy software to, and when that day comes I am sure that I will do so along with everybody else. (I’m watching it, and I welcome it.) But meanwhile, Moose does indeed provide a different way of looking at Perl programming. Although it is a mind-shift, and although it does consume a fair amount of overhead, I find that it is significantly more efficient for me. And since development time is the biggest expense in any project (and un-caught errors the biggest money-robbing question mark), the cost savings profitability enhancements, to me, are compelling. I can buy computing resources to pay the modest-to-me horsepower price that is to be paid, and I am not working in “microsecond-aware” problem spaces.
Certainly one other major “plus” is that Moose is entirely compatible with the legacy code that inevitably surrounds it. I could never afford to replace the entire project; to re-code all those barely working old screens. I am not (yet) comfortable with the idea of replacing the entire language system in the boiler-room. But I can introduce a thoroughly (Test::Most) tested Moose object, and shift new development to it (the source-code sizes inevitably get much smaller), and gradually retrofit the older stuff as time and resources may allow. I really couldn’t do that with an entirely-new language system even if that system were “arguably better.” So, Moose is very strategically important to me, and yet, not at the exclusion of whatever Perl-6 et al may bring. No, “there is peace in the [Perl...] valley, for me.”
Now, where do I see those “goodness results” coming from? Well, it might be said that the results obtained exceed the size of the actual new and original source-code that a developer has to write. The cost of the project is largely a labor cost, and we have found that by developing Moose objects and “testing the hell out of them,” running regression tests on the whole thing several times a day, that up-front cost pays benefits and continues to pay. Because so much of the realizable benefits are concentrated into the object hierarchy that is the constant subject of the tests, the foundation produced is not only strong, but robust. “So, is it Moose, really, or is it just the Best Practices?” It is both, really. Moose both encourages those practices and simplifies them, all within the existing Perl-five framework. So it is, as I said, a tool of tremendous strategic importance. Not to mention ... It Is A Very Good Hack™ ... which as we all know is a programmer’s very highest compliment to a colleague.
| [reply] |
Re: Moose - my new religion
by sundialsvc4 (Abbot) on Nov 28, 2011 at 03:48 UTC
|
I don’t want to hijack a Moose-oriented thread to discuss what might (or might well not) be “the future of Perl as we know it.” Because perhaps the biggest mistake of the Perl-6 project was ... to call it “Perl.” It is a new language. And what is going to determine its eventual commercial success (or lack thereof) is ... not its language ... but rather, its compatibility with existing CPAN modules.
We don’t use Perl because of its language-goodness. (Of which it has, uhhhh, “not much.”) We use it because of the vast and well-tested CPAN library. (IMHO...)
A distinctive feature of Moose is that it enhances the language within the context of Perl-5, and therefore maintains full compatibility with all of CPAN.
| [reply] |
|
|
We don't use Perl because of its language-goodness
I do. The CPAN don't enter into it for me at that level. I was virtually unaware of its existence—but not of its various competitors in the high level language space—for the first 5 years I was slinging Perl. I know it's a little bit of the post "Death of Perl" party-line that sure Perl sucks but, hey, look! the CPAN! I've never felt that way at all. I wouldn't be a software engineer if I couldn't use Perl at least most of the time. Paraphrasing what TEH DAMIAN said: I like Perl because it lets me hack the way I think.
| [reply] |
|
|
Took me a long time to find CPAN as well, and when I did I found the vast array of modules really daunting at first.
| [reply] |
|
|
Because perhaps the biggest mistake of the [Perl 6] project was ... to call it “Perl.”
Oh, please! Anything but that silly debate again. Without a time machine, there is absolutely nothing interesting anyone can possibly contribute to the discussion that hasn't come up countless times already in the past eleven years.
| [reply] |
|
|
Because perhaps the biggest mistake of the Perl-6 project was ... to call it “Perl.” It is a new language.
Yes and no. Yes - because it has a lot of features built in the core of the language itself (first being difference between method and subroutine, for example), and No - because it feel's like Perl. And it feels like Perl because you can comunicate to it in the same way you talk to Perl 5. The "spirit" of expression evalation process is there. It does the right thing from the first time you try to use it.
We don’t use Perl because of its language-goodness. ... We use it because of the vast and well-tested CPAN library.
Yes we do. CPAN is here so we don't have to reimplement stuff from scratch again and again. On the other hand, when working on a new problem I feel most comfortable expressing it in Perl. Later on, I might translate the solution to another platform - mostly for performance reasons. I like Perl because it's Perl, not because of CPAN. I use CPAN for boring problems, and to advocate it's uses to other to solve their boring problems too.
| [reply] |
Re: Moose - my new religion
by Anonymous Monk on Nov 25, 2011 at 09:18 UTC
|
Waiting for Perl 6 futile at this point of time. Almost 12 years have come to pass. And there is nothing good available that can replace Perl 5 or even some other language like Python or Ruby in production environments.
We need to come out of this thing and deal with it. There is not going to be a Perl 6.
The world has moved on, and those who wish to stick with Perl have seen Perl 5 doing pretty well. With all the Modern Perl movement, Perl 5 is still good. And I guess that will be for the remaining bit life of Perl.
Perl 6 was the imaginary future, which never came to happen. And isn't likely to happen for many many years from now. Given that uncertainty. No one serious is ever going to bet on Perl 6.
But thoughts from Perl 6 have helped Perl 5. At this point of time that seems to be the only helpful thing Perl 6 has achieved.
| [reply] |
|
|
This "waiting for Perl 6" confuses me.
People don't wait for new programming languages the same way they wait for a bus. If you wait 30 minutes for a bus that you would expected to come after five minutes, you are angry that you lost 25 minutes, and decide to take the 10 minutes walk to the next subway station, or take a taxi.
That's not how people wait for Perl 6. They use other programming languages (often Perl 5) in the same time, and don't lose any time anticipating a Perl 6 release that will be useable in their production environment. So the 12 years of waiting aren't 12 wasted years for anybody (except if somebody really was that foolish not to use any other programming language in the mean time).
And thus those 12 years aren't really a problem for most of us. When somebody tells you about a cool programming she just started using, does it really matter if that language has been 2 or 12 years in the making?
To stretch the analogy a bit further, it's a bit more like waiting for electrically powered cars. When a company starts selling powerful and affordable electric cars, I'll buy one, and won't make ridiculous claims like "The world has moved on", just because they were long in the making.
Perl 5 has fundamental flaws that aren't being addressed by any future plans for Perl 5 development that I've seen so far, just as gas powered cars have a fundamental flaw in the long run (limited fuel availability). Gradual improvements (like more efficient fuel usage) help for a certain time, but they can't replace a fix for the fundamental problems.
| [reply] |
|
|
That's not how people wait for Perl 6.
I wrote my first serious Perl 6 code in 2005, because Pugs was mature enough to run it. (Admittedly I had to hack on Pugs with copious help from Audrey to make it run, but I did it.) Then Pugs hit a wall and I couldn't run it productively any more. (It took eight hours to run the full test suite with Pugs. I think this was around February 2006.)
Around the time Rakudo became Rakudo and not languages/perl6 in Parrot, I could run that code again. Then came the Rakudo rewrites. I was hopeful that the Rakudo Star release targeted at April 2010 (which slipped to the end of July) would mark the point at which I could have that code running and keep it running with minimal work. I don't mind making minor syntax changes to meet specification changes now and then (it was pretty standard and straightforward OO code with a little bit of multiple dispatch, after all), but the point of usability I wanted was the point at which I didn't have to pay the upgrade tax with every new compiler release just to keep working code working. (The program was effectively finished; it didn't need further development.)
Then came the Rakudo rewrites. I can't even describe this history effectively; I know Rakudo's gone through PGE and NQP and NQP-rx and NQP-ng and now nom, and I know I have them in the wrong order and I don't remember which of those occurred before Rakudo Star 2010.07. In a way, that doesn't matter.
I started to worry last December, and I stopped trying to maintain that program altogether in January when it was clear that the nom rewrite would take far longer and produce far more disruption than anyone else wanted to believe. The choice was between sticking with unmaintained code of Rakudo releases on an abandoned branch or switching to a rewrite in progress.
I knew that I could be wrong—things could have gone smoothly—so I decided to wait and see what happened. Now that nom has officially replaced master, it does have some improvements, but it still has substantial regressions. There's also still no new Rakudo Star release.
I'm not interested in telling other volunteers what to do or what to care about, but I cannot in good conscience say that "Perl 6 is just around the corner" when I (who started working on Parrot in August or September 2001 and on Perl 6 in February 2003) have to pay the upgrade tax every month to keep a relatively simple and finished program running.
I can overlook a lack of documentation (documentation is difficult) and occasional bugs and missing features. I can put up with specification changes (they've largely been for the better). I can choose whether to work around the lack of useful libraries (someone has to write them). I accept that people will work on what they want to work on, especially when most of them aren't getting paid to produce a useful product.
Yet with all of those disclaimers, trying to keep that simple program running across all of the changes in Rakudo became very much a waste of my time. The Perl 5 replacement isn't as nice in a compulinguistic sense, but it has the advantage of working and continuing to work without me having to modify it every few weeks (to get performance improvements or bug fixes). Six years was long enough for my experiment to show that Perl 6 really isn't just around the corner unless something changes dramatically.
(No, I'm not going to share that program, because the spectests cover every part of it. They have for years.)
| [reply] |
|
|
|
|
|
|
|
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: Moose - my new religion
by cavac (Parson) on Jan 08, 2012 at 11:52 UTC
|
Maybe it's just me, but what exactly is modern about Moose? To me, it feels a bit like i've been thrown back in time to when i was programming in C++. For me it feels like it is limiting the potential of a program by defining restricted interfaces.
I always felt that C++ and Java OO always tried to force me into a confined space where only things are possible that the original developer of a class felt necessary. Yeah, i realize that this may or may not be a good thing, depending on what you are trying to accomplish.
For me, using the Perl 5 native OO actually feels like i have been released from a prison camp. I don't have to overload objects or have my local, modified copy of a Perl module just because the long-gone author of that module forgot to close a file. I just wadd a single line of code like $broken->{infile}->close() and be done with it. Makes - in my opinion - for a much more readable code and is easier to debug than having to step through multiple parent classes.
Last time i tested it (quite some time ago), Moose also had a terrible, unacceptable performance penalty that prohibited me from using it on our production servers.
As i said, this is my personal opinion, this may differ if i where in a big development team and/or had much more server resources available. But as it stands now, in a developer team of one, for me Moose does not make sense at all...
Disclaimer: There is of course the chance i misunderstood completly how Moose works. But then again, i'm quite happy with the "classic Perl 5 OO", so i didn't invest weeks and weeks of learning Moose in exquisite detail.
"Believe me, Mike, I calculated the odds of this succeeding against the odds I was doing something incredibly stupid… and I went ahead anyway." (Crow in "MST3K The Movie")
| [reply]
[d/l] |
|
|
Assuming you already use OO, Moose makes a lot of common tasks much easier. Writing object accessors (i.e. getter/setter methods) all the time gets tedious. Moose makes them trivial - and even adds type checking. So if your BankAccount class has a "current_balance" attribute, rather than writing something like this:
sub current_balance {
my $self = shift;
if (@_) {
my $new = shift;
croak "not a number"
unless Scalar::Util::looks_like_number($new);
$self->{current_balance} = $new;
}
return $self->{current_balance};
}
You just write this:
has current_balance => (is => 'rw', isa => 'Num');
And as a bonus, you get the same type checking thrown in to your constructor. (And you never need to write sa constructor again!)
It frees you from having to worry about the ins and outs of writing constructors and accessors and so on, allowing you to spend more time focussed on higher level stuff. That's got to be a good thing.
Method modifiers are another great thing. Say you have a class DB which offers methods "select", "insert", "update" and "delete". For debugging you might want to create this class:
package DebuggingDB;
use Moose;
foreach my $method (qw/select insert update delete/)
{
before $method => sub { warn "$method was called" };
}
That way, whenever one of those methods is called, you see a warning about it. But for this to work, you'd need to go through your code and replace DB->new with DebuggingDB->new everywhere. But we can go better than that...
package DebuggingDB;
use Moose::Role;
foreach my $method (qw/select insert update delete/)
{
before $method => sub { warn "$method was called" };
}
Now DebuggingDB is not a class, but a role, and we can compose it at run-time:
use Moose::Util qw/apply_all_roles/;
apply_all_roles('DB', 'DebuggingDB') if $ENV{DEBUG};
But maybe we know the connection to the accounts database is working fine, and we only need to debug the connection to marketing...
my $accounts = DB->new(...);
my $marketing = DB->new(...);
use Moose::Util qw/apply_all_roles/;
apply_all_roles($marketing, 'DebuggingDB') if $ENV{DEBUG};
The ability to apply roles not just to classes, but to objects at run-time, is very powerful. This is something you can do without Moose, certainly, but Moose makes it a lot easier.
Lastly, it gives you some very powerful introspection: much more so than Perl's default OO introspection (isa, can and DOES).
Yes, Moose does have a performance hit. However, much of that is compile-time rather than run-time. So if you have a long-running process, such as a daemon, this is usually quite acceptable. (Whereas in a CGI script, where start-up time is important, Moose would probably be impractical.)
Moose isn't right for every project, but if you're doing OO, if start-up time isn't so important, and you don't care about adding some pretty heavy dependencies to your project, then it's a natural choice. | [reply]
[d/l]
[select] |
|
|
I value your input. Thanks!
Update: Seems like this reply is getting the odd negative vote. I agree that this post may not be to the likings of everybody. And you're in your rights to give me negative votes. But i'll ask you to add a comment explaining what you didn't like about it so i can use it as a learning experience.
My programs usually have very few traditional getter/setter constructs. These days, i mostly work with multiple processes (prefork stuff), so i do more or less all data exchange though DBI or Memcached (depending on if the data needs to be valid all the time or is just for debugging or non-critical single user settings).
If i need to add multiple similar functions (in this case specifying a modular plugin API) i do something like this:
Update 2: Added readmore tags
I don't think i have more than a dozen really classical getter/setters in my 40.000+ lines of Maplat Perl code (OSS + DarkPAN).
"Believe me, Mike, I calculated the odds of this succeeding against the odds I was doing something incredibly stupid… and I went ahead anyway." (Crow in "MST3K The Movie")
| [reply]
[d/l]
[select] |