編輯器思惟與系統設計思想

前言

與人類社會的歷史相比，計算機的歷史很是短暫，上世紀5、六十年代都能稱爲遠古時期了。但計算機的歷史又很神奇，早期的思想每每都很超前、很先進。好比EJB技術雖然是1998年提出的，但它的設計很超前，諸如微服務等後面出現的技術都或多或少借鑑了它的思想。經過了解計算機技術的發展歷史，每每能從中找到不少有創意的想法，能幫咱們解決當下的問題。因此，今天想來掰扯一下Emacs和Vim這兩款經久不衰的老古董軟件的歷史八卦，看看有沒有值得借鑑的地方。

Vim的八卦

Vim族譜

首先從Vim編輯器的起源提及，下圖Vim的族譜：

Vim的前身是ed編輯器：

• ed是UNIX系統上最古老的程序之一，從初版本開始就入駐了，做者是Ken Thompson（UNIX做者之一）。它提供了面向行（Line）的基本編輯命令。
• ex是ed的超集，是Bill Joy（Sun公司創始人之一）在開發BSD時加強了ed，因而取名叫ex。但ex仍然是面向行的編輯器。
• Bill Joy後續又爲ex提供了可視化界面（Viusal Interface），提供全屏編輯能力，所以命名爲vi。
• 爲了將vi移植到Amiga機器，Bram Moolenaar開發了Vi IMitation（Vi仿製品）。隨着功能的不斷增長，名字也升級爲Vi IMproved（Vi改良版），即Vim。

ed編輯器

ed與VSCode、Sublime Text等現代編輯器有很大不一樣，如前文所說，它是一款行編輯器（此處已幫你們劃重點），即編輯的對象是一整行文本。

ed分命令模式與編輯模式。啓動ed後，默認進入命令模式，等待用戶輸入一條條命令。ed經過執行這些命令，最終達到編輯文件的目的。使用Mac電腦的同窗能夠試試在終端裏執行ed。ed命令的格式是[尋址][命令]：

• 尋址：選中待操做的目標行。ed提供了三種尋址方法：行號：從1開始的整數；$表明最後一行。模式：選中與正則表達式匹配的行。默認從當前行開始，選中第一個匹配的行。如/re/。添加前綴g，則作全局匹配。如g/re/範圍：由兩個地址組成的尋址範圍，[地址],[地址]。如/BEGIN/,/END/
• 命令：用單個字符表示。如下是最經常使用的命令：p：展現，輸出目標行。i：插入，將內容插入到目標行的上一行。a：追加，將內容追加到目標行的下一行。c：更改，替換目標行的內容。d：刪除，刪除目標行。s：替換，用正則表達式替換匹配行內容。

其中i、a、c命令會使ed從命令模式進入編輯模式，在編輯模式中輸入一行.則返回命令模式。如下是ed編輯的幾個示例：

• 刪除全部空行：g/^$/d。用前綴g全局搜索正則表達式/^$/，並執行刪除命令。
• 輸出全部包含「re」的行：g/re/p。一樣全局搜索正則表達式/re/，並執行展現命令。由於該功能實在太經常使用了，因此還特意開發了一個命令「grep」。

編輯器思惟

如前文所說，ed編輯器與現代編輯器很不一樣，它實際上是一個編輯命令解釋器；但ed編輯器又與現代編輯器很相同，全部編輯器的本質都是在不斷執行「尋址」與「命令」，不一樣類型編輯器之間的差別只是編輯的對象不一樣：

• ed是文本行編輯器：編輯的對象是文本行。
• Microsoft Word是文檔編輯器：編輯的對象是章節、段落、詞句等文檔元素。
• Sketch是圖形編輯器：編輯的對象是點、線、面等圖形元素。
• IntelliJ IDEA包含Java代碼編輯器：編輯的對象是類、方法、語句等Java語義元素。
• jQuery是DOM編輯器：編輯的對象是DOM元素。先用CSS Selector尋址，選中要處理的DOM元素；再用連綴表達式執行一系列編輯動做。
• ……

因而可知，編輯器思惟無處不在，只要符合「尋址+命令」模式均可稱做編輯器，所以萬物皆可編輯！編輯器思惟或編輯的本質，用開發者更熟悉的話術來說就是CRUD：

若之後有人質疑開發同窗只是在作簡單的增刪改查，請勇敢地告訴他們：其實我是在作一個垂直領域的編輯器！

若意識到本身在作的實際上是一個編輯器，就能利用編輯器思惟快速發現系統能力的短板。以商品管理系統爲例，若商品管理只提供經過ID查詢商品的功能，就猶如ed編輯器只支持用行號來尋址同樣，使用就很是不方便，能夠借鑑ed經過正則表達式的模式匹配尋址能力，提供經過商品名稱等信息來匹配商品、甚至經過商品照片來匹配類似商品的能力；相似的，建立商品能力也能夠借鑑編輯器複製粘貼的能力，提供用類似商品快速新建商品的能力，甚至還能夠提供從其餘平臺搬家的能力。

ed的族譜

前文只介紹了ed交互式編輯的功能，其實ed還支持腳本化編輯，就是將輸入到終端的編輯命令保存成一個腳本文件，供後續反覆運行。好處是能夠用相同的編輯命令批量編輯任意多個文件。

上圖是ed編輯器的族譜，後續的衍生程序都是選擇並增量了ed的部分能力。好比：

• ex、vi、vim這條分支選擇了交互式路線。
• grep、fgrep、egrep選擇了模式匹配路線。
• sed、awk選擇了腳本化路線。

Emacs的八卦

從Vim陣營叛逃

我曾經是一名Vim重度用戶，由於在大學利用的操做系統是Debian Linux，不管是寫C代碼仍是Java代碼，都是在Vim裏一把梭。好處是閉卷筆試時能夠直接默寫，而用Eclipse的同窗基本是記不住JDK API的全名。:-p

畢業後進了一家外企，不得不開始使用Windows XP系統，某天在記事本里寫東西，發現本身會常常無心識地按一下Esc鍵。用過Vim的同窗確定知道，這是在切換模式。這我意識到：Vim這種多模式的設計很是反人類。Vim啓動時默認進入的不是編輯模式，當新手用戶什麼都還沒學會時，他沒辦法把Vim當成普通的記事原本用。曾有一則關於Vim的笑話，說如何得到一串隨機碼，答案是讓Vim新手嘗試退出Vim。

這種方式不符合個人口味，我嘗試去尋找新的編輯器——當什麼都沒學會的時候，能夠當成最普通的記事原本用；當須要高級功能時，再經過快捷鍵等方式呼喚出來。結果發現Emacs剛好符合這個要求，因此從2010年開始我就從Vim陣營叛逃到了Emacs陣營。我認爲這個使用方式的差別是Vim與Emacs最本質的區別：Vim會強迫用戶從一開始就按照它的規則來作事情；而Emacs則相對不須要過多前置知識。網絡上曾流傳過一張編輯器的學習曲線，還蠻貼切的：

Emacs的起源

Vim的前身ed源自UNIX系統，而Emacs的前身TECO源自UNIX系統的前身——Multics系統。

上世紀70年代，GNU的創始人Richard Stallman在MIT的AI實驗室打工時，發明了TECO編輯器，運行在PDP-10機器上。與ed相似，TECO也是命令解釋器——接收並執行編輯命令——而且也採用單個字符做爲命令名稱，好比「l」是移動一行，「5l」是移動5行。MIT那羣大佬們想用TECO命令完成一些複雜的編輯工做，因而加入了分支判斷、循環等功能；但因爲先天不足，TECO最開始設計的時候，沒有把命令設計成一套完備的編程語言，致使後續改進也很困難，好比命令名稱只能是單個字符，很快字符就不夠用了。

所謂基礎不牢地動山搖，大夥兒都認爲須要用一套嚴謹完備的編程語言替代TECO的半成品腳本語言。因而有一位叫Bernie的教授在Multics系統上用MacLisp重寫了TECO，並命名爲Emacs，還爲它寫了詳細的手冊，教你們如何擴展這個編輯器來知足本身的工做須要。結果，這個版本的Emacs取得巨大成功，連Bernie的祕書——一個號稱本身不懂編程的人——都在照着手冊，有模有樣地寫Lisp代碼來擴展編輯器功能。這件事兒在實驗室引發轟動後，Bernie爲此作了一個總結：若是有一個應用——一個能幫你作點有用事情的程序——內嵌了Lisp，而且能經過Lisp程序擴充它的功能，對於學習編程而言，這是一種很是不錯的入門方式！那些自認爲不會編程的人，這種方式會給他們編寫小但有用的程序的機會，讓他們在實踐中不斷成長，直到他們發現本身就是在編程。

Stallman他們以爲這個想法簡直屌炸天！同時他們想把這個好用的Emacs版本遷移到Multics系統以外的其餘系統，但當時只有Multics系統上有完備的Lisp環境——既有編譯器又有解釋器——諸如UNIX等系統上都沒有。

這裏還有一個小插曲，Java之父James Gosling當年還寫了一個能跨平臺的Emacs版本，叫Gosmacs。原本社區想來一塊兒完善這個版本，結果Gosling把它賣給了一家商業公司，同時它底層的Lisp不是一個真實完備的Lisp，而是一個叫Mocklisp的假Lisp，只是語法上和Lisp長得像而已。因此社區最終放棄了這個選項，決定從頭開始作一個全新的Emacs，也就是GNU Emacs。Stallman先用C語言開發一個跨平臺的Lisp解釋器——Emacs Lisp，再用Lisp實現編輯邏輯。這樣既能在全部平臺上用統一的Lisp方言來寫Emacs擴展，又能兼顧性能。

GNU Emacs有一段時間發展比較以後，由於Stallman本身一我的忙不過來，因此社區又建立了一個分支叫XEmacs，加強了字體抗鋸齒等功能。後來GNU Emacs的維護又變得積極了，把不少XEmacs的特性合併回GNU Emacs，因此如今XEmacs差很少是廢棄狀態，主流版本仍是GNU Emacs。

系統設計

編輯器聖戰

程序員的世界裏充滿了鄙視鏈，有編輯器鄙視鏈、編程語言鄙視鏈、操做系統鄙視鏈……爲何這些聖戰永遠打不完，究竟是像《格列夫遊記》裏小人國因爭論剝雞蛋先打破大頭仍是小頭而發動了戰爭，仍是真的魚和熊掌不可兼得？

前文提到，Vim喜歡強迫用戶按照它的套路來作事。Vim從ed繼承了行編輯器的特性，底層模型是基於「行」的，因此會強行要求全部被編輯的對象適配成它的底層模型。你用Vim寫Java代碼，你編輯的是文本行；你用Vim寫一篇博客，你編輯的是文本行；你用Vim寫一篇論文，你編輯的仍是文本行；不管你編輯的是類、函數、段落、目錄仍是任何其餘內容，都要先在腦海中翻譯成對應的dd、yy等面向行的編輯命令。

Emacs則是容許用戶先把Emacs改形成目標對象的個性化編輯器，能認識目標模型，好比段落、章節、目錄等。用一句時髦的話講就是Emacs有行業Know-How。一樣的例子：用Emacs寫Java代碼，你編輯的是類、方法、語句……；你用Emacs寫一篇博客，你編輯的是段落、句子……；你用Emacs寫一篇論文，你編輯的是目錄、章節、正文、索引……。

兩種設計方法

形成上述差別的緣由是背後兩種不一樣的設計方法，分別稱做自頂向下（Top Down）與自底向上（Bottom Up）：

方法自頂向下自底向上描述將大任務逐級拆分到顆粒度合適——足夠小、又能作些實際的事情——的小任務完善底層編程語言等——讓底層基建不斷逼近業務領域——來適應任務優勢難度較低，目標明確，迭代快速功能完整，適應性強缺點與當前需求耦合過緊，應對變化能力稍弱難度較高，進展較慢

用Vim編輯屬於自頂向下方法——將編輯任務持續拆分，最終拆解到面向行的編輯命令；就像Java平常開發，會逐級拆分，最終拆解到JDK的API。用Emacs編輯屬於自底向上方法——先完善底層Emacs Lisp語言，逐步抽象出面向業務的領域特定語言，最終用DSL完成編輯任務；例如要編輯Markdown文檔，就會提供諸如移動到下一個段落、下一個列表項、表格下一個單元等面向Markdown領域的特定編輯操做。

這兩種設計方法的差別並不意味着只是換個順序寫代碼，而是系統抽象過程的差別，最終體如今系統擴展性的差別上。我我的把系統的可擴展分紅4個等級：

• 硬編碼：系統運行時，數據和行爲都已寫死，不能變化。
• 可配置：系統運行時，數據可動態變化，但行爲固定不變。
• 可控制：系統運行時，數據可動態變化，而且由多種預約義的行爲可供動態選擇。
• 可編程：系統運行時，數據可動態變化，同時行爲可在運行過程當中動態新增，即用戶可從新系統行爲。

自頂向下的極端是硬編碼，會過早地把功能限制在當前的需求裏，後來的需求只能儘可能逼近初始模型；自底向上的極端是可編程，容易過渡設計，爲將來不可能變化的場景提供靈活性，甚至會變成一門通用的編程語言。

兩種設計方法沒有絕對的對錯，都有各自適用的場景，單一地採用任何一種方法都會有問題，須要根據實際狀況在快速實現和系統擴展性之間作權衡。也正由於沒有對錯之分，因此編輯器的聖戰永遠也打不完。

 

原文連接

本文爲阿里雲原創內容，未經容許不得轉載。