為什麼很多人覺得Lua比C++簡單？

05-21

本人是先學的C++，然後學的Lua。感覺Lua雖然語法的內容沒有C++那麼多，但是反人類的地方太多了，大致上就是兩方面：類型的靈活性，和metatable的各種"妙用"。雖然自己寫的Lua代碼一般會保持類型的一致性，以及盡量避免使用metatable（基本上就是假裝自己在寫C++代碼），但是別人並不這樣做呀，於是就看到了很多奇奇怪怪的、看了半天也看不明白、甚至不知道從哪裡開始調試的代碼。
所以為什麼很多人覺得Lua比C++簡單呢？C++雖然語法複雜，但是各種語法規則的限制使得程序員無法過於"自由"，而且面向對象的語言特性也是符合人類思維方式的。舉個不恰當的比方：圍棋的規則比國際象棋簡單許多，難道圍棋比國際象棋簡單？須知直到去年人工智慧才在圍棋方面戰勝人類。
所以我覺得基本知識點內容的多與不多，跟這門語言是否困難，並沒有必然聯繫。理論上來說，我覺得Lua的那些自由的特性如果濫用的話，很容易寫出誰都看不懂、調試起來也十分糾結的代碼的。當然，要讓Lua用起來簡單、容易讓人理解也是有辦法的，就是事先約定一些規則，在寫代碼的時候要盡量遵循。
不知道各位知友有何見解？

感覺上你是先入為主，學習了 C++ 之後，希望學別的語言也使用 C++ 那套思維方式，當出現不同的時候就覺得比 C++ 難。

如果更客觀一些去比較難度，可能是讓未學過這兩種語言的人，學習並完成相同的題目，看看平均而言學習哪一個更快一些。

因為你在用C++的套路去寫Lua，關鍵你是還想用C++的思路去理解Lua。最關鍵的地方是你C++學得還不夠，理解都沒到位。

Lua的一個很好用的地方就是metatable，你偏偏不去用，唉。

C++也有很多鬼畫符的寫法，你大概是沒見過。

謝邀。

我覺得題主你所理解的簡單是有問題的。講道理 Lua 實現了一個幾乎最小而且完整的動態語言核心。而所謂的metatable這種靈活的東西，也更是為了減輕額外的一些設計負擔採取的約定性的東西。但是這種靈活性拿出來不是給任何人都能用的，必然也要做一些取捨和限制。

另外至於所謂的 C++ 的規則和限制什麼的，BS 當年都說過，C++ 是不會限制使用者的風格的，也就是說，欽定了你可以自由自在的瞎jb寫，而且標準委員會會給你語言特性級別的支持。

於是瞎jb寫你用 Jawa 也能寫出非常難調試的代碼，所以這隻能說是人，或者說團隊協作的問題，不能怪到語言上。畢竟 C++ 配合 structural typing 也一樣寫的出來不好跟蹤的代碼（不好跟蹤的一個原因甚至是根本都不給你調試的機會，比如模板）。

關於那個類比，我覺得更是沒道理。如果說 Lua 是圍棋（如果我沒有理解錯你的意思），那 C++ 其實是在圍棋棋盤上用黑白子實現了的圍棋+象棋+軍棋+跳棋。你玩起來覺著像象棋，是因為你只了解了象棋的規則而已。

另外可以建議題主了解一下 Lua 社區的一些其他工具，有些是加了 gradual typing 限制的（類比 TypeScript 之於 JavaScript），也許能夠某種程度上滿足你的需求。

以上。

因為的確比較簡單。比如我最近在寫一本書，《自己動手實現Lua：虛擬機、編譯器、標準庫》，目前初稿已經寫完了，預計下半年出版。由於Lua很簡潔，所以才有可能在一本不太厚的書裡面同時覆蓋虛擬機，編譯器和標準庫這三個主題。你換成C++試試。

我們一個幾年的C++同事對python的評價跟你對lua的評價大致差不多。都用到了一個詞「反人類」

開發項目總是分人的，底層框架怎麼複雜怎麼玩都是核心人員的事情（拿C, C++做核心，Lua做應用層也一樣），評價好不好用應該看寫應用層的。應用層或者業務層需要學習的越少，業務邏輯占代碼的比重越高，那麼這語言越簡單，從這個角度而言，Lua肯定是比C++簡單的。

Lua的元表，環境等提供的可定製性很高，全強類型方式編程也是可行的，這算是一門半完成的語言，而剩下的一半純看應用平台的核心設計人員打算如何使用它。我現在用Lua遵循一個規則，框架強類型OOP，應用層FP，只要確保寫應用時不需要使用元表等技巧，那麼可讀性和調試都就都不是問題。

lua的簡單：犧牲的是運行時的效率，換來的是開發時的簡單。優點：代碼簡潔，代碼量少，因此而易於理解。代碼少也就意味著容易維護、修改。缺點：編譯期難以發現bug，問題不容易暴露。

c++的複雜：開發時的複雜，換來的是運行時的效率。優點：性能好，可以控制的細節多。很多問題在編譯期就會發現。缺點：語法越發複雜，語言太豐富造成掌握起來困難，因此學習成本高，團隊協作難以統一風格。

最好的方案是：變化小的核心部分用編譯型語言比如C／C++完成。

變化頻繁的業務部分用解釋型腳本比如Lua、Python完成。

這就是簡單與複雜的完美結合。

總結就是：同意題主的大部分觀點，確實存在這些問題，所以，揚長避短、合理安排才是正確之道。

因為Lua就是比C艹好寫啊

Lua你不需要關注對象的回收,甚至連迴環他都能回收

你可以把table當作類使用,可以當作數組使用,可以當作結構體使用

table還可以方便的指定各種元表,_index,_newindex 等訪問規則

至於這些元表如果你覺得不好用,你甚至可以完全不用它們啊

C艹幾年就出一個新版本,前幾個版本的新特性都還沒掌握就又來新的了永遠都學不完指針跑飛了內存泄漏了都說不準

但真要說lua比不上的,應該就是調試,腳本的調試比起java c++等還是缺乏那樣強大的ide

狂野的力量~！！你駕馭不住~！！

樓上都答的差不多了我來抖個機靈

因為在Lua裡面，原先由C++編譯器來負責的類型檢查，都需要程序員用自己的大腦來檢查，所以如果按照使用C++的思維來使用Lua，就會發現，大腦憑空多了一筆類型檢查相關的龐大負擔，自然覺得Lua太不嚴謹、用起來太累人了。

如果能把思維放開，不要太在意那些細節，把腳本運行出錯看成是另一種形式的自動類型檢查，就可以輕鬆很多了。

lua語言簡單在於沒有過多的語法和特性，

靈活在於有足夠的metatable支持，可以模擬一其他語言的操作，

困難在於使用者期待寫lua和寫面向對象語言一樣，搞一套繼承，抽象出來，

死板在於使用者認為所有語言都必須面向對象。

以前我也喜歡搞一套繼承到lua裡面，讓自己感覺良好，以為降低了編程門檻，現在回過頭來看，簡直自找麻煩。

這個世界上還有函數式編程語言，看了語法以後可能更覺得反人類，但卻是在某些領域表達力很強的語言。

1、語言難易，跟學習成本有關。C++開始一個Helloword需要好多知識的，編譯環境開發環境都很複雜，相對lua就簡單多了。

2、Lua類型太自由,可以通過名字來得到區別，只要命名規範，這個根本不是問題。

3、c++有類、對象、指針、線程，完全掌握還是需要蠻久的

個人覺得，lua和C++是很難比較的，動態語言和靜態語言的設計目標不一樣，即他們適合的領域是不同的，適合C++的地方壓根用不了lua；適合lua的地方也通常不會想去用C++實現。所以如果總結成：簡單的業務適合用lua開發，複雜的需求適合用c++開發，可以理解為Lua【開發業務】比C++【完成需求】簡單。

而別人說的簡單，另一方面，通常是容易上手：比如同是從網上下載一份代碼，lua直接可以run，而C++、特別是帶vs的solution那種，可能要配半天環境還不能編譯；換個OS，又不能編譯；甚至換個編譯器版本就不能編譯了。。。初學者當然覺得是lua簡單。

關於lz提到的幾點：

1.ide等工具的支持，從語言層面。lua基本靠肉眼識別，各種table寫起來爽，讀起來萬分痛苦；而c++有足夠好用的ide，加上靜態語法檢查，相對容易閱讀。

2.業務的複雜程度。語言像地基，簡單的業務像平房，可能一個人月就可以搞完；複雜的業務像摩天大樓，需要很多人共同參與，合作的複雜度和業務本身的複雜度已經超過了語言本身。從已有的遊戲業務研發經驗來看：為一個團隊制定lua語言的使用規則是非常重要的，即人為的加入許多lua本身不一定提倡的限制，來降低團隊成員合作的複雜度。

3.lua和c++都有炫技的人，c++的奇技淫巧只怕比lua更多更沒上限，不過多闡述。但是能把代碼寫得讓別人讀懂，也讓未來的自己讀懂，其實和語言本身的語法啊語法糖啊沒什麼特別大的關係。。。

lua不是這麼用的，當你的某部分代碼全部操作的都是哈希表，或者是需要自己做一個語言進行簡單的動態邏輯配置的時候，或者是某些動態的邏輯配置需要熱更新時，或者需要協程的語法時，用lua才能簡化你的部分開發。全部c++代碼都用lua寫那是自找麻煩。

可以去看看boost的實現？

不太確定提問者如何定義難易。如果以清晰易跟蹤論，靜態語言在類型上是有天然優勢的；如果是寫起來順手，動態語言又會更勝一籌；至於學習成本，語言細節顯然是C++更複雜，這就不贅述了。

以前看某個答案說的很好，「面向應然編程而不要面向實然編程」。如果一門語言為實現某個目標，需要付出更多精力去了解更深層次的事情，那麼它的學習成本可以認為是更高的。

你覺得簡單是因為你根本沒有實際在使用C++。實際做項目的時候需要懂得東西很多，不是學點語法就可以了。而且C++語法很複雜，你覺得不複雜是可能是因為你還在用C with class(雖然實際上這也沒啥問題)

說實話，都不好學！C語言在處理很多問題是很麻煩，而c++中指針也是一個容易出問題的關鍵，好不好學在羽你自己的理解和運用的能力，不過推薦你學C++，畢竟它是後起之秀，而且現在c++語言也在逐步淘汰中~~，其實你也可以考慮JAVA，相對容易點

這特么的C++簡單？你和我說C++簡單…？我沒聽錯？

因為Lua真的比c++簡單啊！