Hacker News new | past | comments | ask | show | jobs | submit login
Design duality and the expression problem (2018) (tedinski.com)
14 points by tosh 28 days ago | hide | past | favorite | 8 comments



> In a closed world, these [polar and cartesian] are identical representations.

They are not identical! To even think for a moment that they are identical, you must have something like floating point numbers in mind to back x, y, r, theta. An IEEE float can take on the value "inf". The polar representation allows you to represent "a point at infinity in a specific direction", whereas the Cartesian representation allows you to represent "a point at infinity in an axis-aligned direction" and "a set of points at infinity in a set of directions within a quadrant".

You can argue they are identical for points not at infinity. But even then, they are not identical. The polar representation has redundancies (1. negate the radius and flip the angle. 2. add one turn to the angle).

These are the kinds of things that might make you prefer one representation over another, in addition to performance characteristics of certain operations on the points.

If you like thinking about these subtle differences, you can drop down to one dimension and consider two representations for intervals: 1. a lower and upper bound, 2. a center and a radius.


I am pretty sure that's not what the author meant. Given the subject matter it's quite obvious that they meant:

> In a closed world, these [two different ways, data vs. object, to represent two different instances of coordinates on which the same interface (in name and signature) is defined] are identical representations [of a data type bundled with a single method/function].

They are saying that the example in Java and the example in Haskell have the same expressive power. Both allow you to apply a distance function / method to a Coord type coord "thing", and depending on whether coord is a cartesian coordinate the cartesian coordinate based distance implementation is used and if it is a polar coordinate the polar coordinate implementation is used.

Now, it would have been good for the author to acknowledge your point as well so as to avoid this misunderstanding. After all in the example, there is an underlying aspect / layer of things that can be substituted. I just don't think the author intended to talk at all about the actual (non) equivalence of polar vs. cartesian coordinate representations here. They'd probably say (and I'd agree) it doesn't matter at all for what is discussed. You could add a disclaimer saying "these coordinate types are both not actually equivalent" and it would not actually affect the validity of the points made.

P.S. It's not even that the example is bad either. After all it's not uncommon in real codebases that two actual implementations of the same interface are producing subtly different results (e.g. calling into database engine A vs. B). Often these differences don't matter and the benefit of being able to exchange implementation / internal representation lies elsewhere (see DI).


A charitable reading is "identical up to isomorphism."


But they're not identical up to isomorphism. That's the point of my comment. You cannot round-trip (r = Inf, theta = .123) to a cartesian representation and back.


That rests on the assumption that the author is using a particular representation for the values, even though the author doesn't indicate anything about that.


Can you think of a representation where they would be isomorphic?


For the record, I wasn't trying to correct the author as much as I wanted to share an observation that I find interesting about this example.


The fact that comments like yours get downvoted is one of the things that most discourages me from participating in HN.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: