Scripting Languages have a poor reputation regarding performance and a good one regarding productivity. Too many people think that they are Toy Languages.
But things have improved a lot recently and some scripting languages are gaining momentum. In an effort to get rid of the poor reputation of scripting languages, these new languages (some are not so new) are called Agile probably to benefit from the momentum of Agile Processes.
Some such languages include:
Php Language
And apparently Ward Cunningham is striking again here: radio.weblogs.com 
.
I am excited about combining expressive Scripting Language(s) with the trustworthyness of Test Driven Design. -- Ward Cunningham
Ideally, a language should let you pick high or low level, static or dynamic typing, without clutter (such as C++ templates). But when you invest in tests instead of paranoid typechecks, the odds that a given type combination "accidentally" works together moves from a risk to emergent design. -- Phl Ip
Would it not be more constructive to talk of Agile Development Environment rather than language? Where environment would encompass a whole of language, frameworks, editors, coding conventions, tool support ... If you just focus on language, a static type system can seem like straight-jacket of paranoid typechecks, heavy build steps and a lot of unnecessary code. But one of the strengths of a static type system is that it allows for static reasoning about program behaviour, opening up for tool support, that go hand in hand with the agile way, such as refactoring browsers, modelers and interface builders.
What are the distinguishing characteristics of an Agile Language? Is it just Marketing Speak for Scripting Language?
Basically, any language that doesn't excessively hinder you from doing agile practices. Some specific characteristics:
Easy to refactor in, including ease of automating refactoring
This is aided by having a small, simple, and consistent syntax. Perl Language fails on this test, but Smalltalk Language and Lisp Language pass nicely
Ability to create a good, fast unit test framework
object-oriented features (helps to make test cases independent of each other)
Run-time reflection (to make implementing a Test Collector and Test Runner easier)
Ability to automate acceptance testing
It seems like this list is missing an obvious one:
Strong enough primitives and abstractions to build software at an acceptable rate
Here's a proposal that I think is not likely to fly because it tries to be One Size Fits All, but it's too compelling of an idea not to share.
What if we had a programming language with a hybrid of BDD (Behavior Driven Development) and statically checked contracts baked right in, and it was hybrid static/dynamic, procedural/functional, strong-duck-typed, object oriented. Yes, this is wacko, but perhaps not as wacko as it sounds.
Hybrid BDD/Contractual: This can be done by allowing an artifact's contracts to be specified externally, and allowing a contract to be either statically provable or to have executable specs (tests) that are automatically run on build and/or on-demand.
Static/dynamic: Modules can be defined as either compiled/checked, or dynamic, allowing us to Alternate Hard And Soft Layers within the same language.
What if the language gave you access to its own compiler, and the compiled output? Then, you could pre-compile modules, save the results to disk, provide mechanisms to re-compile each module used only if its source were changed (e.g. MD5 sum of the source file saved in the object code), etc.
Further, it would also help if there were a just-in-time compiler,
Procedural/Functional: Many hybrid procedural/functional languages already exist.
Strong duck typing: Can be done using Type Inference. Dynamic portions of the code will have fewer restrictions than static portions since they don't have to provably satisfy the type system.
See original on c2.com