我的第一份工作是一加國內知名遊戲公司的邏輯程式設計師，必須技能是C++，但是一開始只是寫語法和C++很類似的一種指令碼（後來知道是從一個開源指令碼引擎AngelScript修改而成的）。學習遊戲開發的流程，填資料，用指令碼定製各種任務、副本等等。第一年還很有興致，第二年開始就意興闌珊了。

後來熟悉了整個系統，介入到C++部分的程式碼裡。涉及到道具、任務等等邏輯。那時候覺得最難的部分，是UI系統。當時的UI系統，是用XML拼出介面，然後用類似C++的那種指令碼來給它寫邏輯。從一開始被迫學習，到最後使用的時候遇到各種問題，前後折騰了很久。

寫程式的熱情，在實際工作中被一點點的磨滅。我想，很可能許許多多的程式設計師，都會遇到和我一樣的問題。因為愛好而走上這條路，卻被瑣碎的工作磨滅了最初的衝動。等到我成為一個獨當一面的程式設計師的時候，我甚至有一種感覺，覺得自己似乎什麼都會，但是除了專案任務以外的東西，什麼都做不出來。相比高中時候的自己，甚至有一些退步。

直到有一天，我看了一本書《***與畫家》。

在你迷茫的時候，多吸收一些各方面的知識，偶爾會突然開啟一扇窗。

《***與畫家》滿本書都透著濃濃的技術自信，和充足的技術底蘊。它就像是一個知識豐富的技術高手，迫不及待的將平生經驗一股腦傳授給你，為你指明發展的方向。

它的字裡行間透露著對傳統程式語言的鄙夷和對LISP的崇敬。它認為精巧的語言，加上聰明程式設計師實現的高度抽象程式碼，會帶來極大的生產力提升，讓開發更快、BUG更少，讓一兩個開發人員也能撐起一個具有巨大經濟效益的網站。

在Web界已經是遍地動態語言的今天，《***與畫家》裡的判斷似乎已經沒什麼好討論的了（現在動態語言在很多領域已經成為了主流，和作者當年的情況已經有了天壤之別）。但對於當時的我來說，就是大海里的一盞明燈。

雖然書裡對Python（作者當年還是1.x版本）的看法很具有批判性，但是由於那時Python 2.x已經有了長足的發展，加上一個同事的推薦，我全身心投入到了Python的學習之中。

在寫了一些小練習程式之後，我在工作中找到了一個Python的用武之地——用Python實現一個數據表格分析程式，並檢查表格中的資料錯誤、邏輯錯誤。這種表格處理工具在遊戲中具有很大的作用，而且非常適合用指令碼來靈活的擴充套件功能。

第一個實現的簡單版本，使用起來大概是這樣：

這個程式碼主要問題在哪呢？在於讀取資料時，程式設計師自己要指定資料的型別。get_int，get_str，get_float等等等等。

很不幸而又幸運的，當時我用某某雲盤儲存自己的程式碼，有一次誤同步，導致在公司寫的很多程式碼，在家裡操作時覆蓋了。迫使我重寫幾乎整個程式。這次，在同事的參謀下，我實現了這種用法：

這段程式碼實現的功能與上面的完全一樣，但是有兩點變化：

1、用下標操作符代替了get_xxx函式呼叫，更簡潔。

2、讀取時不需要指定型別，執行時，data1自然是整型，data2自然是字串。

這種實現，對於當時的我來說，是一個理念上的重大突破！

為什麼這麼說呢？因為強型別的問題。在Python中，我用一些很簡單的處理，讓mb庫的底層自然的處理了型別。而你知道嗎？在C++中，做到這點難如登天！

C++常常為了推斷一個型別，不惜使用模版技巧，寫出天書一般的程式碼。而且，結果上，仍然不能做到動態語言的這種用法。也就是說，顯式強型別特性，並不僅僅是約束程式設計師減少BUG的工具，它同時也是實現高抽象系統的一個束縛。這是個很有意思的事情，對我當時的觸動很大。不知讀者能否理解。

到了寫出這個表格分析庫之後，我生命中的一扇門打開了。

我回到了可以自由寫程式碼的時代，就像是我的高中時代，而且比那個時代更為簡潔，充滿了更多的可能。

我可以任意的寫程式碼，幾行程式碼就能實現對樹的操作、複雜的巢狀字典。我彷彿可以操作任意複雜的資料結構，或者複雜的遞迴，只要我想清楚了，根本不需要多少編碼時間。

這裡推薦一下我的：Python學習交流q-u-n【 784758214 】內有安裝包和學習視訊資料，零基礎，進階，，大牛線上解答疑問。希望可以幫助你快速瞭解Python、學習python