4 ms·

I know I'm missing something, but this seems like the functional version of object classes. I've mostly favored procedural programming and only use objects whe

I know I'm missing something, but this seems like the functional version of object classes. I've mostly favored procedural programming and only use objects when I have to because the abstraction can make the program harder to reason about, especially when there's a lot of inheritance. But I've heard some hype about types in Rust, and now this. The free chapter in the manning book even introduces types in terms of real world objects. So, for someone who doesn't love objects, why should I love types?

ok_dad 4y ago
Where objects can hide state or I/O in a program, types and functional type driven development make each function very clear as to what it has for input and outputs and part of that is not hiding state anywhere that doesn’t make sense. You might still have a global logger because that makes sense, but generally you know the things you have access to because they’re in the function signature. It can break down if you aren’t careful, and there’s some nuance where you might still store a configuration data as an object property, but it’s a clearly typed property that’s assigned at initialization rather than hidden state that magically appears due to some hidden program flow.
allochthon 4y ago
I recently watched this intro to the topic, which I found really interesting: https://www.youtube.com/watch?v=bnnacleqg6k https://www.youtube.com/watch?v=bnnacleqg6k
- mcdonje 4y ago
  That was a good talk. Thanks for linking it.
josephcsible 4y ago
> I've mostly favored procedural programming and only use objects when I have to because the abstraction can make the program harder to reason about, especially when there's a lot of inheritance. In functional programming, you generally abstract in different directions than you do in object-oriented programming. IMO, functional abstractions make things easier to reason about, since they generally constrain what any given block of code might do. > So, for someone who doesn't love objects, why should I love types? Because powerful type systems mean that a lot of mistakes will be compiler errors instead of bugs.
ImprobableTruth 4y ago
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
Objects and types are quite different concepts. Objects are just "things" in the memory of a computer. Anything in a program is an object. That's why for example the C guys are constantly talking about objects, even C does not have any special facilities to handle more complex types of objects. Types on the other hands side are an abstract concept. You could think of them like sets of objects (even this is a little bit misleading as types are not really sets, but types, which is a different, but in some ways quite similar, mathematical concept). What looks quite similar are types and classes. In OOP languages both are bound to each other: A class describes a set of objects (as a class is a kind of template for objects) and it introduces at the same time a corresponding type (which is as mentioned also "a set" of objects). The interesting thing about types is, as they're an abstract concept, they exist independent of running your program. (Objects OTOH manifest not before they get constructed at runtime in the memory of a computer). With the help of a sound type system it's possible to prove things about the runtime behavior of a program. That's where the value of types comes form. They allow to construct more correct programs by ruling out errors by type-checking a program, which can be done in the case of a static type system at compile time. Stronger type-systems allow to constrain the possible runtime behaviors of a program better and more precisely. They help to make illegal program states unrepresentable. Also it gets possible to deduct correct-by-construction implementations of some program behaviors solely form types. That's what type-driven development is about. So, if you don't like runtime bugs but correct programs you should like strong static typing.

ok_dad 4y ago

Where objects can hide state or I/O in a program, types and functional type driven development make each function very clear as to what it has for input and outputs and part of that is not hiding state anywhere that doesn’t make sense. You might still have a global logger because that makes sense, but generally you know the things you have access to because they’re in the function signature. It can break down if you aren’t careful, and there’s some nuance where you might still store a configuration data as an object property, but it’s a clearly typed property that’s assigned at initialization rather than hidden state that magically appears due to some hidden program flow.

allochthon 4y ago

I recently watched this intro to the topic, which I found really interesting: https://www.youtube.com/watch?v=bnnacleqg6k https://www.youtube.com/watch?v=bnnacleqg6k

mcdonje 4y ago
That was a good talk. Thanks for linking it.

josephcsible 4y ago

> I've mostly favored procedural programming and only use objects when I have to because the abstraction can make the program harder to reason about, especially when there's a lot of inheritance. In functional programming, you generally abstract in different directions than you do in object-oriented programming. IMO, functional abstractions make things easier to reason about, since they generally constrain what any given block of code might do. > So, for someone who doesn't love objects, why should I love types? Because powerful type systems mean that a lot of mistakes will be compiler errors instead of bugs.

ImprobableTruth 4y ago

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

Objects and types are quite different concepts. Objects are just "things" in the memory of a computer. Anything in a program is an object. That's why for example the C guys are constantly talking about objects, even C does not have any special facilities to handle more complex types of objects. Types on the other hands side are an abstract concept. You could think of them like sets of objects (even this is a little bit misleading as types are not really sets, but types, which is a different, but in some ways quite similar, mathematical concept). What looks quite similar are types and classes. In OOP languages both are bound to each other: A class describes a set of objects (as a class is a kind of template for objects) and it introduces at the same time a corresponding type (which is as mentioned also "a set" of objects). The interesting thing about types is, as they're an abstract concept, they exist independent of running your program. (Objects OTOH manifest not before they get constructed at runtime in the memory of a computer). With the help of a sound type system it's possible to prove things about the runtime behavior of a program. That's where the value of types comes form. They allow to construct more correct programs by ruling out errors by type-checking a program, which can be done in the case of a static type system at compile time. Stronger type-systems allow to constrain the possible runtime behaviors of a program better and more precisely. They help to make illegal program states unrepresentable. Also it gets possible to deduct correct-by-construction implementations of some program behaviors solely form types. That's what type-driven development is about. So, if you don't like runtime bugs but correct programs you should like strong static typing.