paasone的創新(2)：separated langsysdemo ecosystem及demo

本文關鍵字：visual demo driven debugging，engitor編程，更好用的qtquick

接《demo as engine,post as app – passone:engitor+enginx之於通用軟件開發/部署/運營/實踐教育的創新意義》文，咱們說到engitor可視做是enginx針對於語言系統分佈化的一個特例，能夠按enginx針對通用服務器程序分佈化的方式打形成「分佈式語言系統」（好比分離出ternoda和language kernel服務端，做成enginx下的子服務組件使之更合理化），咱們還說，engitor是個自然的IDE編輯器(除了提供的qtconsole as language shell only還能夠開發更多的編輯器服務as enginx組件，甚至強大到相似photoshop或遊戲世界編輯器visual editor的那種 -not offline,but ingame editor)。編輯器也就是engitor一詞」itor」主要的所指，其對於

1，運營級UGC的代碼內容製做
2，語言/演示級隔離（能夠將開發生態從偏重語言爲中心的語言庫/包級下放到以應用爲中心的插件/擴展/api級）
3，編輯器帶來的另一點優點：那就是可視化調試。
對於這三者都是重要的，這一切都是不斷整合的的結果(engitor整合了編輯器,enginx整合了服務器子組件IO)，然而是合理的整合：綜合上正如前文所講，」基於engitor的paas化」使開發下放，造成一棧結構，可使全部的APP工做者維護一套套CODEBASE和工做在一套套DEMOBASE上。

前文主要講的是1，本文重點說說2，3：

engitor之於規避腳本語言愈來愈大被當成系統語言的怪圈：分開語言生態與應用生態

腳本語言中，講使用範圍最廣的，除了java就是py了。。JS也在跨三界興起(native,web,mobile)，然而它們都走了一條病態的生態之路。那就是應用引擎和語言引擎不分。拿js來講,,對於開發者來講，每個 package 就是一個 「micro service」，是最小重用單元。大部分的 package 只有幾百行代碼，甚至有些只有幾行代碼。這樣的重用粒度是在其餘社區不可思議的。 ——————- 然而JS將這一切作到了包管理內和社區repos裏做爲語言庫，但其實，相似py，JS npm這種什麼問題域的東西都作成庫的作法其實也很差。拿js cms開發來講，不須要存在demolvl的wordpress的等價物，由於它一切3rd plugins都做爲mircoserive被貢獻到了npm，做爲語言生態而非demo生態存在。與語言包結合更爲緊密些。。

而咱們之前說過，問題域擴展會愈來愈多，一個應用棧系統支持，語言支持層應保持短小，demolvl engine應愈來愈大。而不是反過來，而腳本只應被宿主偶爾調用，不該造成本身寵大的生態。由於它不宜做爲通用面向語言解決通用問題（所以須要配備這麼大的包），而應欠入到具體問題，做爲demolvl小包或熱更層或engitor用戶支持modable層。

腳本只宜被欠入被一個宿主擁有，圍繞一個通用複雜度應用的混合語言選型中每每有二種語言，一系統語言一門腳本語言，不該出現二門寵大系統語言。腳本只應被宿主偶爾調用，不該造成本身寵大的生態。不然就是系統編程語言了，由於它不宜做爲通用面向語言解決通用問題（所以須要配備這麼大的包），而應欠入到具體問題，做爲demolvl小包或熱更層或engitor用戶支持modable層。

在這方面，php比py,js的生態要好。php自己很小。沒有一個包含XXX，XXX庫的大全發行包，它的擴展也基原本自thin dll wrapped native dlls，lua看來也是標準意義上的腳本語言啊。。由於它不通用。也不須通用。也不宜通用。
做爲一個初學者，一門好的工程語言，其實他的惟一門檻是學完了語言就能夠開始編程（編碼）—或許還要加一個調試支持（設計能力和抽象問題的能力只要不是太複雜你們都會有），語言的類庫毫不是你學習一門語言必備的，你沒必要通過學類庫(甚至包括標準庫)完成編程學習庫只是語言的addons。始終要記住：一門好的工程語言，它應假設初學者和非初學者在面對問題時全是隻會語言語法和手頭只有api可用的「api kits」。

engitor就提供了一個隔離層，它使任何語言的庫分離在這個隔離層之下，向用戶明確表示，上面的語言層很thin，而問題層的擴展能夠無限fat，qtcling中，只有一種主語言那就是qtcpp，cling出來的部分是附屬於具體應用的。qtcling能夠任意免binding做系統語言和腳本語言切換的可能（由於它只有一種qtcpp語法），使一切邏輯不致於彙集到腳本層，僅熱更和動態部分須要下放。

可視化editor能帶來visual 調試

只要有調試，我就能編程，根本無須太依賴語法與問題，調試在編程中的做用大約除了編碼就是調試，大約在這裏要對應前面那句再加一句:一門好的工程語言，它應假設初學者和非初學者在面對問題時會迅速找到調試工具和調試支持，並假設語言語法和調試是二個最基本的充要門檻。

但是顯式的調試支持每每沒有工程上的支持，之前是CPP之於彙編，不可視，就是黑乎乎的彙編，如今是js之於WEB PAGE，完成可視化類photoshop，直接整合進語言所屬生態層的。非IDE工具。在敏捷編程中，test cases就是爲了做test(yet another form of 「debugging」 in programming engeering domain)做的測試設局 — 它用的是編程的方法，並且都沒有一個debug case之說。

engitor使dev進入demolvl時代，engitor整合任意應用爲編輯器，由demolvl驅動，就使該應用debugging過程進入了一個真實的demo環境，在其中做debug徹底是demo驅動的，就像gui之於visual debug同樣，也像chrome的F12調試語義CSS同樣，一句話，engitor編程，自帶debug cases且無須編程。這纔是engitor編程的最大意義。

1dddemobase and 1dddebugbase > 1ddcodebase：一個更強大的微實踐選型

咱們在前文中說到,paasone爲開發創建了一個視具體應用爲開發發佈生態的「1dddemobase」，但咱們真的不該該爲一門生來用做DSL的腳本創建一個相似js npm repos寵大的中間層「1ddcodebase」.增長了語言生態無謂的複雜度，這個1ddcodebase只宜是demolvl的codebase.

在前面的選型實踐中，我總想維護一個「1ddcodebase」，就像QT那樣，包含對語言改造支持，問題庫，IDE，本地系統編程，腳本擴展整個生態的支持。（這個生態是我認爲拿來支持編程教學和自學較爲完備的。爲何必需要加一個native langsys？雖然web,mobile開發已徹底不native相關，但由於咱們須要涉及到平臺相關部分。學習上這二代也有着緊密的承前啓後關係不可割裂。），尤爲是QTquick採用JS+利用web方案解決通用問題DEBUG無門檻的方式是極好的選型和教學範本（web編程和JS是調試設局最好的實踐環境和語言學習環境，微服務和微實踐——– 這一切都對應enginx和engitor作的工做） 。然而其中終究依賴了二門語言qt=qpp+js和生態，這就形成了割裂：離開了QT封裝的那些：qtquick那些優點就不存在。

基於qtcling的langone能夠用來解決這個問題。它就是更強大的qtquick，受enginx和engitor支持，langone結構和一棧web化結合將促成新的微實踐大局：

1，它將更加顯式化微服務和微實踐。2，它更強化1dddemobase而不是codebase，和langsys/app之間的開發生態分區：engitor paasone和langone支持下，語言選型談化了，app ecosystem demo選型也將一樣重要。3，qtcling是一門能夠將豐富的現有腳本語言binding進來做統一qtcpp編程的語言，能夠複用已有成果。做混合編程。

綜上：qtcling+enginx+engitor的組合將會是更好的實踐教學選型for beginners。

---

(此處不設回覆，掃碼到微信參與留言，或直接點擊到原文)