From PHP to Perl - Should I, and how?

[salazar]

Heh, some of you may have seen me mucking around the chatterbox asking these questions, but I figured I'd give them a centralized home.

To start off, I've been working with PHP for awhile and have gotten pretty good at it. Which is nice, since all of what I do up to this point is web programming. However, I would like to do some GUI and command line programming at some point in time, which is what brought me to Perl (Perl can do GUI, right?).

My question is that I have some applications and classes, with maybe 1,600 lines of PHP code written. Is it worth it to drop everything, take time to learn Perl (I'm only at the baby steps right now), port that code over, and continue writing in Perl?

So I'm wondering about a couple of things specifically related to web development. Obviously it is possible (See: PerlMonks), but is it as easy and powerful as PHP? I ask this only because PHP was targeted specifically at the Web. Is there anything that you lose by using Perl instead of PHP?

I also have three general Perl questions:
1) Does it get complicated using lots of different modules? Is it hard to keep them updated?
2) Can somebody point me to a thread detailing how to import subs, like a library?
3) Have there been any problems or gotchas you have experienced or noticed which consistently occur amongst converts?

I really, really appreciate this. I look forward to learning Perl, PerlMonks has been great so far :-).

---

Update, 3/9, 7:00 PM EST:
New question. Can Perl handle AJAX? It would make sense for AJAX to work the same as it would with PHP (JavaScript sends a request for a URI, and then utilizes any output from that page), but I wanted to make sure.

---

Update, 3/9, 10:00 PM EST:
Another new question. Inspired by responses I've received, I decided to give Catalyst a try. It looks cool, though I'm having trouble getting started with it. First, the search for "Catalyst" returns 900+ results on CPAN. Do I need to install each one of these? Is there a way to install modules other than downloading the tarballs and compiling them? Second - the documentation references a file named "catalyst.pl", but I'm not sure where that comes from. Any beginners guides out there for starting with Catalyst? Help appreciated!

---

Update, 3/0, 4:30 PM EST:
WOW. I've really just started to look around CPAN's module collection. Very nice, I can see I'll be doing a lot less coding than I originally thought, provided I can put down my dislike of using other people's code, of course ;-) . Any tips on finding modules you need?

[sundialsvc4]

All I can say is, I know dozens of programming languages but I have never been “a convert.”

It is definitely worth your time to learn Perl and to seek to do it well. Proudly put on your neophyte's robes and feel welcomed among the Esteemed Monks who regularly visit here. Never feel that you must in any way “discount” your growing professional experience with PHP, and never expect anyone around here to think negatively of it. “Most of us use PHP too.” You have nothing to prove, nor to defend, here.

Perl is very different from PHP, in the sense that “all of what PHP can do” is only a portion of what Perl can do. Furthermore, whereas PHP by-design incorporates much of its functionality directly into the PHP executable itself, Perl by-design does not. Both of these approaches are “very defensible software design decisions,” just different ones.

There really isn't a conflict here... you're not changing religions. Many of the designers of the PHP language system are “regulars” here. If you study the list of people who have contributed meaningfully to both systems, you find a lot of the same names. The ongoing commercial success of what they've done cannot be denied. Happily, you generally do not find anyone here trying to “preach the gospel” in either direction. (I find that very refreshing.)

Fair warning:   the more you learn about Perl, the more you'll use it. You'll find yourself consciously steering the “big” projects away from PHP and towards Perl. This will especially start happening when you've run into your first project that unexpectedly ran into the rocks of PHP's inherent (and, yes, deliberate, legitimate) design boundaries.

One of those boundaries is “big-core vs. little-core.” (That's just my term.) PHP has a big set of core-features that are all hard-coded into the language. Fortunately, the “one way to do it” that they've chosen to integrate into the PHP language is a pretty-good selection. But hang around Perl for any length of time and you'll see continuous reference to this mantra:   TMTOWTDI = There's More Than One Way To Do It. At first, it sounds like heresy... at best, a calling-card to bad design. But it doesn't work out that way. The core of Perl is relatively small, and upon that small framework is built a fairly-endless cascade of CPAN modules. Some of them, like DBIx::Class and Template::Toolkit, represent an abstraction of the functions that are elsewhere available. For these you will find not just this one but half-a-dozen or more alternate implementations. Meanwhile, you will also find packages like Moose that very fundamentally change the language itself. (And, in the spirit of TMTOWTDI, it's being chased right along by a little Mouse.)

“You won't find that in PHP,” and really, you can't find that in PHP. The flip-side, of course, is that for whatever you are doing now, you might well say that, “but I have utterly no use for that in PHP!” And you are absolutely right ... live long and prosper ... until. One day, you hit the wall of PHP, and you can't readily go beyond it, and when you try to do so ... (hell, you have to get this thing to work somehow!) ... you know in your gut that you are now generating horrible cruft that you (or your successor) will have to maintain. You can't go back and change the tens of thousands of lines that you already did. You can't even argue in any way that the implementation and design of PHP is in any way “wrong.” But you “suddenly ran out of tool,” and you do remember that experience.

[salazar]

Ok. So I'm picking up two main ideas from this post, let me know if I'm mistaken.

1. PHP was designed to be easier to pick up at first
2. PHP is stuck within a certain boundary, which is nearly impossible to get out of - possibly a result of the first point?

[sundialsvc4]

No, I don't think that this assessment is a fair representation of my intent. I will never desparage PHP. In fact, I will always admire it.

Like any tool, “PHP is what it is.” And it's designed to be what it is. It can do a huge number of things and it is very popular. Lots of hosting companies support it, to the point that their tech-support zombies will look at you strangely if you refer to anything else. So it must be doing something right . . . at least today.

Nearly everything is “impossible to get out of,” such that once a project starts in a given direction, it basically cannot switch gears later. Once you're doing PHP, that project is always going to be in PHP. The same is true of Perl, o’course, but here is where the “small core” philosophy becomes useful:   you can change virtually everything about Perl and still be in Perl. It's not, as we say, “monolithic.”

If a great number of PHP projects had hit-the-rocks, then PHP by now would have faded away as an academic curiosity. Software folks do not continue to use tools that have substantially failed them. But... when I look, say, five years down the road when I think that most of today's “web” applications will be targeted instead at “iPhones and god-knows-what-else,” well, it's just me but... I don't really see PHP there. I do see Perl there.

You see, he said, rambling on senselessly, there is a very fundamental difference of philosophy here, and that is:   in the world of PHP, code and HTML are designed to be inter-mixed. PHP is specifically designed that way. It's one of PHP's advantages, at least in some people's eyes (though not mine). It is a deliberate and conscious design decision for which its designers do not (and need not) apologize. But now consider, what's going to happen when (amazing as it sounds now...) HTML is no longer part of the picture? And what if we (as usual...) don't quite know what's going to replace it? I'm not saying that it will happen that way, but I think it will, and what if it does? “You can't pick your winner until after the race is run, but nevertheless you must place your bets ahead of time.” Is a language that by-design meshes code with what is no longer “the presentation of choice” going to continue to be thought of as a winning horse? Is its “advantage” still there? Only time will tell. And... I don't know either! All I'm saying is that I do wonder...

PHP will change. Of course it will. And the legacy-systems we have created will live on. But someone created “object-oriented COBOL,” too... (Hmmm, ADD 1 TO COBOL GIVING COBOL.) ... And it didn't do any good. A big language has a much harder time surviving a sea-change.

[webfiend]

Yes, you should learn Perl, for the same reason you should add any language to your toolkit. It gets easier to clearly express your intent in code as you learn the idioms common across different languages. You also get an idea for what concepts are easier to express in a particular language, which will give you whole new ideas for how to organize a project. I initially learned Perl because of how much easier it was to express regular expressions compared to PHP, and those regular expressions changed how I looked at text manipulation for a very long time indeed. Once I got the hang for coding in Perl, everything including GUI and Web development became much easier and definitely more powerful for me than in PHP. Your mileage may vary, of course.

You don't lose anything by using Perl instead of PHP, but fewer libraries are effectively built-in to the language. Database handling and a bewildering assortment of Web-specific features are available via external libraries on CPAN.

Now on to your specific questions:

1. It depends on the modules and how much you want to know right now. While you're getting started, use <Module> is all you need to know. Later you'll mess with export lists and so forth. Generally speaking, installation and updating of modules is handled via the cpan shell. cpan install <module> and cpan upgrade will do all of the dirty work while you sip your coffee and answer emails. ppm is available if you are using ActivePerl, and it follows a similar usage pattern.
2. Look at Tutorials, and in particular Including files. Also check out perlmod when you're curious to look at the gory details.
3. Sure, but they tend to vary from one user to the next. My gotcha was learning that I didn't have to learn every bit of Perl to start writing useful code. Start simple and improve your code with new idioms as you learn them. Also, the greatest way to answer most questions is TIAS: Try It And See. Like PHP, Perl encourages experimentation.

Go ahead and learn Perl. It's always worth your time to expand your knowledge.

[gwadej]

While several of the other monks have answered your explicit questions. There's one potentially bad idea lurking in your original post.

Is it worth it to drop everything, take time to learn Perl, port that code over, and continue writing in Perl?

Is there any reason why you would need to? If code is working in PHP and you don't have an explicit need to change it, why change?

When learning a new language, it is often better to start off writing small pieces of code or tools than porting some critical (or even just working) code to the new language. Instead of a rewrite,

• Write a tool to make your life easier.
• Make a non-performance critical CGI script to test some ideas.
• Play with a templating system to get some ideas.

Often learning a new language will force you to think about your primary language (and programming) differently. Once you get comfortable with the new language, you may see places where you could do a better job in the new language than in the old one. That is the time to consider building more production code in the new language.

Several times in my career, I've seen someone come to the conclusion that a system should be re-written in a new language to improve the system. I can't think of a single time I've seen that go as planned. Often the new system turns out worse, because the programmers don't know the new language as well as they did the old one. Sometimes this ends up souring them on the new language forever.

IMNSHO, you should definitely learn Perl. If possible, you should also make use of Perl where it fits with your other goals. You should probably not rewrite a significant chunk of functionality unless you have a really good reason.

[salazar]

Thanks. Right now, the bulk of what I have done is in the form of a script which maintains state, and some good ideas for what I want the site to be like.

That's really why I was considering rewriting it, because if I'm going to be doing any web work with Perl, I'm going to want to have some scripts set up to authenticate the user nicely, load his information from the database, log his online presence, etc.

Would you suggest, then, that I continue with the site I am building in PHP, and play with Perl on the side -- then, when the time comes, port it over if I see a significant reason?

[gwadej]

There are CPAN modules to do some of what you are talking about: CGI::Session, CGI::Session::Auth, CGI::Auth::Basic, Apache::Session (I haven't used any of these, so don't take this as a recommendation for a particular module.)

If a couple of CPAN modules replace much of what you want to do, it might be worth changing. In general, though there should be some functionality that is unique to your site. That is what's risky to convert.

It also depends, of course, on the site. If this is a personal project and no one but you is depending on it. Your risk is lower and you might want to experiment. If your job is riding on the site or lots of people are depending on it, I would take the lower-risk approach I mentioned.

Like any other part of programming, these kinds of decisions are not black and white. They involve trade offs. If I had to decide between PHP and Perl for a new site, I'd pick Perl because I know it better. If I had to take an existing site in PHP and either fix it or re-write it in Perl, I'd bite my tongue and work in PHP (probably learning more PHP in the process), because that is the lower risk path.

The main point of my previous post was that you don't have to rewrite everything to get some of the benefits of using another language. More exposure to different types of programming and different languages usually improves your programming in all languages and projects you work on.

I have actually gained a lot of benefit from Perl in jobs where we were required to work in other languages. I have used Perl for testing, data generation, code generators, and a host of little tools to make my development go faster.

[sundialsvc4]

Heh... the experience of learning a new language also transforms your future work in the languages that you already know! It's how you grow in this business... and there's no replacing it.

And the “gurus” who are out there producing “PHP itself” ... do they know? You bet they do! That's the beauty of (and the endless allure of...) this business as a career:   you always feel that you are lucky to be getting paid for doing this. And yet, the digital computer is always your master; never truly your slave.

You now recognize the need to add another powerful tool to your personal tool-belt. Does that, therefore, provide an adequate (business|financial|technical|career) justification to scrap what you have already done? Ditto the expertise you have already acquired? N-O-!!

Never forget the “FISI principle”:   F**k It, Ship It!   :-D

At the end of the (business...) day, “what is done is done, and by the way, it's paying the freight.” What you do in the future is an entirely separate decision.

[oko1]

Is there anything that you lose by using Perl instead of PHP?

Let me preface this by saying that I'm pretty familiar with PHP; in fact, I've taught it professionally. I've also been working with Perl for a number of years; in fact, that's what I started with, while PHP (like a number of other languages) is something I picked up at a job where it was needed.

Now, as to what you lose: unresolved (and unresolvable) bugs in standard PHP functions would have to be #1, followed closely by the long-standing vulnerabilities at #2. You'd also be losing developers who appear to be deaf to the community that actually uses the language. You'd lose the security "add-ons" that protect the language from itself. Gone is the extraordinary clumsiness in handling variables more complex than a scalar, and inside-out weirdness in scoping variables. You'd lose the "ceiling" of PHP: once past a certain (low) level of code complexity, PHP just runs out of steam and can't go any further, while Perl has not such limitation (no blame here, really; PHP is intended to be a presentation-only language with minimal utility outside of that, but people try to push it way beyond that.) There's a bunch of other things, mostly annoyances, that would be gone.

As to positive bits - not much. Perl doesn't have anything quite as convenient as php.net's function lookup (e.g., http://php.net/trim for the 'trim' function) - but you'll have built-in documentation instead. It doesn't have the very nice "include/require" facility - which, in PHP, is (ab)used to create spaghetti code as often as not. But you can get all of those things, and much more, while still retaining all the goodies that Perl has, by learning one of the many templating systems available under Perl. This allows you to separate the presentation from the code - and you'll be amazed at how much clearer and easier this makes large projects.

I also have three general Perl questions: 1) Does it get complicated using lots of different modules? Is it hard to keep them updated? 2) Can somebody point me to a thread detailing how to import subs, like a library? 3) Have there been any problems or gotchas you have experienced or noticed which consistently occur amongst converts?

Modules, once you've learned the two basic styles (functional and object-oriented) are easy; when you look at the docs that come with it, the first thing that you'll (almost) inevitably see is an example of code using that module. Steal it. :) As to installing them, keeping them updated, and so on, the CPAN module (already installed with your Perl) makes that trivial.

How to import subs is part of the standard Perl documentation: just type "perldoc perlmod" at your command line, and you'll have a document describing all the semantics of modules, etc. For a general overview of the docs, see "perldoc perl".

For gotchas - not just for PHP, but for people who have experience in other languages who are just starting to explore Perl - I'd suggest checking out "perldoc perltrap". Well worth reading for the contrast, and as a reminder.

All in all, I think you may find Perl a rather liberating experience. The only way I can judge that, having started from Perl, is that working with PHP feels very constrictive to me these days...

[eff_i_g]

PHP was where I began programming, but Perl has won my heart. (This contrast may be helpful.)

I prefer Perl for the syntax, community, modules, and many others reasons that escape me at the moment :)

Regarding your first question: I think modules make Perl easier in many respects. I get frustrated when I cannot find many standards—modules—in PHP, and folks begin reinventing the wheel because a tool does not exist, or, if it does, it's subpar, etc.

P.S. There are some learning resources here: http://learn.perl.org.

[salazar]

Many thanks for the information, many more for the links. The library on learn.perl.org will prove extremely valuable, I am sure.

[slacker]

The answer to your slightly hidden question:
Perl can do GUI, right?
Yes it can!
Perl Gui Programming

[Lawliet]

See: zentara's code contributions.

[Boldra]

Let's be honest, Perl really doesn't do GUI very well.

There are few GUI builders available, and none of them are particularly good. vptk crashes, and Loft doesn't generate code. There's a reason why a lot of the GUI code hasn't recieved an update in years, and it's not "it's finished and it works perfectly".

[webfiend]

I'm not saying you're wrong, but:

Toolkit	Last Updated
Gtk2	13 Feb 2009
QtGui	4 Feb 2008
Tk	18 Dec 2007
Win32::GUI	13 Feb 2008
Wx	6 Dec 2008

Are there issues with some of these? Yes. I use Tk and Gtk2, and those both work very well for me. Qt gave me issues when I tried to install it. I'm on Linux, so I can't speak for Win32::GUI. Could these libraries be updated more frequently? Sure, except maybe Gtk2. But years? Not exactly.

Builders aren't really my thing, but Gtk2::GladeXML allows Perl Gtk2 apps to consume Glade XML files.

Yes, there's a reason why GUI code hasn't been updated as much as we would like. It's because people are working on these projects in their spare time. It's because Web gets all the glory right now for most new projects - in any language, really. It's because there's no point improving the Perl GUI libraries since everybody already knows "Perl really doesn't do GUI very well."

I'm not saying you're wrong on every point, but you're not exactly right either.

[Lawliet]

I do suggest you learn Perl. (It would not hurt to forget PHP, too :P.)

I must warn you that writing CGI programs will be a little less convenient than PHP, but it will pay off in the long run (the larger the project, the larger the pay off). I find writing a small website in PHP easier than Perl (PHP was built for that stuff, right?).

Regarding module usage: installing them can occasionally be painful (see: PerlMagick) but for the most part it is an easy one-liner in your terminal. Updating is the same.

And, to top it off, I present my favorite reason for learning Perl: Perl in Latin.

[salazar]

What are some of the payoffs? Can you (or anybody, really) give specific examples as to what the benefits of using Perl as CGI as a replacement for PHP would be? Where is the "break even point" for when a project becomes worth doing in Perl?

[mr_mischief]

The break-even point will vary among programmers. It will even for one programmer over time as you gain familiarity with both languages and the best practices for using both languages.

My rule of thumb these days for choosing between PHP and Perl is that if I find a well-designed, secure, fully functional open source project written in PHP for which there is no Perl equivalent, I'll customize the PHP project. If the available starting points are equivalent or I'm writing from scratch in either language, I always choose Perl over PHP. I learned Perl first and then PHP specifically to leverage existing code, so perhaps that has something to do with it.

Sometimes I choose other languages over Perl, too. Where a language is implemented often has a big influence. Languages available on the client side of a web application, like JavaScript in the browser, ActionScript in a Flash client, or haXe (which can target either of those) are one example. Many programs use Python, some dialect of Lisp, or some dialect of Basic for plugins or automation scripting. The GIMP uses Lisp and OpenOffice.org uses what they call OOoBasic for example.

Most of my applications are web-based, but not all. Many involve more than one language. That's true for desktop apps, but especially true of web apps. Having Perl on the server and JavaScript on the client really isn't a bad combination.

I also use C, bash, Pascal, Forth, various forms of Basic, or Lisp for maintaining programs already written in those. I sometimes use C, Forth, or Lisp just to keep my hand in and teach myself more about programming with them, as I don't use them very often. Those skills are too handy to let atrophy.

[sundialsvc4]

I'd chime-in with three answers for that:   CPAN, CPAN, and finally, CPAN.

Where else could you find something like, oh, say, Image::Flight::Suborbital (or maybe Device::USB::MissileLauncher::RocketBaby, just for fun...) and you can put that into your to your “web” (sic...) application and with a little bit of straightforward coding, “it just works?”

You can start with a requirement to do almost anything at all and find CPAN modules which do it. (Including, by the way, CGI authentication and passwords...)

And throughout it all... TMTOWTDI. The problem with “there's only one way to do it” is that, eventually, you will bang into that. No matter how good “that one way” might be, nor to how many people, if you do run into a limitation, you won't be able to fix the problem within that language.

Try this link: Catalyst. On the one hand, yes, “Catalyst is a web framework.” But on the other hand, you are looking at a list of (today) 906 links, and all of them are “real.” You say that you'd like to incorporate XML RPC-calls neatly into your app? It's there. Oh... you say you don't prefer Catalyst? Try: CGI::Application or Mojo or Jifty or ... ...

Notice: you are still in Perl. So, whether your favorite pasttime is “a web application” or sub-orbital flight paths, or maybe just a rocket-baby, you haven't left Perl.

And that is “what all the fuss is about.”   :-D

[Lawliet]

The top benefits for me are modules. The template modules along with the CGI modules (and all the other various ones for databases, servers, etc.) are a huge pay off. That's not really a specific answer, though (sorry).

The "break even point" is hard to estimate. It will be higher for you than it is me due your larger knowledge of PHP and lesser knowledge of Perl. A site for a small business might be better off written in PHP because of it's availability and ease-of-use. The gaming site that you wish to someday create might be better off written in Perl because it is easier to divide the code and faster to write because the hard parts are written for you (see: modules). (I do not want to be specific here due to possible counter-arguments that will be pointlessly accumulated in your node.)

[Anonymous Monk]

All comments have been positive, it's only fair to add some warnings.

Perl certainly can do everything php can do, and much better for many tasks (especially command line, batch processing, etc.). While it can do UI (Tk), but you don't learn perl to do UI. I think the biggest problem with perl, especially if you're using a shared host, is that it's not supported as much. Most things php are installed by default by most hosting packages, perl is not (I meant mod_perl, perl as command line and CGI usually is). You're right that getting all the package dependencies correctly can be a challenge, sometimes a big challenge, for example, the most popular framework Catalyst takes quite a bit of effort to install, and it's not included in most hosting plans.

I do feel you're in better company using perl, I found perl programmers tend to be better/more versatile programmers than PHP, and Java programmers.

[salazar]

I'm told that this should be a problem, though I'm yet to verify those claims ;-) .

[Your Mother]

I use them for many sites and run things under fastcgi, including Catalyst. They are very accommodating, friendly, and a nice place to be. Their uptime is not super though. So, I wouldn't put a serious business or client there. To get unlimited domains, fastcgi, ssh, svn, mysql, etc for $7-10/month is really quite good and worth the hour or two (or sometimes 10... like last month) of downtime that comes semi-annually.

[Your Mother]

Regarding your Ajax update Q, here's a little demo script you can give a try: CGI/Ajax example: lookup a value when a field is filled in. Any language can do Ajax (it's just communicating back and forth over HTTP still). Perl excels at it and the JSON::XS package is one of the fastest, nicest data serializers out there; I prefer Ajax with JSON over XML but anything works.

[soliplaya]

You might want to get "Catalyst" by Jonathan Rockway, ISBN 978-1-847190-95-6 Also maybe read up on the Template::Toolkit module.
As for "importing" a perl library (called "modules" in Perl linguo), not very difficult : - find it on CPAN (http://kobesearch.cpan.org/) - install it - in your program, add a "use my::module;" line. That's all there is to it (well, almost ;-) ).
The on-line documentation for most perl modules is also excellent, and a really good source of information about the general theme the module is about. I recommend it even to people who have no intention of ever using Perl.

[Anonymous Monk]

++ on Template Toolkit. That's a big reason my company hasn't moved to something else (We're a fortune 500 that uses perl internally for almost everything). CPAN is another - being able to install and update libraries is great. We use CGI::Application instead of Catalyst, and I'd probably suggest it instead of catalyst for someone starting out, but both are perfectly capable.

[sundialsvc4]

Say... does that mean you're hiring?   Contact me...  :-D

Actually, I don't have any Catalyst apps out there right now, either. I quoted it because it's got a very large and very diverse list of add-ons right now in CPAN. A very good demonstration of just how much you can do, within one framework, and still be totally “within Perl,” and “within just one (of many) framework(s) within Perl.”

I can't think of a better demonstration against:   “this is the one-and-only PHP, and therefore all we've got to work with is this one-size-fits-all, so we gotta figure out a way to make this thing work somehow.”

[salazar]

Thanks for pointing that out, I'll be sure to look at that as well. I was enticed by the 906 results on CPAN ;-).

[mwah]

Hello salazar

Have there been any problems or gotchas you have experienced or noticed which consistently occur amongst converts?

Only one thing.

If you are used to the PHP way, you may get an almost 1:1 transition in Web projects using HTML::Mason.

• Mason Headquarter
• Mason Book
• Mason on CPAN

Mason allows you (doesn't force you) to intersperse your HTML with stuff like

 [some.html]

    ...
   <table class="someclass">
%   my $counter = 1;     
%   foreach my $pr (@projects) {
%     my $rowcolor = ++$counter & 1 ? $color{DARK} : $color{LIGHT};
      <tr class="tablefont" bgcolor="<% $bgcol %>">
        <td> <% $pr->{topic} %>:</td>
        <td> <% $pr->{link} %> </td>
      </tr>
%   } 
    </table>
    ...

which is almost a PHP idiom (in contrast to the "smarty" way ;-)

And, you may implement catalyst-like controller logic right into the directory it belongs to (dhandler)

Regards

mwa

[salazar]

Sounds cool, and definitely something which will ease my transition, thanks.

So... what are the differences between using, say CGI::Application and HTML::Mason? I'm guessing it has to do with code separation?

[mwah]

what are the differences between using, say CGI::Application and HTML::Mason? I'm guessing it has to do with code separation?

I didn't do CGI::Application so far (should I give it a try?) - but envision it as a all-or-nothing solution for a given web project - whereas Mason is conceptually a lightweight thing close to PHP or JSP and can even be used as an additional templating system for big ships like Catalyst sites.

see: Comparison

Another thing: I use both, PHP and Perl (and several other tools too) - and I think PHP *is* an appropriate solution for most small Web projects where the client is hosted on a cheap server (running *only* PHP, of course). Another Comparison (register w/fantasy name to download ;-).

Regards

mwa

[sundialsvc4]

Any decision to “scrap 1,600 lines of” anything at all is not something to be taken lightly. It's hard to make an economic justification for scrapping.

But I just finished chatting on the folks with some folks who are trying to figure out what it would take to re-deploy their existing massive PHP app to a portable-phone platform, and I basically had to say:   “you're basically ‘on the wrong end of a sharp pointed threaded rod’ because all of your code is utterly and completely tied-in with your HTML.” Precisely the characteristic that is most fundamental to PHP's explicitly-chosen design ... is now biting them in the donkey. And it's really hard to think of “a five year old application” as now being “recalcitrant legacy code.” That's not much lifespan. And that's quite an engineering concern. Food for thought, definitely.

[ELISHEVA]

Not scrapping 1600 lines of code is also a decision not to be taken lightly.

On the systems I work with 1600 lines of code is a pinpoint, and this may also true for your large long term project: (didn't your original post say something about a games site? or am I confusing that with someone else?)

In a coding system, rewrites need to be understood in context. For example, changing 1600 lines of code that has 30K of lines of working production ready code dependent on it, is likely to be a big problem. The change won't just affect the 1600 lines, but also the 30,000 lines that depend on it and the modules that depend on the 30K and so on...

But fortunately you are still in early days, so if there is a time to rewrite is it probably now. I sense you are asking the right question: how much time will be saved or lost when you compare the time spent debugging and rewriting the 1600 lines to the time spent working around, teaching, documenting, extending and maintaining each version (PHP, Perl) of code? If the long-term savings are greater than the time spent rewriting, you have a win-win situation.

In your case there is another time factor to consider: if you choose some other learning experience: (a) will it be as targeted to the skills you really want to master in Perl (b) how much time will an alternate learning project on top of a PHP project take?

The downside of using this as a learning experience, is that it may be hard - any new language entails learning new concepts. Since you are trying to do something for real you may have to learn how to do something mind-bending when all you would really like to do is get the job done.

If your gut says ...

• you could do more with less by having the project in Perl
• being in Perl won't jeopardize your market (Perl isn't so friendly to shared hosting setups)
• long term costs would be less
• the deadline is under your control
• and you are the sort to persist until you master something even if the path gets rocky

then you have little to lose.

Best, beth

[doom]

A lot of people here are being much more polite than I am on this subject, so I'm jumping in -- but a lot of the people here know more about PHP than I do, so take me with several grains of your favorite sodium compound.

PHP has always struck me as a horrible language -- it's primary technical advantage is a smaller memory footprint than perl, but it gets that smaller footprint by not doing some very basic things, i.e. until very recently PHP has had no actual namespaces, which means no way to separate the behavior of components, which means mysterious bugs popping up as upgrades to component X and Y cause action-at-a-distance with component Z.

Yes, I know you can fake namespaces with naming conventions, but there are limits to how well that works (trust me on that one: I do some emacs lisp programming, I know what life is like without real component separation).

Further, I do have experience with using large projects written in PHP, and I've seen a definite pattern of "Let's use this, it's easy to setup", followed by constant buggy behavior that no one can seem to fix. It may be easy to get them setup, but it appears to be very hard to get them setup right.

Now, obviously there are places like Yahoo that live-and-die by PHP, and for them it seems to work... so it would seem that coding conventions, automated tests, and a large, aggressive QA department can make up for many gaps in a language... but before embracing something like PHP, I think you need to ask yourself if you have the resources of a Yahoo at your disposal.

All of this said: the big differences between languages are never really "technical" ones, but rather social ones (I don't think it's an accident that Python attracted the world's most annoying advocates...). PHP is a relatively young language that came in with the web 1.0 bubble, and had very little room to breath before it saw heavy use. Perl has it's roots in Unix sysadmins and system programmers -- it was a pretty strange animal by the standards of the Computer Science Department people, but it's original core community was much more experienced than PHP's... and perl had the advantage of a longer period of adoption, so there was room for at least one major revision before the it got slammed by the web craze. (You might think of PHP as perl with the perl4-era design errors locked-in).

[slacker]

Here is a 10 part Catalyst tutorial.
Catalyst-Manual
This should help get you started

[salazar]

Yep, had been working with that, I hit the wall when it told me to use catalyst.pl.

[sundialsvc4]

Don't let that sort of thing cause you to “hit the wall.” You know that you can expect this to happen, if you start moving too soon... so if it does happen, “you must be moving too soon.” Have another (beer|smoke|cappucino), and just watch. At first.