

It's Time to Get Good at Functional Programming - Anon84
http://www.ddj.com/development-tools/212201710?cid=RSSfeed_DDJ_All

======
13ren
FP is the future of programming, and always will be.

The argument that many-core will lead to FP adoption used to appeal to me, but
then I studied Erlang, and saw that its concurrency power was due to shared-
nothing pure-message passing, and not due to it being functional. FP is a way
to not need to share memory, but Erlang doesn't actually use that for
concurrency. The thinking seems to be that inter-core communication should be
coarser-grained (e.g. at the module level, not the level of recursion over a
list), because it will always be slower than communication within a core.

Also, surprisingly to me, the over-hyped web services, SOA and ESB etc
arguably also aim at pure-message passing concurrency.

------
biohacker42
Functional languages are a red herring.

If you actually want to do something you still have to have side effects, and
that's when all that Haskell-ish beauty goes out the window.

It is still absolutely worth it to learn functional programming, it will
change the way you think, it will make a better programmer in non functional
languages, but it won't solve the problems of side effects.

~~~
gaius
_Purely_ functional languages are a red herring. So-called impure languages
however like OCaml can be enormously productive for certain classes of
problem. As always, it's a matter of the right tool for the job. Too many
people these days only have one tool, then every problem looks like your face.

~~~
jganetsk
Agreed. Languages like OCaml are actually higher-order imperative languages.
They have a very rich, expressive system of "values". A value can be a
function value, partially un-curried, and closed over arbitrary data. They can
also be data values but can be arbitrarily complex. How many languages let you
say:

let tree = Node (Node (Leaf 3) (Leaf 4)) (Node (Leaf 7) (Leaf 8))

This value is constant, just like an integer or string constant in many
languages. In other words, the right-hand side can be arbitrarily complex. And
this data structure gets passed around in a very lightweight manner (by
reference, not by copying).

The Java notion that values are either primitive, or objects... is limiting.

------
timr
_"Most modern programming languages, including object-oriented languages, are
imperative: A program is essentially a list of instructions intended to be
executed in order."_

That's silly. Anyone who has worked with a pure OO language knows that there's
nothing inherently imperative about the approach. Just because the most
popular OO languages (C++, Java) ultimately force you to have a main() doesn't
mean that a procedure is _required_ to write OO code. That's more a reflection
of the OS execution model than the language used to write the app.

I've personally written CORBA apps that were asynchronous, distributed and
multi-threaded -- in C++. Object-oriented development is more than capable of
handling the complexity of multi-core processing.

~~~
ricky_clarkson
Procedural does not mean "has a main()". It means that the code within a
procedure (or method, or function) is always a sequence of steps, i.e., a
procedure. OO is a procedural paradigm. doThis(that) is replaced by
that.doThis().

~~~
timr
I'm aware of that. But then, every program is procedural at some level; show
me a program that doesn't execute as a sequence of steps.

The point is, OO does not require that your code be executed any more
sequentially than does a functional language.

~~~
neilc
A Prolog program is not specified in terms of a "sequence of steps", for
example. Of course, the _implementation_ involves a sequence of operations
(because it is typically going to be evaluated on a Von Neumann-style
machine), but that has nothing to do with the semantics of the program.

 _OO does not require that your code be executed any more sequentially than
does a functional language._

If by "OO", you mean mainstream OO languages like Smalltalk or Java, then they
absolutely do have a more operational definition than a pure functional
language does. Objects send messages to other objects; as a result of
receiving a message, the internal state of an object changes.

~~~
timr
So, you're suggesting that functional programs are somehow totally stateless?
Otherwise, I don't really see your point. All useful programs store state
_somewhere_. The fact that OO programs couple state and code doesn't make them
procedural. Functional programs just tend to muss over this detail by using
closures and anonymous functions (aka "objects") to keep track of state.

An object-oriented program is not required to be expressed in terms of a
"sequence of steps" any more than is a functional program. You can instantiate
objects that talk to one another, asynchronously or otherwise, to
collaboratively do work.

~~~
neilc
You originally said that the idea that OO languages are imperative is "silly",
and that:

 _Anyone who has worked with a pure OO language knows that there's nothing
inherently imperative about the approach._

Can you provide some examples of how you might write "non-imperative" programs
in a mainstream object-oriented language?

 _An object-oriented program is not required to be expressed in terms of a
"sequence of steps" any more than is a functional program_

A functional program is not a "sequence of steps"; in principle, it is just a
mathematical expression that can be evaluated (via some means) to yield a
value (think of a SQL query or a Prolog program).

~~~
timr
_"Can you provide some examples of how you might write "non-imperative"
programs in a mainstream object-oriented language?"_

Go back and read my post -- I drew a distinction between "mainstream" OO
languages, and pure OO languages. If you want to genuinely understand object-
oriented programming, don't look at C++ or Java. Look at Smalltalk or Simula.

 _"A functional program is not a "sequence of steps"; in principle, it is just
a mathematical expression that can be evaluated (via some means) to yield a
value (think of a SQL query or a Prolog program)."_

I know what you're arguing -- the platonic ideal of the functional program is
stateless, and methods within that program have no side effects. In reality,
all programs store state _somewhere_ , and even "pure" functional languages
store state (albeit at a higher level).

What I'm trying to explain is that object-oriented programming doesn't
_require_ side effects. Where functional programs use closures and monads to
pass state around, you could just as easily use a functor to do the same
thing. Thus, you aren't compelled to write object-oriented code in an
imperative style. The difference is that OO code tends to be more explicit
about the location of state variables, and calls them what they are.
Functional programs, in contrast, just tuck the stateful bits into closures,
and pretends that they aren't really state.

------
jsmcgd
Why do you think Clojure wasn't mentioned? Not mature enough?

