6 ms·

What on Earth makes you think it's gone out of fashion? Pretty much all of the most widely-used languages have classes or analogues, if not full OOP.

ogogmad 4y ago
I thought that privileging the first argument of a function, which is all that separates a method from a function, was understood to be an ugly hack. I thought that this was acknowledged now, and only legacy languages are stuck with it. Julia, Rust and Go don't do this. So it's going out of fashion and becoming legacy. IOW, there was never really a difference between obj f(obj); and class obj {obj f();} so the whole idea was a mistake. Likewise, obj.f() should be synonymous with f(obj) and the fact that in some languages it's not is evidence of a poorly thought-out abstraction. See multiple dispatch for the death blow. There's also a discussion elsewhere here about operator overloading, and how arithmetic operators don't behave like methods.
- germandiago 4y ago
  From a mathematical point of view it can seem like that. But now pick a language like Nim, whcih also has a crazy regex to match symbol equality, and unigorm call syntax etc. and the IDE completions are much harder to find.
- Jtsummers 4y ago
  > I thought that privileging the first argument of a function, which is all that separates a method from a function, was understood to be an ugly hack. I thought that this was acknowledged now, and only legacy languages are stuck with it. Julia, Rust and Go don't do this. So it's going out of fashion and becoming legacy. [emphasis added] What? Go has methods which "privilege" the first argument to functions: https://go.dev/tour/methods/1 https://go.dev/tour/methods/1 func (v Vertex) Abs() float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } Though it moves the argument out of the argument list and between the func keyword and method name. Rust also has a notion of methods: https://doc.rust-lang.org/rust-by-example/fn/methods.html https://doc.rust-lang.org/rust-by-example/fn/methods.html Were you thinking of other languages?
  - mappu 4y ago
    In Go you can assign this "method" to a func(v Vertex) float64 and it will run just fine: https://go.dev/play/p/NBS4Fc3r0w- https://go.dev/play/p/NBS4Fc3r0w- It really is just syntax sugar,
- lifthrasiir 4y ago
  You can have multiple `f` with different "arguments" (if you consider a receiver a part of arguments) without the full multimethod, which is actually pretty hard to get it right and only one language out of your examples (Julia) does that. Other two languages (Rust and Go) fully retain classes, slightly obscured to fit with traits and interfaces respectively.
- jakelazaroff 4y ago
  obj.f() shouldn't necessarily be synonymous with f(obj) though. How would the latter case handle private fields, for example?
  - ogogmad 4y ago
    You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. If you think that `obj.f()` and `f(obj)` should mean different things, then your reasoning is likely faulty.
    - jakelazaroff 4y ago
      To clarify, I’m talking about private fields in each object/struct. You could say all functions defined in the same module get access to private struct fields. That works until you want a more specialized version of some of those functions — essentially, a different module that has access to protected fields. Here’s another example. You’re writing a function `g` that accepts an object of type `Foo` and calls function `f` on it. You have a default implementation of `f`, but you also want to let the caller supply their own implementation. If you have some way of attaching behavior to a type — classes, typeclasses, etc — this is trivial. If not, your function has to explicitly ask for every single function from the caller.
    - still_grokking 4y ago
      > You'd use a module to hides things. And than you need functors and existential types to recreate classes… ;-) Your reasoning is likely faulty if you don't see that OOP is a very advanced and great module system. The only problem with OOP is that it's often misused for other things that aren't modules. But that's a different story.
    - theteapot 4y ago
      > You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. And you can instantiate multiple instances of these "modules"?
- imtringued 4y ago
  I wish I had your problems.

ogogmad 4y ago

I thought that privileging the first argument of a function, which is all that separates a method from a function, was understood to be an ugly hack. I thought that this was acknowledged now, and only legacy languages are stuck with it. Julia, Rust and Go don't do this. So it's going out of fashion and becoming legacy. IOW, there was never really a difference between obj f(obj); and class obj {obj f();} so the whole idea was a mistake. Likewise, obj.f() should be synonymous with f(obj) and the fact that in some languages it's not is evidence of a poorly thought-out abstraction. See multiple dispatch for the death blow. There's also a discussion elsewhere here about operator overloading, and how arithmetic operators don't behave like methods.

germandiago 4y ago
From a mathematical point of view it can seem like that. But now pick a language like Nim, whcih also has a crazy regex to match symbol equality, and unigorm call syntax etc. and the IDE completions are much harder to find.
Jtsummers 4y ago
> I thought that privileging the first argument of a function, which is all that separates a method from a function, was understood to be an ugly hack. I thought that this was acknowledged now, and only legacy languages are stuck with it. Julia, Rust and Go don't do this. So it's going out of fashion and becoming legacy. [emphasis added] What? Go has methods which "privilege" the first argument to functions: https://go.dev/tour/methods/1 https://go.dev/tour/methods/1 func (v Vertex) Abs() float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } Though it moves the argument out of the argument list and between the func keyword and method name. Rust also has a notion of methods: https://doc.rust-lang.org/rust-by-example/fn/methods.html https://doc.rust-lang.org/rust-by-example/fn/methods.html Were you thinking of other languages?
- mappu 4y ago
  In Go you can assign this "method" to a func(v Vertex) float64 and it will run just fine: https://go.dev/play/p/NBS4Fc3r0w- https://go.dev/play/p/NBS4Fc3r0w- It really is just syntax sugar,
lifthrasiir 4y ago
You can have multiple `f` with different "arguments" (if you consider a receiver a part of arguments) without the full multimethod, which is actually pretty hard to get it right and only one language out of your examples (Julia) does that. Other two languages (Rust and Go) fully retain classes, slightly obscured to fit with traits and interfaces respectively.
jakelazaroff 4y ago
obj.f() shouldn't necessarily be synonymous with f(obj) though. How would the latter case handle private fields, for example?
- ogogmad 4y ago
  You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. If you think that `obj.f()` and `f(obj)` should mean different things, then your reasoning is likely faulty.
  - jakelazaroff 4y ago
    To clarify, I’m talking about private fields in each object/struct. You could say all functions defined in the same module get access to private struct fields. That works until you want a more specialized version of some of those functions — essentially, a different module that has access to protected fields. Here’s another example. You’re writing a function `g` that accepts an object of type `Foo` and calls function `f` on it. You have a default implementation of `f`, but you also want to let the caller supply their own implementation. If you have some way of attaching behavior to a type — classes, typeclasses, etc — this is trivial. If not, your function has to explicitly ask for every single function from the caller.
  - still_grokking 4y ago
    > You'd use a module to hides things. And than you need functors and existential types to recreate classes… ;-) Your reasoning is likely faulty if you don't see that OOP is a very advanced and great module system. The only problem with OOP is that it's often misused for other things that aren't modules. But that's a different story.
  - theteapot 4y ago
    > You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. And you can instantiate multiple instances of these "modules"?
imtringued 4y ago
I wish I had your problems.