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

91–100 of 133 posts

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

#91

Post by [deleted] »

dheera wrote: post #61
squeaky-clean wrote: post #59

Earlier quoted context omitted.

But sometimes you need to bill at a certain point in the month. I don't pay my rent every X days, I pay it on the first of the month. The best solution for that may be something like establishing it as a frequency rather than accumulative addition. But that won't work in every situation. Dates are complex and require lots of thinking to do correctly in some circumstances.

> I don't pay my rent every X days, I pay it on the first of the month. I don't want to pay rent that way. It's a good way to get scammed because they're charging you a higher per-day rate in February than January. I'd much rather pay rent per day, if possible. If Amazon can take over my property manager I'm sure it'll be possible to bill it with the same flawless consistency of AWS billing, and have a concept of dis…

[deleted]

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

#92

Post by dheera »

mwcampbell wrote: post #83
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.

> Bill for services every 10 days or every 25 days or every 50 days instead of every month. Isn't that just prioritizing one's laziness as a developer over what makes sense to the user? My guess is most users would rather see the bill come out on the same day every month.

> most users

As a user, I would not. I hate months. They're inconsistent. I hate them.

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

#93

Post by contravariant »

If you want to be real nitpicky you shouldn't be using '+' for non-commutative operations either. Ideally you'd also have some kind of distributive law, but if needs be any commutative operation will naturally result in a module over the integers, which I suppose works well enough.

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

#94

Post by mcphage »

FabHK wrote: post #75
mcphage wrote: post #48

Earlier quoted context omitted.

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.

If I pay you Jan 31, Feb 28, March 31, April 30, etc., don't I pay you monthly? Shouldn't I be able to express this as a repeated addition of a month? At any rate, these problems have been solved in finance, with proper date and schedule libraries.

> Shouldn't I be able to express this as a repeated addition of a month?

I don’t think so, no—more likely, it should be Pattern(Month)… like how would you express “second Tuesday” as a series of additions?

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

#95

Post by myrryr »

mwcampbell wrote: post #83
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.

> Bill for services every 10 days or every 25 days or every 50 days instead of every month. Isn't that just prioritizing one's laziness as a developer over what makes sense to the user? My guess is most users would rather see the bill come out on the same day every month.

I want my bills to be nice and predictable. 2 week billing means my bill is the same amount. It means it is in sync with everything else here as well (new Zealand).

I can set up an ap, and it is done. No tweaking needed.

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

#96

Post by foobar1962 »

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…

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.

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

#97

Post by mtwittman »

slaymaker1907 wrote: post #45

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 thoug…

I use the expiration date in KeepassXC and here's my thought on it in particular: I want the KP date-time field to err on the side of simplicity (implementation and interface).

Seems to me best practice of renewing accounts is to always apply padding (TODO: renew Foo today because it expires in roughly n days); if you make as a minimum n >= 2 (or how about >=3 as a safety factor) then you don't have to consider how the account provider administers their cut-off (expires at 00:00 vs 23:59, is timezone a factor?, etc).

With this approach the difference between 'instantaneous time' and 'calendar time' are, for practical purposes, a moot point.

So the date I enter into the KeepassXC field has the padding included. The expiry date as described by the provider I can put in the note field for additional reference.

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

#98

Post by makeitdouble »

I like the point on accepting awkward names a lot.

It comes close to the “system should be a complex as they need to” (some quote I am completely butchering) idea. There’s a point where trying to hide messiness isn’t helpful.

As a side point to the “plus” argument, I think having a name that covers 99% of the use cases but will fail unpredictively on edge cases should be fine for something that is central to the library.

People for whom exact behavior matters will have looked at the doc or tried these use cases by themselves, or there will be enough blog posts like this one to motivate them into checking what their lib does beforehand. Well, anyone working with times and dates will have learned to not trust clean abstractions at this point.

For people who are just writing convenience applications and want a lib that make them feel they can use it without hassle, “plus” is a very good, memorable and easy to use name.

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

#99

Post by ummonk »

The behavior is exactly what I would expect it to do. Arguably I’d use “plus” for adding timespans together (which should be commutative and associative) and “shift” for shifting a date by a timespan, but I don’t think the behavior here needs much elaborating as long as the method is accurately documented

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

#100

Post by ummonk »

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.

Post reply on HN