I’d argue that the reason this is so bad in other languages is because of horrible default implementations.
Look at tostring in java, getting a somewhat printable object would be easy if the default implementation would use reflection or sth to print the object, but instead it prints hash gibberish no one cares about.
I always hated the implementation for .toString() of Duration. It gives you a string like that: PT8H6M12.345S (not a hash)
Apparently, it’s an ISO 8601 thing, but what the hell am I supposed to do with that?
It’s not useful for outputting to end users (which is fair enough), but I don’t even want to write that into a log message.
I got so used to this just being garbage that I would automatically call .toMillis() and write “ms” after it.
Well, and not to gush about Rust too much, but I recently learned that its debug string representation is actually really good. As in, it’s better than my Java workaround, because it’ll even do things like printing 1000ms as 1s.
And that’s just like, oh right, libraries can actually provide a better implementation than what I’ll slap down offhandedly.
Well, because I’m of a very different opinion about its readability. If you know the format, then sure, you can mostly read it as expected. But our logs are often something that customers or sysadmins will want to read. If it says Retrying in PT5S... in there, they’ll think that’s a bug, rather than a duration.
And yeah, I almost figured it was for de-/serialization. I guess, that’s something where I disagree with the designers of Java.
In my opinion, you don’t ever want to rely on the implicit behavior of the language for your serialization needs, but rather want to explicitly write down how you’re serializing. You want to make a conscious decision and document that it’s the ISO 8601 format, so that if you need to hook up another language, you have a chance to use the same format. Or, if you need to change the format, so that you can change the one serialization function, rather than having to find all the places where a .toString() happens.
Admittedly, the Java devs were between a rock and a hard place, due to them having to implement .toString() and the meaning of .toString() being kind of undefined, i.e. it’s never stated whether this is a format for serialization, for debugging or for displaying to the user. And then I guess, because it didn’t explicitly say “for debugging” on there, they felt it was important to go with a standard format.
I’d argue that the reason this is so bad in other languages is because of horrible default implementations. Look at tostring in java, getting a somewhat printable object would be easy if the default implementation would use reflection or sth to print the object, but instead it prints hash gibberish no one cares about.
I always hated the implementation for
.toString()ofDuration. It gives you a string like that:PT8H6M12.345S(not a hash)Apparently, it’s an ISO 8601 thing, but what the hell am I supposed to do with that?
It’s not useful for outputting to end users (which is fair enough), but I don’t even want to write that into a log message.
I got so used to this just being garbage that I would automatically call
.toMillis()and write “ms” after it.Well, and not to gush about Rust too much, but I recently learned that its debug string representation is actually really good. As in, it’s better than my Java workaround, because it’ll even do things like printing 1000ms as 1s.
And that’s just like, oh right, libraries can actually provide a better implementation than what I’ll slap down offhandedly.
Why not? It’s a perfectly human readable representation of that duration, just as intended by ISO.
Just as an example, we use that format to communicate durations between the frontend and backend.
Well, because I’m of a very different opinion about its readability. If you know the format, then sure, you can mostly read it as expected. But our logs are often something that customers or sysadmins will want to read. If it says
Retrying in PT5S...in there, they’ll think that’s a bug, rather than a duration.And yeah, I almost figured it was for de-/serialization. I guess, that’s something where I disagree with the designers of Java.
In my opinion, you don’t ever want to rely on the implicit behavior of the language for your serialization needs, but rather want to explicitly write down how you’re serializing. You want to make a conscious decision and document that it’s the ISO 8601 format, so that if you need to hook up another language, you have a chance to use the same format. Or, if you need to change the format, so that you can change the one serialization function, rather than having to find all the places where a
.toString()happens.Admittedly, the Java devs were between a rock and a hard place, due to them having to implement
.toString()and the meaning of.toString()being kind of undefined, i.e. it’s never stated whether this is a format for serialization, for debugging or for displaying to the user. And then I guess, because it didn’t explicitly say “for debugging” on there, they felt it was important to go with a standard format.