Problem-specifications: I posit that hello-world is too complex for a first exercise. How do we deal with it?

[petertseng]

I learned from:

• https://github.com/exercism/xhaskell/pull/475#issuecomment-275971130
• https://github.com/exercism/todo/issues/12
• https://github.com/exercism/exercism.io/issues/2021

Hello world should be a very easy exercise. Its objectives:

• Demonstrates to the student that theirexercism fetch and exercism submit are working (NB, this could be a language-agnostic exercise, but it is not clear where we would put it)
• Explain to the student how to run the test suite in the language
  
  
  
  • it's up to each track to provide this in their track-specific documentation e.g. https://github.com/exercism/xruby/blob/master/docs/TESTS.md
  
  
  • this role doesn't have to be filled by hello-world, but some students prefer to have the separate exercise dedicated only to making sure this step is solid before moving on. Those who don't care can skip it.
  
  
• Introduce the student to how TDD works
  
  
  
  • shown by https://github.com/exercism/x-common/blob/master/exercises/hello-world/description.md
  
  
  • shown by the process of getting the tests to pass
  
  

I am here to argue that the current hello-world ("Alice" -> "Hello, Alice!", "Bob" -> "Hello, Bob!", no input -> "Hello, World!") does not serve this purpose well, since it also requires the student to know enough about the language to handle the no-input case.

This effect is especially pronounced in languages that do not allow function overloading or default arguments. Some languages resort to passing an empty string, defining two functions, or others discussed in #290. Elm, F#, Haskell, Kotlin, OCaml, Purescript, and Rust are all using their Option/Maybe type, which I argue is not suitable for hello-world (In Learn You A Haskell, Maybe is not mentioned until chapter 7 of 14). But even in languages with function overloading or default arguments, I suggest that these two features are too much for hello-world.

I would say that the best way to achieve the goal of hello-world is to have the function-under-test take zero arguments and return "Hello, World!" unconditionally.

But what can we do? The current hello-world is already out there, and several languages have it.

1. If we change the hello-world README to unequivocally state that the function should return "Hello, World!" unconditionally, then all languages that currently have hello-world will be inconsistent with the README. Is that okay?
2. If we change the hello-world README to be so vague that either interpretation is possible (the current interpretation, or unconditional "Hello, world"), languages can do as they wish, but it is a delicate balance to strike - we have seen before in https://github.com/exercism/exercism.io/issues/2746, an underspecified problem is also undesirable.
3. What if we left hello-world as-is, and made a new exercise, the-answer, whose only function-under-test should return 42 unconditionally. Then, languages can do whichever of the two they please. The only disadvantage is that it will be confusing to track maintainers and exercise porters to have two starter exercises.
4. Maybe you disagree with my proposal: Maybe you think students can be expected to have some minimum level of knowledge upon starting the track. Or you think my proposal is rather too simple. Let me know about it!

[rbasso]

👍 for option 1: Change it to just "Hello, World!!

The purpose of a Hello, World! exercise seems to be, IMHO, just testing the tool-chain. Anything beyond returning/outputting the string makes it less suitable to that purpose.

Also, the hello-world name is so clear in explaining its purpose that it would be a shame to create another exercise as the first one.

[Insti]

Hello world should be a very easy exercise. Its objectives:
...
Introduce the student to how TDD works

I think this is out of scope for hello world, leaving just the first two.

the best way to achieve the goal of hello-world is to have the function-under-test take zero arguments and return "Hello, World!" unconditionally.

:100:

What to do:

1. Rename the current hello-world to greeter add a new hello-world that just says "Hello world." (There will be some challenges around this, but they are not insurmountable.)

2. Create a new first exercise called exercism-works that returns "Exercism works!" (This is similar to suggestion 3, but non-optional.)

[petertseng]

I would find it so great if I could change the existing hello-world README and let the various tracks converge on it, maybe emblazon them. Avoids any confusing operations with having a second starter exercise, or moving hello-world -> greeter (now if I look at a track that has hello-world, how can I tell whether it is the new or old hello world?)

We've done this process once or twice before. We discussed how to handle it in https://github.com/exercism/discussions/issues/2. Maybe it's time to revisit this. I asked tracks to change their sum-of-multiples last April. I marked in the README that there's a change in flight, and let all readers know, if you see a track is using the old version, help us fix it. That was done in #236.

If we get agreement that hello-world should be simplified (I confess, I was thinking I would get more opposition!), how about taking that plan?

On the other hand, hello-world is a bit of a special case since it's the very first experience of a track. If the first experience seems weird and inconsistent in this manner, it may confuse a student who is just trying to get started. We would have to be very careful in applying this plan.

---

One thing that gives me pause is - I may be getting ahead of myself.

It is absolutely true that hello-world in its current form would not be a good first exercise for Haskell (and, I argue, every other option/maybe track, but I couldn't know for sure!). For Haskell, the unconditional hello world is the right thing to do.

But then I wonder, is it too presumptuous to claim that it's the right thing for all tracks? Maybe they're perfectly happy with their hello-world in its current form, and do not want a change.

This is actually a time when I wish we could survey students to see what they think. Would they have appreciated this new simple hello world? Any patterns among the tracks that have harder hello-world exercises?

I try to advocate for changes that I have very good reason to think are better, but especially given that this change tries to better an onboarding experience, wouldn't it be great if there was any data at all to back it up?

[Theodus]

I agree that the current hello-world is too complicated in some languages considering its purpose. However, this is not the case for all languages. I can say for certain that the exercise in its current form is solved fairly easily with the use of default arguments in languages such as Pony and Kotlin.

[rbasso]

(...) I can say for certain that the exercise in its current form is solved fairly easily with the use of default arguments in languages such as Pony and Kotlin.

I believe that the question is not "Is is too hard?", @Theodus, but "Could it be easier?"

In my view, it should be ridiculously easy to solve it, and I would even supply a stub solution like this:

module HelloWorld (hello) where

hello :: String
hello = "Goodbye, World!"

But then I wonder, is it too presumptuous to claim that it's the right thing for all tracks? Maybe they're perfectly happy with their hello-world in its current form, and do not want a change.

This discussion may have started because it is hard for beginners to deal with optional argument in Haskell, @petertseng, and certainly changes are temporary inconveniences for tracks that already have it implemented, but the rationale is sound and there is still no one defending the usefulness of having it more difficult than it needs to be.

If someone comes with a good reason to keep the optional argument, of course we could leave it the way it is. Anyone?

[ErikSchierboom]

I'm also firmly in favor op option 1. The exercise should not be about specific language features in my opinion (no matter how simple), but only about getting to know the track's setup. How do I run the test? What is a red test? How do I get it to pass?

Sure, some languages have easy ways to do optional values, but is that really the first thing you expect people to learn? I don't think so.

[ijanos]

I prefer option 1. Hello World should be as simple as it gets. I think languages with easy option types could have a "Hello World+" language specific exercise with option types baked in.

[petertseng]

There was more support for option 1 than I thought there would be! I will leave for a while longer before I take action in x-common, but I think I will prepare a few PRs those tracks on which I'm a maintainer.

[rpottsoh]

Why not keep the exercise as is except call it something else? Is there nothing that can't be learned from the exercise in its present form? At the same time I am also for having hello-world be more of test/confirmation exercise to help the student realize that they have setup the tools correctly for a particular track.

[petertseng]

Why not keep the exercise as is except call it something else?
Is there nothing that can't be learned from the exercise in its present form?

Indeed, the current hello-world could become greeter, or maybe the niche is already filled by any other problem wherein a function may optionally take an argument - can we get a check on whether there is any other exercise that does the same?

[rbasso]

greeter would be a good introduction to Maybe in Haskell, before its use in a more complex context.

[ErikSchierboom]

Keeping the existing exercise as a new exercise does have its advantages, as it gently introduces optional values. But if our new hello-world exercise would simply return "Hello, World!", wouldn't the greeter exercise be a bit too similar?

[rbasso]

You're right, @ErikSchierboom. It would be better to have something less repetitive. 👍

[ErikSchierboom]

Perhaps we can come up with another exercise which sole focus is optional values?

[rbasso]

It would be nice, but I usually prefer to tweak a existing one and avoid the proliferation of language-specific exercises. We could easily write dozens of exercises to cover Haskell topics, but I'm not sure if this would be good for Exercism as a whole.

[ErikSchierboom]

Well, actually I do think that this would be a good subject, as many languages have their own concept of optional values and how to deal with it.

[petertseng]

Hmm. Those tracks that use hello-world as an intro to TDD (as well as exercism), such as https://github.com/exercism/xkotlin/pull/31 and https://github.com/exercism/xjava/blob/master/exercises/hello-world/TUTORIAL.md (https://github.com/exercism/xjava/pull/139), are going to be in for a rude awakening. I wonder how to reconcile the differences between those tracks that want to use the directed introduction and those that want something dead simple.

[ErikSchierboom]

I think that our message to them would be to perhaps see if they can move the TDD intro to the next exercise (which I would suggest would be leap). The leap exercise is well-suited for a TDD intro I believe, as you can start with a simple base test case, and then subsequently start adding the corner conditions. As such, it's even better suited to a TDD intro than hello-world IMHO.

[rbasso]

So...are we settled about changing the hello-world's description.md file?

To proceed, I think we should, ideally...

• [x] Agree that this should be done.
• [x] Write the PR.
• [ ] Decide on a date/time for merging. 2016-02-20 00:00 UTC?
• [x] Notify all the maintainers about the change and the date.

With that, the tracks could approximately sync their changes if they want to.

Makes sense?

[ErikSchierboom]

Absolutely!

[rbasso]

I just opened the PR and mentioned all the track maintainers there to raise awareness. This will probably allow us to discover if there is anyone against it soon.

I temporarily set the date to 2016-02-20, but we can change it or suspend the process anytime.

[rbasso]

To make it more visible, I'll copy here the link for a HINTS.md file that contains the TDD instructions from exercism/x-common/exercises/hello-world/description.md that will be removed from the exercise.

Tracks that already have implemented the hello-world can use it or merge it to the HINTS.md in the second exercise.

[kytrinyx]

I just wanted to pop in here to say that I completely agree with this, and that I'd like to have an exercise that mimics the old complexity of hello-world. I've put my reasoning in a new issue, since this should not in any way block this effort: https://github.com/exercism/x-common/issues/548

[jtigger]

TL;DR: I strongly disagree with this move: for Early Programmers, hello-world is apparently approachable, as is. I propose that: we leave hello-world, as is; and the Haskell track include a HINTS.md and/or other supports that ease the learning of the exercise.

---

@petertseng said:

Hmm. Those tracks that use hello-world as an intro to TDD (as well as exercism), such as https://github.com/exercism/xkotlin/pull/31 and https://github.com/exercism/xjava/blob/master/exercises/hello-world/TUTORIAL.md (https://github.com/exercism/xjava/pull/139), are going to be in for a rude awakening. I wonder how to reconcile the differences between those tracks that want to use the directed introduction and those that want something dead simple.

Yeah, rude awakening was right! 😮 I literally woke up this morning and was pointed to this discussion by a fellow maintainer. I missed this discussion when it first kicked off.

I spent days writing both the Java and Kotlin tutorials around the hello-world exercises. 🌞 Days. 🌞 Getting the wording right, trimming and highlighting code snippets, walking through the flow ensuring it all works exactly as described... that all takes time and tenacity. I just finished the Kotlin version... merged in 6 days ago. They are here and here.

... and it's not just that a bunch of hard work is about to be flushed. It's that these tutorials were a first (presumably solid) step toward creating engagement with practitioners as they start on the track. I had checked that box off in my head. This idea of rewriting hello-world feels like a full step back in that effort.

So how objective is _my_ input to this discussion?!?! 😀 I clearly have a sunk-cost fallacy running strong. 😜

... fully acknowledging that bias...

I'm (also) concerned that we're moving on a change based on speculation instead of responding to a realized problem.

• the genesis of this idea is _not_ a response to a persistent complaint from actual users, but that hello-world presents with some difficulty in Haskell. Discussion at exercism/xhaskell#475. Who is the audience of the first exercise of the Haskell track? Would you seriously suggest someone new-to-programming to start with Haskell? I wouldn't.
• In fact, there are 1000+ submissions hello-world every month across Exercism (see and explore http://exercism.io/stats/javascript).
• AFAIK, we aren't been aiming to be an introduction to programming. During a User Research effort, last year, @kytrinyx coined the least-experienced of our three cohorts as the "Early Programmer" — someone for whom Exercism submissions are _not_ their first programs.
• I _have_ seen people struggle with hello-world ... those folks were definitely out of their depth. I think we did them a service by suggesting they hit a tutorial on programming and come back when they've got their legs under them.

I propose:

1. hello-world remain unchanged and the (desired) universal first exercise.
2. The Haskell track includes prompts or sufficient starter code that alleviates the curve for the first exercise.

[NobbZ]

Would you seriously suggest someone new-to-programming to start with
Haskell? I wouldn't

But me would as well as the university I'm studying at.

Since 2010 haskell is taught in the first semester. And experience has
shown that people just beeing introduced into programming have much less
trouble to get it than those people who's minds are already polluted by
other paradigms.

And even for people that are not new to programming but totally new to adt
and pattern matches can be totally confused by that maybe.

In c and other languages we do not have default values at all but do
unidiomatic stuff using null pointers/references or an empty string...

I am totally for changing this. Just do greeter as second exercise then..,

John Ryan [e-mail] schrieb am Mo., 13. Feb. 2017, 16:11:

TL;DR: I strongly disagree with this move: for Early Programmers,
hello-world is apparently approachable, as is. I propose that: we leave
hello-world, as is; and the Haskell track include a HINTS.md and/or other

supports that ease the learning of the exercise.

@petertseng https://github.com/petertseng said:

Hmm. Those tracks that use hello-world as an intro to TDD (as well as
exercism), such as exercism/xkotlin#31
https://github.com/exercism/xkotlin/pull/31 and
https://github.com/exercism/xjava/blob/master/exercises/hello-world/TUTORIAL.md
(exercism/xjava#139 https://github.com/exercism/xjava/pull/139), are
going to be in for a rude awakening. I wonder how to reconcile the
differences between those tracks that want to use the directed introduction
and those that want something dead simple.

Yeah, rude awakening was right! 😮 I literally woke up this morning and
was pointed to this discussion by a fellow maintainer. I missed this
discussion when it first kicked off.

I spent days writing both the Java and Kotlin tutorials around the
hello-world exercises. 🌞 Days. 🌞 Getting the wording right, trimming
and highlighting code snippets, walking through the flow ensuring it all
works exactly as described... that all takes time and tenacity. I just
finished the Kotlin version... merged in 6 days ago. They are here
https://github.com/exercism/xjava/blob/master/exercises/hello-world/TUTORIAL.md
and here
https://github.com/exercism/xkotlin/blob/master/exercises/hello-world/TUTORIAL.md
.

... and it's not just that a bunch of hard work is about to be flushed.
It's that these tutorials were a first (presumably solid) step toward
creating engagement with practitioners as they start on the track. I had
checked that box off in my head. This idea of rewriting hello-world feels
like a full step back in that effort.

So how objective is my input to this discussion?!?! 😀 I clearly have a
sunk-cost fallacy running strong. 😜

... fully acknowledging that bias...

I'm (also) concerned that we're moving on a change based on speculation
instead of responding to a realized problem.

• the genesis of this idea is not a response to a persistent
  complaint from actual users, but that hello-world presents with some
  difficulty in Haskell. Discussion at exercism/xhaskell#475
  https://github.com/exercism/xhaskell/pull/475. Who is the audience
  of the first exercise of the Haskell track? Would you seriously suggest
  someone new-to-programming to start with Haskell? I wouldn't.
• In fact, there are 1000+ submissions hello-world every month across
  Exercism (see and explore http://exercism.io/stats/javascript).
• AFAIK, we aren't been aiming to be an introduction to programming.
  During a User Research effort, last year, @kytrinyx
  https://github.com/kytrinyx coined the least-experienced of our
  three cohorts as the "Early Programmer" — someone for whom Exercism
  submissions are not their first programs.
• I have seen people struggle with hello-world ... those folks were
  definitely out of their depth. I think we did them a service by suggesting
  they hit a tutorial on programming and come back when they've got their
  legs under them.

I propose:

1. hello-world remain unchanged and the (desired) universal first
   exercise.
2. The Haskell track includes prompts or sufficient starter code that
   alleviates the curve for the first exercise.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/exercism/x-common/issues/520#issuecomment-279419200,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADmR6PB-lWyGSy4UgjulKtmpWkZArvTks5rcHKugaJpZM4LxD9b
.

[rbasso]

Considering that I'm the one that opened the PR and mentioned all the maintainers, I think I should at least comment part or your comments, @jtigger:

Yeah, rude awakening was right! 😮 I literally woke up this morning and was pointed to this discussion by a fellow maintainer. I missed this discussion when it first kicked off.

Sorry for that! After a while without anyone strongly opposing the idea, I opened the PR and mentioned the maintainers to avoid anyone being surprised.

... and it's not just that a bunch of hard work is about to be flushed. It's that these tutorials were a first (presumably solid) step toward creating engagement with practitioners as they start on the track.

I recognize that creating a good introduction to the track is really important, and no one expects you to throw away all the work you did.

It was suggested here that a solution would be to rename the current hello-word to greeter, and that was also proposed by @NobbZ in #548, which @kytrinyx opened to fill the gap left by this proposed change.

So how objective is my input to this discussion?!?! 😀 I clearly have a sunk-cost fallacy running strong. 😜

... fully acknowledging that bias...

I feel your pain...I just closed this pull request after spending a lot of time raising that child... 😢

I'm (also) concerned that we're moving on a change based on speculation instead of responding to a realized problem.

• the genesis of this idea is not a response to a persistent complaint from actual users, but that hello-world presents with some difficulty in Haskell. Discussion at exercism/xhaskell#475.

Yes, the discussion started in exercism/xhaskell#475, which did not yet implemented the exercise.

After @ErikSchierboom opened the PR we understood that, the way the description.md is, hello-world couldn't be the first exercise of the Haskell track, so we suspended merging it and @petertseng opened this issue.

Who is the audience of the first exercise of the Haskell track? Would you seriously suggest someone new-to-programming to start with Haskell? I wouldn't.

I completely agree with you! Haskell is probably not a good language for beginners.

This discussion may have started in the Haskell track, but I think it has little to do with it.

The main argument is that a hello-world should neither be a common exercise nor a introduction to TDD. It should be a sanity-check that the tooling is OK.

Question: Would that benefit the Haskell track?

Answer: Probably a little. Certainly not enough for us to engage in all the trouble of changing the exercise in x-common.

If people interested in the Haskell track is discussing here, consider that maybe they believe this change makes sense and may be good to most of the tracks.

I propose:

1. hello-world remain unchanged and the (desired) universal first exercise.
   
   
   
   1. The Haskell track includes prompts or sufficient starter code that alleviates the curve for the first exercise.
   
   

A hello-world exercise could be nice in the Haskell track, but we don't really need it.

That said, other people seem to support this change...

[ErikSchierboom]

And I am one of them. As a first exercise, having to deal with optional values is far from ideal I think. There is an added complexity of having to understand null/optional values that I think should not be part of the first exercise (nor the second I think). I thus completely agree with the above statement:

The main argument is that a hello-world should neither be a common exercise nor a introduction to TDD. It should be a sanity-check that the tooling is OK.

It is very unfortunate that you spent some much time on the wording and implementation of these exercises, but I still feel this is the right thing to do.

[petertseng]

@NobbZ says:

polluted by other paradigms

While English is not my first language (and I think you have said before it neither is yours), I want to point out that because of the connotation of "pollute", I read this as dangerously close to a value judgment of paradigms, regardless of whether you intended it to be such.

I will argue later in this message that I would not like to make this about language paradigms.

---

@jtigger says:

rude awakening was right!

I should have pointed you to this discussion as soon as I noticed the Java and Kotlin tracks' tutorials. Given your significant work on this aspect of the on-boarding experience, your opinion is important. I should have sought it early on. Given that I started this discussion and failed to find you despite being aware for days, the blame is on me for that.

I spent days writing both the Java and Kotlin tutorials around the hello-world exercises.

I will remark that there comes a point in almost every open-source maintainer's lifetime where it becomes necessary to say "no" to someone who said "I worked really hard on this, you have to accept my patch".

On the other hand, we are not quite in this same situation. If this proposal were implemented, not all the work would have to be thrown away.

But then again, significant extra work would have to be done, and especially the most by the Java and Kotlin tracks. And this is why the status quo is comfy: Nobody has to do any work. So the burden is on the proposers to demonstrate that the work is worth it.

It's that these tutorials were a first (presumably solid) step toward creating engagement with practitioners as they start on the track.

This is a very important point, and is in fact the point on which we are heading toward the same goal - we want to make the on-boarding experience great.

we're moving on a change based on speculation
the genesis of this idea is not a response to a persistent complaint from actual users

Exactly why I got cold feet. It would have been great if there were surveys, as https://github.com/exercism/discussions/issues/86 suggests.

In fact, I worried that after a redesign that we would have to redo hello-world a second time, even after this change!

Without feedback from the students, I am forced to admit it:
Any action (or non-action) I try to make toward a better on-boarding experience can rightfully be called out as shooting in the dark. The best I can try to do is make an educated guess that the shot in the dark is in generally the right direction. I am speculating that whatever is finally decided would have been approximately in this direction, so that this hello-world change will be a good move in the meantime while waiting for it. It is speculation, and the best way I could think of to evaluate the speculation was to propose the change and see whether it has support.

Who is the audience of the first exercise of the Haskell track?
AFAIK, we aren't been aiming to be an introduction to programming.

It would be good to get clarity on this point, for every track. For now, my assumption will only be that the audience of the first exercise of track L is someone new to language L. This ties in with both the Early Programmer cohort and the Polyglot cohort (the first two listed cohorts on the http://exercism.io/ homepage).

I believe the hello-world proposal is applicable even with only this assumption! I will not ask that someone new to a language learn optional values as the first thing in that language. I was hoping that other languages find analogous reasons.

An assumption that the audience is someone new to Exercism might be helpful and give the proposal more weight, but I say the proposal still makes sense without it.

1. hello-world remain unchanged and the (desired) universal first exercise.
2. The Haskell track includes prompts or sufficient starter code that alleviates the curve for the first exercise.

At this point, I need to break character and talk about specific tracks.

I would say that specifically for all tracks that would (or do) use Maybe/Option to comply with the current README, hello-world is not a suitable first exercise. Further I posit that this unsuitability is difficult to solve with prompts or starter code since it would have to take one of two forms:

1. Go to great lengths to guide the student through a concept that we would rather save for later, making an unnatural introduction to the language.
2. Not use the concept at all, contradicting the README. This indicates disharmony in the world. Thus, I suggested to change the README so that there is no disharmony.

It's admitted by me that of the 40 tracks implementing hello world, only a minority (Elm, F#, Haskell, OCaml, Purescript, and Rust make for 6 tracks out of 40) do (or would) use Maybe/Option.

The other 34 tracks might be okay with this the status quo, as default arguments to functions might not be as big of an ask. Nevertheless, I tried to make the case that this change is desirable for all tracks: It better fits the stated goals of the hello-world exercise.

Really, it would be good if the README allowed for both possibilities (unconditional Hello World, or status quo), but my first attempt in #519 was deemed insufficient, and I found it very tricky to get it right, neither overspecifying nor underspecifying.

hello-world presents with some difficulty in Haskell

Notice that while this issue was sparked by an attempt to add hello-world to the Haskell track, as I said earlier I tried to frame the argument to be more widely applicable. I listed the five other tracks that might care particularly strongly (since they already use Option/Maybe in hello-world). Further, I tried to expand from those six tracks to make it instead an argument that applies to all tracks: that hello-world should do one thing and do it well.

The fact that despite my efforts the Haskell track was still called out implies that I have failed to divorce this argument from the Haskell track. All right. This is unavoidable: I can give reasons why others might care, but I can't make them care.

But even if I fail on this front, I will still ask that this issue (all issues) avoid becoming a "my track vs your track" affair. Is this issue close to becoming that? I don't know for certain, but it's important enough to me that I will call out this risk now, in attempt to snuff it out, even if the risk is only imagined.

---

At the end of the day it does not much matter to me what form hello-world finally takes, but I know that in its current form I will recommend that the Haskell track not add it, and will recommend that the other five tracks with Maybe/Option remove it. Of course they do not have to take the recommendation, but it is there.

This means that I do not object in any way to hello-world in its current form.

What I do strongly object to is (hello-world in its current form and hello-world being the universal first exercise). The proposal to change hello-world represented an attempt to resolve that objection via the first part of the conjunction, but ultimately I can also be satisfied by resolving the second part.

Which way of resolving it is better? If changing hello-world has support and no detractors, then I am all for that, since I think this fits better with the previously-stated goals of hello-world. If, however, I have misunderstood the goals of hello-world and/or we think the goals should be changed, let's get the proper goals down in writing, and then we can evaluate whether it is suitable as a universal first exercise.

[NobbZ]

I want to point out that because of the connotation of "pollute", I read this as dangerously close to a value judgment of paradigms, regardless of whether you intended it to be such.

I do understand what you are about to say here and I do understand your concerns. Therefore let me try to explain how it was meant to be read with some analogon from my real life:

In the room of my son there are about a thousand different toys, none of them is bad, but they are cluttered all over the floor, "polluting" the room, so he doesn't what to play with first. This is when me and my wife chime in and we clean up the room together.

Someone whos mindset is already "poluted" by other paradigms, might have problems to learn a new one or to choose the right one. There are no parents helping most of the time, and even if one used to switching paradigms it involves some mental overhead to switch from one to another. I do have that problem everyday when I switch from go in the job to haskell during commuting and elixir, erlang and some LFE at home (if not family bound).

[jtigger]

@petertseng, thank you for your in-depth and thoughtful response ... and for carefully unpacking the situation and addressing how this discussion unfolded.

I should have pointed you to this discussion as soon as I noticed the Java and Kotlin tracks' tutorials. Given your significant work on this aspect of the on-boarding experience, your opinion is important. I should have sought it early on. Given that I started this discussion and failed to find you despite being aware for days, the blame is on me for that.

I appreciate your reflecting on the experience and thinking through how communication can be improved. 🙏 While It's very neighborly and builds community to think about including folks in a given discussion, each maintainer is responsible for staying informed about the goings-on within the curriculum community.

Notice that while this issue was sparked by an attempt to add hello-world to the Haskell track, as I said earlier I tried to frame the argument to be more widely applicable. I listed the five other tracks that might care particularly strongly (since they already use Option/Maybe in hello-world). Further, I tried to expand from those six tracks to make it instead an argument that applies to all tracks: that hello-world should do one thing and do it well.

Yeah, somehow I totally missed the deeper point: that there's a class of languages for which this is a challenge. And then it clicked for me: hello-world, as the first, is really special for all the reasons others have stated: that it's really a tooling check.

Having had a chance to reflect, myself, I see the common ground (which far outweighs whatever prior efforts):

1. As a matter of long-standing tradition in our craft and as a clear expression of cohesion across the platform, hello-world ought to be the first exercise of each and every track.
2. For all the reasons stated clearly by others, hello-world should also be the _simplest_ exercise in each and every track.

I now understand that if we can't achieve these goals for _all_ tracks, we need to rewrite this exercise. As written, hello-world is not/would not be the simplest exercise for some tracks.

I'm down with option 1.

[kytrinyx]

@jtigger I proposed in https://github.com/exercism/x-common/issues/548 that we create an exercise that is equivalent to hello-world which could be used as the second exercise in the tracks where that would make sense. If we do that, then all of the work that went into the tutorials for Java and Kotlin could still be used (with a copy/place for the text), right?

[ErikSchierboom]

@kytrinyx I think so. It would be a great idea IMHO to have an exercise that focuses solely on null/optional values.

[jtigger]

Yes, if the outcome of #548 is renaming the exercise, it would be simple to adjust that work with minor edits. :)