doc/todo/rewrite_ikiwiki_in_haskell.mdwn

   1 [[!tag wishlist blue-sky]]
   2
   3 In the long term, I have been considering rewriting ikiwiki in haskell.
   4 It's appealing for a lot of reasons, including:
   5
   6 * No need to depend on a C compiler and have wrappers. Instead, ikiwiki
   7   binaries could be built on demand to do the things wrappers are used for
   8   now (cgi, post-commit, etc).
   9 * Potentially much faster. One problem with the now very modular ikiwiki is
  10   that it has to load up dozens of perl modules each time it runs, which
  11   means both opening lots of files and evaluating them. A haskell version
  12   could run from one pre-compiled file. Other speed efficienies are also
  13   likely with haskell. For example, pandoc is apparently an order of
  14   magnitude faster than perl markdown implementations.
  15 * Many plugins could be written in pure functional code, with no side
  16   effects. Not all of them, of course.
  17 * It should be much easier to get ikiwiki to support parallel compilation
  18   on multi-core systems using haskell.
  19 * A rewrite would be an opportunity to utterly break compatability and
  20   redo things based on experience. Since the haskell libraries used for
  21   markdown, templates, etc, are unlikely to be very compatable with the perl
  22   versions, and since perl plugins obviously wouldn't work, and perl setup
  23   files wouldn't be practical to keep, a lot of things would unavoidably
  24   change, and at that point changinge everything else I can think of
  25   probably wouldn't hurt (much).
  26
  27   - Re templates, it would be nice to have a template library that
  28     doesn't use html-ish templating tags, since those are hard for users to
  29     edit in html editors currently.
  30   - This would be a chance to make WikiLinks with link texts read
  31     "the right way round" (ie, vaguely wiki creole compatably).
  32     *[See also [[todo/link_plugin_perhaps_too_general?]] --[[smcv]]]*
  33   - The data structures would probably be quite different.
  34   - I might want to drop a lot of the command-line flags, either
  35     requiring a setup file be used for those things, or leaving the
  36     general-purpose `--set var=value` flag.
  37   - Sometimes the current behavior of `--setup` seems confusing; it might
  38     only cause a setup file to be read, and not force rebuild mode.
  39   - Hard to say how the very high level plugin interface design would change,
  40     but at the least some of the names of hooks could stand a rename, and
  41     their parameter passing cleaned up.
  42
  43 We know that a big, break-the-world rewrite like this can be a very
  44 bad thing for a project to attempt. It would be possible to support
  45 external plugins written in haskell today, without any rewrite; and a few
  46 of the benefits could be obtained by, eg, making the mdwn plugin be a
  47 haskell program that uses pandoc. I doubt that wouod be a good first step
  48 to converting ikiwiki to haskell, because such a program would have very
  49 different data structures and intercommuniucation than a pure haskell
  50 version.
  51
  52 Some other things to be scared about:
  53
  54 * By picking perl, I made a lot of people annoyed (and probably turned
  55   several people away from using ikiwiki). But over time there turned out
  56   to be a lot of folks who knew perl already (even if rustily), and made
  57   some *very* useful contributions. I doubt there's as large a pool of haskell
  58   programmers, and it's probably harder for a python user to learn haskell
  59   than perl if they want to contribute to ikiwiki.
  60 * It might be harder for users of hosting services to install a haskell based
  61   ikiwiki than the perl version. Such systems probably don't have ghc and
  62   a bunch of haskell libraries. OTOH, it might be possible to build a
  63   static binary at home and upload it, thus avoiding a messy installation
  64   procedure entirely.
  65   --[[Joey]]