Slashdot Mirror


Perl 5.20 Released, and Mojolicious 5.0: the Very Modern Perl Web Framework

Kvorg writes: "Back in 2012 Slashdot noticed how at the time of Perl 5.16, the modern Perl projects, including Mojolicious, formed a new and expanding movement of a Perl Renaissance. With the release of Perl 5.20 and Mojolicious 5.0, the Modern Perl Renaissance is ever more striking. Faster, neater, sharper with its asynchronous APIs, Mojolicious is extremely flexible with its advanced request routing, plugin system, perl templating and hook API. Its adherence to the modern interfaces and standards and its implementation of advanced features in support tools, DOM and CSS selectors makes it easy to program with.

Mojolicious, with its philosophy of optimized code-generation (think metaprogramming), enabled-by-default support for encodings and UTF-8, zero dependency deployment with wide support for existing CPAN packages, zero downtime restarts and fully tested implementations, reminds us of how fun and flexible programming in scripting languages used to be. Of course, integrated documentation and a very supportive bundled development server don't hurt, either. The new Perl release with new postfix dereference syntax, subroutine signatures, new slice syntax and numerous optimizations makes it all even more fun."

26 of 126 comments (clear)

  1. Damn I'm old... by Penguinisto · · Score: 5, Funny

    I kept thinking "I am the very model of a modern Major Perl Framework..."

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
    1. Re:Damn I'm old... by just_another_sean · · Score: 2

      I think being old is a requirement for understanding TFS. :-)

      --
      Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
    2. Re:Damn I'm old... by Tackhead · · Score: 4, Funny

      I kept thinking "I am the very model of a modern Major Perl Framework..."

      I am the very model of a modern Major Perl Framework,
      But here I am on Slashdot, trying harder from my job to shirk,
      From HackerNews to 4chan there's no forum in which I won't lurk,
      I am the very model of a modern Major Perl Framework!

  2. Awesome! by just_another_sean · · Score: 5, Interesting

    I don't much care about what a lot of people think about it, I love Perl and still use it daily in my job. I've dabbled in PHP and the various frameworks it supports but I always find myself returning to Perl/CGI/DBI. But this sounds like something I have been waiting for. It's really nice to see some new stuff coming out for Perl 5 as I simply can't seem to wrap my head around Perl 6. This is great news for old dogs!

    --
    Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
    1. Re:Awesome! by walkeraj · · Score: 3, Interesting

      Perl 6, what's that? Seriously though, it's nice to see p5 undergoing productive changes as the grand wait for Perl 6 wears on and as it becomes more clear that the Perl 6 we're getting might not be the one we wanted. Having said that, I find it annoying that the focus on backwards compatibility hamstrings new features to the degree that everything is marked as unstable or experimental and we're left just writing the same damn old perl 5 we've been writing for years. We keep dancing around the issue, but what's really needed is a breaking fork of p5 to revamp the code base and remove a lot of the cruft and make a language that can be parsed by more than just the perl interpreter. Better packaging would be nice too. I'd love to see Perl offer proper bundled binaries a la Go.

      --
      Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
    2. Re:Awesome! by preaction · · Score: 3, Informative

      The p5p (Perl 5 Porters, the main p5 dev group) are removing a bunch of cruft. Old OSes and EBCDIC are up on the chopping block next. They're also removing microperl, which unfortunately probably is the best chance of getting more than perl to parse Perl (microperl removes just about every OS-specific function of Perl, like the unix user/group/passwd file stuff).

      But honestly, there's so few people working in the core code, and I don't imagine any of the major forks I've heard about gaining any steam either.

    3. Re:Awesome! by nmr_andrew · · Score: 2

      More than likely, I don't expect Perl 6 to ever see light of day. The big problem with it is that it's not Perl.

      I don't have a huge problem with a new scripting language, but recognize that it's (for all useful purposes) something new and different and give the project a new name. Also, Perl 5 is AFAICT completely backwards compatible to at least Perl 3; Perl 6 either won't run prior code or requires a huge hack to do so.

    4. Re: Awesome! by jd2112 · · Score: 2

      Perl 6 is the language of the future and always will be.

      --
      Any insufficiently advanced magic is indistinguishable from technology.
  3. Re: People still use Perl? by thetoadwarrior · · Score: 3, Funny

    People still trotting out that tired meme? Color me surprised.

  4. Re:People still use Perl? by Penguinisto · · Score: 2

    People still use BASH (and yes, it's still hella usable if the task is simple).

    If the tool fits and does the job, use it.

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
  5. Maybe one day by aliquis · · Score: 2

    Maybe one day even Slashdot will get UTF-8 support.

    One day.

    Any decade now.

  6. A language that lets you do whatever by duckgod · · Score: 4, Insightful

    The thing that I have always loved about perl is the "there's more than one way to do it" philosophy. Perl lets me do whatever the fuck I want. If I am doing a project for my own enjoyment then I will do whatever I want that gets the job done the fastest. Yes maybe this makes it a bad language for large groups and production applications where programmers need to have restraints in order for the group to work harmoniously. But I am an adult and I don't want to be told what is right or wrong way to do something in my home.

    1. Re:A language that lets you do whatever by Anonymous Coward · · Score: 4, Interesting

      That's one side of perl: The fastest development time imaginable for small programs. The other side, that no one has mentioned, is that perl conforms to the OO paradigm more closely than any other language (including Objective-C.) I have written very large programs in perl and contrary to popular opinion these programs are much easier to read and understand than if they were written in C++ for example.

  7. I think it would be funny as heck if.... by LF11 · · Score: 2

    ...the Next Great Web Language ends up being PERL? Yes, please.

    It has a lot going for it, especially if a project like this makes it as approachable as PHP for web application development.

    Serious question, though: other than it being old, are there any problems that keep it from being viable as a modern web application platform?

    1. Re:I think it would be funny as heck if.... by Anonymous Coward · · Score: 3, Interesting

      Yes. Not technical ones, though. Everyone has been flaming it for so long that it's no longer hip. (Sigh.)

      The problem is that Perl (like C) requires discipline. It is possible to write well written and architected code in any language. But some languages make it harder than others. But some languages (Java, I'm looking at you) are designed to coddle programmers from doing things they shouldn't. It's silly because engineers should know their craft and not require a nanny in the form of a purposely limited language.

    2. Re:I think it would be funny as heck if.... by larry+bagina · · Score: 2
      ehh, I tried using perl for a small "modern" (REST) backend, gave up and used ruby/sinatra/mod_passenger because it worked. Perl? Dancer looked nice but there are too many dependencies. CGI is hopelessly obselete (does /. still run on it?). I implemented my own microwebframework on top of CGI (a hundred lines or so to do routing) before I discovered passenger and switched to that.

      I'd take perl over node anytime but I'm not impressed by CPAN (it's better than npm, if you want some faint praise) and a lot of the code and culture is stuck in the 80s/90s.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    3. Re:I think it would be funny as heck if.... by preaction · · Score: 2

      1) s/Perl/Code/g

      2) This is one of those things that causes frustration the first 3-5 times it happens, and then you find the right habits. I can't remember the last time that actually bit me. Every language has its own definition of falsey.

      3) I've never had to read the Perl source to actually solve a problem in my Perl code (except that one time there was an actual bug in Perl, back in 5.10.0). The documentation explains everything, including all the obscure edge and corner cases.

    4. Re:I think it would be funny as heck if.... by preaction · · Score: 2

      Dancer was inspired by Sinatra, but if you wanted something close to the metal, you wanted Plack (like Rack or WSGI). But really, you wanted Mojolicious.

      Dependencies are not a bad thing. CPANTS makes sure they work. But if you don't like dependencies, you wanted Mojolicious.

    5. Re:I think it would be funny as heck if.... by preaction · · Score: 2

      1) I agree that extensive use of magic vars (the topic var, $_, especially) can create a major problem for readability. But the magic vars, $_ especially, allow concise constructions that would otherwise take a lot of my time to type and longer to verify I typed correctly. The onus is on me, the programmer, to ensure my code is readable, no matter how much the language assists me in that, and I find I can write readable Perl faster than I can write readable JavaScript (choosing two languages I feel I am equally competent in).

      2) The rules is the rules, every language has them. "00" isn't false because the rules say only "0" is false. There's even a special case "0 but true" that explicitly does not warn when used in arithmetic operators. This is a necessity due to some of the fundamentals (much like other languages have some crazy constructs due to the interaction/conflict between fundamental concepts). But here, as in 3, you're right: The plural of anecdote (my claim that this does not bite me anymore) is not data.

      3) You're right, though you're arguing a technicality. Your next paragraph is also anecdotal: "I find it inadequate" would be accurate, and fully supportable. It is not intrinsically inadequate for large projects, no more than any language is.

  8. What Python looks like to Perl programmers by raymorris · · Score: 3, Funny

    http://handsonaswegrow.com/wp-...

    Not exactly, but I like the picture.

  9. Re:That's not it. by preaction · · Score: 2

    I disagree, but perhaps that is because I learned how to program by learning Perl. I've written huge projects in Python, C++, Java, and JavaScript, and I still prefer Perl for my daily problems (but then, I also actually like C++, so it is possible that I am irreparably damaged). I have had no problem moving to other languages, I even like what they offer (even Java).

    Python's idea of the ternary operator, now that's weird. STRING.join( ITERABLE ), that's weird (though the only obvious solution because of how Python is). `string + number = string concatenation`, that's weird. There's weirdness all around!

  10. Re:That's not it. by nmr_andrew · · Score: 5, Insightful

    The problem isn't that perl is old. The problem is that perl reads (and writes) like encrypted sanskrit...

    I really wish people would stop saying this. It's certainly possible to write horribly obfuscated Perl, deliberately or otherwise, just as it's possible to write C, or Python, or anything else in a nearly unreadable way. I'll grant that Perl maybe allows you to get away with a bit more.

    However, it's just about as easy to write clean, maintainable Perl as it is in any other language. Follow good coding practices and you'll have clean code, code badly and it'll be a train wreck regardless of language.

  11. Re:That's not it. by preaction · · Score: 2

    Shell has marginally better whipituptitude, until you want

    1) Arrays
    2) Deep string operations
    3) Documents

    (though, side note, I'm working on a project to make (3) easier to handle because it comes up so often, and there's jq already)

  12. Re:Oxymoron by jjn1056 · · Score: 5, Interesting

    Given I'll make more that $200K programming Perl this year, no that was not my first reflex...

    My first reflex on seeing this on Slashdot was, "I probably shouldn't read the article because its going to be filled with the same tired, ignorant Perl hate. And then I'm going to waste time trying to respond to it."

    You don't have to use Perl if you don't want to. Why isn't that enough? Why do you feel entitled to dump your FUD on my community? Perl isn't the most popular choice but there's a lot of us making a decent living at it, so please if you don't get it, or you don't like it, unless you have a grudge with Perl that hasn't already been mentioned 100K times what's the point of saying anything at all?

    --
    Peace, or Not?
  13. Re:That's not it. by Anonymous Coward · · Score: 5, Interesting

    To expound on this point a bit deeper:

    While one can write horrible code (without trying too hard) in any language (even python!), there *is* a rational reason that Perl tends to fare worse in this regard on average.

    The reason is that, as compared to almost every other programming language out there, Perl was designed by a Linguist (as in, human languages) with an explicit goal of being very expressive. In many other languages, there's one canonical way to do a given thing, and then perhaps a few other ugly, horrible, slow, round-about ways to accomplish the same thing different, but most of the time everyone hones in on the same approximate language patterns.

    Perl, on the other hand, was explicitly designed such that there are often many wildly varying different ways to accomplish the same goal, allowing for a great freedom of expression and stylistic choice. Over the years this theme has extended throughout the Perl ecosphere, well beyond the syntactic features of the core language itself, to the point that just about any programming style or paradigm can be wrought within Perl easily. Do you like C++-style multiple inheritance? Or maybe something more like Traits/Roles and object method invocation via message passing? How about functional style lamba stuff? Meta-object programming? Threads (of a few kinds), Processes, eventloops (of many kinds)? Declarative programming (with or without OO)? DSLs? How many flavors of templating do you want? Just about any real or academic-toy knob you can think of to twist which would affect how programming languages work probably already exists within Perl at this point. In this way it's almost like a modern LISP, but with a much larger standard library of language tools built on top, and fewer parentheses.

    So you throw 50 "professional" programmers in a room with a Perl interpreter and ask them to solve the same high-level problem and you'll probably get 45 completely shitty implementations, 3 decent ones, and two brilliant ones. But not a single one of those 50 implementations will resemble the others much.

    In the hands of a real artist, Perl is a very powerful tool for writing beautiful software, and it gives said artist the freedom to solve problems using the paradigms and syntactic styles that best match the problem domain without ever leaving the world of Perl. In the hands of a novice, however, it's way too much expressive freedom, and leads to basically-trashy, horrible code. Perl is programming without lane markers, seat belts, or brakes. There's nothing standing in the way of greatness, and nothing standing in the way of being a complete idiot, either.

    Unfortunately, most programmers in the world aren't artists. They lack the innate skill, the drive and determination, or even the desire to become an artist. They're just doing a job and collecting a paycheck. Python is a great tool for these people, and Perl is not.

  14. Perl Festivity Levels by TheRealHocusLocus · · Score: 4, Funny

    Perl Festivity Level 1: Developers and users have gathered to nibble hors d'oeuvres and chat amiably with each other about the Modern Perl Renaissance. With every sip of their drinks Perl seems ever more striking. Some are gathered around the upright piano improvising songs that proclaim how it is faster, neater, and sharper than ever before with its asynchronous APIs.

    Perl Festivity Level 2: Everyone is talking loudly -- sometimes to each other, and sometimes to nobody at all. Perl seems even better. Perl Monks are patiently explaining syntax and style to potted plants and other nearby objects. Around the piano people are feeling fun and flexible, just as programming in scripting languages used to be. Someone is crooning a bawdy ballad where a couple of inexperienced DOM and CSS selectors encounter a very supportive bundled development server.

    Perl Festivity Level 3: Monks are arguing violently and defrocking one another over nested do...until loops that bail on exceptions. People are gulping down other peoples' drinks, placing hors d'oeuvres in the upright piano to see what happens when the little hammers strike as everyone bawls "Got my Mojolicious workin' ... but it don't work on Python!" They have lost count of their drinks, and the world is harmonious with blissful adherence to modern interfaces and standards.

    Perl Festivity Level 4: All the guests, hors d'oeuvres smeared all over their naked bodies are performing a ritual dance around a burning heap of tables and chairs in celebration of postfix dereference syntax, subroutine signatures, new slice syntax and numerous optimizations. The piano is missing.

    ~~ with apology and deference to Dave Barry

    --
    <blink>down the rabbit hole</blink>