看板Soft_Job
看到這個問題的第一個直覺是『中文』。
但又覺得要直接推文『中文才是王道』實在是太嘴砲了，
這實在不太符合 Soft_Job 版希望給予協助，
並站在同為軟體工作者提出有『同業』見解的風格。
即使我的回答不是『中文』，
但我能理解想要用『母語』作為選項的人們的心情。
若你我們是做土木的，那『台語』就可能是必備的，而且還要夠道地。
這樣才能跟同業有『文化』上的共通性，用一樣的字眼譙上級。
而在軟體圈『中文』其實是很難的一件事，
因為『語用』會依說話對相有不同的理解、或是不同的解讀方式。
而為了使對方理解，我們會將同一個『語意』選擇不同的表達方式。
對於傳統理工訓練紮實的同事來說，他們較習慣『精確』地滿足字面上的要求。
如果你期待得更多，那你就得『描述』的更加完整。
或是請這些工作伙伴做些不太需要理解『週邊工作』的任務。
若他們是有耐心的，那就反覆修正吧。
而對於邏輯感不強烈的同事來說，同樣的工作內容。
描述得層次、順序、相依關係分明。
不然，他可能會一開始鬼打牆一陣子。
能幫助他比較快上手的方法，我覺得是幫他們起個頭，
若有 sample code 那就更佳了。
其實會有更多情況，我們沒有考慮到對方有沒有理解自己的想法，
單純地將事情描述過去。
像是 ISSUE Tacker 上開的內容不清楚，完全不知所云。
這種情況，通常表示「描述的內容，『情境(Context)』並不明顯」。
有時我也犯了這種錯，也許試著想理解的工作伙伴並不知道前因後果。
他通常會快速中斷我的動作，先要求說『給我個 Context 唄』
要使用語言溝通其實沒有想像中的簡單，但你還是能由對方的表情知道他懂或懂。
另一種情況是，心理狀態的控制。
曾讀過一點 Agile 的書，
那書上講的不是個別的工作方法，而是實施 Agile 時的一些哲學觀。
假設以這些『觀點』為基礎，作為『專業態度』的主要內容，
那處理事情的手法應該會不一樣。像書上有提到面對到問題的時候，
你的『預設』反應是什麼？
=> 快點到找兇手，然後狠狠地將他罵一頓。
這是一種情緒+語言的反應。
當 Version Control System 被誤用時，commit log 常常被當作『犯罪記錄』！
是誰做的一目了然。但這只會讓大家害怕使用 VCS 而已。
書上是舉這樣的例子來說明，這樣的預設行為並沒有助於『問題解決』
我們應該透過 commit log 找出能『協助解決問題』的伙伴。
情緒爆發不會比解好問題重要，特別是把對方弄到情緒不穩，判斷力下降的情況，
這樣本來能很快找出原因的問題，多花了時間在鬼打牆的狀態。
以上是我支持『中文』(及應有心理準備)的理由。
======================================================================
回歸到語言的選則本身，有幾個考慮方向。
1. 以自己的 domain 為中心，向外延展會用到的語言。
2. 提昇學習/工作效率的環境
3. 結合技
『domain 為中心』
通常我們的工作領域會有個不變的 domain，
像我過去一年有很常的時間都在與 ffmpeg 相處。
主要內容是寫 Player，當然市面上已經有許多 Player 了，
不過因產品的需要，我們得有自己能完全掌握的 Player。
而 ffmpeg 是以純 C 實作的，最初我們在 Android 上實作了一個版本。
它的效能不太好，基本上是架構上的問題，
幾歷了幾代的改寫，我們終於有明確的 core library。
要向外延伸的情況就是：
在 x86：
使用 core library + opengl or sdl, etc
在 android：
使用 core library + android sdk (JNI + Java => SurfaceView, AudioTrack, etc)
在 iOS：
使用 core library + iOS SDK & Frameworks
(Objective-C, opengl, audio queue service)
會使用到其他語言，但問題不在於得使用特定的語言。
而是相依的環境下，提供的實作必需採用。
另一種情況是，你得寫 library，它處理一個 domain，
但希望提供多種語言的實作。
例如，CyberLink 這個 UPnP library：
http://sourceforge.net/search/?q=CyberLink
你可以在 sf.net 蒐尋得到不同的實作，大部分是同一個作者：
http://sourceforge.net/users/skonno
在他的專案，看到一堆 CyberLink for [各種語言、平台]
『提昇學習/工作效率的環境』
程式開發的工作，不外乎理解與實作。
但是在沒有理解正確前，實作起來像在走迷宮處處碰壁。
以常用的網路電臺格式 shoutcast 來說，它的定義很簡單：
http://www.smackfu.com/stuff/programming/shoutcast.html
但在看似簡單的定義下，你怎麼知道你的理解是對的呢？
目標是擴充 ffmpeg 讓它能支援 shoutcast 格式的播放。
由於 C 不是我非常熟悉的語言，實作起來速度會慢的驚人，
我用來實作 proof of concept 的語言選用的是 python：
https://gist.github.com/1056677
利用一個能快速開發的語言，來驗證我腦袋對於 shoutcast 的理解正不正確。
我不用一開始就處理 C 的字串操作問題。
然而在撰寫測試的過程中，我發意外發現：如果我不需要 meta-inf 資料。
那我就不要送要求 meta-inf request，只要濾掉 header 就都是 mp3 data。
若我使用選擇在 C 裡直接實作，我可能沒有多餘的心力去做些額外的嘗試。
於是，就採用實驗後的理解做出了第一個初版：
https://github.com/qrtt1/ffmpeg_icy/commit/
b55719bca9a8757ae774bc194fd049224aa4bb52
若原 PO 想要學習新的語言，
scripting language 快速實作、驗證的優點可以列為考量。
在輔助開發，或是替自己寫開發用工具都有幫助。
像就有人利用 M4 作為 code generator
『結合技』-亢龍有悔
入行也有三年多一點了。回想起來是否嘲笑過人落伍呢？
我想我應該不會用這麼模糊的字眼。
原 PO 所在意的落伍是什麼，我並不能明確地抓到語意，
感覺起來像是：不會用新的語言。
對我來說，看起來工作的樣子很累的那群人，我會這樣形容：
『還在用學生時期土法煉鋼的方式在寫 code』
(完整的想法：
http://chingyichan.wordpress.com/2010/04/26/cycle/ )
不會安排、組織自己工作情境，
並在思想層面做調整的人，始終得那麼疲勞地工作著。
即使學了新東西，時間久了還是永遠的新手。
生產力其實不用追逐流行，而是對自己的工作上會用到的工具、情境再精致化。
如同前一篇的推文者提到的，不可能又快又沒有 bug。
但我們對自己工作整體環境、工具選用、實作習慣上的調整，
能提昇實作速度，並『加速』Bug 被發現的機率。
個人會提議你將在許多語言都有幾會用上的，
重構、單元測試、版本控制作為學習的選項。
你得反思自己現在擁有的技能，組合出最強大的火力。
--
◆ From: 61.231.54.189
※ 批踢踢實業坊(ptt.cc)※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1315625145.A.D74.html
→ qrtt1:一直在改錯字orz 09/10 11:37
→ awert:人家聽/看得懂的 09/10 12:18
→ awert:很多時候有些人連問問題都不會表達，這點真的不好.. 09/10 12:19
推 Aqery:我遇到的是常常客戶要什麼自己也不清楚，要我們先做出來再說 09/10 12:48
→ Aqery:做出來在看看是不是自己想要的，不喜歡在改，來來回回... 09/10 12:48
→ bigbobbon:我離開業界太久,所以不清楚現狀,不過經過幾天大家的熱烈 09/10 16:07
→ bigbobbon:就是,c還是王道, 不過我現在是迷戀prolog,因為他太完美 09/10 16:08
→ bigbobbon:了,有興趣的可以試試XD 09/10 16:09
→ iincho:prolog寫過..不過那種東西是給選上的人寫的...XD 09/10 18:37
→ qrtt1:prolog 都在你的選擇範圍了，那有沒有考慮 forth 09/10 21:09
→ yoco315:forth 大好 XD 09/11 00:52
推 lama618:講得實在太好了 09/11 01:05