David Ascher has written a very good white paper on dynamic languages. The paper is very readable and frames a lot of the issues around dynamic languages. I was flattered when David told me at OSCON that he referenced this blog in the Further Reading section. It's taken me a while to read the paper, and then a second while to writing this post.

One of the great/terrible things about the term "dynamic languages" is that it means so many things to so many people. As I read the paper, I found places where my definition of dynamic languages was the same as what David wrote, and other places where it was different. So I'm going to over some of that in this post, partly to record it for myself, and partly for the benefit of anybody who cares (if there is anybody). Much of what's here won't make sense unless you read David's paper first.

In the Introduction, I agree that a big issue is helping people to understand that kind of languages being discussed have a much broader range of applicability. I think of the whole dynamic languages fad as an exercise in helping people to learn many of the lessons that Smalltalk and Lisp developers already know.

The paper lists 3 criterion for dynamic languages:

Criterion 1: High-level
As David noted, the notion of high-level is hard to pin down. He describes a bias towards more abstract built-in data types as one aspect of being high level. Many languages have large libraries of data types. I think that what is important here is the combination of more abstract built-in data types and syntax. A lot of what I like about Python vs Java/C# is the effectiveness of the notation for dealing with sequences, dictionaries, and so forth. The operations are there in Java/C#, but it's just a lot more concise in Python.

I don't think that favoring a VM implementation over a native code generating implementation is a requirement for a language to be high level or dynamic.

For me part of what it means for a language to be dynamic is to be able to interact with it. This means an interactive interpreter loop in addition to batch compilation/execution. I also think that a language needs to provide reflective capabilities in order to qualify as high level.

Criterion 2: Grassroots open source
One sentence in this section stuck out for me:

...the nature of the original creator (biological or corporate) has massive impact on the language's adoption and evolution...

I think that this is a highly important point, that covers more than languages. Equally important is the community that springs up around such an endeavor.

Having said all that, there are languages which fall into my classification of dynamic languages which are not open source -- the usual suspects, Lisp and Smalltalk (and yes, I'm aware that there are open source implementations of both).

Criterion 3: Dynamically Typed
I don't have any real disagreement here, although I do think that a possible next direction for dynamic languages is to allow usage of static typing at the programmer's discretion. This could happen via either explicit type declarations or via type inference.

In the section on Properties of Dynamic Languages, I'd change the subsection Optimizing person-time, not computer-time to "Optimizing person-time and computer time". I don't think that these goals need to be in opposition. I also highly agreed with the two subsections Open source, deeply and Evolution by meritocracy and natural selection.

In the section on When to use Dynamic Languages, there is a subsection titled Ideally suited for loose coupling. I didn't quite understand the point that was being made.

The Myths about Dynamic Languages section has two subsections with very similar titles, You can't build real applications with scripting languages and You can't build large systems with dynamic languages. This seemed a bit like hairsplitting to me. I did find it amusing that the second subsection amounted to "proof by Smalltalk". Interesting that this section involves proof by Smalltalk.

I did have some trouble with the subsection titled Dynamic languages don't have good tools. I can't speak about tools for Perl, TCL or PHP, but the tools that I've found for Python have issues as far as I'm concerned. The best tool that I've found so far is Wing, which has improved quite a bit for 2.0. It still doesn't have any kind of refactoring tools, and it's not hackable because you don't have the source, unlike Emacs, Eclipse, a Smalltalk, or a Lisp Machine.

Of the challenges that David listed, the one that concerns me the most is No real/formal budget. The money isn't actually the problem that worries me. The problem that worries me appears later in the paragraph:

problematically, to engage in long-term technical projects

I think that it is important that a language's developer community be able to engage in person/resource intensive longer-term technical projects. There are plenty of things piling up for Python 3000, which is only going to happen if Guido van Rossum becomes independently wealthy or retires. Mitchell Baker summed it up best in her post titled Why Pay for Staff? when she said "Speed matters".