Missing initial code for ruby track

I noticed that some tracks contains some boilerplate code when starting a new exercise, but this is not true for Ruby track.

When starting a new exercise in the Ruby track, we only have some comments as a starting point, like the following :

“”"
=begin Write your code for the ‘Reverse String’ exercise in this file. Make the tests in reverse_string_test.rb pass.

To get started with TDD, see the README.md file in your
ruby/reverse-string directory.
=end
`
“”"

I was wondering if this is something we can improve? (Considering that some users won’t know how to write the minimum code to start running the tests successfully)

The created issue is exercism/ruby#1754.


Which side of things are you wanting to improve, the Learning or the Practice? How do you see scaffolding helping the track in each situation that each side of the track presents?

It is not that we “only have some comments as a starting point” as some exercises do have more than only those comments.

But also, no code must be written to run the tests successfully. (Other than sometimes the infrastructure has a temporary issue.)

The “user” gets that for free when they either submit via the command line tool or hit that “run tests” button.

So I think I will ask you:

“Is this something we can improve?” Can you show an example that you might have in mind, given that the reason to consider that you gave was “some … will not know how to. … run the tests successfully”.

@kotp I did not express myself clearly, sorry about that.

Let’s take the exercise “Reverse String” as an example.

The Go version contains a minimal code as a starting point, as we can confirm in this link

The Ruby version, on the other hand, only contains the comments I mentioned in the original post, as we can see here.

What I have in mind is providing a minimal code as a starting point to the Ruby exercises that only have the comments. For the “Reverse String” exercise, we would have something like the following:

module Reverser
  def self.reverse(word)

  end
end

So we can talk here. The Go file is delivered as:

package reverse

func Reverse(input string) string {
	panic("Please implement the Reverse function")
}

While what we get with Ruby for the same exercise is:

=begin
Write your code for the 'Reverse String' exercise in this file. Make the tests in
`reverse_string_test.rb` pass.

To get started with TDD, see the `README.md` file in your
`ruby/reverse-string` directory.
=end

Now that is easy to see.

Then I would see your suggestion of:

module Reverser
  def self.reverse(word)
    
  end
end

This is communicating way too much information, and infers that choices
were made. For example, why would use we use module here? Why would we
not have instead:

class Reverser

  def self.reverse(collection)
    new(collection).to_s
  end

  # Solve the exercise using the "given" method above, leaving it as is

end

In some ways, this is helpful, but it does bias the learner in ways that
may not be appropriate. If this is a practice exercise, why would we
care how they solve it?

In the learning side, there are things that we do want them to practice,
but then again, it is too easy to influence their solution, and even in
ways that is hard to predict.


Still, with out the code suggested, the learner does not need to write
any code at all to successfully run the tests and be told “Uninitialized
Reverser”, which is telling them the minimum thing that they really need
to do to move forward to solve this successfully.

It leaves their choice to reach for module Reverser, or
class Reverser or even something else.

I would not want to unduly influence their choices, or seemingly dictate
solutions.

Other tracks are different than Ruby. For example, Go has a very much
"Do not worry about communication through style, our go_fmt tool will
communicate that for you, and take your personal subtle communication
out of the picture as much as we can.

C and some other languages very much benefit from having scaffolding
provided for you, at least for the first few exercises, so that you see
what that looks like, and then after that it is up to you to provide the
needed.


You showed your suggested improvement, it removes the comments.

Are the comments a problem?

Why are they gone?

Thanks for posting :slight_smile:

If this last bit is true, then I totally agree we should improve them. But I think by the time someone has worked through the learning exercises (which do have stubs - e.g. lasagna) they should be familiar enough with the basic setup code to be able to solve the other exercises.

Because Exercism expects students to look at the tests to pass the exercises, the required code should then hopefully be clear.

And then as @kotp says, the aim is to not give too much away. With Go, there’s really often one good route to a setup, whereas with Ruby, there’s often lots of routes (due to the differences in the languages)