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."
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."
I kept thinking "I am the very model of a modern Major Perl Framework..."
Quo usque tandem abutere, Nimbus, patientia nostra?
Color me surprised.
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
There is no "i" (nor "me") in asynchronous.
Maybe one day even Slashdot will get UTF-8 support.
One day.
Any decade now.
I was using perl before it was cool.
(I figured a fanboi submission required a hipster response)
#DeleteChrome
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.
...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?
Objective-C is older and it's usually considered as fairly modern.
Ok, I know I'll get modded down to oblivion for this, but my first thought on reading the headline was "Modern Perl Web Framework, isn't that an oxymoron?" Any others think that as a reflex at first too? Even if you don't really believe it?
I know I used to love Perl, but that was a long time ago...
Hmm, the humour and sarcasm seem to have been be lost on you.
http://handsonaswegrow.com/wp-...
Not exactly, but I like the picture.
The problem isn't that perl is old. The problem is that perl reads (and writes) like encrypted sanskrit and is just generally weird in its approach to everything.
Once you've invested a great deal of time learning it, and its APIs, it's a big deal to change, because you're effective in it... but, speaking from personal experience, after years of perl-ing, I tried something else, and what a revelation it was. Not everyone is willing to put in the kind of effort it takes, and familiarity itself can make nice seem wrongish after years of coding otherwise.
For new entries to the scripting language world, the only really good reason to learn perl is to maintain legacy code. Updates can't fix it -- the very language is a mess. And the fact is, there are some really terrific scripting languages out there now. There's little -- or no -- need to subject one's self to perl.
I've fallen off your lawn, and I can't get up.
Was this during Perl's heyday, when it was ... shudder... popular? The popular language of the day always suffers from very poor programmers making very bad decisions.
I dunno, the authors of Go seem to be making some pretty good decisions so far.
Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
Welcome back into the Middle Age.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Good choice because, goodness knows, you can only copy/paste Perl...
I live ze unknown. I love ze unknown. I am ze unknown.
If you are too stupid and unskilled to sanitize your input, you shouldn't be coding in ANY language.
Gee, if that was the criteria, I'd be banning Java at work. Because I've seen first-hand a number of Java devs writing absolutely stupid things resulting in a heap of vulnerabilities.
The reality is that you get a bunch of stupid developers, and it doesn't matter what language you put in front of them, they're going to write stupid code. The people who've worked under me in perl don't get the opportunity to write code that dumb because a) I provide a saner framework work in where those gotchas are centralised into common functions and objects, and b) I code review everything that goes in until they acquire a better knowledge base to work from and then I do spot reviews and review anything they feel, with their now better experience, might be tricky and should get extra eyes.
I don't care what language you're working in. If you don't realise that calling the shell with special characters that you didn't know you had will cause problems, it's the developer at fault, not the language. I don't care if it's cmd = "do-stuff " + tainted_value; Process p = java.lang.Runtime.exec(cmd); or my $cmd = "do-stuff $tainted_value"; my $rc = system($cmd);, that's going to result in broken code. If you don't realise that doing the same thing with SQL is going to cause problems, you shouldn't be doing SQL. Or running a subprocess, waiting for it to exit, and THEN reading its stdout. These are all common things, in my experience, and most of them I've seen in Java code, though I do get to work with some nimwits in a different reporting chain using perl stupidly as well. I don't ascribe the bad code to the language, but to the bad developers. Maybe you should look, too, and you'd find it's your developers that are the problem, not the language.
The bad Java programmers don't wind up publiching to CPAN. The problem is not Perl itself, it's the astonishing array of complete crapware that lives at CPAN is is used without code review by every *new* Perl author. The sort of abuse of sense that occurred in the switchiover from mod_perl version 1 to mod_perl version 2 is happening every day, in dozens of projects, and it's death to stability.
A "new framework" won't fix this taking the "sudo cpan Module::Name" habit of building and installing the latest, unstable, incmpatible crap on the fly is the problem. And a "new framework" won't fix this unless it puts a bullet through the idea of "let's just grab and install the latest!!!" approach to software.
I've put that bullet through that approach.
I've grabbed the precise versions of everything that we're going to use, checked into our version control system, complete with a full build-from-scratch setup that will build perl from source, with the exact options we need (or at least the exact same options every time, not sure if we need threading, for example), and the precise list of CPAN modules that we are using, along with standard patches to said modules where required (some of them don't support AIX as well as we need). Upgrading a module will require a degree of regression testing, etc.. And all developers will use exactly the right levels of everything as the level that is going into production.
I'm a huge fan of CPAN. It has issues, such as some crap code, but yet it remains one of Perl's greatest strengths. Like anything else worth having, it provides sufficient rope to hang yourself with, so you do have to be careful, putting the onus back on the developer to find a mode that works for them. And yet, to fulfill corporate requirements, I'm using precise levels of code. There's no reason why you can't have the best of both worlds.
No I don't see any character.
a) No they're not.
b) (S)he meant programmers using the language, not the language designers.
Someone please mod parent up...
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>
Cool, but meanwhile nearly everyone else has solved this problem with some sort of standardized dependency framework, while you are using homebrew glue.
I was very active back in the early days of 5.0 development. I fought for this and lost.
I always struggled with the non-nonsensical @{} ${} ..... style. It was difficult to mentally process. Long chains of dereferencing would be especially complicated.
I'm very pleased to see this finally make it in.
chennai local news Karan Johar buys rights of a hit Pakistani number and gets Arijit Singh to rework it.The music of their last outing together made it to the list of chartbusters (Remember tamil cinema news
tamilnadu political news The next schedule of Mahesh Babu-Tamannaah starrer Aagadu will commence its shooting at Ramoji Film City, Hyderabad. Director Sreenu Vaitla is currently filming scenes on the lead pair and support
I don't ascribe the bad code to the language, but to the bad developers.
Unfortunately, Perl limits even good developers.
The major problem I have with Perl is not its sometimes ugly syntax, but rather its limited mechanisms for enforcing code correctness at compile time. This means that many types of error can't be found until one runs a program. This in turn means one runs up against the classic combinatoric explosion problem associated with run time testing. Given that even the best developers have bad days, this can be a big problem.
Perl is a lot like Visual Basic, or spreadsheet languages, in this sense.
Languages such as Java, C#, C++, Ada, VHDL, SystemVerilog, and many others all provide a much stronger level of support for checking things at compile time. This can even be done to some extent in a really old language like C, with tools such as the mainstream lint tool, and the many lint extensions that are available or which can be readily written.
As a bonus, many of these mechanisms to exist to support compile time checking of code make reading other people's code easier (and with modern development tools, they also make modifying that code to help understand it easier).
With Perl, "use strict" gives you a little bit of this, but it really doesn't compare to what is possible in other languages. Even modern Perl extensions such as Moose are pretty limited in comparison to what can be done in other languages. In the final analysis making smart compilers and other tools for code checking depends on the type system the language implements, and Perl falls short.
I don't think Larry Wall understood this (if he had done his research, he would have, since Ada had been around for several years when Perl was created, and even then -- 1987 -- these issues were well understood), and I don't think most Perl programmers understand it either to this day.
Perl also has the problem that it's difficult to parse, so a coding team has to have pretty strict standards regarding language use if it's going to be developing code checking tools. Hence, the "there's more than one way to do it" concept in the design of the language actually creates a serious problem for users of the language, because it complicates the problem of parsing the language (and there's no built-in parser that can readily be customized for use in writing a code checking tool).
It would have been better to have strong type checking be the default, with a more limited syntax, then let the user relax the strictness when desired (sort of like using Java and Groovy together, getting the benefits of a scripting language when appropriate, but also getting the benefits of a well thought out language).
As a result of this issue, I prefer not to use Perl for anything more than 5-10 pages in length. In such a short program, it's not that bad to review the code, fully understand it, and test it. Within those limits, it's a useful tool.
I used to be a huge fan of C++.
All those negatives you cite seem to me to be advantages. Because when you know how to use them, they become powerful forces for good. Sure, there's plenty of room to shoot your foot off, but there are some things you can do in Perl that a stricter language wouldn't let you do.
I don't think Larry Wall understood this (if he had done his research, he would have, since Ada had been around for several years when Perl was created, and even then -- 1987 -- these issues were well understood), and I don't think most Perl programmers understand it either to this day.
Some people like static languages, and some people like dynamic languages. Dismissing people who don't share your preference with "I don't think they understand" is the height of arrogance.
I mostly lurk and seldom reply to anon.
But I'm compelled to say
Well Spoke, and thanks for the forethought.
Perl was the reason I started wrapping my brain around regular expressions. Later in the 90's I build complex backends using cgilib. Tried a few frameworks like mason..... I became a perlOphite for all the sentiments you expressed so well.
The ease of cpan, of quickly manipulating DBI tables, so many reasons why it, and its attitude,
always works for me. Off a CLI, wrapped up in a shell script, part of a larger pipe; I just cannot imagine using another interpreter as painlessly.
Specially for admin stuff and my personal libs of
files/data which require maintaining.
That said, were I a manager today I'd see the .... would have a better outcome from the
sense in concluding that python, ruby, a compiled
lang,
devs; despite my personal aversion for each of them. Enforcing Delimiters does not good code guarantee and makes editing others' code in vi more tedious (or macro'd). Maybe if I were an IDE
type of guy.
I found my time spent adopting/trying/using rails/passenger/gems/mongrel less warm-n-fuzzy
than squating in the cpan/perlmonkworld camp
I feel Perl epotimizes the LAMP stack, the finishing touch of what, for me, was a process
(mentioned earlier) of learning OS as much as CS
and appreciating the many ways to do one thing.
But not all programmers feel drawn to broader systems and from that narrower perspective more structure makes infinitely more sense.
For those who might say perl is a hackers language
I would heartily agree. Its where it's genius lies.
resist propaganda