A quote:
To understand Julia, we have to first understand Julia’s lack of classes. In object-oriented programming, classes allow objects and methods on those objects to be put in one space. The idea is that when you are, for example, writing business logic with books, then you want to neatly put the operations on the book near the definition of the book. One such operation can be to
sell. Thesellfunction can do things like marking the book object as sold. This can work fine, you can even add new classes such as bicycles and spoons and add asellmethod to them as long as they all inherit from the same superclass, say,Product. ThisProductclass would define an emptysellmethod which needs to be extended by all subclasses and allows the compiler and static linter tools to know that anyProductsubclass has asellmethod which is great for discoverability of those methods. So, as an object-oriented programmer, a lot of thought is put into finding the right inheritance so that methods can be re-used between different classes. Also, class and object variables hold the data and are coupled to methods too. In summary, methods are coupled to other methods and to data.This coupling is counter to the idea of modularity. Modular artifacts are easier to produce and maintain. For example, mechanical artifacts such as cars, bridges and bikes are not glued together but instead use fasteners such as nuts and bolts. If the products would be all glued together, then the tiniest mistake in the production of one of these artifacts means that it can be thrown away immediately. The same holds for maintenance. In most cases, repairing a glued together artifact is more expensive than replacing it by a new artifact. And this is exactly the problem with object-oriented programming. In essence, the whole system is glued together since not only methods are glued to their class and data, but also classes are glued together.