Go: Specifications confusing

[cjbottaro]

Hello. I'm doing the Go track and I find the specifications in the readme very confusing. Take hello-world for example...

First off all, we're not writing a program (there is no main function), we just writing a function (the readme instructs to write a program).

Second, if we're writing a function, the specification should be described in terms of input and output (and maybe side effects). Using words like "greets", "says" and "saying" implies printing (presumably to STDOUT). Using phrases like "If I tell the program..." implies that we're writing a program with command line args (argv).

Looking at the tests reveal this is absolutely not the case. We're writing a function which takes a string as input and returns a string. It would be much more clear, IMO, if the specification was written like:

Write a function named HelloWorld which takes a single string as input.
If the string is empty (""), the function should return "Hello, World!".
If the string is non-empty, the function should return a greeting:  "Hello, <string>!".

Thank you.

[kytrinyx]

I find the specifications in the readme very confusing [...].

Yeah, that's fair. We try to make the README generic, since the same description is used for all of the languages.

We can't say "write a function" (some languages have methods not functions) and we can't specify inputs and outputs (implementations vary between languages). The test suite is the specification.

I'll see what I can do to clarify.

[cjbottaro]

Ahh, I thought the readme was specific to each language. Interesting. So that means all the exercises are the same across the all languages? That seems difficult to be able to teach idiomatic code.

Take for example an exercise where the user is to create an in-memory cache. Languages without closures would probably just have an API with cache.read and cache.write. But languages with closures (like Ruby), you could have a cache.fetch:

cache.fetch(key){ generate_value } # block is only called if key doesn't exist

But this idea doesn't translate well to, say, Python because Python doesn't have anonymous functions (lambdas only allow expressions).

Anyway, just some ideas. :)

[kytrinyx]

So that means all the exercises are the same across the all languages?

Ish :) Language tracks will skip exercises that don't make sense in that language. Here's the full list of problems and which languages implement them: http://x.exercism.io/problems

[Insti]

Languages can add their own specific comments to the Readme using a HINTS.md file.

[kytrinyx]

I'm going to close this in favor of the one that @Insti kindly opened a new one in the Go track. (Thanks @Insti!)