4 ms·
What the article attempts to exemplify is conciseness and transparency. C++ is inherently OOP and OOP is not concise or transparent. For example when you exte
by austincheney 8y ago
What the article attempts to exemplify is conciseness and transparency. C++ is inherently OOP and OOP is not concise or transparent.
For example when you extend an object the object knows of its chain of inheritance at compile time, but this is not immediately evident from reading an extended instance in the code. This allows code that is simple to write and expand, but more challenging to maintain. It also results in a large amount of boilerplate programming by convention.
The way I prefer to think about this is programming as a means of communication. There are three mental models of communication: explicitness, implicitness, and stupid.
Inherited object instances are implicit structures. You have some idea of what they are because of where they come from and what you know about that thing they come from. This requires some amount of reasoning that isn't directly spelled out. Implicitness is a convenience that scales well. In spoken language the most common implicit things are pronouns.
Creating everything as an explicit quality takes a tremendous amount of work. The result though is clarity in that you know what you are looking at by simply reading it. Counter-intuitively explicit things are not necessarily more code and in many cases actually result in less code. This is the nature of sacrificing convenience for precision.
- jcelerier 8y ago> C++ is inherently OOP in 1985 maybe. It was already pretty much not OOP in 1999 with libraries such as boost.graph, and is as far from "Java/C#" oop that you can imagine in 2018, where you can easily build lazy functional pipelines (https://github.com/ericniebler/range-v3 https://github.com/ericniebler/range-v3), pattern-match (https://github.com/mpark/patterns https://github.com/mpark/patterns), and where generic programming is the dominant paradigm.