If you are one of those folks who have been using PHP and nothing but PHP for a long time you will be hard pressed to find an alternative. PHP is, after all, one of those things that are “easy to get into, but difficult to get out of”. PHP lures you in with its forgiving nature, vast library of pre-built extensions, ease of deployment and just plain “instant gratification”. It’s easy to forget that there are other languages for server-side programming/scripting.

More Tools for your Toolbox

When I was teaching CS classes back then, I always told my students never rely on a single programming language and never tie yourself to a single platform. I have always stressed the importance of learning more than one programming language and making sure that whatever you do, do it cross-platform if possible. By not limiting yourself to one language or platform, you will be able to develop solutions using the right tools for the problem at hand.

The following is a short list of programming languages that I have used in the past. These are my “bread and butter” languages in addition to PHP. These are also the reasons why I found it easy to ditch PHP. If you have never used any other programming language besides PHP, perhaps you should take a look at what else is out there.

One Interface Behind Them All

In theory, you can use any programming language to do server-side programming. You read that right: you can use any programming (or scripting) language. You can use C, C++, Fortran, Haskell, Java, Lisp, Lua, Perl, PHP, Python, Ruby, and so on. You can use whatever you want, as long you are able to receive input and send output via the Common Gateway Interface or CGI.

Server-side programming/scripting essentially involves two basic operations:

1. Receiving and acting on a request;
2. Sending back a response.

CGI acts as a bridge between your web server and your server-side program/script. When your web server receives a request and it sees that request as a request to execute a program/script on the server, it will set up everything that is necessary to run your program/script. It then runs the program/script, captures its output, if any, and sends it back to the client who issued the request. In Unix terms, any program/script that can take input from stdin and send output to stdout can be used on a web server that supports CGI. This is an overly simplified description. If you wish to learn more about CGI, use “the Google”.

Because the server runs the CGI program/script as an external process to handle each request, this means that there is an overhead for each request. To boost performance, modern web servers have come up with ways of eliminating or reducing the overhead from external process creation. For instance, Apache allows you to create modules that act as filters and handlers for requests. In most cases, PHP will have been installed as an Apache handler on your server which embeds the PHP interpreter in the running Apache process, eliminating the need to create an external process to run your PHP script. There is also an extension to the CGI standard called FastCGI which takes a different approach. FastCGI runs several instances of your program/script as long-running background processes. The webserver then connects to these processes whenever a requests requires the use of CGI, sends the request and collects the response and sends it back to the client.

Of course, these days you care less about the details and worry more about what your program/script does.

Is it “Programming” or is it “Scripting?”

At the heart of it, programming is programming and scripting is programming using a scripting language. In the early days, it’s easy to differentiate between “scripting” and “programming”. Scripts were written using “interpreted” programming languages which typically ran inside another program (e.g., CAD with Lisp scripting) or a stand-alone interpreter. “Programs”, in the original sense of the word, were written using “compiled” programming languages.

These days, the distinction has been blurred with the advent of compiled programming languages that are run using an interpreter. Java is just one example of this. You write your Java program and then compile it into machine-independent byte-code which you then run using a Java virtual machine or JVM. A JVM is essentially an interpreter but these days, we also have the so-called JVM with Just-in-Time compilation which maps machine-independent byte-code into native instructions for the CPU running the VM.

It’s all become so confusing these days with all the recent developments in VM technology. The distinction between “scripting” and “programming” has eroded. Personally I just prefer to call it programming. So from this point onwards, I will simply use the term “programming” to refer to “scripting” as well and “programs” to refer to “scripts”.

One more thing: Knowing how to write HTML and CSS does not make you a programmer, so please stop calling yourself a programmer or “coder” if all you know is HTML and CSS.

The Duct Tape of the Internet

Let’s begin with the grand daddy of server-side programming: Perl. Created by Larry Wall in 1987, it has evolved into a true, general-purpose programming language. It was developed primarily to automate system administration on Unix systems. It began to gain popularity in the early 1990’s as a convenient way to write CGI scripts. PHP can trace it’s origins back to a CGI script written by Rasmus Lerdorf using Perl. That’s right, a scripting language begat another scripting language. You can see shades of Perl in PHP, the most visible is the use of the $ symbol to start a variable name.

Perl may come across as a quirky, cryptic language to some. It has also been the butt of jokes in recent times with the advent of newer (and sexier) programming languages. The Perl mantra TIMTOWTDI (there is more than one way to do it) is both a blessing and a curse. Take printing a progress bar for example. As one person found out by asking the Perl monks, TMTOWTDI. But make no mistake. Perl is a very powerful language, with a friendly community and a huge library of pre-written modules.

The standard Perl installation comes with the CGI module which allows you to get up and running with CGI very quickly. You can use Perl to write a simple CGI script without using the CGI module. However, using the CGI module frees you from having to deal with a raw CGI environment. It also gives you with useful functions for handling query strings and forms, URL escaping, and error handling.

It also comes with a standard for database interfaces and drivers (DBI and DBD). DBI will usually come pre-installed along with commonly used database drivers. If you are familiar with ODBC or if you have played around with PDO, the Perl DBI is similar in spirit. It provides you with a consistent interface for database access and more importantly, it gives you prepared statements even if the underlying database does not support it.

More importantly, most virtual hosting shops support already support Perl in addition to PHP. You will probably have two options, depending on your hosting provider. First option would be to write your programs as just plain CGI programs and upload them to a special directory on your account. Second option would be to write your program to take advantage of mod_perl if it is installed by your hosting provider. mod_perl not only allows you to write CGI programs, it also allows you to create Apache modules using Perl.

Over-Engineered Beyond Help

Next up we have the programming language that no self-respecting software “engineer” can do without: Java. Although it has all the required facilities needed to write CGI programs, if you must do something in Java, you should do it properly. And the proper way of server-side programming in Java is to write a Java Servlet. In order to do that, you need to run it inside a Servlet Container such as Apache Tomcat.

Java already has database connectivity covered with its standard JDBC. Odds are that your servlet container can also run JSP’s which allow you to embed Java code in your markup. Your servlet container then takes these JSP’s, compiles them into a servlet when handling the first request and uses the compiled servlet to handle subsequent requests.

As you have probably learned by now (or not), it is better to separate your program into distinct areas using the Model-View-Controller paradigm. Java supports this out of the box. You have POJO’s (plain old Java objects) to use for your model. The servlet serves as controller. JSP provides you with the view. Once you have the basics nailed down, it’s all very simple onwards. Or not…

As your program grows in size and complexity you will find the simple MVC approach using POJOs, servlets and JSP’s become unwieldy at best. You will be looking for a better solution. Java has a standard for developing large scale web applications too. J2EE is a collection of standards that encompass everything you need to develop large scale web applications and service oriented applications (SOA’s). Newbies will probably be overwhelmed by the amount of complexity involved in developing and deploying large-scale apps using J2EE. It has more acronyms than a bowl of alphabet soup. Once you’ve finished wading through your acronym soup, prepare to swim in XML tag soup. Almost everything in a J2EE server is configured using XML. But then again, developing and deploying a large-scale J2EE app was never meant to be a job for a lone developer and there are tools you can use to tame all that XML.

As for hosting your Java apps, typically you need to find a specialized hosting service of which there is no short supply.

Ooooooh! Shiny!

Then there’s Ruby. First released to the public in 1995 by Yukihiro Matsumoto, it was an obscure programming language from Japan that exploded in popularity in recent years (due to a well-marketed web programming framework). As one fellow so succinctly put: “Ruby is the language for trendy, non-conformists.”

Ruby by itself is a very capable language with a large set of libraries included as standard. The CGI library is one of them so you can also get to writing server-side programs in no time. Like Perl and Java, it also comes with a standard library for interfacing with databases.

I tried Ruby some time early last year but I find its reliance on on begin and end to be a major annoyance at best. That’s the reason why I hated programming in Pascal and VB so much. Come on, if braces worked for C, C++, Java, Javascript, Perl, PHP, etc. why bother using whole words to delineate blocks of code? Another sticking point, at least at the time, was performance. For small one-off scripts, it’s pretty decent. However, for larger more complex programs which are spread across several files, performance really sucks! The time it takes to launch the interpreter, byte compile your code and run it was simply unacceptable for me. If you’re going to use Ruby for CGI programming, use FastCGI or some other way of keeping a cached copy of your byte-compiled code in memory.

With those two aside, I find some features that make Ruby hard to resist. There’s “monkey patching”. Ruby classes are open classes. This means two things: you can spread class definitions across multiple files and you can modify built-in or standard library class behavior. Being able to spread class definitions across files helps to make your code more manageable as it grows in complexity and size. By modifying behavior of built-in or standard library classes you’re able to create semantics that are more suited to the job at hand. This can also be a problem, especially if your program is reliant on third-party libraries, as it is possible that the modified behavior is not what you really want. But when done carefully, it can extend the usefulness of existing classes (like to what Mootools does for Javascript).

Ruby also makes it relatively simple to map data from a text file or database record into a dynamically generated class at run-time. This proves useful in creating ORM’s (object-relational mappings). Most Java ORM’s use a clunky approach glued together with unholy amounts of XML. Ruby makes it easy by providing the facilities necessary as built-ins.

Another great feature is class composition. This is similar to the concept of interfaces and mixins in other languages. You define a set of methods and properties in a module. When you need them in your class, you simply include the module.

As for finding hosting providers that support Ruby, thanks to a popular web programming framework, most hosting providers now support Ruby in addition to PHP and Perl. Just like Java however, you can get better bang for your buck by going with a specialized Ruby hosting package.

Batteries Included

Now we come to my programming language of choice: Python. While using whitespace to delimit blocks of code may seem strange to those who come from the “bracketed” programming languages such as C, Java, Perl or PHP, it actually makes your programs easy to read by default. You don’t need to remember any silly coding and indenting conventions. As long as you use a consistent means of indenting your code (4 spaces is recommended), you are pretty much set when it comes to readability. It was a bit uncomfortable at first but blocks delineated by indentation sort of grows on you eventually.

With that single “unusual” quirk aside, Python has all of the tools you need to get started with server-side programming: “Batteries Included”. Simply import the cgi module in your code and start plugging away at your program. However just like in Java, there is a standard way of doing things and the standard way of server-side programming using Python is through the use of WSGI. Python’s WSGI is similar in spirit to Java’s Servlet specification. It defines a standard way of writing programs that have to interface with a web server using a request-response model. It takes the server’s execution environment, the client’s request, and the server’s response and packages it into one coherent specification.

One more thing that I like about programming in Python is that your program sort of describes itself. You spend less time writing descriptive comments as to what a section of your code does, unlike other programming languages. Chances are that you can write a Python program now without any documenting comments, come back six months later and look at your code and you will still be able to read and understand what it does.

Performance-wise, Python has consistently outperformed PHP and Ruby as of late. Python programs are compiled into byte-code before it gets executed by the Python VM (interpreter) just like Java. However, unlike Java, there is no explicit compilation step necessary. Unlike Java, Python can run your code regardless of whether or not it is in the byte-code compiled form. Your byte-compiled Python code essentially acts as an on-disk cache for the VM. When you first run your program, the Python interpreter will byte-compile your code and if it can, it will write the byte-compiled code into a file with a .pyc extension. The next time you run your program, the interpreter will check if there is a .pyc file present. If found, it will check to see if your source file is newer than the .pyc file. If your .pyc file is up to date, the interpreter skips the byte-compilation step and runs the .pyc file instead. If your source file is newer, it will byte-compile it and try to write it to disk. This is another reason why I prefer Python over anything else. I can distribute just the .pyc files without the .py source files. I am all for “open source” but there times when you just don’t want clients to be dicking around with your code.

As for libraries, chances are good that the standard Python installation already has everything you need. Python also comes with a standard for database interfaces called DBI, which like its Perl counterpart, provides you with a consistent interface regardless of what database you are using. It also provides you with prepared statements which can be emulated in the driver in case your database does not support it.

Just like Ruby and Java, you are better off going with a specialized Python hosting package if you are going to do WSGI. If you only need to write CGI programs in Python, then many hosting providers already support Python in addition to Perl, PHP, and Ruby.

So there you have it. I hope this goes to show that PHP is not the be all and end all to programming.

a

I tried the latest version of Eclipse the other night. As usual, I downloaded the “Eclipse Classic” tarball for Linux. It’s an iffy release to say the least, akin to KDE 4.0. There have been major changes in the platform itself. But the most visible part is the way plugins are managed and installed. Personally I had high hopes for the new UI as the old one was a bit unwieldy to work with. Unfortunately, the new UI still needs a lot more work done. The main problem I had with the new UI is that even the plugins that already came with the package I downloaded still show up int the Available Software window. There also appears to be a bug where if you check and then uncheck a plugin, it will still install that plugin. There are also some new issues and regressions introduced by the new UI that they still have to work on.

Right now, I’m back to using Vim. Eclipse 3.4 is just too flaky for me at the moment.

a