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

hello-world: description forces implementation #1850

Closed
ErikSchierboom opened this issue Sep 22, 2021 · 18 comments
Closed

hello-world: description forces implementation #1850

ErikSchierboom opened this issue Sep 22, 2021 · 18 comments

Comments

@ErikSchierboom
Copy link
Member

The description.md file of the hello-world exercise contains the following text:

Write a function that returns the string "Hello, World!"

While this may seem innocuous, not all tracks are using a function to return the string "Hello, World!".

Case in point: F#

While we could make F# use a function, I'd rather not to as it adds unnecessary overhead.

Apart from that, some tracks only have methods (which are a special type of functions), so the terminology seems wrong there too.

Maybe we could come up with an alternative description?

@petertseng
Copy link
Member

petertseng commented Sep 22, 2021

When we removed the language of "Write a program to do X" in #321 we considered alternatives:

  • Write a function to do X
  • Write code to do X
  • Do X

It seems that in most cases, "Do X" was used in #528 (to clarify, the verb differs based on what the exercise is; it's not literally the word "do"; often it will be "implement X", etc.)

If we were to take that approach here, then perhaps we're looking at something like...

Produce the string "Hello, World!"

It's not easy to come up with a lowest common denominator wording, that's for sure.

Here's another idea, based on the fact that (to my knowledge) we've generally agreed that stubs should be provided:

Modify the provided code so that it produces the string "Hello, World!"

@ErikSchierboom
Copy link
Member Author

Here's another idea, based on the fact that (to my knowledge) we've generally agreed that stubs should be provided:

Modify the provided code so that it produces the string "Hello, World!"

I really like this suggestion. We have indeed mandated stubs, so this fits with that nicely.

@peterloane
Copy link

peterloane commented Sep 24, 2021

Would the following wording be clearer?

Change

Modify the provided code so that it produces the string "Hello, World!"

to
Modify the provided code so that it displays the string "Hello, World!"

@glennj
Copy link
Contributor

glennj commented Sep 24, 2021

If the language wants the string returned, that's not really "displaying". "Producing" is more apropos.

@peterloane
Copy link

Yes, displaying is not an improvement.

Producing just seems a bit opaque to me here.
Would "output" be better?

Modify the provided code so that it outputs the string "Hello, World!"

@siebenschlaefer
Copy link
Contributor

siebenschlaefer commented Sep 25, 2021

Or "returns"?
[Edit: SleeplessByte is right, I didn't pay attention to the start of this discussion]

@SleeplessByte
Copy link
Member

@siebenschlaefer the point is that there are languages where it's not a function and thus there is no return (neither implicit or explicit).

@ErikSchierboom
Copy link
Member Author

"Producing" might be a bit opaque, but that is also a benefit here :)

@peterloane
Copy link

What is wanted should be as clear as possible though

'The classical introductory exercise. Just say "Hello, World!".'
but what is wanted is
'The classical introductory exercise. Just output "Hello, World!".'

@ErikSchierboom
Copy link
Member Author

but what is wanted is
'The classical introductory exercise. Just output "Hello, World!".'

I don't think this is the straightforward answer, as outputting can very easily be interpreted as: print to the console, which is not what we want.

@SleeplessByte
Copy link
Member

Perhaps: The result should be "Hello, World!", leaving it in the middle what "result" means?

@peterloane
Copy link

peterloane commented Sep 29, 2021

I don't think this is the straightforward answer, as outputting can very easily be interpreted as: print to the console, which is not what we want.

Yes, it could be interpreted as print to the console, or write to a file, or any other form of output.

But note the HelloWorld link included starts with 'A "Hello, World!" program generally is a computer program that outputs or displays the message "Hello, World!"', which is also not what is wanted then?

To avoid unwanted interpretation, the specification of what is wanted would need to be more precise I think. (Any ambiguity or opacity leaves it open to interpretation.)

If print to the console is not wanted for example, then what is it that is wanted?

@iago-lito
Copy link

Yeah, why not be explicit with something like "Return the chain 'Hello World!' or display it to the console, or write it to a file, depending on the language track." ?

@junedev
Copy link
Member

junedev commented Jan 14, 2022

It might not be perfect but I think this suggestion made above is substantially better than what we have currently so I would vote for using it for now.

Modify the provided code so that it produces the string "Hello, World!"

@ErikSchierboom
Copy link
Member Author

Anyone interested in doing a PR? 👼

@SaschaMann
Copy link
Contributor

Is this exercise still relevant? I thought it had been replaced by the Goodbye, Mars -> Hello, World exercise?

@ErikSchierboom
Copy link
Member Author

@SaschaMann That is the very same exercise :)

@ErikSchierboom
Copy link
Member Author

With https://github.com/exercism/problem-specifications/pull/1926/files merged, this can now be closed.

petertseng pushed a commit to das-g/exercism-haskell that referenced this issue Feb 27, 2023
Although function values and non-function values (and the variables
bound to them) have a lot in common in Haskell, we shouldn't call all of
them "functions".

The discussion at
https://forum.exercism.org/t/is-a-string-value-in-haskell-a-function/4034
resulted in this conclusion

exercism/problem-specifications#1850
exercism/problem-specifications#1926
petertseng pushed a commit to das-g/exercism-haskell that referenced this issue Feb 27, 2023
Although function values and non-function values (and the variables
bound to them) have a lot in common in Haskell, we shouldn't call all of
them "functions".

The discussion at
https://forum.exercism.org/t/is-a-string-value-in-haskell-a-function/4034
resulted in this conclusion

exercism/problem-specifications#1850
exercism/problem-specifications#1926
petertseng pushed a commit to exercism/haskell that referenced this issue Feb 27, 2023
Although function values and non-function values (and the variables
bound to them) have a lot in common in Haskell, we shouldn't call all of
them "functions".

The discussion at
https://forum.exercism.org/t/is-a-string-value-in-haskell-a-function/4034
resulted in this conclusion

exercism/problem-specifications#1850
exercism/problem-specifications#1926
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

9 participants