在過去的25年里，編程世界發生了巨大的變化，如今，我們有大量的有用的、靈活的數據類型可以使用，但在25年前，你需要花大量的額外時間自己去構造這些類型。

C和Pascal語言——當時的標準語言——提供了少量的面向機器的數據類型：數字，指針，數組，形式上的字符串，以及把多種數據組合到一起的結構體或record。重要的是，以這些基本的類型為基石，我們可以構造出更多有趣的類型，例如棧，樹，鏈接表，哈希表，可變數組等。

在Perl或Python，或Erlang語言里，我不需要考慮這些東西。我在使用list、string或array時，根本不關心它們能容納多少元素，或放在內存的什么地方。最常使用的還有字典，同樣，根本不擔心它的容量或哈希沖突是如何避免的細節內容。

除此外，我仍然需要一些新的數據類型，但它們更多的是現有類型的一種變換，而不是重新構造。任意維度的vector實際就是array。一個RGB 顏色值實際上一個3元tuple。一個多項式既可以是一個tuple，也可以說list。我驚奇于這些 array，tuple，list，dictionary等數據類型大大的消除了我在大學課程里學到的那些基本數據類型上的不便。在實現一個平衡二叉樹時，你的注意力放在如何讓二叉樹平衡，而不是痛苦的糾結于亂如麻的指針操作。

將已有的小方塊搭建成一個新的建筑，這將會引起比小方塊出現帶來的更大的變化。這些小方塊是如何出現的已經不是人們關心的重點。在很多的編程課程和教材中，本來很好的教學中突然出現了一批新詞匯：對象，構造器，抽象基礎類，以及私有方法。于是，下一次作業中，用簡單的三元tuple來表達的RGB顏色值變成了由一個具有get、set方法，多高構造器的類來代替，更要命的，出現了大量的代碼。

這就是為什么有人會不停的呼吁、解釋為什么面向對象不是個好東西、會使編程失去樂趣的原因。但很少奏效。

并不是面向對象不好，或含有什么缺陷。而是面向對象不是計算機編程的基本原子，它們不是人們想象的天生就存在的。不設門檻的任意使用面向對象來解決問題會讓代碼變得臃腫和過度技術化，然而，很多人還是堅持鍥而不舍的用對象來解決所有問題。這非常糟糕，因為這樣做讓人們辨不清面向對象風格的做法是否真的產生了使問題簡化并易于理解的效果。