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

轉載于:https://www.cnblogs.com/charlesblc/p/5951274.html

總結

以上是生活随笔為你收集整理的【转载】C/C++语言分析 每年学一种编程语言 git历史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。