5.2 四语言对照实验：同一道题的四种解法

5.2 四语言对照实验：同一道题的四种解法

本节摘要：本节做一组受控对照：同一道业务题——"解析逗号分隔的订单行，过滤有效单，按客户分组求和，产出报表"——分别用 Haskell、OCaml、Clojure、Scala 实现。四份代码并排放，函数式思想的内核（纯函数、不可变、组合）与各语言的实现选择（类型严谨度、求值策略、数据结构哲学）被清晰剥离。对照表与类型严谨度坐标是本节的两个核心产出。

实验设计：控制变量

题目刻意选了"解析、过滤、聚合、渲染"四段式，因为它能同时考察：错误处理风格（解析会失败）、数据结构选型（分组求和要用映射）、组合能力（四段要焊管道）。变量控制约定：各语言都用其社区主流写法（不故意炫技也不用刻意笨拙的写法），标准库优先。先看 Haskell 基准版（上一节同款风格，压缩为完整小程）：

import qualified Data.Map as Map
import Data.List (foldl')

type Order = (String, Double)      -- 客户名, 金额

-- 解析："alice,120.5" -> Just ("alice",120.5)
parse :: String -> Maybe Order
parse s = case break (==',') s of
  (name, ',':amt) | not (null name) -> Just (name, read amt)
  _ -> Nothing

aggregate :: [Order] -> Map.Map String Double
aggregate = foldl' (\acc (n, v) -> Map.insertWith (+) n v acc) Map.empty

report :: [String] -> [String]
report xs = [ n ++ " 合计 " ++ show v
            | (n, v) <- Map.toList (aggregate (mapMaybe parse xs)) ]

main = mapM_ putStrLn (report ["alice,120.5", "bob,80", "alice,20.5", "badrow"])
-- alice 合计 141.0
-- bob 合计 80.0
​

四行核心逻辑：parse 承担错误处理（Maybe 声明可失败）、aggregate 承担分组（不可变映射加严格折叠）、列表推导式承担渲染。记住这份形状，下面三份对照。

一、OCaml：严格务实的 ML 系

OCaml 与 Haskell 同属 ML 家族，两处关键分歧：默认严格求值（第 2.2 节的两套节拍，OCaml 选了严格），以及不加括号的函数调用与符号化的错误处理（Option 与 Result 类型，对应 Haskell 的 Maybe 与 Either）：

(* 解析：返回 option —— 无行则 None *)
let parse line =
  match String.index_opt line ',' with
  | None -> None
  | Some i ->
      let name = String.sub line 0 i in
      let amt  = float_of_string_opt (String.sub line (i+1) (String.length line - i - 1)) in
      match amt with
      | Some v when name <> "" -> Some (name, v)
      | _ -> None

(* 聚合：Hashtbl 也可，此处用不可变风格折叠 *)
let aggregate orders =
  List.fold_left (fun acc (n, v) ->
    let cur = match StringMap.find_opt n acc with Some c -> c | None -> 0.0 in
    StringMap.add n (cur +. v) acc) StringMap.empty orders

(* 渲染与主管道 *)
let report lines =
  StringMap.bindings (aggregate (List.filter_map parse lines))
  |> List.map (fun (n, v) -> Printf.sprintf "%s 合计 %.1f" n v)

let () = List.iter print_endline
           (report ["alice,120.5"; "bob,80"; "alice,20.5"; "badrow"])
​

对照读法：List.filter_map 是 mapMaybe 的 OCaml 名字；StringMap.find_opt 的 _opt 后缀是 OCaml 社区约定——可能失败的 API 在名字里自报家门。与 Haskell 相比，类型推导更激进（本例几乎没写类型注解），语言刻意不挡在编译期管太多，把"要不要严格"的决定留给工程师——务实风格贯穿始终。

二、Clojure：动态类型的不可变主义

Clojure 是四者中唯一的动态类型语言，走了另一条极端：放弃静态类型的编译期保障，把全部筹码押在不可变数据结构、REPL 驱动与函数组合上。同一道题：

(defn parse [line]
  (let [[name amt] (clojure.string/split line #",")]
    (when (and (seq name) (re-matches #"[\d.]+" amt))
      [name (Double/parseDouble amt)])))

(defn aggregate [orders]
  (reduce (fn [acc [n v]] (update acc n (fnil + 0) v)) {} orders))

(defn report [lines]
  (->> lines
       (keep parse)                     ; 解析并丢弃失败行
       (aggregate)
       (map (fn [[n v]] (str n " 合计 " v)))))

(doseq [row (report ["alice,120.5" "bob,80" "alice,20.5" "badrow"])]
  (println row))
​

三个显著差异。其一，线程宏 ->>：数据流从上往下读，"解析、聚合、渲染"的管道形状直接排成了代码的形状——组合思想以语法形式出场。其二，update 加 fnil：对不可变映射的"插入或累加"，标准库一个函数办妥，上一节的 insertWith 同款语义。其三，没有任何类型注解：解析失败的防护（正则）写在运行时，编译器不管。Clojure 工程师的信条是"用不可变结构让大半类型错误失去发生的机会"——动态而有纪律，这是光谱上的另一个端点。

三、Scala：JVM 上的融合派

Scala 的立场是"两种范式都要，且要互操作"：函数式结构齐全（case class、模式匹配、Option、不可变集合默认），同时与 Java 无缝共生。同一道题：

case class Order(customer: String, amount: Double)

def parse(line: String): Option[Order] =
  line.split(",") match {
    case Array(name, amt) if name.nonEmpty =>
      amt.toDoubleOption.map(Order(name, _))
    case _ => None
  }

def report(lines: List[String]): List[String] =
  lines.flatMap(parse)                       // 解析并丢弃失败
    .groupBy(_.customer)                     // 不可变 Map[String, List[Order]]
    .view.mapValues(_.map(_.amount).sum)     // 分组求和
    .map { case (n, v) => f"$n 合计 $v%.1f" }
    .toList

@main def run(): Unit =
  report(List("alice,120.5", "bob,80", "alice,20.5", "badrow")).foreach(println)
​

toDoubleOption 返回 Option——Java 的 Double.parseDouble 会抛异常，Scala 标准库把它包成"可能失败"的函数式形态，两种世界的翻译层是 Scala 的日常。flatMap 加 groupBy 的组合与 Haskell 的 mapMaybe 加 foldl' 完全同构，只是 API 名字与风格不同。Scala 的代价也如实记录：语法糖密度高（同一道题社区能写出四种风格）、编译器复杂度世界第一梯队，团队约定比语言本身更重要。

图：四语言特性对照矩阵

四、读表结论：类型严谨度坐标

把四个语言放上一根坐标轴——"保障由谁提供：编译器到工程师"。Haskell 最左（编译器强制纯度与失败处理），OCaml 次之（编译器管类型、工程师管严格性），Scala 中间（编译器管类型、世界边界靠翻译层），Clojure 最右（全靠工程师纪律与不可变结构的惯性）。没有正确的站位，只有与团队、与生态、与项目周期的匹配：核心计价逻辑偏左，数据探索脚本偏右，是常见的合理分布。

变式练习：把这道题用你最熟的主流语言写一遍，对照四份实现找"同构点"——你会发现 JavaScript 的 reduce 加 Map、Python 的 defaultdict 都能对上号。这个"找同构"的动作，就是下一节移植工作的核心技能。

💡 关键直觉：读陌生函数式语言代码时，别逐字翻译语法，先找三个锚点——失败建模用什么类型、聚合用什么折叠、管道用什么符号。三锚在手，一门新语言的函数式代码可以读个八九不离十。

本节要点回顾

• 受控对照的读法：同一道题隔离出"内核思想"与"实现选择"，混淆两者是跨语言学习的最大障碍。
• OCaml 务实：默认严格、option 命名自报家门，ML 系的"严而不管闲事"。
• Clojure 押注不可变：放弃静态类型，以持久化数据结构与线程宏换取动态流畅。
• Scala 是翻译层：Option 包装 Java 异常，flatMap 与 groupBy 与 Haskell 同构。
• 严谨度坐标可用于选型：核心域偏编译器保障，脚本域偏工程师纪律，混合分布是常态。

方言地图看完，最后一站是大多数人真正的工作现场：不换语言，把函数式思想搬进 Java、JavaScript、Python 的存量代码。