That's how the real world is. The state and the functionality are in one thing. OOP models the real world. Are you suggesting that data should be stored in global variables instead?

You don’t lose scoping by avoiding classes. I’m not really sure what you are asking. You store all data in primitives or structs, and pass it along to functions, which mutate the data. Much simpler to reason about, comprehend, debug, test, and so on.

> You store all data in primitives or structs, and pass it along to functions

OK, so in global variables, like in C language. And you think this is better than OOP. Glad that's working for you!

> OK, so in global variables, like in C language.

Not at all!

This is the main reason OO has dominated for so long. OO has somehow taken on the meaning "Anything which isn't C".

And it's not even an accurate representation of C, it's a straw man version of C. C programmers know the perils of global variables.

Here is some code:

  int myState;
  void myFunc() {

  }  

If I take the above code and make it look like C:

  #ifndef MYSTUFF_H
  #define MYSTUFF_H
  int myState;
  void myFunc() {
    ...
  }
  #endif

Yuck! Global variable! disgusting!

Now I make it look like Java:

  class MyStuff {
    int myState;
    void myFunc() {
      ...
    }
  }

This is somehow "encapsulated". But start calling myFunc() at different times from different threads and see if myState behaves more like a stack variable or a global variable.

OO made it much more socially acceptable to pollute your code with this kind of "encapsulation". And OO devs decided that even this was too much of a straightjacket - some people liked C#'s take on properties, where you didn't have to work so hard writing getters and setters (further breaking encapsulation).

Real C Programmers™ actually encapsulate:

    my_state_t myFunc(my_state_t in) {..}

In your last line of code the my_state_t is really the "this" pointer. You're simulating OOP.

Yes!

Once you take away inheritance ("prefer composition"), polymorphism (better offerings elsewhere), encapsulation (not encapsulation!), message-passing (better offerings elsewhere), you're left with a small syntactic trick that really wasn't that hard to do in C.

Even Lua gives you that [1]:

> This use of a self parameter is a central point in any object-oriented language. Most OO languages have this mechanism partly hidden from the programmer, so that she does not have to declare this parameter (although she still can use the name self or this inside a method). Lua can also hide this parameter, using the colon operator.

    function Account.withdraw (self, v)
      self.balance = self.balance - v
    end

    function Account:withdraw (v)
      self.balance = self.balance - v
    end

[1] https://www.lua.org/pil/16.html

This is miniature OOP and that puts you in "major catastrophe" territory according to some on this thread.

Uh no. You would typically retrieve the data in a function and assign it to a variable scoped to the function. The struct or array then gets passed through a pipeline of functions to do something possibly writing the data back to disk or the db.

Even if there is some data I want to keep in memory there is no need for a global usually. In go I may just keep it in a var in a goroutine that doesn’t exit until the process does.

In go you mix state with logic (example below), which apparently is a "major catastrophe" according to some on this thread.

   type Engine struct {
       HorsePower int
   }

   func (e Engine) Start() {
       fmt.Println("Engine is starting with", e.HorsePower, "horsepower.")
   }

> Are you suggesting that data should be stored in global variables instead?

According to FP, data shouldnt be stored where possible and yes, if you can, store global or top level immutable blobs and pass by reference.

> That's how the real world is.

Well, maybe not. I dont rememer where it came to me that OOP is like classical physics, where everything has to get passed around with the speed of light and FP is like quantum physics, stateless until you do the computation. I dont know how accurate this analogy is but it still fascinates me since modelling reality is enlarge what programming is.

And that’s the essence of OOP. Once you grasp why that is such a colossal blunder, it’s obvious what a mistake the entire endeavor truly is.