語言的界限就是一個人世界的界限
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
語言的界限就是一個人世界的界限
語言的界限就是一個人的世界的界限
— 維特根斯坦
Ruby on Rails的世界
很多人會告訴你, 學習不同程式語言能夠讓你看到新的世界, 改變你思考的方式, 在程式設計師修煉之道
我是從C++開始學習程式設計的, 大部分工作時間也是在用C++, 但是常常會受到一些人的’蠱惑’, 看到一些鼓吹某個語言好的文章後, 就會忍不住的學習這個語言, 然後理解一下為啥好. 再加上工作本身的需要, 已經學習了一堆的語言了. 但是, 沒有哪一次像這次學Ruby on Rails感受更多. 一般提到學習新語言的時候都會說離現在的知識越遠越好, 其實本質上就是需要你接觸到一個完全不同的環境, 進入一個完全不同的領域.但是我以前沒有太理解, 語言學了一大堆, 但是其實一直在做遊戲, 學個新語言吧還都去找找這個語言寫的遊戲引擎(或者用這個指令碼語言驅動的遊戲引擎)弄來弄去也就那麼幾個概念, 甚至於用的工具變來變去都差不太多. 當然, 在以前出現這樣的情況, 部分原因是我刻意的, 為了專注於遊戲. 這一次靜下心來, 好好的把Ruby on Rails學了過來, 雖然還並不是做純粹的網頁, 而是做一個客戶端的後端, 但是感覺已經和寫遊戲完全不一樣了. 其中最大的感受在於網頁開發領域的自動化程度之高, 讓遊戲開發簡直就像是還停留在上個世紀, 讓我都有些懷疑自己是不是還沒有接觸過真正牛的遊戲開發.
特別是Gem和Bundle. Gem這個Ruby的包管理系統真是太方便了, 發現一個新的庫? 簡單的gem install xxx就行了, 同時還會自動下載依賴的所有其他庫. 要加到工程裡面去, 在Gemfile裡面新增一行Gem 'xxx', Bundle install就行了. 聯想一下C++裡面怎麼在VS裡面加一個新的庫刪一個庫或者庫更新, 我都要哭了. 在C++裡面, 配置和載入一個大點的庫都可以單獨寫篇部落格了, 比如Boost, Qt啥的, 我還真寫過… 同時, 真正把Ruby當作一個平臺來管理的, 還有配套的Gem網站和ruby-toolbox
Ruby on Rails的世界以外
我的反應是, 其他的環境難道就沒有類似Gem的包管理系統嗎? 讓我慚愧的是, 原來真的有, 只是我從來都不知道而已, Python的pip, Objective-C的cocoapods, 最讓我驚喜的是, 還有類似Bundle思想的Vim的外掛管理Vim Bundle, 從這個名字就知道這個哥們是從哪學來的這種自動化管理思想了. 值得思考的是, 為什麼我一直不知道它們的存在, 僅僅是因為我孤陋寡聞嗎? 我幾乎是與學習Ruby同時就知道了Gem, 因為幾乎每個第三方庫都會告訴你用Gem來安裝, 而其他語言不是… 這就是生態系統的差異. BTW: Gem從Ruby1.9開始, 就已經內建在Ruby了.
C++的世界?
ObjC都有了cocoapods, 那C++呢? C++因為本身跨平臺的負擔, 各類庫的編譯方式各式各樣, 再加上歷史傳承原因, 老舊並存, 從原始的makefile, 到autoconf, 到稍微新一點的CMake, 甚至還有用ant的, 編譯器也有VS, g++, llvm等幾家了, 要做一個讓第三方庫能通用的包管理, 就我的想法幾乎是不可能的, 但是針對特定環境的, 比如針對Windows的VS, Linux/Unix的G++等, 還是有可能的. 有意思的是, 還真的有, 雖然好像都不成熟. 找到一個所謂windows-package-manager, Npackd好像能下載一些庫, 不可思議的是, 這些哥們竟然還特意開發了一個UI… 真是思維的差異啊… 難道大家都認為沒有UI的東西在Windows上就不會有人用嗎? 因為Windows那爛的不可用的shell嗎? 支援VS的NuGet, 不過好像專門用於管理.Net, 悲哀. 在這個過程中, 我還發現了Apache Maven, 一個Apache發起的用於JAVA的包管理工具.
不用懷疑, 結果是很明顯的, C++還沒有一個稍微成熟點, 到可用地步的包管理工具, 不管是VS裡面還是g++上, 也是因為這樣原因, 我在學習Python的時候, 甚至都沒有考慮到去找類似的工具… 其實easy_install和pip的成熟度還是較高的, 但是從C++來的思維方式, 限制了我, 這是我現在的真實感受. 回憶起開發的過程, 在VS中配置一個工程真的是一個痛苦的過程, 以至於沒有一點經驗還真幹不了, 並且還容易出錯, 格式, 目錄什麼的要是亂了還影響後來的開發, 因為這個原因, 在我剛工作的時候, 即使是一個我自己從頭開發的全新服務端程式,(我是從服務端開始開發的)都是我們主程配置好了工程, 解決了一些自己庫和第三方庫的依賴問題後, 然後我再開始編碼的. 而這個服務端的程式配置, 是全手動的, 為了簡化, 是從一個我們自己做的模板上clone出來, 然後再去做調整. 到我帶團隊的時候, 初期也都是自己配置工程, 直到比較後期了才敢讓其他人來幹這個活, 儘管我早就已經對他們的程式碼相當放心了. 回憶一下這個過程, 就能知道這個過程有多麼痛苦了. 不管C++本身有多少負擔, 實際的開發過程相對於ROR來說, 的確是太原始了. 從以上的體驗來說, 儘管C++被大家公認來說是一個非常難學難寫好的語言, 但其實正確配置第三方庫和C++的工程甚至比寫C++本身來說還要困難…-_-! 可能正是這個原因, C++庫的開發社群有種反向的潮流, 那就是以自己庫儘量少的依賴第三方庫為優點, 簡單的來說, 你要依賴第三方庫太多, 配置太麻煩, 根本就不會有人願意用你的庫… 而這個, 假如有個好的包管理, 根本就不應該是問題. 這在某種程度上其實也限制了社群的良性發展, 每個庫都帶一堆的基礎庫算什麼回事啊. 這個問題在C語言中似乎更加嚴重, 因為連STL都沒有…
最後的感嘆
想起以前一個經典的C++程式設計師與Python程式設計師之間的爭論, 當時還感嘆中國人的吵架智慧, 見這裡, C++的使用者們(包括我)很多時候都把自己使用C++開發的效率低歸結為C++語言本身為了效率所做的犧牲, 即其本身的複雜性. 就如BS說的‘絕對複雜的問題需要相對複雜的工具來解決’. 事實上, 還有一部分在於我們的開發環境, 包括上面提到的典型的專案配置過程, 只是我們沒有意識到而已.
列表
這裡是我整理的一些包管理軟體列表:
- Ruby: Gem和Bundle
- Python: pip
- Objective-C: cocoapods
- Vim外掛: Vim Bundle
- Lua: LuaDist和LuaRocks
- javascript: cpm和jam
- nodejs: npm
- JAVA: Maven
- .Net: NuGet
- PHP: PEAR, composer, Maven for PHP
- Windows: Npackd
給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow
