functional

[Justin Johansson]

Michal Minich Wrote:

> what mostly functional programmers think about it:
> 
> What are the properties of "Functional Programming Languages"?
> http://lambda-the-ultimate.org/node/2539
> 
> What are the real benefits of FP?
> http://lambda-the-ultimate.org/node/1578
> 
> from the discussion it seems there may be no straight answer.
> 
> it might be interesting to see discussion to second question about D on 
> this group - if it did't already happened?

As we all note there are endless discussions about FP vs IP all over the net.

And while the links posted above lead to some interesting discussion, it's all
"pubtalk".  (Brits and Aussie know what a pub is .. in your neck of the woods it
might be called a bar .. where you hang out, drink beer and discuss footy,
baseball, gridiron, soccer, politics, religion and, if you are a nerd, computer crap).

My tenet is simply this.  Functional Programming (FP) and Imperative Programming (IP)
are both tools like a kind of hammer in search of a nail to hit.  What, though, is the purpose
of just finding a nail to hit?  In any case, you could hit a nail with a tennis racket or a golf club
or whatever but what's the objective?

If the objective is to join to material objects together, a nail and a hammer might be
one solution.  Super glue might also work.

Now I don't know if this story is urban myth or what but supposedly there was once a very
successful hardware salesperson who said 

"I don't sell drill-bits.  I sell solutions to make holes."

What it boils down to is this: the problem has to be defined and then you need to find the
solution.

The salesperson was successful because she identified the problem.

If the problem is ill-defined, you have a moving target, endless discussions about the
right tool are a sure thing and the quality of the discussion ends up amounting to
"pubtalk" along the lines "my hammer is better than your hammer".

The most challenging problem of all in computer science (and most other fields of
endeavour) is to "define the problem".  From there, we can do about finding the
best solution.

With kind regards to all and especially Michal for posting the LtU contribution,

Justin Johansson