16 ms·

IMO types are fundamentally about restriction. Limiting the shape of your data and what you can do with it, so that this information becomes explicit - making i

IMO types are fundamentally about restriction. Limiting the shape of your data and what you can do with it, so that this information becomes explicit - making it easier to reason about the program, both for yourself and the compiler. I think this is illuminated very well by sum types. If you have a variable of X | Y, you know that it's either exactly X or Y. You can pattern match, to handle the case that it's an X and then you call a function on it and you know exactly which function it is. Inheritance is so nightmarish to me because people tend to use it in such a way that I often don't have the slightest clue what I'm actually dealing with, buried under layers of indirection that seem to serve absolutely no purpose. If I have an object of class X, is that actually an X, or something that just looks like it and actually behaves differently because someone decided to override a method in a subclass? Interfaces tend to be much less monstrous IME, so I don't think the issue is with abstractions themselves. Especially when people use interfaces to abstract over common behavior between data types, rather than trying to future proof for something that never occurs.

still_grokking 4y ago
I don't know of any sane language that does not support interfaces. Type-classes are also just interfaces. Additionally quite some orthogonal concepts are mixed up here: Classes, inheritance, overriding, runtime types, patterns… In the end OO and FP are anyway the same thing at the core. You can mechanically translate one into the other: https://www.javiercasas.com/articles/codata-in-action https://www.javiercasas.com/articles/codata-in-action
- ImprobableTruth 4y ago
  ...C. I thought the context here made it obvious, the person I replied to was talking about programming in a procedural manner and eschewing abstractions. I never even mentioned anything that even relates to runtime types, I don't know why you'd bring them up? And saying that classes, inheritance and overriding are orthogonal is bizarre. They're intricately linked and at the heart of OOP. It doesn't even make sense to define overriding without inheritance. >In the end OO and FP are anyway the same thing at the core. You can mechanically translate one into the other: Coinductive types have destructors so they look a bit OO-ish, but that's it. The key part of OO isn't having fields, but inheritance.
  - still_grokking 4y ago
    > I never even mentioned anything that even relates to runtime types, I don't know why you'd bring them up? You've complained about dynamic overrides. You're talking about dynamic overrides because in the case of "static overrides" (or usually in "normal" OOP languages that are overloads) there can't be any confusion which method gets called. The compiler, and therefore your IDE, knows that. Dynamic overrides are only a thing when dynamic dispatch is involved. Dynamic dispatch is directly related to runtime types. > And saying that classes, inheritance and overriding are orthogonal is bizarre. They're intricately linked and at the heart of OOP. That's only the case for languages like C++ / Java and clones. You can have of course inheritance and overriding without classes. See Self or more prominently JavaScript. (No, JS does not have classes. It has by now some syntax sugar that is called "class", but that's just a simple source translation to JS prototype system under the hood). > It doesn't even make sense to define overriding without inheritance. Of course you can have overriding without inheritance. You can create type-class hierarchies where functions on the leaves override functions above them in the hierarchy. This is possible without having any inheritance relation between the objects involved. I could show you Scala code that does exactly this. In a system with prototypes there is also no need for any inheritance relationship to override something. You can just grab the prototype of an object and change ("override") methods on it. You can do that form everywhere in your program in a language like JS… And in theory you could have inheritance without overriding. Also of course no classes are needed for that. (Even I don't know any language that does something funny like that as it would be quite limiting). > Coinductive types have destructors so they look a bit OO-ish, but that's it. No, that's not it. You can create an algorithm that can translate code form the FP form to the OO form (and back). I didn't invent this. Someone actually created such an "converter". (I would need to dig a little bit to find the relevant paper and YouTube talks again; maybe you're faster with googling :-D. If not, feel free to ask again, than I would go digging in my PDF chaos). > The key part of OO isn't having fields, but inheritance. Well, the inventor of OO himself would strongly disagree… ;-) OO is about message passing. The C++ / Java "OOP interpretation" is some quite ill abnormality OTOH.

still_grokking 4y ago

I don't know of any sane language that does not support interfaces. Type-classes are also just interfaces. Additionally quite some orthogonal concepts are mixed up here: Classes, inheritance, overriding, runtime types, patterns… In the end OO and FP are anyway the same thing at the core. You can mechanically translate one into the other: https://www.javiercasas.com/articles/codata-in-action https://www.javiercasas.com/articles/codata-in-action

ImprobableTruth 4y ago
...C. I thought the context here made it obvious, the person I replied to was talking about programming in a procedural manner and eschewing abstractions. I never even mentioned anything that even relates to runtime types, I don't know why you'd bring them up? And saying that classes, inheritance and overriding are orthogonal is bizarre. They're intricately linked and at the heart of OOP. It doesn't even make sense to define overriding without inheritance. >In the end OO and FP are anyway the same thing at the core. You can mechanically translate one into the other: Coinductive types have destructors so they look a bit OO-ish, but that's it. The key part of OO isn't having fields, but inheritance.
- still_grokking 4y ago
  > I never even mentioned anything that even relates to runtime types, I don't know why you'd bring them up? You've complained about dynamic overrides. You're talking about dynamic overrides because in the case of "static overrides" (or usually in "normal" OOP languages that are overloads) there can't be any confusion which method gets called. The compiler, and therefore your IDE, knows that. Dynamic overrides are only a thing when dynamic dispatch is involved. Dynamic dispatch is directly related to runtime types. > And saying that classes, inheritance and overriding are orthogonal is bizarre. They're intricately linked and at the heart of OOP. That's only the case for languages like C++ / Java and clones. You can have of course inheritance and overriding without classes. See Self or more prominently JavaScript. (No, JS does not have classes. It has by now some syntax sugar that is called "class", but that's just a simple source translation to JS prototype system under the hood). > It doesn't even make sense to define overriding without inheritance. Of course you can have overriding without inheritance. You can create type-class hierarchies where functions on the leaves override functions above them in the hierarchy. This is possible without having any inheritance relation between the objects involved. I could show you Scala code that does exactly this. In a system with prototypes there is also no need for any inheritance relationship to override something. You can just grab the prototype of an object and change ("override") methods on it. You can do that form everywhere in your program in a language like JS… And in theory you could have inheritance without overriding. Also of course no classes are needed for that. (Even I don't know any language that does something funny like that as it would be quite limiting). > Coinductive types have destructors so they look a bit OO-ish, but that's it. No, that's not it. You can create an algorithm that can translate code form the FP form to the OO form (and back). I didn't invent this. Someone actually created such an "converter". (I would need to dig a little bit to find the relevant paper and YouTube talks again; maybe you're faster with googling :-D. If not, feel free to ask again, than I would go digging in my PDF chaos). > The key part of OO isn't having fields, but inheritance. Well, the inventor of OO himself would strongly disagree… ;-) OO is about message passing. The C++ / Java "OOP interpretation" is some quite ill abnormality OTOH.