Why is OOP still so widely spread? (stackoverflow.blog)

You can mutate state on the inside, but still provide a "pure" mathematical function on the outside. For example, a root finding solver. The general problem/feature with objects, is that when a method returns, the object may be in a different state (and often is). Such state changes are hidden but not "encapsulated" as they still contribute to the global state of your application. In other words, the global variables are still there, you've just organised them into modules.

The same thing happens with FP and OOP. Both are too broad to be defined concisely, and the definitions, when collected, are often contradictory or necessarily exclude what others would consider valid <paradigm> languages.

Any discussion about these paradigms and their relative merit or "goodness" has to be clear about which subset of OOP and FP properties are being discussed and compared.

An example: A popular view of many current FP proponents is the idea of immutability as a key requirement of FP. But this necessarily excludes Common Lisp, a multi-paradigm language with the ability to use many other FP ideas. Instead, CL would be included under FP (or include FP as one of its paradigms) by someone focusing on things like higher order functions, being able to construct functions at runtime via closures, etc.

The same can be used to understand OO. Message passing is a property of some OO systems. Inheritance and class hierarchies are a property of others, possibly overlapping with the first. Closely tying methods to classes (see Java) is another common property. But Java and Smalltalk are both considered OO and both contain ideas absent in the other. Which of those ideas are OO, which are ancillary. And which OO ideas are present in one but absent in the other, does it invalidate the other language as an OO language or does it just mean it has a different view of OO?

[0] https://en.wikipedia.org/wiki/Definitions_of_fascism#Umberto...

Yes, these are called "Trait objects" in Rust.

https://doc.rust-lang.org/book/ch17-02-trait-objects.html

Inheritance: T IS-A Foo

Composition: T HAS-A Foo

Neither: T IS-DESCRIBED-BY Foo

If both objects `Foo` and `Bar` have a method called `baz`, calling `object.baz` will dispatch to the objects `baz` function, no inheritance needed.

In that way, there are 3 ideas when you have inheritance. The first is reuse of code. The second is a relationship between 2 classes/types such that you get the Liskov Substitution principle. The third is dynamic dispatch based on object (or type/class in most cases).

Almost all FP languages have the third (type classes, traits, generic interfaces, the list goes on) and the first (default implementations of traits/typeclasses) but none have the second.

In Python defining function f is enough for a class to be a Foo (and Foo could not exist at all in code, replaced by the informal concept that a type with method f is a Foo)

In languages like Java, there are interfaces, which are not classes at all and describe with tedious compiler-friendly explicitness what a class needs to qualify as a Foo.

On a different variability axis, sometimes you need to declare interface implementations explicitly ("class Bar implements Foo" in Java) and sometimes not (Python duck typing, C++ concepts)

And then you have Bar and Baz that implement trait Foo.

Example:

  pub trait Foo {
    // 
    fn f(&self) -> String;
    // Default implementation, can be overriden
    fn banana(&Self) -> String {
       String::from("BananaNjam!")
    }
  }

  pub struct Baz {
    pub BazThingy: String,
    pub Whatever: String,
  }

  impl Foo for Baz {
     fn f(&self) -> String {
       format!("{} {}", self.BazThing, self.Whatever)
     }
  }

  pub struct Bar {
    pub Bar: String,
    pub Tralala: String,
  }

  impl Foo for Bar {
     fn f(&self) -> String {
       format!("{} {}", self.Bar, self.Tralala)
     }
  }


  //   Now function that uses Foo, could be any object that implements foo
  pub fn FooFighter( item: &impl Foo) {
    println!("FooFighters rocks because {}", item.f() );
  }

I'm coming to the opinion that, if you need private member functions to retain encapsulation, that's a strong sign that your design was never properly encapsulated in the first place.

The motivation for making something private is to prevent people from breaking your object by messing with things they shouldn't. Generally speaking, only real way for it to be possible break an object is if its internal state is complicated enough to allow that to happen in the first place. Which is itself a failure of encapsulation.

Somewhat more concretely: If you've got to private fields A and B, where any change to A must be accompanied by some corresponding change to B, and the logic for enforcing that rule needs to be enforced at several places within your class, then, at the level of abstraction your object is operating at, A and B represent a single logical entity, and should never have been represented as individual fields in the first place. They should have been encapsulated into their own object.

Even more concretely:

Don't do this:

  class Thing {
    val counter = 0;
  
    fun foo() {
      val x = counter;
      counter++;
      ...
    }

    fun bar() {
      val x = counter;
      counter++;
      ...
    }
  }

  class Thing {
    val counter = 0;
  
    fun foo() {
      val x = counter_next();
      ...
    }

    fun bar() {
      val x = counter_next();
      ...
    }

    private fun counter_next() {
      val x = counter;
      counter++;
      return counter;
  }

  class Counter {
    int state = 0;

    fun next() {
      val x = state;
      state++;
      return x;
    }
  }

  class Thing {
    val counter = Counter();

    fun foo() {
      val x = counter.next();
    }
  }

Also, this is all arguably a separate issue from using privates simply to avoid cluttering your public interface when factoring code. If you're working in a language that doesn't really have good nested functions, private methods are your next best choice.

There's a trade-off being made between conciseness on one hand and fast feedback on the other. Python leans toward conciseness and Java/C++ lean toward fast feedback. In Python you can express complicated ideas quickly, but you can't necessarily express correct ideas quickly. Whereas in C++ you can express correct ideas quickly but you can't express complicated ideas quickly.

If it's costly for you to correct defects in deployed software then you might prefer the fast feedback of C++ or Java rather than the flexibility of Python.

Since java 8, java.util.List had a sort method and Collections.sort(List) just calls List::sort. Before that, only the Collections.sort method existed.

At least from java 6 on, java has a SortedSet and SortedMap that accept comparators as constructor parameters, but have no sort methods (So basically data.sort, not collections.sort(data)).

Arrays can of course only be sorted via Arrays.sort, since arrays have no methods.

In Java, you can implement your own dispatch table quite easily

  Map<Class<?>, Consumer<Fruit>> dispatchTable = Map.of(Apple.class, fruit -> handleFruit((Apple)fruit));
  Fruit fruit = basket[0];
  dispatchTable.get(fruit.getClass()).accept(fruit);

Having used all three of the named languages, I disagree. Smalltalk has a lot more in common with Ruby than Erlang.

> I think when everyone talks about OOP today they mean the lineage that descended from C++, which broadly is: Java, Javascript, C#, Python, and Ruby, to a lesser extent Go.

Ruby, as you yourself noted, descends from Smalltalk, not C++. JavaScript descends from Self, not C++. Python doesn't really seem to descend from C++ either. I think you are confusing having (very loosely, in some cases) Algol-derived syntax for being descended from C++.

> Contemporary OOP is the enforced semantic association of data with their methods, encapsulation of private data, and shared memory.

I disagree with this description; shared memory is orthogonal to OOP, and encapsulation isn't even provided without awkward gymnastics in some of the contemporary OOP languages you (erroneously) describe as C++ descendants (e.g., Python has a unenforced convention for notating that a member should be considered private, and Ruby has private methods and makes instance variables essentially private, but also includes encapsulation-busting methods near the top of the inheritance heirarchy, like Object#instance_eval.) And without strict encapsulation, enforced syntactic association of methods with data also doesn't exist (not sure what enforced semantic association is supposed to mean, unless it is enforced by way of enforced syntactic association.)

In many HN threads with lots of comments, at some point in the thread (and very often starting at or near the top), the comments successively veer off to the right, sometimes to a ridiculous extent, forcing rightmost comments into a thin vertical column that is a pain to read. And worse, the main topic of the OP is often not discussed much at all, since the majority of comments are about these minute inconsequential details, as you say above - and since these trivia subthreads tend to get upvoted the most.

Sometimes that 'best tool' really just happens to be the one I have X years of experience in, because I'm here, right now, in front of the project, and have solved the same problem Y times before with acceptable results (systems running, people getting value as expected). That doesn't automatically justify being a stick-in-the-mud and never adopting any new technology ever.

But it also means that jumping to new tools on a semi-annual basis, you'll have a hard time having justified confidence you can deliver something of value. I have to qualify with "justified" because... I've seen too many folks who have confidence and... really shouldn't. And I recognize that because I can see how I was once there.

I had a call from someone in 2017 asking about something I'd built for them in 2002. System was still running. Someone had been doing basic system upgrades every so often, but they'd hit some logical issues and needed more insight, and pinged me. Last year I noticed a previous client project started in 2000 was still up. I've no doubt they've updated some of the back end stuff, but some of the stuff I put in place I can still see (html comment, semi-unusual url structure, etc).

Understanding that what you build might actually be in place, working for people for 15-20 years is hard to get your head around until you've actually done this for 20 years. When I was 20 I could not understand the ramifications of decisions impacting people or companies for 20 years - I just didn't have that life experience - no one at 20 does. We're often fed magical press releases about acquisitions and exits and we read stories of things shutting down, getting sunset, etc. Those aren't the norms though, I don't think.

With that in mind, my criteria for choosing the 'right tool' has shifted some in the last few years, and I'm always a bit more hesitant to jump on latest shiny trends, as... I do get somewhat concerned about the long term viability. That has to be a factor in 'best tool' calculations, no? (sorry for long ramble)...

   Math.abs(-5)

A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...

2. Hollywood principle. Library: you call us. Framework: we call you.

3. Frameworks are good for novices in certain paradigm because they guide along a standardised way to build apps. If you however find the framework's way not precise enough or its abstraction leaky then you will have a hard time escaping from the straightjacket.

Lot of frameworks actually are a combination of two things:

1. the actual "way of building apps"

2. useful library of functions

Lot of people would like to start with 1 and use 2 to guide them in the beginning, but drop 1 later on. Unfortunately frameworks couple 1 and 2 together very tightly making many people not even consider such frameworks.

You've made explicit another confounding factor: a language is more than its syntax - you have to consider the entire ecosystem and constraints being operated under - including tooling and libraries

You get people hearing that OOP sucks, and they start to have fears and hatred towards it, thinking that all OO and every single idea and concept related to it is bad.

This is called stereotyping, and it's not productive to bring into a technical conversation. Even inside FP it exists, ever saw a Scheme programer and a Haskell programmer debate? They'd go on forever about whose the one true Functional Programmer.

With that said, I would say some people would agree that operator overloading and ad-hoc polymorphism are core features of OO languages. In fact, many people learn first about ad-hoc polymorphism through an OO language, such as learning about Java Interfaces or Traits in Ruby.

So in that sense, TypeClasses do relate to OO.

This is where things get muddy. What is OO, what is FP? If you keep yourself stuck in the taxonomy you'll never leave it, because choosing labels is a subjective process. You can put the boundary wherever you want, there is no success criteria.

That said, there are real concentre ideas and implementation strategies. Those are more interesting, but don't get talked about very often.

Some of OOs main features:

- Data encapsulation

- Polymorphism

- Behavior abstraction

And Haskell similarly puts a lot of emphasis on those same features.

So what does one mean if they say OOP is bad? That those features are bad? That would transitively imply that Haskell similarly emphasises bad features?

Now I don't know about everyone, but that's not what I mean if I criticize OOP, I'm not claiming to avoid polymorphism, to get rid of behavior abstraction, and to stop trying to encapsulate data.

So the question is, what's wrong with OOP then? And this is where you'll see that things get nuanced and detailed oriented. And that it's not everything that is wrong, only certain specific things are not ideal and might have better solutions.

And at that point, you can't even speak of OOP generally, you need to speak of specific languages. For example, you could argue that Haskell TypeClasses are a better way to implement ad-hoc polymorphism than Java Interfaces. But someone could say that Self's Traits are just as good if not better than both of those approaches. Etc.

They surely do, OOP like FP, is very fuzzy and since the Simula/Smalltalk days there have been multiple ways to try to represent OOP concepts.

There isn't any OOP language that implements every OOP idea, just like there isn't any FP language that implements every FP idea.

Type classes allow for polymorphism, and combined with modules one can make use of module private implementations for the encapsulation part.

Extensibility can be achieved either by having a type implement multiple type classes, COM v1..vn style, or by delegation.

For a person trying to decide if they should learn OOP or not, I believe the above statement (along with the entire comment) is exactly what parent comment is talking about. A "noob's" reaction to that statement would be "what does that mean?", "why should I care?", "is this important?".

For other "noobs", the reaction would be "HN user leafboi seems an expert so I would stick to what he/she says even if I don't understand what he/she means and I will quote him/her every time an OOP discussion comes up. Fuck OOP".

Meanwhile there are still millions of projects done with OOP, including super-complex AAA games, and more are being done right now...