Mojolicious – Perl real-time web framework
mojolicio.us
mojolicio.us
I mostly use Python these days myself but I'll never forget the sense of power that Perl gave me when I learned it back in the late 90s (prior to Perl I had programmed in Turbo Pascal and Basic). To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code, mostly thanks to a huge ecosystem of powerful libraries (CPAN). Granted, the object-orientation felt more like a hack than a normal language feature (because it was one), but all in all it's still a really great language and just as powerful as Python, JS or Ruby.
Perl's OOP is definitely a hack! But it's a clever and elegant hack, and younger languages can learn a lot from studying how an awk++ managed to evolve support for all these new programming paradigms, without being totally co-opted by the ones which turned out to be fads. (When these languages are Perl's age, will they have evolved as successfully?)
Take OOP support in Perl. Prior to that, Perl had references, which could point to other basic value types, and it had packages, which were namespaces in the symbol table. Only two small changes were necessary for OOP.
First, a new built-in function `bless` was added which marked a reference as associated with a certain package. Second, a new binary operator for dispatch was added, the familiar `->` from other languages. The dispatch operator looked up a package from the reference on the left hand side, looked up a symbol within that package given by the right hand side, and pushed the reference onto the front of the argument list in the subsequent function call. In the called function, the initial reference argument became the equivalent of `this`, by convention.
Modulo some discussion of @ISA, that's it. You now understand Perl's implementation of OOP.
The elegance of this approach finally hit home for me when building transparent RPC for Perl and other languages. On the client side, when you dispatch a function call on a "stub" object, you'd like to dispatch a real function call on a remote object. In Python, you have to worry about whether you're calling a "bound function" on the remote object, versus calling a static method of the remote object, versus calling a "free function" defined at module scope (how do you address these?), and so on. In Perl, these are all effectively the same thing because the dispatch operator is so simple, and there's no extra OOP structure baked into the language itself like there is with Python.
Disclaimer: I mostly write Python 2.x now, but things like the complicated object runtime and the general uselessness of lambdas strike me as places where the language has stumbled.
Inheritance was no longer a black box, but just a way of working out where to look for the method and execute it.
If you squint you can view prototypal inheritance as class-based-inheritance-where-everything-is-a-singleton ... but you really need some alcohol to deal with the headache you get from squinting that much.
This sounds interesting. Why do you feel this way?
(If you still wonder -- from your comment history you shouldn't -- try Google: python lambda broken)
I work with Perl professionally now after having spent most of my self-taught programming education using Python, and I've been pleasantly surprised with the language. I'm both coding new projects and working with a more than decade old code base, and I've found that Perl code is as good as the programmer.
Yes, like any decades old language it has its warts, but Perl 5 itself is still being developed and improved upon. For those who know another scripting language, the free book Modern Perl is a great place to start learning: http://modernperlbooks.com/books/modern_perl_2014/
One of the things I like about Perl is that it offers tremendous performance, in addition to having an actually-useful debugger.
Subroutine calls in Perl aren't free; in fact they have a significant performance penalty if overused. And that's exactly what Moose uses, in droves.
Making Perl act like Ruby will also make it as slow as Ruby, and as difficult to debug.
As such, runtime is just as fast as any other perl code that uses accessor methods rather than poking into its own internals.
Plus, of course, once you've got a Devel::NYTProf profile showing that a particular accessor is a hot spot, you can still poke into your own internals for that particular purpose to resolve the bottleneck.
So, no, not really; generally you only pay a cost for the pieces of cleverness that you actually use, especially given the existence of Moo for fast-startup code where you don't need the MOP.
I don't know enough to vouch for Perl's performance vs other scripting languages, but I do know my boss (a very experienced Perl hacker) has a favorite saying: "If you wanted performance, why did you pick Perl?" :)
Perl might be one of the fastest languages from this point of view. I write 1%of my code in C and the rest in Perl for optimal efficiency.
and even metaobject protocol
Until the Perl community resolves the issues with Perl 6, the waters are too murky for a lot of otherwise would-be JAPHs.
Perl 6 is worth paying attention to, but not as "something which will make Perl 5 obsolete". Don't let the status of the various P6 distributions stop you from using P5 to make cool stuff today. :)
That's mostly just a marketing ploy by a few people trying to make money off books and speaking fees. Ignore it.
> To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code
I've been a part of an awful lot of different programming communities over the years. And somehow each one has a different set of languages they know and favor and have learned in the past.
What's more, they seem to think this same experience more universal than not. I've heard whole groups of people who claim in three part harmony that they love [X], and don't know anyone who's ever used [Y].
Every time I see a comment or blog post or tweet that mentions "that [Z] language and/or tool that we all know and love", I can't help but wonder which gated community they're a part of. It's just automatic now. Kind of like how every time I hear Canon in D, I remember the Pachelbel rant on youtube.
How many developers or "power users" would have just ran that command without even thinking about it?
I guess signing packages with trusted keys and serving them over https is far too lame for devs these days.
(Not that I'm calling out this particular project, it's seems to be crazy popular to offer "curl some.script | bash" as installation instructions lately for some reason.)
Big corps (and users which avoid smartphones, certain social networks, marketing campaigns, etc, like me), should develop their internal git mirrors, cpan mirror, build systems, etc. As usual.
Many developers reproduce the same issue with node, python, ruby etc. That does not remove LOVE from this beautiful framework.
I can state that the mojolicio.us "web development can be fun again" is true for me.
Just go for it, check yourself the docs and the source, hack, and judge by yourself.
We are talking about that, not about the lack of common sense of many developers, when the topic is about systems, security and operational tasks.
Perl apps can be deployed securely after auditing them. What knowledge do you lack about this defocus topic ?
Developers are supposed to do "cpanm Mojolicious", like for any other perl module.
"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"
What I'm getting at is its probably easier for me to get this line of source code added to a perl module:
# Don't actually run this in a Perl interpreter, esp not as root, OK?
`rm -Rf /`;
It would be harder to get this added to the installer:
# Don't actually run this in a shell script, esp not as root, OK?
rm -Rf /
Also if CPAN / its installer / github / etc get owned, the last problem to be concerned about is one little perl module. You have bigger trouble.
Let's face it - Perl is magic ;)
https://docs.djangoproject.com/en/dev/ref/templates/api/#com...
$ perl -Mojo -lE 'a("/foo", { text => "lol" })->start' get /foo
lol
The only thing that's missing is a book that explains the concepts in more depth than the documentation. (I believe some folks in the community are working on that).
I really like the new concept brought by Node.js. However I realised that most of the time I don't need/want to write asynchronous code which I found harder to test and grow than synchronous code.
Now Mojolicious is a non-blocking IO framework that simulate blocking IO by default. This means that with Mojo you can write code either with blocking or non-blocking IO. To do that you'll have to learn using the mojo::IOLoop which is less natural than node.js to do non blocking but does the job and got easier to use with the 5.0 release.
With node.js you don't have that choice, you're stuck writing application entirely asynchronous.
I would be much more interested in a comparison with the alternatives, for example Mojolicious vs Catalyst, but apparently very few people are able to do that.
Also doing non-blocking stuff with Catalyst seems to be a real pain (though I haven't tried it yet).
When I read up a little on Mojolicious to have an opinion a couple of years ago, it seemed more complex than Catalyst?
I'll put my JavaScript hobby aside and look at it again. Any good links? [Except the one posted by walterbell at http://blogs.perl.org/users/joel_berger/mojolicious/ Grumble, that was already on my reading list.]
Those are elegant, I'll watch them as if they were new Seinfeld episodes. :-)
I didn't have a "slightly off impression", rather I didn't see a large reason to go Mojo.* instead of Catalyst (without a need for real time support.)
As soon as you mention the outdated (indated by FCGI-mod_perl) CGI module .. you are thought to be living in the 90s. For production, I can agree partially with them, but for educational purposes, it twitches my nerve :/
Though, I like mojo over others due to its lean code.
Non-realtime frameworks often have to resort to communicating with websockets over something like zeromq.
Delicious! Let's pipe data retrieved over raw HTTP and pipe it directly to sh. It's like one of those Head-On commercials (remember those?) only with digital cyanide.
So again, what's the difference as opposed to convenience with the pipe?
It is not a problem with mojolicious at all. Its a nice helper that should be carefully used.
http://www.reddit.com/r/stljobs/comments/2a9940/seeking_software_developer_for_the_genome/