JQuery and Moose
In the spirt of re-usability, I'm sharing something I posted elsewhere last week:
The context is that recruiters are pressuring older programmers to learn JQuery (read Community College class) and I'm also wondering whether to rewrite a few apps that I maintain.
I'm standing by the conclusion of my Amazon post. Although there is naturally some value to a standardized framework, these frameworks are usually presented in contrast to the worst alternative. The examples demonstrate that JQuery is vastly superior to a procedure based approach that doesn't even use shared function calls for optimization. I reached the conclusion that JQuery provides a handful of generic class definitions for "programmers" who will never learn OO, or other code encapsulation skills.
Although I don't want to overstate these parallels to Moose, JavaScript implements OO exactly the same way as Perl5- without accessors. Consequently, I'm skeptical when I hear that Perl5's OO is archaic or discredited. I didn't encounter the argument that JQuery "fixes" JavaScript's flawed OO design. But that useless book might merely have lacked the technical sophistication. Others may have already drawn this parallel.
Granted, Perl5's vocabulary, such as the @ISA idiom for inheritance, should never have persisted beyond Perl5 beta. It seems very tentative, like a placeholder for a task that was never completed.
But I've been thinking about the talk in Austin demonstrating Moose roles and how essential its "partial inheritance" features are. And I started thinking about JQuery. Does this feature simply accomodate poor programming? And as such, is there a danger of institutionalizing poor practices? Nobody should be designing classes that provide functionality beyond the "role" expected in the Moose framework. If an application is capable of multiple roles, each should be split into separate class definitions. Classes are supposed to be specific and discrete.
This post may indicate my ignorance: My CPAN contributions always consist of multiple classes that reflect this programming practice. And it's frustrating that CPAN doesn't distinguish which classes are independent. In other words, CPAN's taxonomy doesn't separate classes from packages. I.e. in Java, a package represents a group of inter-related classes.
Back to Moose: Is the paradigm that what Java considers a package, Moose considers a class; and what Java considers a class, Moose considers a role? I'm sure I'm over-simplifying. But if this description is fundamentally accurate, then I'm inclined to express my reservations, however belatedly. Is Moose merely popular because everyone likes it?
-Jim
NoSQL::PL2SQL is everything I've got.
I don't quite get it. Is this the anti-modern-javascript post we all have been waiting for?
jQuery isn't great, and the APIs that plugins provide is generally godawful (method names passed as strings al a ... $("#id).accordion( "option", "active", 2 ) ... what the frack is that?)
However, jQuery is pretty useful and there's a lot of stuff that JQ does for you that I wouldn't ever want to do by hand. But if something with a decent API design came along I'd greatly prefer to use that.
I'm not sure I follow the parallels you make between Moose roles and JQ. The design of JQ bears little resemblance to anything a Moose core dev would recommend.
jQuery certainly isn't a different kind of JavaScript OO, it's just a library that presents a set of methods and functions.
What Java considers a package, Perl considers a directory on the filesystem (CPAN considers it a "Distribution"). What Java considers a class, Perl considers a package or a module, and Moose considers a class (they are used interchangably in Perl and Moose). Java's internal, private classes cannot be achieved with Perl, but multiple classes/packages can be inside a single Perl module.
Java does not have Roles, but it does have Interfaces. Moose's roles can be used as Java Interfaces, but they can also have concrete implementations of methods, making them more powerful.
That'll be because:
Rather jQuery's focuses are on functional programming, DOM manipulation and making AJAX more sugary. The nearest equivalent in Perl would not be Moose, but rather, say, the combination of List::MoreUtils, HTML::Zoom and WWW::Mechanize.
No. The concept of classes is roughly identical between Java and Moose (except that Moose, building on Perl, supports multiple inheritance). Moose roles are closer to Java interfaces, except that interfaces consist of method signatures with no implementations, while roles may provide implementations for methods (but are not required to do so).
I haven't read the book, but in the synopsis it states that JQuery is a "JavaScript library" - I would agree with this, it's a library not a framework.
You seem to be thinking about it as if it is a framework and maybe this has got you off on the wrong foot.
For app building JS has some pretty nice frameworks, take a look...
http://backbonejs.org/
http://emberjs.com/
http://javascriptmvc.com/
Thanks for all the great responses. I expected a bit more come-uppance for my generalizations about Moose.
I understand that "modern perl" specifically refers to the MOP paradigm and generally means Moose. But results on a google search for "modern javascript" only show effective synonyms for "state-of-the-art javascript".
confuseAcat's response struck me as slightly ad hominem. My fundamental point is the challenge of separating the hype from the substance. The use of the term "modern" smacks of the former in that "modern" is not very descriptive and intends to imply that its detractors are trogolodytes. FWIW, "modern" can sometimes also mean "outdated" as in "modern architecture".
preaction's response about perl directories is contrary to my understanding: I've published XML::Parser::Nodes consistent with XML::Parser::Expat, XML::Parser::PerlSax, and XML::Parser::Lite. These are all separate distros independent of XML::Parser.
In conclusion: Both these responses demonstrate the same confusion and ambiguity that I've experienced.
Also, thanks nickl, I'll check out your recommendations.
> I understand that "modern perl" specifically refers to the MOP paradigm and generally means Moose.
I'm sorry, but this statement is wrong in too many ways to enumerate here.
Modern Perl refers to simply learning from one's past and eschewing a number of practices that have turned out to be bad. As a few examples (this is *by far* not an exhaustive list):
- programming without strict/warnings
- programming without using cpan (i.e. lots of reimplementation and copy/paste)
- write code that's difficult to read
- using bareword filehandles
- using 2-arg open
Modern Perl instead encourages people to (again, non-exhaustive):
- use strictures and warnings everywhere
- use CPAN as much as possible
- don't reimplement functionality repeatedly
- don't ever copy-paste code
- write tests for everything
- use Devel::Cover, Perl::Critic, Perl::Tidy
- use modern features of perl core (such as 3-arg open, filehandle references), that replace bad practices
John Resig is a big Perl user, which surprised me nicely when I was interviewing him for FLOSS Weekly.