From f7037f4870c4a34becf32f4bd953d7d6ddcf556b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 1 Apr 2009 13:47:41 -0400 Subject: [PATCH] happy Make Big Confusing Proposal Day --- doc/todo/rewrite_ikiwiki_in_haskell.mdwn | 68 ++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 doc/todo/rewrite_ikiwiki_in_haskell.mdwn diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn new file mode 100644 index 000000000..204c48cd7 --- /dev/null +++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn @@ -0,0 +1,68 @@ +[[!tag wishlist blue-sky]] + +In the long term, I have been considering rewriting ikiwiki in haskell. +It's appealing for a lot of reasons, including: + +* No need to depend on a C compiler and have wrappers. Instead, ikiwiki + binaries could be built on demand to do the things wrappers are used for + now (cgi, post-commit, etc). +* Potentially much faster. One problem with the now very modular ikiwiki is + that it has to load up dozens of perl modules each time it runs, which + means both opening lots of files and evaluating them. A haskell version + could run from one pre-compiled file. Other speed efficienies are also + likely with haskell. For example, pandoc is apparently an order of + magnitude faster than perl markdown implementations. +* Many plugins could be written in pure functional code, with no side + effects. Not all of them, of course. +* It should be much easier to get ikiwiki to support parallel compilation + on multi-core systems using haskell. +* A rewrite would be an opportunity to utterly break compatability and + redo things based on experience. Since the haskell libraries used for + markdown, templates, etc, are unlikely to be very compatable with the perl + versions, and since perl plugins obviously wouldn't work, and perl setup + files wouldn't be practical to keep, a lot of things would unavoidably + change, and at that point changinge everything else I can think of + probably wouldn't hurt (much). + + - Re templates, it would be nice to have a template library that + doesn't use html-ish templating tags, since those are hard for users to + edit in html editors currently. + - This would be a chance to make WikiLinks with link texts read + "the right way round" (ie, vaguely wiki creole compatably). + - The data structures would probably be quite different. + - I might want to drop a lot of the command-line flags, either + requiring a setup file be used for those things, or leaving the + general-purpose `--set var=value` flag. + - Sometimes the current behavior of `--setup` seems confusing; it might + only cause a setup file to be read, and not force rebuild mode. + - Hard to say how the very high level plugin interface design would change, + but at the least some of the names of hooks could stand a rename, and + their parameter passing cleaned up. + +We know that a big, break-the-world rewrite like this can be a very +bad thing for a project to attempt. It would be possible to support +external plugins written in haskell today, without any rewrite; and a few +of the benefits could be obtained by, eg, making the mdwn plugin be a +haskell program that uses pandoc. I doubt that wouod be a good first step +to converting ikiwiki to haskell, because such a program would have very +different data structures and intercommuniucation than a pure haskell +version. + +Some other things to be scared about: + +* By picking perl, I made a lot of people annoyed (and probably turned + several people away from using ikiwiki). But over time there turned out + to be a lot of folks who knew perl already (even if rustily), and made + some *very* useful contributions. I doubt there's as large a pool of haskell + programmers, and it's probably harder for a python user to learn haskell + than perl if they want to contribute to ikiwiki. +* It might be harder for users of hosting services to install a haskell based + ikiwiki than the perl version. Such systems probably don't have ghc and + a bunch of haskell libraries. OTOH, it might be possible to build a + static binary at home and upload it, thus avoiding a messy installation + procedure entirely. +* I can barely code in haskell yet. I'm probably about 100x faster at + programming in perl. I need to get some more practical experience before + I´m fast and seasoned enough in haskell to attempt such a project. + (And so far, progress at learning has been slow and I have not managed + to write anything serious in haskell.) --[[Joey]] -- 2.39.2