-
Notifications
You must be signed in to change notification settings - Fork 520
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
Problem Ordering #127
Comments
And here's my first suggested order, grouped into sections just so I could explain why I put certain problems together: Getting StartedThis ordering feels pretty good to me. These problems tend to show up early in tracks and they don't seem to hit any of Rust's weirder edges.
Getting into RustNow we start to hit some more Rust-specific stuff. And the order here I'm less clear on.
LifetimesNow for the real Rust-specific stuff. We only have three exercises that require lifetimes. Anagrams is the easiest, since it doesn't use structs & randomness
Putting it all togetherThese are the ones where I looked at the example code and said "I dunno what this is even doing." I have no opinion about the order of these, since I don't fully understand them.
|
@IanWhitney this is so good! |
Note: This won't pass CI. I haven't yet put the problem into config.json. Waiting on exercism#127 Implements the Pangram problem and follows the current canonical test suite.
I'm about to do a PR to add the Pangram exercise. My example implementation may not be the way most students go, so I'm not sure we can rely on it to figure out where the exercise should go. But, most solutions will almost certainly use
Based on that, I think it would go towards the start of the Getting Into Rust section. Somewhere in the first 3 problems. |
And #131, when it's ready for merge, should probably be in the 2nd half of Getting Into Rust. Somewhere around |
Fixes exercism#127 This commit follows the problem order I suggested in exercism#127, with one exception. I've put sublist ahead of allergies. Both use enum, but the enums in allergies can be more of a hassle, as evidenced by all of the ways I've seen students implement them. Sublist does have the disadvantage of also requiring a solution that is generic over multiple types. But I think the best thing to do is keep an eye on students that reach this part of the track. Or the later introduction of new exercises could improve this flow.
History: Thanks to the hard work of #167 and #127, we have topics in problems.md that tell why we ordered problems a certain way. After #229 (motivated by #179), we copied the topics into config.json, since now all tracks can take advantage of the "topics" concept. To reduce duplication, we can remove the topics and specific problems. This commit uses something more abstract, that states our values without going into the exact implementation. This requires less maintenance, and is less likely to go out of date than specifically listing problems. Since it only has the ordering philosophy and not the actual topics, it's time to rename it to problem_ordering.md. Closes #236
As brought up in #126 (and elsewhere), our problem ordering is weird. I've certainly put some problems in the wrong spots, for sure.
I ran through the example solutions for all of our problems made a table of what skills each problem (probably) requires. Implementations can vary, obviously.
So, some stuff is at the bottom that clearly should be (rectangles, forth, circular-buffer). But the start of our problem list is not well geared towards newcomers. Let's discuss better options.
The text was updated successfully, but these errors were encountered: