By Peter Bell

Do Scripting Languages Scale?

One of the common complaints about "lightweight" scripting languages like ColdFusion, PHP, Python and Ruby (as opposed to languages like Java or C#) is that they "don't scale". There is truth to the statement, but not in the way that most technical managers understand it . . .

The biggest difference between (say) Java and Ruby is the amount of "documentation" that you have to put into your code to make it run. In Java you have to explicitly document the type of every variable, you have to pass objects that implement the correct interfaces and generally have to jump through hoops to keep the compiler happy. There are numerous benefits to this approach. A certain class of errors are caught automatically by the compiler, the compiler can provide code hinting and automated support for certain types of refactorings and it can be easier to understand someone elses code (because they can't do things like dynamically mix methods into classes at runtime which can be a bit of a puzzler if you're looking at a class file and it is calling a method that doesn't appear to exist in the source code). In short, languages like Java are ideal for larger development teams and for more average programmers (although lots of very smart programmers use Java).

Scripting languages typically allow you much more flexibility in how you code which allows more experienced developers to create extremely elegant applications very quickly and for less capable developers to create code of almost Perl like impenetrability.

From a performance perspective, there is usually a "dynamic penalty" at runtime with running more dynamic languages, but for most use cases where scalalbility is a real issue, it is a matter of whether you have to throw 10 or 14 boxes at a problem (ratio will depend wildly on use case, exact code written, languages chosen, and testing methodology) and with the right virtualization and sys-admin tools it is often better from a business perspective to get an application to market more quickly and to be able to modify it more easily than to save a few boxes at the cost of slower time to market and higher development cost. In short, these days most of the time, programmers are more expensive than hardware.

Of course, there are plenty of use cases where performance is critical or where the additional hardware costs (both in terms of hardware and sys-admin time/effort) means that statically typed languages are the right choice, but I tend to assume a scripting language is usually the better starting point unless see a specific contra-indication. Scripting languages scale in every way that matters except for number of developers on a code base. Depending on the team, somewhere between 5 and 25 developers it makes more sense to consider a statically typed language, but the vast majority of projects don't need that many developers on a given service.

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.005.