[Bf-committers] Proposal for unifying nodes

[Nathan Vegdahl]

> And I also read "nodes as data proccessors" arguments as a showing an
> exclusive familiarity with procedural programming languages such as C++ and
> unfamiliarity with functional programming languages.

    Interestingly, I made that statement specifically *because* of my
familiarity with languages such as Haskell.  (I worked for 2 years at
a company that was exclusively Haskell-based, and I learned very well
to think in terms of functional programming.)
    In a purely functional language, every function fits the
mathematical definition of what a function is: it takes input, and
produces output, without side-effects.  In that respect, Blender's
node system fits well my conception of functional programming, because
that's how nodes work.

    But the node system inherently is not going to be as powerful as a
functional language (or any other language), because it's a DAG, and
therefore no recursion is possible (a primary construction in any
purely functional language).  In fact, loops in general are not
possible except when strictly kept inside single nodes (for example,
looping over light sources to calculate shading).

    So already the node system is a major departure from functional
programming, even in Robin's proposal.
    The point of the node system isn't to be a programming language.
So although looking at various languages can be useful as inspiration,
when it comes down to it, we're building something much simpler and
less expressive.

--Nathan V

On Wed, Jun 17, 2009 at 4:32 AM, Yves Poissant<ypoissant2 at videotron.ca> wrote:
> When I first read the propositions to unify all the nodes through some form
> of functional programming paradigm, I thought "man, this is brilliant". I
> feel sad to see all the oppositions to this idea. Anyone who have used
> functional programming language such as Lisp, or Scheme, or even JavaScript
> (when used as the true functional language that it is instead of as an
> innefficient replacement for C++), to name just those I have actually used,
> know how powerfull the functional programming paradigm can be.
>
> So I see someone suggesting a paradigm change, which is on the
> *implementation level* and I read a barrage of use cases which are at the
> *UI level*. And unfortunately, the discussion have completely shifted toward
> use-cases arguments and counter-arguments.
>
> For this discussion to progress, the arguments would need to come back at
> the implementation level and keep in mind that there is still the UI
> available for separating functions that truely makes sense only in some
> contexts. Good UI design still makes a lot of sense even if the underlying
> nodes implementation is "functional" or whatever other paradigm.
>
> Counter-argumenters tends to have a restricted view of what a function can
> take as input arguments and what it can output. There too, nodes, even if
> they are implemented through a functional programming paradigm, don't do
> their stuff through pure magic. There is still a need for a designer
> somewhere to code those functions and make sure those functions are
> efficient.
>
> And I also read "nodes as data proccessors" arguments as a showing an
> exclusive familiarity with procedural programming languages such as C++ and
> unfamiliarity with functional programming languages.
>
> The functional programming paradigm exists since a long time and it works.
> And it is efficient in more ways than simply execution speed. It is also
> extremely efficient for coding some data processing problems. There are
> processing constructs in functional programming languages that are just way
> too painfull to program in a procedural language. I've worked for 9 years
> for a company where we developped eLearning multimedia products (in the days
> when multimedia was cool) using Lisp, Scheme and Prolog as our programming
> languages. And we could do stuff in a few lines of code that would have
> taken days, even weeks for a Director or Flash programmer.
>
> Unfortunately, my experience showed me that trying to explain the benefits
> of functional programming to someone who have never used such languages is
> truely a lost cause. The fundamental knowledge onto which the concepts can
> stick are just not there and this fundation can only be built after several
> months of functional programming experience. All I can suggest to oponents
> is to try to keep an open mind.
>
> Yves
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>