aspose file tools*
The moose likes Linux / UNIX and the fly likes Scripts on Linux/Unix: PHP, Perl, and Python Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Linux / UNIX
Bookmark "Scripts on Linux/Unix: PHP, Perl, and Python" Watch "Scripts on Linux/Unix: PHP, Perl, and Python" New topic
Author

Scripts on Linux/Unix: PHP, Perl, and Python

Tejas Jain
Ranch Hand

Joined: Mar 04, 2008
Posts: 119
PHP, Perl, and Python are the "P" of LAMP technologies. They all can handle http request and create html response. They all can access database.
Can anyone comment on the advantage and disadvantages of the three scripting languages?


"Knowing is not enough, you must apply... Willing is not enough, you must do."
--Bruce Lee
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Well, first, there's scripting languages in general. They're the "in thing" right now because of the "Git 'R Dun" approach to software development that so popular these days. You can slap out some code and see things almost immediately. We even see this in Java, with Groovy.

It isn't what it seems to be, however. I've worked with all sorts of programming languages and platforms over a long and evil career, and my conclusion has been that - excepting maybe assembly language - the amount of work required to produce a reliable, secure enterprise-grade application is roughly the same, whether it's C, C++, Java or Python.

What shifts is where you spend your time. C requires a fair amount of "up-front" work before you can see output. Java and C++ require even more in the design phase getting all those classes worked out and interconnected. Managers hate this. It's "unproductive", they want to See Screens.

Scripting languages are good for that. But there's a price. The workload shifts from the design phase to the debugging phase. All that time and care spent over getting C++ and Java code to even #%#%!! compile is what reduces the amount and severity of blowups once you finally do get something working. Few scripted languages can do strong error checking before the code is actually run. Many scripted languages, in fact could have had entire modules replaced with random garbage and you'd only find out come execution time.

I like instant gratification, too. But the computers of the world are in a vast conspiracy to make me look like an idiot. And if I must be made to look like an idiot, I'd rather do so at the privacy of my own desk at compile-time rather than in front of a large audience at a big-client demo or in production.

Which is why I hang out at the JavaRanch, instead of a board devoted to PHP or Python.

Regardless, not everything needs a full Java stack with ORM and a 300-line Maven build file. Some things aren't worth the trouble, and for that, PHP, Perl, Python, et al. are life-savers. Of course, some of the most successful systems I've ever seen were originally "not worth the trouble", but proved to be to useful and so popular that they grew into hideous all-devouring monsters upon whose continued functioning the very existence of the company depends. But that's another story.

So much for my Rs. 0.94, on scripting languages in general. If you want specifically to know pros and cons of the three languages mentioned:

1. Perl. The oldest of the lot. Exceptionally well-suited for pattern-matching. One of its original design goals was to be capable of ripping data out of report files, and it does it very well. Does a lot of things very well. Extensive packaged code library (CPAN). The downside of Perl is it's one of the major "write-only" programming languages. Like APL, you can dash out powerful and effective code in a hurry, but a week later, even the original author may not be able to look at it and tell what it's doing. Another "pro" when used for CGI is its "taint" mechanism, which helps prevent attacks through the webserver.

2. PHP. I like to call this the "Visual Basic" of the non-Microsoft Web. PHP owes a lot of its structure to Perl and C, but it's specifically designed to make it easy to write web pages. Its pros are an extensive and well-documented collection of function sets for all occasions, its readability, and its ASP-like mingling of code and HTML. Its cons are that it wasn't intended to scale to Enterprise proportions - it has an ASP-like mingling of code and HTML. Which drives editing programs crazy, and makes it difficult to read either the code or the HTML once pages get complex. It's still struggling to make the leap for a standard object-oriented architecture and it has had occasional security issues. It's also arguably the most successful "P" in LAMP, having been used for all sorts of major applications like WordPress and the WikiPedia.

3. Python. Python is a lot easier on the eyes than Perl or PHP. If PHP is "Visual Basic for the Web", Python is "Visual Basic" for everything else. Or at least BASIC for everything else. Like Perl, it has extensive package support and an archive (the cheese shop). I've had less trouble using the archives for Python than for Perl, probably because the CPAN archives frequently have to compile C code to be installed. Some nice things have been done in the areas of packaging and distribution of Python. They have a concept called a Python "egg", which is analogous to a Java JAR, and an installation program called easy_install. The Trac issue management system is written in Python, as is a lot of the support code for the Xen virtual machine facility and Red Hat's Anaconda program. There's a good Struts-like web development framework written in Python called Django which includes a limited but useful ORM capability. A final plus is that Python implementations frequently compile-on-demand, keeping a binary shadow of the code next to the original source for better preformance. A final minus is that the Python syntax is horribly dependent on indentations, so if you use an editor that doesn't intelligently manage spaces and tabs, you can end up with listings that look OK on the screen and on paper, but don't work right, if at all.

Is that a good start?


Customer surveys are for companies who didn't pay proper attention to begin with.
Tejas Jain
Ranch Hand

Joined: Mar 04, 2008
Posts: 119
Tim, It is a good analysis and summary. Thanks
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Scripts on Linux/Unix: PHP, Perl, and Python