Hacker News Reader

Comment by martingxx | Hacker News Reader

The `fmt` packages is described as being for "formatted i/o". It seems that ordered maps, while not "i/o" is reasonable to describe as "formatting", so it's fine to do it in this package I think.

`fmt` has always made things look prettier, that's part of what formatting is about.

You could equally argue that `fmt` should not round floats or pad numbers with zeros or spaces.

View on HN

Formatting and making things prettier is not manipulation. When I call a function called "fmt.Println" is expect it to print, not sort.

As far as I can tell, it’s not manipulating, it’s formatting in sorted order.

Sorting is manipulating...

You can print in sorted order without modifying the map at all. I don’t know what definition of “manipulating” you’re using, but I struggle to imagine a definition that is both useful and consistent with your position.

The data itself is not being "manipulated", though. By definition it is unordered. You are not guaranteed that whatever order you get when iterating the keys will remain the same. But any string rendering of the map would put the keys in an "order" and thus would be "manipulating" the data according to you. Why not have the order be useful to humans?

I'm very surprised by those vitriolic comments...

Really I have never seen print change the order of the data it is given (that's manipulating, indeed) for the sake of what seems to be laziness.

If there is a real need for sorted iteration then it should be external to print, possibly a new API of maps.

How are you reading "vitriol" from these comments? "Print" isn't changing the order of the data it's given--the data is unordered by definition. It has to print it in an order, so it orders it by keys as a practical courtesy to humans. Nothing is manipulated except perhaps data structures internal to the print operation.

> "Print" isn't changing the order of the data it's given

Eh? That's exactly the functionality they are announcing...

You're missing the point entirely. Maps have no defined order. You cannot "change" the order of a map, because it has no order. `[foo:1 bar:2]` is the same map as `[bar:2 foo:1]`, there is no difference.

For printing purposes that means that it doesn't matter which order you print something out in. ANY order is equally correct. So you might as well choose the one that makes the most sense to human eyes, which is to print them out ordered alphabetically on the keys.

Just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything. Literally nothing about the map changes.

> You're missing the point entirely. Maps have no defined order. You cannot "change" the order of a map, because it has no order.

Clearly, I am not the one missing the point...

The order maps iterate is not the point. The point is that e.g. a 'print' function should print, not sort and change the order.

> just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything

Again, the printing function does not 'choose', it manipulates the date returned by sorting them.

My point is that, to follow good design principle, this sorted iteration should be a public API of maps.

Is rounding of a float manipulation?

Reply on news.ycombinator.com