"Code re-use is the goal. FP and OOP are just means to that end."
I think that both of you are right, to some extent. Code reuse is a goal, because it's better than writing everything anew every time you need some functionality. But it's not a long term goal, because sooner or later, it turns out that the code you have is insufficiently abstract, and you have to replace it with something more generic. I don't think that the level of genericity and abstraction available in mainstream languages is up to the task of making long-time code reuse an appropriate goal. VPRI-style "'runnable math' specifications" seem like the way to go, but how many people program that way?
Code reuse isn't the point of OOP. It may be a goal you personally have when you're writing code in OOP style, but AFAIK it was not Alan Kay's overriding goal when he coined the term. It was more about promoting clean, well-factored program designs. Reuse just happens to fall out of that more readily than bad program designs.
I edited my post to make it clear that that was a quote. :-) I also think that in case of OOP, it's an incidental outcome. (Efficient code reuse clearly needs more than just to have your program have a message-passing based architecture.)
I think that both of you are right, to some extent. Code reuse is a goal, because it's better than writing everything anew every time you need some functionality. But it's not a long term goal, because sooner or later, it turns out that the code you have is insufficiently abstract, and you have to replace it with something more generic. I don't think that the level of genericity and abstraction available in mainstream languages is up to the task of making long-time code reuse an appropriate goal. VPRI-style "'runnable math' specifications" seem like the way to go, but how many people program that way?