Lambda the Ultimate

Replace "visual dataflow" by "object-oriented" or just about any other paradigm and your statement is still true. What other visual dataflow paradigms have you used? Do they handle state and nondeterminism well? Are they higher-order?

I haven't used higher-order or stateful visual tools, but I can imagine how you'd go about making those additions. I still don't think that doing everything "visually" is a good idea - encoding something as simple as "(-b + s*sqrt(b^2-4ac))/ 2a" becomes quite annoying with boxes and wires. And I don't think doing everything with "dataflow" is a good idea. Actually, this makes it sound like you agree:

Replace "visual dataflow" by "object-oriented" or just about any other paradigm and your statement is still true.

The way I see it, most of the "paradigms" that are baked into languages can and should instead be modeled functionally in a single core language. This meta-paradigm of first crafting an architecture that defines a custom "paradigm" against which the rest of the code is written seems more promising as a general approach than a language that presents a small handful of paradigms to present to the programmer.

Yes, I agree with you. A language like Max/MSP or OpenMusic just changes the default paradigm (the one the others are built on). It is a good default for music, since the GUI and the program are almost identical (you can see immediately what control knobs do and change it if it's not right). Equations like "(-b + s*sqrt(b^2-4ac))/ 2a" aren't programmed in dataflow, they are defined as text in their own boxes. The behavior of Max/MSP is similar to functional reactive programming, except that glitches are avoided by programmer convention and not by the system (this makes the implementation *much* simpler). OpenMusic is even more multiparadigm: it is built on top of Common Lisp and any Lisp function can be used in the dataflow layer.

Why does that make the implementation much simpler?

The lack of strong semantics, such as synchrony / glitch prevention, probably leads to *more* complex implementations once you want to start optimizing things. In the case of Max/MSP, they already hit this wall. E.g., to add parallelism, they're adding an explicit parallel polyphony component, instead of taking advantage of the overall data flow model.

i continue to try to grok the evolution of frp (pre-arrows, arrows, post-arrows, etc.) and trust that some day it will have sort of come full circle in something of a zen like way, such that we can all use it to do seemingly imperative things in really nice clean safer ways, and we can all thumb our noses at plain old unconstrained imperative badness. (of course, by then maybe the Max people will have retired on their own private island with all the money they've been making in the meanwhile. d'oh.)

In the case of Max/MSP, they already hit this wall.

Yes, you're right. If the implementation would enforce a stronger semantics, programs would be simpler and less prone to strange behavior. I recently showed a number of expert Max/MSP programmers at IRCAM how easy it was to create glitches in Max/MSP, and their reaction was "Oh, but your program has an error! No Max programmer would do things that way!". The Max/MSP programmer community has assimilated its limitations so they do not feel them as limitations. But Max/MSP programs occasionally have strange behavior that remains unexplained.

It's an impressively product environment, but they are cognizant of oddities (and subtleties of use) like this. They even practice (manual) boilerplate approaches to get around it.

To hit a wall with respect to optimization, optimization would have to be the goal. Parallelism is managed with an explicit polyphony component because they're typically pairing off note/gate events to instances of a monophonic synthesizer. There's no way that "taking advantage of the overall data flow model" would help in this respect since explicit instantiation is exactly what they're after.

The hope was that they could get the parallelism from the runtime. They hit a complexity wall -- perhaps it was due to legacy issues, and not the language (but the ad-hoc form of determinism in the language mentioned earlier makes me skeptical of this). Not being able to extract parallelism from computationally intensive dataflow music language suggests something went wrong, however.

It is already possible to do higher order programming in Max. "Modules" can take arguments and those arguments can be names of other modules. Using this, you can write a module that, given a name, instantiates the module within itself and connects it to its inputs and outputs. You'll likely want one version of this "instantiator" module for every reasonable combination of input and output port numbers. It's not pretty, but it works.

The Ptolemy project is so tantelizing. I want it to somehow magically transition from a mature research tool to something of industrial robustness (whatever that subjective might mean), if only so more people could become aware of it.

Ptolemy II does look impressive at first glance. But I am puzzled because they seem to misrepresent Esterel's synchronous model. In the Ptolemy II documentation, the Synchronous/Reactive model (SR) is identified with Esterel. They say (on page 23):

Moreover, in most realizations, modularity is compromised by the need to seek a global fixed point at each clock tick.

This is not true of Esterel: there is no one global clock signal, and only local fixed points are needed among the signals involved in each transition. Esterel is completely modular.

You are still in a language/environment where both iteration and recursion are fundamentally hard to express.

i witnessed a demo of LabVIEW once where iirc (my memory is fuzzy and I don't use the product myself) iteration/recursion were easily done by having a type of box connector that went from output back to input on the same box.

There are a few variations of getting around this in visually-compatible ways.

You can get recursive forms with Haskell-style FRP programs. Ptolemy has some languages that go further, letting you specify stuff like differential equations. On the other end, a lot of systems provide a visual macro language and/or lazy component instantiation.

I'd like to think that we'll see interesting programming language / programming environment pairings emerge in the next few years because of pressure from the digital art community, but I don't any rapid changes.

There is some progress already. Apple's Quartz Composer has support for a box in which you can key in a JavaScript function. It also has another box for keying in image processing kernels in C-like code. You can connect output pins to input pins to create feedback loops (essentially recursion). Macro patches can iterate other patches.

Btw this also came up in a different thread context.

I actually disagree somewhat with the "easy to teach" comment. In most cases, I find that non-programmers have an easier time with Processing than they do Max. The problem with Max is that some easy things are easy, but other easy things are quite difficult due to the dataflow approach. Furthermore, many aspects of the language are downright silly. For example, simply moving a module on the 2D plane can result in your patch no longer working properly.

simply moving a module on the 2D plane can result in your patch no longer working properly

There's a reason for that. It's because of the Max conventions on execution order, which are important to ensure deterministic behavior. So if you want to dismiss this as "silly", you have to address the behavioral issue too!

In order to get a program to fail or not even compile in haskell, all you have to do is to simply move a function or even just change the indentation of an expression. This problem with textual syntax in logo is one of the reasons behind creating scratch as "the next logo".

It's "silly" simply because one output should not be allowed to be connected to two inputs in the first place. It would be simple to enforce that an appropriate trigger object be used instead negating the whole issue.

I'm not as convinced on the one output / two input issue.

Not being able to safely move a component around is a usability problem in a tangible, visual language. Tying scheduler semantics to this was an odd choice. Other schemes, in the presence of cycles, may also be odd, but I refuse to believe this was the right choice (e.g., Esterel gets around this).

I'm not sure I follow. Requiring a trigger object would eliminate the problem related to moving components around. If programs should be dependent on the order of operations in the first place is another question.

It's often harder to do something if you already know what you want to do in these visual programming environments.

But it's way easier to experiment, due to the real-time feedback, which is why I think they're popular (and why electronic musicians still love the plugging in wires paradigm).

I haven't worked with the music languages under discussion at all. However, my experience with tools like Simulink and Ptolemy has been that structural properties (connections between components) are more easily expressed and understood using diagrams, while behavioral properties (what a component does) are often more easily expressed in text. Certainly you can express structure in text -- that's what everything from your language, through the various FRP systems, to nesC do. But in my opinion it's a lot easier to work with structure by manipulating lines and blocks. Similarly, you can express complex behaviors visually, but it's often easier to do so in text. I can recall several Simulink modelling experiences where I started trying to build a complex component behavior by diagrammatically composing simpler parts in complicated ways. The resulting diagram was difficult to understand and hard to debug. I eventually broke down and rewrote the whole thing as an S-function block. Ideally, I'd like a language to allow me to form new components using either text descriptions of behavior or as a structural composition of other components -- whichever works best for the task at hand.

What is the meaning of "structure" here? "Connections between components" doesn't seem clearly distinguishable from behaviour to me, unless all the components in question conform to some sort of standard interface (like logic gates).

Perhaps a graphical interface to monads would make them easy for the masses to use? :-)

I don't think it's necessary to have a single logic-gate-like standard interface (Ptolemy II is an excellent example of heterogeneous component composition). I suppose that what defines a "component" in the sense I meant above is something that has input and output ports, and specifies some transformation from inputs to outputs (the behavior of the component). We are, after all, speaking of dataflow languages. Or, in the case of Simulink, signal-flow languages.

Of course, one can create a complex behavior by building a structure composed of simpler behaviors. So in that sense you're correct that the concepts are not "clearly distinguishable". But sometimes it's esier to decribe the behavior you want as an textually described algorithm instead of as a visual composition of primitives. That's why I'd like to have a language that allows complex behavior to be built both ways.

And yes, a graphical interface to monads might help... although my impression is that the problem most people have with monads isn't so much using them, as figuring out when and how to construct them.

I find it to be domain dependent. For example, textual descriptions of animations are hard to deal with. Seeing a path, destination, etc. are useful. Not to say graphical representations are necessarily easy to deal with ;-)

Sometimes, I want the leaves of computations to be textual -- e.g., arithmetic -- and higher level manipulations to be graphical -- e.g., the music circuit. Othertimes, I want the leaf to be graphical -- a teen -- and the composed orchestration textual. Sometimes, I want to be able to slip in and out of both modes. There isn't a system that lets me comfortably do both -- I suspect a more restricted and library aware version of FRP is the best next bet -- but I'll keep searching :)

It's probably worth mentioning Michael is credited on the Csound wiki page.

1. I suspect Max has more patches. E.g., look at, http://www.maxobjects.com/?request=a&operateur=AND&id_format=0&id_plateforme=0&Submit=OK . 261 pages of lists of patches with the letter 'a', with each paging showing 15 objects.

2. I agree about performance. Interestingly, and I've written this here before, the dataflow model is very appealing performance-wise because of multi/manycore opportunities, which are finally starting to be explored.

2. I agree about performance. Interestingly, and I've written this here before, the dataflow model is very appealing performance-wise because of multi/manycore opportunities, which are finally starting to be explored.

Any recent work to point us at? I've seen claims about how data-flow will scale better across many cores, but I haven't seen any language that follows through on the claim. Still, I'd love to see it, but I won't let the claim by without evidence.

Claims are always made about how functional programming languages/actors/... will scale to many cores, but then there is
no fast many core version of Haskell/Erlang/Scala to show off... Many/multi-core itself with unrestricted memory models might be a dead end in of itself, and GPU/restricted memory model processing (e.g., Larabee) might be more promising. Here data-flow shows promise as it can match how textures are transformed and referenced on the GPU.

I agree about Erlang/Haskell/Scala. Bryan Sullivan had a wonderful Bay FP talk about Realworld / Parallel Haskell saying essentially the same thing.

For parallel dataflow.. what about Labview? I haven't played with it, but they seem to be getting success with parallelization. Caveat: the demos I have seen seem very write-once, though my FRP background may bias me.

Manycore seems biased towards simpler cores, at least from the architecture guys I've talk to (as opposed to, say, most speculative architectures) -- Larabee is an example of that. Furthermore, a lot of the proposed 'manycore' OSs focus on partitioning more than just CPU (e.g., network or bus), which seems in line with dataflow methodologies. My concern is how it scales from controlling machines (labview) to applications (Flapjax) -- I've been focusing on core libraries this year and will start to poke at it next year once those are ready :)

Btw, I'll be at MSR Redmond this summer with Ben Livshits and browser or security folks -- if you ever visit, I'd like to meet you :)

Its been done. Still, you put yourself in a straight jacket with dataflow, even when text based. Text excels at abstraction, so the trick is to throw some abstraction in the mix.

Have you looked at Lucid?