Slashdot Mirror
Mojolicious 2.0: Modern Perl For the Web
Kvorg writes "After a year of rapid development, newly released version 2.0 of Mojolicious, the new generation real-time Perl web framework written by Sebastian Riedel and many others, offers a versatile and elegant web framework that is as good at web scraping and simple scripts as it is at building complex, interactive real-time applications with HTML5 and websockets. It supports easy 0-dependency installs, excellent developer mode, multiple deployment scenarios, many CPAN modules and plugins."
Because clearly what we need is _yet another_ way to develop web applications.
Says the AC posting on a site written in perl.
Every time I look at a script I've written that's at least a year old, it's like the first time I've ever seen the code.
Not to take anything away from this framework, but now I'm curious since at first I took the post title too literally. Wasn't Ruby supposed to be modern Perl for the web? Whatever happened to that? People get bored? Web developer ADHD?
Another perl web framework. I can't wait. I'm champing at the bit. /yawn
I use perl all the time, and have yet to run into a framework that actually saves time overall. They're generally designed by Unix guys who really don't want to think about web design any more than they have to - and it shows.
#DeleteChrome
The only exciting part of this new Mojolicious is to expand on a bunch of Perl web stuff you might already maintain. I don't have any large apps (like slashdot), but many "single page" type applications that process data or serve up custom reports. The simple pages simply flush stdout so when displaying long output appear speedy to the user. Others use some javascript and cludgy .html() replacements. Websockets and json support would be nice when extending these applications where the "bulk" of the code written in plain Perl doesn't need to be modified.
I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool.
String parsing and massaging.
Hashes.
Also, system administration. Like sed and awk, perl should be in most sysadmins' arsenal, seeing daily use.
Want to replace all occurrences of foo with bar in all files, while making a backup?
What perl is not good for, and frequently is abused for is providing multiple layers of abstraction. You burn memory at an alarming rate, and your code becomes even harder to maintain by "simplifying" it. If good perl code looks cryptic, add comments!
I suppose the idea is neat, but I personally don't have any particular applications where I need Perl to actually be the whole webserver for me. The things that do come to mind would involve a small system where there is no webserver installed, but going on port 80 would mean running the script with higher privileges and the whole mess of Perl and everything need to be jailed. Or maybe to try one of those utilities I heard about to pass privileged ports to an app, but I haven't had experience with those.
To be honest, frameworks left kind of a bad taste in my mouth when a language such as Ruby that had been around for years suddenly exploded when Ruby on Rails showed up. Everybody and their brother thought it was the new hip thing to use, until a lot of the bigger websites which had deployed it started to actually dump it due to limitations. Nobody wanted to take the time to write good code to start with, and it bit them in the butt.
Using frameworks (whether it's .NET or on the web or otherwise) usually starts out as a means to set up a new project quickly, but the problem is that they end up being an excuse to make sloppy bloated coat for the final product. Perl was always fast and efficient; people should learn to develop in it that way.
I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.
It's still _the_ tool for quick one-off type stuff. I know of no other tool that lets you just mash data together and produce something useful as easily and quickly as perl. That said, I'd never use it for a serious application or anything that had to be maintained for more than a few weeks. Those days are gone.. maintainability and reliability are king.
For my part, I find it remarkably easy to implement RPC calls, CRUD especially, using this framework. Go to CPAN, read the Mojolicious::Lite exampes and decide for yourself whether it's worth your while.
Crumb's Corollary: Never bring a knife to a bun fight.
Don't avoid $_ and @_; use them when they are useful, even in implicit form. Perhaps especially in explicit form.
What's more elegant?
or
or
I have seen far too much misguided code of the first and second type.
Have the comments explain what the purpose of the code is, not how it does it. The way to fix perl code isn't to read and understand the actual code, but replace the part that doesn't work as expected with code that does. If you understand your comment and know how to write perl, you don't really need to understand how a cryptic line does something - it's faster to rewrite it from scratch to do what you want.
I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.
It's still _the_ tool for quick one-off type stuff. I know of no other tool that lets you just mash data together and produce something useful as easily and quickly as perl. That said, I'd never use it for a serious application or anything that had to be maintained for more than a few weeks. Those days are gone.. maintainability and reliability are king.
Well the really smart guys that figure out DNA started using it. Many startups use it. I've used it pretty much everywhere I've gone and it's leaps and bounds above what I find in use in most places. It's huge in Japan. It was the favorite language of the guy who created Ruby, he just wanted more.
So yeah no serious application or anything that had to be maintained, no never that, because how could anyone possibly write maintainable Perl. Instead you should use a programming language where maintainability and reliability are king, that language of course is ...???
By the way Slashdot the not so serious site you are on is written in Perl.
Indeed. While it's slower than "chomp while chomp", it doesn't depend on $/ being set correctly.
(If you can rely on $/, and you golf, s-$/+$-- is even shorter)
By the looks of it Mojolicious does support stuff plain Django doesn't pay much attention to or leaves to the webserver (long polling for instance). Useful!
Then again, Mojolicious doesn't have a built-in ORM or input-validation via forms. Together with URL handling and the request/response loop these are the basic building blocks in Django.
So 'superior in important ways' depends on what you find important. I'm guessing 99% of Django users beg to differ.
This sig is intentionally left blank
If you understand your comment and know how to write perl, you don't really need to understand how a cryptic line does something - it's faster to rewrite it from scratch to do what you want.
That assumes that the comment correctly describes what the code intends to do. This is a very big assumption to make and I've worked on numerous projects where the comments were significantly different from what the code did. Looking through the change logs, this situation always arises because someone updated the code but didn't bother to update the comments.
This brings me to my point: The code doesn't lie.
If you can't understand a piece of code, you're going to be working off assumptions. Refactoring code based on assumptions is dangerous unless you have very rigorous unit tests. I've found that the level of code obfuscation is negatively correlated with the quality (or even presence!) of unit tests. YMMV.
What happened to modularity?
Django advocates loose coupling between it's modules. You can easily use Django's ORM in a non-Django app, or use a different ORM (e.g. SQLAlchemy) in a Django app. Having said that, I've found that the Django ORM is nice and intuitive if you're a programmer (like me!) and really want to avoid working with SQL directly while SQLAlchemy caters to people who are more comfortable with SQL.
Your example of Perl is Slashcode? I'm not sure that has the desired affect on the audience...
Can you be Even More Awesome?!
Never said it _hasn't_ been used to write something maintainable.. just that I wouldn't use it for that (any more.. ).
Yes you can write maintainable code in perl if you make a specific effort to do so, but to me that defeats the point. It's primarily a hack and slash language that lets you crank out code while you think. To me writing maintainable perl is like writing a quick one-off script in c++ or java. Yes you can do it, but why bother. Use the tool that is suited for the task.
And the DNA thing is a perfect example of the kind of "we need an answer to this question, then don't care about the code afterwards" situations where perl is king.
Perl can be as easy to read and maintain as the developer can be bothered to make it. Sloppy Perl is written by sloppy developers. It has proper variable scoping, namespacing, packages, object inheritance, etc. You also don't have to squeeze as much functionality into one line using as many special characters as possible.
Sure, there's plenty of ugly Perl out there. I suspect much of that is stuff that started as a small, quickly hacked together script which grew into something larger. Perl also used to hold PHP's place as THE language to use for web back end stuff, so it had a lot of amateur devs doing stupid crap. I can find you awful code in any language you want, though. I've got some crazy Python in front of me right now.
I'm not saying it's the best language to use anymore, but it's not even 1/4 as bad as people like to make it out to be around here. Plus many of its libraries are still easier to use and have more functionality than the equivalent libraries in other more popular languages (opinions on that may vary, of course). LWP is still my favorite web client library.
I agree that it's possible to write maintainable perl, but from my vantage point, perl is not really designed for this.
To me it's more of a hack n` slash language. Code while you think. All those shortcuts and lack of boilerplate code and ability to just say "take this data, compare it with this, and do whatever" in a few lines is to me perl's strength. The fact that the resultant code is hard to read is the weakness. If you are not going to do that, and write code in a more rigid, designed manner to avoid this, why use perl in the first place? To me it's like writing a quick one-off type script in c++.. you can do it, but why would you want to? For the libraries as you said maybe.
The argument that it's not the tools it's the developer stands, however I do think some tools are more oriented towards maintainability (java, c++) and others towards rapid development (perl). You get ugly code in every language, but perl almost directly encourages it. The CPAN tool is _the_ definition of perl. Works, but oh my god is this code or cyphertext!
What's more elegant?
(or mystring = mystring.rstrip('\r\n') if you're pedantic about only removing EOL chars)
Dewey, what part of this looks like authorities should be involved?
Totally apart from a pretty slick MVC framework the Mojolicious project has my undying affection for producing the mojo tool.
How many times have you wanted to scrape something out of a web page and you thought "I know, I'll use wget (or curl) and sed! Easy enough." so you write
# get story titles from slashdot
wget slashdot.org -O - 2>/dev/null | sed -e 's/uh, what now?//'
And then you get stuck fiddling with ever-crazier sed expressions to filter down to just the data you want? I know I've been there a dozen times and wound up with various unpleasant solutions or, when necessary, I've broken down and written a proper perl script which parses the HTML (and taken about 20 times as long as I planned to take to do it!) Maybe you try
And just go with it, because it's good enough. Well, no more! Now I can say
And have my results just like that!
Just as jQuery was a revolution in DOM scripting, to the point where I just won't write JS without it, so is mojo a revolution for these kinds of applications. I can now pull down pages and parse the actual structure and select just what I need. Beautiful.
I want my Cowboyneal