[Bf-committers] Proposal for unifying nodes

[joe]

Ok.  So to summarize the discussion, what we want is a way to
meaningfully share nodes between tree types where it makes sense,
right?  But not necessarily have a totally unified system.  It's a
little confusing to me, because it seems like there's a lot of
hyperbole going on :)

Anyway, I think being able to share nodes where it makes sense is a
good idea.  I'm not sure how that would work though in more complex
cases.  Mixing texture nodes and modifier nodes, for example, wouldn't
work in a naive implementation because texture nodes operate on single
values, while modifier nodes would operate on many.  You'd need a more
intelligent system, maybe even Robin's idea of passing around
procedural functions.

Joe

On Wed, Jun 17, 2009 at 11:33 AM, Nathan Vegdahl<cessen at cessen.com> wrote:
>> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>