Based on something that I brought up on the Racket track a while back, I think the hello-world objective “Modify the provided code so that it produces the string ‘Hello, World!’” is potentially misleading – the code isn’t itself producing “Hello, World!” when it’s run, it’s the test runner that’s checking the return value. There’s been a historic issue with students misunderstanding what the Hello, World exercise is actually asking for, and I think that some more precise language in the objective might help with that.
I suggested changing Racket’s description to “so that the function returns the string” instead, but the track maintainer suggested I bump it up a tier and bring it up here instead, to see if there’s some language or clarification that’d be potentially better for all tracks.
More that “it” means “the code in the box”. A function doesn’t inherently return anything when it’s interpreted/compiled, so it wouldn’t be the right answer, based on that assumption. This is the complaint someone had about the description when I showed them a language track.
Right — it’s missing the “when evaluated” context. A function definition on its own doesn’t do anything, so if the expectation is that just the code that is presented to the student in the editor should “produce” a value, rather than be evaluated by the test runner, this could be a potential source of confusion.
I don’t think we need to specify that code only takes effect when executed. That’s pretty fundamental to what “code” is. Exercism doesn’t set out to teach what code is or how programs work.