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

61–70 of 133 posts

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

#61

Post by dheera »

squeaky-clean wrote: post #59
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.

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 discounted "reversed instances" and "spot instances" for real estate.

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

#62

Post by qwertox »

mjevans wrote: post #47
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?

It's not (only?) related to leap years. It appears to be related to the month of April and some other weird stuff.

    -- leap year 2012:
    2019-01-31 to 2012-01-30 --> 7 years 1 day
    2012-01-30 to 2019-01-31 --> 7 years 1 day

    2019-01-31 to 2012-02-29 --> 6 years 11 months          6 years 11 months 3 days   6 years 10 months 30 days (2012-02-30 does not exist)
    2012-02-30 to 2019-01-31 --> 6 years 10 months 30 days (2012-02-30 does not exist)

    2019-01-31 to 2012-03-30 --> 6 years 10 months 1 day
    2012-03-30 to 2019-01-31 --> 6 years 10 months 1 day

    2019-01-31 to 2012-04-30 --> 6 years 9 months           6 years 9 months 1 day

    2019-01-31 to 2012-05-01 --> 6 years 8 months 30 days
    2012-05-01 to 2019-01-31 --> 6 years 8 months 30 days

    -- non-leap year 2013:
    2019-01-31 to 2013-04-30 --> 5 years 9 months           5 years 9 months 1 day
I stumbled upon it while testing some JavaScript time and date frameworks and wanted to use Wolfram|Alpha because I was somewhat confused with the correct interval between two dates.

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

#63

Post by rahimnathwani »

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.

What is your definition of 'unit of time'? Neither 'month' nor 'day' have fixed durations (the latter due to leap seconds). So why should we consider 'day' a unit of time but not 'month'?

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

#64

Post by Negitivefrags »

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…

In New Zealand we pay rent every 2 weeks instead of monthly and I’ve seen someone from the US come here and make the opposite argument.

“They are scamming you because you have to pay an extra months rent every year”

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

#65

Post by squeaky-clean »

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…

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 monthly amount. I'm sure my landlord wouldn't complain if I paid all 12 months up front. That's the only truly "fair" way.

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

#66

Post by ericevans »

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.

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

#67

Post by kaishiro »

mjevans wrote: post #40
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 did cover that: """ None of the examples in the article use a more vague syntax, such as "0 days before the end of the month". """ As another reply points out, it's incrementing the Month set of buckets. I'll also extend with other results I expect: 2020-12-31 .plus(1 months) => 2021-01-31 2020-12-31 .plus(2 months) => 2021-02-28 2020-12-31 .plus(3 months) => 2021-03-31 2020-12-31 .plus(4 months) => 2021-04-30 A no…

Maybe I'm just being thick (it's usually the case), but for the life of me I still don't know what your answer to the parent's question is, and I can't tell how your quoted part is supposed to answer it.

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

#68

Post by ericevans »

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 ways to deal with the flaws. I decided that if I had ended with this it would have communicated: Aw, just keep trying and you'll get something nice! That can be very risky.

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

#70

Post by teknopaul »

Etheryte wrote: post #5

Being honest with naming things is also a great roundabout way to ensure you write maintainable, readable code. If the name is honest and it feels awkward, it's a good red flag that there might be a problem with the approach you're taking. I think code golf languages (a-la [0]) are a good example of this approach as well, when your language is as terse as possible, giving very deep consideration to what the language…

I think I missed something here, does this article really suggest that plusExcuseExcuse() would be better? The domain is dates, we all know months have different numbers of days so _something_ must be done and this is explicit from the domain.

Changing PI to PI_ISH because numbers in a language is limited does make code more readable.

Almost everything in a computer is an imperfect model.

i++

is not improved as

incrementUnlessItOverflows(i)

You are not going to change how increment works so avoid making it awkward.

You cant change the fact that number of days in a month varies.

I find this as annoying as "mistakes programmers make about time" articles. The reality is programmers understand that all time in all computers is just a model to be played with.

Recently I saw the people are fretting because there may _have to be_ a negative leap second. Leap seconds are a man-made concept. You don't _have to_ have a negative leap second, you just have to accept the earth's spin is not constant, utc is a model, the model is not worse if its out by >1, it was never perfect, it exists to be convenient. utc ignores being out by >1 millisecond, why is there a problem if the denomination is a 1000ms?

The world keeps turning and the model is simpler if _all_ leap seconds were ignored, it will take a while until midday over Greenwich is affected and it will not matter when it is. It was an arbitry location in the first place.

It seems to me JodaTime is correct, if you want to add 30 days plus(30 days), if you want to accept that the month model is imperfect plus(1 month) and see what you get.

++ is concise and precise, the domain is a programming language.

Post reply on HN