s have a poor reputation regarding performance and a good one regarding productivity. Too many people think that they are ToyLanguage
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 AgileProcess
Some such languages include:
And apparently WardCunningham
is striking again here: http://radio.weblogs.com/0102677/2003/04/04.html
I am excited about combining expressive ScriptingLanguage
(s) with the trustworthyness of TestDrivenDesign
. -- WardCunningham
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. -- PhlIp
Would it not be more constructive to talk of AgileDevelopmentEnvironment?
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 AgileLanguage? Is it just MarketingSpeak? for ScriptingLanguage?
Basically, any language that doesn't excessively hinder you from doing agile practices. Some specific characteristics:
It seems like this list is missing an obvious one:
- Easy to refactor in, including ease of automating refactoring
- 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 TestCollector and TestRunner easier)
- Ability to automate acceptance testing
- 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 OneSizeFitsAll
, but it's too compelling of an idea not to share.
What if we had a programming language with a hybrid of BDD (BehaviorDrivenDevelopment
) 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 AlternateHardAndSoftLayers 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 TypeInference. Dynamic portions of the code will have fewer restrictions than static portions since they don't have to provably satisfy the type system.