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

111–120 of 133 posts

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

#111

Post by chii »

slaymaker1907 wrote: post #49
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.

but this breaks down when the destination date is not within the calendar days of the month. For example, what is 3 months from Nov 30th? Should it be Feb 28th (or, if it's a leap year, should it have been 29th?), or should it be Mar 2nd?

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

#112

Post by dang »

cgrealy wrote: post #110
dheera wrote: post #57

Also ``` .plus(1 month) ``` The unknown behavior of 1-30 + 1 month is a red flag that maybe you shouldn't be using "month" as a unit of time because it isn't. Months suck. Bill for services every 10 days or every 25 days or every 50 days instead of every month.

Product: we need to support doing x on a monthly cycle Dev: Actually, months are a really inaccurate way of measuring time and we should convince all our clients not to use them. CEO: you're fired. Programming is the art of turning messy, real world, human problems into tools that work in the best way possible. If you abdicate that responsibility, quite frankly, what use are you?

Please don't argue in the flamewar style on HN. You can make your substantive points without that.

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

#113

Post by euske »

hcarvalhoalves wrote: post #90

The problem is not in the `plus` method, as it's working as expected when the unit is in days. It's the `month` unit that is misleading, since `1 month` looks like a constant value but really isn't, as the behaviour depends on the other operand, breaking associativity – or any expectation on how addition between two constants work really. It would be less confusing if the API removed `month` as a period, and as a pro…

This is just a hindsight, but I'd make two kinds of time period: "exact" period and "flexible" period. Define these as two different types, which can be converted to each other but only explicitly. Functions like plus() can take both types (via method overload) but the user must be aware that their behavior is different.

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

#114

Post by tshaddox »

deathanatos wrote: post #108
foobar1962 wrote: post #96

Earlier quoted context omitted.

I was going to post exactly this: the problem is "month" which is not a fixed value. "Year" also has the same problem due to leap years. I suppose that leap seconds could also pose problems too. I've recommended that clients specify time periods in days or weeks and avoid "months" entirely (ie, 90 days or 26 weeks, but not 3 months) or to specify an end date explicitly.

None of day†‡, hour‡, or minute‡ are fixed duration, either, depending on use cases & circumstance. An absolute delta type is good to have, but it's also useful to have a "relative delta" type (how my language calls it). Each has their use cases. † ±1–2h on DST enter/exits ‡ ±1s during leap seconds

And of course if day isn’t a fixed duration, then no intuitive definition of week would be a fixed duration either.

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

#115

Post by hamilyon2 »

Everyone in computing knows calendars and time are tricky concepts. In all honesty, there is no point to make API less terse: unaware will ignore it and use anyway. Educated will use it with thought, even if it is terse.

But general point holds: honesty in API is important

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

#117

Post by [deleted] »

zestyping wrote: post #54

I think it's possible to be both honest and readable. One way to look at the issue is that the confusion stems from giving the same name to operators of different types , namely the "Instant plus Period" operator and the "Period plus Period" operator. Period could be implemented as a vector with independent components for days, months, and so on. (I don't know if that's how JodaTime does it, but that's what I would d…

[deleted]

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

#118

Post by labawi »

ummonk wrote: post #100
zestyping wrote: post #54

I think it's possible to be both honest and readable. One way to look at the issue is that the confusion stems from giving the same name to operators of different types , namely the "Instant plus Period" operator and the "Period plus Period" operator. Period could be implemented as a vector with independent components for days, months, and so on. (I don't know if that's how JodaTime does it, but that's what I would d…

I’d argue it should be shiftBy rather than advanceBy to deal with negative periods, but yes. The issue here is the conflation of summing periods (commutative and associative) with shifting a date by a certain period. None of the proposed names in the post actually clarify anything - they merely make the behavior seem more confusing.

IMO, it should be advanceBy, if going backwards takes a negative interval. Shift by 10d isn't completely clear which on direction it would shift.

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

#119

Post by ithkuil »

Xophmeister wrote: post #82
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.

I came across this problem once before and came to the same conclusion. “A month” is an ill-defined unit, so I just don’t allow it to be representable in datetime arithmetic. You make the point that “1 day” would also fall under this category, but it’s less variable and so it being equal to “24 hours” is good enough.

One can argue that when something works most of the times until it breaks in some edge cases (twice a year) it's actually more dangerous since you're unlikely to encounter those issues until it hits all of your customers at once.

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

#120

Post by ithkuil »

ericevans wrote: post #66
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.

This is definitely the sort of idea that I like when exploring and trying to find a better model. The point I was trying to make in the article is that there are times when, however you try, you don't find a satisfying answer in the time you have.

Your point was good. But perhaps your unfortunate example is in turn a good example that if you can't find a good name for something perhaps there is a different way to look at things that produces a less contrived (but still explicit and honest) naming scheme.

Looking forward to read about your explorations on that front.

Post reply on HN