Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we remove the twofer exercise entirely? #552

Closed
coriolinus opened this issue Jun 18, 2018 · 5 comments · Fixed by #560
Closed

Should we remove the twofer exercise entirely? #552

coriolinus opened this issue Jun 18, 2018 · 5 comments · Fixed by #560

Comments

@coriolinus
Copy link
Member

The twofer exercise assigns special meaning to the empty string, which is not good practice in rust. We came to a close decision to use that instead of the Option type, but it still doesn't feel right.

We have a ton of exercises toward the beginning of the track; the track would not suffer for removing one.

Thoughts?

@coriolinus
Copy link
Member Author

coriolinus commented Jun 18, 2018

Also, configlet gets confused by the twofer exercise name; it expects "two-fer", apparently. See #547.

@ZapAnton
Copy link
Contributor

My two cents, if I may.

This may sound like weak compromise, but what about leaving twofer exercise as it is (with some modifications like a comment, stating that using empty string to convey special meaning is a bad practice in Rust, and, perhaps, a feature-locked test with Option as an example of idiomatic Rust - basically suggestions from #520 ) and adding another exercise (e.g. twofer-idiomatic) that is completely done using Option?

The motivation behind this suggestion is that Rust is not really beginner-friendly language to learn that requires some mental shift and a lot of reading from user to learn about immutability, Options, borrow-checker etc. There is a big learning gap between doing things in Rust like you would do it in another language and doing things the Rust way.

Perhaps splitting exercises could show this to new users and motivate them to spend more time to study advanced topic in Rust while still learning the basics.

It would also prepare people, who would try to complete double-linked-list or BST exercises, since these are trivial exercises in other languages but may seem really hard in Rust (at least in safe Rust).

If splitting the exercises is undesirable then I would rewrite twofer with Options and move it somewhere between 8th and 10th exercises

@petertseng
Copy link
Member

The original purpose of two-fer was to immediately follow hello-world, but exercism/problem-specifications#1170 abolished that, which I agree with because exercism/problem-specifications#949 (comment) .

Let's take some time to decide what we want Rust track students to get out of two-fer. If it's "generic easy exercise", then yeah we have a whole ton of those already. Like leap. Don't need two-fer, and I'd be down with getting rid of it. If it's intro to Option, sure that's fine, then move it later (although does that mean the previous exercise that was intro to Option no longer the intro to Option)?

Ideally I'd incorporate general student response to the exercise on exercism.io into my answer, but I cannot honestly say that I have the time to evaluate student response there (only what people post here).

@coriolinus
Copy link
Member Author

coriolinus commented Jun 21, 2018 via email

@petertseng
Copy link
Member

want an exercise dedicated to introducing conditionals?

I think the answer is yes if and only if the goal of an exercism track should be to teach a language from scratch. Unfortunately, I didn't find in https://github.com/exercism/docs/blob/master/about/goal-of-exercism.md a clear yes or no answer to that question (maybe I missed it, feel free to correct me).

Personally I think that since we provide the links in https://github.com/exercism/rust/blob/master/docs/LEARNING.md and we don't want to compete with those links, I don't think we're teaching from scratch

So to me that says remove.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants