I have been programming for 30 years and I have never seen such a division in programming languages. New tools have made it much easier to create new programming languages which I suspect is a major catalyst to this division. This review will probably be obsolete in the next 6 months but I wanted to take this opportunity to introduce developers to an unbiased, experience based, view of the programming languages that are available to the industry. I will start with the languages I am most familiar with and move towards those that I have no experience with.
When I started programming in PHP I immediately could see the long-term limitations of this language. Coming from a Perl/CGI background the limitations of not having direct access to the underlying protocol made it a difficult transition. PHP offers a somewhat high level interface with web servers, a limitation that over time has been corrected by exposing the raw content from the body, though there is still no way to access the raw headers received from the server. PHP does expose the headers in a way that is compatible with internet standards so it isn’t a complete loss. The real problem with PHP these days is a problem that is also faced by all CGI-based web development languages, lack of persistence. Developers are somewhat able to get around this lack of persistence by setting up crontabs to execute tasks on regular intervals, but each task runs in a separate process so there is no direct access to those tasks without adding complex inter-process communication. A related problem is PHP’s lack of support for parallel processing. I admit I haven’t yet tried to use the new PHP thread library but on a quick review of it’s features it seems to be mutex based, with no support for atomic operations. Overall, PHP is a good short term solution for web-only applications, but the long term prospects beyond Web 3.0 when web sites will be expected to offer live, interactive agents, and scheduled tasks, seems limited. PHP wasn’t design for real-time or stand alone applications and without some serious work by the developers of the PHP language to deal with these limitations the end of PHP’s usefulness can easily be seen in the not-so-distant future.
I can’t begin to express how useful this language is. I said useful, not fast. When I first started programming in Java web applications was the farthest thing from my mind. Compared to C and C++ the Java Virtual Machine (JVM) is a sluggish platform, and the compile process was horribly slow. When I saw my first Java/Tomcat web application I couldn’t believe my eyes. The site was ultra-fast and web pages practically opened instantly. I couldn’t believe what I was seeing until I tried it myself. With faster CPU’s Java compilers have become much faster, though they certainly aren’t instant. It can easily be seen with desktop applications written in Java that with modern processors Java execution is fast enough for most purposes. Those familiar with JNI know that it is even possible to produce low-level operations that occur at hardware-level speeds so most of the speed limitations of Java have become irrelevant. The magic of Java/Tomcat applications is that the JSP and Java sources that make up the application aren’t compiled in real time, they are pre-complied and/or cached, making Tomcat extremely fast once all of the code has been compiled. Java is an extensive language, with libraries for virtually every modern technology. It was developed from the beginning for real-time applications and therefore excels in future technologies such as web agents and schedule based operations. With all of this power at your fingertips why would you even consider using another language? I’ll tell you why, it is because no programmer wants to wait for their code to compile to see the results, and that is one of the big annoyances of Java web applications. Most of the time you also need to restart the server (aka. servlet container) to see your updates. If you are expecting your shared hosting account to support your web applications written in Java your in for a rude awakening. The beloved CPanel hosting management application has extremely poor support for Java/Tomcat, and it is still listed as experimental, therefore most shared hosting providers don’t offer it. Even if they do it may be difficult or impossible to configure most applications written for Tomcat since CPanel doesn’t look for your applications WEB-INF/context.xml configuration file. With improvements to CPanel support and automatic compiling of Java sources, which Tomcat doesn’t currently provide, Java/Tomcat may have a bright future, but right now there isn’t much support for it unless you have dedicated hosting or a virtual private server.
If you are like most web developers I’ve met you are probably asking what a fish has to do with web design but I assure you there is a programming language named Pike that can be used to develop web applications. In all fairness I have no experience with the Roxen server which is developed in Pike and is likely the standard for Pike web applications. I have gone down the hard-road of developing pike web applications as stand-alone applications using Apache proxy features to expose them to the web. Exposing the benefits of Pike is difficult at best, but the syntax of Pike is comparable to the works of mozart, it is a beautiful language and with proper documentation it could easily become the easiest web development language to learn. Pike is surprisingly fast for a language that gets compiled in real-time, and it’s flexibility is outstanding. Pike provides an object oriented approach to programming that directly mirrors the vision of what most programmers believe Objects should be. Pike has a great deal of potential for cross-platform usage, but chances are you are going to need to compile Pike yourself if you want the latest features. If you are using Windows, don’t expect much help from the developers of Pike in this department, Windows builds of Pike have become legend with very few developers knowing how to do it. Pike, and it’s modules, wasn’t, and is not, designed for windows and unless you have a deep understanding of the Linux Operating system and windows operating system it is unlikely you will be able to do it yourself. Luckily there are some binary versions of Pike available for windows, and that is really the best option. Pike is deeply suited for real-time, parallel computing, so it has a great deal of future potential. What you will find right now is that there are many bugs, and undocumented problems. It is not unusual to run into core dumps in Pike where the entire application crashes. Depending on your C/C++ skills you may see more core dumps in Pike than if you wrote your applications in a native programming language. My other major complaint about Pike is it’s weak security and limitations to it’s flexibility. From first glance Pike seems infinitely flexible, but that vision breaks down when trying to find solutions for real problems. The security of Pike also leaves a lot to be desired as it is almost impossible to create a secure sandbox in Pike. With the ease of triggering core-dumps, and caught errors returning pointers to secure objects the LPC language roots of Pike where it was meant to be programmed by large team of untrusted developers has been lost. Pike is a great language for research purposes, but without some serious funding the future of Pike is limited at best. Pike has most of the features you could ever need for a web application, unfortunately there are some limitations and many of those features aren’t yet fully functional.
Python is a language that was designed for script-kiddies, wanna-be hackers, and you can’t help but feel like a hacker when using the language. The features and forks of python are unbelievable. Hackers have made python compilers, and even made a version which runs on the Java virtual machine. If you are looking for a system with no internal security where you have unlimited access to every internal piece of functionality you will be right at home with Python. Anything that is possible with a programming language will probably eventually be supported by Python. Python developers take the language seriously and won’t let anything stand in the way of achieving their goals. My only real complaint about Python is it’s complete lack of security context. Without highly-restrictive virtual machines encapsulating Python there is really not possibility of running untrusted code in python. Every piece of code running on Python has open access to the entire web application placing the security of Python into serious doubt. My final complaint about Python is that it lacks binary compatibility between versions. Most python applications are compiled into a binary format that isn’t compatible with other versions of python. If your web server is using a different version of python than you are developing with you can expect some serious difficulty deploying your applications. Ensuring you are using the correct version of python at all times and that you are installing your applications into the correct version-specific folders is no trivial task. Add in the fact that most Linux distributions depend on old versions of python, and most web applications require new versions of python, and you are going to be spending a great deal of time working out solutions to version management. Python has a great deal of current and future potential, and may be great for some purposes but entrusting valuable information to python is a risky proposal that could easily turn into a disaster. On the bright side hackers are going to be dealing with the same version management problems that you are so chances are a hacker will crash your web application long before being able to access all of your data.
Ruby is the first fad programming language since LPC and it just won’t go away! At first look the syntax of Ruby is ambiguous, and to discover that this ambiguity was by design is a direct assault on logical thinking. Ruby may be a bit slow, but it works. Ruby is the only pure object oriented language that I have ever used. Literally everything in Ruby is an object and this can make computationally heavy applications painfully slow, but how often are we really writing computationally expensive code? Ruby was developed on a concept of code re-use, called DRY which stands for Don’t Repeat Yourself. If you see a reference to DRY coding you can bet that Ruby is going to be mentioned and 99.9% of the time your going to win that bet. The idea that there may exist some extremely high level programming language that could make programming extremely easy has been solidified into the Ruby programming language. Ruby is the programming equivalent to vertical marketing, and Ruby code tends to reach for higher and higher levels of abstraction. Ruby has become so abstract that there are now many code generators for Ruby which has automated a great deal of programming tasks. Due to the fundamental design of Ruby it has become a favorite among companies that are looking to make a quick-buck, and have no long term goals. Developing of simple applications in Ruby is simple, but if you are looking for security and high-tech applications Ruby is a recipe for failure. Let us start with the Ruby “Gem” which is the biggest security threat the internet has ever faced. Most features of Ruby are provided by Gem’s and installing a Ruby Gem is equivalent to removing all password protection from your server. When a Gem is installed it has the option of running compilers giving every Gem full access to your account while it is being installed. While it is possible for Gem’s to be signed, adding some potential for security, most Gem’s are not signed. Because of this every Gem/feature you add to your system is taking a HUGE risk. Even if the author of the Gem hasn’t included a back-door to hack your server Gem installation is still prone to man-in-the middle attacks due to the fact that most Gem’s aren’t signed by trusted keys. The cost of trusted keys is also prohibitive for most programmers so in reality cryptographic signatures aren’t a solution. It would be nice if there was at least some amount of configuration to limit a Gem’s access to your machine, but it simply isn’t possible with the current Ruby technology. Like Python there is also very little internal security in Ruby, but at least Ruby provides some level of data privacy, even if that privacy is easy to get around. Some people say Java faces these same security issues, but the truth is with Security Managers it is possible to make Java sandboxes secure. If you are looking for a fast solution to fill your web application needs, and don’t mind that the gem publishers can easily hack every one of their users servers than Ruby may be the solution you are looking for. In my experience we hide our money in a bank, or under our bed, we don’t just leave it out in the open for everyone to steal, and that is how I see Ruby, as an open donation box where anyone can walk by and steal from you.
Clojure is a LISP language and is therefore a highly technical programming language which restricts the technology to programming experts. Clojure is a relatively new language, and is quickly emerging. It runs on the Java platform and provides complete access to Java features. I admit that Clojure development is fast, and that extremely complex problems can be solved with very little code. It is actually more difficult to learn Clojure, or any LISP language for that matter, than it is to solve problems with it. If you are looking for unlimited flexibility than Clojure is truly your only option as there are no limits to what you can do with Clojure. The drawbacks of Clojure are it’s speed, and the steep learning curve. Clojure is not an easy language to learn, but once you know it you can use it to test virtually any programming theory but once your code is functional you will probably want to port your code to another language since only a small percentage of web developers understand LISP syntax.
If you believe I’ve written more than a few lines of ASP code than your sadly mistaken so instead of reviewing ASP as a language, let me review why I don’t use ASP. My vague understanding of ASP is that it is a child of visual basic. I have limited experience with visual basic and as best I can tell, visual basic and ASP were designed for people who don’t have any interest in programming and want to take the easy way out. ASP and Visual basic are both highly integrated with the .NET framework, and are an ideal solution when you want to unlock all of the features Windows has to offer. Beyond running ASP on Windows, you have to accept that ASP is fully owned by Microsoft and has a long history of poor cross-platform compatiblity. Personally I have had no luck with Linux ASP emulators, and unless you like the idea of being locked into Windows Servers, high-priced licenses, and virus-prone servers, ASP is really not an ideal language for most purposes. On the other hand, there are some applications that are only possible with Windows, and that is where ASP shines. It isn’t often that we run into situations where we need to access Windows Specific technologies, but when you do need to access Windows specific technologies ASP is probably the best option. There was a time when ASP would have been my first choice for accessing Windows capabilities but these days I would choose integrating Native Code in other programming languages, over ASP, with the deep understanding that most Windows only technologies are eventually available for other platforms.
#9 C/C++ and other native languages
It is certainly possible to use any turing complete computer language to do web development. Just because you can do something, doesn’t mean you should. It is possible to make extremly fast web applications in natively compiled programming languages, at a huge cost in development time. If this is your goal I strongly encourage you to research Apache Plugin development. Developing web applications as apache plugins is possible and your web applications would be executing at hardware-level speeds, with infinite security potential. Native programming language web application development is truly the road-less traveled. It is possible but it is expensive, both in terms of complexity, and coding time. With the many high-level languages available if you truly need to access low-level code it is usually better to extend an existing high-level language with native code libraries. You certainly can code complete web applications in native programming languages, but if you are going to take things that far, why not just develop an entirely new high-level programming language that does meet your needs? The amount of time it would take to develop a new programming language, and web application in that language, may be equivalent to the amount of time it takes to buld native language web applications, assuming you are going to utilize modern Compiler-Compiler technologies to develop your new language. If you are funded by someone with extremly deep pockets and a need for extreme security, such as a government, native applications may be the best solution, but even governments use high-level programming languages.
It should be painfully obvious at this point that the web development industry is not as mature as most people believe it is. There is a great deal of room for improvement in every web application development solution that is currently available. There isn’t yet an all-in-one solution to web development, and it is likely that you will need to use a combination of technologies to build significantly advanced web applications with today’s technologies.
Theoretical Turing Machine of the Future
While no one can truly know what tomorrow brings, I suspect that eventually XML will replace all programming languages. Using XSLT which is an XML technology it is technically possible to transform XML documents into source code. It is already possible to edit structured XML documents, of any complexity, using web based forms and therefore possible to engineer software without writing a single line of code. At the core of every programming language is a syntax and structure, and since XML can represent any data structure it can technically replace every programming language. I don’t believe XML will replace all programming languages in my lifetime, but XML, or some derivative of it, can replace every existing programming language, so I believe eventually that will happen.