用寫文章的方式寫程序--「三維度」邏輯編程語言的設計（1）

 一、 前言

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

 

 

二、編程的癥結

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

    的確，寫文章跟寫程序有很大的不一樣，然而這種不一樣是基於咱們每天使用的面向對象編程語言（OOPL）上的一種感覺，OOPL其實跟面向過程編程都是屬於「命令式」編程，也就是程序員必須告訴計算機每一步要如何作，細化到作這一步是用分支語句仍是用循環語句的語言細節，這樣解決問題就須要大量的編碼，有時候代碼量太大而不得不依靠各類架構或者設計模式來幫助人們理解複雜的程序行爲，然而這些架構或設計模式卻並非軟件工程師以外的人很是容易理解的事物，儘管工程師聲稱他們有詳細的文檔，也有「統一的模型語言」--UML，但事實證實UML並不成功。

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

• 命令式：
  • 　　「給我講講大家對這個國家的印象」。
• 陳述式：
  • 　　「他給我講了他們對這個國家的印象」。
• 虛擬式：
  • 　　「我但願你給咱們講一下大家對這個國家的印象」。

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

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

  三、編程範式

    這個問題是一個編程「範式」問題。與說話的方式或者寫文章的方式對應，咱們的編程範式也能夠分爲「命令式編程」、「申明式編程」、「函數式編程」、「邏輯式編程」等。

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

    有關內容請參見《編程範式：命令式編程(Imperative)、聲明式編程(Declarative)和函數式編程(Functional)》。我的以爲，LINQ有申明式編程的特色，VS編譯器將LINQ編譯成一些列對象的函數調用，背後又是函數式編程的風格。SOD框架的ORM查詢語言--OQL也採用了函數式編程的風格，經過一些列的對象函數鏈式調用實現，具體能夠參見《ORM查詢語言（OQL）簡介--概念篇》一文。

 四、三維度理論

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

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

  5，三維度編程模式

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

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

 

注：此圖內容來自於筆者今年出版的新書《SOD框架「企業級」應用數據架構實戰》中的【6.3.3 業務分析三維度理論 】內容，已經購書的朋友能夠搶先看到這部份內容，尚未購書的朋友能夠點擊前面書名連接瞭解。