Hacker News Reader

Comment by mcdonje | Hacker News Reader

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?

View on HN

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.

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

...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.

> 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.

> 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.

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.

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.

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

That was a good talk. Thanks for linking it.

Reply on news.ycombinator.com