Talk:Dynamic programming language: Difference between revisions

Content deleted Content added
Re-organized discussion
Line 1:
= Current discussion =
How can Eiffel be a dynamic language? It's the exact opposite.
== What exactly is a dynamic programming language ? ==
I believe that everyone agrees that '''dynamic programmig language''' does not have a precise definition. That's including programming language designers/designers wannabe [http://lambda-the-ultimate.org/node/12]. In addition, this term has been greatly misused by journalists and techies (including Gosling) who simply didn't know what they were talking about. If this article provides a precise definition, well, we need to build it first.
 
=== Languages ===
-----------------
I believe that everybody agrees that
* Compiled C is not dynamic.
* Lisp, Scheme, Dylan, Python, Ruby are dynamic.
 
What about
Just removed ASP as "dynamic language"... and added VBScript... learn it loosers!!
* Haskell and OCaml ? After all, they support dynamic programming, with extensions, they can perform compile-time reflexivity, etc.
* Java ? After all, it supports reflexivity and, with extensions, it supports dynamic programming, etc.
* Acute ? It's statically + dynamically typed.
* Self-modifiable assembly language ?
 
=== Criteria ===
-----------------
* Dynamic = interpreted ?
* Dynamic = dynamically-typed ?
* Dynamic = check as many things as possible at run-time rather than ahead-of-time (including types and possibly syntax) ?
* Dynamic = no need for type annotations ?
* Dynamic = interactive programming ?
* Dynamic = modifying properties of the language itself at run-time ? (à la SmallTalk)
* Dynamic = run-time introspection ? (à la Python, Ruby)
* Dynamic = run-time read/write introspection ?
* Dynamic = dynamically linked ?
* Dynamic = new and shiny ?
 
Is there such a thing as '''a dynamic programming language''' or should we say that one language is '''more dynamic''' than another ? I would vote for the second option.
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. [[User:K.lee|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.
 
===Characteristics of dynamic programming languages===
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
 
The term '''dynamic programming language''' does not have a precise definition, but it is nevertheless useful to refer to what distinguishes "dynamic" languages such as [[Perl]] and [[Python programming language|Python]] from more traditional languages such as [[C programming language|C]], [[C Plus Plus|C++]], and [[Java programming language|Java]]. Not all languages considered dynamic will have all of the features below, and some non-dynamic languages will share some of them or have some way to achieve the same effect; the reader should assume that there are exceptions nearly all of the generalizations below.
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;
Traditional programming languages require that the program be annotated with extra information (such as [[Datatype#Explicit_or_implicit_declaration_and_inference|type declarations]]) that makes the compile-time checking possible. Dynamic languages dispense with these annotations because they use extra information available at runtime instead. In particular, they are [[dynamic typing|dynamically typed]], and use [[garbage collection (computer science)|automatic memory management]].
* 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.
 
[[User:K.lee|k.lee]] 02:52, 17 Feb 2004 (UTC)
 
=== Dynamic = dynamically typed? ===
 
Could anyone give an example of a dynamic programming language which is not dynamically typed, or a dynamically typed programming language which is not dynamic? -- [[User:ciphergoth|ciphergoth]] 20:05, 2005 Apr 5 (UTC)
Line 35 ⟶ 43:
:Maybe. I'm still not sure what exactly this article wants to classify as a dynamic language. [[pike programming language|Pike]] is a statically typed, high level, object oriented, interpreted language. Is it a dynamic language? I can't tell from this article. Its similar to a statically typed python with C-style syntax though. [[User:Generic Player|Generic Player]] 04:09, 6 Apr 2005 (UTC)
 
===Rewrite===
 
I just started this rewrite, but didn't have time to finish it. I leave the text here in the hope it's useful in a future version -- [[User:ciphergoth|ciphergoth]] 20:05, 2005 Apr 5 (UTC)
Line 41 ⟶ 49:
In [[computer science]], a '''dynamic programming language''' is a kind of [[programming language]] in which many tests to ensure that each computational step is valid are deferred until the operation is actually performed (at [[runtime]]) rather than taking place when the program is first prepared for execution (at [[compile time]]). They allow programs to change their structure as they run: functions may be introduced or removed, new classes of objects may be created, new modules may appear.
 
==Characteristics of dynamic programming languages==
 
===Advantages===
The term '''dynamic programming language''' does not have a precise definition, but it is nevertheless useful to refer to what distinguishes "dynamic" languages such as [[Perl]] and [[Python programming language|Python]] from more traditional languages such as [[C programming language|C]], [[C Plus Plus|C++]], and [[Java programming language|Java]]. Not all languages considered dynamic will have all of the features below, and some non-dynamic languages will share some of them or have some way to achieve the same effect; the reader should assume that there are exceptions nearly all of the generalizations below.
 
Traditional programming languages require that the program be annotated with extra information (such as [[Datatype#Explicit_or_implicit_declaration_and_inference|type declarations]]) that makes the compile-time checking possible. Dynamic languages dispense with these annotations because they use extra information available at runtime instead. In particular, they are [[dynamic typing|dynamically typed]], and use [[garbage collection (computer science)|automatic memory management]].
 
----
 
For a discussion on dynamic programming languages, see [http://lambda-the-ultimate.org/node/12].
 
==Advantages==
 
* Dynamic programming languages are generally somewhat easier for newcomers to programming, in large part because they need not understand the system of annotations referred to above in order to write programs
Line 68 ⟶ 67:
 
* This delay can be dramatically reduced almost to zero in practice however, for instance, the Objective-C programming language used a pre-loaded cache and a small bit of assembler code in order to reduce this overhead to a single operation.
 
----
 
That's a claim I've often heard. I've never seen anything to back it. Does anyone have any clue ?
 
[[User:Yoric|Yoric]] 14:25, 14 June 2006 (UTC)
 
 
= 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. [[User:K.lee|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.
 
[[User:K.lee|k.lee]] 02:52, 17 Feb 2004 (UTC)