Leap: Remove recommendation to DIY in description

[sshine]

Leap-year functions don't generally occur in standard libraries.

Is there a single example of a language we have that does this?

If there is one, then that would be the right way to solve this exercise in that language. Presumably this exercise is primarily placed at the top of core tracks. We should not encourage to re-implement standard library functions at that point. But this is a hypothetical argument.

[NobbZ]

The first language that comes to my mind was PHP, but google didn't return something useful in this regard, so I tried ruby and TADA:

https://ruby-doc.org/stdlib-2.3.1/libdoc/date/rdoc/Date.html#method-c-leap-3F

And as ruby was more or less the very first language in exercism, this makes totally sense to be there (initially).

But I wouldn't miss the sentence, as ruby is probably one of the very, very rare samples having it in the stdlib.

[emcoding]

Yeah, Ruby has Date#leap? :-) It makes sense to move this sentence to the exercise's hint.md file in the Track repo for every language that has it. Ruby/Leap https://github.com/exercism/ruby/tree/master/exercises/leap

As a side note: I don't mind that we keep DIY exercises in the track, as long as they're not core. And I'd prefer if we add a 'diy' topic to those exercises. But this is still under consideration in the core team.

[sshine]

I don't mind that we keep DIY exercises in the track, as long as they're not core.

That's exactly why I tagged you; I've seen you make that point before and wanted to make that come across. :)

[sshine]

Can I merge this?

[sshine]

@petertseng just reminded me that this PR existed in #1582 in relation to the statement "When implementing this in a language with a built-in square root function, implement your own function.", and to my surprise, I was the author of this PR.

I am still in favor of having merged it, but I no longer find the argument reasonable. For the sake of correctness, I will criticize this argument and provide another one so that this PR may only give warranted precedence to similar choices or future policy-making.

TL;DR: Providing such a comment in .meta/hints.md instead of in README.md gives the most flexibility for individual tracks to decide. The drawback is that the contributor who ports the exercise to another track has to remember to add it if it applies to their track.

---

The rest of this is me talking to myself.

Leap-year functions don't generally occur in standard libraries.

I disagree now.

Depending on what is meant by "standard libraries" (the "core" of what makes the runtime system able to run, or some curated subset of most used packages or modules, or something similar), they may or may not ship directly with the execution environment, but there is almost always a date or calendar library within short reach of the seasoned developer that does contain such a function, and often this date or calendar module does not even need to be explicitly installed on its own.

Is there a single example of a language we have that does this?

• Haskell: Data.Time.Calendar.isLeapYear
• OCaml: Date.is_leap_year
• Python: calendar.isleap
• Ruby: Date.leap?
• and so on...

for various definitions of what a standard library is.

If there is one, then that would be the right way to solve this exercise in that language.

Yes. And I seem to recall that we don't want reimplementation exercises on the core track.

And maybe that invalidates Leap completely as a core exercise. And maybe it doesn't.

Depending on whether or not we should ever ask a student on any track to reimplement functions that are somehow already available, and depending on whether or not we should have a fixed policy about this, or simply recommend these things, requires some high-level policy making.

Presumably this exercise is primarily placed at the top of core tracks. We should not encourage to re-implement standard library functions at that point. But this is a hypothetical argument.

Yes, Leap occurs in the core track for 22 tracks and is most often the 1st or 2nd exercise after Hello, and in two cases the 3rd exercise. And yes, we should not encourage to re-implement standard library functions without, at least, disclaiming at some point, before or after having solved the exercise, that they exist.

To restate, I don't oppose that this was merged.

But for the reason that having an "If your language ..." message in the README is slightly obstructive to every single track, since it presents the student with the imperative to not use something they don't know whether exists or not. Then rather provide a track-specific message that says you can't use a function if this applies.

[yawpitch]

And maybe that invalidates Leap completely as a core exercise. And maybe it doesn't.

It absolutely does not. If we wrote an exercise that did sha1 hashing that would be valuable to any student that had never implemented it, regardless of whether or not sha1 hashing is in the standard library of any number of languages.

[bencoman]

If we wrote an exercise that did sha1 hashing that would be valuable to any student that had never implemented it

That depends on whether the aim of Exercism is to: a) teach algorithms; or b) teach languages.
I thought it was weighted towards the latter.

That said, I lean towards "don't use the built in function" for sufficiently simply exercises

• e.g. Leap is about practicing simple boolean expressions and modulo division, which students miss if they use a built-in function. A hint saying "don't use built-in isLeap()" has a side-effect of teaching students that that function exists and they don't gain anything more from actually using it.

[yawpitch]

That depends on whether the aim of Exercism is to: a) teach algorithms; or b) teach languages.
I thought it was weighted towards the latter.

There’s no conflict between between those two. Implementing anything involves learning an algorithm, and implementing the algorithms behind either sha1 or leap will introduce several important components of the language.

Leap is about practicing simple boolean expressions and modulo division, which students miss if they use a built-in function. A hint saying "don't use built-in isLeap()" has a side-effect of teaching students that that function exists and they don't gain anything more from actually using it.

That’s my point; there’s nothing wrong with re-implementing what may be standard library functionality if it helps learn part of the language. The beauty of properly implementing leap is that it teaches much more than modulo division and Boolean expressions. An idealized solution in any given language may require addressing evaluation order, operator precedence rules, and things like short-circuiting. The reason it exists in so many standard libraries is because it’s both non-trivial to understand all that and something that, once you get it right, is unusually small and stable and prone to being a good example of those areas of the language’s idioms. Re-implementing it isn’t make work, any more than reimplementing sha1 or wc or find etc would be.

A statement in the README indicating that a builtin should be avoided is sufficient.