leifaffles

Yes. Thanks.

Can you clarify what you mean about "real" macros vs AST macros? The only obvious extension to normal AST-style macros I can think of is fexprs, which re-run the macro procedure on every invocation (rather than once at read/build/macroexpansion/whatever time).

I think there is some broad confusion over "flow-based programming" implying "non-programmers using a graph editor to connect things". So I'm going to ignore that completely in favor of talking about flow-based programming for programmers.

Here's an example I have experience with:

The GRL research language [1] is a dataflow language for behavior-based robotics. It's a real programming language that batch compiles down to C code that runs in O(1) time and space (it's not Turing complete). It escapes from the "spaghetti code" problem you mention by providing an abstraction of a procedure as a compile-time rewrite rule that transforms the dataflow graph (for Lisp hackers, every procedure is basically a macro that can be passed around by value at compile-time).

(FWIW, graphical editors can actually be a useful and pleasant way to construct throwaway flow graphs, but aren't particularly useful for developing new abstractions (i.e. dataflow procedures or data types). They run into the spaghetti code problem you mention, by which the only way to reuse a chunk of functionality is copy-paste)

The system has been used for things like programming actual robots, Half Life bots [2], and motor control for interactive game-like thingies [3]. What it's really great at is managing stateful information over time. Things like moving averages, low pass filters, and other types of state machines (flip-flops, "just true" constructs, etc) all become first-class values in your programming language.

So how could this be used in a more flexible environment that isn't ideological about dataflow programming? While dataflow graphs may be limited in their expressiveness, we can use them to encapsulate many types of state machines, particularly those that change over time or in response to stimulus. Under this model, every self-contained flow graph becomes a thunk whose input values are determined by evaluating arbitrary expressions in the host language (and can be dynamically instantiated). For implementations of this technique, see [3]. Finally, [4] is an implementation of the stateful time-based dataflow constructs I wrote for a game in C#, which power things like motor behaviors, input processing, collision avoidance, animations, and interpolations. As a bonus, you can add events on top of these for a simple implementation of functional reactive programming.

So do you want to build a web app in a dataflow language? Maybe not. Do you want flow-based constructs in your programming language? Depending on what you're building, the answer could range of "Not really" to "I can't live without them."

[1] http://www.cs.northwestern.edu/~ian/grl-paper.pdf

[2] http://www.cs.northwestern.edu/~gdunham/flexbot/manual/grl_f...

[3] http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4...

[4] https://bitbucket.org/leifaffles/chad/src/d6a13c2315cce41dba...

The big elephant in the room is that this isn't really about metaprogramming. It's about the failure of the text as a means for manipulating of computer programs (e.g. eval on strings, reflection, method_missing, _getattr_, etc). It would be as if we represented and manipulated numbers as text strings.

Much like languages have more successful ways of representing numbers, some languages are more successful at metaprogramming. In particular, Lisp takes the view that the act of metaprogramming is really the act of writing application-specific compiler extensions. The default behavior simply doesn't involve ripping apart strings and concating them back together.

This article tackles a lot of confusion that has come with the word over the past couple decades: http://www.thedailybeast.com/articles/2013/06/05/neoconserva...

I agree. It'd be great if we could just ask him, but I don't know if I've ever heard him say something that wasn't manipulative and to his perceived political advantage.

See also: http://en.wikipedia.org/wiki/Venona_project

I found this short fracking discussion enlightening: http://www.youtube.com/watch?v=NW_xJqPjE_I#!

This seems like an argument for more manual management of state, less abstraction, and more human compiler. That isn't to say we shouldn't have that discussion, but it is part of that discussion.