3 ms·

> First, programming languages should make it simple to create types where equality comparison is disabled because it makes no sense This is kind of a silly "s

by dvt 7y ago

> First, programming languages should make it simple to create types where equality comparison is disabled because it makes no sense This is kind of a silly "solution" as some languages don't even have types, others have "soft" types, and others support arbitrary typecasting. (Not even going to get into duck typing, union types, etc. Type theory is hard.) > Programming languages must make the difference between structural equality and reference equality crystal clear This is probably intractable. Author doesn't even touch cases where you have objects that contain other objects. Are these references or values? How does the equality operator work there? How deep does the rabbit hole go? If you only deal with values, then you're probably crippling performance. There are reasons for these design concessions, it's unfair to assume that people that designed these languages are complete doofuses. > One might look at the length of this post and say, “Wow, equality is really complicated! I’m going to give up coding and become a soybean farmer.” Farming is magnitudes harder than what the average programmer does day-to-day :)

rossdavidh 7y ago
In fairness, he did also say that being a soybean farmer was harder.
lmm 7y ago
> This is kind of a silly "solution" as some languages don't even have types, others have "soft" types, and others support arbitrary typecasting. Well, more fool those languages. It's a good solution, and if your language can't offer an equivalent, take it up with your language's maintainers. > This is probably intractable. Author doesn't even touch cases where you have objects that contain other objects. Are these references or values? Let's not declare it intractable before we've actually tried. The language would need to draw a clear distinction between (possibly compound) values and objects-with-identity - like the distinction between struct and class in C#, or between case class and class in Scala - and ripple that distinction all the way up; values should only be allowed to contain other values, should be immutable, and should be able to be treated in a generic way (i.e. a record system). Objects-with-identity should be rarer and heavily encapsulated, almost like Erlang actors; the simplest example is a reference cell (i.e. a mutable thing holding a value of a particular type that can be get and set). Doesn't sound like such a bad language design.
- dvt 7y ago
  I'd have to think about this more, but I think your purported solution (mostly immutable record-type objects) would tax performance and memory constraints.
  - lmm 7y ago
    Haskell already works that way, and is a high-performance language. (The same is true of strict ML-family languages, so laziness is not required to make this practical). Those languages generally just don't bother with reference comparisons at all, but one could imagine a more hybrid language that included support for traditional OO - in fact idiomatic Scala works like this (and again is a high-performance language, though to some extent that relies on what's probably the best garbage collector in the world). I don't know what kind of support Erlang has for making comparisons between actor identities, but that might be an even better example.
naasking 7y ago
> This is probably intractable You might be thinking too ambitiously. Having separate operators for identity vs. structural equality checks would suffice.

by dvt 7y ago

rossdavidh 7y ago

In fairness, he did also say that being a soybean farmer was harder.

lmm 7y ago

> This is kind of a silly "solution" as some languages don't even have types, others have "soft" types, and others support arbitrary typecasting. Well, more fool those languages. It's a good solution, and if your language can't offer an equivalent, take it up with your language's maintainers. > This is probably intractable. Author doesn't even touch cases where you have objects that contain other objects. Are these references or values? Let's not declare it intractable before we've actually tried. The language would need to draw a clear distinction between (possibly compound) values and objects-with-identity - like the distinction between struct and class in C#, or between case class and class in Scala - and ripple that distinction all the way up; values should only be allowed to contain other values, should be immutable, and should be able to be treated in a generic way (i.e. a record system). Objects-with-identity should be rarer and heavily encapsulated, almost like Erlang actors; the simplest example is a reference cell (i.e. a mutable thing holding a value of a particular type that can be get and set). Doesn't sound like such a bad language design.

dvt 7y ago
I'd have to think about this more, but I think your purported solution (mostly immutable record-type objects) would tax performance and memory constraints.
- lmm 7y ago
  Haskell already works that way, and is a high-performance language. (The same is true of strict ML-family languages, so laziness is not required to make this practical). Those languages generally just don't bother with reference comparisons at all, but one could imagine a more hybrid language that included support for traditional OO - in fact idiomatic Scala works like this (and again is a high-performance language, though to some extent that relies on what's probably the best garbage collector in the world). I don't know what kind of support Erlang has for making comparisons between actor identities, but that might be an even better example.

naasking 7y ago

> This is probably intractable You might be thinking too ambitiously. Having separate operators for identity vs. structural equality checks would suffice.