No, that is introspection (also known under names such as RTTI, object metadata, and some others). Metaprogramming is the act of programming your programming tools/program itself.
Introspection is a form of meta programming (if you're making choices based on what you learn from introspection).
When we say "meta x" we mean talking about x, e.g. "meta discussions" on HN is discussions about discussions. Meta programming is writing programs about the program, which can also just be doing introspection and making choices based on that.
You are mistaken. If normal programming constructs did not allow the programmer to choose behavior based on input, then every program would have a fixed execution path, would have the same output every time. and metaprogramming itself would not be possible. You are arguing that function arguments are metaprogramming, which is not what the use of the word 'metaprogramming' connotates. Metaprogramming, in the domain of computer programming, specifically carries the intention of programming in such a way that one or more sub-programs are created from the perspective of the one the programmer is working in.
"If normal programming constructs did not allow the programmer to choose behavior based on input, then every program would have a fixed execution path, would have the same output every time. and metaprogramming itself would not be possible."
There is a difference between program control flow based on user input and generating program logic during the course of execution.
I posit that you may have metaprogramming in a progam that has the same output every time.
To me, metaprogramming is writing code which generates or modifies behavior, logic or program flow control. This may happen at compile or run time. Wether generating a closure and setting an attribute on a JS object or using "eval" to define the function, the effect is the same -- the object's implementation was not defined by the original source or environment.
For instance, this is metaprogramming:
def decorate(obj)
obj.send :define_method, :yay, (Proc.new{ puts "woohoo!"})
end
a = File.open('tmp.txt','w')
decorated_a = decorate(a)
a.yay
Here, there is no eval, but a's implementation changes at runtime. The same is trivially reproduced in JS.
edit: the difference between the original article and this is that the original article makes modifications directly to the original objects, and not to arbitrary objects, which i suppose is why you object to referring to this as meta-programming.
>You are arguing that function arguments are metaprogramming
No, I'm not. We seem to have a terminology mismatch somewhere. Asking a function how many arguments it takes and then taking some action based on that fact would be meta-programming, but taking input isn't.
The number of arguments a function takes is the return value from a function which was passed, as an argument, another function. That is not metaprogramming as it is known by programmers. It is a branch in the program which will be determined at runtime, a feature of computer programming.
>That is not metaprogramming as it is known by programmers.
By what programmers? I have a feeling we are coming from completely different places here.
What do you call what Smalltalk programmers do? In Smalltalk, what we call "meta-programming" happens a great deal but I've never seen eval called in a Smalltalk program ever.
Have you read the book "The art of the meta-object protocol"? Everything in that book is meta-programming yet I don't recall eval being used anywhere, and much of the code was simply to allow programs to discover things about the program itself at runtime.
I have not read that book, but the extensibility features of the CLOS are a world apart from some fixed set of API calls used to make decisions based on object metadata at runtime. CLOS is hugely powerful an entirely extensible down to the core of the Lisp axioms, and nothing at all like some simple set of runtime API calls.
That a kind of metaprogramming is not as powerful as another kind does not prevent it from being metaprogramming.
Some C++ template trickery is clearly metaprogramming - at least, it is to me and people in the C++ community who refer to it as such. It does not give the flexibility that's available in a Lisp, but it's still metaprogramming.
C++ templates are clearly metaprogramming in every way. I cannot think of a case in which they are not metaprogramming. If you brought up C++ metaprogramming with the assumption that I would argue it's not metaprogramming, you were mistaken.
Comments
Metaprogramming doesn't require eval. Meta programming is being able to ask the program about itself and make changes to it during run time.
No, that is introspection (also known under names such as RTTI, object metadata, and some others). Metaprogramming is the act of programming your programming tools/program itself.
Introspection is a form of meta programming (if you're making choices based on what you learn from introspection).
When we say "meta x" we mean talking about x, e.g. "meta discussions" on HN is discussions about discussions. Meta programming is writing programs about the program, which can also just be doing introspection and making choices based on that.
You are mistaken. If normal programming constructs did not allow the programmer to choose behavior based on input, then every program would have a fixed execution path, would have the same output every time. and metaprogramming itself would not be possible. You are arguing that function arguments are metaprogramming, which is not what the use of the word 'metaprogramming' connotates. Metaprogramming, in the domain of computer programming, specifically carries the intention of programming in such a way that one or more sub-programs are created from the perspective of the one the programmer is working in.
"If normal programming constructs did not allow the programmer to choose behavior based on input, then every program would have a fixed execution path, would have the same output every time. and metaprogramming itself would not be possible."
There is a difference between program control flow based on user input and generating program logic during the course of execution.
I posit that you may have metaprogramming in a progam that has the same output every time.
To me, metaprogramming is writing code which generates or modifies behavior, logic or program flow control. This may happen at compile or run time. Wether generating a closure and setting an attribute on a JS object or using "eval" to define the function, the effect is the same -- the object's implementation was not defined by the original source or environment.
For instance, this is metaprogramming:
def decorate(obj) obj.send :define_method, :yay, (Proc.new{ puts "woohoo!"}) end
a = File.open('tmp.txt','w')
decorated_a = decorate(a) a.yay
Here, there is no eval, but a's implementation changes at runtime. The same is trivially reproduced in JS.
edit: the difference between the original article and this is that the original article makes modifications directly to the original objects, and not to arbitrary objects, which i suppose is why you object to referring to this as meta-programming.
>You are arguing that function arguments are metaprogramming
No, I'm not. We seem to have a terminology mismatch somewhere. Asking a function how many arguments it takes and then taking some action based on that fact would be meta-programming, but taking input isn't.
The number of arguments a function takes is the return value from a function which was passed, as an argument, another function. That is not metaprogramming as it is known by programmers. It is a branch in the program which will be determined at runtime, a feature of computer programming.
>That is not metaprogramming as it is known by programmers.
By what programmers? I have a feeling we are coming from completely different places here.
What do you call what Smalltalk programmers do? In Smalltalk, what we call "meta-programming" happens a great deal but I've never seen eval called in a Smalltalk program ever.
Have you read the book "The art of the meta-object protocol"? Everything in that book is meta-programming yet I don't recall eval being used anywhere, and much of the code was simply to allow programs to discover things about the program itself at runtime.
I have not read that book, but the extensibility features of the CLOS are a world apart from some fixed set of API calls used to make decisions based on object metadata at runtime. CLOS is hugely powerful an entirely extensible down to the core of the Lisp axioms, and nothing at all like some simple set of runtime API calls.
That a kind of metaprogramming is not as powerful as another kind does not prevent it from being metaprogramming.
Some C++ template trickery is clearly metaprogramming - at least, it is to me and people in the C++ community who refer to it as such. It does not give the flexibility that's available in a Lisp, but it's still metaprogramming.
C++ templates are clearly metaprogramming in every way. I cannot think of a case in which they are not metaprogramming. If you brought up C++ metaprogramming with the assumption that I would argue it's not metaprogramming, you were mistaken.