
MCG: Visual Functional Programming - tokenrove
http://area.autodesk.com/blogs/chris/mcg-visual-functional-programming
======
dgudkov
Looks like a rather solid system. Although, this approach when you have to
connect blocks with arrows (which also can be seen in many enterprise ETLs) is
not convenient, in my opinion. Text-based programming languages are convenient
because you don't have to explicitly indicate which line should be executed
after which. Function pipelining is so convenient exactly because it
eliminates explicit passing results from one function to another. That's why
in our EasyMorph ([http://easymorph.com](http://easymorph.com)), which is also
a some kind of visual programming language[1] used to replace scripted data
transformation, we pack data transformations in logical blocks (very much like
function pipelining) so that almost no arrows needed. Another point is about
project readability. When all blocks look the same it's hard to understand
what the function does. So we paid a lot of attention to designing distinct
and informative icons.

[1] [http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-
fun...](http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-
functional.html)

~~~
devonkim
The boxes and lines approaches work very well when you're doing coordination
programming tasks rather than algorithmic and numerical ones. Instead of
forcing people to use rigidly specified academic / formal systems like UML
sequence and activity diagrams, Visio has withstood the UX of most business
users' needs that have little background in programming. A lot of what your
system does seems to be a close analogue to what SRC Computers developed in
its compilers to perform dataflow analysis with some auto-vectorization logic.
However, a lot of the CPU-FPGA crossover works better with vector-centric
languages like Matlab or Fortran than primarily scalar constructs like in C or
Java.

One thing I can say with confidence is that general purpose visual programming
languages are extremely difficult to produce due to UX / UI expectations, but
for smaller companies significant progress can be made with domain specific
visual languages which your product seems to be aiming at. Good job avoiding
one of the tar pits of failed programming paradigms of the past century.

~~~
elcritch
What UI/UX expectations make it difficult to make visual programming languages
general purpose?

~~~
devonkim
One thing I observed as an everyday user and developer on a visual language /
ecosystem was that design patterns emerged that were really easy to do in most
text programs that were really cumbersome to do in block diagrams but I could
find almost nothing that was easier in a visual language than a textual one.
For example, most modern class-based OOP systems have virtual inheritance
possibilities where you can overload behaviors and we have compiler resolution
that determines what can and can't perform the override. I have not found an
easy way to show this visually across many block diagrams without introducing
a lot of confusion (eg. dotted lines instead of solid ones, collapsing box
groups together) because of issues like dynamic dispatch. This stuff is pretty
easy to form the constructs as a competent programmer but once I was in a
visual language I was flipping around pages and pages of pretty blocks that
started to get in the way rather than guide me towards understanding the 500
blocks I dropped down and the rats nest of lines pointing everywhere with
switch statements galore. In our system I tried to write dependency injection
and other elements of aspect oriented programming in but the inability for
easy to associate referential steps in our specific system really messed with
usability and thus debugging capabilities. As a power user I was not that much
more productive than a relative novice in our system, and that really bothered
me on what kept my productivity in the system from growing.

Eventually it all came down to inability for automatic, sensible scoping of
logical components to be performed in our software due to lack of awareness of
what the user is actually looking for because of lack of typing (we didn't
have data structures / types - numbers and strings were all the same raw data)
- all the analysis that could be done effectively for users was done following
program execution, not really static analysis of a dataflow / graph.
Everything was a side effect in a block diagram system just like how it can be
in OOP, but unlike in OOP I had a heck of a time pointing references to a
fragment under test to, say, a mock step easily (we did add them in eventually
but scoping the substitution was insane). We have automatic folding in text
editors that does pretty well, too, but grouping a bunch of randomly laid out
shapes on a canvas together and hiding them while selecting them with a mouse
was really painful for the minimal value it'd provide.

What happens is that the structure of the dataflow becomes a concern
orthogonal to the basic algorithmic steps like looping, string manipulation,
logical operators, arithmetic operators. Because most of the limitations of
software production happen due to people's lack of tooling or abilities to
reason about their data and behaviors efficiently / effectively, this means
that given the failures so far in visual programming systems we probably need
to re-think usability first before trying to develop a programming system
around it.

The reasons we were able to get much success in our product with a visual
programming paradigm was 1\. we used users' existing expectations from
products like Visio to help with onboarding / training 2\. we developed
complex logic like web requests in normal code (Java) and packaged them up
into block diagram components that are easy to configure, so it was a lot like
Automator constructs 3\. everything was fairly easy to trace during program
runs (required for auditors anyway)

This all came with a large amount of resource costs though which is why it
never really would have worked as a consumer product unfortunately.

~~~
elcritch
Fantastic! Really insightful feedback. How to do sensible scoping of logical
components has been something I've been trying to rethink recently. Currently,
you can read through text and imagine the logical components. But it'd be
interesting to see more discussion put into modes of visual expressions,
especially when combined with more textual information.

What would you classify as easy to associate referential steps? I've been
using html5 components to combine hierarchical structure while being able to
still use manual id/herd to provide the occasional "slice" outside the normal
data stack. However, it still requires modifying a textual code stack.

Also the aspect oriented programming part sounds interesting. Did you ever try
having "behavioral subnodes" which modify the parent node? I found it to be
powerful, but only when used in a hierarchical data flow pattern. Though I
haven't built the gui side of that approach yet.

Thanks for the feedback. I'm working on a set of programming tools based on
many of these ideas, and trying a few angles to visualized those orthogonal
concepts in a more interactive way. Oh, and the resource cost does seem to be
a blocker for consumer products in this area.

------
galfarragem
A bit off topic, but a big concern in my opinion: the amount of different
programming languages that graphic software professional _users_ (not
professional devs) must learn if they want to control their workflow with
scripting. Usually professional graphic software users use several software
packages not just one. As far as I can keep up:

autocad (lisp, .net, experiments on js)

revit (.net, experiments on ruby)

adobe suite (js)

archicad (GDL)

sketchup (ruby)

3Dmax (maxscript)

blender (python)

Is about time to create a _lingua franca_ \+ a specific DSL that could allow
to interact with all of them.

 _edit: I know that this is not easy to implement, but as a professional user
it would pay off to learn a lingua franca and be able to automate minor tasks
by myself. Learning several languages doesn 't._

~~~
Keyframe
In 3D applications, these days, python is more or less everything you need for
daily tasks. Even 3dsmax has relative python support now.

~~~
corysama
As does Maya an several other packages

> Some Programs that support Python: Maya, Modo, Houdini, XSI, Massive,
> Blender, Photoshop (indirectly),3ds max (indirectly)

[http://www.chadvernon.com/blog/resources/python-scripting-
fo...](http://www.chadvernon.com/blog/resources/python-scripting-for-maya-
artists/)

------
agumonkey
No mention of Maya, Houdini, Shake ?? meh. I was into cgi/compositing before
hitting graduate programming, and was always surprised how a lot of lazy
dataflow / DAGs brought to 'programming' but nobody really felt the same.
There was an hidden vibe from the PLT research guys that DAGs were limiting
compared to a usual functional programming language. I never knew why, and now
I'm even more curious.

~~~
d166e8
>> here was an hidden vibe from the PLT research guys that DAGs were limiting
compared to a usual functional programming language. I never knew why, and now
I'm even more curious.

I think the key insight is that in a functional programming language functions
need to be able to be values that flow through the graph and that can be
dynamically created. Supporting lazy evaluation and expressing data-flow is
insufficient to make a language truly functional.

The challenge I would give a data-flow language to see if it is truly
functional is this: can you create a general "compose function" or "partial
apply" node in these packages that works based on run-time inputs.

~~~
agumonkey
I hear you, but since many FP languages are turned into DAGs before
compilation, I always thought CGI software just didn't think about 'first
class' graphs and thus no meta level operators. It would be very interesting
to try though.

------
petecox
Where I'm from, MCG means something quite different. :)

~~~
yitchelle
Too right mate, I was thinking it was AFL footy, a cricketing app or something
similar. :-)

