zero_zilch_nada: remove ambiguous reference to empty

[sudomateo]

In Go, there can be a difference between a type's zero value and its
empty value. For example, consider the following code snippet:

func main() {
	var s1 []string
	fmt.Printf("%#v\n", s1)
	if s1 == nil {
		fmt.Println("s1 is equal to nil")
	}

	s2 := []string{}
	fmt.Printf("%#v\n", s2)
	if s2 == nil {
		fmt.Println("s2 is equal to nil")
	}
}

The variable s1 will be set to its zero value (nil) whereas the
variable s2 will be set to a slice of strings with zero elements. This
behavior makes the term "empty" ambiguous and may confuse students as they
continue learning about Go.

In addition to code updates, the exercise text was updated to introduce
the var keyword as well as various verbiage updates.

Updated the documentation for the nil and zero-values concepts to better
reflect the new zero_zilch_nada exercise content. Long term, I'd
probably recommend merging the two concepts into one but for now keeping
their content the same ensures that students will learn the relevant
content regardless of which concept they click on.

[ErikSchierboom]

Thanks a lot for working on this! I've left some comments to help explain what is expected in the various documents.

I don't know if you're interested, but this exercise could use a little love. In its current state it is, well, rather matter-of-factly. You just return a single value from the functions and there is no real story/theme around the functionality to give the students something fun to work with. Would you be interested in trying to add a bit more flavor to this exercise and make it more fun for students? If so, let me know, and I can help you with that.

[sudomateo]

Thank you for the feedback! I reworked the zero-values concept per your feedback. I also updated the zero-zilch-nada exercise to be a bit more involved for the student.

I'll do the same for the nil concept once I get more time to work on this. For now I'm leaving conversations open around the nil concept.

[ErikSchierboom]

I also updated the zero-zilch-nada exercise to be a bit more involved for the student.

Maybe I'm missing something, but the instructions of the exercise look to be relatively unchanged. With more involved, I meant giving the exercise a little bit of story/theme, to have the tasks make sense for the student (and not just a list of fill-in methods). Note that this story/theme doesn't have to be very involved, it can be relatively simple. For some inspiration, I'd look at existing exercises like https://github.com/exercism/elixir/blob/main/exercises/concept/dna-encoding/.docs/instructions.md or https://github.com/exercism/elixir/blob/main/exercises/concept/high-school-sweetheart/.docs/instructions.md

[junedev]

@sudomateo As a story I can recommend the amusement park story: https://github.com/exercism/javascript/blob/main/exercises/concept/amusement-park/.docs/instructions.md

Write some introduction sentences about working for the amusement park IT and being in charge of data quality of the visitor data etc.

Then you can set up the tasks the following way:

• First Task: let the student write a NewVisitor function that creates and returns a visitor struct given some data as parameters. Describe in the task descriptions which fields the struct should have, e.g. name as string, age as int, address as map (street, city), etc. This task does not practice anything yet really, it is more for the setup.
• Then the following tasks can be things like "Determine whether the visitor provided a name" where you pass a visitor struct as parameter and the function e.g. "nameIsSet" returns true or false depending on the value of that field.
• I would see the above as the minimum to make this a bit more story-like. If you want to go further you can also mix it up with something like this task where you provide some map and the student needs to return some text: https://github.com/exercism/javascript/blob/main/exercises/concept/amusement-park/.docs/instructions.md#4-improve-the-ticket-status-response

I don't think it is necessary that the exercise covers all the types. Concentrate on a few tasks to cover the most common types. That's enough for the student to understand the idea.

If you go ahead with these types of tasks, don't forget to add structs as a prerequisite.

Erik says it is ok to change the slug and folder name to "amusement-park".

[ErikSchierboom]

I don't think it is necessary that the exercise covers all the types. Concentrate on a few tasks to cover the most common types. That's enough for the student to understand the idea.

100% this ☝️

[sudomateo]

Thank you for the feedback @ErikSchierboom and @junedev. I've been a bit busy in and out of work the past week. I'll try to take a look at this in the next few days. I like the idea of making the exercise a bit more story-like. When I first opened this pull request, I was under the impression I should leave the exercise alone. It's nice to see that I can help shape the exercise to be more engaging.

[jmrunkle]

FYI: CI should be fixed at head if you do not mind syncing your fork with main and then rebasing this branch.

[sudomateo]

I'm going modify the zero-zilch-nada exercise and rename it to census. This census exercise will ask the user to create new residents with their necessary information, check whether or not required information is missing from a given resident, allow the counting of valid residents with all required information present, and allow residents to "move out" by setting their fields to their zero value. It's similar to the amusement park exercise with a bit more focus on zero values. I'll update this pull request once I finish the exercise. Apologies for the delay, last minute travel plans.

[ErikSchierboom]

I'm going modify the zero-zilch-nada exercise and rename it to census. This census exercise will ask the user to create new residents with their necessary information, check whether or not required information is missing from a given resident, allow the counting of valid residents with all required information present, and allow residents to "move out" by setting their fields to their zero value. It's similar to the amusement park exercise with a bit more focus on zero values. I'll update this pull request once I finish the exercise. Apologies for the delay, last minute travel plans.

That sounds excellent.

[ErikSchierboom]

This looks great! I'll let one of the Go maintainers review the Go side of things.

Thanks a lot!

[ErikSchierboom]

There is a merge conflict.

[ErikSchierboom]

Nice! @junedev could you look at the Go side of things?

[junedev]

Nice! @junedev could you look at the Go side of things?

Done

[junedev]

@sudomateo The last thing that remains is getting the CI to pass.

For the prerequisites you need to write "string-formatting" instead of "strings" for now. (It will be changed later when "strings" becomes available. Additionally you need to remove "pointers" for now as it does not exists yet. You can leave a comment here #1643 that it needs to be added again later.

[junedev]

As for the other CI failures, can you try to use "package census" instead of "package census_test" for the test file? This is how it was done in the other concept exercises. (Not sure this will fix the issue though.)

[ekingery]

Rubber stamping based on the other reviews / fixes and the tests passing.

[sudomateo]

Fixed the merge conflict.

[ekingery]

Fixed the merge conflict.

By the way, thanks for your work on this exercise, @sudomateo! Looks great.

[sudomateo]

Fixed the merge conflict.

By the way, thanks for your work on this exercise, @sudomateo! Looks great.

Anytime! I'm happy to help!

[ErikSchierboom]

Yeah, great work @sudomateo!