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

Why not always provide header for client? #252

Closed
jocal17 opened this issue Dec 23, 2017 · 11 comments
Closed

Why not always provide header for client? #252

jocal17 opened this issue Dec 23, 2017 · 11 comments

Comments

@jocal17
Copy link

jocal17 commented Dec 23, 2017

How about changing exercise anatomy to
+--
+-- makefile
+-- src
| +-- example.c
| +-- .h

Since the client always needs to now what the test is expecting, why not either always make them check the test or always have header included? The latter seems better since exercism advertises as beginner friendly.

@ryanplusplus
Copy link
Member

@patricksjackson @wolf99 what are your thoughts? I think we had this discussion before but can't remember why we decided not to provide a header.

@arcuru
Copy link
Contributor

arcuru commented Dec 24, 2017

Typically we provide the header if it's the first problem (hello world) or if it's not obvious what the header needs to be from the test file (see the struct definitions in anagram). I would bet that there are at least a couple problems where the necessary header content is really not obvious from the test file though, so just giving all the headers would certainly make things easier.

The problem is we have to walk the line of helping out enough to be 'beginner friendly', yet not taking away too much of the problem solving. If we provided all the headers then we would never be forcing a student to ask "What type should this argument be?". The test files can't always let that be a choice, but we really want students to be asking those questions early, as long as it doesn't turn them off from continuing.

So there is value in learning how to reverse engineer an interface from the test file, and there are several best practices unique to headers that are easier to learn after somebody points them out to you in code review (but you'd probably ignore if we just gave the header). For example, header guards and const'ness in the function definitions.

That said there'd probably be less friction if we just included them all, but that doesn't necessarily mean it'd be better :)

(It's been quite a while since I learned C, so I don't know how prohibitive 'figuring out the headers' actually is, and you can take my opinion with a grain of salt.)

@wolf99
Copy link
Contributor

wolf99 commented Dec 24, 2017

Issue #43 discussed this previously.
For my own opinion, I'd tend to agree with @patricksjackson. As with most language tracks there is a point at which the student has to learn how to implement the interface as well as the implementation. Making the step to deciding on and implementing the header files provides this, at least in part. IMHO people that reach the level where the stub files are no longer provided should be able to figure out how to create them themselves by that point - it is a necessary part of programming in C as only very basic programs could be created without writing one's own header files at some point.

It occurs to me that to for students to experience the full design decision process there should be a some subsequent point at which they are asked to write the test file itself also! AFAICT though this would be unfeasible for the language track infrastructure to handle.

@wolf99
Copy link
Contributor

wolf99 commented Dec 24, 2017

I can't recall if the README's provide any hints about this for the first exercises that require it. @jocal17 do you recall which exercise you found this to be an issue?

It might be worth providing some hand-holding for the first one or two. The Java track has done something similar recently, exercism/java#1075

@jocal17
Copy link
Author

jocal17 commented Dec 26, 2017

It was the second exercise, isogram. Since all other exercises I've done provided a starting file my first thought was that the isogram one was broken.

@wolf99
Copy link
Contributor

wolf99 commented Dec 27, 2017

Would this have been due to the exercise reordering? Or is it intentional that later exercises provide stubs? (maybe to help in more complex exercises)

@jocal17
Copy link
Author

jocal17 commented Jan 4, 2018

It was intentional in the other exercises. As far as I can tell they are provided for all exercises. They were Haskell and Python so somewhat different, though Haskell also provides the function types.

@wolf99
Copy link
Contributor

wolf99 commented Jan 4, 2018

The current core exercises with stubs, in current order of curriculum is listed below, basically only hello-world has one. Later exercises in the list with headers are provided to give type or limit definitions, but students will not reach these if they fail after hello-world. A number of the non-core exercises also have headers provided.

Following just the core, IMO it seems the jump to no provided header may now happen a little early in the case that a student is very new to C. Maybe we should provide a header for isogram also (and whatever exercises are unlocked by it) and a hints.md file for gigasecond (and whatever exercises are unlocked by it), to explain that the student is now expected to add the header themselves. What do you think @ryanplusplus , @patricksjackson ?

  • hello-world
  • isogram
  • gigasecond
  • hamming
  • grains
  • beer-song
  • difference-of-squares
  • binary-search
  • roman-numerals
  • allergies
  • atbash-cipher
  • phone-number
  • clock
  • sieve
  • robot-simulator
  • pascals-triangle
  • binary
  • palindrome-products
  • scrabble-score
  • queen-attack

@ryanplusplus
Copy link
Member

I think that sounds reasonable

@wolf99
Copy link
Contributor

wolf99 commented Jan 5, 2018

I'll start working on a PR for this soon then 😃

@wolf99
Copy link
Contributor

wolf99 commented Jan 8, 2018

Fixed by #255

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

No branches or pull requests

4 participants