two-fer: Consistency of the empty string

[NobbZ]

In some languages we are able to define functions with the same name and different aritys. Those languages will automatically treat hello() different to hello("").

Other languages do not have this luxury or do allow to use default values for arguments.

So in the C track I realized, the empty string is used to signal “nothing given”, while NULL might be more appropriate.

Other languages have similar (perhaps more noisy) ways to differ between an empty string and “nothing given” by Maybe or Option style types.

Therefore I wanted to start a discussion about treatement of the empty string.

1. Treat it as if we had called without a name, so we create "Hello, World!" as output
2. Treat it as proper name and return "Hello, !"
3. Leave it open to language maintainers

I tried to look up at least the tracks I already solved hello-world in:

• Different functions by arity: Erlang, Elixir
• empty string is nothing: C
• empty string is proper name: Rust (Option-type)
• testsuite is unclear about the meaning of the empty string: Scala (default mechanisms used based on NULL-references), Crystal (as Scala), Scheme (as Scala), PHP (default mechanisms based on PHP stuff I deny to delve into)

Especially in the last group, it mostly depends on the student how he implements the handling of the default value. I've seen solutions in such exercises that check default name to NULL (or similar) or "" and then do a conditional reassignment in the functions body (which in my opinion defeats the purpose of default values for argument).

Especially this wild growing stuff is in my opinion dangerous. In many tracks there are not many people who actually review, and even after hello-world is not hidden any more, many reviewers seem to just skip it.

[kytrinyx]

which in my opinion defeats the purpose of default values for argument

Agreed, if we can set a default, it should be "world", not nil or an empty string.

Also agreed that if the language can differentiate between empty string and nil, it should probably treat the empty string as a name.

In Go you could, potentially pass a pointer to a string so that you can get a nil, but the idiom is to pass a string, and if it's empty, conditionally reassign it, so in that case I would not bring up nils at all in the test suite.

[kotp]

and even after hello-world is not hidden any more, many reviewers seem to just skip it.

Since the hello-world comment from RIkki is "Usually the next step is to have a conversation about your code and iterate on your solution. ... we won't be encouraging conversations and iterations... " it seems to make sense that most reviewers would skip it, since the exercise is just a "If you can get here, you can get to the next step" kind of orientation thing.

[NobbZ]

Yeah, this automatic comment by rikki should be obseleted as well I think.

I really do appreciate rikkis style comments, but not the “ignore hello-world” comment. To be honest, it doesn't even appear for every user. Or it does appear only very late. I've even seen discussions around hello world before rikki did his “Usually the next step…”.

So either fix rikki that this comment does happen instantly and is omnipotent or remove it completely.

When we had the discussion about removing the special casing around hello-world there have been voices that there were languages where hello-world is not trivial.

Personally, I do think, that this non-triviality is true for all languages that lack one of default values for arguments or string interpolation/concatenation.

Haskell and Rust need to use an option/maybe type (only rust does have this exercise though), which in fact is a container type. In most tutorials for both of the languages those containers are about mid term.

In C currently an empty string is used to signal "nothing". Also there we do not return a string, but we use an out-parameter, and an additional parameter that tells us how many bytes we are allowed to write into the out parameter. In most C books and tutorials such stuff is covered usually late mid-term and used as a reason to continue with memory management.

In all three of this languages I'd actually prefer to leap before hello-world, if not even as the very first. It does not require anything but basic types. This is really an exercise which you can port from one language to another by just changing syntax. Maybe it is not idiomatic then, but valid. It only requires the most basic datatypes, which are handled in most tutorials and books as the very first (int and bool) as well as the most basic branching concept, the if. The next thing you need to know is how to actually define and write a function. Three basic things, covered early in nearly every programming related lecture.

As a summary, we should either remove rikkis message referenced by @kotp about hello world completely, or change it to be posted at the first exercise of a track in a more generic version. Giving the tracks maintainers back the ability to decide about an appropriate starting point for their track.

Maybe move this into just another issue? Or keep the discussion here?

[kotp]

Another solution may be to place the information into the test, informing about the purpose of the exercise, the exercise is not a 'language' exercise, but a 'getting familiar with exercism' one.

There have been conversations in HelloWorld for Ruby though, where those new to the language have questions about the implementation of even presenting a string.

I think even a non-programming exercise may be appropriate, given what I perceive as the purpose of the very first exercise, "how to exercism".

[NobbZ]

There have been conversations in HelloWorld for Ruby though, where those new to the language have questions about the implementation of even presenting a string.

As I read this, I feel even more right with my statement above, which I will summarize here as “hello-world is not a good start into most (if not any) tracks.”

Another solution may be to place the information into the test, informing about the purpose of the exercise, the exercise is not a 'language' exercise, but a 'getting familiar with exercism' one.

---

I think even a non-programming exercise may be appropriate, given what I perceive as the purpose of the very first exercise, "how to exercism".

These two are nice! I like them! 👍!

Lets try to create a complete language agnostic problem, which isn't one. Just submit an arbitrary file (README.md itself?) and continue with exercism f to get the first real exercise. And also do push hello-world to a more appropriate place which fits into that tracks learning curve.

This getting-started (working title) might get tedious for people like me, touching a complete new track every now and then.

Also, there will be really no commenting needed, since everything what rikki could comment, is already written in the README. And as there is no comment necessary, we need some specialcasing back again. Drop this submission as it comes. Just set a single boolean in the users table to remember that the user has done this once, and he will never get bothered with that exercise again, regardless of how many he starts.

But why do we do it anyway? Users do get on this site because someone already told them what exercism is, be it in person or via blog post or stuff. The new user needs to read about installing the client anyway. As I am thinking about it, every user that actively installs the CLI should already be aware of what exercism is and why he actually does download and install the CLI. Or am I living in a dreamworld and users are in fact stupid, pop into exercism by accident and do install stuff just because they are told to do without even knowing if they will ever use it?

Even an github account is needed to beeing able to join exercism. In my small world I'd assume, that only people do join who know what they are doing and why…

[kotp]

I think submitting the README file starts a precedence. If they aren't expected to do the same in the future, we should not start them off doing the unwanted.

Give a small "This would have been a program you wrote" contented file, with an appropriate for the language track extension.

Give a "Dummy Test File" such as they would expect to see with content that communicates "This test file will exist, but this one is here only for demonstration purposes...." And perhaps some note about "Submit the code file, not the test file" type of thing.

Just a practical first run, that mirrors as close as possible to what they are going to see next time. A 'damp-run' of what they will be doing, but without any coding.

[kytrinyx]

Users do get on this site because someone already told them what exercism is, be it in person or via blog post or stuff.

Up until quite recently, if you came to the exercism homepage it wasn't entirely clear what exercism is, who it's for, how it works, or why you would want to do it. It also wasn't clear how to get started. This has improved, but I think that we can improve it even further.

I think that there is value to a dry run (damp run?) that walks them through the exercism process without any mental overhead of trying to program (especially if the language and tools are unfamiliar).

I like the idea of making this language-agnostic, and also making sure that people only get this exercise once, and only if they've never, ever submitted anything solutions.

In fact, we wouldn't need metadata and language implementations, we could have the API determine that this is someone's very first time on the site, and give them that exercise.

[petertseng]

“hello-world is not a good start into most (if not any) tracks.”
Haskell and Rust need to use an option/maybe type (only rust does have this exercise though), which in fact is a container type. In most tutorials for both of the languages those containers are about mid term.

Yeah, sometimes I wonder whether that's a bad idea whether the Rust track is driving away people. See at exercism/rust#127 where @IanWhitney says "Some/None. Really? We did that in Hello World?".

I think that there is value to a dry run (damp run?) that walks them through the exercism process without any mental overhead of trying to program (especially if the language and tools are unfamiliar).

I personally would have seen value in a very minimal coding. Such as "write a function that always returns 5" or "write a function that always returns 42" and the test suite is a single test, that the function indeed returns 42.

The disadvantage of that as opposed to the language-agnostic one of course is that every track is obligated to provide their own. Considering that we're in the state where not every track has implemented hello-world, this may be a long time coming. Perhaps that may convince me that the language-agnostic one is best after all...

[rpottsoh]

Is this issue still relevant since hello-world no longer has an empty string, or should the issue be re-titled if it still has relevance, perhaps in more generic sense?

[kytrinyx]

I think we should take this into account in the discussion in #548

[petertseng]

“hello-world is not a good start into most (if not any) tracks.”

We already dealt with hello-world in #520, but it's useful for me to link to exercism/scheme#34 here, need all the information handy.

[ErikSchierboom]

If the language has a construct for an absence of a value (either via method overloads, an option/some type, or null), I think we should encourage tracks to use that and to treat any other value as a name (even the empty string). That said, I don't necessarily think we must deal with the empty string, as also indicated by the canonical data which doesn't contain an empty string.

What could be useful is to add a comment to the canonical data alerting maintainers to possible issues with empty names being pased.