Lessons learned from working at Continuum | Aaron Meurer's Blog

[utterances-bot]

Lessons learned from working at Continuum | Aaron Meurer's Blog

https://asmeurer.com/blog/posts/lessons-learned-from-working-at-continuum/

[asmeurer]

To comment on this post, click on "Sign in with GitHub" below. If you don't want to authorize the Utterances bot, you can go to the GitHub issues page for this post and comment there.

[asmeurer]

These are the original comments on this post that were made when this blog used the Disqus blog system.

Comment from cyberbikepunk on 2015-10-06 07:25:49+00:00:

I enjoyed this. Thanks

Comment from Ionut Vancea on 2015-10-06 08:46:10+00:00:

Thanks!

Comment from Andrew M. Farrell on 2015-10-06 17:30:48+00:00:

I would be interested in hearing more about why one should avoid object oriented programming. I've found that trying to onboard onto a project where the a codebase that did not have an expression of what its first-class-citizens were and what operations could be performed on them was rather difficult. I'm intensely curious: what do you view as the disadvantages of OOP?

Replies:

Comment from asmeurer on 2015-10-12 01:28:16+00:00:

Object oriented programming can be done well, and there are definitely cases where it is the correct abstraction (I said avoid it when procedural programming will do just fine).

My gripe with it is twofold. One is that it tends to separate out program logic into many places. The more you split your code into many methods, or use subclassing, or other OO features, the more this is true. This makes the code harder to follow, especially as a newcomer to the codebase.

The second gripe is that while OO can be done well, it too often isn't. The issue is that there are so many "features" of OO systems (especially in Python) that can be abused. The temptation to add unnecessary complexity into a system is too high. Some example of this might be:

- Splitting the class hierarchy, even when some classes are never directly used (remember that subclassing splits apart the code logic, making it harder to follow)

- Overusing syntactic sugar features, whether it's a simple use of things like properties or __methods__ (in Python). Syntactic sugar can be powerful, but it also adds complexity, especially for newcomers, who must learn what the special syntax means. Simple function calls can be verbose, but they are also the easiest for newcomers to understand, since function names tend to be made up of words that describe what they do, rather than symbols that only suggest what they do.

- Using complex features of the OO system that few people truly understand (like multiple inheritance, or even normal single inheritance in some cases, or descriptors). This effectively moves the logic out from being explicit (for, if, else, etc.) to using the implicit logic of the OO system, which, although is consistent and generally well designed, is often only understood by language experts (do you understand how the C3 algorithm works, and can you name off the top of your head the invariants that it maintains? Can you explain, without looking up any documentation, how the super() function in Python works?).

- Changing the way that OO systems fundamentally work. This is even worse than the last point because it changes even the implicit logic. This generally involves using nasty things like metaclasses and descriptors.

Procedural programming is nice because, at least in Python, you can't really change how it works, or extend it, except in simple ways (like with decorators). So instead of being tempted to change the way the language works to fit your problem, you fit your problem into the way the language works, which, at least for problems that are already close to how the language works, leads to code that only requires an understanding of the language itself to read.

Comment from Jason K. Moore on 2015-10-06 17:32:14+00:00:

Nice writeup and I'm looking forward to seeing what you and Anthony will be doing! Congrats!

Comment from Andrew on 2015-10-07 23:30:42+00:00:

Very nice write-up Aaron.

Comment from G.J Anagnostopoulos on 2015-10-08 13:48:01+00:00:

Very nice writeup.Thanks!

Comment from Denis Akhiyarov on 2015-11-16 16:19:06+00:00:

@asmeurer:disqus what do u think of closures to avoid partially OOP? or limiting advanced features of OOP in metaclasses?