gigasecond:add clarity to the goal#1398
gigasecond:add clarity to the goal#1398kotp merged 2 commits intoexercism:masterfrom andy5995:patch-1
Conversation
kotp
left a comment
kotp
left a comment
There was a problem hiding this comment.
I would prefer to leave it ambiguous, given the history of the exercise here at Exercism. The tests almost drive a Date/Time solution, but I think that has so far been avoided. The Date is a dependency of the tests, rather than a driving factor of the exercise itself.
| @@ -1,3 +1,4 @@ | |||
| Calculate the moment when someone has lived for 10^9 seconds. | |||
| Given a `start` value, write a function that returns what the date will | |||
There was a problem hiding this comment.
I'm interested in the fact that this specifies the input, which was otherwise unclear.
If nothing else changes about this exercise, I would like to keep the input clarity change, at the very minimum.
If I must suggest a minimum change that only includes the above, it would be something like:
Given a starting time as input, determine the moment that is 10^9 seconds past that starting time.
There was a problem hiding this comment.
A "starting time" suggests that it must be a Time object, or at least can limit our imagination. I would like to encourage people to think a little more fundamentally about that. Giving a single second such as the Integer 1 or even a float of 1.0 should do the expected thing. Giving a Time object should also work.
However, the thoughts given are from the perspective of Ruby, at least. If nothing else, I suppose the Ruby track could modify the Readme to indicate this in some way.
I think that some ambiguity is good, happens in real life and helps to provoke discussion about choices as it doesn't limit, unduly, the choices.
There was a problem hiding this comment.
A "starting time" suggests that it must be a Time object, or at least can limit our imagination
Without regard to whether I personally agree with this statement or not, I observe the following to be true about this statement:
- I believe that we make our descriptions independent of any particular language, and thus it makes sense to use plain English.
- Regardless of what English sentence someone may suggest, a reader of that sentence might choose to interpret any noun as a possible object
- Had the suggestion been "Given a starting moment, determine...", a reader might imagine Moment should be a class.
- Had the suggestion been "Given a starting point, determine..." a reader might imagine PointInTime should be a class
- The English sentence deliberately makes no mention of any specific classes (and it should stay that way), but a person who wishes to port the exercise to a given track might choose to make such an interpretation in consultation with the maintainers of the track.
Next, I note whether I personally agree with the statement
A "starting time" suggests that it must be a Time object, or at least can limit our imagination
I personally don't agree. The sentence as written doesn't mandate about how a "starting time" is represented in code. If I have a desire to say that an integer represents a starting time, I will think that the sentence as written does not contradict my desire.
I think that some ambiguity is good, happens in real life and helps to provoke discussion about choices as it doesn't limit, unduly, the choices.
I agree. I am thinking the sentence as written meets the requested criterion of not being over-constraining about the choices.
Thus, my suggestion currently remains unchanged.
As a reminder, my suggestion is:
Given a starting time as input, determine the moment that is 10^9 seconds past that starting time.
There was a problem hiding this comment.
I think "moment" is plain English, as it depicts a small segment of time. The "Gigasecond" implying that the smallest moment is probably a second. It is defined as "a small (indetefinite) measure of time" and is a well known concept. A "starting point" is just a more specific indication of what kind of moment. And I don't believe it needs to be the start of something, it could be measuring from the end of something as well.
I would say, rather, that "Given a starting point" the object may be a StartingPoint class, as a direct translation, but I see your point.
Of course, I fully agree with your third bullet point.
In my statement about the starting time suggesting that it must be, I missed the word "maybe", as in "maybe suggests a Time object".
I don't think a suggestion is a mandate in any case, ever, so definitely the sentence as written doesn't mandate. But the suggestion may limit the initial thoughts when we see it. I think that making that decision can be influenced by what we see in the description. So I also agree with your response.
So I like your suggestion as it is, if we can use "moment" in place of "starting time". It clearly means the same thing (as implied by addition of a gigasecond) and lets the language communicate the meaning of the word, and the sentence.
There was a problem hiding this comment.
So I like your suggestion as it is, if we can use "moment" in place of "starting time". It clearly means the same thing (as implied by addition of a gigasecond) and lets the language communicate the meaning of the word, and the sentence.
OK, no objection here.
|
This was my perspective, as a new-comer.. Most exercises I've done were suggestions in the books I've read, with no accompanying test code. The goal is stated and I either decide to try it or not. In the case of something like the exercism project, I may only download the exercise if I decided to do the exercise. Trying to guess at what the goal was, at first I assumed "moment" was supposed to be a value in "years" after a person is born. Though I felt the stated goal was too vague, I downloaded the exercise anyway, and was able to figure out the goal by looking at the test code. I don't remember seeing anywhere that advised a user to look at the test code for hints (but I sometimes skim over things too much so maybe that's my bad). Someone new to programming, or having no experience with unit tests may not realize that he or she should look at the source code in the test directory. My perspective is that of an intermediate C developer who has been coding as a hobby (off and on) since 1992. I was working on the rust language gigasecond project. I have no experience with writing unit tests yet but it's nearing the top of my TODO list. |
|
I don't see anywhere in that specific exercise to look to the test code for hints, but there is the explanation that there are tests that are skipped, so you must go to the test file, or run the flag to skip the tests. I also notice that the Rust track does give more hints in their addendum to the Readme about |
|
When a final decision has been made, feel free to just modify the PR and merge. Thanks for reviewing everyone! |
|
How about: It has no mention of what specific thing to do, such as suggesting to calculate, divine, conjure, look up, or some other specific way to get to the answer. @andy5995 I suppose we would not be able to do that, without write access to your repository? |
| @@ -1,3 +1,4 @@ | |||
| Calculate the moment when someone has lived for 10^9 seconds. | |||
| Given a `start` value, write a function that returns what the date will | |||
There was a problem hiding this comment.
My suggestion, would be:
Given a moment, determine the moment that would be after a gigasecond (10^9 seconds) has passed.
@petertseng suggestion as converted with "no objection here" from him:
Given a moment as input, determine the moment that is 10^9 seconds past that moment.
@kotp I invited you as a collaborator. That may be sufficient in this case, if you were inclined to make the final change. Also because I submitted this PR through the web, maintainers should be able to edit by default. |
The parenthesis shortly define gigasecond, the following sentence spells it out explicitly in long form.
kotp
left a comment
kotp
left a comment
There was a problem hiding this comment.
Waiting on blessing for @PeterSeng
|
Would or I dropped parenthesis since next sentence defines gigasecond. |
|
See the commit message, regarding the parenthesis. But yeah, that works with or without.
I think "seconds" depicts time, and moment echoes time, so no reason to expand that word out to its definition. "Moment" is used in English very commonly. Give me a moment, wait one moment, one moment, please..., etc. We understand it, and given the context, it comes out as well. Given something I don't yet understand, add an amount of seconds to find out what that better understanding via context now is now. |
|
Sorry, I didn't see this, or I would have referenced it. The implementation takes time_t values of seconds since epoch as input and output, where
is the canonical solution. The tests are written as: given 2 inputs of the form <ints to represent: year, month, day, hours, mins, and seconds> that are known to be a gigasecond apart, check the users transform of the first matches the second, which in theory is a very different problem. One involving the nuances of daylight savings, the subject of the PR. I think part of the reason these got to be so different is the absence of indication of what format the 'moment (in time)' should be in (E.g.: that the problem involves using Gregorian calendar). Doing so might have helped in that case. |
| @@ -1,3 +1,4 @@ | |||
| Calculate the moment when someone has lived for 10^9 seconds. | |||
| Given a moment, determine the moment that would be after a gigasecond | |||
There was a problem hiding this comment.
I would have said as input, but if you look at all the other instances of "given" in this repository, "as input" is very rare. I suppose the word "given" is given to imply "as input"
There was a problem hiding this comment.
I think "given" -> "given as input" is clear.
|
Thanks all for the discussion. |
This helps address my comments in #710 (comment) exercism/problem-specifications#1398 exercism/problem-specifications#1404
exercism#1398 rewrote the test Description. The change should be carried over to the "blurb".
6 participants
No description provided.