" It's the baroque mental twists and turns we have to learn to make on procedural programming that are the problem."
What? For me the "modern OO" is as baroque as it gets.
First of all, and your example reminded me of that, because it hides what's happening. What's a window and a line? How am I supposed to know what's happening, if one has the .add method? Docs, sure, but it's non intuitive. Granted, today there's so much complexity you can't handle it all in your head.
But especially because procedural is how the computer works. Assembly. A list of instructions that are read in sequence. That I can understand. Now, OO makes this flow very convoluted, and the more "OO" someone programs, the shorter the procedures are, rather relying on inheritance, types to make computations, which of course, are good in one sense, but break the train of thought.
Some people will always prefer assembly code because they eschew all abstraction, but most of us need abstraction to deal with complexity. Picky your poison: do you like your abstractions to be objects or functions? Once he FP programmer starts flinging around higher order functions, FP can just as convoluted as OOP.
Actually, some authors define objects as functions with an internal state. In that sense, objects derive from functions.
For instance, in OCaml, the function "counter" defined as:
"let counter = let x = ref 0 in fun _ -> x := !x + 1; !x ;;"
is an object with one method that increments and returns the value of a counter.
In my opinion, OOP is intrinsically more complicated that FP because you can't really avoid complex patterns even to do simple things.
An example that comes to mind is the "Visitor" pattern. To me, it requires more mental gymnastic than what is found in most functional programs. It amounts to mixing higher order and functions with state which is something you try to avoid in FP.
But I admit that I'm not well-versed in OOP. I've always found it complicated. Not Objects per se, but design of big programs using classes with complex relations, UML, design patterns and so on...
I haven't used the visitor pattern in OOP in over 10 years and I write lots of code. There are many other better solutions to the expression problem than visitors. I don't bother with design patterns much or UML at all. I do mix my style up with FP when appropriate, but OOP is my dominant organizing principle.
OOP really is just about object thinking, just like FP really is about thinking in terms of functions. All the other baggage in either paradigm is quite optional.
The article is arguing that abstractions like OOP are unnecessary for a beginner. It is only after you understand procedural code that OOP "makes sense".
What? For me the "modern OO" is as baroque as it gets.
First of all, and your example reminded me of that, because it hides what's happening. What's a window and a line? How am I supposed to know what's happening, if one has the .add method? Docs, sure, but it's non intuitive. Granted, today there's so much complexity you can't handle it all in your head.
But especially because procedural is how the computer works. Assembly. A list of instructions that are read in sequence. That I can understand. Now, OO makes this flow very convoluted, and the more "OO" someone programs, the shorter the procedures are, rather relying on inheritance, types to make computations, which of course, are good in one sense, but break the train of thought.