I think there is value in analyzing and discussing code by itself. But the most interesting stuff often is (also) in the head of developers, or in the process they use to arrive at the code.

I’m with you when it comes to using the style that betters suits your problem. But I think that often when we say “this problem is not a good match for paradigm X” we are really saying “I don’t know X well enough to be productive on this problem”. :-)

I think it is rare that you will find a (usefull) application that is pure OO or functional (especially if you ask if it has “procedural” aspects), so aren’t we better off looking for oportunities of use them at the appropriate time?

Still I believe the code itself, whatever the process used to write it, is important.

It’s true you can write pure functions in C, but for me that would be Functional C, not Procedural C. :) You can also do OO in C (real OO I mean, not C++) if you write some code to exchange messages between instances.

To conclude, I think there can be some metrics that can tell you: this piece of code is good FP, good OOP or crap.
But I’m not sure if they can be automatically measured, for sure they will be much more complicated to measure than Demeter violations or LCOM4.

Even something as simple as

4 – 8*9 + abs(12 -45)

can be interpreted as a mathematical immutable structure, or it can be interpreted as a procedure “first I compute 8*9 then…”. Or it can be interpreted as messages sent to objects. What do “8” and “9” represent anyway? They could be integer, rational, complex, floating point numbers… or maybe matrixes or categories. The “-” and “*” could be messages that are sent to these objects, and at some level I don’t know or care to which class they really belong.

I must also disagree that FP is about some fixed order of operations; even in this small example you could choose to compute 12-45 first, and you could compute the subexpressions concurrently.

Having cacheable results is a nice property; but it’s hardly a characterization. I can cache results in procedural and OO code as well. It depends on the meaning of a particular operation. If having cacheable results is all you care about, then you can do that easily with procedural C :-) I think that when you think of FP you are interested in more than just cacheable results. I think you’re more interested in writing components that can be combined with predictable results. I think you’re thinking of mathematical transformations.

It’s not a single property of the code itself; the FP is mainly in the process that you use to arrive at the final code. You don’t see the process :-) See the similar discussion in the Italian DDD mailing list. The reason there is not much DDD code to look at is that even if you looked at it you would not see the DDD process, unless you know that process rather well to start with.

I disagree heartily. While it’s true that pure FP has the property of referential transparency, can we say that it’s the essence of FP? I think it’s not, and furthermore I think it gives you very little guidance on how to write effective functional programs. Modelling with mathematical structures is much more likely to be a good guide.

About OOP, Alan Kay wrote that “messaging” is the key thing. At some other point he wrote that “messaging, encapsulation of state and extreme late binding of all things” is the essential point of OOP. Open Recursion seems to be “late binding of some things”.

My point here is that most people characterize programming paradigms by some inherent property of the programming languages themselves. But I think that it’s a lot more useful to characterize programming paradigms as different modes of thought.

OOP = open recursion
FP = referential transparency
Procedural = none of the above

For example let’s take:
4 – 8*9 + abs(12 -45)

how do you solve it?

first I do 8*9 = 72
then I do 12 – 45 = -33
if <0 then multiply for -1 = 33
etc.

many function have order and if nested
see also the do-notation in Haskell
http://en.wikibooks.org/wiki/Haskell/do_Notation

the main point is that in functional code you take the result of one operation and you put it as input in the following (or you return early for an error). So there is a kind of immutable chain of actions.

The if in my code where just redirecting the flow (proceed with this function or the other one or return), like the maybe monad in Haskell.

Instead in procedural code, you read and write on persistent variables, the value of them could not be calculated in advance.

Saying it in another way: in FP your functions are perfectly cachable, that is given the values of input parameters is always safe return the previously computed result. This is true for my code, but not for procedural code.

Anyway I agree with you that this is hard to spot if you don't have a functional eye, and usually you need functional programming experience for that.

I'm also happy for this post because it also helped me to clarify better the problem to myself. I'm working on a new presentation completely about code and code quality. When I'll have something half-baked I'd like to present it at xpug-mi