I'm not sure if Joey's aware of this or not, but reading the code of e.g. Ikiwiki.pm [1] there's a very clear reason why it's a little hard to work with, and this has nothing to do with Perl.

The code looks superficially clean, particularly also because it appears to follow a consistent formatting standard; however it violates DRY a lot and features high levels of redundancy and repetition, making it not so much hard, but exhausting to read through. It looks a little like the kind of code i see in "enterprise java solutions".

[1] http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=...

Writing Ikiwiki plugins is often very easy, because triggers for most events you'd want to get involved in are available, and because much of Ikiwiki's own functionality is implemented as plugins. Reading and understanding internals, as you point out, can be challenging.

Tricky and/or important bits of functionality are often covered by automated tests (and I've test-driven new functionality in: http://www.schmonz.com/2013/08/22/tdd-by-example-an-ikiwiki-...). A sufficiently motivated person could incrementally test-protect more of the internals and refactor under test. I hope to have more time for this soon.

Haskell has rotted my perl brain.

> Haskell has rotted my perl brain.

<3

Can't help mention a talk from flatMap (Oslo) -- How Haskell is Changing my Brain by Alissa Pajer [1]

[1] https://vimeo.com/96639840