Why are objects so hard to debug?

I think this is largely a moot point with debuggers that can (conditionally) breakpoint-on-write -- if you see a global variable being set to a wrong value, put a breakpoint-on-write to that variable with condition to trigger when that wrong value is written, and you'll stop exactly in the code that wrote to it. Then trace back the computation from there to see where that value came from.

What really makes programs hard to debug is their total size and complexity; in object-oriented programs that tend to favour emphasis on reducing local complexity, global complexity increases. Tracing through layers of indirection whose only purpose is seemingly to call other layers is tedious, and the flow of data --- something which is important to see --- becomes more obfuscated.

Your debugger is broken. The call stack will have implicit "this" pointers/references in each frame, and the instance variables can be found there.

Now, the rant as a whole has a valid point that mutable state causes confusion in terms of finding the code that mutated it. An argument for immutability or time-reversible debuggers. But OOP at least gives you a chance to keep the mutating methods close together where you can find them.

The more you program the more you tend to design with the intent of making it easier to debug. You end up doing a lot of things that borrow from other paradigms like passing more variables to method calls while using fewer instance variables and consciously avoiding side effects.

Honestly, I don;t know enough about the functional paradigm to argue whether it is easier to debug. It looks like it has a lot of features that would make it so.

Definitely agree that inheritance, instance variables, setters make things more difficult. Inheriting from a framework is asking for trouble.

Firstly I don't spend most of my time debugging. I do spend a fair amount of time programming in a way that makes it less likely I'll have to debug (asserting contracts, implementing tests). Whacking out some random spaghetti code, then spending days navigating it isn't productive.

And secondly, thinking about the recent projects I've worked on, the debugging I have done has not been about finding where a variable got the wrong value. The only day-sapping bugs I've had recently have been figuring out why some piece of code performs an incorrect calculation; and figuring out how to ensure the correct order of different operations. The latter I suspect would have been more difficult in an FP with a more complex stack trace and tail call elimination. Most of the smaller debugging problems I have relate to impedance mismatches between my code and 3rd party libraries.

Library interface problems seem less in FP, but mostly because there are fewer libraries. It is easy to make a totally understandable, simple, programming environment if you never have to do any heavy lifting with other people's code.

I program in FP, but a lot of the time I end up in OO languages with good library, tool, testing and debugging support.

I can't help but think this is another case of FP-zealots interpreting the world in a way that maximises the problem they know how to solve.

With objects, state is encapsulated and not modified by the outside, making them much more predictable and thus also easier to test.

This one goes further and argues that oop is !imperative. Have popular definitions changed while I wasn't paying attention?

Modern debuggers have conditional breakpoints, breakpoints on write, breakpoints on count, sophisticated formatters and all kinds of facilities which make the problem of debugging a method call that might go to a subclass instead of the base class all but trivial.

Debugging complex programs is hard, regardless of the underlying methodology that this code uses.

There are advantages to the functional approach - I use it for most of my programming these days - but this article is pure FUD. Actually it goes beyond that, making claims that are outright falsehoods.

> The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming.

what ?!?

Polymorphic virtual methods are also hard to debug because you must figure out what type the object actually is. You must either run the code with breakpoints, or run it mentally in your head.

Don't give up on knowing exactly who's in control and what the data structures look like unless there is a clear benefit.

With heavy OOP in C++, you often end up with code that knows nothing about the data except a heap pointer and a pointer to a virtual method table. Not only does this make debugging a pain, it kills almost every opportunity for compiler optimization.

Of course, this pattern can be really useful. But it should be selected as a very deliberate design process, not "Oh, we put everything behind interfaces because I heard it's good."

The only place where the pattern is really, truly necessary is when a library needs to call user-supplied methods on user-supplied data. In C this looks like:

    // library.h
    void set_callback(void (*myfunc)(void *, int), void *);
    
    // me.c
    struct S { ... };
    void update_s(void *s, int new_value); // must cast to struct S *

    struct S s;
    set_callback(&update_s, &s);

    a.getB().getC().getD().e() - NullPointerException can have 4 causes

    B b = a.getB();
    C c = b.getC();
    D d = c.getD();
    d.e(); // NPE can have only 1 reason, you can inspect b,c,d at debug time without stepping inside

The most common things that cause this in code are defaults - when you have defaults and need to debug you need to consider many possible reasons the end effect is what it is.

It's not a big deal, but it makes debuging one step harder (instead of "I know why we get there, let's go deeper" it's "We get there either because of X or Y, let's debug to decide, or go both ways").

I think if you feel this way, you should definitely look for languages and tools that don't admit as many bugs.

So, I guess yeah, if you don't have great tools anything is "so hard to debug"

Also, always using inheritance is bad, but so is never using inheritance. (Does that need explanation?)

With imperative code, you can just hop up the stack!

...unless something screws up your stack frames, in which case you win nothing good day sir.

With OOP code, you alternate framework code with application code, which never happens with imperative libraries!

...except any sort of nontrivial library that has proper abstraction via callbacks, in which case you very much do end up alternating application code with libraries.

Inheriting from a framework object can do things you don't expect!

...except that in languages that aren't C++, it's usually pretty easy to control whether or not you execute parent class code instead of/in addition to your extended function.

The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming.

ahahahahha what? no.

Imperative != functional programming. At all. Had a CTO try to convince me this was case, was dead wrong. Imperative code allows for mutation of global state and perhaps no functions-as-first-class-citizens. Functional code (in theory) allows for no mutation of global state and always has functions-as-first-class-citizens.

Author has also left out declarative languages, which also somewhat fit that definition, but hey, who's counting?

The best way to illustrate the issue with debugging multi-threaded programs is to describe the debugging scenario as consisting of multiple stacks.

What? Fuck no. The biggest issue with debugging multi-threaded programs is having shared mutable state. The fact that thread A can write and screw up something depended upon by thread B, which is totally supported in imperative programming and is hard to protect against, is the problem. Second would be the magic of race conditions, live locks, dead locks, and all of that jazz.

OOP is, other than pure functional programming, perhaps the only sane way of dealing with mutlithreaded programs when you aren't subscribing whole-hog to actor-style message passing.

~

This is a bad article, and displays both a fundamental lack of understanding as well as a sort of arrogance in the profession of the aforementioned ignorance.

EDIT:

And no, OOP/actor programming is not a panacea for all of your problems either.

There is quite a lot of room in the world for simple imperative programs (which are basically objects interfaced with from the command line) or chained functional programs (very useful for data transformation pipelines).

That said, there are reasons why we invented OOP. There are use cases for it. There are places where it is the right thing, and to pretend otherwise makes it all the harder to know when not to use it.