

Imperative vs Functional Programming - gtani
http://apocalisp.wordpress.com/2011/05/30/imperative-vs-functional-programming/

======
ekidd
Quoted by the article: _Computers function by executing a series of
instructions, at the level of machine language, which perform calculations and
manipulate memory and I/O._

Today, our computers increasingly have many cores, and many threads. On top of
that, we often have to co-ordinate between dozens of separate servers, each
with their own memory and I/O.

In this environment, manipulating memory becomes tricky, because you must co-
ordinate among anything from 2 to 2,000 simultaneous processes. This raises a
whole host of issues: (a) direct interaction using locks and semaphores is
_hard_ to get right, (b) the memory in question may be located on separate
machines, and (c) if you're running at a billion instructions per second with
a 0.1 second lag between machines, simply defining "simultaneous" can give you
a headache. And with the rise of GPUs for blazingly fast general-purpose
computation, even the hardware itself is becoming deeply functional.

We've come up with a whole host of strategies for tackling this problem:
Worker queues, MapReduce, Erlang-style message passing, shared-nothing
architectures backed by databases, and even eventually-consistent NoSQL
systems. Each of these, in some fashion, represents a retreat from the old-
school model of a single process manipulating global memory.

In this world, functional programming adds one more tool to our kit. It treats
mutation and global memory as a special case, and gives us a new vocabulary
for working in this world: map, reduce, transactional memory, monads, and
local state (via Haskell's ST monad, for example). Even if you work in
traditional OO languages, this functional vocabulary will give you new ways to
tackle hard problems.

------
_delirium
I actually like the machines/mathematics dichotomy in CS, though it often
seems to come up as a one-versus-the-other holy war. I guess I'm actually okay
with both of these statements, and am glad people are pushing both:

 _1\. Computation is fundamentally a machine doing things; although of course
these machines' operation is also analyzable via mathematics_ ; and

 _2\. Computation is fundamentally a mathematical phenomenon; although of
course it is also implementable on machines._

I guess there's a philosophical debate about which is more fundamental (does
mathematics 'exist' ontologically?), but pragmatically I'm okay with
considering them both fundamental approaches to CS.

~~~
jpendry
sounds like this: <http://en.m.wikipedia.org/wiki/Church–Turing_thesis>

------
thomas11
There's a fantastic paper called "Why Functional Programming Matters" by John
Hughes [1]. Most of you here will know it, but it's so good that I wouldn't
want any newcomers to miss it.

It's from 1984 and IMO still the best essay on the basic idea of FP. For
Hughes, FP's fundamental strength is in program composition and modularity,
and he shows this with relevant examples.

[1] <http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html>

------
alecbenzer
"programmers well versed in functional programming are extraordinarily
productive in any language"

This could just be due to the fact that people who learn functional languages
are interested enough in learning languages that they're productive in most of
them. If, for example, functional languages were the norm, and some people
decided to experiment with OO languages, then it might be that people who knew
OO languages would be the ones that were productive in any language.

~~~
loup-vaillant
Except that FP basically dominates class based OO[1]. If FP were the norm,
nobody would study class based OO. Remaining alternatives could be prototype
based OO, bare-bone programming (assembly, C, LLVM), stack languages, and
domain specific languages.

[1]: <http://www.loup-vaillant.fr/articles/classes-suck>

~~~
alecbenzer
That's an opinion, and it may have merit and be valid, but it still could be
the case that people might want to experiment with OO languages, and also
doesn't change the fact that people who know FP might just be better in any
language because of their interest in programming languages, not because of
the merits of FP.

------
Peaker
He quotes the guy saying "Computers function by executing a series of
instructions".

This is no longer true, and becoming less true all the time.

Using a massive amount of GPU's, and many CPU cores is no longer a simple
series of instructions.

Then, the more abstract model of functional programming allows the
implementation more freedom when distributing work on the many cores/GPUs, and
can make use of this new architecture.

If we have even more radical changes in hardware architectures, it is almost
certain that the more abstract models of programming will survive better than
those tied to a particular hardware architecture (Von neumann model).

~~~
wladimir
_Then, the more abstract model of functional programming allows the
implementation more freedom when distributing work on the many cores/GPUs, and
can make use of this new architecture_

I have read this many times over the years and it sounds perfect. It would be
great to have some form of programming that maps to parallel architectures
without headaches and bug-prone extra work.

Still, for GPU programming we're mainly stuck with things like OpenCL/CUDA,
which are imperative like ever, and it's a lot of work to port non-trivial
programs to them.

Also, even with Haskell/Erlang/etc AFAIK you still have to do special handling
to get programs to be efficient with manycore parallelism. And that's not even
talking about GPU.

Is this system ever implemented or does it just exist in theory?

~~~
gmt2027
The basic problem in porting to OpenCL/CUDA is identifying the mapping and
reduction operations buried in imperative code. That these data-parallel
operations are fundamentally functional is clearly reflected in the primitives
that the Thrust and CUDPP libraries provide.

The real challenge emerges during program restructuring and performance
tuning. This requires intimate architectural knowledge and frequent trade-offs
between conflicting optimisations.

~~~
wladimir
So we're already doing 'fundamentally functional' operations? That's an
interesting way to look at it, but it's still driven from an imperative
language. The grandparent post talked about functional programming in a
functional programming language on a GPU.

Is Theano a step in this direction? (
<http://deeplearning.net/software/theano/> )

------
raganwald
_It might be true that functional programming is difficult to learn for
programmers not well versed in mathematics. My response to that is: Toughen
up, princess._

Pithy, but also tinged with sadness. It's a response to the same argument
against programming languages being "too powerful" or using "difficult to
understand" pattern like parser combinators.

~~~
swannodette
I'm a fan of FP and I find most of the arguments being made here for FP over
OO to be quite unconvincing. You don't need to understand mathematics anymore
in FP than you need to in OO. If there is any mathematics in FP it's of the
logical variety anyhow - which programmers are already familiar with.

~~~
raganwald
Since I don't have any training in Category Theory, I don't know what I don't
know. I do know that it seems from the outside of the Ivory Tower that the
explanations for FP are far more difficult to understand than the FP itself.

But then again, perhaps if I had studies mathematics, I might have some
additional insights into FP that go beyond knowing all of the jargon.

~~~
swannodette
You don't need to understand the Y Combinator to understand recursion. You
don't need to understand the theory behind the Lambda Calculus to write
anonymous functions. You don't need to understand Gentzen Calculi to write
interesting Prolog programs. You don't need to understand the Curry-Howard
isomorphism to understand static typing.

These things deepen your understanding certainly, but not understanding them
does not in any way limit our ability to write incredible programs.

~~~
shadowfox
To add to what you said, you certainly need not understand Category theory in
order to be effective as a functional programmer.

Category theory is a very powerful concept. Understanding elements of it will
certainly open your mind to the fundamental nature of mathematics. But the
essential aspects of it have long been mapped in to other, more accessible,
theoretical frameworks. So you can usually get away with never knowing that
subject :)

------
d0m
One thing to say is that OO doesn't mean no-functional and functional does't
mean no OO. For instance, Python's String is functional since you can't alter
it.. 'test'.replace('t', 's') will always return something new and does't not
depend of anything but the string itself. I'm not saying python by itself is
purely functional.. (as scheme is not purely functional).

I'm saying that because I've had great success recently by using immutable
objects in languages that aren't.. how to say, functional friendly?

~~~
nickik
I always trie to explan that to people its not about FP vs. OO. You can have a
very functional OO language (dylan or scala come to mind) or you can have a
imperativ OO Language (Java).

The real importend fight is FP vs Imperative. If the language is OO or not
does not really matter.

~~~
thesz
For OO you have to have state. Objects should have identities which
distinguish them. That means that two objects are distinct even if all their
properties are equal.

This break referential transparency. Two runs of "new Integer(2);" will be
different.

So you cannot have proper functional language with OO. Even if all your
objects are immutable.

~~~
babel17
Yes you can. Check out my language Babel-17 (<http://www.babel-17.com>) .

~~~
thesz
>>So you cannot have proper functional language with OO.

>Yes you can. Check out my language Babel-17

I failed to see how purely functional structured programming address the need
of identity for objects.

Could you elaborate a little more?

~~~
loup-vaillant
Noob question: what the hell are you needing identity for?

~~~
thesz
To differentiate objects one from another.

[http://en.wikipedia.org/wiki/Identity_%28object-
oriented_pro...](http://en.wikipedia.org/wiki/Identity_%28object-
oriented_programming%29)

"identity is the basis for polymorphism in object-oriented programming."

In a purely functional object-oriented programming you don't need identity.
But then that practice is almost indistinguishable from usual pure functional
programming we have for at least 20 years with Haskell.

~~~
loup-vaillant
Forgive my insistence, but, what kind of _problem_ does the ability to
differentiate objects from one another solves? What kind of _programs_ are
made simpler by this ability?

Besides, I don't see how you would need identity in the sense of being
structurally-equal-but-not-the-same for class based polymorphism. You could
perfectly do this without any side effect, despite what the `final` keyword in
Java might mean.

By "identity" Wikipedia probably means something like "you think I'm a Foo,
which is right, but underneath, I'm a _special_ kind of Foo: a Bar. By the
way, there are others special kinds of Foo: the Baz, the Fiz, the Buz…". In
other words, _subtyping_ is the basis for polymorphism in OOP.

~~~
thesz
>Forgive my insistence, but, what kind of problem does the ability to
differentiate objects from one another solves? What kind of programs are made
simpler by this ability?

Oh, I don't know. I am not an expert in OO* at all.

All I know is that for something to be true OO it has to have objects with
identities. I was told so. ;)

All I know about OO is Liskov substitution principle. Where it is unnecessary
I tend to use State monad and immutable objects.

>subtyping is the basis for polymorphism in OOP.

Which can be solved by several means, interfaces and inheritance being two of
them.

~~~
babel17
> All I know is that for something to be true OO it has to have objects with
> identities. I was told so. ;)

Well, you were told wrong things :-)

~~~
thesz
Please, list object-oriented systems with objects with identities and object-
oriented systems without those. Count both. Discuss. ;)

Alan Kay, who coined term "object-oriented" described object-oriented system
as an assembly of objects communicating by message passing. Message passing
_requires_ identities (and state, except in severely reduced form).

~~~
babel17
Message passing does require a sender, a receiver, and a message. You can have
those in purely functional programming. No identity needed. But if you really
want one, you can have it: Two objects are identical, if they react to all
messages in the same way. You can also explicitly define equality ==, and then
say that a and b are identical if a == b.

~~~
thesz
>Message passing does require a sender, a receiver, and a message. You can
have those in purely functional programming. No identity needed.

Would you mind show me some code in pure functional language?

I mean, in Haskell or Clean. Those are pure enough.

~~~
loup-vaillant
[http://www.loup-vaillant.fr/articles/classes-as-syntactic-
su...](http://www.loup-vaillant.fr/articles/classes-as-syntactic-sugar)

My Ocaml code is not pure, but we can easy remove any occurrence of `ref`, and
restricting oneself to pure methods, which produce a new fresh object instead
of modifying `this` in place.

~~~
thesz
Sorry, I am not very fluent in OCaml. Also, I didn't find word "message" in
the link above.

I am experiencing limitations of pure objects and message passing almost right
now. In my spare time I am currently developing dynamic data flow CPU which is
based on immutable "objects" and message sending. It is quite unusual style of
programming, very unlike anything else, including Smalltalk, Erlang and
everything.

~~~
loup-vaillant
It's like Haskell, with a slightly heavier syntax. And it's eager. And you can
unsafePerformIO all over the place (but avoid doing so even in Ocaml).

    
    
        (* Ocaml *)    --Haskell
        let foo = 42   foo = 42    -- top level declaration
        type bar =     data bar =  -- type declaration
    

Also, records in Ocaml are a separate kind of type, more like C structs:

    
    
        type bar = { x:int;     (* defination *)
                     y:float;
                   }
        bar.x                   (* "member" acces *)
    
    

"Message passing" and "Method calling" are strictly equivalent, at least when
everything is synchronous.

------
iwwr
The contrast to imperative programming is not FP, but rather declarative
programming. The idea of referential transparency comes from DP, not FP.

Example: Prolog, a declarative language with many of the qualities of FP, yet
not FP.

~~~
silentbicycle
Prolog is not really declarative except for the pure core, though. Cuts,
assert, retract, etc. break its referential transparency.

------
agentultra
_How is functional style rooted in the "purpose" of the software and the
"nature of the thinking" that programmers do?_

Well I would say that for now the _nature_ of thought is still unknowable.

The _process_ of thinking is something a programmer acquires by rote training.
I don't believe that there is a "style" of programming that is universally
applicable or models the very nature of thought itself. Such is the stuff
programmers dream of.

Even language is an abstraction we put on reality.

Mathematics is just another language and one many feel represents reality more
succintly and accurately.

------
joevandyk
_The facts of reality that give rise to the FP approach is the recognition
that computation is essentially a process of inferring quantities. Its purpose
is to aid in human thinking. And the conceptual faculty is a quantitative
mechanism. This is laid out eloquently in David Harriman’s book “The Logical
Leap”. See also “Concept-formation as a mathematical process” in OPAR.

The computer is in essence a quantifying device. Its invention was motivated
by man’s need to quantify._

Anyone else tired of verbose writing?

------
sn
What about dataflow programming? Shell scripting is one example. I think the
same thing could be implemented using event driven programming, the event
being the completion of some function, though that would be a little less
clear.

------
olalonde
What would be a good first functional language to learn coming from an
imperative/OO background?

~~~
nickik
Depends on you you can either "jump in the deep end" or you can gratually move
more to it.

Gratually moving is good if you want to stay productive. (Scala, Common Lisp,
dylan come to mind)

Jumping in the deepend will totaly go against everything you learned but you
will learn very fast. (Haskell, ML, Clojure and Scheme are probebly best here)

Books: Land of Lisp/Practical Common Lisp for Commen Lisp Not sure about Scala
Programming Dylan for Dylan

Learn you a Haskell for Haskell Programming Clojure/Practical Clojure for
Clojure Structure and Interpretation of Computer Programmes/The little Schemer
for Scheme (Don't know a good book for ML)

~~~
olalonde
Yes, the plan is to jump in the deep end, unwire my brain and apply the
concepts I learn to my day to day Ruby/Javascript programming as much as
possible. I think I'll go with Haskell.

~~~
yogsototh
I am currently learning Haskell. I started by not really knowing where to
start. Now I follow this advice, and until now I find it very helpful:

[http://stackoverflow.com/questions/1012573/how-to-learn-
hask...](http://stackoverflow.com/questions/1012573/how-to-learn-haskell)

