What will the world of dynamic programming languages and Web applications look like in five years?
This is one of those highly personal and deeply philosophical questions best saved for after dessert is served, the drinks are poured, and the sidearms are safely locked away.
At the simplest level, the debate seems crucial. Choose the right language and new libraries magically appear because, well, the coolest programmers use the right language. The hottest languages attract the most developer energy, which usually turns into new libraries with the latest ideas.
Choosing the wrong language means filling your brains with semantic cruft that must be paged out to make room for yet another way of writing a loop. No one will be able to make sense of your code, and no one but you will care.
Most programmers who’ve been around long enough to survive the rise and fall of programming languages such as Cobol and Fortran recognize that the problem isn’t a life-or-death matter. There won’t be one winner, and backing the wrong horse won’t be fatal. These stable old hands point out that Cobol continues to run strong. At this writing, more than 1 percent of the listings on Dice.com include Cobol. By comparison, JavaScript draws a bit more than 7 percent!
Still, choosing poorly saps one’s energy. Some languages will be the dominant choice in certain niches. Choosing poorly means duplicating effort and looking longingly at the fast progress of others.
Commons or craft Rob Malda, one of the founders of Slashdot, says that he chose Perl for the site because there were so many good libraries available in the CPAN (Comprehensive Perl Archive Network).
“I think Perl’s primary advantage in 1997 when I original selected it was the active development occurring on CPAN,” Malda explained. “There was a library for everything useful, and usually very quickly. This was critical because new technologies and versions for core functions were updating constantly.”
But today, he added, “We have a much better idea of what you need for Web site building, and the tools and libraries have stabilized. All languages can handle the obvious things nice enough now.”
This is a nice, politically neutral statement, but it doesn’t solve the problem that in many shops, there must be only one Highlander. Only a kindergarten teacher would smile and say that all are equally good.
When a decision must be made, some believe it makes sense to go with popularity. The rich will get richer. PHP is the first language that many people learn after mastering HTML, and it will always be as comfortable as a childhood home. PHP server platforms from Zend Technologies offer better performance, making it possible to write a serious application in the language.
But will PHP be able to shake the casual structure that encourages beginners to whip up spaghetti code? Will it be able to continue to mix the presentation layer and the application layer without driving everyone insane? Will Zend’s collection of server optimizations provide enough performance to overcome any limitations of the language?
Others suggest that developer passion will produce the dominant language. Perl and Python attract some of the smartest minds who see programming as a craft. Their insight and devotion to creating elegant solutions is bound to produce a great platform in two years.
Hearts and minds
The same credibility with programming hipsters, however, can scare away the bulk of programmers and limit a language to a niche. This isn’t fatal, but it can come close if the masses flock to something simpler. The cool library writers can follow demand.
Some want to place their bets on Ruby on Rails, a striking and elegant solution that produces sophisticated results in no time. A few lines of code produce a full interface with all of the pages necessary to create, update, and delete records.
This simplicity often turns into shackles when the programmers reach the edge of the framework’s capabilities. Changing little details or producing slightly unorthodox output can be maddening.
There are many other options. Some developers love Groovy, the dynamic language integrated with the Java API. A programmer gets the rock-solid foundation of compiled Java code mixed with the flexibility to diddle with the Java objects in real time.
And then there are others who see languages such as JavaScript rising from the browser and colonizing the server. A unified platform makes everything simpler. Yes, Netscape wanted this to happen years ago, but thanks to the lightning performance of the new JavaScript semi-compilers, the language is bound to look even more attractive.
All of the languages mentioned above have enough of critical mass behind them to succeed and even flourish in the future. The right answer for you will depend more on the nature of your business and the structure of your data than on whether one platform becomes cooler than yours.
Evolutionary forces
Toward that end, here are 10 principles that will guide the evolution of scripting languages in the future. None of these will offer the definitive answer and save you from a long evening of dessert, liquid refreshment, and debate, but they will provide some guidance that may make the answer appear with more clarity.
1. The semantic barriers won’t be as important as the languages rush to steal good ideas from one and other. The dynamic languages are blurring together faster than they’re distinguishing themselves.
Larry Wall nabbed Python’s object system when he created Perl, and he and his acolytes are committed to making sure that there are many ways to do anything you want to do in Perl. Language committees are always debating how to weld a great idea from another language into the current one, and this will continue to happen. In five years, there’s a good chance you’ll be able to imagine you’re writing Python while the code is interpreted by something called JavaScript.
2. Frameworks are becoming even more dominant. Some people identify themselves as Django developers even though they’re writing Python code. Ruby has been around for years, but it didn’t become a rock star until it was matched with the Rails framework. The frameworks are so dominant that good JavaScript programmers can look at code written for an unfamiliar AJAX framework and end up confused. Libraries such as Dojo and jQuery aren’t just a set of helpful routines; they actively tweak the language and ask you to adopt a particular set of idioms.
The right solution may require you to choose both a platform and the framework itself — time to plan another evening of discussion.
3. Applications are becoming their own worlds. There are 23 job listings for WordPress developers. While the WordPress plug-ins will be written in PHP, the programmers will rely heavily on the standard set of libraries included in WordPress. Is it fair to say that the coders are working in PHP, or are they really working in WordPress?
The power of the dominant applications is apparent to everyone. Facebook even calls its scripting language FBJS (Facebook JavaScript) because it’s so site-specific.
But there are limits to this cross-pollination. “I don’t see this lasting because it’s so specific,” said David Goodger, a director of Python Software Foundation. “A lot of graphics packages had their own proprietary language for scripting. But then it’s this static thing. You don’t have the advantage of this vibrant community. If you take this language like Python, you have the advantage of this well-developed tool with the well-developed libraries. You’ve got the best of all possible worlds.”
Still, even if the applications embrace a 100 percent pure version of a language, all of the code will be dominated by the application’s API. Look for languages and their syntax to remain relatively pure while the libraries define another language built on top of the first.
4. Communities will be more important. As Goodger notes, Python is especially popular in a few niches, such as the world of bioinformatics and graphics. People who work with synthetic images or DNA results learn Python to do their job. Even if Python dies everywhere else, biochemists are probably still going to be learning Python.
The power of these communities is phenomenal. When Steve Jobs introduced the iPhone, everyone began looking for Cocoa programmers again. Mike Hendrickson, the publisher at O’Reilly Books, said, “We’ve seen a huge turnaround for Cocoa. It was all but gone a couple of years ago. Now, there’s a huge, huge increase in Cocoa because a lot of people want to develop their cool apps for the iPhone.”
If Steve Jobs decides that some unary lambda calculus is the language of choice for the iPhone 4.0, the developer community is going to find a way to rationalize his selection and talk about how much they love the language.
5. The Web and the cloud are the ultimate platform. Google’s App Engine sparked a huge burst of interest in Python. Perl and PHP were early favorites because they were so well integrated with Apache, a Web server that was both free and easy to configure. Tomorrow’s scripting languages of choice will be determined more by the simplicity, cost, and scalability of the hosting platform, not by the purity of the syntactic sugar. Look for such tools as AppJet and Coghead by selling a cloud with a simple scripting language for building the application.
6. Better language technology will make a difference. The battle for supremacy between Mozilla’s Firefox (“JavaScript, I am your father”) and Google’s Chrome (“Come live in thread harmony, Luke”) is good for everyone. The performance gains these browsers have brought to JavaScript have been dramatic, and they’re already making some other scripting languages jealous.
At the end of 2007, Larry Wall wrote, perhaps puckishly, that JavaScript “has some issues, but in the long run JavaScript might actually turn out to be a decent platform for running Perl 6 on.”
Sophisticated engines such as SpiderMonkey and V8 show that scripting languages can begin to compete with full compiled code because a smart just-in-time compiler can make guesses about the data that are often good enough.
The stunning performance is bound to attract the attention of folks who dream of running JavaScript on the server. While Netscape tried this idea a long time ago, there’s some merit in letting both the server and the client speak the same language. Now the only problem is figuring out which version of JavaScript to use. If history is any indication, it will be just a bit different from all of the browsers.
7. Emulation and cross-compilation will extend the life of dynamic code. Java programmers can use Jython to let Python code control Java objects. Groovy burrows deeply into the Java stack. Google’s Web Toolkit converts Java into JavaScript. Watch for the virtual machines from Java and .Net to become even friendlier to changes that come along at runtime.
8. All of the embedding makes it simpler for programming to escape the command line and start appearing in Web applications themselves. Some of the highly customizable platforms let you add custom code in a Web form.
Uploading JavaScript or Python on the fly to customize a Web application is still only for real programmers, but it will become easier and easier for casual users to avoid bugging the IT staff by writing their own code. Some WordPress plug-ins let users edit the JavaScript that controls the ads. The bloggers may be changing only a few colors and details for Google AdSense, but these Turing-complete mini-sandboxes are going to bring programming to the masses (see ” Application builders in the sky”).
Watch clouds like AppJet, a Web site that lets you build a Web application with one file filled with JavaScript. AppJet’s Web site is the IDE: You just go to a Web page and edit the code, and voila, the code is tested right in your browser.
9. The rise of the amateurs may make much of dynamic programming irrelevant. Web sites such as Coghead ( see my review), Caspio, and Microsoft’s Popfly let the world do much of the programming without typing any characters at all — unless they want to put a label on some Web form. All of the instructions for the server are communicated by mouse clicks, lines, and flowcharts. This democratization will create graphical languages that may flourish — if the creators can make them simple enough for the average human.
10. Adaptability for modern architectures is key. David Goodger says that the Python team invests a great deal of time in improving multicore performance. Earlier versions of Pythons could handle threads, but threads were still bound to a single core. That changed after researchers with big data sets pushed for better performance that can take advantage of the hardware.
If your applications are naturally multithreaded, then watch the development of these core-savvy languages. If the work you do is limited to a single thread, well, look elsewhere for performance.
The one Highlander
These principles don’t lead to one clear answer for the path of dynamic languages and Web development. The real answer may be that anyone can choose any of the languages as long as they make sure they track and navigate these 10 themes.
For instance, simplicity is an important theme as developers move toward elegant solutions. Ruby on Rails is quite popular because of the straightforward syntax and the tight integration with the database. The best frameworks that speed the development of complex, database-driven applications will triumph. But then, we already knew that. The performance of Ruby on Rails is often criticized. JavaScript isn’t well known in the world of traditional Web application development. If someone can merge the two, the combination could dominate.
Many other dynamic languages are already borrowing some of the best concepts from Rails. The Java programmers, for instance, can turn to Grails, a simple framework built on top of Groovy and a JVM.
Speed will always matter. For this reason, JavaScript will become more and more useful as the high-powered competition on the Web influences other uses of the language. Other languages will need to either borrow many of the ideas from the JavaScript core or find a way to benefit from them through emulation.
Slashdot co-founder Rob Malda, who chose to build the site on Perl because of all the good libraries in the CPAN repository, sees the features that attracted him to Perl in nearly every dynamic language today.
“Down the road it seems unlikely that we’d rewrite in Perl, but I have no real guess as to what we would rewrite in,” he said. “I suspect Rails would be fast enough in five years to consider it, but who knows?”
