Stub file on compiled strong typed track

Exercism Building Exercism
1

What do you think it would be a good practice to provide a student with a stub file in a compiled strongly typed track?

I’d like to offer a stub file that compiles without errors and fails all tests in a generic way without providing hints for resolution, but I realized that would be completely impractical. I’m currently using a stub file “version” that doesn’t compile and offers a very basic code structure, at least in the “easy” exercises, and a comment on the need to implement the solution.

Perhaps a description that the code offered doesn’t compile and requires implementing the solution would be sufficient, but I’m not sure about that and I don’t know the best way/words to talk it to people. My concern is that the fact that the code doesn’t compile will cause the student to interpret it as a buggy exercise and give up trying to solve it, as has happened to me more than once in some completely unfamiliar language courses I had enrolled in.

2

Would this compile?

Function RunExercise(
    Const InputBase   : Integer;
    Const InputDigits : IntArray;
    Const OutputBase  : Integer
) :   IntArray;
Begin

   Raise Exception.Create('Please implement this function');

End;
1 Like
3

It chains with another issue I have.

Under my current compilation flags (-Sehnw), it don’t compile:

AllYourBase.pas(26,10) Error: Identifier not found "Exception"
AllYourBase.pas(32) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /home/jimmy/fpc-3.2.2/bin/ppcx64 returned an error exitcode

I set up a very strict compilation method thinking it might help with messages about unused/initialized variables, units, unused functions, etc. But I was never sure if this was actually a good idea. I was thinking about changing or removing these flags, and if so, I should actually create a compilable version of the stub file instead of just explaining what to do “before starting.”

Without the flags, the error is:

An unhandled exception occurred at $0000000000456EE7:
Exception: Please implement this function
  $0000000000456EE7
  $0000000000401379

For now, I don’t know a good way to catch and show only the message to the student or if I just let it as is. But I can try to find a solution for all the “issues”, including the compiler restrict flags.

4

Like @keiraville indicated, the norm generally is to have the code panic by default, preferably with a message telling the student they need to replace the panicking line with their implementation. You’d then document this in the track-specific testing docs so it’s clear what students need to do.

2 Likes
5

It also is a goal to learn to read the failure output of the compiler and make sense of it. So I would not put too much effort into “beautifying” failure messages.

Document what you expect people to do (in track docs), add comments to (at least the first couple of) exercise stubs about what might be problematic for language beginners and then expect people to have learned enough of the basics to get along with compiler output and test feedback.

1 Like
6

To that end, The Test Runner Interface | Exercism's Docs has guidance about what types of cleanup might be useful. Simplifying the paths in the output was a helpful tip for the Racket track. The version number is embedded in the raco output and stripping it out means we don’t need to update the golden tests every time we bump the Racket language version.

2 Likes