 | This is an archive of past discussions about Dynamic programming language. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 |
Archives of the discussion (before 2005)
How can Eiffel be a dynamic language? It's the exact opposite.
Just removed ASP as "dynamic language"... and added VBScript... learn it loosers!!
The term "dynamic programming language" is not standard in computer science, and much of the article content is technically misleading, wrong, or just plain gibberish. k.lee 18:48 26 May 2003 (UTC)
OK, it's much improved now, but still has some inaccuracies and doesn't quite separate out the following issues:
- metaprogramming and reflective programming (both a language feature and a programming style)
- OO dynamic dispatch (a language feature)
- particular compilation strategies for indirect calls
- dynamic loading and linking (a platform service)
BTW I still don't agree that dynamic programming language is standard terminology, and the article's blurring of lines among the above three issues doesn't help me believe that there's a precise technical definition of this term. For example, the definition that "functions may be introduced or removed, new classes of objects may be created, new modules may appear" is inadequate --- Java can do all these things through dynamic class loading. Even in C, functions and modules can be introduced or removed.
If you're talking about only those languages with strong support for metaprogramming, then Lisp and Dylan (languages with quoted data and syntax macros) qualify but Smalltalk, Self, Objective-C, and OCaml do not.
If you're talking about languages with an eval function, then OCaml in its current incarnation does not count by any stretch of the imagination. Smalltalk and Self don't count either, because these only have eval in the sense that the environment has traditionally had an embedded compiler. There's nothing in the Smalltalk or Self language definitions that requires eval to exist. Contrast this with Scheme, which requires eval in the R5RS. Languages with no official standards documents only have eval through tradition; it would not be hard, for example, to include
I could write more on this topic but I don't have time. I think that, ideally, this article should
- state that the term "dynamic programming language" is neither a technical term nor a binary on/off property;
- then, list four or five precise technical features (e.g., quoted data, eval, dynamic loading, dynamic dispatch and other forms of indirect calls) that make a language "more dynamic" in flavor, linking to articles on those topics rather than describing them in the article body.
- then, discuss costs and benefits of a highly dynamic language, environment, and programming style. One of those costs is a requirement that the user generally must accept either (a) worse performance or (b) greater compiler sophistication. One can then point to an article on implementations of high-level languages. Actually I believe programming language implementation is an article that sorely needs to be written.
Anyway, someday perhaps I'll do all this, and more, in my Copious Spare Time.
k.lee 02:52, 17 Feb 2004 (UTC)