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

71–80 of 133 posts

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

#71

Post by matheusmoreira »

mjevans wrote: post #2

I disagree about "plus" in the JodaTime example. The month addition with corner cases did exactly what I expected because the whole library has been polished to "do what a normal human would do, most of the time". A normal human would not suspect Jan + 1 month, is any month other than Feb. However I suspect, not even reading the documentation, if it were fed 30 or 31 days, rather than '1 month', it would also do exac…

> A normal human would not suspect Jan + 1 month, is any month other than Feb.

Because humans intentionally reduce the precision of their computations to make them easier.

  Today = 2021-08-04

  Next year = 2022
  The exact month, day, hour are all unknown.

  Next month = 2021-09
  The exact day and hour are unknown.

  Tomorrow = 2021-08-05
  The hours and minutes are unknown.
If humans used the same level of precision as computers, they'd run into the same problems. Probable date of birth calculation is an example.

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

#72

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

#73

Post by stickfigure »

ericevans wrote: post #68
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…

Okay, I almost wish I hadn't read this comment because it is so similar to what I have in part 2! So please don't be annoyed when you see it in a couple of weeks ;-) I actually separated it into a separate part because it undermines my primary point. Sure, we all love it when we have a better decomposition, better names, and everything falls into place. But it doesn't always. Not in the time we have. So then we need…

The only thing advanceBy has going for it is that when the programmer inevitably tries to type add (after wondering why plus turns up nothing), the IDE _might_ show it in a dropdown.

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

#74

Post by dheera »

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

Earlier quoted context omitted.

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

Per-day still has errors when leap-seconds and daylight savings get involved. It's just a smaller error. And unless you can convince landlords nationwide to change how billing works, a company creating a monthly billing service is just going to find another developer that makes what they want. edit: Also this may not be typical in every lease, but all of my leases have established the rate as both a yearly and monthl…

They should give you a discount for committing to 12 months, and a further discount for paying 12 months upfront. AWS does.

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

#75

Post by FabHK »

mcphage wrote: post #48
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.

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.

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

#76

Post by jl6 »

For what it’s worth, SAS can add months to time points with the aid of an alignment parameter, so 01JAN2021 + 1 month would be 01FEB2021 with beginning alignment and 28FEB2021 with end alignment. There is also middle and sameday alignment.

This is the snappily named intnx function. I guess that’s an honest name in the sense that it is very suggestive of needing to read the documentation before using it.

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

#77

Post by bcrosby95 »

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.

Sure, programming would be infinitely easier if I could ignore reality and substitute it with my own.

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

#78

Post by sib »

ThinBold wrote: post #20

That (some date + 1 month) + 1 month ≠ some date + 2 months has always been true for floating numbers. This is exactly why you never trust fast matrix multiplications---they rely on cancelations of the form (a + b) - b = a + (b - b) = a. I would argue that 1 month is just having too few significant digits. You can even implement it as returning 30 with probability 60% and returning 31 with probability 40%. Then on av…

Sure, but I'd guess that neither developers nor "normal people" immediately think "floating point" when they think about a month.

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

#79

Post by depaya »

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.

You're setting the same trap as those viral math problems people share on Facebook:

6÷2(1+2) = ?

We could argue about what the _right_ answer is to that equation, but I call it a trap because it's intentionally confusing and devoid of any context (or the ability to ask a follow up question). There isn't really a situation where you would see that equation and not know the intended way to interpret it... just like your question.

There are a couple of ways that context _could_ be provided though:

I'm writing an automated task that should run once per month, I don't necessarily care what day of the month it runs though since it just cleans up some temp files. If today happens to be Feb 28th, and I say run today, then every month after, I would expect it to run Feb 28th, March 28th, April 28th...

I'm writing an 'end of month' task that needs to run at the end of every month for some bookkeeping reason. If today happens to be Feb 28th, and I say run today, then every month after, I would expect it to run Feb 28th, March 31th, April 30th...

In both of these situations I would program accordingly. Computers don't understand context, that's the job of the human programming it.

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

#80

Post by bottled_poe »

stickfigure wrote: post #73
ericevans wrote: post #68

Earlier quoted context omitted.

Okay, I almost wish I hadn't read this comment because it is so similar to what I have in part 2! So please don't be annoyed when you see it in a couple of weeks ;-) I actually separated it into a separate part because it undermines my primary point. Sure, we all love it when we have a better decomposition, better names, and everything falls into place. But it doesn't always. Not in the time we have. So then we need…

The only thing advanceBy has going for it is that when the programmer inevitably tries to type add (after wondering why plus turns up nothing), the IDE _might_ show it in a dropdown.

Ok, but that’s when you read the docs. Also, in many languages, those expected methods could be mocked out to raise compiler errors, redirecting the developer to the correct methods.
Post reply on HN