I'm the author and I appreciate the insights. I wrote the article about what I consider to be building blocks of metaprogramming. I don't agree at all that eval() is the only piece of JS code that is metaprogramming. I believe that being able to dynamically define methods on objects at runtime is an example of "code that writes code" and hence metaprogrmming. YMMV.
No, that is simply programming with dynamic features. Nearly all modern programming tasks involve this.
If you would like to look at some interesting JavaScript metaprogramming, check out projects like Objective-J/Cappuccino, Clamato, BiwaScheme, HotRuby, and a Python one I'm forgetting the name of (not Pyjamas, that does not run itself in JavaScript, it is compiled by a different language.)
These pre-process some other types of code into native JavaScript structures which execute in the browser or JavaScript interpreter. They are distinct from inserting snippets of live generated code from strings into a system that is already live (as in eval() and friends) to modify it at runtime. That is one of the worst ways to use metaprogramming. What you want is a system that is self-hosting, in order to let you express yourself more deeply in the language. That way, your metaprogramming constructs execute in a controlled environment instead of chaotically determined by various factors at runtime. Lisp is the prime example of this.
In his defense, I'd say that the line between "metaprogramming" and using the features a dynamic language gives you is fuzzy. I'm not sure if I consider changing the semantics of a data type in Lua through its metatable metaprogramming or not, for example.
Generating source code at runtime definitely counts as metaprogramming, but doing that and having to re-parse it is probably the coarsest and most error-prone way. Lisp routes around this by working with ADTs directly, but that forces a lot of other trade-offs in the language design.
If a compiler is implemented in the language it compiles, and exposes compilation again to the program it compiles, then the implementation is metaprogrammable.
Your point? You said that someone should look to these systems as cases of "metaprogramming". Now you say that they are "metaprogrammable". You seem to have a very specific notion of metaprogramming, what exactly would you consider to be a prototypical use of it?
Comments
I'm the author and I appreciate the insights. I wrote the article about what I consider to be building blocks of metaprogramming. I don't agree at all that eval() is the only piece of JS code that is metaprogramming. I believe that being able to dynamically define methods on objects at runtime is an example of "code that writes code" and hence metaprogrmming. YMMV.
No, that is simply programming with dynamic features. Nearly all modern programming tasks involve this.
If you would like to look at some interesting JavaScript metaprogramming, check out projects like Objective-J/Cappuccino, Clamato, BiwaScheme, HotRuby, and a Python one I'm forgetting the name of (not Pyjamas, that does not run itself in JavaScript, it is compiled by a different language.)
These pre-process some other types of code into native JavaScript structures which execute in the browser or JavaScript interpreter. They are distinct from inserting snippets of live generated code from strings into a system that is already live (as in eval() and friends) to modify it at runtime. That is one of the worst ways to use metaprogramming. What you want is a system that is self-hosting, in order to let you express yourself more deeply in the language. That way, your metaprogramming constructs execute in a controlled environment instead of chaotically determined by various factors at runtime. Lisp is the prime example of this.
In his defense, I'd say that the line between "metaprogramming" and using the features a dynamic language gives you is fuzzy. I'm not sure if I consider changing the semantics of a data type in Lua through its metatable metaprogramming or not, for example.
Generating source code at runtime definitely counts as metaprogramming, but doing that and having to re-parse it is probably the coarsest and most error-prone way. Lisp routes around this by working with ADTs directly, but that forces a lot of other trade-offs in the language design.
What you're describing is a compiler, which is also not metaprogramming.
If a compiler is implemented in the language it compiles, and exposes compilation again to the program it compiles, then the implementation is metaprogrammable.
Your point? You said that someone should look to these systems as cases of "metaprogramming". Now you say that they are "metaprogrammable". You seem to have a very specific notion of metaprogramming, what exactly would you consider to be a prototypical use of it?