Yes it may work better, But it requires the quantity 'nubbed' to be of the Ord class, whereas standard nub doesn't.

Those are two pairs of (empty) single quotes, not one pair of double quotes surrounding a comma...

• Dashes and Underscores should both be replaced, this can be done with a fairly simple line.
  I would suggest googling " regex replace character with another". This should also
  help take care of leading and ending underscores on it's own.

• regardless of input Camel Case words should always have lowercase letters aside from first letter
  of every word starting from second word.

• This is my first post on codeWars. If I have by anychance done anything against posting convention
  please let me know.

Care to elaborate why?

This does not fulfill the requirements at all.

Yes, it's python 2. See the fork for the python 3 version.

I think the problem could be defined a bit more thoroughly.

What about strings which contain both dashes and underscores, like 'the_well-known_guy'? Even though we can safely guess that the result should be 'theWell-knownGuy', finding a consistent algorithm would be quite difficult. What about strings with a leading underscore? More importantly, what about strings which contain uppercase characters? The sample tests seem to indicate that uppercase letters in the input should be preserved, yet I managed to pass all the tests with a solution which doesn't. For example, that solution would fail on the string 'the_UK_guy', returning 'theUkGuy'.

Do note that I'm not suggesting the Kata be made more difficult, just better defined, no matter if the definition is arbitrary. As it stands, I think it's just encouraging people not to try to learn more about a problem, which is a terrible habit.

Haskell random test might be generating some weird Chars, I could not figure it out myself.

Not a kata issue then, I guess.

You're right, I'm quite surprised that I didn't check for that optimization. I haven't written Haskell in a while, but I know that at the time I loved to fiddle with things and look at the Core, to see what improvements could be made. I guess now I have no choice but to get back into it ;)

You did miss a couple of parentheses in there though. $ has really low precedence.

Also, GHC might already optimise (++) . ([]) to (:). If there should be performance problems, profiling may be a better bet than trying to be smarter than GHC.

[toUpper c] ++ (replicate i $ toLower c) is just toUpper c : replicate i $ toLower c. As the other commenter noted, there are some unecessary statements.