多人愛爭論第一門程序語言該學什麼。每個人的出發點不同，有人認爲，第一門語言應當是有趣、無進入門坎；有人則認爲，第一門語言影響往後程序開發的思考方式，要嚴謹而富有思考性；有人以實用爲出發點，認爲視（將來）工作與環境而定會比較好。
似乎哪個出發點都對，只是現今程序開發領域中，開發者勢必要學習多個語言，對第一門語言的爭議很多，卻很少人談論第二門程序語言該學什麼。
回想一下，你的第一門語言是在什麼情況下開始的，你有機會選擇嗎？
很多人對第一門語言的選擇就是無從選擇，多半是學校指定課程或工作上需要，或者是爲了跳槽，選擇了時下被認爲工作機會多的語言。
如果是學校指定課程會用到的語言，多半又會牽涉到該教授奠定程序基礎的語言，或者是畢了業後可以實用的語言。如果學校選了可以奠定程序開發基礎的語言，有時又會被扣上產學落差的大帽子，然後就有人急着將當下實用的語言帶入校園，只不過業界實用的語言不只一個，真要以實作爲前提，就會造成有學校一個學期學一個語言，畢業前學了三、四種語言，卻樣樣不通的窘境。
但是進入工作後往往要求你對自己負責的工種語言必須做深入的研究，例如程序員客棧www.proginn.com裏面目前優質開發者三位當中一位web後端開發：明顯之前學校學習的是java，後來工作做web開發所以對PHP非常精通（上圖）
圖靈獎得主Edsger W. Dijkstra曾在2001年寫了一封信給德州大學預算委員會（你可以搜尋〈Dijkstraon Haskell and Java〉，找到這封信的PDF連接），力勸對方別將大學程序開發入門課程中使用的函數式程序開發語言Haskell，改成命令式語言Java，其所持實際性的理由之一是，對於新生課程來說，多數學生對命令式程序開發已有一定熟悉度，讓他們面對函數式語言，能讓他們馬上發現，程序開發還有許多沒想過的東西。
Dijkstra認爲Java是大雜燴，是透過大量廣告與侵略性銷售行爲，才得以達到商場接受度；他說：「不僅是小提琴塑造了小提琴家，我們訓練自己使用的工具也塑造了我們，而在程序語言這方面有着深遠的影響，它們塑造了我們的思考習慣」。
除了奠定基礎或者是實用外的考察外，有些人比較有選擇性，可以基於興趣或成就感，選擇第一門語言，程序開發基礎或實用性不見得是主要考察，他們認爲興趣與成就感才能促成學習的動力。
在現今瀰漫人人都該學程序開發、從小就該學程序開發的年代，有人試着挑選一些語法細節少、運行門檻低、結果回饋顯著的語言，就是爲了減少語言新鮮人的挫折，讓他們能在學習過程中時時獲得成就感，因而培養出程序開發的興趣甚至能力。
能重新認識程序開發的語言
基於不同的出發點，你可能已經歷經了第一門或甚至多門的語言選擇（或無從選擇），如果有機會重新來過，假設你現在有機會選擇第二門語言，或者是你正面臨或建議他第二門語言該學什麼，你會怎麼選擇？
說是選擇，也不全然是自主下的選擇，畢竟第一門語言的影響力，有時像是母語般，還是會影響我們對第二門語言的選擇，我的建議是，第一門語言既然必然影響第二門語言的選擇，就長遠考察來說，第二門不如選擇與第一門相對性大，而且能夠重新認識程序開發的語言。
不少研究指出，人類使用的語言會影響我們對世界的認知，使用不同語言的人會有不同的思考方式。在程序開發領域中，Dijkstra也談到很重要的一點，程序語言塑造了我們的思考習慣。在運用第一門語言時，你是從它的角度來觀看程序世界，如果第二門語言採取的角度與第一門類似，你看到的世界並不會有多大不同，找到一門可以相對角度觀看程序世界的語言，才能看到程序世界的另一面。
如果你的第一門語言是靜態定型語言，那麼第二門試着學習動態定型，瞭解動態定型的彈性，第一門若選擇了動態定型，那就反過來選擇靜態定型，瞭解靜態定型中如何更嚴謹地思考型態。
如果第一門語言以面向對象爲主要典範，那麼第二門就學習以函式爲中心的語言。如果第一門語言是命令式，那麼就第二門就來了解函數式風格的語言。如果是處處以語法作出限制的語言作爲第一門，那就以隨時依賴慣例的語言作爲第二門。如果你是基於工作選擇了第一門語言，那麼就基於興趣來選擇第二門語言。倘若你進入門檻低的語言是第一門，那麼考慮找個進入門坎高的語言來做爲第二門……
以相對於第一門的角度來選擇第二門語言，往往有如驟然面臨巨大陌生環境，這迫使你重新體會第一門語言剛開始時的步履蹣跚，你得從相對角度重新認識程序開發的世界，這樣纔有機會重新塑造思考習慣，也才能體驗到Dijkstra在信中談到的，程序開發還有許多你沒有想過的東西，因爲重新認識程序開發，你纔有機會開始在程序開發上重複練習。
程序世界中的重複練習
在練習小提琴時，經常要反覆地練習某個曲子，直到每個動作連貫而流暢，練習書法時，必須重複地練習臨摩書法家的名帖，不少技藝都需要透過重複性的練習來熟悉基本動作，爲將來更高超技巧奠定基礎，同樣地，每個卓越運動家的成就，都必然歷經過十萬個小時以上的練習，那麼，在程序開發的世界中，有這種形式的重複練習嗎？維基百科上有個〈Kata（programming）〉條目談到，code kata可以讓程序開發者透過練習與重複來磨練技能。
第一個將日本武術中Kata概念帶入程序開發領域的人，可能是《ThePragmatic Programmer》共同作者之一DaveThomas，他建立了CodeKata（codekata.com），目前提供了21個簡短的Kata練習，有些練習必須進行程序開發，然而撰寫代碼上可以有多種不同方式，有些重點不在程序開發，而在思考方式，正確答案也不只一個，你可以重複進行這些練習，這裏練習的目標不在最後的解答，而是在練習的過程。Bob大叔在《The Clean Coder》中談到Kata時也講到：「練習者不是在解決真正的問題，因爲你已經知道解決方案。相反地，你是在練習解決這個問題時，需要的動作和決策」。
當你在歷經第一門語言的洗禮之後，對於某些問題，也許已經知道該語言如何解決，因此第二門語言在選擇時，若能挑選差異性大的語言，就可以藉此換個角度來思考，重新訓練你解決問題時的動作和決策。此時，除了從語法上來重新思考之外，也要從語言社羣的文化與慣例來思考，如此一來，就算是基礎的數據結構與算法，也可以進行重複練習而從中獲得不同的思考方式，我先前專欄〈數據結構與算法的七個思考術〉，談到的就是這類的概念。
一年經驗續用九年vs.十萬個小時的練習
有人反對CodeKata的概念，認爲程序開發領域中重複解決相同的問題集合，並不會帶來任何進步，持有的對照示例像是：有人就算開了一輩子的車，也不會成爲車神，也有人從戲謔角度說到「我只有一年經驗，但又重複用了九年，這聽來很糟，但是十萬個小時的重複練習聽來就很威」，這樣的比喻並不正確，重點並不在於重複。
如同小提琴每一次的練習，雖然看似重複，然而每次都得嘗試在重複中找到動作中需要改進的地方，或者更有效率的按弦方式等，纔算是練習，如果每次都只是不假思索、單純地重複，沒有任何困難度與挑戰性在裏頭，那就只是一年經驗續用九年的重複，如果每次重複都加入了自我挑戰與困難度，那纔會是十萬個小時的練習。