多人爱争论第一门程序语言该学什么。每个人的出发点不同，有人认为，第一门语言应当是有趣、无进入门坎；有人则认为，第一门语言影响往后程序开发的思考方式，要严谨而富有思考性；有人以实用为出发点，认为视（将来）工作与环境而定会比较好。
似乎哪个出发点都对，只是现今程序开发领域中，开发者势必要学习多个语言，对第一门语言的争议很多，却很少人谈论第二门程序语言该学什么。
回想一下，你的第一门语言是在什么情况下开始的，你有机会选择吗？
很多人对第一门语言的选择就是无从选择，多半是学校指定课程或工作上需要，或者是为了跳槽，选择了时下被认为工作机会多的语言。
如果是学校指定课程会用到的语言，多半又会牵涉到该教授奠定程序基础的语言，或者是毕了业后可以实用的语言。如果学校选了可以奠定程序开发基础的语言，有时又会被扣上产学落差的大帽子，然后就有人急着将当下实用的语言带入校园，只不过业界实用的语言不只一个，真要以实作为前提，就会造成有学校一个学期学一个语言，毕业前学了三、四种语言，却样样不通的窘境。
但是进入工作后往往要求你对自己负责的工种语言必须做深入的研究，例如程序员客栈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的概念，认为程序开发领域中重复解决相同的问题集合，并不会带来任何进步，持有的对照示例像是：有人就算开了一辈子的车，也不会成为车神，也有人从戏谑角度说到「我只有一年经验，但又重复用了九年，这听来很糟，但是十万个小时的重复练习听来就很威」，这样的比喻并不正确，重点并不在于重复。
如同小提琴每一次的练习，虽然看似重复，然而每次都得尝试在重复中找到动作中需要改进的地方，或者更有效率的按弦方式等，才算是练习，如果每次都只是不假思索、单纯地重复，没有任何困难度与挑战性在里头，那就只是一年经验续用九年的重复，如果每次重复都加入了自我挑战与困难度，那才会是十万个小时的练习。