DevSource: Where do you see scripting languages going? Where will scripting be in five years? Do you see it being replaced by compiled languages?

Conway: If anything, I think the trend is in the other direction: interpreted or "just-in-time" compiled languages will increasingly take over from pre-compiled languages. Compilation will eventually come to be seen for what it is: merely an optimization tool, and one whose use is almost always premature.

It'll still be useful when shipping stand-alone code beyond environments you control, but increasingly compilation will be seen as a packaging technique. Of course, the other aspect of that is that the line between compilation and interpretation — which has always been a little arbitrary — will blur even further. Perl already has an on-the-fly compilation phase in front of the interpreter, but it targets Perl's internal "assembly language," rather than the underlying hardware's. The future will be about consistency across platforms, so compilers will increasingly need to target abstract "virtual machines" (like Sun's JVM or Microsoft's CLR) that are layered over the hardware. At which point, are you compiling or interpreting? And does it matter?

Pall: In five years, I imagine that the term "scripting" will lose even more of its significance as it becomes seen as programming instead. As more programming is done with scripting languages, doing memory management yourself, or implementing yet another LZW-based compression library will be seen as a risky proposition when deadlines approach.

Compiling is and will remain a part of scripting languages, evidenced in byte-compiling, which does not preclude high-level scripting, but instead only aids its adoption as efficiency concerns are addressed.

Van Rossum: In five years I expect that dynamic languages (the successors inspired by today's languages, or today's languages evolved) overtake Java and C++ as the dominant implementation languages in most areas. Moore's law is on our side.

Thomas: I see a definite trend among the leaders in the industry away from compiled languages and towards dynamic ones. A lot of Java developers, for example, are experimenting with a Ruby web framework called Rails.

The distinction isn't really compiled languages vs. interpreted languages. All languages are at some point interpreted (given the complexity of today's processor architectures). The issue is really one of language style. There are static languages, such as C# and Java, which try to dot every "I" and cross every "T" at compile time. There are dynamic languages, such as Smalltalk, Python, and Ruby, which have strong, but dynamic, typing. For a long time, developers felt that the type-safety of static languages would mean their code was more reliable.

That seems pretty intuitive. But increasingly, people are finding that not to be the case. They're finding that the productivity gains they get from dynamic languages are enormous, and that type safety is generally not an issue. Sure, it is theoretically possible for you to have a variable called 'person' but discover at runtime that it's referencing an object of class PurchaseOrder. But it just doesn't happen in practice.

Hobbs: I believe that there will continue to be a place for the dynamic languages in the computing world of tomorrow. There are elements that are shared between dynamic and systems programming (C/C++, C#, Java) languages. Newer systems languages like C# and Java are evolving, however, the dynamic languages are evolving as well. They do complement each other, and the dichotomy of their purpose will remain.

DevSource: What do you see as the attraction of scripting languages?

Conway: Interpreted languages do two things much better than compiled languages.

Firstly, they provide more sophisticated programming tools and support for more advanced programming techniques. For example, Perl provides hashed look-up tables and arbitrary-length arrays as core data types. C doesn't even have a proper string type. Likewise, Perl's data sorting facilities are integrated into the language, so the sorting criteria are directly programmable.

Having all the basic tools of programming (i.e. high-level data types and common algorithms) built into the language, rather than having to build them yourself, means that you need to write less code to solve a given problem. Scripting languages let you use power-tools and pre-fabricated panels to build your home, instead of having to build a stone axe to cut down the timbers to shore up the mine to extract the iron to forge the saw to mill the lumber to get the posts to sink the foundations on top of which you'll eventually construct your dwelling, once you've gone back to the mine to get more iron to cast an adze and some nails and a hammer, and used them to build a ladder and... well, you get the idea.

The second major attraction of interpreted languages is that they let you do incremental development very quickly, without the constant irritation of sitting around waiting for compiles to finish. Many Perl programmers — myself included — develop directly in their favorite text editor: write some code, hit a function key, and see it execute immediately. No frustrating pause, no break in your concentration. That "immediacy" and "seamlessness" is a huge benefit, and often overlooked.

Pall: The speed of development when scripting is already widely-known, and often its speed of execution suffices. If a program takes 10ms or 100ms is often not a concern.

The large amount of people, untrained as traditional computer scientists, who can take up scripting increases its ranks by an order of magnitude. Scripting is easier for intermediate computer users to start doing; witness the many teenagers doing PHP and Python.

Van Rossum: Developer productivity. One needs significantly fewer lines to accomplish the same thing (a factor of 2-5 compared to Java or C++) and that pays back in many ways: quicker development time, easier maintenance, easier retargeting after project goals change, easier to do "exploratory programming," quicker time to market. Even in the late 90s, I recall several startups that became very successful due to their use of Python as a "secret weapon:" Yahoo Mail and Yahoo Groups started out as successful Python-based startups, and so did Microsoft's Commerce Server.

Thomas: Fundamentally, scripting languages let me deliver value to my customers faster. That's good for them, and it's good for me. I get more rapid feedback, which makes my applications better, They get to start using the code earlier, which improves their cashflow. It's a win-win.

Hobbs: I believe the strongest attraction is the irrefutable optimization of person-time vs. computer-time when one uses dynamic languages in development. You can do so much with so little effort, it's addictive. Really!