Slashdot Mirror

Catalyst http://www.catalystframework.org/ with perl - everything else are toys.

It is hard to explain the power to people still playing around with other tools. If Catalyst scares you, Dancer http://perldancer.org/ is an easy beginner step.

Catalyst doesn't force you into anything.
YOU decide how to do things.
YOU make your "best practices."
No limits.

These choices can be bad for people who like to be told what and how to code. If you'd listened, then you're probably using .NET something anyway.

"I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent."

It's a shame that this 'Osborne effect' has hung over Perl for the last decade. I wonder how Perl 5 would now be perceived if Perl 6 had been given a different name and announced as a research project into language development, rather than the next version of Perl? With better PR, Perl 5.10 could easily have been 'Perl 6'.

All this tends to obscure the quet evolution of Perl 5 programming into what 'chromatic' and others are calling 'Modern Perl', using an idiomatic style that takes full advantage of recent language features (some borrowed from Perl 6) and CPAN to write efficient and maintainable code:

http://www.modernperlbooks.com/
http://onyxneon.com/books/modern_perl/

As always, a lot of the most active development is happening outside the core language. Anyone interested in some of the directions Perl 5 is going in today ought to check out projects like these:

http://www.iinteractive.com/moose/
http://plackperl.org/
http://www.catalystframework.org/
http://mojolicio.us/

http://wiki.catalystframework.org/wiki/sitesrunningcatalyst

That's just those using Catalyst (a popular Perl based Model View Controller system) but if you glance down the list you are going to see some huge sites with big, big traffic loads. All new stuff, things launched within the past two/three years max. BBC iPlayer alone is one of the heaviest hit sites on the web, and that's Perl.

Actually you're wrong on the iPlayer comment. Yes, current iPlayer runs on Perl but the new one which will replace it does not. It is actually PHP web app instead (http://www.bbc.co.uk/blogs/bbcinternet/2010/05/introducing_the_all_new_bbc_ip.html), with Java thrown in for some services. So wonder what that says for Perl that a high volume site is moving away from Perl to PHP.
As far as I'm aware Perl is still used in parts of the new iPlayer site but it doesn't have the same major role as it did before.

There definitely are: http://wiki.catalystframework.org/wiki/sitesrunningcatalyst

And thats just those written in Catalyst (a Perl MVC web development framework). Thanks for giving us the benefit of the doubt?

http://wiki.catalystframework.org/wiki/sitesrunningcatalyst

That's just those using Catalyst (a popular Perl based Model View Controller system) but if you glance down the list you are going to see some huge sites with big, big traffic loads. All new stuff, things launched within the past two/three years max. BBC iPlayer alone is one of the heaviest hit sites on the web, and that's Perl.

So you are wrong in your guess that "80%" of Perl programmers are sysadmins writing cron jobs. Whoever modded you up should have done a bit of checking, because marking your opinion as insightful is highly inaccurate.

There have been several new Perl books written just for Catalyst in the past two years, so just because you are not finding anything new for Mason (which is probably not the framework of choice for the modern Perl programmer anyway) that is not much of an indicator. There's tons of FREE docs and examples for Perl in any case (http://search.cpan.org/)

As far as Google's lack of commitment to Perl, well, I'm sorry to hear about that, but that's one company. Google Appengine is a pretty small garden, and the Perl interpreter has trouble running under its confinement. To be honest, Python doesn't run everything under appengine either, you need to write code for appengine. I think getting PHP or other languages to run under it will be equally difficult.

If you want to program in Perl on the cloud you have a ton of options, such as EC2, Rackspace cloud and pretty much any cloud provider with an open system (not Appengines walled garden) Oh, and if you want a smarter search engine, trying http://duckduckgo.com/, which is written in Perl and I find more useful than Google search.

I realize that the Perl community needs to do a better job showing that we are not stuck in 1998, so I forgive your lack of knowledge in this matter. I do actually appreciate the opportunity to discuss it, since this is really the only way this perception problem with be solved. However I hope you can meet me halfway and do a bit of checking on modern Perl before you make such sweeping judgments again. Because to be honest this exact opinion you've expressed I've seen over and over again for several years, and it's totally different from what I see everyday, as a fulltime, highly paid Perl programmer for at least 15 years. Take a look at Moose (http://moose.perl.org/) if you think Perl's OO is lagging, or Plack (http://plackperl.org/) if you think Mason and mod_perl is all we have, for example. Our community is smart, diverse, highly active and strongly focused on the next 20 years of Perl.

John Napiorkowski

It seems like the current way to be hip in developer circles is to make fun of Perl.

I really want to understand this phenomenon as I doubt most of these people bashing Perl have never even seen any Perl code written in the last 4 years. Hell, I could bet that a lot of people have never seen any *real* Perl code at all.

Perl 5 is a modern language which has the features of other currently more trendy dynamic languages and more. We have modern web frameworks. We have robust database bindings and state-of-the-art ORM libraries. We have have a well-tested modern object-system with optional declarative syntax. Perl is used by several high profile sites which, at this point, everyone already knows (BBC, DuckDuckGo, Slashdot, etc).

Perl 6 is a different language but shares a lot of the common minds behind all these awesome Perl 5 tools. However, even if you don't like Perl 5 for whatever reason keep in mind that Rakudo Star is a completely different thing (as a matter of fact, the name "Perl 6" should probably be dropped in favor of Rakudo - to avoid all this cargo-cult).

I gave RoR a chance and evaluated it for a while

I applaud you for your 'I actually evaluated it' viewpoint.

Like you, I also had a looksie at both Ruby and RoR.

Loved ruby. Found RoR interesting but didn't like it much.... read on for why.

In short, I really like Ruby, the 'why the lucky stuff' tutorial was absolutely the most fun I've had learning a language in years. I was so enthused I evaluated rewriting significant parts of my business systems in ruby/RoR. So I looked at RoR.

RoR was OK ... some nice ideas I hadn't really been sat in front of and forced to stare at before ... but I'm sure they weren't new. After a few test projects, some things put me off using it.

First, I tend to shy away from code generation (vs. smarter code) as an affront to maintanability, except in very specific types of situations and I felt that RoR overuses this technique without obviously providing any other options.

Secondly, the whole 'define your data model in a text file' thing is pretty broken in my view. How many web based systems need to be moved from one database to another? How many times will the text file EXACTLY match the specification that is database-native? (Hint: This is NEVER a safe assumption, particularly across database versions, if your data model is nontrivial) It's OK if 90% of your projects are going to be 'the client has no idea of scalability required or target environment, yet somehow knows ruby is OK to use' ... but in other cases (almost all that I ever see), I would posit that the overhead and distance-from-the-grindstone you are building in to your codebase is actually counter-productive.

The final nail in the coffin for me was that language-native Unicode support was lacking in ruby at the time. I understand this is being or has been resolved with a later release, but I have not had time to go back to it.

the community can only follow the "hype" and treats the RoR dev team like deities, yet has no idea how to do certain things, how to properly structure and architect software, and responds with vitriol when asked about this.

RoR is a framework that provides quick results with certain types of qualities in a certain problem space. The qualities are relative (though rarely significant) machine-level inefficiency and in my view limited maintainability (too much code generation), The way it is marked, RoR appeals to the 'I'm a fairly inexperienced coder, probably in the west, using a Mac, and doing build, deploy, forget-style web agency type jobs for bread and butter' types. It's not a bad fit for such people.

So instead I stuck to what I know, and have been using Catalyst for my projects.

These days I would NEVER consider programming a web-based (I would almost say -- any complex transactional) system in perl. Whilst it is of course possible, and there are many successful perl-based websites, implementation language is not a design decision to be taken lightly, and perl is a tool less-suited to the web based system problem space than PHP. This shows in both usage stats and the job market. Learn something else.

Full disclosure on my background: perl (pretty damn fluent, CPAN author, have done a lot with the language - but not a fan of OO perl at all, and NEVER use it as a primary language for web systems), PHP (fluent, frequent since PHP3 - but not a fan of OO PHP at all), web (80% my focus since ... 2000 or so), interest in security, TCP/IP RFCs were my high school reading, also do Linux systems stuff, including embedded/diskless/virtualisation, used *BSD a bit, OK javascript, some Java/C/whatever, own my own international business operational in six languages (only one of these being latin-based) including custom integration of voice/fax/telephony/sms/email/web and multicurrency billing/accounting so I believe I can claim to understand a little about the business side of software - maintainability, reliability, security.

I gave RoR a chance and evaluated it for a while, and while RoR isn't bad, it's community is absolutely terrible. Help is hard to get, and more often than not a simple question leads to 5 people falling over eachother to call you stupid in various degrees, yet they are unable to actually offer any help. A large majority (from what I've seen) of the community can only follow the "hype" and treats the RoR dev team like deities, yet has no idea how to do certain things, how to properly structure and architect software, and responds with vitriol when asked about this.

So instead I stuck to what I know, and have been using Catalyst for my projects. That community is awesome, helpful, knowledgeable and not afraid to help out even for dumb questions.

In short:
RoR: loud, obnoxious, hype followers
Catalyst: quiet, friendly, no hype anywhere (which unfortunately means Catalyst is a bit in the shadows)

Just my 2 cents.

You mean like Mason? Possibly you're looking for something more like Catalyst?

These things have been available for Perl for a long time.

...is backwards compatibility. In general, you can take some obscure piece of code that someone wrote almost a decade ago, and it will run on your modern Perl system. Unfortunately, people then take those obscure snippets of code, and try to learn from them. They may have been the best way to do things eight years ago, but they're certainly not now.

As such, one of the hardest problems with Perl is education of new techniques. Too many systems still use CGI.pm when they could use Catalyst. They use some home-grown system of objects, when they could be using Moose. They put up with outdated techniques when Perl::Critic would find them in a heartbeat.

So, if everyone learnt the new techniques, we'd be fine, right? Unfortunately, it's not that simple. I teach Perl for a job, it's still an incredibly popular language here in Australia. But because that old code still works, I still need to teach people how to understand it, even if I then proceed to teach them better ways so they can avoid it. That increases cognitive workload, and there's only so much one can fit into a fresh brain during its first contact with a language.

Perl still remains the language of choice for writing minesweeper bots.

RoR is (was?) popular because it brought a lot of great ideas to the table, with a decent implementation. Those ideas have by now been stolen/copied by several other frameworks in your language of choice.

If you know PHP, check out http://www.cakephp.org/
If you know perl, check out http://www.catalystframework.org/

At my company, we have switching from legacy/inhouse PHP to cakePHP for new projects, and the fact of using a decent/modern MVC framework has already more than paid for the learning curve by saving weeks of development time.

Not only is it now possible to hire people who know the specific framework that we're using, but I know that the development patterns I'm using now can easily be transferred to any of the other Rails-knockoff frameworks, even across languages.

This seems as good a place as any to let interested people know about the 2007 Catalyst Advent Calendar. 24 days of how to work with catalyst. This year things are getting pretty sophisticated, with the first two entries dealing with Catalyst/YUI integration, including how to build a CRUD app with catalyst and YUI.

Catalyst, Baby!

http://dev.catalystframework.org/

http://www.catalystframework.org/

Catalyst is mature, activly supported, and being used in a lot of locations. (Sixapart's Vox being the largest example)

So, no, we haven't been pushed out of the web market by other lauguages. Thanks for asking. =)

(There's Jifty too, but I have no person experience with it)

http://www.catalystframework.org

I find it strange that nobody yet has given a reference to Catalyst, the best MVC framework for Perl. From people that have tried both (not me), it is said to be the equivalent of RoR for Perl. I can't back that because I'm a perl monk and I don't have time for yet another language (what for, when you have already tried the best language ? ;-)

Application skeleton and database CRUD in 30 seconds (measured!!!). Try it.

Did you read the book? His experience is modeled off Subversion (he wrote it). Subversion is pretty successful.

As an aside, we run Catalyst the same way (but with a little bit less bureaucracy, and fewer core contributers).

I'm currently writing an app with Catalyst. ("Currently" as in "paused to look something up while working on it and spotted this story".) It's based on Perl and usually combined with Template Toolkit, which uses a mini-language to describe templates. I definitely recommend it—it's about the cleanest way I've found to create a dynamic site.

Catalyst is designed to keep the different parts of your app separate from each other, unlike PHP which tends to encourage mixing presentation code with application logic. (You can write PHP apps nearly as cleanly as Catalyst apps, but Catalyst helps you do it while PHP makes it fairly inconvenient.) It basically carves your site into three big chunks—Model, which talks to the database; View, which talks to the web browser; and Controller, which bridges the other two. Typically you'll need a model for each database, a controller for each section of the site, and a view for each method used to access the site (HTML, RSS, web service, PDF...). Models are usually auto-generated, and the glue code for the views is written for you, so you basically just have to write your templates and application logic.

Because it's based on Perl, you automatically get a few bonus security features, like taint checking (which tracks user-provided data to ensure you don't use it in unsafe ways) and database libraries that use placeholders. Catalyst apps almost never use raw SQL either (they use libraries that create objects to represent the tables and records), so injection attacks are virtually impossible.

If you don't want to use Perl, Ruby on Rails is fairly similar, and I know a lot of people swear by it; Ruby has a shallower learning curve as well. It doesn't have the libraries or userbase Perl does, though.

I know you're only joking, but you might be surprised to see what the 'perl hippies' are working on now.

Another, more recent sollution [sic] would be Ruby on Rails, which has some realy niffty [sic] features.

Another, more recent sollution [sic] would be Ruby on Rails, which has some realy niffty [sic] features.

Does PHP now handle Unicode (UTF-8) text transparently in all its built-in functions? You know, like Perl 5.8, coincidentally released in 2002.

Yup.

Quote:

When you manipulate (trim, split, splice, etc.) strings encoded in a multibyte encoding, you need to use special functions...

mbstring is a non-default extension...

It is not recommended to use the function overloading option in the per-directory context, because it's not confirmed yet to be stable enough in a production environment and may lead to undefined behaviour.

Yeah, that sounds like something I want to use.

For comparison, here is my experience using Perl. I'm currently coding my own Wiki engine using a Perl framework called Catalyst. Everything's going pretty well. I recently wondered about unicode content. I thought I would at least need to load the 'utf8' module in some places. Nope. I didn't have to do a thing. I copied the list of languages at the bottom of the English Wikipedia's main page and pasted it into a test page. It just worked. I did not need to do anything to be able to use UTF-8 encoded Unicode text. No extra modules to load (it turns out the 'utf8' module is for including UTF-8 text in the Perl code itself) and certainly no recompiling of the interpreter. It displayed correctly, my wiki formatter full of regular expressions worked correctly, the 'diff' display using a third-party module worked correctly.

That's what I call "handling Unicode (UTF-8) text transparently in all its built-in functions". PHP's clumsy solutions simply don't compare.

Also, they forgot about EditGrid, which is based on Gnumeric and web-ified with Catalyst.

PHP, like all scripting languages, suffers from having to parse all script files each time a page is displayed.

Speak for yourself, PHP weenie. My Perl code is parsed and "compiled" only when I restart the FastCGI handler(s) for my Catalyst web app(s). My templates are (I'm sure) parsed on each invocation though. The situation is probably similar for other real scripting languages e.g Python and Ruby.

... or you could use http://www.catalystframework.org/, which has utf8 and internationalization support built in and tested from the core upwards and due to being written in perl can talk to pretty much anything you can find a CPAN module for (and via Inline::Java, ::Python etc. pretty much anything you can't, too).

It is no longer limited to subversion actually - there are already plugins for mercurial, perforce and more (see http://projects.edgewall.com/trac/wiki/VersioningS ystemBackend).

Some other open-source projects that use Trac include adium, catalyst, ruby on rails and madwifi - see http://projects.edgewall.com/trac/wiki/TracUsers for more.

Perl still manages to reliably not suck. Catalyst can do magic scaffolding etc..., but lets you get as down and dirty as you want, and scaffolding isn't required. It also has the distinct advantage over other web frameworks in that it can use anything in the CPAN. It doesn't tell you how to do things, just makes them simpler.