An aphorism on metaprogramming

http://oyster.diiq.org/post/35892719382/aphorism-metaprogramming-involves-three-objects

by akkartik • 14 years ago

23 15 14 years ago

oyster.diiq.org

gruseom4• 14 years ago

This might be the nicest summary I've seen of the Lisp style of metaprogramming or, if you prefer, homoiconicity.

diiq• 14 years ago

Like many koans, I'm afraid it probably only makes sense to someone who already knows; I suspect it's completely meaningless to someone who hasn't already had a chunk of direct experience.

kaizen-konpusai• 14 years ago

To fix that it probably only needs one or two really good examples, though. I find the lack of examples to be the most common cause of misunderstanding. The reason the experienced person understands is because they have their own examples already.

gruseom4• 14 years ago

I hope that's not true. A koan's job is to thwart understanding. This concept, on the other hand, is simple and beautiful and it ought to be possible to explain it — though perhaps not without a few well-chosen examples. (Edit: kaizen-konpusai beat me to it on the latter.) For fun, I took the liberty of revising your aphorism (don't be mad. I mean it as a tribute ;)) and adding one explanatory bit. Do you think anything has been lost?

Metaprogramming involves three things: the code as text, the code as program, and the code as data.

The text (often called the source code) is what programmers read and write. The program is what the code does. The data is how the code is represented to other programs.

A good language for metaprogramming requires two things: the program must be easily expressible as data, and the text must clearly evoke both the program and the data in the mind of the coder.

recursive• 14 years ago

I'm not sure how representative I am, but as someone who doesn't really understand what meta-programming is about, my impression is that it's a combination of nonsensical comparisons (e.g. I don't understand the difference between text and data) and vacuous truths.

I suspect this is a reflection on me more than the koan, but I also think my reaction would probably not be uncommon among the unenlightened.

freyrs3• 14 years ago

In non-homoiconic languages I think this aphorism is more apt:

> Metaprogramming is the language feature that helps you write code that you won't be able to understand once the cocaine wears off.

Rickasaurus• 14 years ago

In case you didn't know: "Languages in which program code is represented as the language's fundamental data type are called 'homoiconic'."

From: http://c2.com/cgi/wiki?HomoiconicLanguages

I didn't.

gruseom4• 14 years ago

There's an ambiguity in that definition: what does "represented" mean? It can mean "represented as source code", i.e. for consumption by the programmer, or it can mean "represented as runtime state", i.e. for consumption by the machine. The first is what the OP means by code-as-text and the second is what the OP means by code-as-data.

A program always has both kinds of representation. Without a textual representation, no one could write or read it. Without a runtime representation, it couldn't be executed. But usually it is complicated to translate between the two. In Lisp (the classic homoiconic language), these representations are so similar that it is trivial to translate from one to the other and back again. That's what makes Lisp good for metaprogramming (writing programs that manipulate other programs): it's so easy to go back and forth between the human-friendly representation (source code) and the runtime representation (data) that a whole class of new techniques arises.

ericbb• 14 years ago

What's "code-as-procedure" supposed to be? Denotation?

And how could "code-as-procedure" fail to be easy to express using "code-as-data"?

Isn't it more essential that "code-as-data" should be easy to express in "code-as-text"? (As that's where languages like Lisp and ML, that have quasiquotation, excel).

twelvechairs• 14 years ago

Someone yell at me if I am wrong (self taught - with all the ups and downs implied), but to me these are not good names. A few points on this:

* 'code-as' is a bit of a strange statement as it implies two-steps from an original object - as you are taking something encoded ('code') and translating it to something else ('as').

* 'code-as-text' should be 'code-as-representation' at least (you needn't represent anything as text if you dont want to - it could be coloured geometric shapes...)

* I don't understand what 'code-as-procedure' means either. Is this an abstract-syntax-tree or just platform-executable-code?

* 'code-as-data' is meaningless because everything is data, both the text and procedure... Does the OP mean something platform-executable? Or something within a type system?

Good topic to launch discussion on though....

tinco2• 14 years ago

Let me try to explain it using a bit more consistent terms. Code models the behaviour of a system, let's replace all instances of 'code-as' with 'behaviour-as' to avoid confusion. So we reason about the language in which a behaviour model is expressed.

'behaviour-as-text' is the serialization of the behaviour model according to the grammar of the language.

'behaviour-as-data' is the model representation as it is viewed and modified in the model.

'behaviour-as-procedure' is the meaning of the model in the sense of execution. The semantics of the model.

So this text says that the semantics of the behaviour model need to be easily expressed as data, and the textual representation of the model must clearly show both its semantics and its data representation.

tinco2• 14 years ago

So the freaky thing about metaprogramming is that the model changes itself right? The aphorism in three simple sentences:

1 "data must express procedure"

2 "text must express procedure"

3 "text must express data"

This shows that text both directly expresses procedure by rule 2, and indirectly by rule 1 via rule 3. This indirection step allows recursion to take place (i.e. the data contains a model in the same language as it is defined in) that is used for the model to reason about itself.

An aphorism on metaprogramming

Related Stories