?? index.htm
字號:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>Thinking in Java | Prewords</title>
<meta name="Microsoft Theme" content="inmotion 111, default"></head>
<body background="../_themes/inmotion/inmtextb.gif" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/_themes/inmotion/inmtextb.gif" bgcolor="#FFFFCC" text="#000000" link="#800000" vlink="#996633" alink="#FF3399">
<p><strong>寫在前面的話</strong></p>
<p>我的兄弟Todd目前正在進行從硬件到編程領域的工作轉變。我曾提醒他下一次大革命的重點將是遺傳工程。<br>
我們的微生物技術將能制造食品、燃油和塑料；它們都是清潔的，不會造成污染，而且能使人類進一步透視物理世界的奧秘。我認為相比之下電腦的進步會顯得微不足道。</p>
<p>但隨后，我又意識到自己正在犯一些科幻作家常犯的錯誤：在技術中迷失了（這種事情在科幻小說里常有發生）！如果是一名有經驗的作家，就知道絕對不能就事論事，必須以人為中心。遺傳對我們的生命有非常大的影響，但不能十分確定它能抹淡計算機革命——或至少信息革命——的影響。信息涉及人相互間的溝通：的確，汽車和輪子的發明都非常重要，但它們最終亦如此而已。真正重要的還是我們與世界的關系，而其中最關鍵的就是通信。</p>
<p>這本書或許能說明一些問題。許多人認為我有點兒大膽或者稍微有些狂妄，居然把所有家當都擺到了Web上。“這樣做還有誰來買它呢？”他們問。假如我是一個十分守舊的人，那么絕對不這樣干。但我確實不想再沿原來的老路再寫一本計算機參考書了。我不知道最終會發生什么事情，但的確認為這是我對一本書作出的最明智的一個決定。</p>
<p>至少有一件事是可以肯定的，人們開始向我發送糾錯反饋。這是一個令人震驚的體驗，因為讀者會看到書中的每一個角落，并揪出那些藏匿得很深的技術及語法錯誤。這樣一來，和其他以傳統方式發行的書不同，我就能及時改正已知的所有類別的錯誤，而不是讓它們最終印成鉛字，堂而皇之地出現在各位的面前。俗話說，“當局者迷，旁觀者清”。人們對書中的錯誤是非常敏感的，往往毫不客氣地指出：“我想這樣說是錯誤的，我的看法是……”。在我仔細研究后，往往發現自己確實有不當之處，而這是當初寫作時根本沒有意識到的（檢查多少遍也不行）。我意識到這是群體力量的一個可喜的反映，它使這本書顯得的確與眾不同。</p>
<p>但我隨之又聽到了另一個聲音：“好吧，你在那兒放的電子版的確很有創意，但我想要的是從真正的出版社那里印刷的一個版本！”事實上，我作出了許多努力，讓它用普通打印機機就能得到很好的閱讀效果，但仍然不象真正印刷的書那樣正規。許多人不想在屏幕上看完整本書，也不喜歡拿著一疊紙閱讀。無論打印格式有多么好，這些人喜歡是仍然是真正的“書”（激光打印機的墨盒也太貴了一點）。現在看來，計算機的革命仍未使出版界完全走出傳統的模式。但是，有一個學生向我推薦了未來出版的一種模式：書籍將首先在互聯網上出版，然后只有在絕對必要的前提下，才會印刷到紙張上。目前，為數眾多的書籍銷售都不十分理想，許多出版社都在虧本。但如采用這種方式出版，就顯得靈活得多，也更容易保證贏利。</p>
<p>這本書也從另一個角度也給了我深刻的啟迪。我剛開始的時候以為Java“只是另一種程序設計語言”。這個想法在許多情況下都是成立的。但隨著時間的推移，我對它的學習也愈加深入，開始意識到它的基本宗旨與我見過的其他所有語言都有所區別。</p>
<p>程序設計與對復雜性的操控有很大的關系：對一個準備解決的問題，它的復雜程度取決用于解決它的機器的復雜程度。正是由于這一復雜性的存在，我們的程序設計項目屢屢失敗。對于我以前接觸過的所有編程語言，它們都沒能跳過這一框框，由此決定了它們的主要設計目標就是克服程序開發與維護中的復雜性。當然，許多語言在設計時就已考慮到了復雜性的問題。但從另一角度看，實際設計時肯定會有另一些問題浮現出來，需把它們考慮到這個復雜性的問題里。不可避免地，其他那些問題最后會變成最讓程序員頭痛的。例如，C++必須同C保持向后兼容（使C程序員能盡快地適應新環境），同時又要保證編程的效率。C++在這兩個方面都設計得很好，為其贏得了不少的聲譽。但它們同時也暴露出了額外的復雜性，阻礙了某些項目的成功實現（當然，你可以責備程序員和管理層，但假如一種語言能通過捕獲你的錯誤而提供幫助，它為什么不那樣做呢？）。作為另一個例子，Visual
Basic（VB）同當初的BASIC有關的緊密的聯系。而BASIC并沒有打算設計成一種能全面解決問題的語言，所以堆加到VB身上的所有擴展都造成了令人頭痛和難于管理和維護的語法。另一方面，C++、VB和其他如Smalltalk之類的語言均在復雜性的問題上下了一番功夫。由此得到的結果便是，它們在解決特定類型的問題時是非常成功的。<br>
在理解到Java最終的目標是減輕程序員的負擔時，我才真正感受到了震憾，盡管它的潛臺詞好象是說：“除了縮短時間和減小產生健壯代碼的難度以外，我們不關心其他任何事情。”在目前這個初級階段，達到那個目標的后果便是代碼不能特別快地運行（盡管有許多保證都說Java終究有一天會運行得多么快），但它確實將開發時間縮短到令人驚訝的地步——幾乎只有創建一個等效C++程序一半甚至更短的時間。這段節省下來的時間可以產生更大的效益，但Java并不僅止于此。它甚至更上一層樓，將重要性越來越明顯的一切復雜任務都封裝在內，比如網絡程序和多線程處理等等。Java的各種語言特性和庫在任何時候都能使那些任務輕而易舉完成。而且最后，它解決了一些真正有些難度的復雜問題：跨平臺程序、動態代碼改換以及安全保護等等。換在從前，其中任何每一個都能使你頭大如斗。所以不管我們見到了什么性能問題，Java的保證仍然是非常有效的：它使程序員顯著提高了程序設計的效率！</p>
<p>在我看來，編程效率提升后影響最大的就是Web。網絡程序設計以前非常困難，而Java使這個問題迎刃而解（而且Java也在不斷地進步，使解決這類問題變得越來越容易）。網絡程序的設計要求我們相互間更有效率地溝通，而且至少要比電話通信來得便宜（僅僅電子函件就為許多公司帶來了好處）。隨著我們網上通信越來越頻繁，令人震驚的事情會慢慢發生，而且它們令人吃驚的程度絕不亞于當初工業革命給人帶來的震憾。</p>
<p>在各個方面：創建程序；按計劃編制程序；構造用戶界面，使程序能與用戶溝通；在不同類型的機器上運行程序；以及方便地編寫程序，使其能通過因特網通信——Java提高了人與人之間的“通信帶寬”。而且我認為通信革命的結果可能并不單單是數量龐大的比特到處傳來傳去那么簡單。我們認為認清真正的革命發生在哪里，因為人和人之間的交流變得更方便了——個體與個體之間，個體與組之間，組與組之間，甚至在星球之間。有人預言下一次大革命的發生就是由于足夠多的人和足夠多的相互連接造成的，而這種革命是以整個世界為基礎發生的。Java可能是、也可能不是促成那次革命的直接因素，但我在這里至少感覺自己在做一些有意義的工作——嘗試教會大家一種重要的語言！</p>
<!--msthemeseparator--><p align="center"><img src="../_themes/inmotion/inmhorsa.gif" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/_themes/inmotion/inmhorsa.gif" width="300" height="10"></p>
<p align="center"><a href="../../../../tppmsgs/msgs0.htm#1" tppabs="http://www.bruceeckel.com/">英文版主頁</a> | <a href="../index.htm" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/index.htm">中文版主頁</a> | <a href="../contents/index.htm" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/contents/index.htm">詳細目錄</a>
| <a href="../about/index.htm" tppabs="http://member.netease.com/%7etransbot/Thinking%20in%20Java/about/index.htm">關于譯者</a></p>
</body>
</html>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -