What I'm specifically asking is how would this example be modelled/programmed in a FP language (Actual code, not theoretically)?

In "a" FP language? If any suffices, then I pick Emacs lisp. It does have the concept of types (kind of, sort of), but only built-in ones. So your example reduces to "how do you multiply each item in a list by something and return a new list".

(mapcar (lambda (x) (* x 2)) '(1 2 3)) 

There you go. Other languages will be similar, with the difference that you get th benefit of explicit types with the usual functional "matching" semantics. Check out Haskell:

incPrice :: (a) -> [a] -> [a] incPrice _ [] = [] incPrice percentage (x:xs) = x*percentage : incPrice percentage xs 

(Or something like that, it has been ages...)

I want to be open to the author's arguments,

Why? I tried to read the article; I had to give up after a page and just quickly scanned the rest.

The problem of the article is not that it's against OOP. Neither am I blindly "pro OOP". I have programmed with logic, functional and OOP paradigms, quite often in the same language when possible, and frequently without any of the three, purely imperative or even on the assembler level. I would never say that any of those paradigms is vastly superiour to the other in every aspect. Would I argue that I like language X better then Y? Of course I would! But that is not what that article is about.

The problem of the article is that he uses an abundance of rhetoric tools (fallacies) from the first to the last sentence. It is completely futile to even begin to describe all the errors it contains. The author makes it abundantly clear that he has zero interest in discussion, he is on a crusade. So why bother?

At the end of the day all those things are just tools to get a job done. There may be jobs where OOP is better, and there may be other jobs where FP is better, or where both are overkill. The important thing is to pick the right tool for the job, and get it done.

What I'm specifically asking is how would this example be modelled/programmed in a FP language (Actual code, not theoretically)?

In "a" FP language? If any suffices, then I pick Emacs lisp. It does have the concept of types (kind of, sort of), but only built-in ones. So your example reduces to "how do you multiply each item in a list by something and return a new list".

(mapcar (lambda (x) (* x 2)) '(1 2 3)) 

There you go. Other languages will be similar, with the difference that you get th benefit of explicit types with the usual functional "matching" semantics. Check out Haskell:

incPrice :: (Num) -> [Num] -> [Num] incPrice _ [] = [] incPrice percentage (x:xs) = x*percentage : incPrice percentage xs 

(Or something like that, it has been ages...)

I want to be open to the author's arguments,

Why? I tried to read the article; I had to give up after a page and just quickly scanned the rest.

The problem of the article is not that it's against OOP. Neither am I blindly "pro OOP". I have programmed with logic, functional and OOP paradigms, quite often in the same language when possible, and frequently without any of the three, purely imperative or even on the assembler level. I would never say that any of those paradigms is vastly superiour to the other in every aspect. Would I argue that I like language X better then Y? Of course I would! But that is not what that article is about.

The problem of the article is that he uses an abundance of rhetoric tools (fallacies) from the first to the last sentence. It is completely futile to even begin to describe all the errors it contains. The author makes it abundantly clear that he has zero interest in discussion, he is on a crusade. So why bother?

At the end of the day all those things are just tools to get a job done. There may be jobs where OOP is better, and there may be other jobs where FP is better, or where both are overkill. The important thing is to pick the right tool for the job, and get it done.