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 業務分析三維度理論 】內容，已經購書的朋友可以搶先看到這部分內容，還沒有購書的朋友可以點擊前面書名連接了解，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/106362.html
標籤：其他