Ward's Wiki code (WikiBase) is amazingly elegant and short. But it was just a bit of Perl-4. What's the shortest piece of source you can write that will implement a fully-featured wiki? Use any language you like. See WikiPrinciples for a list of the (minimum) requirements for a wiki. The contenders under 50 lines (WikiPrinciples obeyed): * SigWik, 4 lines, 222 chars of Perl and Shell. (source: http://caseywest.com/code/scripts/sigwik.txt) (based on FleaWi) * FleaWi, 4 lines, 228 chars of Perl and Shell. (source: http://nick.cleaton.net/fleawi.txt) (based on SigWik) * WiPhiki, 4 lines, 289 chars of PHP and Shell. (source: WiPhiki) * NanoWiki, 5 lines, 295 chars of Perl. (source: NanoWiki) (partially based on SigWik and PeeWee) * PeeWee, 7 lines, 444 chars of Perl. (source: http://caseywest.com/code/scripts/peewee.txt) * PeWi, 7 lines, 515 chars of Perl. (source: http://infomesh.net/200X/pewi/pewi.pl.txt) * Peki, 7 lines of Perl. (http://phiki.infogami.com/peki) * Tinki, 8 lines, 729 chars of Ruby. (source: http://gist.github.com/3808680) * WyPy, 11 lines, 814 chars of Python. (source: http://infomesh.net/2003/wypy/wy.py.txt) * MuWiki, 15 lines of PHP. (source: http://jaramir.slack.it/MuWiki/wiki.phps. Valid xHTML) * WjKj, 16 lines, 1,212 chars of Java (JSP) (source: WjKj) * WikWiki, 17 lines, 1,287 chars of PHP (source: WikWiki) * Phiki, 18 lines of PHP. (source: http://phiki.infogami.com) * WyRiki, 20 lines, 1,361 chars of Ruby (source: http://onestepback.org/misc/wyriki.txt, technique shamelessly stolen from WyPy) * Pyki, 25 lines of Python (source: http://phiki.infogami.com/pykisource) Based on Phiki * TinyWiki, 28 lines of Perl. (even though it has grown to ~97 lines now, the classic 28-line version met the WikiPrinciples) * Qiki, 32 lines of Python. (http://www.colourcountry.net/cgi-bin/qiki.py) (now downloadable!) * FinikiWiki, 38 lines of Perl. * RikiWiki, 40 lines of Ruby. The contenders under 50 lines (WikiPrinciples not obeyed): * WikKe, 3 lines, 206 (IE: 199) chars of PHP, JavaScript, and Bash. (source: http://jane.no-ip.com/~sbp/wikke.txt) The contenders under 2 lines (dubious): * BogoWiki, one char of Shell to load a wiki process. * Kwiki, one line, 39 chars of Perl to load a wiki module family: "use Kwiki;Kwiki->new->load_hub->process" (http://www.kwiki.org/) ''I don't think that counts. See comment about WikiPlusPlus below...'' ---- Of course, the shortest source implementing a fully-featured Wiki is written in the WikiPlusPlus language (implementation of which is left as an exercise to the reader). It looks something like this: wiki^standard: run ''I got a "Cross-Search Time-out Error on Line 1". Can you help me fix it? :-) '' ---- Does storing the HTML as templates in separate files, rather than in the source code count as SLOC? Could be a loophole there. ''Since mixing HTML and code is generally discouraged, I would have to say templates are fair. Templates will also be small and not interesting to optimize anyway.'' ---- '''Tough talk''' My money's on WardCunningham. Language: Perl. -- TimVoght Thanks for your confidence Tim. My wiki/4 was 220 lines of perl in its first working version, though it has grown since. I got rid of dispatching by writing it as cooperating cgi scripts: wiki.cgi, edit.cgi, post.cgi, search.cgi and changes.cgi. I bet it could be done in 100 lines. -- WardCunningham Perl is definitely the language. I'm not sure Ward is twisted enough to win. -- CliffordAdams That's mighty big talk round these here parts, Clifford. Me, I'd back python/zope to beat out perl in shortness on account of there seems like a lot in zope to leverage. But I also wonder whether some Interdev magic might put the freeware to shame... -- PeterMerel I'd bet that the proprietary KayLanguage from http://www.kx.com will surpass any 0known experience with concise programming. When programming in K, one refers to characters of code, not lines. And there are usually no loops. -- EricNewhuis ''that sounds a lot like APL, which was much more widespread.'' The KayLanguage is a descendant of APL, among others, so that isn't surprising. APL is very concise but not 'optimized' for web/text processing, so I doubt it would be *the* shortest. ''Come on! You Python people can't let these two go unchallenged!'' Can't? Why not? "What is the shortest time a third party reader needs to understand another person's WikiSource?" That would be a more useful measurement. ''I concur. I looked at a short perl wiki, and it left me aghast. Then I looked at wypy with all the lambda and RE, and was again floored. When I look at my VERBOSE procedural programming, it reads like Dick and Jane at the compsci lab. Which means any reasonably literate wannabe geek can comprehend it. I propose a competition for the EASIEST TO COMPREHEND WIKI.'' -- KirkBailey The 23 line Python contender WyPy currently (2003-08) wipes the floor with all the other submissions, but I wouldn't call it exactly readable, unfortunately. Still, ObfuscatedPython is possible then... ''I thought Dinki was rather easy to understand, and it's in Perl. Unfortunately, the source appears to have gone missing.'' ---- I see WyRiki was just added - at 20 lines of Ruby. But I'm sure that a bunch of useless new lines could be removed, to make it "shorter." How long is a "line?" ''80 characters'' Next up: The ObfuscatedWikiContest. ;-> I'm sure that something like "#!/bin/sh\nGET http://wiki.tld/ | perl" would make for a much shorter wiki, but that'd be cheating now, wouldn't it? Perhaps it's as best to limit this competition to some major languages (Python, Perl, Ruby, PHP seem the best contenders)? I hope that everyone enjoys the new WyPy: WyRiki's introduction was quite a challenge! -- SeanPalmer Anybody up for the challenge of SmallestXhtmlWikiContest? * Why? The difference in HTML used by a wiki versus the XHTML equivalent is quite trivial; you could just convert any of the existing entries to XHTML, in about 5 minutes, and be done with. It appears to me that it would be quite different as simple regular expressions no longer work. When you see \n\n, a simple implementation will put in
, an xhtml wiki has to analyze all the appropriate closing tags before continuing. I'm also curious about how implementations deal with such things as between '''''''''' and ''''''''''. I'd also expect as much semantic correctness as possible. For example consecutive list items should be contained within