> I think Java-style OO was successful because it made code organization obvious I can't agree with this opinion. I often find it an annoying restriction that

> I think Java-style OO was successful because it made code organization obvious I can't agree with this opinion. I often find it an annoying restriction that I must put all my functions in a class. Let's look at a trivial example of multiplying a matrix by a vector. You can write matrix.multiplyBy(vector); // OR vector.multiplyBy(matrix); It is possible to multiply from the left or from the right (as long as the matrix and vector dimensions match). This makes it even more annoying. What I'd really like to do is: multiply(matrix, vector); // vector is a column // OR multiply(vector, matrix); // vector is a row Perhaps it's the kind of problems I work with (and the non-OO languages I am used to), but I am regularly faced with this problem if I have to use a language like Java where you have to put all your functions inside classes. To further elaborate why I don't really like OOP (except in a minority of cases where inheritance, etc makes intuitive sense), I think the biggest issue is that classes/objects are the method to do almost everything. Namespaces, visibility, inheritance, dynamic dispatch, etc are all somewhat orthogonal features. Having a "class" to be the unit that uses all of these features is, in my opinion, a restriction. Lists (or arrays), tuples (or structs) and Maps (or dicts) are what I want 99% of the time. When programming with Java or similar languages, I feel like the primary means of abstraction and composition in the language is catering to a 1% problem. I learned programming in the late 90s, early 2000s, during the height of the craziest OOP craze (when "object oriented" was synonymous with "good"), so it took me a while to un-learn all of the OOP methods but I feel like I did turn into a better programmer when I stopped thinking in terms of objects. OOP is a neat paradigm for some cases, but I find those cases very rare.