Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good Design is Imperfect Design, Part 1: Honest Names

domainlanguage.com

Post reply on HN
Print view View original

41–50 of 133 posts

Re: Good Design is Imperfect Design, Part 1: Honest Names

#41

Post by derjdoj »

majormajor wrote: post #23
derjdoj wrote: post #9

Please don’t have a method named plusIshRoundCeiling() in a library that “might” be used for years in lots of projects :) The plus() one is almost there and you can easily explain the ugly bits in javadocs (with lots of warnings around it so that it sticks out and is addressed hopefully in some next convenient cycle)

> (with lots of warnings around it so that it sticks out and is addressed hopefully in some next convenient cycle) How do you expect to address it when there isn't a single obvious "right" that everyone will have the same intuition on?

For instance, as in the article, provide the examples so that the users have more heads-up as in what is actually happening.

Long term, you might deprecate it and solve the problem with more intuitive abstraction.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#42

Post by ithkuil »

The problem is not the "plus" operator but instead lies in the "month" duration.

Not all months last the same number of days, and while we are at it not all days have 24 hours!

I'd rather move the explicit (and complicated) choice of what kind of month are you talking about (and thus also the relevant discussion about naming) into the operator that constructs a time interval.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#43

Post by ericevans »

cactus2093 wrote: post #33
stickfigure wrote: post #26

Strong disagree - 'plus' is quite a good name for Joda Instant, and his alternatives are atrocious. Certain problem domains require baseline familiarity with the subject. Far more people can recite the old "30 days has September, April, June, and November" rhyme than can explain what the words commutative and associative mean. Date math may annoy pure mathematicians but normal humans are used to working with calendar…

Exactly right. Although I think your comment here rather underestimates mathematicians :) Regular people are the ones who are only used to thinking in real numbers or integers. While some may be familiar in a practical way with how dates and times work, they would probably struggle to rigorously define the algebra of time math where associativity and commutativity don't hold. Mathematicians will be familiar with area…

It is interesting that many of the comments have suggested that JodaTime does what a "normal person" would expect in most of these odd cases, whereas you are pointing out that advanced mathematical concepts can define an algebra where associativity doesn't apply. Almost opposite points! But well taken.

One thing though: I think I was clear that I like Joda Time. It does handle these things better than most libraries. That is what makes it interesting to discuss. I could write a fun article picking apart some awful library, such as the old Java default library, but what would be the point.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#44

Post by ericevans »

derjdoj wrote: post #9

Please don’t have a method named plusIshRoundCeiling() in a library that “might” be used for years in lots of projects :) The plus() one is almost there and you can easily explain the ugly bits in javadocs (with lots of warnings around it so that it sticks out and is addressed hopefully in some next convenient cycle)

I was trying to be funny here! There is lots of room between "plus", which I think is misleading, and the kitchen sink name you quote. Although it depends on how serious the problems were, in this case I'd pick something shorter that still suggested rough edges.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#45

Post by slaymaker1907 »

I disagree with the author on this one. While it isn't a perfect analogue to mathematical addition, neither is floating point math. The bigger issue is that calendar math is tricky and durations cannot always be converted between one another.

The correct solution in my opinion would be to have distinct types for this sort of thing to help clear up the ambiguity. Date and time are really tricky concepts to model though and it is a difficult balance between honesty/precision and intuitiveness for such APIs. One such clunkiness I've seen with KeepassXC is that it stores password expirations exclusively as timestamps. This is actually not correct for the common use case of passwords expiring on a particular day (since you don't know the time) because what if you are in a different timezone? This I think shows that you can't just convert dates into datetimes without problems.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#46

Post by ericevans »

badJack wrote: post #35
SamBorick wrote: post #25

Earlier quoted context omitted.

I think this is exactly the opposite of the takeaway. If the underlying concept isn't simple, don't pretend it's simple with a simple name.

to go a step further, anyone using time variables based on calendar periods should know better than to think the relative time of +1 month would be simple. I'm not sure it's the fault of using a simple name in this case. I'm sure there could have been a lot better options to drive that point home, but the author picked one that I'm sure everyone has an opinion about. That seems like an effective way to get people tal…

What would be a better example to make the point, do you think? I always use the best example I can think of. Obviously there must be better ones.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#47

Post by mjevans »

qwertox wrote: post #29

Date arithmetic seem to be a complicated matter. Around 2.5 years ago I sent the following feedback to the Wolfram|Alpha Feedback Team, never heard back from them. Message: When I compute "2019-01-31 to 2016-04-04" I get "2 years 9 months 26 days" and when I compute the reversed input "2016-04-04 to 2019-01-31" I get "2 years 9 months 27 days" But when I compute "2019-01-31 to 2015-10-21" I get "3 years 3 months 10 d…

Inverting the date range probably confused the logic involved in accounting for leap dates. Possibly it fails to account for swapping the order of the dates to achieve an always positive result?

Re: Good Design is Imperfect Design, Part 1: Honest Names

#48

Post by mcphage »

tmp538394722 wrote: post #19
mjevans wrote: post #15

Earlier quoted context omitted.

You seem to be stuck on: 'what is the value of 1 month' and thinking in terms of days, because that appears to be the precision of the left value. Programmers exist in a world where things such as leap seconds matter. Normally if you have a timestamp that is just before a leap second, then add exactly a day's worth of seconds, you'd slide back a little in time. This might matter in another context, such as defining t…

You’ve ignored your critique and answered only the more obvious anecdotes. So I’ll repeat: What’s Feb 28th + 1 month? Does the human expect the last day of March? Or the 28th day of March? The API doesn’t make that clear - I think you could reasonably argue for either.

I think that's the easier case—most people would expect Feb 28th + 1 month = Mar 28th. The tricker one is Jan 31 + 1 month, because there is no Feb 31st. I don't think there is a "correct" answer to that.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#49

Post by slaymaker1907 »

ithkuil wrote: post #42

The problem is not the "plus" operator but instead lies in the "month" duration. Not all months last the same number of days, and while we are at it not all days have 24 hours! I'd rather move the explicit (and complicated) choice of what kind of month are you talking about (and thus also the relevant discussion about naming) into the operator that constructs a time interval.

That's not really always possible/practical. It's pretty common to say "in three months from now" in which case defining a month to be 31, 30, 29, or 28 days is not correct. The plain English meaning is to be on the same day of the month, but add 3 to the month value, probably rounding down if necessary. Therefore, 3 months from January 31st 2021 would be April 30th despite going through February which has 28 days.

Re: Good Design is Imperfect Design, Part 1: Honest Names

#50

Post by ericevans »

SamBorick wrote: post #25
lmarcos wrote: post #24

I was expecting the author to actually give a supposedly better name other than 'plus' at the end of the post. Bummer. Perhaps there is no better name and actually 'plus' is the perfect election?

I think this is exactly the opposite of the takeaway. If the underlying concept isn't simple, don't pretend it's simple with a simple name.

Yes, that was my point. Avoid overly simple names and also overly elegant names, unless you've actually found a simple, elegant concept.

I do have thoughts on better names. I'll write a follow up about that. But I didn't want to include it in this article because my most important point was that we need ways to curb our perfectionist tendencies, and not by hiding the rough spots. And if I had ended on that up note, it would have been the usual cheesy ending: Look! I'm so good that I always end up with a beautiful design. Which, as you say, was the opposite of the takeaway I wanted.

Post reply on HN