I find this article & much of the FP community somehow completely misses the point of OO.

I’m not an expert of OO to provide great claims, but I can say that working in ruby made me see it really is a beautiful way to handle state in certain cases & has value.

How can you completely write-off an entire paradigm/philosophy?

In general there’s a lack of respect for many languages that don’t fit the cool/obscure criteria. Most languages were designed for quite a long period of time, if nothing else give some respect to all the time spent & try to understand the design choices that were made. People don’t add or omit features purely out of ignorance of FP or types.

Not every language needs to protect people from mistakes. Not every language needs to have a sound type system or one at all. Not every language even has to have a novel feature.

But every language will have a vision, which I think more often than not is not purely semantics/feature based. Ecosystems are part of the language. The philosophies of the creator is part of the language. Etc.

It is extremely rare that any feature is strictly better than any other feature.

The PersonnelRecord isn’t OOP and exhibits a widespread misunderstanding:

class PersonnelRecord {
public:
  char* employeeName() const;
  int   employeeSocialSecurityNumber() const;
  char* employeeDepartment() const;
protected:
  char  name[100];
  int   socialSecurityNumber;
  char  department[10];
  float salary;
}

As written, the PersonnelRecord class will inevitably lead to code duplication, tightly coupled classes, and other maintainability issues. An improvement that’s still not OOP, but exposes a more flexible contract, resembles:

class Employee {
public:
  Name name() const;
  SocialSecurityNumber socialSecurityNumber() const;
  Department department() const;
private:
  Name name;
  SocialSecurityNumber socialSecurityNumber;
  Department department;
  Salary salary;
}

OOP is more about the actionable messages that objects understand to carry out tasks on behalf of other objects. Wrapping immutable data exposed via accessors reaps few benefits. Rather, OOP strives to model behaviours that relate to the problem domain:

class Employee {
public:
  void hire();
  void fire();
  void kill();
  void raise( float percentage );
  void promote( Position position );
  void transfer( Department department );
private:
  Name name;
  SocialSecurityNumber socialSecurityNumber;
  Department department;
  Salary salary;
}

This allows for writing the following code:

employee.transfer( department );

I don’t know how to “transfer” an employee given the code from the article, but it would not be nearly as elegant.

This waffled on a lot so I skipped to the end for the “mathematic explanation for why OOP sucks a big time”:

You’ll see the Java and C# […] make it inconvenient to write abstract variables and convenient to throw in few ints and floats, although these are quite close to the machine implementation

[…]

In functional programming you just say “a” if it’s something that goes through your system intact. That’s as abstract as it can be

This is nothing to do with functional-vs-OOP; it’s about type genericity. A functional language can still require you to specify parameter types (sure, many don’t and have generic functions, but that’s not the point unless you’re comparing specific languages rather than programming paradigms).

I feel like the whole piece is fluff.

Frankly hater pieces such as this are unhelpful. They are unhelpful to the author who shows ignorance in the topic he is talking about, and unhelpful to the wider community who apparently are mostly doing it all wrong. Most of all it is unhelpful to beginners who might be prejudiced against a paradigm together with particular languages/frameworks/methodologies and practices without due reason.

I’m not an expert on OOP or FP, but I’ve used both and greatly prefer FP. I just FP programs so much easier to understand than OOP programs. However, I think some concepts from OOP such as encapsulation have some merits and can also be implemented in a FP style. I think there has been enough debate on FP vs OOP and we should accept that ideas from both paradigms are very valuable. While I personally hate dislike OOP and believe FP is the way forward, I will never flame someone for using OOP.