Euler Decision No. 31 at Haskell

Question

I compared my solution to the one published on haskell.org http://www.haskell.org/haskellwiki/Euler_problems/31_to_40 and I don’t know what to think about it. Is this what I wrote so non-idiomatically that the average haskell developer immediately catapulted my code to the moon?

main = print $ length $ split 200 split n = split' [200, 100, 50, 20, 10, 5, 2, 1] n where split' (1:[]) n = [take n $ repeat 1] split' (c:cs) n | n > c = map (c:) (split' (c:cs) (n - c)) ++ split' cs n | n == c = [[c]] ++ split' cs n | otherwise = split' cs n 

Starting with the development of "enterpriseisey", I seem to appreciate direct and dumb solutions, but, on the other hand, maybe everyone can read single-line lines just fine, and I just need to pick up my game? Would you recommend code compaction as an exercise, or is it just for hackers?

Answer 1

As a rule, you can say that if there is a chance that others will read the code you write, you should remain painstakingly describing each last step in your code, even if it means that you need to write ten more lines than a quick and funky solution.

If you write code only for yourself, then you can do whatever you want, but you need to remember that you probably would like to understand the code that you write when you find it on your hard drive after a long time.

Sealing can be useful in order to learn how to use the special Haskell functions and boasting (“I solved it in one line!”), But otherwise we must not forget how important the readability and maintainability are.

Another advantage of a longer code is that it is easier to debug if the code does not behave as expected, because it is similar to its logical structure (if formatted correctly) and, therefore, greatly facilitates error tracking.