4 ms·

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

candiddevmike 6y ago
I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.
- masklinn 6y ago
  > I think you're looking at it wrong. You can absolutely solve it with interfaces There are lots of generics use case you either can't solve at all with interfaces, or you have to contort every which way and usually lose something in the process (type-safety, performances, readability, …).
chowells 6y ago
You can't use interfaces to prevent inserting values of the wrong types into a set. When you view the purpose of types as preventing bugs, that seems like a giant missing feature.
coldtea 6y ago
>The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.
- lkramer 6y ago
  Sorry, when I said new data structures, I meant containers like maps and list, which I very rarely get to create day to day. I can see it for your transformations, but I have seldom seen cases where generics would really help (usually we're talking about comparing complex structure types that will need custom code anyway).
  - esarbe 6y ago
    How about sets?
  - Smaug123 6y ago
    "Theorems for free"! By which I mean, when I'm coding something and it could be universally quantified on the type, then it's better to do so. That way, it's impossible to phrase certain errors. For example, a function `Set<a> -> Set<a>` must produce a subset of the input set; that's guaranteed by the types. I can't accidentally include the value 0 in my set, because 0 isn't of that generic type. The generic forces you to think in terms of the structure you're manipulating, rather than in terms of its contents.
Someone 6y ago
“Can you give a real world example that couldn't be solved with interfaces?” Of course not. Go is Turing complete, and generics do not make it Turing-completer (whatever that may mean) The question isn’t about what can or cannot be done, but about expressiveness, ease of understanding for humans versus language size (even if you have plenty of disk and RAM, That correlates with buggyness of the compiler) and compilation speed.
deleted 6y ago
[deleted]
arp242 6y ago
> Can you give a real world example that couldn't be solved with interfaces? There are none, you can always work around them, with the only downside is that you'll move some potential compile-time errors to runtime errors. But that's the wrong conversation to be having; we could also say "why do we need floats? Everything can be solved with ints too", which is true, but also a lot of work and a poor trade-off. Similar arguments exist for many language features. So it's a question of trade-offs: how much time will this save people? Will it reduce faults? And what are the costs of adding this? And how do they balance?

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

candiddevmike 6y ago

I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.

masklinn 6y ago
> I think you're looking at it wrong. You can absolutely solve it with interfaces There are lots of generics use case you either can't solve at all with interfaces, or you have to contort every which way and usually lose something in the process (type-safety, performances, readability, …).

chowells 6y ago

You can't use interfaces to prevent inserting values of the wrong types into a set. When you view the purpose of types as preventing bugs, that seems like a giant missing feature.

coldtea 6y ago

>The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.

lkramer 6y ago
Sorry, when I said new data structures, I meant containers like maps and list, which I very rarely get to create day to day. I can see it for your transformations, but I have seldom seen cases where generics would really help (usually we're talking about comparing complex structure types that will need custom code anyway).
- esarbe 6y ago
  How about sets?
- Smaug123 6y ago
  "Theorems for free"! By which I mean, when I'm coding something and it could be universally quantified on the type, then it's better to do so. That way, it's impossible to phrase certain errors. For example, a function `Set<a> -> Set<a>` must produce a subset of the input set; that's guaranteed by the types. I can't accidentally include the value 0 in my set, because 0 isn't of that generic type. The generic forces you to think in terms of the structure you're manipulating, rather than in terms of its contents.

Someone 6y ago

“Can you give a real world example that couldn't be solved with interfaces?” Of course not. Go is Turing complete, and generics do not make it Turing-completer (whatever that may mean) The question isn’t about what can or cannot be done, but about expressiveness, ease of understanding for humans versus language size (even if you have plenty of disk and RAM, That correlates with buggyness of the compiler) and compilation speed.

deleted 6y ago

[deleted]

arp242 6y ago

> Can you give a real world example that couldn't be solved with interfaces? There are none, you can always work around them, with the only downside is that you'll move some potential compile-time errors to runtime errors. But that's the wrong conversation to be having; we could also say "why do we need floats? Everything can be solved with ints too", which is true, but also a lot of work and a poor trade-off. Similar arguments exist for many language features. So it's a question of trade-offs: how much time will this save people? Will it reduce faults? And what are the costs of adding this? And how do they balance?