3 ms·

The traits concept mentioned in your link looks very different from Rust traits. It describes something more akin to Java interfaces.

by kccqzy 2y ago

pjmlp 2y ago
Java interfaces are based on Objective-C protocols. The only big difference is how implementation is mapped into the trait specification.
- kccqzy 2y ago
  And that's the problem isn't it? Rust traits are based on GHC type classes, not at all from either Java or Objective-C or Smalltalk.
  - pjmlp 2y ago
    Thankfully this fellow Simon Peyton Jones has a talk about how they map into OOP paradigm. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://www.microsoft.com/en-us/research/publication/classes-jim-not-know-2009/ https://www.microsoft.com/en-us/research/publication/classes... "Adventure with Types in Haskell" https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=brE_dyedGm0 https://www.youtube.com/watch?v=brE_dyedGm0 On the first lecture he discusses how Haskell relates to OOP in regards of subtyping and generic polymorphism and how although different on the surface they share those CS concepts in their own ways.
    - kccqzy 2y ago
      No. Did you read the contents of the links you shared? The name of the slides in your first link is "Classes, Jim, but not as we know them". And let me quote from the slides in your first link: From slide 40: > So the links to intensional polymorphism are closer than the links to OOP. From the first bullet of slide 43: > No problem with multiple constraints > f :: (Num a, Show a) => a -> ... From the second bullet: > Existing types can retroactively be made instances of new type classes (e.g. introduce new Wibble class, make existing types an instance of it): > class Wibble a where > wib :: a -> Bool > instance Wibble Int where > wib n = n+1 From slide 46: > In Haskell you must anticipate the need to act on arguments of various type > f :: Tree -> Int > vs > f’ :: Treelike a => a -> Int > (in OO you can retroactively sub-class Tree) From slide 50: > In Java (ish): > inc :: Numable -> Numable > from any sub-type of Numable to any super-type of Numable > In Haskell: > inc :: Num a => a -> a > Result has precisely same type as argument I appreciate you sharing informative links even though they prove you wrong. I haven't seen this set of slides before but I find it a very good concise explanation of why Haskell classes are not traditional OOP classes or interfaces.
      - pjmlp 2y ago
        I didn't say they were exactly 100% the same thing, and from those videos starting at 1:01:00, I advise the section "Two approaches to polymorphism", including the overlapped set of features.
        kccqzy 2y ago
        We are commenting on an article titled "Great things about Rust that aren't just performance" and it's clear to me that one of the great things being mentioned is how Rust approaches polymorphism that's different from the typical way in Java or Objective-C. So it is more important to highlight the differences rather than the similarities. Think about it: if the Rust trait system were highly similar to Java interfaces, why would people rave about it?

The traits concept mentioned in your link looks very different from Rust traits. It describes something more akin to Java interfaces.

by kccqzy 2y ago

The traits concept mentioned in your link looks very different from Rust traits. It describes something more akin to Java interfaces.

pjmlp 2y ago

Java interfaces are based on Objective-C protocols. The only big difference is how implementation is mapped into the trait specification.

kccqzy 2y ago
And that's the problem isn't it? Rust traits are based on GHC type classes, not at all from either Java or Objective-C or Smalltalk.
- pjmlp 2y ago
  Thankfully this fellow Simon Peyton Jones has a talk about how they map into OOP paradigm. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://www.microsoft.com/en-us/research/publication/classes-jim-not-know-2009/ https://www.microsoft.com/en-us/research/publication/classes... "Adventure with Types in Haskell" https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=brE_dyedGm0 https://www.youtube.com/watch?v=brE_dyedGm0 On the first lecture he discusses how Haskell relates to OOP in regards of subtyping and generic polymorphism and how although different on the surface they share those CS concepts in their own ways.
  - kccqzy 2y ago
    No. Did you read the contents of the links you shared? The name of the slides in your first link is "Classes, Jim, but not as we know them". And let me quote from the slides in your first link: From slide 40: > So the links to intensional polymorphism are closer than the links to OOP. From the first bullet of slide 43: > No problem with multiple constraints > f :: (Num a, Show a) => a -> ... From the second bullet: > Existing types can retroactively be made instances of new type classes (e.g. introduce new Wibble class, make existing types an instance of it): > class Wibble a where > wib :: a -> Bool > instance Wibble Int where > wib n = n+1 From slide 46: > In Haskell you must anticipate the need to act on arguments of various type > f :: Tree -> Int > vs > f’ :: Treelike a => a -> Int > (in OO you can retroactively sub-class Tree) From slide 50: > In Java (ish): > inc :: Numable -> Numable > from any sub-type of Numable to any super-type of Numable > In Haskell: > inc :: Num a => a -> a > Result has precisely same type as argument I appreciate you sharing informative links even though they prove you wrong. I haven't seen this set of slides before but I find it a very good concise explanation of why Haskell classes are not traditional OOP classes or interfaces.
    - pjmlp 2y ago
      I didn't say they were exactly 100% the same thing, and from those videos starting at 1:01:00, I advise the section "Two approaches to polymorphism", including the overlapped set of features.
      - kccqzy 2y ago
        We are commenting on an article titled "Great things about Rust that aren't just performance" and it's clear to me that one of the great things being mentioned is how Rust approaches polymorphism that's different from the typical way in Java or Objective-C. So it is more important to highlight the differences rather than the similarities. Think about it: if the Rust trait system were highly similar to Java interfaces, why would people rave about it?