1、 前言

    前幾個月，看到園子裡面一篇介紹邏輯程式語言的文章《邏輯式程式語言極簡實現（使用C#）》，覺得作者寫得很有趣，用講故事的方式來講述了一個極簡邏輯程式語言的設計，於是我也萌生了寫一篇有關邏輯程式語言的文章。說實話，我很早就接觸了邏輯程式設計的概念，最開始學程式設計的時候就想著有朝一日搞搞AI，當你在AI界機器學習還僅僅是一個概念，最火的莫過於被稱呼為“第五代程式語言”的邏輯程式語言--Prolog。可惜工作中始終沒有機會實戰這種程式語言，對Prolog也只是一知半解。直到2013年，我提出《業務分析三維度（場景+角色+時間）理論》後，思考如何將這個理論在程式設計上進行落地，才發現邏輯程式設計的概念非常符合這個三維度理論，而且這個理論跟DCI架構殊途同歸，思想上是很類似的，具體內容可以參考我最近寫的新書《SOD框架“企業級”應用資料架構實戰》裡面的【6.3.3 業務分析三維度理論 】，如下圖。

2、程式設計的癥結

    回到本文標題，大家可能有疑問，寫文章和寫程式是一回事嗎？怎麼能用寫文章的方式來寫程式！

    的確，寫文章跟寫程式有很大的不同，然而這種不同是基於我們天天使用的面向物件程式語言（OOPL）上的一種感受，面向物件其實跟面向過程程式設計都是屬於“命令式”程式設計，也就是程式設計師必須告訴計算機每一步要如何做，細化到做這一步是用分支語句還是用迴圈語句的語言細節，這樣解決問題就需要大量的編碼，有時候程式碼量太大而不得不依靠各種架構或者設計模式來幫助人們理解複雜的程式行為，然而這些架構或設計模式卻並不是軟體工程師之外的人非常容易理解的事物，儘管工程師聲稱他們有詳細的文件，也有“統一的模型語言”--UML，但事實證明UML並不成功。

    我們說話的方式可以分為命令式、陳述式是虛擬式（參見原文）。命令式是說話人施加給他人的意志；陳述式是如實的反映不以人的意志為轉移的客觀事實；虛擬式表達人的主觀意志或者判斷。例如，一篇文章中如何描述有關“國家的印象”，不同的語式分別如下：

• 命令式：
  • 　　“給我講講你們對這個國家的印象”。
• 陳述式：
  • 　　“他給我講了他們對這個國家的印象”。
• 虛擬式：
  • 　　“我希望你給我們講一下你們對這個國家的印象”。

    在實際的對話中，命令式交談有點像領導讓下級彙報工作，領導會不斷問下級各種工作細節；陳述式交談有點像一個朋友傾聽你講的一個故事，你只管講，我聽著就行；虛擬式是你希望瞭解某個事情但又不能以命令的口吻，你們之間是一種平等的關係，所以只能用這種委婉的語氣，實際談話過程與命令式交談是類似的，只不過語氣不同。所以，我們重點只需要區分命令式和陳述式兩種說話風格，命令式關注你怎麼做（要不怎麼反映你的意志），陳述式關注你做了什麼，或者你將要做什麼，也就是更加關注做事情的結果。所以，你寫一篇文章，或者寫一本書，為了激起讀者的閱讀慾望，就應該更加關注你寫的文章“要寫什麼“，“寫了什麼”，“主人公做了什麼”，雖然你也會用很多篇幅去詳細描述這個問題具體是如何做的，但一定要用特別的段落、醒目的標題去表達前者。這恐怕是現在程式設計師覺得寫程式跟寫文章最大的區別之處：無法直接通過程式源碼錶達這個程式要做什麼或做了什麼，原始碼也沒有什麼“程式標題”，那是“需求說明文件”乾的事情。

    上面這個問題，是我們在程式設計中遇到的一個根本問題。我們深陷於程式設計的程式碼細節，而不能直接告訴計算機我們想要什麼。它們要求你去描述如何做，而不是做什麼。在你能叫得出名字的任何一種語言裡，程式是一個對能計算出你想要的東西的處理過程的描述，而不是一個對你想要的東西的描述。作為程式設計師，我們用程式碼解決問題。我們應該能夠用程式碼來表達我們想要的結果，而不是想要達到這種結果需要的過程。這才是癥結所在。這段話來自於《也談程式設計改革》，我們是應該面向過程，還是面向結果的程式設計。而提出這個問題的作者Jon Beltran是一個西班牙程式設計師，作家，企業家，他說：“I want to fix programming - 程式設計改革”。

  3、程式設計正規化

    這個問題是一個程式設計“正規化”問題。與說話的方式或者寫文章的方式對應，我們的程式設計正規化也可以分為“指令式程式設計”、“申明式程式設計”、“函數語言程式設計”、“邏輯式程式設計”等。

• 指令式程式設計--主要思想是關注計算機執行的步驟，即一步一步告訴計算機先做什麼再做什麼。
• 宣告式程式設計--是以資料結構的形式來表達程式執行的邏輯。它的主要思想是告訴計算機應該做什麼，但不指定具體要怎麼做。SQL 語句就是最明顯的一種宣告式程式設計的例子，HTML，CSS也是這樣的例子。
• 函數語言程式設計--和宣告式程式設計是有所關聯的，因為他們思想是一致的：即只關注做什麼而不是怎麼做。但函數語言程式設計不僅僅侷限於宣告式程式設計。
• 邏輯式程式設計--設定答案須符合的規則來解決問題，而非設定步驟來解決問題，過程是事實+規則=結果。

    有關內容請參見《程式設計正規化：指令式程式設計(Imperative)、宣告式程式設計(Declarative)和函數語言程式設計(Functional)》。個人覺得，LINQ有申明式程式設計的特點，VS編譯器將LINQ編譯成一些列物件的函式呼叫，背後又是函數語言程式設計的風格。SOD框架的ORM查詢語言--OQL也採用了函數語言程式設計的風格，通過一些列的物件函式鏈式呼叫實現，具體可以參見《ORM查詢語言（OQL）簡介--概念篇》一文。

 4、三維度理論

    我在 2013 年提出了《業務分析三維度（場景+角色+時間）理論》，嘗試從場景維度、 角色維度和時間維度來分析問題，從而提出了一套分析業務的方法論，以下簡稱“三維度理 論”。其實這個方法就是記敘文三要素（環境，人物，主要內容）的進一步抽象總結。我發現，記敘文三要素的環境類似於場景概念，人物類似於角色概念，事件的主要內容就是角色在場景中互動的各種資料。這個過程跟DCI架構的理念很相似的，如果從這個角度來看，那麼 DCI 架構就是我們寫記敘文的模式了。既然DCI架構是一種程式架構，那麼反過來說，我們用寫記敘文的方式來寫程式也是完全可能的。 在記敘文三要素的基礎上，有記敘文六要素的概念，指的是時間，地點，人物，事情的 起因，經過，結果。我對此進一步抽象總結，提出了“三維度理論”，場景就是六要素中 的地點，角色就是人物，時間對應六要素的時間，記敘文中事件的起因、經過和結果，就是 場景、角色在時間維度上面的投影。如下圖所示。

      我們用這三個維度來分析業務系統，這種業務分析視角，更符合人的一般思維模式，讓 人容易理解，因為人本身就是在不斷地扮演各種角色做事情的，因此，業務專家也很喜歡這 樣的工作方式，做業務分析，然後跟受眾講解業務細節問題，這個“工具”，就像是業務專 家手裡的三維“顯微鏡”一樣。場景、角色、時間，這 3 個維度，就抽象、立體的把業務描 述清楚了！這個道理可能太淺顯了，所以很少看到有人系統的來論證它，我把這個東西總結 為“業務分析三維度（場景+角色+時間）理論”，後面簡稱為“三維度理論”。
    人們總是侷限於事情的表象，製造出很多複雜的事情而又無法掌控這些事情。如果要化 繁為簡，就需要深入事務背後的機制；要找到這種機制，就需要進行較高層次的抽象，通俗 的說法就是形而上學， 由點到面，由一般到特殊這些思維方法。這個過程抽象出來的模型， 可以用場景，角色，時間三個維度去觀察，分析；甚至，直接用這三個維度去為這個抽象建模。 有關三維度理論的詳細內容，請參考筆者的部落格文章《業務分析三維度（場景+角色+時 間）之程式設計師坐禪論道》。

  5，三維度程式設計模式

    上面說到三維度理論是一個用來進行業務分析的理論，如果業務分析的結果能直接對應一套抽象模型，而這個模型又能用程式程式碼表達，那就意味著我們完全可以用寫文章的方式來寫程式，即這樣一種程式：描述業務中的物件、描述業務場景、描述參與場景的物件角色、描述角色物件或者場景在時間中的相互作用，回答系統中有關的問題，角色參與場景活動的開始、經過和結果，回答角色相互之間的關係。。。用這種方式來寫程式，跟寫一篇記敘文就很相似了，寫記敘文可是每個小學畢業的人都會的技能，這樣差不多人人都可以寫程式了。

    總結一下，上面理想中的寫程式的過程其實就是在定義規則，這種方式正是"邏輯程式設計"的正規化。為了實現這個目標，我將要“發明”一套“三維度”邏輯程式語言，不管算不算髮明，先打個引號再說。今天的話題設計了太多的程式設計理論概念，需要讀者先消化一下這些概念，再下一篇，我將一個“遊戲人生”的故事，來詳細介紹這門“程式語言”的設計，先放圖，敬請期待。

注：此圖內容來自於筆者今年出版的新書《SOD框架“企業級”應用資料架構實戰》中的【6.3.3 業務分析三維度理論 】內容，已經購書的朋友可以搶先看到這部分內容，還沒有購書的朋友可以點選前面書名連線瞭解。