I just read it, and it is indeed what I have just said. Unless you would like to quote a specific part of the article, instead of simply pasting a link to a page on Wikipedia?
In my next reply in our conversation I was going to quote exactly this article:
"The language in which the metaprogram is written is called the metalanguage. The language of the programs that are manipulated is called the object language. The ability of a programming language to be its own metalanguage is called reflection or reflexivity."
Reflection is what I was describing. Asking a function its arity is indeed accomplished by passing said function to some other function, but if you want to find the source code for this function look for "reflection" because that's where it should be defined.
"Metaprogramming usually works through one of two ways. The first way is to expose the internals of the run-time engine to the programming code through application programming interfaces (APIs). The second approach is dynamic execution of string expressions that contain programming commands. Thus, 'programs can write programs'. Although both approaches can be used in the same language, most languages tend to lean toward one or the other."
You seem to only accept the second kind as meta-programming. What do you base your description on? Knowing that would make it easier to see where you're coming from and hopefully what the source of the misunderstanding is.
In general, yes, I would consider the second kind as more meta-ish. Even though I think literal strings are a terrible way to accomplish metaprogramming, a set of API calls for introspection is not what I would consider metaprogramming, since they will almost always be accomplished through runtime calls and do not actually generate any other code that can be further manipulated.
Reflection as it is defined in that passage is more of what I am talking about, yes. But I think most languages lack this, including JavaScript. Some good examples are Lisp, Template Haskell, and the macro tools available in OCaml. I have nothing against runtime features, but I do not really consider it metaprogramming if that is the only way to accomplish it, since you are effectively being locked out of a true meta-circular system as a programmer. This style of programming is what defines Lisp and many other languages in the functional realm.
Source introspection, AST manipulation and macro expansion very well may deserve their own term to distinguish them from other forms of dynamic programming. (by that, i don't mean vtables, i mean the other forms of programming your control flow.) However, the term metaprogramming is already defined to mean something more expansive than those two things. I can see how you might want to distinguish the particular forms of manipulation enabled through source modification from the obvious uses of first-class functions, especially if you've gone deep down the rabbit hole, but you're going to have to use a different term.
I just don't think first-class functions are metaprogramming. I have never heard them conflated before, and outside of the author's own writing, have yet to see another example.
Calling the examples just "fist-class functions" is being reductionist. The examples programmatically change the structure of the code. That fits the definition from Wikipedia:
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data ...
It's not manipulating the program as data. It is simply the program itself. If the program runs with its output being another program which runs, then that is a form of metaprogramming. In this case, the program is simply running. A collection of functions which accept arguments and return values directly is not what most people would consider metaprogramming. It's just a program.
JavaScript is entirely capable of doing metaprogramming, but in the article posted here, it does not.
It's adding structure (methods to classes) at runtime which normally would require writing source code. That is treating the program as data; it manipulates the object system as any other kind of data.
You seem confident that your definition of metaprogramming is the accepted definition, but I don't see evidence of that.
sword_symbol = "*********"
drew.metaclass.send(:define_method, 'swing') do |sound_effect|
puts "#{name}: #{sword_symbol} #{sound_effect}"
end
drew.swing 'slash!!'
I understand that to add the swing method without writing the source code to do it. This use is trivial, but it's easy for me to extrapolate to how one could make the newly created method depend on runtime information.
Comments
Your definition of metaprogramming is not the accepted one. http://en.wikipedia.org/wiki/Metaprogramming
I just read it, and it is indeed what I have just said. Unless you would like to quote a specific part of the article, instead of simply pasting a link to a page on Wikipedia?
In my next reply in our conversation I was going to quote exactly this article:
"The language in which the metaprogram is written is called the metalanguage. The language of the programs that are manipulated is called the object language. The ability of a programming language to be its own metalanguage is called reflection or reflexivity."
Reflection is what I was describing. Asking a function its arity is indeed accomplished by passing said function to some other function, but if you want to find the source code for this function look for "reflection" because that's where it should be defined.
"Metaprogramming usually works through one of two ways. The first way is to expose the internals of the run-time engine to the programming code through application programming interfaces (APIs). The second approach is dynamic execution of string expressions that contain programming commands. Thus, 'programs can write programs'. Although both approaches can be used in the same language, most languages tend to lean toward one or the other."
You seem to only accept the second kind as meta-programming. What do you base your description on? Knowing that would make it easier to see where you're coming from and hopefully what the source of the misunderstanding is.
In general, yes, I would consider the second kind as more meta-ish. Even though I think literal strings are a terrible way to accomplish metaprogramming, a set of API calls for introspection is not what I would consider metaprogramming, since they will almost always be accomplished through runtime calls and do not actually generate any other code that can be further manipulated.
Reflection as it is defined in that passage is more of what I am talking about, yes. But I think most languages lack this, including JavaScript. Some good examples are Lisp, Template Haskell, and the macro tools available in OCaml. I have nothing against runtime features, but I do not really consider it metaprogramming if that is the only way to accomplish it, since you are effectively being locked out of a true meta-circular system as a programmer. This style of programming is what defines Lisp and many other languages in the functional realm.
Source introspection, AST manipulation and macro expansion very well may deserve their own term to distinguish them from other forms of dynamic programming. (by that, i don't mean vtables, i mean the other forms of programming your control flow.) However, the term metaprogramming is already defined to mean something more expansive than those two things. I can see how you might want to distinguish the particular forms of manipulation enabled through source modification from the obvious uses of first-class functions, especially if you've gone deep down the rabbit hole, but you're going to have to use a different term.
I just don't think first-class functions are metaprogramming. I have never heard them conflated before, and outside of the author's own writing, have yet to see another example.
Calling the examples just "fist-class functions" is being reductionist. The examples programmatically change the structure of the code. That fits the definition from Wikipedia:
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data ...
It's not manipulating the program as data. It is simply the program itself. If the program runs with its output being another program which runs, then that is a form of metaprogramming. In this case, the program is simply running. A collection of functions which accept arguments and return values directly is not what most people would consider metaprogramming. It's just a program.
JavaScript is entirely capable of doing metaprogramming, but in the article posted here, it does not.
It's adding structure (methods to classes) at runtime which normally would require writing source code. That is treating the program as data; it manipulates the object system as any other kind of data.
You seem confident that your definition of metaprogramming is the accepted definition, but I don't see evidence of that.
"It's adding structure (methods to classes) at runtime which normally would require writing source code."
-- the linked blog post doesn't do this, though it is possible.
Then what is this?
I understand that to add the swing method without writing the source code to do it. This use is trivial, but it's easy for me to extrapolate to how one could make the newly created method depend on runtime information.Ruby, not javascript.