【轉載】C/C++語言分析 & 每一年學一種編程語言 & git歷史

http://blog.csdn.net/turingbook/article/details/1778867

《程序員修煉之路》英文註釋版

做者提出的經營之道是：
——Invest Regularly，不斷投資，聚沙成塔。
——Diversity，擴大知識面，多元化，減小風險，增長潛力。
——Manage Risk，控制風險，這點與上呼應，要注意結合學習短線和長線技術。
——Buy low，sell hign，低買高賣，尋找潛力股。
——Review and rebalance，多總結。

 

做者提出的8大目標，可能更有實踐意義：
——每一年學習一種新語言。

 

http://blog.csdn.net/turingbook/article/details/1775488

Linus和Dmitry關於git源代碼的C/C++之爭：

」若是你想用更花哨的語言，C++絕對是最糟糕的選擇。若是想要真正的高級特性，那就選擇有垃圾回收或
                  者好的系統集成的，而不是既缺少C的簡約（sparseness）又缺少C的直接並且沒有重要概念的高層                  
綁定（high-level bindings to important concepts）的東西。

        「一言以蔽之，C++正處在困境當中，它既沒法幫助原型化或者簡單的GUI編程足夠簡化從而真正可用，又                  
不是C那樣積極地鼓勵你使用簡單和直接的語言構造的精益系統編程語言。

                   （另外一位同窗插了一句：這尚未提到很難找到兩個C++編譯器支持一樣的特性。）

做者劉江的按注：

Dmitry有一點是確定正確的，語言之爭更多的是一種相似宗教信仰上的，因此很難有結果，也沒有太多實際意義。這種爭論由於出自高手之間，因此仍是會透露出不少重要的信息。好比：

1. 對於要求性能高的系統編程領域，C++其實未必賽過C，並且事實上，也確實有不少此類項目是選擇C做爲主要語言的。C的生命力目前仍然毋庸置疑。更多的信息能夠讀這裏。

2. C++目前確實處於一種被夾攻的態勢，一方面在企業級系統開發（數據密集、業務規則複雜多變）中，C++已經基本被Java和C#等淘汰出局，另外一方面在系統編程和嵌入式等更接近硬件的領域，又遭到C的強烈狙擊。

3. OO技術並不是one-size-fits-all。

C語言做爲一種古老的語言，其侷限性也是很明顯的，好比已經成爲安全問題淵藪的緩衝區溢出。C的標準庫也存在各類各樣的問題。對於更加貼近現實世界的衆多項目，沒有面向對象機制，顯然會影響開發效率。

C++目前的困境，很大程度上是因爲此前的圖書和文獻曾經一度傾向於炫技，陶醉於對語言各類細節的深刻探索，有華麗化、複雜化的趨勢，語言設計者們苦心設計出來各類豐富的特性和多範型的編程風格，卻成了學習者和使用者的負擔

老人毛病多多，新人青黃不接，C++社區的確面臨危機。

注：我也下載了文章提到的《C++必知必會》

裏面還提到一個Compact的概念，參考 http://www.faqs.org/docs/artu/ch04s02.html#compactness

Compactness is the property that a design can fit inside a human being's head. 
A good practical test for compactness is this: Does an experienced user normally need a manual? 
If not, then the design (or at least the subset of it that covers normal use) is compact.

「在通用編程語言中，C和Python是半緊湊的；Perl、Java、Emacs Lisp和shell則不是（尤爲是真正的shell編程要求你知道半打sed和awk這樣的其餘工具）。
C++是反緊湊的——語言的設計者認可，他並不期望任何一個程序員可以徹底理解這一語言。」

 

 

http://blog.csdn.net/myan/article/details/1777230

時至今日，在通常的場合下，C和C++語言的主要用途就是系統級軟件的開發。具體地說，C/C++寫平臺、工具和基礎庫，支持高層的語言來完成應用邏輯。 
在9月份《程序員》雜誌上刊登的一篇《微軟架構師談編程語言發展》的文章裏，Brian Beckman直截了當地說，C++語言主要是用來開發別的語言的。
這話片面一點，若是改爲 「C++語言主要是用來支持別的語言的」，那就大致沒錯了。

作系統軟件開發的時候，重要的是理解系統的運做方式，那些漂亮的抽象手法和高級特性是次要的。

那些高級的抽象結構每每是 沒必要要的，反而是因爲抽象層次的提升，使得開發者要弄清楚「下面實際發生的事情」變得不太容易了。
因此不少老手實際上以爲用C語言控制力更強一些，更得心 應手一些。真正的C語言高手，對於語言和編譯器都很熟悉了，
基本上在寫C時候就已經知道編譯器優化之後產生彙編代碼是個什麼樣子，甚至能夠改變C代碼來引 導編譯器產生最優化的機器碼。
而C++的機制很豐富，不少機制是爲了知足高層應用和框架的需求而準備的，在這個層次上發揮不出來，反而把清晰性給犧牲掉 了。
不少時候，一個簡單的語句，到底背後會發生什麼，即便是老手也說不清。

std::string s(「Linux Torvalds");
     std::string scopy = s;

     上面這段代碼不過是建立兩個內容相同的字符串副本，可是沒有任何一我的可以在不瞭解更多信息的狀況下清楚地描述背後所發生的事情，
由於不一樣的STL對於 string的實現方式不一樣，所以在copy assignment時表現也不一樣，有的多是簡單地複製字符串對象，有的可能具備ref-counting機制，
須要建立對象、設定對象值、增長引用計 數，有的沒有考慮線程安全性，有的考慮了線程安全性，還得加鎖解鎖，對不起，加解鎖也還有不少作法。
建立新的string對象時，有時還須要調用內存分配 器，而這個東西的實現又五花八門，有的直接new char[]，有的從內建的memory pool申請，
memeory pool是否是線程安全的？對不起，此次可能又要涉及加解鎖問題。memeory pool會不會已經滿了？要不要次第調用new/malloc申請新的內存塊？
總之，後面的事情夠多夠複雜，沒有至關功力，對平臺瞭解不夠深刻，很難說出個子午卯酉來。

寫算法程序的時候，不用STL就以爲不爽。

一個transform 就能夠搞定的事情，非要用for循環，這會讓我感受渾身不自在。因此通常狀況下，拿到一個什麼問題，我仍是會用C++去解決的。
對我來講， Torvalds的話實際上是很中肯的，即便是用C++，也要儘量搞清楚其背後發生的事情，這樣在寫low level程序的時候纔會有把握。

若是是設計應用級別的程序，就儘量不用C/C++，把底層的事情都忘掉，專心專意作好應用層的設計纔是正道。

 

http://blog.codingnow.com/2007/09/c_vs_cplusplus.html#more

好了，讓我再引用 Linus 的一句說到我心坎裏的話。「字符串/內存管理根本可有可無。這不是重要的部分，並且也不復雜。惟一真正重要的部分是設計。」

設計！這纔是重中之重。

http://blog.csdn.net/myan/article/details/1778843

 這裏面的道理是這樣的，反正如今C和C++都是來作系統級開發，那些華麗的抽象機制用不上，思考解決方案的時候，就以C的方式。
注意，C也是能夠作基於對 象甚至面向對象甚至組件級別的設計的，可是在C的層面上思考問題，設計可以更精益（lean，如今這是個時髦詞），更輕便，更直接。

我支持STL是基於一樣的理由。不少時候，你從C出發獲得的設計，也無非就是STL已經實現得很好的東西。在這個時候，固然能夠用STL。
尤爲是那些算 法，針對C array也是適用的，用accumulate求和，用transform映射，用adjacent_find尋找相等的毗鄰項，
用 lower_bound和equal_range作二分查找，等等，這不是比手寫要爽多了嗎？固然，使用STL，仍是必須熟悉其背後的機理，沒有這個底 子，仍是規規矩矩用C算了。

通常性的編碼實踐準則，以及基本的編程能力和基本功，乃至基本的程序設計理論以及算法設計。纔是真正須要花時間掌握的東西。
C++中衆多的細節雖然在庫設計者手裏面有其用武之地，但普通程序員則根本無需過多關注，尤爲是沒有實際動機的關注。

學習最佳編碼實踐比學習C++更重要。看優秀的代碼也比埋頭用差勁的編碼方式寫垃圾代碼要有效。直接、清晰、明瞭、KISS地表達意圖比玩編碼花招要重要…
十年學會編程不是指對每門語言都得十年，那一生才能學幾門語言哪，若是按字母順序學的話一生都別期望學到Ruby了；
十年學習編程更不是指先把語言特性從粗到細全都吃透纔敢下手編程，在實踐中提升纔是最重要的。

C++的書，Bjarne的聖經《The C++ Programming Language》是高屋建瓴的。《大規模C++程序設計》是挺務實的。《Accelerated C++》是最佳入門的。
《C++ Templates》是僅做參考的。《C++ Template Metaprogramming》是精力過剩者能夠玩一玩的，普通程序員碰都別碰的。
《ISO.IEC C++ Standard 14882》不是拿來讀的。Bjarne最近在作C++的教育，新書是絕對能夠期待的。

P.S. 關於如何學習編程，g9的blog上有許多精彩的文章：這裏，這裏，這裏，這裏… 實際上，我建議你去把g9老大的blog翻個底朝天 :P

學C++」和「不學C++」這個二分法是沒意義的，爲何？由於這個問題很表面，甚至很浮躁。重要的不是你掌握的語言，而是你掌握的能力，借用myan老大的話，
「重要的是這個磨練過程，而不是結果，要的是你粗壯的腿，而不是你身上背的那袋鹽巴。」。

對此大嘴Joel在《Joel On Software》裏面提到的漏洞抽象定律闡述得就很是漂亮。

這是Joel在2002年提出的，全部不證自明的抽象都是有漏洞的。抽象泄漏是指任何試圖減小或隱藏複雜性的抽象，其實並不能徹底屏蔽細節，
試圖被隱藏的複雜細節老是可能會泄漏出來。

抽象漏洞法則說明：任什麼時候候一個能夠提升效率的抽象工具，雖然節約了咱們工做的時間，可是，節約不了咱們的學習時間。

代碼生成工具如ORM等Hibernate都是這種思路，它抽象了一些東西，可是，全部的抽象機制都是有漏洞的。惟一能夠處理漏洞的方法就是知道抽象的原理，
都抽象了些什麼東西。因此，在你瞭解抽象原理的過程當中，時間之神將討回你以前節約的時間。

因此，答案是，讓你成爲高手的並非你掌握什麼語言，精通C++未必就能讓你成爲高手，不精通C++也未必就能讓你成爲低手。

按照一種曹操的邏輯，「天下語言，惟imperative與declarative耳」。C++是前者裏面最複雜的一種，支持最普遍的編程範式。
借用當初數學系入學大會上一個老師的話，「你數學都學了，還有什麼不能學的呢？」。學語言是一個途徑，若是你把它用來磨練本身，能夠。
若是你把它用來做爲學習系統底層知識的鑰匙，能夠。若是你把它用來做爲學習如何編寫優秀的代碼，如何組織大型的程序，如何進行抽象設計，能夠。
若是掉書袋，光啃細節，我認爲不能夠（除非你必需要用到細節，像boost庫的coder們）。

而後再借用一下g9老大的《銀彈和咱們的職業》中的話：

銀彈和咱們的職業發展有什麼相干？很簡單：咱們得把時間用於學習解決本質困難。新技術給高手帶來方便。菜鳥們卻不用期望被新技術拯救。
沿用之前的比喻， 一流的攝影師不會由於相機的更新換代而丟掉飯碗，反而可能借助先進技術留下傳世佳做。由於攝影的本質困難，仍是攝影師的藝術感受。
熱門技術也就等於相機。 不停追新，學習這個框架，那個軟件，比如整天鑽研不一樣相機的說明書。而熱門技術後的前因後果，才比如攝影技術。爲何推出這個框架？
它解決了什麼其它框架 不能解決的問題？它在哪裏適用？它在哪裏不適用？它用了什麼新的設計？它改進了哪些舊的設計？Why is forever. 
和 朋友聊天時提到Steve McConnell的《Professional Software Development》裏面引了一個調查，說軟件開發技術的半衰期20年。
也就是說20年後咱們如今知識裏一半的東西過期。至關不壞。朋友打趣道：「應 該說20年後IT界一半的技術過期，咱們學的過期技術遠遠超過這個比例。
具體到某人，極可能5年他就廢了」。話雖悲觀，但可見選擇學習內容的重要性。學習 本質技藝（技術早晚過期，技藝卻經常使用長新）還有一好處，
就是不用看着本身心愛的技術受到挑戰的時候乾嚎。C/C++過期就過期了唄，只要有其它的系統編程 語言。Java倒了就倒了唄，未必我不能用.NET？
Ruby曇花一現又如何。若是用得不爽，換到其它動態語言就是了。J2EE被廢了又怎樣？未必咱們就 作不出分佈系統了？這裏還舉了更多的例子。
 
一句話，只有人是真正的銀彈。職業發展的目標，就是把本身變成銀彈。那時候，你就再也不是人，而是人彈。
 

 

http://blog.csdn.net/turingbook/article/details/1775488

剛知道git也是Linus開發的。git誕生於2005年，因爲Bitkeeper中止和Linux源碼庫合做，Linus本身開發的一套分佈式代碼管理系統，特性有：

速度
簡單的設計
對非線性開發模式的強力支持（容許上千個並行開發的分支）
徹底分佈式
有能力高效管理相似 Linux 內核同樣的超大規模項目（速度和數據量）

下面這個解釋的很好：

http://www.open-open.com/lib/view/open1339575112974.html

 

 

https://www.zhihu.com/question/21994269

Linus Torvalds爲何能稱爲大神：

做者：Copter
連接：https://www.zhihu.com/question/21994269/answer/19966256
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

抽象總結：當一我的的影響力遠超過他的能力時，他離人們心中的神位已經不遠了。

開源世界中，你的貢獻決定了你的地位。Linus 做爲程序員，無可爭議地屬於頂尖級別。他不只是現現在普遍應用於各領域的 Linux 內核 The Linux Kernel Archives 的創始人（沒必要說當時他仍是個大學生），也是多年來成功管理 Linux 內核開發 kernel/git/torvalds/linux.git 的核心人物。僅憑這兩點，被網友稱爲「大神」一點不爲過。

他同時也是 Git http://git-scm.com/ 原始做者。Git 版本管理工具正在被愈來愈多的項目採用，逐漸統一了開發管理市場。

另外，他本人的一些觀點獲得了程序員的普遍讚譽，好比他認爲批評就應該直接了當地說出來，以便快速地消除誤會並修正錯誤（大意）等。著名的 "So, Nvidia, fuck you!「 以及對 C++ 語言設計的抨擊 Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. [LWN.net] 都是踐行這一觀點的有力表明。還由於此人無不良嗜好，行事低調，相婦教子，家庭美滿。容易得到程序員們的一致確定。 至於他得到的一些官方承認，我想就沒必要列舉了吧。順便說，拋棄百毒，題主你又離大神近了一步。：P