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

31–40 of 133 posts

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

#31

Post by underwater »

Kinrany wrote: post #4
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…

I found the argument about lack of associativity convincing: it's very counterintuitive that date + 1 month + 1 month is different from date + 2 months

The unit of 'month' is not fixed. It doesn't even have a value until it's applied to a date.

(It is almost like a quantum state. It can be between 28 and 31 days, depending on what it's being applied to. But as soon as it's applied to an absolute date the ambiguity disappears).

If you expand out the short hand 2000-02-02 + (1 month forward from February) + (1 month forward from March), then we can see associativing is nonsensical.

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

#32

Post by prpl »

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.

It should be the 28th and there should be a ceiling method.

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

#33

Post by cactus2093 »

stickfigure wrote: post #26

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

Exactly right.

Although I think your comment here rather underestimates mathematicians :) Regular people are the ones who are only used to thinking in real numbers or integers. While some may be familiar in a practical way with how dates and times work, they would probably struggle to rigorously define the algebra of time math where associativity and commutativity don't hold. Mathematicians will be familiar with areas like abstract algebra and group theory and very capable of understanding the concept that date math is not normal integer arithmetic.

Either way though, I agree the plus operator works great here given the inherent weirdness of how we have structured human time, and everything the author is proposing is worse. Joda handles the trickiness of dealing with time far better and in a much less error-prone way than any other library I've seen.

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

#34

Post by Strs2FillMyDrms »

I completely agree with this. And reminds me of how Oracle brushed all complexity from the word "filter" and simply went and named the function as is. A Filter implies a flow direction, it also implies two segments, the desired and the unwanted portion of the filtering operation. Which one is the one staying? which is the one that passes through?

I've seen people argue that one side should be called "sieved" while others say it should be named "selected"... to add to this , let's add even more complexity, since "selected" implies agency.. while filter performs a passive _selection_, in which case it should not be considered a selection at all.

It seems easy, but in reality some concepts (If not all) are inherently messy, specially on the English language since it seems the most abstract of all languages.

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

#35

Post by badJack »

SamBorick wrote: post #25
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.

to go a step further, anyone using time variables based on calendar periods should know better than to think the relative time of +1 month would be simple. I'm not sure it's the fault of using a simple name in this case.

I'm sure there could have been a lot better options to drive that point home, but the author picked one that I'm sure everyone has an opinion about. That seems like an effective way to get people talking about it, but it could be divisive in bad ways.

I'm a little put off by the other saying "a clean name shuts down our thinking", so maybe I'm just responding in disgust.

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

#36

Post by underwater »

I think a lot of people here are getting hung up on the associativity, or that the name is not fully descriptive.

But remember that this functionality exist ms is a library for operating on dates. It is clear to the user that values like "2 days" or "1 month" are intermediate values that cannot or should not be used as output. They need to be applied to an absolute date to become resolved and be useful.

The context, and real world experience with dates, makes this distinction obvious.

Side note: I created a similar library in the past. I struggled more with deciding if the clipping behaviour was even desirable than worrying about the naming, but that was merely due to the API I used. My function signature was `addMonths(v, 2)`, which eliminated ambiguity.

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

#38

Post by CptMauli »

FooBarWidget wrote: post #3
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…

What is 2021-02-28 + 1 month? Is that 2021-03-28 or 2021-03-31? It is far from obvious what a normal human would do most of the time here. The lack of associativity is still a problem. If 2021-02-28 + 1 month = 2021-03-28,then (2021-02-28 + 1 month) + 1 month = 2021-03-28 + 1 month = 2021-04-28. While if I ask what is 2021-02-28 + 2 months (given 2021-02-28 + 1 month = 2021-03-31), most people would say 2021-04-30. W…

I still think plus is fine in this case. And really, my expectation is, that anybody who thinks about adding a months, knows about their own intention. Because I suspect just adding the month is not what most people are actually doing, I guess in 90% of the cases most developers will add another step, rounding to the last (or first) day, or to the next same weekday, whatever.

The one thing nobody wants, is to add a month and land in the month one over.

So even if the semantic differs between libraries for adding a month, it actually doesn't mather that much. Because for all the other cases one could imagine, most people will add days or weeks, if staying on the same day matters.

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

#39

Post by derjdoj »

progman32 wrote: post #14
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)

Can you explain why you see this name as unacceptable?

I did’n quite intended to sound as if I think it would be unacceptable but the method name sounded too comical to me to be honest. Almost as if the intention is to say this method is a bit of a joke don’t use it please.

Maybe move() might work better here or moveToCalendarNearest() or something to flag up that in certain cases you need to be extra careful as mentioned in the article.

It is really hard to get this right and personally I would be flagging it up in javadocs.

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

#40

Post by mjevans »

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.

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 normal human has several options, and truncating to stay within the month makes the most sense to the most people most of the time. It's perfectly reasonable to take that step when resolving the indicated date to a representable value.

I'll go further: JodaTime probably isn't focused on Precision Date Calculations; it behaves very much the way I expect someone working with forms and fields, general CRUD enterprisy software stuff, would want auto-filled dates to work.

Post reply on HN