如何理性的評價各種編程語言的優劣?

我不是想找萬能的銀彈,也不是讓個別phper來引戰的,知乎上雖然有一個類似的問題,PHP、Java、Python、C、C++ 這幾種編程語言都各有什麼特點或優點? - C(編程語言),但是裡面是賣萌和抖機靈的多,沒有看到一些作為一個初學者真正想知道的問題。

舉個例子,PHP能夠進行WEB開發,也能進行桌面開發,但並沒有那款桌面軟體是用PHP開發的,所以PHP這門語言其實更適合於web開發,這算是對PHP一些評價。都說語言是工具,要在合適的時候使用合適的工具,不了解特性又怎麼在合適的時候用呢?但了解語言的特性肯定是那些有一定使用經驗的人才有發言權的啊,我問這個問題就是為了從有經驗的人口中了解這些特性,學習學習。真的不是故意想挑起語言之爭什麼的。

謝謝各位小夥伴解答啦 ~ &> _ &< ~


首先這個問題是沒有辦法明確回答的,因為「理性」一詞的定義並不明確,優劣一詞也不明確。我只能說一下自己的觀點。

在這裡先推薦一篇矽谷創業教父Paul Graham的文章Beating the Average,希望大家先讀一下。

正如題主所說的那樣,「PHP能夠進行WEB開發,也能進行桌面開發,但並沒有那款桌面軟體是用PHP開發的,所以PHP這門語言其實更適合於web開發,這算是對PHP一些評價。」 所有的通用編程語言(General Purpose Programming Language)都是圖靈等價的,計算能力上沒有任何差別,但是為什麼沒有什麼人喜歡用圖靈機來編桌面、網路或者其他應用?!為什麼大家不人人用彙編?!所以在爭論計算機語言優劣的時候祭出圖靈等價只能是很low方式。但是在計算性上的確所有語言都是等Power的,那麼問題來了,我們通常爭論一個語言比另一個語言更強大的時候我們到底在TMD爭論什麼?!或者說同一門的新版本比舊版本更強大,或者更明確一些,Java 1.8里有lambda,那麼它是否比Java 1.7更強大?Java 1.5引入了泛型,那麼它是否比1.4要強大?Python 3.5里有用async還有await協程,那麼Python 3.5是否比Python 3.4更強大?首先我覺得新版本是更強大的,泛型的引入避免了一些運行時的類型錯誤,lambda讓函數不必顯示地包在對象之中。Python的協程解放了一些對程序流程的控制。然後我也覺得它們沒有讓這語言更強大,因為差不多的特性都能在老的版本上實現,只是比較挫。但是,但是1.5中引入的泛型你是否可以用庫來彌補?顯然好像是不行的。所以特性可以分為能用庫來彌補的跟不能用庫來彌補的,我覺得這是1.5比1.4真正強大了,1.5真是要優於1.4,這一點上應該沒有什麼爭議。但Java 1.8是不是比1.7更優,你可以跟我再爭論一下,並且我不覺得這種爭論有任何結果。

那麼對於語言是否更優,我的定義是語言A的特性不能用語言B的庫來彌補,那麼A語言在這種特性上就是更優,如果B可以用庫彌補A的這種特性那麼A是不是更優可以有爭議。這種爭議我通常會躲開或者擱置。

那麼顯然,C語言應該是比彙編更優的,首先C語言可以定義更多的類型、結構體,這是彙編語言庫不能彌補的,其次,C語言有三種控制流的語句,順序、條件、循環(忘記是麥卡錫還是Dijkstra還是霍爾最先提出的了,知道的告訴我一下)而你再厲害的彙編庫也不可能彌補C語言有if for while這些語法上的優勢。

以下純個人觀點:
那麼Java是否比C++更優?Well,Java有自動的內存回收,C++也出了Smart Pointer,不同的只是學習成本。在其他一些地方Java也有些特性是C++用庫沒有辦法彌補的。

Java是否比C語言優?大的尺度上好像並沒有,Java的面向對象只是一種抽象問題的思想,而在C語言里有人一樣也可以面向對象來編程。但是其他有有些方面Java的確更優,比如說數組index out of bound。

Haskell是否比Java更優?答案是肯定的。Haskell里有的一堆可以讓你少寫成百上千行代碼的特性Java里都沒。

文中給了一個叫Blub的悖論:
有一個用Blub語言(假想的語言)的程序員,它是一個比Cobol還有彙編語言更強大的語言。因為對於彙編那是編譯器要的事。而對於Cobol這個用Blub的程序員不知道Cobol程序員怎麼用Cobol把事情搞定,因為Cobol連XXX特性都沒有,所以這個程序員並不會使用Cobol或者彙編。

只要當這個Blub程序員向下審視其他不如Blub強大的語言時,這種不強大十分明顯,因為這些語言沒有Blub程序員習慣使用的特性。而當它們抬頭看更強大的語言時,他們並不覺得他們在仰望。他們看到的只是一個奇怪的語言(這裡作者應該是指Lisp),並且認為Blub與它是一樣強大的,只是裡面有一堆奇怪的東西。Blub已經夠好了,它他用Blub的方式思考。

悖論到此結束。
這也許就是語言之爭的起源,一般的人只是做著比較單一的工作,只要有一種語言他們熟悉並且走夠好就可以了,同時,他們已經習慣了這種語言的思考方式。後者是很可怕的。

(這裡扯點別的,有人問一個中國人:為什麼而學習?這裡的為什麼而跟了一個動詞,我們慣性地會想一個目標,比如為中華崛起而讀書。為往聖繼絕學,為萬世開太平,總是要有一個目標。這裡的為什麼對應英語what ... for,而老外用的是why?所以有的老外會這樣回答這個問題「因為知識本身就是值得學習的」這個老外是歐幾里得,雖然他是希臘人可能不用英語,但是我只想說自然語言都會限制我們的思考,就更不用說計算機語言了)

比如在一門沒有遞歸的語言中你思考的語言永遠都只是循環那幾樣東西,在彙編里你永遠的只想著如果搞那堆寄存器,應該用什麼指令。所以你應該跳出來,打破你現在熟悉的東西,忘掉它重新開始,看看Haskell、F#、Lisp、Scala、Scheme、Clojure、Ocaml、Erlang,這個世界豐富多彩的。Haskell、F#里我能舉出好多你在Java、C++、C#里永遠也沒法用庫彌補的特性。但是這並不代表你就一定要用Haskell與F#,我唯一不希望看到的是你專精了C跟C++語言好多年,然後又去花好多時間去鑽研Go或者Python,因為我覺得它們不會給你帶來新的思想。

最後引用一句Beating the Average中的話:
人人都知道,把你全部的程序全部使用彙編手寫是錯誤的,但是很少有人注意到一個更一般的原則:如果你可以選擇多種語言,若其中大部分語言都是相同的,那麼如果你不用那個強大的就是錯誤。

當然對於這個原則是有例外的。如果你需要寫一個程序來與已有的程序協同工作,那麼新的程序還是用與原來相同的語言比較好。如果你需要寫一個非常簡單的程序比如操作bit,那麼一個抽象能力不怎麼高的語言就夠了,並且這樣還會更快。如果你要寫一個短的,並且寫完就棄用的程序,那麼你就用庫最強大,能幫你快點完成工作的語言。但是對於一般的應用軟體,你一定想用你所知道的最強大(並且效率還不錯)的語言,用任何類似的其他語言都是一個錯誤,比如說彙編語言。


以下轉自王小波的文章:打工經歷 。
來源,王小波的書
沉默的大多數小說在線閱讀
正文 打工經歷
希望軟體公司老闆不要學下例的那種。

在美留學時,我打過各種零工。其中有一回,我和上海來的老曹去給家中國餐館裝修房子。這家餐館的老闆是個上海人,尖嘴猴腮,吝嗇得不得了;給人家當了半輩子的大廚,攢了點錢,自己要開店,又有點燒得慌——這副嘴臉實在是難看,用老曹的話來說,是一副赤佬像。上工第一天,他就對我們說:我請你們倆,就是要省錢,否則不如請老美。這工程要按我的意思來干。要用什麼工具、材料,向我提出來,我去買。別想揩我的油……

以前,我知道美國的科技發達、商業也發達,但我還不知道,美國還是各種手藝人的國家。我們打工的那條街上就有一大窩,什麼電工、管子工、木工等等,還有包攬裝修工程的小包工頭兒;一聽見我們開了工,就都跑來看。先看我們掄大鎚、打釺子,面露微笑,然後就跑到後面去找老闆,說:你請的這兩個寶貝要是在本世紀內能把這餐館裝修完,我輸你一百塊錢。我臉上著實掛不住,真想扔了釺子不幹。但老曹從牙縫裡啐口吐沫說:不理他!這個世紀干不完,還有下個世紀,反正赤佬要給我們工錢……

俗話說,沒有金剛鑽,別攬磁器活。要是不懂怎麼裝修房子就去攬這個活,那是我們的錯。我雖是不懂,但有一把力氣,幹個小工還是夠格的。人家老曹原是滬東船廠的,是從銅作工提拔起來的工程師,專門裝修船艙的,裝修個餐館還不知道怎麼幹嗎……他總說,現在的當務之急是買工具、租工具,但那赤佬老闆總說,別想揩油。與其被人疑為貪小便宜,還不如悶頭幹活,賺點工錢算了。

等把地面打掉以後,我們在這條街上贏得了一定程度的尊敬。順便說一句,打下來的水泥塊是我一塊塊抱出去,扔到垃圾箱里,老闆連個手推車都捨不得租。他覺得已經出了人工錢,再租工具就是吃了虧。那些美國的工匠路過時,總來聊聊天,對我們的苦幹精神深表欽佩。但是他們說,活可不是你們倆這種干法。說實在的,他們都想攬這個裝修工程,只是價錢談不攏。下一步是把舊有的隔斷牆拆了。我覺得這很簡單,揮起大鎚就砸——才砸了一下,就被老闆喝止。他說這會把牆裡的木料砸壞。隔斷牆裡能有什麼木料,不過是些零零碎碎的破爛木頭。但老闆說,要用它來造地板。於是,我們就一根根把這些爛木頭上的釘子起出來。美國人見了問我們在幹什麼,我如實一說,對方捂住肚子往地下一蹲,笑得就地打起滾來。這回連老曹臉上都掛不住了,直怪我太多嘴……

起完了釘子,又買了幾塊新木料,老闆要試試我們的木匠手藝,讓我們先造個門。老曹就用鋸子下起料來:我怎麼看,怎麼覺得這鋸子不像那麼回事兒,鋸起木頭來直拐彎兒。它和我以前見過的鋸子怎麼就那麼不一樣呢。正在幹活,來了一個美國木匠。他笑著問我們原來是幹啥的。我出國前是個大學教師,但這不能說,不能丟學校的臉。老曹的來路更不能說,說了是給滬東船廠丟臉。我說:我們是藝術家。這話不全是扯謊。我出國前就發表過小說,至於老曹,頗擅丹青,作品還參加過上海工人畫展……那老美說:我早就知道你們是藝術家!我暗自得意:我們身上的藝術氣質是如此濃郁,人家一眼就看出來了。誰知他又補充了一句,工人沒有像你們這麼幹活的!等這老美一走,老曹就扔下了鋸子,破口大罵起來。原來這鋸子的正確用途,是在花園裡鋸鋸樹杈……

我們給赤佬老闆幹了一個多月,也賺了他幾百塊錢的工錢,那個餐館還是不像餐館,也不像是冷庫,而是像個破爛攤。轉眼間夏去秋來,我們也該回去上學了。那老闆的臉色越來越難看,天天催我們加班。催也沒有用,手裡拿著手錘鐵棍,拼了命也是干不出活來的。那條街上的美國工匠也嗅出味來了,全聚在我們門前,一面看我們倆出洋像,一面等赤佬老闆把工程交給他們。在這種情況下,連老曹也綳不住,終於和我一起辭活不幹了。於是,這工程就像熟透的桃子一樣,掉進了美國師傅的懷裡。本來,辭了活以後就該走掉。但老曹還要看看美國人是怎麼幹活的。他說,這個工程幹得窩囊,但不是他的過錯,全怪那赤佬滿肚子餿主意。要是由著他的意思來干,就能讓洋鬼子看看中國人是怎麼幹活的……

美國包工頭接下了這個工程,馬上把它分了出去,分給電工、木工、管子工,今天上午是你的,下午是他的,後天是我的,等等。幾個電話打出去,就有人來送工具,滿滿當當一卡車。這些工具不要說我,連老曹都沒見過。除了電鋸電刨,居然還有用電瓶的鏟車,可以在室內開動,三下五除二,就把我們留下的破爛從室內推了出去。電工上了電動升降台,在天花板上下電線,底下木工就在裝配地板,手法純熟之極。雖然是用現成的構件,也得承認人家幹活真是太快了。裝好以後電刨子一跑,賊亮;幹完了馬上走人,運走機械,新的工人和機械馬上開進來……轉眼之間,飯館就有個樣兒了……我和老曹看了一會兒,就灰溜溜地走開了。這是因為我們都當過工人,知道怎麼工作才有尊嚴。


一般我認為,菜鳥支持他是因為不需要學習太多東西,同時老闆支持他是因為手下很多活都需要菜鳥干,那就是一個爛語言。


現在的年輕人真是,什麼腦子都不動,就想得到可以寫論文級別的知識,真不知道是說你們幼稚好還是居心不良好。在學校就炒功課,出來社會就抄襲,一幫廢材。

想要符合理性評價,那麼科學的評價是一種理性的評價。
要科學的評價,只需要建立可重複性的驗證或者實驗手段就可以了。

以下是一種僅供參考的驗證或者實驗方法的步驟:

1. 選擇一個常見的可編程解決的問題
2. 選擇候選編程語言可使用的語言措施、庫等等範圍
3. 邀請足夠多的中等或以上水平程序員的程序員,在約定的範圍內編寫代碼解決這個問題
4. 升級這個問題或者擴展這個問題的應用範圍

按以上步驟迭代,統計每次迭代時(也就是問題變化時)解決問題的各語言的代碼的變化量。

關於候選編程的問題,應該盡量貼合主流的開發環境需要解決的問題。
---
至於要討論什麼才是語言優劣的標準,那是另外一個問題。


The Economy of Programming Languages OpenClassroom


這就是讀史的重要性。每種編程語言的基因基本上決定於剛被設計出來時的用途,雖然後天改造也有影響,但是把魚改造成熊掌無論如何是不如直接找熊要熊掌的。

上個圖吧,稍老了點,侵刪。


我覺得對於編程語言,其實不必過於的理性。首先往往編程語言不是我們能夠選擇的,而且就算你可以選擇,但是選擇的餘地其實也並不多。作為一個愛好其實根本不必太理性。我個人其實比較喜歡clojure的,但是沒有實際的應用場景,如果自己搞一些東西,一定會用的,但是這段時間工作很忙碌,也就沒有時間搞了,但是我是發自真心的喜歡這個語言。

此外,我還比較喜歡靈活度比較高的語言,但又不必處理太多的底層細節,比如javascript,python,ruby。討厭那些需要處理無窮細節,規則無比複雜的語言,代表性的有c++。

好的語言應該是這樣的:簡單,可靠,靈活。
特性上應該有:支持函數性也支持面向對象,高度靈活的語法,龐大的類庫,有垃圾回收機制,有異常處理機制,高級的多線程模型(比如actor),能用最少的代碼做最多的事情。符合這些的其實只有clojure了。

但是一旦我決定使用clojure來開發我們的應用,就要面對無法招到人得窘境了,這裡是西安,不是西雅圖。


http://www.xuthus.cc
當你看了這篇博文之後,也許你就知道了
英文原文:How to kill a dragon with various programming languages
 這篇有趣的文章編譯自一篇西班牙博客。
  有一位美麗的公主,被關押在一個城堡中最高的塔上,一條兇惡的巨龍看守著她,需要有一位勇士營救她…
  下面是各種語言如何想辦法將公主從巨龍手中營救出來的。
Java– 趕到那裡,找到巨龍,開發出一套由多個功能層組成的惡龍殲滅框架,寫幾篇關於這種框架的文章…但巨龍並沒有被消滅掉。
.NET– 趕到哪裡,看到了 Java 程序員的做法,完全拷貝過來,試圖去殺掉巨龍,但巨龍把他吃掉了。
C - 趕到那裡,對巨龍不屑一顧,舉起劍,砍掉巨龍的頭,找到公主…把公主晾在一邊,去看看有沒有最新提交的 linux 內核代碼。
C++– 先打造出一根針,然後在上面添加各種功能特徵,直到最後匯聚成一把複雜的劍,這把劍複雜到只有他能理解其中的功能…殺死龍,但他過橋時遇到了麻煩,因為內存溢出了。
COBOL - 趕到那裡,看到巨龍,認為自己太老了,殺不死這條巨龍,營救不出公主,於是離開了。
Pascal - 他花 10 年時間開發出一套巨龍殲滅系統…當戰鬥開始時,他發現這套系統只能關住蜥蜴。
VB - 使用各種組件開發出一套巨龍毀滅武器,他跳到巨龍的後面,在最關鍵的時刻,他發現這種武器只能在雨夜裡工作…
PL/SQL– 分析其它屠龍者的數據,創建出具有多維數據、n向關係的數據表模型、OLAP,花 15 年時間分析這些數據…當結果出來時,公主已經變成了同性戀者。
Ruby - 盛大出征,號稱自己不管做什麼都是最強的,當面對巨龍,他亮出了一張畫有他殺死一條瘸腿的巨龍的圖片…巨龍懶洋洋的吃掉了他。
Smalltalk - 趕到那裡,分析巨龍和公主,轉身走了,它們是次要問題。
shell - 創造一個超級強大的滅龍武器…但當面對龍的時刻,他忘了如何使用它。
Assembler - 他認為他的方法是正確的,而且是最高效的…但他把D寫成了A,殺死了公主。
Fortran - 趕到那裡,開發出來一套 4 萬 5 千行的解決方案,殺死巨龍,與公主見了面…但公主認為他是懦夫,反而傾心於高富帥的 Java 程序員。
FOX PRO - 開發出一套殺龍系統。外表看起來華麗好用,但實際內部到處補丁,所以,當開始運行這套殺龍武器時,他才發現忘了給 DBF 加索引。
Lisp:這是一位著名的遊俠騎士,在跟很多的屠龍專家交談後,將他們的技巧模型化,他開發出這套系統,當開始運行系統時,他認識到,他少寫了一個括弧。
HTML: 用各種著名的殺龍的劍拼裝成一個網頁,但他忽視了 W3C 標準。在跟龍相遇的時刻,他發現他的代碼跟瀏覽器不兼容,於是他變成了赤手空拳。巨龍把他當成小甜點吃了。
Prolog: 他認為需要有一件殺龍的武器。於是在一個有 182014 件武器的目錄里搜索。截止到公主死的那一年,他的成就包括:通曉了各種武器的製造方法,從索引A開始:Atomic Bombs, Anti-Air Weapons, Arches, Ammunition, Axes…
PHP: 開發出一個 web 網頁,當這個運行時,它能通過一個 Apache 伺服器從一個 MySQL 武器資料庫里檢索出武器消滅掉$dragon。然而,他在 DELETE 語句里忘了寫 WHERE 語句,於是殺死了公主,巨龍,女侍,女巫,魔法師,和程序員自己。
JavaScript: 他創建了腳本網頁,當網頁運行時,腳本會除掉巨龍,他一載入頁面,一些美麗的少女就向他拋來了鮮花,發出來尖叫。不幸的是,他沒有認真分析這個類似蜥蜴的怪物——也被稱作 Mozilla,他得到的只是讓控制台里填滿了 error 信息,《Book of Mozilla》記載了他是如何被吞掉的。
Basic:他開發出來一種能夠殺死紙龍的武器,但不論他如何改進,他發現,他都不能殺死一隻比捲毛獅子狗大的龍。
Matlab: 他寫出循環語句能計算出用巨箭射死巨龍的彈道。這個程序運行的完美無瑕疵。現在需要的是人能有這樣大的力量按這種精度發射這支巨箭。
e:他用傻瓜式框架編出一套外掛和病毒。利用外掛放大了巨龍的弱點,並散播病毒感染了巨龍,但最後毒死了巨龍,公主也毒死了自己。
http://www.xuthus.cc


實際上,各種語言最根本的區別是思維哲學不同。
php是務實,一切以最簡單的代碼完成功能為主,好開發,好部署,好更新。
python是極致簡潔,力求用最簡潔的語法高效完成任務。
java是嚴謹,語法要求各種強制類型,強制try catch之類的。
其他語言也各有各自的思維哲學,實際上,學到一定程度後,就會對不符合自己性格的語言越來越排斥,雖然會用,但不會喜歡。
各種語言的應用領域有不同,但新項目開發中具體使用哪種語言,基本上是由總監的喜好,和公司的人手決定的,而並不是什麼更適合。


首先,理性地說你沒法直接評價優劣,語言被開發出來,要麼有特定的場景,要麼真的為了玩和學,所以最終涉及的因素多了去了,只能在限定好範圍的情況下對比優劣。


樓主的問題是初學者怎麼理解? 我的話,對編譯器前端算入門,編譯器後端還沒能深入。嘗試梳理一下語言的分類。

編程語言粗略劃分有編譯型和解釋型,編譯型語言在代碼執行前就要分析出執行的細節,比如數據結構的內存細節,用來保證運行的性能和正確性。解釋型語言在這兩方面就比較差,但是在開發過程就非常靈活。

編程語言帶偏見還可以分成函數式編程和面向對象編程兩大派,雖然說法不嚴謹,但總體上說因為抽象是必需的,前者通過函數來抽象,要求數據不能修改來保證正確,然後通過可變對象之間互發消息來抽象。當然兩者經常會搭配使用,不過我主要是函數式陣營的。而且前者偏理論,後者偏工程。

除了上邊兩點,也就是執行方式和抽象方案,平台生態還有開發體驗也是很重要的因素如果你想對比兩個語言。

另外語言也能分成通用編程語言和領域特定語言(DSL),前者為儘可能多的開發需求設計,後者為專門的需求設計。

各種編程語言差別雖然很大,但實際上是不同的語言特性的取捨,比如用了不可變數據再要模擬對象得可變數據會麻煩,用了可變數據在並行計算方面會頭疼,用不可變數據對垃圾回收要求會很高,諸如此類。然後還有語法的需求,想寫大量的縮進還是大量的括弧,圓括弧還是花括弧,也都是取捨。另外還有平台的開發體驗,類庫多不多,解答問題的人多不多,支不支持 live coding。

所以樓主真想對比語言的話,把上邊說到的幾點逐個特點逐個語言摸清楚……然後再打算。考慮我知識量不夠,建議樓主多翻一下國外的文章去看細節。


就看實現了多少 LISP 的內容就好了
(逃


只想來吐槽.一下


樓主: 如何理性的評價各種編程語言的優劣? 你的這個"的"字是怎麼解釋?評價是動詞,前面的de應該是地吧.
你這樣一句錯句怎麼讓人回復.


還有樓下的人,人家明顯是問[如何理性評價] 不是讓大家評價...


如何評價XX的問題通常需要從很多不同的角度來評價。就編程語言,需要從企業領導,項目領導,程序員,學生,計算機專家,語言設計者等多角度評價,每個角度可能得出相同或不同的結論。即便是從程序員來說,也有分為無關者,使用者,被坑者,使用並被坑者,這些人的結論也可能相同或不同。
從掌握和使用者角度來說,入門難度低,行業薪酬高,未來前景好的語言為最佳,但目前還不知道有沒有。如果有,望告知,甚是感謝~!


一般人是這樣子的,第一次,是在維護語言,第二次之後,是在維護自己。


js除了到es6版本才彌補的不足外,是我用過最好的語言。。


我非常贊成鳥哥的話:
或許人性都是如此, 覺得掌握了複雜的東西會比較吊, 然而他們卻忘記了, 還是我剛才的觀點, 語言只是你學習來解決你實際問題, 把你的想法變為實際的工具, 你的成長應該是你在使用它們解決問題的過程中, 解決問題的經驗的成長, 而不是語言的使用技藝的增長.
還有:
PHP的程序員, 需要認真的想好, 你的代碼會怎麼被執行, 你怎麼寫代碼, 最終的執行效率才最高. 而不像其他的語言, 程序員可以把一部分優化工作交給編譯器.


我就不喜歡寫代碼,所以我需要用的東西哪個語言有實現,我就用哪個語言,跨語言開發也不難


編程語言的比較,說到底是代碼形狀和可驗證性(靜態和動態)問題


所有的語言本質上都一樣,一法通萬法通……一樣的東西你談什麼優劣


初學簡單呀,你先想好你想做哪一個方面的軟體,然後谷歌一下這個領域內用戶量前十名的軟體都是用什麼語言寫得就行。
比方說
安卓 java
iOS obj-c/swift
操作系統 c/彙編
網頁 html/css/js
win桌面 c#
等等等等


推薦閱讀:

使用 C 語言進行伺服器端編程,未來職業前景與發展前途怎樣?
如何評價翁愷老師?
如何用 C 語言解決兩個大數相乘問題?
如何學慣用 C 語言寫 惠普 / Palm webOS 程序?
頭文件、庫文件、命名空間三者之間是什麼關係?

TAG:編程語言 | Python | PHP | Java | C編程語言 |