I’ve been reading about functional programming lately, and it occurs to me that XOD has some elements of the functional paradigm built in. In particular a node, when it doesn’t use state, is a pure function. It will always return the same outputs for the same inputs. Nodes can be used inside other nodes, so functional composition is supported, and without any complex syntax to learn and get wrong.
Nodes have referential transparency. I don’t really understand this one, but I think it means you can replace an input with the value it represents and still get the same result. Or something. Wikipedia says referential integrity is the same as pure function. Like I said, not sure about that one.
Immutability is another one. Again, don’t really understand it, but I think a XOD node won’t change it’s input, it will only create a new output. So immutability might be supported too.
XOD doesn’t support recursion. A node cannot contain another copy of itself. Not sure how the functional languages handle that but that’s how they do looping. (or one of the ways anyway).
So, is XOD a functional programming language? It seems to come close.
Yes, XOD has a lot of elements of functional programming (FP) language. However, it misses one important feature of FP known as “functions as first-class citizens” or “high-order functions” (HOFs). That is, a patch node can’t have an intput of type “patch”. The first idea of using functions as arguments in Haskell, LISP, or another FP is passing them to widely known map / filter / reduce / fold functions to process a list of items somehow.
This feature would be hard to implement in XOD and we failed to imagine how it could look like visually without over-complicating the language. Howerver, we have an idea prototype which would allow nodes like the mentioned map, filter, reduce without resorting to HOFs at all.
From another point of view, XOD has notion of pulses and pulse chains. The make it somewhat imperative when necessary. So, putting it in summary, I’d say XOD is a multi-paradigm language.
Yeah I missed the first order function part, and you are right of course. Although you could maybe have an input pin type of “function” that could accept a node as input, which would require the node to evaluate the input function first, get the result and use that as the input to the rest of the node’s functionality. Could be a nightmare getting all the nodes to execute in a suitable sequence to get everything right though. Don’t know, I’m not a proper programmer, just an enthusiastic amateur.
I also have no idea how useful that sort of functionality would be in the XOD ecosystem anyway, given the limited resources of the environment the programs run in. You could be spending a million dollars to save ten cents.
The functional programming paradigm I find interesting though. I haven’t really wrapped my head around it. Had a bit of a play with Haskell, and doing a bit of reading about Clojure and F# (which seems like a nice language). But the syntax is difficult to get a hold of for my vintage brain. Sometimes it seems downright backwards. Almost as hard as C++. Anyway, all good fun.
