Divide Basic Acronym and Advanced Acronym

[emcoding]

1) We are short on really easy exercises 2) The easy exercises we do have, tend to get more complex over time because of added tests for edge cases 3) There are several proposals (open and closed, implemented and not) to add cases to the current Acronym 4) Adding one or two more tests will not provide a powerful Acronymizer; that needs a more thorough analysis (especially of establishing a limit of how powerful we'd like such an advanced Acronymizer to be.) 5) Exercism is not meant primarily for practising with regex

=> Proposal: 1) Keeping the current Acronym as simple as possible, such that 'splitting on spaces' will not do, but not pretending that we're offering a real solution for creating Acronyms. 2) Create a new, advanced Acronym, that catches a much broader range of edge cases.

It would be another series of exercises, like the recently introduced Resistor series, with advancing complexity.

[iHiD]

This is part of a bigger conversation about the learning purpose of exercises and the learning purpose of tests. Previously, exercise's didn't have learning purposes and nor did tests, they were purely interesting problems to solve.

I think the key thing is defining what each exercism aims to achieve from a learning POV, and effectively writing a "learning" spec for it. Each test can then be cross-referenced with that spec to see whether the test adds clarity or complexity to an exercise.

I think the same should be true of adding exercises as well. If we want to add a more complex acronym, then we have to answer the question of "why do we want to add it?" in the context of what someone is learning or practicing.

For clarity, I'm not in any way against complex or multi-dimensional exercises, but I feel that they shouldn't be on the core track, and that that should sort of be encoded into their spec.

[iHiD]

Also, FWIW I've mentored a lot of Acroynm's on Ruby and not had a single situation where the learner hasn't been able to get to the optimal solution and learn some stuff along the way. The key to that is providing them with the regexp (which I always do if they've not got it on their first go) because that opens up their eyes to lots of possibilities. I've found that exercise to be good for teaching block shorthand in Ruby (map(&:upcase) rather than .map{|x|x.upcase}), for introducing scan and then for loads of general Rubyisms. I feel like it's been a great exercise to teach idioms - but I don't use it to teach Regexp and I don't feel like that's the point of it.

[kytrinyx]

If people want to learn Regexp I'd rather they use https://regexcrossword.com/ than Exercism. If we have exercises that only seem useful with regexen, then I think it's worth considering deprecating them, or leaving them as a side exercise and pointing people to regexcrossword.

[emcoding]

Aha, but I think there is an interesting exercise hidden in a more advanced Acronym - but not by adding randomly more characters to tests to build up to a more complex regex . My thinking was that an advanced Acronym would require a different approach, and that would be interesting.

In regard to the simple/current Acronym: I'm not against having a simple regex in an exercise, as long as it's a means to a goal (in Acronym: by giving the regex away for free, students discover how choosing a different method can improve their code dramatically).

But yeah, maybe a series is not such a good idea. Another option would be to have a Simple Acronym and a Power Acronym, so that tracks can choose which one fits best.

[kytrinyx]

@F3PiX rather than have two acronym exercises, I'd like to explore what the two different core things that people are learning or practicing are, and then see if we can come up with a new exercise that addresses one of them. I think it would make sense to keep the current Acronym as simple as possible, as you suggest. What is it about the more powerful one that is interesting, do you think?

[macta]

I agree with the original premise - It seems rather sad that an early (and quite fun) exercise has to dip into regex. Its interesting that some languages treat characters as objects and I think you learn a lot from that without jumping straight to regex (or at least complicated regex):

e.g.

words := aString splitOn: [ :char | (char isAlphaNumeric or: [ char = $' ]) not].
^ String
    streamContents: [ :stream | 
            words
                reject: [ :word | word isEmpty ]
                thenDo: [ :word | stream nextPut: word first uppercase ] ]