Pinderkent

I read an article today lamenting the lack of good documentation accompanying the recent Ruby 1.9.1 release. While very true, I think it's a result of the general nature of the Ruby community. The general attitude has often been a preference towards the typical "quick and dirty" approach. Performance, maintainability, feature set and documentation have often taken a back seat.

In some cases this is a good attitude to talk. It has made Ruby and Perl useful languages for many system administrators, for instance. They can quickly write one-off scripts with minimal effort. But for software development on a larger scale, those typically aren't good languages to use. There's nothing stopping them from being used, of course. It's just that the end result often isn't of a high quality, and maintainability is often a huge nightmare.

Python is often much better in this regard. The community has generally taken a more careful approach, with greater emphasis on correctness and quality. We see this reflected not only in documentation that actually exists, but documentation that is very informative and clear. So while you many not be able to develop a one-off script as quickly with Python as you could with Ruby or Perl, Python does lend itself towards larger-scale application development.

I have recently worked with several Django-based Web applications, and a number of Ruby on Rails Web apps before that, at one company I'm consulting with. I have to say that the Django Web apps were much cleaner, better documented and had fewer bugs than the Ruby on Rails Web apps. Management always initially liked how quickly the Ruby on Rails development team could get their Web apps up and running in production, but were never pleased with the numerous problems that arose afterwards. Those issues just didn't arise with the users of the Django apps, because the effort was put towards doing it much more correctly the first time, even if it took slightly longer to get the apps into production use.

Unless the general attitude within the Ruby community changes, I think it's unlikely that we will see better documentation. But this will become more of a problem as we have increasingly more Ruby code that needs to be maintained. Good documentation is always essential when performing code maintenance, especially when the underlying programming platform (eg. Ruby) changes so rapidly. So maybe this will help drive demand within the Ruby community for better documentation efforts.

Although it's not a new concept by any means, the use of JavaScript for server-side development has gotten some attention recently. This is unfortunate, as JavaScript is not the sort of technology you want to use when developing the back-end for a Web site.

Even as a client-side language, JavaScript has proven to be of a very questionable quality. I think Jonathan Edwards was correct when he described JavaScript as being "quick" and "dirty", and only just "good enough" for most users. For years now, even the major JavaScript implementations have exhibited horrible performance. Only after 15 years of use are we seeing that start to change, with faster VMs from Adobe, Mozilla and Google. As a language, JavaScript itself does very little to encourage the development of secure, high-quality code.

Server-side development calls for a more rigorous programming language and environment than JavaScript can offer. Considering JavaScript's performance problems on the client-side, it's likely they'd be magnified when it comes to server-side development. And JavaScript really doesn't offer anything beyond more traditional server-side languages like Java, C#, PHP, Perl, Python and Ruby. As is mentioned in the Ajaxian article, there is a huge amount of basic Web back-end infrastructure that will need to be built to make server-side JavaScript even barely comparable to any of the aforementioned programming languages.

What's worse, however, is the general "attitude" associated with JavaScript. It has always been a language that appeals to those who want to get their scripts written quickly, even if the quality is terrible and there are major security flaws. It has often been used by Web designers to quickly add some interactivity to the pages they have designed, without needing an extensive programming background. Indeed, this amateurish attitude becomes very dangerous on the server.

PHP is a good example of such danger. For years many PHP developers generated SQL queries directly using data sent to their script by the user, with little to no filtering. This resulted in SQL injection attacks becoming very common for PHP-based software. We still even see this sort of development happening today, in some very sad cases. Meanwhile, more mature server-side languages and environments like Java and .NET have for years provided support for parameterized SQL queries. But even the most inexperienced of Java and .NET developers know better than to not appropriately filter user input.

While there will of course be some professionals using it, and using it well, I fear that the rise of server-side JavaScript would lead to nothing but problems. Just as the PHP community is starting to get its collective act together, we might see a new generation of inexperienced, amateurish developers start with server-side development using JavaScript.

Then again, maybe that's not a bad thing. It'll guarantee a steady stream of work for those of us who have made a career out of fixing such mistakes. But it is unfortunate that we couldn't stop such problems in the first place, but using better languages for server-side development. With some work, Haskell could become very useful for server-side development where quality is concerned, while Erlang plays its part in reliable and highly-scalable systems. Regardless, the main thing we need to keep in mind is that JavaScript should be avoided for server-side development.

Today I was forwarded a link to an article suggesting that PHP became popular "because of its merits". Furthermore, the article goes on to suggest that PHP became widely used because of its "features" and "power". I'm not so sure that's actually the case.

I think PHP's popularity arose from it having few barriers to entry, and because there were few viable alternatives. But before we can consider this, we have to look back to when PHP started to become popular. This would have been during the late 1990s and early 2000s. At that point in time, commercial Web hosting providers had limited options for hosting a large number of Web sites on low-cost Web servers. Unlike today, VMware's offerings were in their infancy. Alternatives like Xen and OpenVZ weren't yet around. So VPS-like offerings were very rare, especially at a price that a student or hobbyist could afford.

Most users of affordable shared hosting weren't able to have much control over their servers. The hosting company would often not give any sort of shell access, but rather just use Linux and Apache vhosts, and allow their users to upload their files via FTP or a Web interface. Some of the better hosts allowed for users to deploy CGI scripts. In practice, there were often severe limitations, however. The choice of language for these CGI scripts was typically between shell scripts or Perl scripts.

So to develop an interactive Web site, many people ended up learning Perl, as it was their only viable option. Perl is a powerful language, but it does have a higher barrier of entry than PHP, especially in terms of its syntax. People unwilling or unable to work with Perl had to choose an alternative. In most cases, this ended up being PHP. Ruby on Rails did not yet exist. ASP was basically limited to servers running Windows, which many shared hosting providers did not use. Java-based Web solutions were too resource-intensive for what shared hosting providers could offer each user.

PHP was free, open source, ran on Linux, and could integrate well with Apache. Thus when users specifically requested it, many shared hosting providers were willing to install it. For many users, it proved to be an easier and more enjoyable language to use than Perl. Many hobbyists, and especially students, became familiar with it. They'd develop interactive Web sites that they could then affordably host with one of the numerous shared hosting providers who did support PHP. Soon enough, some of these sites were converted to more general PHP apps, some released commercially and many released as open source software.

At this point, we not only had developers using PHP, but non-developers who still wanted to have a Web site started using pre-developed software written in PHP, as well. This is when its popularity really started to take off. But we need to keep in mind that it wasn't because PHP was technically superior or even comparable to Perl, or the other available Web-oriented languages. In many ways it wasn't, and usually still isn't.

It was essentially the only option, besides Perl, available to those who wanted to put up an interactive Web site with minimal cost and effort. Even if you didn't want to use PHP, if Perl's offerings weren't suitable or not usable with your host, you fell back on PHP. A side effect of this is that many younger developers took the language from the student/amateur/hobbyist world to the professional software development world as they progressed in their careers. We started to see larger and more popular sites be implemented using PHP, even when other languages and platforms were available.

When considering it from a technical perspective, it's clear that PHP is often very lacking. The language itself isn't remarkable in any way. Compared to many other programming languages, the language itself it is immature and sloppy. It offers a large library, but it is a inconsistent mess relative to what Perl, Python, Ruby and Java offer. Security-wise, PHP has long been known as pathetic. Looking at the changelog for PHP 5, we see a huge number of security-related fixes, even as late as the 5.2.7 release, which came nearly two years after 5.2.0, and over five years after 5.0.0 Beta 1. In terms of performance, PHP has never been known as a winner, often indicated by the necessity of a PHP accelerator for even low-traffic sites. Finally, in terms of maintainability, PHP code is often a terrible mess, often because it was written extremely quickly and with little care.

We can't deny that PHP is popular. It obviously is very widely used, by big and small players alike. But this popularity arose not because of technical merit, but rather because it was the only option available at the time, leaving people with little or no other choice in the matter. Times have changed. That's why alternative programming languages and Web frameworks have become widely used. People realize that they now have options, and thus make use of them. I know many Web developers who are extremely happy to be able to move away from PHP. If PHP truly did offer significant technical benefits, we wouldn't see the eagerness we currently see towards Ruby- and Python-based Web solutions, as PHP would be more than sufficient for most.

Like many technologies, PHP's rise to fame was more accidental than earned by merit. It was in the right place at the right time. And so we shouldn't consider it bad to criticize PHP when such criticism is due. It has served many people well, but that still doesn't mean that it isn't lacking in many, many, many respects.

It's not the end for Perl. It hasn't died. We won't see that happen for some time, if ever. But lately, it sure has lost its way. Andrew Binstock recently pointed this out in his article about Perl. Although it is very difficult to measure or quantify a programming language's popularity, we can get an overall sense of the "buzz" surrounding it.

Perl used to have that community "buzz". About 10 or 12 years ago, when somebody brought up Perl in a newsgroup or mailing list discussion, there was genuine excitement about what it had to offer. Mainly, that was rapid development, CPAN, powerful regular expressions, and the ability to write CGI scripts, all with little expense. We had needs, and Perl did a fantastic job of meeting them.

Times have changed. We still need to be able to develop software rapidly and with as little cost as possible. But we now have to make better use of our systems with multicore CPUs. Languages like Erlang often do this better than Perl does. Also, we need languages that allow for applications to be more easily maintained. For most sizeable, real-world development projects, Perl code can quickly become a maintenance headache.

Furthermore, the main benefits of Perl are now offered by most other mainstream languages. Python and Ruby offer very good regex support, a suitably large library, support for rapid development, a high degree of portability, and a low cost. Python, for instance, often encourages the development of more maintainable programs than Perl does.

There's very little that'll draw people specifically towards Perl. Recently, I've seen it used only because that's what the developers were most familiar with, or in numerous businesses, it's what they're stuck maintaining. Few people these days seem to choose Perl because it offers something they just can't get elsewhere.

Andrew makes some good observations in his post. One we really need to consider is how, for example, the Python community has gone out of its way to create several usable and actively-developed implementations of the language. We have the CPython implementation. There's IronPython for .NET. There's also Jython for Java. And we can't forget Stackless Python.

We just don't see that sort of activity in the Perl community. Sure, there is Rakudo. And there is also the now-stagnant Pugs implementation. But neither is really suitable for production use. Meanwhile, the different Python implementations are used successfully by many different people and companies. The Python implementations have momentum; Perl does not.

I read a number of blogs, mailing lists, newsgroups, and online forums dealing with Perl. Likewise, I talk often with people in industry who make use of Perl on a daily basis. And one thing I've noticed is that there's little excitement to be found. I think the extraordinarily long time it has taken to get anything useful in terms of Perl 6 has been extremely harmful to the Perl community. To really see a programming language prosper, it needs that raw community excitement. Python and Ruby currently have this excitement. Erlang and Haskell have it, too. Even the Common Lisp community seems more up-beat than the Perl community.

It's far too early to label Perl as "dead", or even "dying". Perl will be with us for ages. But we shouldn't deceive ourselves into thinking that it still has the same momentum that it used to, or has momentum comparable to what we see in the Python, Erlang, Ruby and Lisp communities. The action we see within the Perl community pales these days compared to what is happening in the other communities.

I recently wrote about how undetected type errors when using languages like Ruby and Python can be quite dangerous. That article has gotten some notice, with one response considering Groovy.

The article about Groovy purports to have an example of a statically typed Groovy script that compiles fine, but results in a type error at runtime. The script is:

int x = "test"

The error received at runtime is:

Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot
cast object 'test' with class 'java.lang.String' to class 'java.lang.Integer'
at typesafe.run(typesafe.groovy:1)
at typesafe.main(typesafe.groovy)

If Groovy were truly a statically typed language, then the compiler would have raised a compile-time error. But since that did not happen, one or more of the following may be true:

1. The Groovy compiler does not perform adequate compile-time typechecking.
3. The Groovy compiler performs compile-time typechecking, but a bug prevents it from catching this particular error.
4. The semantics of Groovy prevent it from being a statically typed language.

The essence of static typing is that such an error would always be caught at compile time. We can't say that a language is statically typed if such an error occurs at runtime. Just because the programmer can specify the type of a variable (eg. 'int' in this case), it does not mean that the language is statically typed. This is especially true if the compiler or interpreter completely ignores such type specifiers at compile-time.

So in this case, I think the verdict is quite clear: Groovy cannot be considered a statically typed language, as it exhibited a runtime type-related error.