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

21–30 of 133 posts

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

#21

Post by brianpan »

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.

The article is about naming the method. The fact that dates are messy means a clean API is difficult/impossible.

I think plus() is a name that is good enough. I can't think of a better name that will help the user understand what will happen in the 2/28 + 1 month case. That's asking too much of a method name. That's what docs are for.

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

#22

Post by opheliate »

brianpan wrote: post #21
tmp538394722 wrote: post #19

Earlier quoted context omitted.

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.

The article is about naming the method. The fact that dates are messy means a clean API is difficult/impossible. I think plus() is a name that is good enough. I can't think of a better name that will help the user understand what will happen in the 2/28 + 1 month case. That's asking too much of a method name. That's what docs are for.

Perhaps .dateAfter(1 month) would be more appropriate? I sympathise with the author in finding the violation of associativity of “plus” a bit jarring.

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

#23

Post by majormajor »

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?

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

#25

Post by SamBorick »

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.

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

#26

Post by stickfigure »

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 calendars.

In the problem domain of dates, 'plus' is analogous to (but not exactly) its mathematical counterpart, and Joda's month math is almost always exactly what you want. Furthermore, plusIshRoundCeiling doesn't really explain anything; ceiling of what? The OP suggests that the cognitive dissonance is beneficial to the user. In which case it might as well be plusAsterisk or plusDontForgetToReadTheDocumentation.

The problem with plusGoReadTheDocs et al is that all problem domains have little edge cases like this. Excepting pure math, every single plus method is going to have notes. It'll be worse than those useless Prop 65 warnings in California.

Joda did this one right. Date math is simply not associative or commutative. Thankfully, most people are familiar with calendars and have some intuitive sense of this already. Littering the API with special hints doesn't help.

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

#27

Post by jimminy »

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.

If you're adding 1 month, you're working on the month's location, e.g. 2021 - (02) - 28.

When you increment the month, the result would be 2021-03-28.

The only time you'd modify the day, is if the day became invalid due to an overflow, during that increment. If, when, you overflow the days you'd set the value of days to the maximum in that month.

If I tell someone, I'll get to that in a month, they expect by this day in the next month, the next calendar page, not 30/31 days.

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

#29

Post by qwertox »

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 days"
    and when I compute the reversed input
    "2015-10-21 to 2019-01-31" I get "3 years 3 months 10 days"
    
    Shouldn't the very first one ( "2019-01-31 to 2016-04-04" ) also return "2 years 9 months 27 days"?

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

#30

Post by _dwt »

Without quibbling about the particular (adding a month) example, I can vouch that this is a great way to help the people for whom the software is being built refine their thinking. I help clients often with inherited/legacy/hacked-together code, often written by non-expert programmers for "odd" platforms (think: Excel VBA macros, which use the spreadsheet itself as the sole data structure). Identifying the awkward implicit concepts in this code, and giving them corresponding awkward names, can help the client recognize places where their tool doesn't map onto their domain knowledge the way they thought it did. As a recent example: "run of same-named tasks when ordered by date, then name" isn't exactly the same concept as "block of time dedicated to a specific task"!
Post reply on HN