關鍵字：自帶paas語言系統,自帶組件,自帶用戶工具語言系統，一元下的多元，初學者第一門實踐語言選型
在編程實踐選型上，往往涉及到來自語言，應用，工具，人（又分多種角色）多個方面的影響，需要處理多個現有生態異化矛盾和處理已有實現之間的差距，甚至出現需要重新發明語言等基礎設施間的輪子的情況都時有發生，是一個格局需要放大到軟件工程方方面面的過程。—–一言以概之：軟件工程，——-其實，大凡考慮進所有事情並最終處理涉及到人端的那些方面的事情都能稱為工程，可見其大和複雜，這也是為什麼很多圖省事的方案企圖提出一個“one for all”終極方案的原由所在。這個“one”往往可能被實現為開發上來講的一種/多種語言系統，一個包含語言修正/強化的framework（如qt），一個工具，一套問題域解法，一套敏捷方法，等等，當然更有可能是它們的綜合 —- 公司或個人將他們做成自己的codebase用於持久複用以應付統一選型。。
在《1ddlang選型》一文中歸納的是以前1-4種舊的純粹語言選型方向的“one for all”討論—lddlang也就是某種1ddcodebase，在那裡我們主要聚集語言內部特性。本文作為《1ddlang選型》，《語言選型簡史：快速整合產生的斷層》的系列之三，將繼續著眼於大的工程方面的綜合實踐選型。
那麼，有多少種oneforall？都有過哪些實現或案例呢？理想的oneforall呢,這樣的終極方案始終存在嗎？討論它有意義麼？
雖然被不斷懷疑，然而終極編程和“one for all”真的存在,它並不需要是類似編程葵花寶典之類的東西，我們可以理解讓編程體現為適可而止，有止境的境界，在工程上(編程上讓事情變得越來越容易最後不需投入或極少投入再學習成本)，通往其的方法可以有很多種，但一種無疑是那種—比如，某種直到腳本和可視編輯器級的工具級開發封裝。
如果編程方法可以歸結為一門最終的哲學，學者可以利用它舉一反三，完成自舉學習，那麼這種元性質的哲學，就是終極。
圖形界面的出現和DLL API機制，VB可視化，在這個意義上都是偉大的鋪墊作品，面向對象也是一種終極編程，它在語言內在抽象接近平民，各種OO範式，PME，再後來，框架容器，都是使編程變得終極的方法和基礎工作。這些只是整合而已，嚴格來說其主旨只有二點：
1）著眼於大的面向人的工程和實踐方面，首先要保證這個一體化方案必須是方案全包和self contained的（沒有斷層，不用跨越，，不用四處找方案）。必須是“一元下的多元”。比如統一後端語言系統要包含多種前端做到no binding。就可視作是此。
2）然後是平坦化（“多元下的一元化”）。能圍繞一門語言良性地建立起實踐的方方面面工程與選型，且所有其中的東西都是one style的no steeps，故這樣的方案必須要包含一門語言，一種部署方案，然後使這一切形成平坦化的。可能最終歸於一門語言系統級的封裝實現中。故最大整合，全包，又要求良性集成 – 儘量多用onestyle的抽象線索來整合並突出統一易用能用。才是其主要特點，而如上所講，一元下的多元，多元下的一元onestyle其實並不矛盾
也許最好的例子，就是我們熟知的WEB和web開發界中.net這樣的東西，WEB是一個涉及到運用雲計算這些最新軟件技術的領域，又運用了上述所有這些—-特別是語言上的開發技術，的地方如.net,js（當然還有更多…），是封裝最完善最統一的領域，可以很好拿來作為例子。
《編程的最高境界是什麼》：以web舉例，onestyle WEB開發與調試設局的編程實踐
WEB開發是現今最簡單的開發，沒有最簡，因為它就是最簡。
WEB前端開發門檻很低，因為在大量框架下，最前端的樣式效果開發（實際上不叫開發，叫界面配置）已經變成純粹的藝術行為了，因為它變成了debug and visual driven coding,或稱programming,而js用來編程前端html dom 和style elements，也可用同樣的調試和開發方式被調試。
而web app開發主要是處理一些服務性的api,雲時代不同應用通過service api交互，服務性API，js+xml（json,etc..）讓任何領域邏輯的開發編程，都變成都是界面編程下的邏輯(前端也是xml->html,css也有xml化的scss)。xml是數據化代碼轉領域邏輯的終極手段。
這二者是統一的技術一個可視一個XML語義化而已，使用相同的語言。這個層上的web開發就是一個充分經過了onestyle風格整合過程的多工程開發領域。這主要指問題域還有使用的語言，見下：
什麼是終極編程及最好的實踐語言，以js+.net舉例
在前文《語言選型通史中》中我們談到.net和JS，談到前者的統一後端特性和後者的跨三界開發。
1) js為什麼流行
a, 前端是一個對領域邏輯封裝得最完善的領域，包括桌面GUI，HTML，網站模板技術，MVC範式等。html標識系統，JS作為前端語言內部的適用性，源於web前端，也能應用成為mobile,native的前端。
b, 而js也可用於後端服務器甚至傳統native開發—當然這是非c runtime的而是jsruntime backend的（這屬web的“系統編程”了，實現編程，區別前面談到的service api應用），js+web有鮮明的one lang,one problemdomain solution的特點（這裡js是nodejs實現或emcs規範，它被廣泛用於服務端編程），雖然它只是在目前慢慢成為事實…。
你的第一門實踐語言，應該是類JS的，鬆語法描述，調試資源豐富，從界面到邏輯，一條龍，可漸進，先前端再後端再全棧，是實踐的最佳路徑和起點。這或許就是為什麼JS是越來越多地成為最佳實踐語言的原因根本
2) 再來看.net和web的後端，系統編程和實現方面：面向多種定製化的平臺，包括工具在內的全生態self contained
因為clr平臺提供了最基礎的後端和組件環境，包括語言服務，平臺後端，工具在內的東西都可以定製成self contained的，可以說，統一後端，將原來native開發上可用的東西全弄到可託管後端支持下:
a, 統一後端，也是統一了平臺，跨mobile,web,native desktop,是第四代語言最鮮明的特徵。
(與traditional c runtime backend nativedev分開,在這裡，桌面開發分native上的桌面開發，和託管到.net clr上的桌面開發，.net上有自己的封裝版本，所以這是另外一種全功能的跨desktop,web,mobile託管平臺。不對native開發斷層。)
b, .net 可以直接調用語言服務，甚至新的語言完全可以通過dropin語言前端的方式放置的方式安裝。因為在.net統一後端下服務即組件所以接入了後端的語言前端只是普通組件可按普通API方式調用。
c, .net這樣的框架為IDE提供了一個統一。使得sharp,mono,vs這樣的東西不致於存在像本地編譯器那樣的鴻溝，比如不必安裝巨大的本地sdk，大家可以共用一套runtime（由於.net runtime即組件，組件即源碼標準庫，不必發佈巨大的sdk），sharp,mono可以僅面向託管碼，調試，智能提示可以輕易做得跟vs一樣強大。
這點使得用戶維護一個屬於他們自己的，且跨三平臺統一的codebase,runtime,ide,甚至一切成為可能並可打包帶走。
它是一種根本上的遷移。只要是在遷移之上的東西，都是self contained.taken alway的。
架構已定，用戶入階和工具支持方面：
如果說選型已定（包括OS支持，語言，語言強化，服務端引擎，具體應用體系 — 這些往往被做在了一體化的語言或統一後端中，或PAAS環境中），那麼這裡就是尾端APP開發。由於問題域實在太複雜太多變太廣泛，很難有大全的編程套件能兼顧覆蓋全部領域，而.net這樣的統一後端能容易裂變成子集又有社區包管理，能最大程度地向無架構APP開發靠攏。
充分的複用支持和應用域實現及工具級支持 —- 但這也是在當今時代，複用二字，是用戶需要學會用他們解決問題的最基礎方法和唯一手段，也是使用任何語言最基本的素養要求：.net開發只是設想你會任何一門它支持的語言，即使是vb.net或是某brainstorm。
1) engitor無架構APP開發：
全生態+無架構是微實踐的基礎。因為只有做到了無架構，才能避免在用戶開發APP層級還進行復雜設計的必要，才能到達微實踐的地步。架構和設計已在前面的語言整合中被解決了。
用戶開發應該是二次開發，無架構，平坦式複用，，，而大部分時候我們都是在進行二次開發。以軟件為體系進行該軟件之下的擴展開發，形成的應用叫APP。那種帶設計的大型開發，要麼是重造輪子，要麼是更復雜一點的二次開發而已。
比如，OO就是語法代碼級的擴展。和二次開發。是語言級對開發是一層層堆棧或剝棧的事實反映，迭代是最安全的類OO之於demo繼續演化的工程行為行為，也強調繼承了以一點點疊加慢慢發展的思路。因為從抽象上說，軟件本質就是棧的添加修正行為。所以，結合《編程實踐養成過程反推式》：demo演化，也是編程。只不過它處在工程明顯的地方，即尾端。
所以，用戶設計中，應該儘可能地避免複雜設計和規模過大的問題封裝。（導致的語言應用過於複雜和問題封裝問題）那種為了特定問題提出一套語言特性的做法更是不可取。語言核心應該穩定，不應該從下而上地變，雖然從上而下地變是可以的。更不應該透給用戶編程層。
2) 微實踐：
在以上架構下，實踐者僅要求有的基本素養，1你不需要懂太多，在你能控制的複雜度內幹正確的事；2假設在新API面前，每個人都是腳本工具小子，這樣就夠；3,懂得適當的邏輯歸類，甚至免OO，比如，你不習慣用OO，完全可以用編輯器或者用統一後端支持下的僅支持過程函數在源碼文件中擺放編程的免OO DESIGN語言來編程。
一個能打包打包，在一個小時，一篇文章中講完教完的編程實踐才是好的自包含的微實踐課程。這對最初級的學習者也適用。
.net和js，它們都是onestyle的code and demobase(說demo是因為有組件，這個demobase是comopentbase)，js npm社區有幾行代碼組成一個庫的micro service存在。開發只是組合服務。
demo as engine+microservice開發興起了，所以1dddemobase > 1ddcodebase了，找類qt的那種開發庫組織1ddcodebase過時了。恩直接找大量第三方小件，雜亂的也行，只要搭出的demo具備好的facades就行了。
可複用件選型+小微開發，這一切得蓋於最良性的基建結構—語言選型部分。
(此處不設回覆，掃碼到微信參與留言，或直接點擊到原文)
