Comments on: Is this functional programming?

By: Florian Krüsch

Florian Krüsch — Wed, 11 Nov 2009 11:25:31 +0000

sounds like you’re saying that programming a filter pipeline contradicts or is not real functional programming…
in fact functional programming is great for ensuring the correctness of the chaining, especially when using monads | http://en.wikipedia.org/wiki/Monad_(functional_programming)

By: stephan

stephan — Mon, 26 Oct 2009 20:31:39 +0000

I’m sorry, wordpress isn’t very good with code in comments. [Generics] worked for Scala though.

By: Apocalisp

Apocalisp — Mon, 26 Oct 2009 16:13:32 +0000

Hmm… there are supposed to be some angle brackets in that Haskell code, but your comments system eated them.

By: Apocalisp

Apocalisp — Mon, 26 Oct 2009 16:10:48 +0000

For comparison with a purely functional language, here’s that code in Haskell:


getSlots n m = (zipWith (-)  tail)

               . sort

               . ([0, m] ++)

               . take (n - 1)

               . randomRs (1, m - 1)

This is a pure function that takes a random number generator and returns an IO action within which the “slots” are provided.

By: Keith Dahlby

Keith Dahlby — Wed, 21 Oct 2009 17:55:17 +0000

Thanks for the comments everyone, glad to stir up a discussion. I think it’s important to realize that a “pipeline” just takes inputs from before the dot and returns new values out the “other side”. Assuming you’re not modifying shared state, that’s pretty much the definition of a function.

In this example, Values is always going to take the Random seed and return the sequence of values generated from it (technically this is modifying the state of the Random object, but in practice it doesn’t matter). Similarly, Pairwise is always going to return a new sequence generated from calling a function on adjacent elements in the input sequence. Whether or not they are “pure” seems irrelevant: they are useful abstractions implemented as functions – functional abstraction.

“While this chain looks elegant and concise the ‘extension methods’ used to enable it look verbose and complex as hell.”

Isn’t that the point of any abstraction, be it object-oriented or functional? Implementing the complex details once allows us to reuse them forever in “elegant and concise” compositions that greatly reduce the complexity of the code you’re actually interested in.

Cheers ~
Keith

By: Wedge

Wedge — Wed, 21 Oct 2009 10:01:25 +0000

Sure it’s functional programming. Don’t get so caught up on the trendiness of functional programming to think that one way of using functional programming is less cool and less “truly, really functional” than another way. Using extension methods and other constructs to create a useful, readable, terse pipeline programming model is plenty “functional” even though it may not be quite as clever as a y-combinator or map reduce.

Remember that a Turing machine is the utter definition of the imperative, stateful programming model, yet every single function has its equivalent expression in Turing machine code form. They are two sides of the exact same coin. They are two levers under the same load, what matters is which lever is more useful to accomplish the task at hand.

Orthodoxy is for chumps, the important aspect is whether it’s GOOD programming, regardless of style.

By: Apocalisp

Apocalisp — Mon, 19 Oct 2009 22:42:53 +0000

Your fluent interfaces want to be function composition. Let them.

By: walter higgins

walter higgins — Mon, 19 Oct 2009 21:13:27 +0000

I don’t think that’s functional programming – just an examlpe of a fluent interface http://www.martinfowler.com/bliki/FluentInterface.html

By: Spoon boy

Spoon boy — Mon, 19 Oct 2009 20:22:24 +0000

Spoon boy: Do not try and bend the objects. That’s impossible. Instead… only try to realize the truth.
Neo: What truth?
Spoon boy: There is no OOP.
Neo: There is no OOP?
Spoon boy: Then you’ll see, that it is not the OOP that bends, it is only yourself.

By: Apocalisp

Apocalisp — Mon, 19 Oct 2009 17:18:11 +0000

You’re getting closer.

There is no Object-Oriented programming. There’s only programming. Functional Programming is simply programming with pure functions.

Your “objects” want to be functions.

By: Raoul Felix

Raoul Felix — Mon, 19 Oct 2009 14:48:06 +0000

In addition to what Daniel Sobral said, another defining characteristic of functional programming is that the code should not produce any side effects. That is why there is no state and data has to be immutable.

There is also no notion of time in functional programming. If a function produces a result with a given set of parameters, it should always produce the same result given the same parameters.

By: Janko M.

Janko M. — Mon, 19 Oct 2009 13:30:32 +0000

No. This is poor man’s stack programming.

Lucky for him he needed just one-level deep stack in this example. While this chain looks elegant and concise the “extension methods” used to enable it look verbose and complex as hell.

By: Justin Cormack

Justin Cormack — Mon, 19 Oct 2009 12:44:14 +0000

If you want a real “this is different” example, you need to be returning functions. Something like the jquery pipeline model is more like it, where all the core library operations return functions not values. That example just returns a scalar, so it is not composable any more…

By: Daniel Sobral

Daniel Sobral — Mon, 19 Oct 2009 11:09:25 +0000

Pipe lines are definitely one example of functional programming. There are few things that define functional programming:

1. Immutability. Data never changes, you just produce new data.

2. Functions as data. Functions can be passed around and manipulated just like any other type of data.

There, now you have Lisp. :-)

In traditional OO programming, each method called would change the data in-place. Not that this is a requirement of OOP, but it comes so naturally that it became the standard.