[policy] Include starter implementations for the first X exercises so that new-to-the-language practitioners are driven by test failures, not compilation errors.

[rstockbridge]

I am new to Java but have prior programming experience. The problems I have completed so far on the Java track either have either come with a nearly blank starter implementation, or no starter implementation at all.

For my code to be compilable (and therefore testable), I have had to reverse engineer all the tests at once to deduce method signatures and 3rd party dependencies, even if most tests are ignored to begin with. It was quite challenging to infer some of the return values given that I am a beginner in Java.

It would be really helpful if the starter implementations contain sufficient information to be compilable, i.e. they contain required methods with appropriate signatures and dummy return values, and import statements. This way the focus can be on writing code that passes one test at a time.

[jtigger]

First, thank you for taking the time to provide this feedback, @rstockbridge.

This topic has also come up in other language tracks: exercism/rust#117, exercism/haskell#181. There's been a mix of opinions.

In exercism/rust#117:

@IanWhitney said

For me, I like not having the signature. I'm entirely new to Rust and static typing and I've found that I like puzzling out what I have to implement by looking at the tests.

@kytrinyx said:

I'm also on the fence. In the Go track we've provided stub files early on, and then we phase them out after the first few. For the most part reverse engineering function signatures doesn't seem to be difficult in Go ... I can't speak to how much busywork that adds here.

...

A proposal incorporating your request with those observations:

1. the first ~10 exercises, we provide complete stubs.
2. the subsequent ~10 exercises, we stub a portion of the interface and comment-out the bodies of the tests that cover the other part.
3. After that, include no starter code.
   • that said, if there are "interesting" interface aspects, mention these in the HINT.md file (gets merged into the README.md for the exercise).

Thoughts?

[rstockbridge]

This proposal sounds excellent 😄 - a good balance of helping beginners get started while still leaving some things to be figured out. Obviously it makes the most sense to implement this after #142 is complete.

[jtigger]

We've been using the new GitHub Projects feature to express priorities: https://github.com/exercism/xjava/projects/2

I've added this to our "Epics" column... once we determine the (re)ordering of the track, we'll break that down into individual user stories according to the proposal.

[rstockbridge]

Awesome, sounds good!

[jtigger]

I believe this qualifies as a "policy" — a decision that affects future work. Labeled accordingly.

[jtigger]

A "policy" is not a decision set-in-stone. It's a direction chosen at a point in time with the information/thinking on-hand. All decisions should be challenged.

To make a meaningful contribution, please include a new perspective and argue how it mixes in the values expressed and changes the decision.

[jtigger]

@exercism/java so...... how far into the track should we provide these starters?

[FridaTveit]

I think maybe provide complete starter implementations for the first five exercises? That way the exercises are still relatively easy when people have to start doing it all themselves.

And maybe for the next 10 exercises we provide incomplete starter implementations and comment out the bodies of the tests that cover the other parts like you suggested. But we should include a HINT.md or something to make it obvious that they need to uncomment that code.

After that we could provide no starter implementation. Apart from that there are some exercises, list-ops for example, where I think the most difficult part of the exercise is just figuring out what the signatures of the methods are meant to be, which doesn't seem quite right. So maybe provide incomplete starter implemetation in those cases?

[rstockbridge]

@FridaTveit Your suggestions are excellent - seems like the right balance of getting people started but also requiring them to become more independent.

[jtigger]

Agreed!

[stkent]

I'm going to close this issue now we have a centralized policies document. That document links back to this issue if we ever need to pull it back up for reevaluation!