Twenty years of free software, part 1: Ikiwiki | Hacker News Reader

Twenty years of free software, part 1: Ikiwiki

joeyh.name

I should tell my own wiki software story. It's not a free software story, sadly.

It's 1995, and I'm working as a contractor for a large multi-national telecommunications company. My co-workers on the 24/7 support team have been gathering useful emails sent out by the other IT staff. They had worked on a Perl script to assemble these text files into a single big HTML page, located on our internal web server. When you got a new useful tidbit (such as how to partition the disk space on this class of server), you'd have to re-run the script to generate the new page.

Shortly after that, I learned about HTML forms, and submitting them and generating a response. The Aha! moment occurs, and I decide to make an interactive version of this "notes db".

450 lines of Perl later, I had something that resembled other early wikis, with a couple notable exceptions.

It didn't occur to me to create a markup language to make writing the wiki pages easier. You had to know some basic HTML. Links between pages were possible, the script searched for anchor links and replaced 'NOTESDB' with the actual server URL upon rendering a page for display.

A hierarchy was enforced. You could (and should) link between documents, but it was expected that each page had a parent page, and could have multiple child pages, all of which were always listed before the start of the text. The notion of a flat namespace (as was with Ward Cunningham's wiki) was antithetical to how I thought things should work. It is interesting to contrast my thinking at the time to the flow of history since.

I was rather proud of that bit of code, and it was in use for years after I had left the company. I didn't learn about other wiki software until a couple years later.

I should have asked permission to release it as free software, but that didn't occur to me either. I'm not much of a promoter, so I don't know that I would have been able to build up a community around it anyway.

Part 2 of the series: Twenty years of free software -- part 2 etckeeper [1]

[1] http://joeyh.name/blog/entry/twenty_years_of_free_software_-...

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.

Haskell has rotted my perl brain.

> Haskell has rotted my perl brain.

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

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

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.

Reply on news.ycombinator.com