Should there be a placeholder src/lib.rs for all exercises?

[mkantor]

I noticed that several of the exercises have placeholder implementations with various levels of verbosity (e.g. all-your-base, grains, react, space-age). However this is absent from most of the exercises. I was unable to find documentation to suggest whether these files should or should not exist.

Anyway, it could probably be considered a bug one way or the other. I'm willing to help standardize things.

[petertseng]

What I see in #117 and #200: I'm not sure what to make of discussions on what they should contain, but everyone seemed to agree that a lib/src.rs should at least exist, even if it is empty.

documentation

Our track's README is anemic. I have filed issue #278 to address that.

[mkantor]

@petertseng thanks, I neglected to search closed issues but I see there's a lot of good discussion already there. After reading everyone's arguments I'm on the fence about providing stub signatures, but agree that at the very least empty src/lib.rs files in every exercise would be nice. I'll send a PR to that effect in the near future.

[IanWhitney]

Here's my thoughts.

When we decide if there should be stub files we should think about who our students are.

If our student is someone new to Rust, then I think there is a lot of value in having them write the entire function themselves, including the signature. Not every exercise will have a interesting signature to write, but enough of them do. And thinking about "I want to accept type x and return type y" is the core of writing Rust (or at least it is for me, your mileage may vary).

If our student is someone familiar with Rust but trying to write better-designed implementations, then having the method signature makes more sense. They already understand that part of Rust and want to work on 'cleaner' code.

Personally, I'm a Rust learner, so I favor the first approach.

[ijanos]

I feel like the first approach is somewhat misguided in this context. I agree that it is educational to create a new function with a right signature, but we include tests and those "lock" the signatures.

Creativity and learning lies in figuring out a function signature that can be used to solve a problem. I see no creative work in recreating a signature from the tests, it is busywork. There are two approaches to solve an exercise with no stub:

1. Don't look at the test, only read the exercise. Create a function. Compile. Read the error messages.
2. Look at the tests and create the function with the right signature based on the test.

If you take the first approach there is a possibility that you created a perfectly fine solution but still fail because the creator of the test choose a different approach. If you succeed it is because you guessed correctly. How would you feel as a beginner who failed to guess right but you see nothing wrong with your solution?

The second approach is basically reading the signature, at this point there is no meaningful difference in providing one in a stub.

[jcdyer]

The second approach is basically reading the signature

Learning how to read a compiler error, and get from there to a method signature is a valuable skill for new rust developers to learn. Even if you're just appeasing the compiler, it's good to learn that this function needs to be marked pub, and that reference needs to be mutable in order to do a particular thing with it.

The problem, as I mentioned in #275 (now closed in favor of this ticket) is that the compiler errors from the tests make you fix all the issues before you can even get started. One solution is to provide stub functions that eliminate those issues. Another is to fully comment out all the tests but the first one, instead of marking them with #[ignore], so the learner can address them one at a time, and get the experience of building up an app from scratch, one feature at a time.

[petertseng]

the compiler errors from the tests make you fix all the issues before you can even get started

I'm obligated to ensure that previously mentioned proposals get mentioned - consider using https://doc.rust-lang.org/book/conditional-compilation.html for it.

[IanWhitney]

I experimented with conditional compilation a bit. I found it to be a clunky solution to the problem. But it's likely that I was doing it wrong.

[ijanos]

I think commenting out code is simple and easy to understood even for beginners.

I still prefer the stub file approach though :)

[petertseng]

I was thinking it'd be easier for https://github.com/exercism/xrust/blob/master/_test/check-exercises.sh#L44 to work with #[cfg(feature = "remove this line when you're ready to test")] than to uncomment. But we can make it easier if the comment start/end were specific strings like /* move this line below the next test when you are ready for it and either something like exercism */ or (this will bite often since we will often get it wrong, I'm sure) make sure the */ is the last line in the file.

I personally don't think I gain a lot out of reconstructing the stubs from the tests, so I can say I would prefer to have the signatures in the stub files. This is based on the fact that starting with a test and no code is not reflective of how I code normally at all - if I were coding from scratch I would have decided the function signature before writing the test. The fact that the test is already determined means I have relatively little choice in the signature.

However, I also don't care enough to go and populate the stub files with signatures myself!

It occurs to me that if we provide signatures, it's relatively easy for a student who does not want them to simple truncate -s0 src/lib.rs, but harder to do it the other way around (student copies signatures from example solution?).

Whichever we choose, we'll obviously fail to make someone happy. In the far future we could allow the student to configure whether the stub files should have signatures or be empty as in exercism/discussions#114 (comment), but we can't wait for that to make a decision since it is the far future.

I wonder if it'd be smart to survey students working through the Rust track and see what they think, in a similar fashion as https://gist.github.com/behrtam/9b1aaae227b5e67dd145ecd5f74e58eb.