Home » forums » LtU Forum

MCG: A Visual Functional Programming Language

Hi everyone,

It's been a while! Some of you might remember me posting here a few years ago about my adventures with type systems and stack-based languages. For the last couple of years I have been head's down working on a visual functional programming language at Autodesk. The language is called MCG (Max Creation Graph) and is part of the commercial 3D animation, modeling and rendering software package 3ds Max. I've written a blog post about MCG that introduces the language to a technically savvy audience.

As some of you may know visual programming languages are quite commonplace in 3D software packages. A few examples include: Houdini, Grasshopper, Softimage ICE, Fabric Engine Canvas, Dynamo, NUKE Compositing, and more. However, I can't find much mention of these languages in the literature.

Switching from designing programming languages as a hobby to doing it professionally has been very interesting! I found myself spending a lot less time consulting the literature and spending more of time responding to customer needs and feedback. Now that MCG is shipped and being used, I'm interested in reconnecting with the academic community. I am wondering if anyone has some suggestion about what aspect of MCG might be of the most interest for researchers, and what type of publication I should pursue (e.g. technical report, experience report, research paper, or simply stick to non-academic publications). Any tips or suggestions would be most welcome! I'm also interested in exploring potential collaborations with researchers so please reach out to me if this is something that might interest you.

Thanks!

By cdiggins at 2015-10-31 16:59 | LtU Forum | previous forum topic | next forum topic | other blogs | 6246 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Looks Solid

Read it. Looks solid, congratulations.

I myself am not a real fan of visual languages, though it certainly looks pretty and I can imagine visual languages make sense in the context of 3ds max.

Is there a fall-back to text underneath?

By marco at Sat, 2015-10-31 19:26 | login or register to post comments

Thanks Marco! There is a

Thanks Marco! There is a generated text language for debug purposes but it isn't really appropriate to use for generating graphs since it uses variables. I am experimenting with parsing a pseudo-C# that has no statements to enable people to write graphs in text.

By cdiggins at Sun, 2015-11-01 12:06 | login or register to post comments

It looks like Quartz

It looks like Quartz Composer/VVVV/other connect the block languages without their liveness features. It has a visual syntax for functional programming, but you haven't really explored a visual experience yet, is that accurate? Visual syntax is somewhat more accessible than textual syntax, but I feel that the full promise of visual programming is only realized with tighter feedback loops.

As an example of how liveness could be applied, check out DesignScript (also from autodesk):

https://www.youtube.com/watch?v=h0Sk1w7xU4Q

The abstractions are non-functional mostly, but I wonder if that has a huge influence on being able to provide live feedback. On the other hand, there is Conal's tangible functional programming, but this mostly jumps out of the connect-the-block visual paradigm.

By Sean McDirmid at Sat, 2015-10-31 23:38 | login or register to post comments

Thanks Sean

> "but you haven't really explored a visual experience yet, is that accurate?"

You mean it isn't a visual experience because updates to the graph aren't updated in real-time in the scene? This is something I would like to do. Or did you mean the visual syntax is very sparse (a very deliberate choice)

By cdiggins at Sun, 2015-11-01 12:39 | login or register to post comments

You go VPL because you want

You go VPL because you want to provide a better UI to the user than a stuttering text edit/debug loop. So what you have is visual syntax for a functional language, but it doesn't really feel like a VPL yet. In particular, there doesn't seem to be much benefit to using this syntax over a textual syntax since the visual syntax is as dead as textual syntax typically is. A visual programming experience is supposed to be more concrete (as part of their core usability benefit) and the code I'm seeing in the blog post and video provides none of that. So if you want to keep it abstract, why not just go textual?

Live update might help, but I don't see how the feedback could be framed very well with respect to very abstract functional code. You can't just design the syntax/semantics first and tack experience features on later.

By Sean McDirmid at Sun, 2015-11-01 14:52 | login or register to post comments

balancing direct and abstract

First... excellent critique :)

So if you want to keep it abstract, why not just go textual?

Maybe two useful datapoints:

* In our world, we assume users can read/edit SQL, but hate writing it. So visual interactions to guide authoring code, and textual for small edits, can be palatable.

* We're finding abstract elements are great visual hooks for direct interaction. In MCG, the ability to connect a function-valued-block as input for a higher-order block was slick. In our world, clicking on a code abstraction ("odds: all elements with a value that is odd") and having that get highlighted in running program pane is pretty powerful. So, direct interaction with visual abstractions, whether when mixed with other visual abstractions or concrete values, can be great!

By lmeyerov at Mon, 2015-11-02 03:40 | login or register to post comments

There is of course a big

There is of course a big opportunity with a VPL to help the user write code, even given very abstract constructs. But I don't see that happening (yet?) in this case.

Also, the ability to see what an abstraction is doing is great for reading, comprehension, and debugging, but it doesn't help much with writing code. Writing is a much harder problem, how do we know when to use these abstractions at all? You must really read and learn the manual.

Visual PL design is hard, perhaps much harder than normal PL because the expectations are so much higher on usability.

By Sean McDirmid at Mon, 2015-11-02 06:11 | login or register to post comments

CMU Genie Pascal et. al.

My wife got Secret Coders

Anyway, It all makes me fondly think of the (terribly slow and painful even at the time; we were on Mac Plus machines!) Genie programming environments used in CMU undergrad back in the dark ages ('88-'92). I want that kind of "painting by numbers" IDE for my kid.

By raould at Mon, 2015-11-02 19:34 | login or register to post comments

Aardappel

Just a thought. You could look at Aardappel's dissertation.

By marco at Sun, 2015-11-01 15:06 | login or register to post comments

Cool

That's cool. I personally think all programmers can benefit from tools like this - not just those using 3d software tools.

Functional programming languages typically focus on "sum" types (the dual of "product" types i.e records). In C-like languages (that have them) sum types seem to be called "enums" (Rust, Swift). Functions are then defined by case analysis on the argument (since it is a disjunction of fields). In textual programming languages pattern matching is an important tool in making writing such functions easier. Visually sum types would consist of a sequence of output ports - each of which would be required to be connected (corresponding to exhaustiveness checking in functional compilers) and which cannot merge. It would be interesting to work out what might correspond to pattern matching - or if there are visual alternatives.

It's cool that you support higher order functions. However, the extra "Function" port on every node seems a little redundant. One alternative you might consider is to put that port on the title of the node.

As you point out partial application works out well (you just hook up the inputs).

To support anonymous higher order functions you'll need to allow cycles (since the output of the lambda becomes an input).

I can offer you a few other ui ideas you might want to consider

1) Tree views for projecting fields of record types
2) Type nodes and explicit input ports for generic type parameters (for cases where inference isn't possible)
3) Generate a textual (pseudo-code) representation of the graph automatically with hyperlinks back to the graph nodes - this allows an easy to understand overview of potentially complex graphs which can look like a "forest of spaghetti".
4) Explicit "fork" and "join" nodes - which avoids the spaghetti-ish effects of having multiple links to/from the same port and which allows you to retarget links simply with drag and drop.

By chrisoliver at Sun, 2015-11-01 00:02 | login or register to post comments

Sum Types

I agree the extra "Function" port on every node is a bit redundant. I'm thinking of moving towards a special "lambda abstraction" node (perhaps I'd call it "to function") to minimize the visual noise.

Your ideas on visual representations of sum types is interesting, thanks for sharing!

By cdiggins at Sun, 2015-11-01 12:46 | login or register to post comments