Hacker News Reader

> Then don’t [use them, it's that simple!]

The problem with classes in languages that use them as a main abstraction (Java, Ruby, etc) is that people reach for them for all abstraction and software design as their Day 1 tool.

All program state and behavior is now immediately fragmented from Day 1 in arbitrary buckets and my experience some moss quickly grows on them and things are never changed for the life of the program.

Just seems your post doesn't offer much insight beyond the classic OOP advice I've heard for years when people realize it's not that great: oh no, you're doing it wrong, don't do the bad things, just do the good things and ensure everyone else is doing them too. I don't see how that's actionable nor useful.

Limiting class use as much as possible and using functional module pattern as TFA does, on the hand hand, is actionable advice for these common issues with classes.

I just don't see much of a practical difference between these two approaches. From a functional perspective, objects are fundamentally a set of namespaced functions that implicitly take the same state/map/JSobj as an argument bound to "this". You can pass that state in explicitly and it just becomes what the author is talking about. And you can have the same state-management nightmares with that approach, because nothing is fundamentally different. Instead of obj.method(arg1) you have namespace::function(obj, arg1). I've worked in a very large frontend codebase using this technique and it's just as much of a pain as implicitly managing state with objects, if not more of a pain b/c it's no longer idiomatic.

State management is hard. Changing how you refer to the state isn't going to make it any easier, just different.

The difference with this approach is that any function can take obj as an argument. If it's pass by reference, any function can mutate obj. If obj winds up in an inconsistent state, any function in the entire codebase could have done it.

With a class, however, you normally make the data members private; that is, only the member functions of the class can change them. If the data gets mangled, you now have a very small set of places to look. That difference matters when debug time comes around.

If you use a functional approach, you’re probably not mutating anything ever. That usually makes it trivial to find the source of a problem, because you can quickly isolate it to a specific call stack.

> only the member functions of the class can change them. If the data gets mangled, you now have a very small set of places to look.

But probably anything could have called those mutating methods, so you still need to consider the entire codebase.

Anything could have called those mutating methods. But only those mutating methods could have put the object in an inconsistent state. I therefore have to fix the method that did that, and then let anything in the entire codebase freely call those methods.

Those limits only apply to certain languages. In typescript you can keep functions private to a module, and in functional languages you would likely return a new object instead of mutating the existing ones. Heck even in C you can enforce privacy without needing a class -- only expose certain functions in the header and pass around handles instead of the data structure directly

If classes were just that then they'd not be so bad. They also tend to bring inheritance along with them, though, and that's a messy beast.

It's classical inheritance in particular that's fragile and rigid and problematic.

Prototypical inheritance (which, I assume, is the other side of what you're referring to) is also weird. Prototypes eliminate classes as a special thing (relegating them to mere constructors or factories, which is fair) but they don't help with typing (compiler-enforced or logical).

If A has B in its prototype chain, are all values of A able to be transparently treated as values of B? Plausibly, this works, but there's nothing that really enforces it. Prototype inheritance is just a way of not needing to repeat code.

I agree it's a bit better than class inheritance, but most of the time all you need and want is composition.

We're agreed that prototypal inheritance (at least in Javascript) is orthogonal to typing. Your question about the values of A and B seems to imply a parent:child relationship -- which is the kind of hierarchy that we're looking to avoid, right? It's straightfwd to flatten the prototype chain using a single delegate prototype.

Yes, favor composition over inheritance.

FWIW, I really like Eric Elliott's take on this stuff: https://medium.com/javascript-scene/common-misconceptions-ab...

That implicitness is part of the problem.

In an object, all the functions implicitly take that state (or explicitly don't if you mark them static).

So instead of namespace::function(arg1), you now have namespace::function(obj, arg1), even when your function has nothing to do with obj. From the outside, you then have to wonder which members of obj might be being read or written inside the function. If lots of those methods call other methods, which may or may not modify the state of the object, you can end up in a situation where it's hard to reason about the functions because you have to read a lot of code to work out what the inputs and outputs really are.

This is the problem in the Java-style "everything must be a member of a class" approach. People have a tendency to make everything into members of objects.

A function that only takes the values it needs is much easier to reason about.

I think that you are right in that there isn't much practical difference between the two approaches when well-written (in particular when staticness/mutability/constness are clear). However, I find poorly written OO (e.g all methods are instance methods, local variables stored as members) to be really tricky to reason about, and all too common. I haven't had that problem with poorly-written non-OO code.

I think this can reasonably be described as a footgun rather than a bad design. Instance methods should relate to the state of the instance. If they don't that's a poor design choice. This is a pretty easy code smell to reject in code review.

Perhaps Java would be cleaner if it had free functions. But this isn't so different than a big class that has a pile of static methods.

C++ also addresses the "you have to wonder what members might be read or written inside the function" by encouraging the use of "const" as much as possible. You get really nice invariants preventing surprise state changes in receiver objects and other parameters through judicious use of "const", even if everything is a class or object.

> This is a pretty easy code smell to reject in code review.

It is if the code was reviewed. If, OTOH, it just grew until something needs to be done (like the object with 60 public methods that I'm currently trying to refactor), you can have a devil of a time unpicking it.

The same could be true where free functions are preferred, but it seems that most programmers seem to have grasped the idea that global variables are hard.

> by encouraging the use of "const" as much as possible.

I'm a big fan of const-correctness. I haven't written C++ in years, but I always used to love putting 'const' everywhere.

If you aren't doing code review then no design principles will save you.

But that's the point I'm trying to make - Over my career, I have inherited bad code in both styles - "prefer objects" and "prefer functions". In my experience, bad objects tend to be a nightmare. Bad free functions tend to just be a bit annoying.

There are only two ways in which code review can keep your codebase clean in this situation: Stop doing any other development until it's all nice, or invent time travel.

"Don’t use classes" is not what I meant. It’s "don’t create abstractions”. Create the literal thing you want to create, in any way (though preferably somewhat organized), then maybe think about making it cooler.

It also wasn’t supposed to be advice. (Not sure what you mean by TFA.)

I surmise that "TFA" means "The Fine Article" referring to the source article

What do you mean by 'abstraction' here?

By the definitions I'm familiar with, functions would be abstractions of program segments, and variables would be abstractions of program data.

With that understanding, the closest you could get to writing a program without creating abstractions would be to write in assembly—but even if you opt to use as little abstraction as possible, you may just get further from your original recommendation to "Create the literal thing you want to create":

I can see a couple ways of interpreting that statement.

1) Imagine what you want to create already existed: what it would literally be is a block of machine code, so when you write your program you should make it as close to that hypothetical literal existence as possible.

2) What you want to create doesn't exist materially, so its only literal existence is a set of high-level domain-specific concepts (i.e. its existence is a spec), in which case the most literal way to represent it would be through a set of matching high-level concepts defined through a programming language, i.e. a set of matching abstractions.

Under the second interpretation at least, it requires heavy use of abstraction in order to implement the spec as literally as possible.

I think they mean something like abstract base classes.

It's tempting to design a class hierarchy from first principles: everything in the game is an entity, from which players and NPCs are derived. The NPC base class has several derived versions (allies, monsters); the monster class is specialized into animals and dragons, which in turn....

You can often paint yourself into a corner this way, where you suddenly don't want the dragon class to reuse part of the MonsterBase. They're suggesting making the classes stand-alone with duplicated code, at least until you figure out what these classes actually have in common and what is incidental overlap.

That's why designing the actual program is important. Also, static and strong typing for powerful refactoring plus extensive tests, and you can refact that Dragon class into something new. And while I do agree with you, I think it is not OOP that's bad but the programmer doesn't understand when to do inheritence vs composition etc

> Inheritance gone wrong. If a derived type behaves differently, it should not be a derived type. See Liskov substitution principle. Just because a hash map is somewhat like a list of key/value pairs doesn’t mean it should derive from one.

The trouble is that "extends" conflates three different things, and many languages don't offer an easy way to do those things separately:

1. Ad-hoc polymorphism: this thing offers the same interface as this other thing, but with a different implementation

2. Composition: this thing contains this other thing, and uses it to implement its own functionality

3. Delegation: this thing implements this interface by forwarding it to this thing that it contains (possibly overriding some parts)

So you end up with things that need to share implementation accidentally exposing a common interface, or vice versa. Thankfully we're seeing more and more languages offering the option to do delegation more explicitly (Kotlin/Rust-style delegation, Haskell/Rust-style derivation), and to do ad-hoc polymorphism without needing to share implementation (Java-style interfaces, Haskell typeclasses / Rust traits).

In Raku those things are also separate.

1. Polymorphism

    class Example {
      method be-nice () {
        'be nice'
      }
    }

    class Bill-and-Ted is Example {
      method be-nice () {
        'be excellent to each other'
      }
    }

2. Composition

    role Salaried {
      has $.salary;
    }

    role Employee {
      has $.title;
    }

    class Manager does Employee does Salaried {}

3. Delegation

    class Price {
      has $.cost;
    }

    class Product {
      has Price $.inner handles( 'price' => 'cost' );
    }

Any call to the `.price()` method on `Product` will delegate to the `.cost()` method on the inner object.

Big classes or no, I've found the key is to have good tests around your public facing contract. IME most unit tests are poor and too fragile because they treat methods as the "unit", even helper methods (or mock out calls to their own internal helper methods, if they're the public-facing methods). So if you want to move stuff around, you find your tests aren't testing for the true behavior/side effects, but just that your previous method heirarchy is in-place.

But when your public facing methods are big blobs, they tend to have lots of params that cause fairly different thing to happen, and it gets much harder to have testing confidence around that than if you had a bigger set of smaller public-facing operations.

Your thoughts on this reminds me of: https://martinfowler.com/articles/mocksArentStubs.html#Class...

It's a basic philosophical difference in what a unit test should be doing. It goes back over a decade.

Thanks for the link, I hadn't seen those terms before, but yeah, I have been debating it for a while with coworkers.

I'm a bit in between the way described there, though, since I'll often happily leave other objects mocked as long as I know that my contract successfully called that object. I don't need to test all the way through their own implementation - there should be sufficient testing on that object to drive a refactor of it. I just want to support a refactor of me.

My view is basically: "we're gonna have to restructure some of this code as future requirements come in, so let's make sure our tests ensure that the things we really want to happen do happen" (like an update being sent to the database or other backend service layer).

I have similar hesitancy about applying a lot of design patterns early. Most of the places I've worked have been in the experimentation and rapid feature development stages of the business, with all development being internal development (rather than providing an SDK to others), so being able to change the code is more critical than being able to treat the code as more of a framework.

Large classes are not always a bad thing. It's better to have a large class with 1K lines which you can break up at a later date than having lots of small classes which have unclear or overlapping responsibilities and which will be difficult to reorganize later. It's much easier to split up and categorize parts of a large blob of code than to re-categorize and merge bits and pieces of logic that are scattered all around.

What kind of coding do you do where a 1K class is considered large?

What do you consider large?

I think classes without internal state, can be large and still simple to understand. But if many mutable fields and internal constraints, then things can get complicated. Better keep such classes smaller

I would never argue smaller isn't better. But the code I work on every day tends to have much larger classes than that.

Yes, key point is to separate classes if they have state or not. I have a simple convention in my code base, a repository does not have state, a service depends on repositories & can have state, thus a repository can have lots of methods (different ways of retrieving data) & a service is specialized & only have small number of methods.

If an existing services does not match exactly what you need to do, you write a new service and reuse the same repositories.

> Then don’t. Or only do it after everything is done and you have explored the domain.

I think this really hits the nail on the head. Classes are the ultimate DRY tool but it seems like much of our industry is realizing that it's rare for any project outside of small self-contained libraries to reach the point where you know enough about your problem domain to ever start meaningfully factoring code out like this.

Instead having "here are the different shapes of state you might see floating around" and "here are some functions that can do things with certain shapes" becomes really powerful when you need to be nimble with features/requirements. Encapsulation is beautiful when the scope is specified completely up front but it I've found it leads to more complicated code and mental overhead because you create a world where the least cost path to doing what you want does a run around with types.

I came here to talk about Liskov, but since you beat me to it I'll mention SOLID principles of class design instead, which it really sounds like the OP isn't aware of or just isn't following and it feels like is the source of a lot of their class based woes.

Every "problem" that the post brings up is a consequence of incorrectly using good programming practices. Solution? Not use the good programming practices at all if we can't get it right.

Seriously, just hire a good senior software engineer

You can write terrible code with nulls and without nulls, but when all else is equal, code without nulls is less terrible. Same with code without classes.

But if I'm the kind of programmer who's going to write terrible software, why would you expect me to be able to choose a good paradigm? For that matter, why would you expect me to be able to be good enough to avoid nulls?

I used to be an oo programmer. Now I'm fully FP, and I'm never going back. When you say "not sold", I guess my question is, have you tried it?

I am and have done both. I tend to prefer a functional style, but even then I'm going to be using classes (or a similar construct) for quite a lot of problems.

porque no los dos?

I find some problems are solved better in an OO way such as interacting with a relational database.

Others like data processing, are better done in a functional pattern.

I look for the right tool for the job rather than some idealistic purity

> I find some problems are solved better in an OO way such as interacting with a relational database.

I've switched to functional interactions with a database, (Elixir/Ecto) and really, it's much better. In particular the explicit and declarative nature of the database interactions combines the convenience of an ORM with "not hiding important gotchas from you". I'm not arguing for pure functional systems (which I can see going very poorly with relational databases).

There are some things that objects are good at like caching state as a model. But even here the FP systems typically do it better via FP actors and (again, impure) message passing, which enforces no-shared memory, and at least in erlang virtual machine systems, couples segregated state with limiting blast radius for your systems failure domains, which is 150% the "right thing to do". Of course if we're getting pedantic, this is even close to OO the way that Alan Kay imagined it, than what the OP and GP talk about, and I don't consider that to be OO in the contemporary, colloquial sense of "everything that happened after Bjarne Soustroup invented C++"

I highly recommend this video for a more philosophical take on how to do "impure FP" without OO that is informed by a decade of industry experience: https://www.youtube.com/watch?v=yTkzNHF6rMs which is by Gary Bernhardt (of WAT fame)

> I look for the right tool for the job rather than some idealistic purity

This is all about right tool for the job. IMO, FP code is easier to read, easier to reason about, easier to maintain. I think it's a shame that FP gets this reputation for being 'about ideological purity'. I like using "working programmer's FP", and the FP that I use are built on designs that are driven by real, customer-use-case driven concerns and real-world constraints, and how to make life easier for programmers and operators.

>I'm not arguing for pure functional systems (which I can see going very poorly with relational databases).

Why? The very best "OO" interactions I have with a database are via Linq which is a monad [1]. What it actually does is simply build the plan for what to do in the database and actually do the query at the last possible opportunity. Exactly how it would work in a purely functional setting.

[1 ]https://github.com/louthy/language-ext/wiki/Thinking-Functio...

Yes, ecto is basically a monad too (it's based on linq), but at the edges it will violate functional purity.

Linq is functional, but functional-impure.

I largely use the OO patterns to collect related functionality based on the domain.

Many of the methods on those organizational classes are implemented in a functional manner.

I rely on the class/instance pattern for working with a database. static class methods for actions that work on multiple rows, instance methods for single row interactions.

This works especially well in typescript where I can set private/protected/public

That said, I rarely use inheritance except when it's obvious - no nested class hierarchies or other such traps.

Thanks for the video, I'll give it a watch.