用haskell 十分钟写一个wiki程序

好吧，我承认，标题是唬人的。用十分钟实现的这个小wiki还不具备全文搜索，智能推荐，启发式屏蔽关键词等等能力。

这几天用晚上的时间研究了下haskell的web应用，见前两天的 haskell + fastcgi 篇。所应用的就是基本的 fastcgi, dbm以及 XHtml 这几个模块。 从无到有自己实现 session以及url映射等基础组件，总共的功能代码不到100行吧。有了这个基本架子之后，在上面添加一个 wiki 功能，真的只用了十多(n)分钟。（Turbogears那个视频也很唬滥，他可是在一大堆现有的模块之上搞的，我好歹是从cgi搞起）

通过几天的实践，几点感受：
1. haskell 是门简单的语言，但很多入门读物都是具有医生头衔的人写的，上来就是monad,范畴论,组合子，要么就是写个解释器之类的，真的会吓到我这样的小白
2. haskell的类型确实是个好东西，类型检查可以在编译期间排除掉大部分的错误，所以基本上，只要程序能通过编译，不大需要调试的，因为类型检查强迫你按正确的用法使用各个模块
3. dbm 是sql hater的救星

代码片段1: （url 分发部分） 如果url 不在map里，就去wiki的 dbm 里面找，找不到的话，给一个创建页面，找到了的话，就现实这个页面。

  target <- liftIO $ HT.lookup mapping uriPath
  case target of
    Nothing -> do
      -- missing page, find wiki
      let wiki = dbmWiki env
      wikiContent <- liftIO $ findWiki wiki uriPath 
      case wikiContent of
        Nothing -> do
                output $ showHtml $ pageNotFound uriPath
        Just content -> do
                output $ showHtml $ readWikiPage uriPath content

而 Wiki 模块中的几个函数，简单到不忍心拿出来的地步：

从dbm 中找一个页面是否存在： （简直就是换了个函数名而已）

findWiki dbm path = lookupA dbm path

把一个新页写入 dbm 中：

writeWikiPage dbm path content = do
  insertA dbm path content
  flushA dbm

显示wiki页面：

readWikiPage path cont = header << [
                             thetitle << path,
                             meta ! [httpequiv "Content-Type", content "text/html", strAttr "charset" "UTF-8"]
                            ] +++
                            body << pre << cont

创建页面：

pageNotFound uri = page "Page Not found" b
    where
      b = body << [
           h1 << "Page Not found",
           form ! [method "POST", action "/createPage"] << 
                    [
                     h2 << "Page Content:",
                     textarea ! [name "content", cols "100", rows "25"] << "",
                     br,
                     hidden "path" uri,
                     submit "" "Submit"
                    ]
          ]

保存页面：

createPage env sid = do
  let dbm =  dbmWiki env
  method  <- requestMethod
  path'   <- getInput "path"
  content'<- getInput "content"
  case maybe2 path' content' of
    Nothing -> do
      return (h1 << "miss field", "/")
    Just (path, content) -> do
                       liftIO $ writeWikiPage dbm path content
                       return (h1 << "write ok", path)

简陋的功能有了，现在可以访问一个不存在的url 然后显示一个创建页面，保存就ok了。 下面需要一个Index页，把所有已有的页面列出来：
下面这个函数生成一个 Html 类型的结果，内容为一个 div

wikiIndex env sid = do    
  paths <- keysA dbm             -- 把 dbm 的所有key 取出
  --  div 由一个 h1 和一系列链接组成
  return $ thediv << (h1 << "Wiki Index" +++ [ li << anchor ! [href p] << p | p <- paths])
    where
      dbm = dbmWiki env         -- 获得 wiki的dbm handle

评论

4 楼 albertlee 2008-05-26  

说句影响工作前途的话： 我基本上不用 Unit Test。

以前我经常自责：我不够面向，我不够对象
现在要加上：我不够敏捷，我不够XP
再加：我不够SOA，我不够云计算

3 楼 ray_linn 2008-05-26  

没什么意义，搞语法复古啊？

2 楼 Trustno1 2008-05-26  

引用

1. haskell 是门简单的语言，但很多入门读物都是具有医生头衔的人写的，上来就是monad,范畴论,组合子，要么就是写个解释器之类的，真的会吓到我这样的小白

这个东西很难说，用不着Monad,光是rescursive call,Type Class,function composite这类的语法,就已经可以吓退很多人了.

引用

2. haskell的类型确实是个好东西，类型检查可以在编译期间排除掉大部分的错误，所以基本上，只要程序能通过编译，不大需要调试的，因为类型检查强迫你按正确的用法使用各个模块

要论语言的灵活性Haskell这种Full of DSL的static type语言,才是正途.没有static check,光靠unit test实在是很吃力的事情.Ruby这些语言之所以开发快完全仰赖于几个比较优秀的intellegen sense.Erlang没有一个好的intellegen sense问题就很大.emacs+esense效果差强人意,erlide,erlybrid也好不到哪里去.写Erlang程序的时候,会把40%的时间用于调试参数类型错误上面.说实在的把设计intellegen sense的那些精力放在设计type system上面，足够写出Haskell那样强大的类型系统了.

1 楼 albertlee 2008-05-26  

http://www.kamang.net/node/180

粗略的用ab做了简单的负载测试，都是动态请求，涉及页面组装及dbm读取，大概能到1000次每秒，在更多的数据及更复杂的逻辑情况下肯定还要低不少，因此这个数没多大说服力。只能说明haskell 与 fastcgi的性能不会成为瓶颈。作为纯函数型的语言来说，对其性能的质疑可以打消了。


ab -c 15 -n 1000 http://localhost/bt

Concurrency Level: 15
Time taken for tests: 0.978165 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 585000 bytes
HTML transferred: 355000 bytes
Requests per second: 1022.32 [#/sec] (mean)
Time per request: 14.672 [ms] (mean)
Time per request: 0.978 [ms] (mean, across all concurrent requests)
Transfer rate: 583.75 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.2 0 11
Processing: 3 13 5.2 12 40
Waiting: 2 12 5.2 11 40
Total: 5 13 5.3 12 40

Percentage of the requests served within a certain time (ms)
50% 12
66% 13
75% 14
80% 16
90% 22
95% 24
98% 29
99% 36
100% 40 (longest request)