All tracks that have discussed whether to have stubs or not

[petertseng]

Hello. If your track ever had any discussions regarding whether to provide stub files to students, I would be pleased if you would comment on this issue with what you decided. Or, even better, if you have records of these discussions in an issue or PR, you could add a link to the below list.

Due to my laziness, I'll only record tracks for which there actually was a discussion. It wonder if that skews the results at all!

If you want to take the time to record tracks for which there was no discussion, I wouldn't object, I just won't do it myself. The reason is that it takes slightly less time to scan a single issue to determine what the track's policy is, and more time to scan multiple directories and determine whether they contain stub files. Note that this also implies there is no check to see whether a track actually complies with its own policy. That is also out of scope, since each track's maintainers can individually decide how quickly to make the track conform to its own policies.

• Template for exercise submission exercism#960 - first support for stub files

Track	Issue	Stubs?	If yes, contents?
Bash	exercism/bash#87	hello world	signatures
C	exercism/c#43	hello world	signatures
C	exercism/c#252	first two	signatures
C++	exercism/cpp#4	no
C#	exercism/csharp#138	all	signatures or empty classes
Ceylon	exercism/ceylon#11	all	signatures
Coq	exercism/coq#4	all	signatures
Clojure	exercism/clojure#121	all	names
Clojure	exercism/clojure#136	first 5	names
Clojure	exercism/clojure#205*	all	names
Crystal	exercism/crystal#63	all	blank
Dart	exercism/dart#82	pending
Elm	exercism/elm#206*	all	signatures
Erlang	exercism/erlang#145*	all	signatures
F#	exercism/fsharp#229	all	difficulty 1-3: signatures+types; 4-7: signatures; 8-10: empty
Go	exercism/go#148	first few	signatures
Go	exercism/go#279	first few	signatures
Haskell	exercism/haskell#181	all	signatures
Java	exercism/java#178	first 10+10	signatures
Java	exercism/java#977	difficulty < 5	signatures
JavaScript	exercism/javascript#128	first 2	signatures
JavaScript	exercism/javascript#424	pending	pending
Julia	exercism/julia#2 (comment)	all	signatures
Lisp	exercism/common-lisp#20	all	signatures
Perl6	exercism/raku#76	all	first few: signatures. rest: blank
Pony	exercism/pony#37*	all	signatures
PureScript	exercism/purescript#8 (comment)	all	names
Python	exercism/python#210	no
Python	exercism/python#272	all	names
OCaml	exercism/ocaml#285	all	signatures
Rust	exercism/rust#117	all	empty (some w/ sigs)
Rust	exercism/rust#117	all	empty (some w/ sigs)
Rust	exercism/rust#200	all	empty (continued)
Rust	exercism/rust#269	all	empty (continued)
Scala	exercism/scala#137	all	first 10: signatures. rest: blank
Scheme	exercism/scheme#1*	all	signatures
Standard ML	exercism/sml#32	all	signatures
Swift	exercism/swift#245 (comment)	all	blank
TypeScript	exercism/typescript#57	all	blank

Asterisk indicates the link only determines the policy of whether to have stubs. No asterisk indicates the link includes rationale.

[petertseng]

I feel like I should close this issue since there is never any "completed" state for it (maybe if all tracks wanted to standardise on whether to provide stub files or not, and we decided to come together and make it happen), and I wouldn't want it to clog up the issue queue. I'm still happy to hear your comments though, don't let the fact that the issue is closed stop you!

[petertseng]

In general, it seems stubs may be provided for at least two reasons:

1. If the implementation file needs to be placed in a certain directory due to the language or build tool's project structure.
   • Having a stub file (empty or not) saves the student the busy-work of having to create the directory structure then create the file.
   • Note that this busy-work has been described as supremely annoying.
   • I think this is always a good reason to have a stub file.
2. The stub file could possibly provide the expected signatures.
   • There is healthy debate about whether it is a useful learning experience for the student to figure out the expected signatures versus just busy-work.
   • As a middle ground, some tracks may decide to place the expected signatures in a comment in the test file, or in HINTS.md such that it becomes included in the README.
   • Some tracks choose to only do this for the first few exercise, to get the student started on the track, but then wean off.
   • Of course, tracks that do not wish to do this can just include an empty stub file, which at least will cause the directory structure to be preserved.
   • For statically-typed languages, typically the entire test suite must type-check before it can be run. Therefore, to make the test suite runnable, tracks of statically-typed languages tend to choose one of the following options:
     • nothing (as a consequence, students must figure out the signatures from reading the tests and write them all before any work can be done on the first test)
     • provide stubs with the signatures: saves student the above work, but also removes that part of the learning process
     • use conditional compilation to make the compiler not perform type-checking for later tests. This is not possible in all languages.

[kytrinyx]

FYI @exercism/track-maintainers interesting discussion/analysis here about stub files. If you have anything to add (including links to discussions in your respective tracks), please add it here.

[masters3d]

Swift just moved to stub blank files for all excercises.
exercism/swift#245 (comment)

[robkeim]

@petertseng I updated your original comment with the related discussion in C# and F#.

FYI @ErikSchierboom who created these issues.

[Insti]

Re-opened this because it's still under active discussion and it would nice if it was more discoverable. We can close it again once it gets old and we've all worked out what we're doing about our stubs.

[ErikSchierboom]

The concensus of the C# and F# track was that we will be using stub files, where the earlier ones will already be providing the exact required functions, and later on you will have to add them yourselves.

[verdammelt]

The Lisp track uses a stub file for all exercises as the boilerplate to set up the package is not something we are teaching. I think this is important to do. It is analogous to the issues of specific directory structures in other languages.

Currently all our exercises contain functions with the correct signature but no body. I'm thinking now that dropping these off after the first set of exercises would be safe to do.

[petertseng]

There is healthy debate about whether it is a useful learning experience for the student to figure out the expected signatures versus just busy-work.
As a middle ground, some tracks may decide to place the expected signatures in a comment in the test file, or in HINTS.md such that it becomes included in the README.

A vision of the future...

What if I, as a student, could express a preference (possibly per-track) for what kind of stub file the API delivers:

• Always with signatures
• Always without signatures (and/or always empty, though these two might not always be the same)
• The track maintainers' recommendation (may differ based on exercise)

Catering to the preferences and needs of different audiences (Those who say "I think it's educational and valuable to think carefully about the signatures" versus "I think it's useless busy-work to have to divine the signatures from the test file")

[IanWhitney]

That would be cool. If someone (not it!) wants to do the work, I would support it.

[LegalizeAdulthood]

Regarding C++, I think the conclusion is no.

We can always change our mind later :).

[petertseng]

Regarding C++, I think the conclusion is no.

Good. Next step is if there is any issue other than exercism/cpp#4 that documents the decision in detail, to say what that issue is. If there is no such issue, there is no need to respond.

[tuxagon]

What if I, as a student, could express a preference (possibly per-track) for what kind of stub file the API delivers

@petertseng I find this a fascinating idea. One of the biggest complications, I think, is the tests would require a specific signature, especially for statically-typed languages. I'm not sure it wouldn't ever not be busy-work under those conditions. The concept of "catered" problem solving is really interesting, though.

[sshine]

OCaml: exercism/ocaml#285, stubs for all files, containing signatures.