discussion: Making the Haskell track more interesting for beginners

[rbasso]

We have added, changed and reordered exercises, but maybe we need a more rational approach to keep the track interesting.

At the moment, we are doing a few things to try to keep more beginners going on:

• Improving the documentation.
• Moving exercises to Stack projects - This makes easier to run the tests and deal with dependencies.
• Fail-fast the tests, so that only the first failed test will be displayed.
• Adding stub solutions - To help users understand what exactly needs to be implemented.
• Move instructions to HINTS.md - It would be great if people could solve the exercises just looking at the instructions and results of the tests. Instructions do not belong to Tests.hs files of stub solutions.
• beer-song, house and food-chaincould have working stub solutions.
• Make the track more gradual - Allow beginners to solve each new exercises without having to learn too much, but always demanding a little more knowledge.
• Make the track more idiomatic - Most people come to Haskell because it's a very beautiful programming language. When they are forced to write ugly code to solve an exercise they may leave.
• Remove pointless, repetitive and boring exercises.

Some other ideas:

• Display additional test data - A failed test showing which function call failed would save the work of reading the test suite to search for the failed test case.

What do you think we could do?

[petertseng]

Remove pointless, repetitive and boring exercises.

Is it about time we deprecate binary, hexadecimal, trinary, octal?

There are at least three exercises which all involve generating a repetitive string: Do we want to keep all? food-chain, house, beer-song

[rbasso]

Is it about time we deprecate binary, hexadecimal, trinary, octal?

I was waiting for exercism/problem-specifications#279 to deprecate them, because I have no idea about how to do it correctly:

kytrinyx commented 19 days ago

FYI @rbasso @NobbZ @ErikSchierboom @wobh @Cohen-Carlisle @yurrriq

Before we can submit a blazon ticket we need to finish clarifying the process for deprecating exercises. Up until now it's been messy and prone to error, and I'd rather have that all straightened out before we deprecate four at a time across a bunch of language tracks. exercism/discussions#40

Is moving the exercises to deprecated in config.json enough? What does foregone means there? When should we use it?

There are at least three exercises which all involve generating a repetitive string: Do we want to keep all? food-chain, house, beer-song

Seems we should take a serious look at it, but before we need to answers some questions:

1. Are there more problem of the same type?
2. Do each one teach something new?
3. Do they have distinct difficulties, or they are essentially the same?

We can probably answer those questions more easily after we categorize the exercises to solve #193, but I'm not against taking a look at that now.

I remember that I was tired of those exercises by the time I reached food-chain, so I wrote a "lazy" solution 😁 :. I know that more people share the same feeling about these song generation problems.

They are about code refactoring, right? I just found this video of @kytrinyx using food-chain as an example. Taking a look at that to see if it changes my view of this kind of exercise.

[NobbZ]

As far as I understood it, the key "deprecated" is for deprecated exercises, which were used in a track but have been replaced by others, while "foregone" is for exercises which are not suitable for a track. But I think @kytrinyx can make it more clear.

[kytrinyx]

Yeah, agreed. Another way of looking at it is that deprecated means that the exercise exists, but we're not going to serve it up. foregone means that we don't want it to exist in the first place.

Also: Yes, I agree that we should be deprecating exercises that people find tedious.

I'm sorry it's taking so long for me to get to issue exercism/discussions#40 :/

[petertseng]

Well, perhaps a more pointed question: What bad things would happen if we moved binary, hexadecimal, trinary, octal to "deprecated" right now? What is stopping us?

[ErikSchierboom]

So foregone should be used for exercises that don't make sense for that language track? Will the contribute page not list foregone exercises?

I am also wondering what would happen if we just deprecated the existing binary and similar exercises.

[rbasso]

What bad things would happen if we moved binary, hexadecimal, trinary, octal to "deprecated" right now? What is stopping us?

Anyone knows that?

[kytrinyx]

Nothing terrible would happen:

1. People would not be automatically given those exercises when they say exercism fetch haskell
2. It will still show up in http://exercism.io/tracks/haskell/exercises
3. Only people who have solved the exercise previously will see it (no new people will solve, it so no new people will see it)

[rbasso]

Considering that there is no risk, I think we could deprecate the exercises now as suggested by @petertseng.

Is it about time we deprecate binary, hexadecimal, trinary, octal?

[rbasso]

Another question!

What about gigasecond? The way it is implemented, I see no pedagogical value in it:

• The solutions are almost exactly the same: fromDay = addUTCTime 10e9.
• It doesn't reflect what is in x-common.
• It seems too simple plain and boring.

We could:

• Remove it.
• Transform it in a new, harder exercise matching x-common.

What do you think?

[kytrinyx]

Considering that there is no risk, I think we could deprecate the exercises now as suggested by @petertseng.

Agreed!

What about gigasecond?

In the Go track gigasecond is a fantastic exercise. People tackle it in so many different ways, and there are myriad opportunities to talk about idioms in the language and certain language features.

I think that if it can be turned into a more interesting exercise, then that's worth doing. If not, just deprecate it.