[Bf-committers] Proposal for unifying nodes

Yves Poissant ypoissant2 at videotron.ca
Wed Jun 17 13:32:21 CEST 2009


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 



More information about the Bf-committers mailing list