Given the amount of comments on this article, I feel like I'm the only one who missed the point the author is trying to make. TFA goes from praising the existence and ease of use of data types, particularly collections, in high-level languages such as Python (an object-oriented language) and constrasts it to C and Pascal (neither of which are object-oriented) and then seems to extoll the virtues of relying on basic data types (eg, tuples) as opposed to custom data types, and concludes that OOP is more complicated.
I could try and summarize the article differently:
The exports of Libya are numerous in amount.
One thing they export is corn, or as the Indians call it, "maize".
Another famous Indian was "Crazy Horse".
In conclusion, Libya is a land of contrast. Thank you.
Point 1 is pretty uncontroversial: well-written data structures in high-level languages are easy to use and save you a lot of typing. Point 2, not so much. When you start to argue that tuples are a good way to represent a data structure you will presumably use in several places in your program, this is a lot more controversial (but has nothing to do with OOP, you can write Haskell using tuples instead of records too...). Regarding the conclusion, OOP is not a "fundamental particle" of programming: you had non-OO languages before, and you have non-OO languages now. For me, you have two major things which distinguish functional languages from object-oriented ones: immutable state, and a less strict coupling between data structures and behaviours operating on these structures. Neither points are addressed in TFA.
OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical way to architect every piece of your solution. That's all.
The underlying reason is that data types must address (in some way) a number of requirements: copyability, management of owned resources, conversions, limits, etc. You need to take care of all that for every single custom data type you create, or your code will be a minefield of half-baked data types. This large base cost for data types in turn makes the classic 'divide and conquer' strategy for software development more costly, which triggers further practical problems with overgrown and over-engineered types.
> OOP philosophy is to turn concepts from your problem space into custom data types.
I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their own. In languages supporting even basic pattern matching, I use tuples whenever I need to return more than one value for a function, and I'm not interested in reusing together elsewhere.
But this does not scale to complex program and complex data types. And your custom data structures will need to support a number of operations (eg, comparison, etc...). I don't really see what this has to do with OOP per se.
Do we really need to reinvent these complex datatypes each time, thought? How many classes there exists in Java or C++ just to keep x,y and z coordinates of a point in 3d space? With custom types we gain the ability to distinguish color (r, g, b) from position (x, y, z), but is it worth the cost? How often do you catch errors like assigning point coordinates to a color?
If you want to use library A that has Vector3d type defined with library B that uses library C that has Point3f class, and with graphic library that use its own Vertex class - isn't it stupid that we need to convert the data all the time?
I've seen application in C++ that uses 4 types of string: QString, std::string, char* and custom type to pass data to database. 3 of them just because of used libraries.
I think OOP mindest makes people whip their own datatypes too easily, and it hurts when you need to integrate libraries developed independently. Most of the time tuples, lists and hashmaps suffice, and in better languages you get many operations on you composite datatypes for free - for example serialization, deep copying and deep equality checking.
Haskell has String, ByteString and Text :) Data type proliferation is not confined to object-oriented languages (actually, since datatypes are much easier and cheaper to build in functional languages, they're even more likely to occur within FP).
The nice thing about Haskell is that you can have a million data types with different names, and as long as they're capable of implementing the type classes you are using, you can pretty much freely switch between the different underlying types. And if a library author doesn't provide an instance of a type class for the data type, you are still able to write one.
In most OOP languages, you'd be forced to either monkey-patch the classes, or writing cumbersome wrappers.
I could try and summarize the article differently:
Point 1 is pretty uncontroversial: well-written data structures in high-level languages are easy to use and save you a lot of typing. Point 2, not so much. When you start to argue that tuples are a good way to represent a data structure you will presumably use in several places in your program, this is a lot more controversial (but has nothing to do with OOP, you can write Haskell using tuples instead of records too...). Regarding the conclusion, OOP is not a "fundamental particle" of programming: you had non-OO languages before, and you have non-OO languages now. For me, you have two major things which distinguish functional languages from object-oriented ones: immutable state, and a less strict coupling between data structures and behaviours operating on these structures. Neither points are addressed in TFA.