[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