關於視覺化程式設計分類的民間智慧 – drossbucket

banq發表於2021-07-02
視覺化程式設計ROS

駭客新聞中有趣的反覆出現的主題之一是視覺化程式設計。這是我真正欣賞 Hacker News 的事情之一。大多數領域都存在“鬼知識”的問題，這是來之不易的實踐理解，主要是在從業者之間口頭傳遞，而不是在任何地方公開。至少在程式設計中，其中的一部分會進入論壇帖子。它通常隱藏在大執行緒的深處，但這總比沒有好。
形式邏輯對更普遍的形式和技術語言感到好奇：我們如何在其他數學領域或程式設計中使用文字的屬性？文字擅長什麼，不擅長什麼？視覺化程式設計的評論執行緒被證明是探索這個問題的好地方。
如果某件事在文字中很容易，但在特定的視覺化程式設計工具中卻很困難，你可以保證有人會抱怨它。其中一些抱怨是相當膚淺的，但有些則涉及到文字的一些相當深的屬性：線性、資訊密度、離散符號的字母表。相反，對特定視覺特徵的熱情可以很好地表明文字的不足之處。
文章其餘部分的基本結構如下：
  • 對這些執行緒中評論者通常所說的“視覺化程式設計”的含義進行細分。這是一個相當廣泛的術語，人們對它的理解非常不同。
  • 共同主題。這是這篇文章的主要內容，我從中提取了多個執行緒中出現的主題。
  • 一個簡短的討論型別部分，其中包含在撰寫本文時想到的一些初始問題。有很多方向我可以接受，這篇文章已經足夠長了，沒有詳細討論這些，所以我只是含糊地揮一下手。可能我最終會至少寫一篇後續文章，以在我對這些問題進行更多思考時找出其中的一些線索。

 

視覺化程式設計的型別

  • 基於節點的介面

有大量的視覺化程式設計工具大致處於“帶有箭頭的框”的正規化中,我認為這些的技術術語是“基於節點的”，這些工具中的大多數是主要用於特定領域的專用工具。這些領域反覆出現：實驗室和工業控制。LabVIEW 是該類別中討論的主要工具。事實上，它可能是最常討論的工具，吸引了相當多的咆哮，但也吸引了許多捍衛者。
  1. 遊戲引擎。虛幻引擎的藍圖可能是第二個最常見的話題。這是一個視覺遊戲指令碼系統。
  2. 音樂製作。Max/MSP 作為連線和修改音訊剪輯的工具出現了很多。
  3. 視覺效果。Houdini、Nuke 和 Blender 都有用於建立效果的基於節點的編輯器。
  4. 資料遷移。SSIS 是這裡的主要工具，用於遷移和轉換 Microsoft SQL Server 資料。
  5. 其他被提及的工具包括 Simulink（基於 Matlab 的動態系統建模環境）、Grasshopper for Rhino3D（3D 建模）、TouchDesigner（互動式藝術裝置）和 Azure Logic Apps（結合雲服務）。

  • 基於塊的 IDE

這個類別包括像 Scratch 這樣的環境，它們將一些普通程式設計的語法轉換成可以插在一起的彩色塊。這些通常用作新程式設計師的教育工具，尤其是在教孩子時。
這可能是人們所說的“視覺化程式設計”的第二個最常見的東西，儘管關於它們是否應該計算存在一些爭論，因為它們主要複製了普通的基於文字的程式設計的約定：

Scratch 是一個用於傳統程式碼的快速組合 UI。僅僅因為程式設計文字嵌入在可拖動塊中並不能使其成為一種視覺語言，它是文字編輯器的不同 UI。當然，它的視覺效果，但它實際上並沒有以任何方式改變語言。它可以像文字一樣容易地表示，語義是相同的。它基本上是一個更適合初學者的以滑鼠為中心的 IDE。

  • 拖放式 UI 構建器

拖放式 UI 構建器出現了一些，雖然沒有我最初預期的那麼多，並且通常沒有命名任何特定工具（Delphi 確實得到了一些提及。）特別是關於新作物的討論很少無程式碼/低程式碼工具，我認為是因為這些執行緒中的大多數都早於當前的炒作浪潮。
這些工具絕對是視覺化的，但不一定非常程式化——它們通常用於製作一個特定的佈局，而不是一個動態範圍的佈局。UI 設計的視覺方面往往會與指定動態行為的能力發生衝突：
這個特定領域的主要挑戰是描述當視窗大小發生變化時佈局應該發生什麼，或者視覺元素之間是否存在依賴關係（例如，某些元素僅在選中核取方塊時才會出現）。在視覺上佈置事物時，您只能設計一個特定的佈局例項。如果你的所有元素都是靜態的，這很好用。但是，如果佈局以任何方式是動態的（調整視窗大小是最常見的情況），您現在必須要麼描述當事情發生變化時您希望發生的事情，要麼讓系統猜測。並且有很多選項：縮放、裁剪、信箱、溢位、“智慧”迴流……可能性是無窮無盡的，因此描述所有這些複雜性通常需要完整的程式語言。
這些工具還具有較少的離散化、結構化元素，通常與程式設計相關聯——例如，基於節點的工具仍然具有可組合在一起的允許框和箭頭狀態的離散“語法”。UI 工具相對連續且非結構化，其中 UI 元素可以調整為任意畫素大小。
  • 電子表格

電子表格是一種視覺化程式設計正規化，這是一個非常成功的正規化，這是一個很好的論據：
我認為電子表格也有資格作為視覺化程式語言，因為它們是二維和基於網格的，而一維文字程式語言則不然。
網格使他們能夠使用相對和絕對 2D 定址，因此您可以在單元格之間複製和貼上公式，因此它們是可重用和可重定位的。您可以透過指向、單擊和拖動來輸入地址和運算元，而不是（或也）輸入文字。
  • 基於文字的程式碼的視覺增強

作為自己的信徒，我認為問題在於視覺化程式設計遇到了與人工智慧詛咒相同的問題：
“一旦人工智慧中的問題得到解決，它就不再被視為人工智慧，因為我們知道它是如何工作的。” 
同樣，一旦成功的視覺化互動功能（無論是語法高亮、逐步除錯的跟蹤檢查器、“智慧感知”程式碼完成……）被 IDE 採用併成為主流，它就不再被認為是“視覺化的”，而變成經典“文字程式設計”不可或缺的一部分。
有幾次關於視覺化工具的討論，透過除錯跟蹤、依賴關係圖、繼承層次結構等更好地理解普通的基於文字的程式。同樣，這些大多僅限於幾個子執行緒，而不是“視覺化程式設計”的中心示例。
一些人還指出，即使是純文字檔案中的基於文字的程式設計也有許多視覺元素。人類編寫的程式碼不是線性的位元組串，我們使用縮排和空格以及視覺上與眾不同的字元：
括號是一個很好的例子——它們向它們所包圍的文字彎曲，以視覺方式加強語義。
  • 實驗性或推測性介面

在括號和縮排的另一端，我們有全新的實驗性視覺介面。Bret Victor 的 Dynamicland 和其他實驗經常在這裡提出，以及對 VR 帶來的可能性的猜測：
只要我們在推測：我有點夢想也許我們會看到利用 VR 的程式設計環境。
人類真的很擅長記住空間。（“給我描述一下你童年的臥室。”或“你的三年級老師長什麼樣？”）
已經有“記憶宮殿”的想法表明您可以將空間記憶用於其他目的。
我想知道，透過瀏覽程式碼庫並環顧四周來學習或搜尋程式碼庫會是什麼感覺？
這是最令人興奮的類別，但它是如此開放且未經測試，以至於很難說出任何非常具體的內容。
 

更多：視覺化程式設計

相關文章