3 ms·

In comparing your 10 year post to your 20 year post, I notice that naming conventions have become started to favor clearer names describing the function of soft

In comparing your 10 year post to your 20 year post, I notice that naming conventions have become started to favor clearer names describing the function of software. Here was a scary part: "I stepped back because I can't write Perl very well anymore,..." Can you say a little about why you cannot? You've written for so long I thought you would be even better.

joeyh 10y ago
Haskell has rotted my perl brain.
- deleted 10y ago
  [deleted]
- 0xmohit 10y ago
  > 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 https://vimeo.com/96639840
Mithaldu 10y ago
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=IkiWiki.pm http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=...
- schmonz 10y ago
  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-feature/ 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.

joeyh 10y ago

Haskell has rotted my perl brain.

deleted 10y ago
[deleted]
0xmohit 10y ago
> 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 https://vimeo.com/96639840

Mithaldu 10y ago

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=IkiWiki.pm http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=...

schmonz 10y ago
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-feature/ 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.