查看積分策略說明發表回覆
Discuz! 代碼
提示插入
直接插入
說明訊息

插入粗體文本 插入斜體文本 插入下劃線 置中對齊 插入超級連結 插入信件位址 插入圖像 插入 flash 插入代碼 插入引言 插入列表
刪除線 直線分隔線 虛線分隔線
    
添加文字底框
內容 [字數檢查]:

表情符號

更多 Smilies
字型大小 |||
溫馨提示:本區開放遊客瀏覽。


文章關鍵字 : [功能說明]
(關鍵字可加強搜索準確性, 如關鍵字多於一組, 請以 , 作分隔, e.g. : 阿笨,shiuh,第一笨)

 關閉 URL 識別 | html 禁用
 關閉 表情符號 | 表情符號 可用
 關閉 Discuz! 代碼 | Discuz! 代碼 可用
使用個人簽名
接收新回覆信件通知
推薦放檔網絡空間

檔案(Torent, zip等)
  1. freedl
  2. multiupload
  3. btghost
  4. 便當狗
  5. mediafire
  6. pillowangel
圖片(JPG, GIF等)
  1. hotimg
  2. tinypic
  3. mousems2
  4. imageshack
  5. imm.io
>>>歡迎推薦好用空間


最新10篇文章回顧
Vic

 發表於 2011-6-9 09:45 PM

謝謝eric兄的意見~ 熊很同意「解決問題」…或者更基本的「了解問題」的能力…比掌握「程式語言」更困難…也更需要天份and經驗的累積…這是書本上學不到的…

我想原文中提到有關寫文章也有差不多道理…單純的掌握「程式語言」…好比學習詞彙…「when there is a will, there is way」…每一個單字都很簡單…但加在一齊的意思就不是每個人都可以看懂…語言也需要真正地的運用…去實踐…才能解決到麥當奴買一個漢堡的「問題」。

只是在現實生活中…程式語言比各地語言的變化與其變化速度…都要快很多…令人不勝負荷…明明已經知道如何用滿州文來買漢堡…過了幾天…說滿州文已經被淘汰…請改說漢語等等…

什麼lawyer…熊只是一個苦力的labour…


ericshliao

 發表於 2011-6-9 07:39 PM

我覺得翻譯的算不錯,意思都到了。
對於那段回答,我也覺得很精彩,說到了很重要的點。但programming還有其他重點,在那段回答裡就看不到了。此外,拿寫文章來和寫程式相類比,初看覺得很有道理,但細想下,其實並不貼切。
以我個人的經驗來說,programming language本身並不難學,各種程式語言都有共通點,會了一種,要學(或看)另一種,門檻會低不少。但若是拿現在和二十年前比起來,真正麻煩、難學的是並不是在programming language本身,而是各式各樣的library、module、class architecture。
現在要寫程式,由於涉及的層面往往超越了單純的數值、文字的運算、處理,還牽涉到底層的OS提供的API,以及user interface,如果不先瞭解有哪些function可以用,或是所依賴的OS或UI的概要架構,根本不可能像那段回答裡所說的「流利」的寫出程式。而這已經不是純粹的程式寫作了。
此外,假設有個人想寫個圖形處理的的程式,需要用到一些數學運算,例如三角函數之類的,如果那人的三角函數都已經還給課本和老師了,要如何「流利」的寫出程式呢?
在當前的環境下,要像那段回答裡所說的「流利」的寫程式,除了對程式語言的熟稔度必須很高,還必須跨越我前面提到的兩個限制。寫程式是要解決一個(或很多個)問題,和寫文章是有很大差別的。寫文章是很單純的語言、文字的運用,只要把腦袋裡的想法轉換成適合的文字就可以了,不必考慮能不能解決問題,但寫程式除了程式語言的運用之外,更重要的是要考慮這段程式碼能不能妥善的解決問題。當programmer腦袋裡根本連問題要怎麼解都還沒有明確的想法時,就算他對於程式語言再怎麼熟,還是不可能流利的把程式寫出來。因此,要像寫作文、寫文章一樣流利的來寫程式,我認為現實上那是不可能的。所謂的「流利」的把程式寫出來,大概只限於小型、問題單純、解法明確的計畫、模組。
看了那段回答,我認為他確實陳述了一個理想的境界,那個理想的境界在寫文章的領域是可能存在的,但在寫程式的領域中其實是不存在的。尤其是看了一些較大型的計畫的程式碼後,我更有這種體認。
多寫程式、多練習、多看別人的範例,是必須的學習過程,但再怎麼厲害的programmer,換個不同專業領域的題目給他寫,很可能就當場卡住。或許,這就是那個人為何會從programmer改行當英文老師的原因了。就算你對某個程式語言再熟稔,解不出來的問題就是解不出來,那根本和寫程式的能力無關。寫程式的能力是可以被教導的,但解問題的能力卻不是教得出來的。上補習班學習,頂多是學會了使用某種程式語言,但用程式來「解決問題」就不是補習班能教的。同樣的,拿到了證照也不代表有用程式來「解決問題」的能力。
language lawyer...我大概連當language lawyer都不夠格吧...

[ericshliao 在  2011-6-9 07:58 PM 作了最後編輯]


Vic

 發表於 2011-6-9 06:35 PM

有人在 Slashdot 上问了一个问题:什么认证最好?( Best Certifications To Get?)提问者说他想在 IT 领域有所提升,所以想要考取一些有价值的认证,以便简历可以更好看一些。 Slashdot 上的人给出了很多回答,其中有一个回答很精彩,而且还被投递到了 Hacker News ,回答的原文在这里,我简单翻译如下(翻译仓促,建议直接阅读原文):


引用:
我曾经是一名程序员,后来去做了日本的一名英语教师。日本是一个很有意思的地方,这里的学生知道懂得很多英语,但是却不能在麦当劳顺利点一杯饮料。在编程领域也有一些这样的人,我们把他们叫做“语言律师”(language lawyers)。这种人可以回答有关编程语言的任何问题,但是却没有真实的编程能力;他们可以很容易通过面试,但是当他们真正编程的时候却非常令人失望。这些程序员和我的学生非常像:他们有5000词汇量,知道书上写的所有语法规则,但就是不会说英语。

我现在的观点是编程就像写作。有关编程的很多概念并不困难,它之所以困难是因为我们不善于“写作”。大部分的程序员并不能做到“流利”,也没有写得“流利”的意愿。他们不阅读别人的代码,不认识也不会使用“成语”,思维模式不是编程语言的思维模式(They don’t think in the programming language)。很多代码之所以烂是因为它的“流利”程度就好像3岁小孩写的小说。这也是为什么我们的程序呈现出不必要的复杂。

我们教授编程的方法是错误的,那种方式和日本的英语老师教授英语的方式如出一辙。我们只是传授有关编程的一切概念,然后期望学生可以从那些东西当中自发地学会如何编程。

在语言学习方面有一个假说:所有的语言只有在被理解的情况下才会真正被吸收。也就是说,如果你可以根据你已经知道的或者上下文理解你听到或读到的词句,那么你就会吸收它。解释不能帮助你吸收语言。我相信这对编程而言也是正确的。我们应该让学生寖浸在好的代码中,让他们不通过解释来真正吸收编程的能力。


我个人很认同这个回答中表达的观点。如果文中所说是真的,那么中国的英语教育和日本的英语教育实在没有什么差别,教的都是“哑巴英语”。我们学习英语的时候都是偏重于“单词意思”、“语法”等东西,结果学习完之后还是中文思维,听到英文第一反应是先把它翻译成中文,然后再去理解它的意思。因为有了“翻译”这个环节,听和说几乎都会慢半拍,怎么可能流利呢?编程也是一样,你的脑子里记的都是一些所谓的“代码规范”、“最佳实践”⋯⋯ 写代码的时候总是先想到这些,而且每每以“符合规范”为荣。我并不是说规范不好,但是如果你不能把这些规范“忘掉”,写出来的代码虽然没有什么毛病,但肯定不会让人觉得很妙。一个写作的人如果在写作的时候总是念念不忘语法规则,也肯定写不出好看的文章。

语言是用来使用的,编程语言也是一样。不少人喜欢在那里死记硬背一些语言特性然后去和别人谈论,有时候还美其名曰“注重细节”,这对提高编程能力完全没有用处。说来惭愧,我一直都是一个 language lawyer,编程书籍和文档都看了不少,但真正做出来的东西就实在太少了。有时候想要看别人的代码然后模仿,但是看懂别人的代码之后就觉得自己已经了解,然后就失去了动手的兴趣。做东西也是一样,当我做到80%的时候就会发现剩下的自己都知道怎么做,于是很容易就半途而废。

“知道怎么做”和“真正去做并且完成”完全是两回事,知道所有的单词也未必可以写出一个优美的句子。希望以后在英语和编程学习方面都可以摆脱中国语言教育留下的坏习惯。

原文:http://www.zhuoqun.net/html/y2011/1706.html


我覺得我的程度可能連lawyer都說不上…看來還需要努力…多學多看更要多嘗試。





所在時區為 GMT+8, 現在時間是 2024-4-28 04:14 AM
清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明
Discuz! 0.1 | Processed in 0.020457 second(s), 7 queries , Qzip disabled