Add Acronym Exercise

[lpalma]

Port Acronym to the Haskell Track.

As always, happy to receive feedback :-)

[petertseng]

Nice job on the example implementation! Thanks.

[petertseng]

if this one gets String Manipulation, should any other exercise that deals with String get this topic too?

For solving #274 I only included topics that will affect ordering decisions in #476 .

Do you propose that string manipulation affects ordering decisions, and if so can you help find the other exercises that have it so they can be labeled properly too? If a topic appears in this file, it is advantageous for it to appear on all exercises that have that topic, otherwise we don't get the full picture when making ordering decisions.

[lpalma]

I noticed #274 (comment) mentions String instead of String Manipulation, I'm ok with either term.

The only problem I see with this topic affecting ordering decision is the breadth of difficulty that it might include.

For instance, taken from #274 (comment), we know Maybe, ADT, Either and IO Monads require enough understanding so that it can be used for ordering the exercises. But take a few String related exercises:

• Bob: 1
• Pangram: 1
• Run Length Encoding: 1
• Acronym: 2
• Beer song: 3
• Anagram: 4
• Ocr Numbers: 5
• Pig Latin: 6

They are all related to String Manipulation, but don't have any other subtopic (except for Beer Song, which includes Refactoring, although I'm not sure if I agree). Still, they have fairly different levels of difficulty. Perhaps there are more underlying topics that we haven't discovered yet, but currently they can't rely only on String to be ordered.

That said, do we have a clear/fixed way to order the exercises based on their topics? For example:

• Sort by most difficult topic (likely the current approach); or
• Assign a weight to each topic and sort the exercises by the sum of their weight.

[petertseng]

breadth of difficulty
Perhaps there are more underlying topics that we haven't discovered yet, but currently they can't rely only on String to be ordered.

Indeed, maybe we will have to think of a more precise topic.

That said, do we have a clear/fixed way to order the exercises based on their topics?

I can't really say the current system is clear at all, really. Surely the hardest topic is important, but there's no mapping of topics to numbers nor is there a rule for whether any additional topics would or would not make an exercise harder. They're just guesses. They could be wrong.

[lpalma]

I was thinking whether we could find a way to classify exercises based on student feedback.
I'm gonna give a suggestion here first because you have far more experience with Exercism than I do, so you may be aware of reasons for this idea to not work.

Say, for instance, the student could rate the exercise in the submission page. We could ask for feedback in two opportunities:

1. In the submission page, the User finds an option to rate the difficulty of the exercise; or
2. Upon archiving the exercise, the User is prompted with a request to rate the difficulty exercise.

I favour option 1 due to many Users (including me) not archiving their exercises.

Then, we could use their feedback to help us sort the exercises on a given period (say, once every 2 months).
Certainly, there is a high degree of subjectivity with this system. A Student already familiar with the Language could rate an exercise Very Easy, while beginners would rate it Hard. Therefore, maybe we could set some sort of threshold. For example, if we get more than 40% of the feedback suggesting the Exercise is far off the current level, than we should reorder it.

This system could also help us improve Exercism in more than one way, for example:

1. Discover what topics the students are having more difficulty in a Track, then try to add more exercises on that topic;
2. Find holes in a Track, such as students finding an exercise much more difficult than the previous one, so that we can add more exercises in between.
3. Find overloaded topics, such as students rating successive exercises easier, which could mean we are adding too many exercises on that topic, causing students to get bored.

I apologise for often giving such big comments/replies, I hope they are constructive to Exercism in some way :-)

[petertseng]

based on student feedback.

It's a good idea. exercism/discussions#92 and exercism/discussions#86 might have some useful information.

1. In the submission page, the User finds an option to rate the difficulty of the exercise; or
2. Upon archiving the exercise, the User is prompted with a request to rate the difficulty exercise.

I favour option 1 due to many Users (including me) not archiving their exercises.

Same. There are many I don't archive because I deem that feedback would always be welcome on it.

A Student already familiar with the Language could rate an exercise Very Easy, while beginners would rate it Hard

We may be able to adjust for it if we let students declare familiarity with the language:

• Allow declaration of language mastery. exercism#2164
• Self-rank proficiency/years exp in a language (for others to see) exercism#2594
• Allow users to self-identify themselves as newbies, experts, etc. discussions#16

too many exercises on that topic, causing students to get bored.

I see it is a track-specific version of exercism/problem-specifications#326

I apologise for often giving such big comments/replies

One could argue that my response is either too short and doesn't give the consideration deserved, or that it is too long if one includes all the text in everything I linked to as part of my answer.

I think the suggestions are good, so there is no need to apologise. And the links should show there are others interested in the same, so there are places to add your voice and get more people interested. These would benefit all language tracks of Exercism!

[petertseng]

same q as #511 (comment) - same across all exercises, or allow to be different?

[petertseng]

same q as #511 (comment) - how should we put the version in here?

[petertseng]

As you can see, we'll defer on String since we can always add it later. Everything we're discussing in #514 (comment) is still valid of course.