對的,我這里要講的不是如何掌握一種程序語言,而是所有的……
很多編程初學者至今還在給我寫信請教,問我該學習什么程序語言,怎么學習。
由于我知道如何掌握“所有”的程序語言,總是感覺這種該學“一種”什么語言的問題比較低級,所以一直沒來得及回復他們 。
可是逐漸的,我發(fā)現(xiàn)原來不只是小白們有這個問題,就連美國大公司的很多資深工程師,其實也沒搞明白。
今天我有動力了,想來統(tǒng)一回答一下這個擱置已久的“初級問題”。類似的話題貌似曾經(jīng)寫過,然而現(xiàn)在我想把它重新寫一遍。
因為在跟很多人交流之后,我對自己頭腦中的(未轉化為語言的)想法,有了更精準的表達。
如果你存在以下的種種困惑,那么這篇文章也許會對你有所幫助:
-
你是編程初學者,不知道該選擇什么程序語言來入門。
-
你是資深的程序員或者團隊領導,對新出現(xiàn)的種種語言感到困惑,不知道該“投資”哪種語言。
-
你的團隊為使用哪種程序語言爭論不休,發(fā)生各種宗教斗爭。
-
你追逐潮流采用了某種時髦的語言,結果兩個月之后發(fā)現(xiàn)深陷泥潭,痛苦不堪……
雖然我已經(jīng)不再過問這些世事,然而無可置疑的現(xiàn)實是,程序語言仍然是很重要的話題,這個情況短時間內不會改變。
程序員的崗位往往會要求熟悉某些語言,甚至某些奇葩的公司要求你“深入理解 OOP 或者 FP 設計模式”。
對于在職的程序員,程序語言至今仍然是可以爭得面紅耳赤的宗教話題。
它的宗教性之強,以至于我在批評和調侃某些語言(比如 Go 語言)的時候,有些人會本能地以為我是另外一種語言(比如 Java)的粉絲。
顯然我不可能是任何一種語言的粉絲,我甚至不是 Yin 語言的粉絲,對于任何從沒見過的語言,我都是直接拿起來就用,而不需要經(jīng)過學習的過程。
看了這篇文章,也許你會明白我為什么可以達到這個效果。
理解了這里面的東西,每個程序員都應該可以做到這一點。
嗯,但愿吧。
重視語言特性,而不是語言
很多人在乎自己或者別人是否“會”某種語言,對“發(fā)明”了某種語言的人倍加崇拜,為各種語言的孰優(yōu)孰劣爭得面紅耳赤。
這些問題對于我來說都是不存在的。
雖然我寫文章批評過不少語言的缺陷,在實際工作中我卻很少跟人爭論這些。
如果有其它人在我身邊爭論,我甚至會戴上耳機,都懶得聽他們說什么。
為什么呢?
我發(fā)現(xiàn)歸根結底的原因,是因為我重視的是“語言特性”,而不是整個的“語言”。
我能用任何語言寫出不錯的代碼,就算再糟糕的語言也差不了多少。
任何一種“語言”,都是各種“語言特性”的組合。
打個比方吧,一個程序語言就像一臺電腦。
它的牌子可能叫“聯(lián)想”,或者“IBM”,或者“Dell”,或者“蘋果”。
那么,你可以說蘋果一定比 IBM 好嗎?
你不能。
你得看看它里面裝的是什么型號的處理器,有多少個核,主頻多少,有多少 L1 cache,L2 cache……,有多少內存和硬盤,顯示器分辨率有多大,顯卡是什么 GPU,網(wǎng)卡速度,等等各種“配置”。
有時候你還得看各個組件之間的兼容性。這些配置對應到程序語言里面,就是所謂“語言特性”。
舉一些語言特性的例子:
-
變量定義
-
算術運算
-
for 循環(huán)語句,while 循環(huán)語句
-
函數(shù)定義,函數(shù)調用
-
遞歸
-
靜態(tài)類型系統(tǒng)
-
類型推導
-
lambda 函數(shù)
-
面向對象
-
垃圾回收
-
指針算術
-
goto 語句
這些語言特性,就像你在選擇一臺電腦的時候,看它里面是什么配置。
選電腦的時候,沒有人會說 Dell 一定是最好的,他們只會說這個型號里面裝的是 Intel 的 i7 處理器,這個比 i5 的好,DDR3 的內存 比 DDR2 的快這么多,SSD 比磁盤快很多,ATI 的顯卡是垃圾…… 如此等等。
程序語言也是一樣的道理。
對于初學者來說,其實沒必要糾結到底要先學哪一種語言,再學哪一種。
曾經(jīng)有人給我發(fā)信問這種問題,糾結了好幾個星期,結果一個語言都還沒開始學。
有這糾結的時間,其實都可以把他糾結過的語言全部掌握了。
初學者往往不理解,每一種語言里面必然有一套“通用”的特性。比如變量,函數(shù),整數(shù)和浮點數(shù)運算,等等。
這些是每個通用程序語言里面都必須有的,一個都不能少。
你只要通過“某種語言”學會了這些特性,掌握這些特性的根本概念,就能隨時把這些知識應用到任何其它語言。
你為此投入的時間基本不會浪費。
所以初學者糾結要“先學哪種語言”,這種時間花的很不值得,還不如隨便挑一個語言,跳進去。
如果你不能用一種語言里面的基本特性寫出好的代碼,那你換成另外一種語言也無濟于事。你會寫出一樣差的代碼。
我經(jīng)??吹接行┤?Java 代碼寫得相當亂,相當糟糕,卻罵 Java 不好,雄心勃勃要換用 Go 語言。
這些人沒有明白,是否能寫出好的代碼在于人,而不在于語言。
如果你的心中沒有清晰簡單的思維模型,你用任何語言表述出來都是一堆亂麻。
如果你 Java 代碼寫得很糟糕,那么你寫 Go 語言代碼也會一樣糟糕,甚至更差。
很多初學者不了解,一個高明的程序員如果開始用一種新的程序語言,他往往不是去看這個語言的大部頭手冊或者書籍,而是先有一個需要解決的問題。
手頭有了問題,他可以用兩分鐘瀏覽一下這語言的手冊,看看這語言大概長什么樣。
然后,他直接拿起一段例子代碼來開始修改搗鼓,想法把這代碼改成自己正想解決的問題。
在這個簡短的過程中,他很快的掌握了這個語言,并用它表達出心里的想法。
在這個過程中,隨著需求的出現(xiàn),他可能會問這樣的問題:
-
這個語言的“變量定義”是什么語法,需要“聲明類型”嗎,還是可以用“類型推導”?
-
它的“類型”是什么語法?是否支持“泛型”?泛型的 “variance” 如何表達?
-
這個語言的“函數(shù)”是什么語法,“函數(shù)調用”是什么語法,可否使用“缺省參數(shù)”?
-
……
注意到了嗎?上面每一個引號里面的內容,都是一種語言特性(或者叫概念)。
這些概念可以存在于任何的語言里面,雖然語法可能不一樣,它們的本質都是一樣的。
比如,有些語言的參數(shù)類型寫在變量前面,有些寫在后面,有些中間隔了一個冒號,有些沒有。
這些實際問題都是隨著寫實際的代碼,解決手頭的問題,自然而然帶出來的,而不是一開頭就抱著語言手冊看得仔仔細細。
因為掌握了語言特性的人都知道,自己需要的特性,在任何語言里面一定有對應的表達方式。
如果沒有直接的方式表達,那么一定有某種“繞過方式”。
如果有直接的表達方式,那么它只是語法稍微有所不同而已。
所以,他是帶著問題找特性,就像查字典一樣,而不是被淹沒于大部頭的手冊里面,昏昏欲睡一個月才開始寫代碼。
掌握了通用的語言特性,剩下的就只剩某些語言“特有”的特性了。
研究語言的人都知道,要設計出新的,好的,無害的特性,是非常困難的。
所以一般說來,一種好的語言,它所特有的新特性,終究不會超過一兩種。
如果有個語言號稱自己有超過 5 種新特性,那你就得小心了,因為它們帶來的和可能不是優(yōu)勢,而是災難!
同樣的道理,最好的語言研究者,往往不是某種語言的設計者,而是某種關鍵語言特性的設計者(或者支持者)。
舉個例子,著名的計算機科學家 Dijkstra 就是“遞歸”的強烈支持者。現(xiàn)在的語言里面都有遞歸,然而你可能不知道,早期的程序語言是不支持遞歸的。
直到 Dijkstra 強烈要求 Algol 60 委員會加入對遞歸的支持,這個局面才改變了。Tony Hoare 也是語言特性設計者。
他設計了幾個重要的語言特性,卻沒有設計過任何語言。另外大家不要忘了,有個語言專家叫王垠,他是早期 union type 的支持者和實現(xiàn)者,也是 checked exception 特性的支持者,他在自己的博文里指出了 checked exception 和 union type 之間的關系 :P
很多人盲目的崇拜語言設計者,只要聽到有人設計(或者美其民曰“發(fā)明”)了一個語言,就熱血沸騰,佩服的五體投地。
他們卻沒有理解,其實所有的程序語言,不過是像 Dell,聯(lián)想一樣的“組裝機”。
語言特性的設計者,才是像 Intel,AMD,ARM,Qualcomm 那樣核心技術的創(chuàng)造者。
合理的入門語言
所以初學者要想事半功倍,就應該從一種“合理”的,沒有明顯嚴重問題的語言出發(fā),掌握最關鍵的語言特性,然后由此把這些概念應用到其它語言。
哪些是合理的入門語言呢?我個人覺得這些語言都可以用來入門:
-
Scheme
-
C
-
Java
-
Python
-
JavaScript
那么相比之下,我不推薦用哪些語言入門呢?
-
Shell
-
PowerShell
-
AWK
-
Perl
-
PHP
-
Basic
-
Go
-
Rust
總的說來,你不應該使用所謂“腳本語言”作為入門語言,特別是那些源于早期 Unix 系統(tǒng)的腳本語言工具。
PowerShell 雖然比 Unix 的 Shell 有所進步,然而它仍然沒有擺脫腳本語言的根本問題——他們的設計者不知道他們自己在干什么 :P
采用腳本語言學編程,一個很嚴重的問題就是使得學習者抓不住關鍵。
腳本語言往往把一些系統(tǒng)工具性質的東西(比如正則表達式,Web 概念)加入到語法里面,導致初學者為它們浪費太多時間,卻沒有理解編程最關鍵的概念:變量,函數(shù),遞歸,類型……
不推薦 Go 語言的原因類似,雖然 Go 語言不算腳本語言,然而他的設計者顯然不明白自己在干什么。所以使用 Go 語言來學編程,你不能專注于最關鍵,最好的語言特性。
同樣的,我不覺得 Rust 適合作為入門語言。Rust 花了太大精力來夸耀它的“新特性”,而這些新特性不但不是最關鍵的部分,而且很多是有問題的。初學者過早的關注這些特性,不僅學不會最關鍵的編程思想,而且可能誤入歧途。
掌握關鍵語言特性,忽略次要特性
為了達到我之前提到的融會貫通,一通百通的效果,初學者應該專注于語言里面最關鍵的特性,而不是被次要的特性分心。
舉個夸張點的例子。
我發(fā)現(xiàn)很多編程培訓班和野雞大學的編程入門課,往往一來就教學生如何使用printf 打印“Hello World!”,進而要他們記憶
printf 的各種“格式字符”的意義,要他們實現(xiàn)各種復雜格式的打印輸出,甚至要求打印到文本文件里,然后再讀出來……
可是殊不知,這種輸出輸入操作其實根本不算是語言的一部分,而且對于掌握編程的核心概念來說,都是次要的。
有些人的 Java 課程進行了好幾個星期,居然還在布置各種
printf 的作業(yè)。學生寫出幾百行的 printf,卻不理解變量和函數(shù)是什么,甚至連算術語句和循環(huán)語句都不知道怎么用!
這就是為什么很多初學者感覺編程很難,我連
%d,
%f,
%.2f 的含義都記不住,還怎么學編程!
然而這些野雞大學的“教授”頭銜是如此的洗腦,以至于被他們教過的學生(比如我女朋友)到我這里請教,居然罵我凈教一些沒用的東西,學了連
printf 的作業(yè)都沒法完成 :P
你別跟我講
for 循環(huán),函數(shù)什么的了…… 可不可以等幾個月,等我背熟了
printf的用法再學那些啊?
所以你就發(fā)現(xiàn)一旦被差勁的老師教過,這個程序員基本就毀了。就算遇到好的老師,他們也很難糾正過來。
當然這是一個夸張的例子,因為 printf 根本不算是語言特性,但這個例子從同樣的角度說明了次要膚淺的語言特性帶來的問題。
這里舉一些次要語言特性的例子:
-
C 語言的語句塊,如果里面只有一條語句,可以不打花括號。
-
Go 語言的函數(shù)參數(shù)類型如果一樣可以合并在一起寫,比如
func foo(s string, x, y, z int, c bool) { … }
-
Perl 把正則表達式作為語言的一種特殊語法
-
JavaScript 語句可以在某些時候省略句尾的分號
-
Haskell 和 ML 等語言的 currying
自己動手實現(xiàn)語言特性
在基本學會了各種語言特性,能用它們來寫代碼之后,下一步的進階就是去實現(xiàn)它們。
只有實現(xiàn)了各種語言特性,你才能完全地擁有它們,成為它們的主人。否則你就只是它們的使用者,你會被語言的設計者牽著鼻子走。
有個大師說得好,完全理解一種語言最好的方法就是自己動手實現(xiàn)它,也就是自己寫一個解釋器來實現(xiàn)它的語義。
但我覺得這句話應該稍微修改一下:完全理解一種“語言特性”最好的方法就是自己親自實現(xiàn)它。
注意我在這里把“語言”改為了“語言特性”。你并不需要實現(xiàn)整個語言來達到這個目的,因為我們最終使用的是語言特性。
只要你自己實現(xiàn)了一種語言特性,你就能理解這個特性在任何語言里的實現(xiàn)方式和用法。
舉個例子,學習 SICP 的時候,大家都會親自用 Scheme 實現(xiàn)一個面向對象系統(tǒng)。
用 Scheme 實現(xiàn)的面向對象系統(tǒng),跟 Java,C++,Python 之類的語言語法相去甚遠,然而它卻能幫助你理解任何這些 OOP 語言里面的“面向對象”這一概念,它甚至能幫助你理解各種面向對象實現(xiàn)的差異。
這種效果是你直接學習 OOP 語言得不到的,因為在學習 Java,C++,Python 之類語言的時候,你只是一個用戶,而用 Scheme 自己動手實現(xiàn)了 OO 系統(tǒng)之后,你成為了一個創(chuàng)造者。
類似的特性還包括類型推導,類型檢查,惰性求值,如此等等。
我實現(xiàn)過幾乎所有的語言特性,所以任何語言在我的面前,都是可以被任意拆卸組裝的玩具,而不再是凌駕于我之上的神圣。
總結
寫了這么多,重要的話重復三遍:語言特性,語言特性,語言特性,語言特性!
不管是初學者還是資深程序員,應該專注于語言特性,而不是糾結于整個的“語言品牌”。
只有這樣才能達到融會貫通,拿起任何語言幾乎立即就會用,并且寫出高質量的代碼。
END
來源:王垠
http://www.yinwang.org/blog-cn/2017/07/06/master-pl
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!