by Lynn Greiner

PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe

Aug 29, 200815 mins

Three years ago, Lynn Greiner interviewed the big cheeses responsible for the popular scripting languages PHP, Perl, Tcl, Python, Ruby and JavaScript to find out where the languages were headed. In this follow-up discussion, she asks the dynamic language luminaries what has changed since then.

The former second-class citizens of the programming world have leaped to the fore, changing the face of enterprise software development. With the rise of Web 2.0, scripting languages (also called dynamic languages) are now often considered important tools in a developer’s arsenal. That’s a far cry from than their old reputation as lesser tools for those who can’t handle “real” programming.

Dynamic languages are certainly popular. Almost 70 percent of the 1,200 developers surveyed by Evans Data for its most recent Global Development Survey currently use JavaScript, the most popular dynamic language, with fifteen percent more planning to adopt it. PHP is used by just over a third of developers, and Perl has captured about a quarter of developers (though Perl is much more popular in North America, with 36 percent spending at least some of their time using it).

However, like any other tool, dynamic languages are not necessarily interchangeable. Each has its place in a programmer’s toolkit. We asked a group of luminaries in the scripting world for their perspectives on the current state of the scripting universe, and how it has changed since we last looked at the scripting language scene in 2005.

  • Norris Boyd is the creator and maintainer of Mozilla Rhino, a JavaScript implementation for Java. Boyd was part of the JavaScript team at Netscape. Today, he is an engineering manager at Google.

  • Richard Dice is the president of the Perl Foundation, the organization which has responsibility for Perl’s legal, organizational, technical and administrative infrastructure.

  • Jeff Hobbs is director of languages and Tcl tech lead at ActiveState Software and a member of the Tcl core team.

  • Steve Holden is chairman of the Python Software Foundation, and author of Python Web Programming.

  • John Lam leads the IronRuby team at Microsoft.

  • Rohan Pall, representing PHP, is a consultant who has been programming Web applications for almost a decade. What place do scripting languages have in today’s computing environment?

Boyd: The biggest change since 2005 has been the growth of richer Web applications that perform more of their computations in the browser using JavaScript. The demand for these applications has forced developers to learn and use JavaScript much more than before.

There’s also been a lot of interest in Ruby, another dynamic language, spurred by the release and growth of Ruby on Rails. As a result of these changes, many developers are becoming more comfortable with dynamic languages.

Dice: Since 2005, there haven’t been any singular events that changed the way scripting languages are used or their capabilities. They have evolved (more in perception than in real capability) from a place where they were used only for simple tasks or prototyping of new systems into much more general use. The general upward slope in their acceptance and capabilities in that time, though, means that CIOs definitely need to put them on their radar and develop “scripting language awareness.” In late 2007, Forrester Research published its Forrester Dynamic Language Wave survey, so research on the topic is out there to work with.

Hobbs: Scripting languages are increasingly prevalent in Web applications, with PHP’s growing popularity and the rise of Ruby on Rails, while maintaining their dominance in important daily tasks such as machine and test automation with Tcl and data manipulation with Perl. Python is finding increasing use in the scientific communities.

Holden: Scripting languages are being used in a wide range of application areas. Python has recently achieved increased visibility in many areas of science and engineering, particularly in bioinformatics. Three significant Web frameworks (Django, TurboGears and Pylons) have reached maturity in the last three years.

Scripting languages have a place anywhere that a systems programming language (e.g., implementing an operating system) is not required. Otherwise they fit basically anywhere, whether it be on the server or the desktop. Python excels in all these areas!

Lam: In general, it’s easier to create and change code written in a dynamic language. Much of the Web has traditionally been created using dynamic languages, from Ajax on the client to server code written in PHP, Perl, Python and Ruby. Ruby on Rails in particular has driven a lot of interest towards Ruby, and is one of the preferred platforms to build Web 2.0 startups on.

Pall: In the last three years, we’ve seen the adoption of very fast CPUs, namely the Intel Core 2 line. Breaking the 3GHz barrier on this architecture—and now pushing 4GHz—has sped up dynamic language code to the point where many algorithms that simply weren’t feasible to implement in PHP are now possible on commodity hardware.

In the last year, I’ve participated in writing text analysis software for auto-classifying documents. Our initial plan was to use C to do the heavy processing and PHP for the rest. As it turned out, on midrange commodity hardware, we were able to use PHP throughout and maintain solid performance. Web applications are commonly scripted, but in my experience, even internal processing-intensive applications are now commonly being implemented in modern, dynamic, scripting programming languages. The bulwarks have been breached and progress is now ushered in.

Next: How have attitudes changed towards dynamic languages? What changes are you seeing in attitudes towards scripting (dynamic) languages?

Boyd: The increased use of JavaScript for browser-based applications is sparking interest in JavaScript as a language for use outside the browser. I work on Mozilla Rhino, which is a JavaScript environment for Java, and we have seen a lot of people using Rhino on the server side to add scripting to their applications. It’s a nice extension language for applications since it was designed from the start to run inside another application.

Dice: I’m noticing changing attitudes from several angles. As I mentioned before, Forrester Research released a Wave survey paper last year regarding dynamic languages. This was motivated by their noticing that their customers were using more dynamic languages and requesting information on the competitive landscape in the field of dynamic languages.

Tools companies, including Eclipse and ActiveState, are offering more and better products for working with dynamic languages.

A segment of Java programmers seem to be embracing Ruby (and Rails) in particular. A new dynamic language, Groovy, is capitalizing on this trend by providing a dynamic language on the Java Virtual Machine (JVM) that incorporates elements of both Java and Ruby.

Support for independent software vendors (ISVs) with dynamic languages is also improving. The Linux Foundation’s recently-released LSB 3.2 spec includes Perl and Python as first-class supported languages within the spec, so ISVs who target this spec for their software can depend on Perl and Python being present in regularized configurations.

Hobbs: The dynamic languages are becoming more accepted. This is in part through more acceptance of open-source software, which all the dominant dynamic languages are (versus Java and .Net, which are questionably open in their process and/or sources). It is also due to good frameworks being developed using newer languages such as Ruby on Rails. You also see larger organizations fostering support for the languages, such as Google’s support of Python, which was made their primary development language for Google App Engine.

Holden: People seem more positive towards scripting languages. They have, over time, come to realize that their performance is such that they work for most problems and have also learned that the compilation step can be heavy-handed and a huge time sink in the development cycle.

There is now a more general appreciation of the advantages of dynamic languages, whose characteristics are well-suited to Agile test-driven development techniques that have also become more popular in the same time frame.

The last three years have seen increased uptake in dynamic languages in many application areas. For Python in particular, the IronPython (now a Microsoft open-source project) and Jython (whose primary developer was recently hired by Sun Microsystems) implementations have had a positive impact.

Lam: Compilation is orthogonal to static/dynamic. IronRuby is a compiled language (and an interpreted one too— we offer both options), yet it is clearly a dynamic language. So it’s better to say that there are changes in attitude between static versus dynamic languages.

There is a “polyglot programmer” meme going around which roughly says that future systems will be built on a statically typed library foundation (e.g. BCL in .Net) with a dynamically typed language used in a dual role to both script those static types as well as define a domain-specific language (DSL) which will be used to implement the high level app logic.

Pall: For a large number of applications, when deciding what technology to use, it is no longer the case that the debate centers around dynamic languages versus compiled languages. Scripting is now considered real programming, and indeed most people don’t even use the word “scripting” when describing what they do, but instead call it “programming.” These days, it boils down to which dynamic programming language to use, not if you should use one.

Next: Has Ajax made a difference? What effect has the growing prevalence of Ajax had on the adoption of the various languages? Are people adapting the techniques to languages other than JavaScript?

Boyd: Other than a greater comfort with dynamic languages, I don’t know of specific impacts of Ajax on other languages. The techniques of Ajax are really only applicable inside the browser.

Dice: Ajax is entirely a JavaScript phenomenon—it stands for “Asynchronous JavaScript and XML.” It is not so much a technology itself as a way of combining several existing technologies (CSS, XHTML, XML, DHTML and JavaScript, and the various document object models (DOMs) available within modern Web browsers). Taking these technologies together and calling them Ajax, Web applications can be made much more usable, visually appealing and functionally rich than previous Web application development paradigms afforded.

The first scripting language to benefit from Ajax in a big way was Ruby, though this was much more an accident than anything else. A Ruby Web rapid application development framework called Ruby on Rails started gaining attention in 2005. It had three things in its favor: it was based on the Ruby language (which a lot of people find quite nice to program with), developers found it to be a significant boost to productivity, and it was the first framework to integrate with any Ajax library. So it quickly became identified with Ajax and vice versa. Nowadays, every major scripting language has decent integration with every major Ajax library.

Most Ajax usage in Web applications development involves interaction with the server-side of the Web application. The front end of the application—the end that lives on the Web browser—is HTML, Javascript, Ajax, etc. The front end interacts with (and most often is dynamically created by) the back-end, which can be programmed in Perl, Python, Ruby (or Java, C++, Smalltalk, Lisp, etc.).

Hobbs: JavaScript is just the front-end language, often with a dynamic language on the back-end. These are commonly Python, PHP or Ruby (Rails), as they have become popular through common Web frameworks. Dynamic languages are common because they are much easier to use than Java or .Net on the background, providing as much as 10x more developer productivity. You can always throw more hardware at a problem, but getting something solid out on time is key, and dynamic languages provide great leverage to succeed.

Holden: Since Ajax is simply asynchronous network calls, it is not affecting the adoption of any specific language beyond more JavaScript usage in webpages. The technique of Ajax is in no way new and has been available for decades, including in Python.

In the Python world, the TurboGears framework in particular accommodates support for several well-known Ajax toolkits, but the emergence of Ajax is essentially orthogonal to the language used for Web development, and is as likely to be used in the ASP.Net environment as by Python users.

Lam: Ajax is popular because browsers are popular. JavaScript’s popularity is directly tied to the fact that it’s deployed on virtually all browsers today. Right now, there really aren’t any other dynamic languages for the browser that are widely deployed, so nobody’s really trying. I coined the term ARAX to try and drive some thinking around using Ruby in the browser as an alternative language to JavaScript. That generated some interest in the Rails community since they would be interested in running some of their Ruby code in the browser.

Pall: Ajax is a very specific technology that allows webpages to rise above mediocre user-interfaces and become true applications using JavaScript. Flash ActionScript has had this capability for a while, but now lightweight solutions are possible without depending on proprietary tools like Flash that are sometimes not available for use in large internal projects or secure sites.

Top Fortune 500 companies have limitations in their technology choices that must be adhered to, and Ajax has brought needed functionality to Web applications that are now replacing legacy Visual Basic applications, and doing it while being compatible across operating systems. Using Firefox to run Web applications internally on GNU/Linux based operating systems, with its solid Ajax implementation, has cut down licensing costs for many school boards across the province of Ontario, Canada, for example. This savings can be translated into hundreds of thousands of dollars saved.

Next: What should CIOs know? What is the one thing you would tell a CIO who is considering scripting languages?

Boyd: Whether or not to use a specific language depends on the problem you’re trying to solve. If you want to create richer browser-based applications, then JavaScript is an obvious answer. And JavaScript is also worth considering if you’d like to add scripting capabilities to other applications.

Need more on JavaScript tech details? See JavaScript 2’s New Direction and You Used JavaScript to Write What?!

Dice: Scripting languages are the expanding frontier of programmer productivity and they are the first technologies to expand into whatever new niches appear in IT. They’re the best way to future-proof your efforts without sacrificing new opportunities.

Of all the scripting languages, Perl offers the biggest installed base of applications, of code, of integrated systems, of skilled programmers. It has the lowest defect rate of any open-source software product. It is ported to essentially every hardware architecture and operating systems, from embedded control systems to mainframes. It is optimized for speed, for memory footprint, for programmer productivity. It has readily-accessible libraries for all types of programming tasks: Web application development, systems and network integration and management, end-user application development, middleware programming, REST and service-oriented architecture programming. Perl is ideal for the organization that takes charge of its own IT future.

Looking for more on Perl? Start here: You Used Perl to Write WHAT?!

Hobbs: First and foremost, scripting (dynamic) languages are here to stay. Dynamic languages better support an adaptive/iterative development model, and so are of increasing importance in the fast changing IT landscape of the early 21st century. They provide an excellent complement and often a better outright replacement for systems languages (such as Java, C++ and C#).

At ActiveState we are addressing similar issues around the misconceptions of open-source software in general and dynamic languages in particular with whitepapers like 10 Myths About Running Open Source Software in Your Business. (PDF)

Holden: Don’t discount scripting languages in general or Python in particular because of a lack of explicit typing or assumptions of poor performance. Requiring the declaration of types only catches a minor set of potential bugs that are easily discovered by typical unit testing. As for performance, Python might just surprise you.

And on the off-chance something is not fast enough, you have the option to go back and rewriting it in C/C++ (or in Java or any .Net language if you use Jython or IronPython) as needed, allowing you to still benefit from Python’s high level of productivity.

Scripting languages in general and Python in particular can offer massive increases in productivity with little or no negative effects on eventual system performance. Where performance gains are required extensions can be crafted in compiled languages if necessary.

To get started with Python technically, see You Used Python to Write What?! by Martin Aspelli, and Python Upgrades Readied for 2008.

Lam: Dynamic languages offer better productivity in many cases. Future programs will be written using a mix of static and dynamic typed languages. Use each language where it is best suited: dynamic languages to define DSLs, and static languages where you want to leverage the power of a strong type system for things like static verification of programs or increased performance.

For more on Ruby’s technical plusses-and-minusses, see You Used Ruby to Write What?! by Zed Shaw and Hal Fulton’s Why Ruby on Rails Succeeded.

Pall: Dynamic languages improve productivity and reduce complexity leading to simpler less error-prone solutions. PHP has a large, helpful, intelligent community that offers a mature product, without too many surprises.

Also see: PHP’s Enterprise Strengths and Weaknesses.

Want more software development news and analysis? Sign up for the Development & Architecture newsletter, which is delivered to your in-box twice a month.