200年前的「電腦之父」巴貝奇(上):籠罩在「蒸氣龐克」幻想中的差分機

200年前的「電腦之父」巴貝奇(上):籠罩在「蒸氣龐克」幻想中的差分機
Photo Credit: Wikimedia Commons @ public domain

我們想讓你知道的是

巴貝奇與艾達,他們對於現今科技的貢獻一直有所爭議。有人認為巴貝奇乃是電腦之父,而艾達更是史上第一名程式設計師。但也有人認為巴貝奇的分析機和現今電腦的出現並無直接關聯,更像是「電腦之叔」,艾達所撰寫的註釋未必真的是世上第一條程式碼。

文:Satoman

  • 本文含有FGO第2部5.5章「地獄界曼陀羅平安京轟雷一閃」​部分劇情,請讀者自行斟酌觀看。 本文作者學測數學只有4級分,關於數理部分知識可能有誤,請多加糾正。

通關FGO(編按:手機遊戲Fate/Grand Order的縮寫)第2部5.5章後,我個人印象最深刻的是紫式部和巴貝奇這個主從配對。相較起悲劇的第四章,這次也總算是讓巴貝奇在主線裡帥了一次。

而我個人最喜歡的台詞則是:

詩聖乃人類的瑰寶,不可不護。

這句話從身為理組之巔的巴貝奇口中說出或許會讓有些人感到突兀,但若是了解巴貝奇的人生、嗜好與摯友,那便能對這句話感到深刻的共鳴。讓我們先來看看遊戲中巴貝奇個人資料中的一段描述吧:「雖然個性嚴肅,但是對無垢的少女和聰慧的少女沒輒。」

所謂的無垢少女,所指的當然就是科學怪人弗蘭肯斯坦——芙蘭,瘋狂科學家維克特.弗蘭肯斯坦以屍塊和電流創造出的怪物。在FATE系列作中,科學怪人則是被設定為一名純真善良的人造人少女,而科學家維克特則是巴貝奇的老友,因此他也對芙蘭頗為照顧……甚至是偏向溺愛。

那「聰慧的少女」又是誰呢?或許有人已經知道答案了,但是請容我先賣個關子,先從巴貝奇的一生講起吧。故事要從西元1821年講起,當年的查爾斯.巴貝奇(Charles Babbage)正當而立之年,而這名已被周遭朋友認為是數學天才的男士正對著眼前的西洋棋棋局沉思。

機械的極限到底在哪?

讓數學天才陷入苦惱的並非這場自己即將被擊敗的棋局。畢竟他的棋藝並非頂尖,而對手則早已擊敗歐洲的諸多知名棋手,甚至曾讓拿破崙、腓特烈大帝等名人俯首認敗。他抬頭凝視對手,大腦思考著無數的可能性,希望能解開潛藏於對手身上的秘密。而他的對手仍舊是面無表情,看似永遠都是如此的沉著且冷靜。

思考時間結束,巴貝奇移動了棋子,過了半晌他的對手也做出了回應。隨著嘎吱作響的金屬與木材的摩擦聲響起,他的對手以僵硬但一絲不苟的動作拿起了棋子,並精準的放在棋盤的一角。

「將軍!」他的對手並沒有開口,但一旁音箱傳出了勝利宣言。

巴貝奇再次凝視著仍舊是面無表情……正確來講,是不可能有任何表情變化的對手。黝黑的皮膚、東方的奇特裝束隱藏著它那以球型關節運作的手臂,下半身則是與裝著數個齒輪與鍊條的棋桌合為一體。

「我認輸。」巴貝奇站起身,承認了自己的敗北。但是他真正在意的並非棋局的敗北,而是因為未能拆穿對方的奧秘而敗北。而他的對手仍是面無表情,端坐在棋桌另一側。對手的「擁有者」則是匆忙的開始收集殘局,看來巴貝奇的視線讓他感到頗為不安。

這是巴貝奇第二次的敗北,敗北給這名「土耳其行棋傀儡」。

Kempelen_chess1
Photo Credit: Carafe @ CC BY-SA 3.0
土耳其行棋傀儡

沒錯,巴貝奇的對手並非人類,至少表面上不是。「土耳其行棋傀儡」是一個在18世紀至19世紀初一度風靡歐洲的西洋棋自動魁儡。它的製作者沃爾夫岡.馮.肯佩倫(Wolfgang von Kempelen)宣稱這個土耳其魁儡能贏過頂尖棋手,甚至還能完成西洋棋的難題「騎士巡邏」。

如同上述,這名傀儡也確實擊敗了許多知名棋手,甚至吸引到拿破崙(Napoleon)、腓特烈大帝(Frederick the Great)、富蘭克林(Benjamin Franklin)等知名人士與它對弈並敗北。人們一直無法破解下棋傀儡的其中奧妙,有人認為這是一個精巧的機械機關、有人則認為這是一個妖術裝置,而也有不少有識之士像巴貝奇一樣,認為魁儡是一場精心設計的騙局。

事實上,正如同巴貝奇所猜測的。土耳其行棋傀儡並非真正由機械下棋,而是巧妙的隱藏了一名職業棋手在桌底,並藉由帶有磁性的棋子觀測棋盤並操作人偶下棋。這騙局的真相一直到半世紀後才被揭露。但對巴貝奇來講,土耳其傀儡並非只是騙局這麼簡單,而是讓他思考著一個嚴肅的議題:

機械的極限到底在哪?

在工業革命的滾滾蒸氣中,眾多學者、工程師、發明家思考著相同的問題,他們因此設計出了各式各樣的嶄新機械,人類文明的因此加快了進展的腳步。但是,巴貝奇所思考的「極限」比當時的眾人來得更加深遠、更加宏大。

求學的過程

查爾斯.巴貝奇出生於1791年的倫敦,父親是一名富有的銀行家。他自小身體孱弱,又有兩名兄長早年夭折,因此父親對他甚是寵愛。因此巴貝奇得以在不受限的環境中成長學習,而他自小就透漏了對於機械、數理的喜好。當拿到當時最新潮的機械玩具時,巴貝奇總是會把它們拆解研究,想摸清這些機關是如何運作的。

而當他長大入校學習後,隨即便翻透了學校圖書館數學書籍並徹夜研讀,對少年巴貝奇來講,數字的深奧擁有讓他難以抗拒的魅力。富裕的家境讓巴貝奇擁有極佳的學習環境,而他成年後也順利進入英國的頂尖學府劍橋大學的三一學院就讀。

百年前,著名的數理學家艾薩克.牛頓(Sir Isaac Newton)便是在此研究光學、力學與微積分。現今,在牛頓故居附近的小花園中也栽種著一顆蘋果樹,默默地向來往的學子訴說這名偉人過往曾向世人闡明的真理。

看起來,巴貝奇將會在這裡如魚得水般的學習成長,讓自己的才學更加茁壯。可是,事與願違。巴貝奇進入三一學院後,馬上失望的發現學校的數學課程過於保守與過時,甚至不如他入學前後自己先行研讀完畢的書籍。

這是由於英國與歐陸的微積分之爭。牛頓與德國數學家萊布尼茲(Gottfried Wilhelm Leibniz)近乎在同一時期發明了微積分。牛頓的發明較早,但萊布尼茲的發明卻擁有更為簡明的記號與嚴整的系統性。但牛頓始終認為萊布尼茲剽竊了他的發明,雙方關係也勢如水火。

英國基於對牛頓的敬重,在百年後仍是盲目固守於牛頓版本的微積分,也因此讓國內的數學教育與研究進展止步不前。相較之下,在歐陸使用萊布尼茲微積分的學者們則是成果豐碩。

法國以3L:拉格朗日(Joseph-Louis Lagrange)、拉普拉斯(Pierre-Simon Laplace)、勒讓德(Adrien-Marie Legendre)這三名以字首L為名的學者在數學界大有斬獲,而瑞士的白努利家族(Bernoulli family)與他們的學生歐拉(Leonhard Euler)也為近代數學建立了不可撼動的基礎。

當巴貝奇向教授詢問他自行購買的教課書內容,但教授只告訴他不要浪費時間時,巴貝奇就明瞭了他在這裡學不到真正的數學。而巴貝奇的對應方法也很簡單:教授不會的我自己學,還可以教給其他同學。

他和志同道合的好友們成立了數學社團「分析社」,自行翻譯歐陸的數學著作並相互切磋,這群社員未來也一一成為了英國學界的中流砥柱。另外,由於富有老家給予的資助,巴貝奇在劍橋大學過著舒適且寬裕的生活。除了他最愛的數學之外,也培養出了眾多興趣——包括了西洋棋在內。

John_Herschel_1846_(cropped)
Photo Credit: Wikimedia Commons @ public domain
約翰.賀歇爾是巴貝奇的畢生摯友

籌辦「倫敦天文學會」

而在其他學生正在為了畢業求職而焦頭爛額時,他顯得自在且不受成規的拘束,他轉學來到了劍橋大學的另一個學院彼得學院,甚至還在畢業前就找好了對象並訂了婚。1814年,巴貝奇從劍橋大學畢業。比起尋找工作賺取穩定的收入,他反而選擇立刻與未婚妻喬治安娜(Georgiana Whitmore)完婚。

顯然有點過於自由的巴貝奇讓他的老父有點擔心,但是仍是固定寄送「零用錢」讓小倆口不愁吃穿,甚至還能維持上流紳士淑女的生活。巴貝奇夫妻在老家的金援下過了數年愜意的生活,更是在間接連生下了三名兒子(但其中兩名不幸夭折)。

但是這樣的啃老生活也不是巴貝奇真正想要的,他希望能像英國公眾與學界證明自己的學識與才華,並將之用於世。在幾次因為自己的古怪脾氣而求職失敗後,巴貝奇終於獲得了他的同窗好友約翰.赫歇爾(John Herschel)和其父的協助。

約翰.赫歇爾是天文學家與英國攝影技術的先驅,而其父天文學者威廉.赫歇爾是知名的望遠鏡設計者,更是天王星的發現者。在這對父子的聯合推薦下,巴貝奇成為了英國皇家學會的院士,而他累積多年的才學也將在此時開花結果。

巴貝奇的數學才華很快的獲得了皇家學會的認可與資助,而善於交際的巴貝奇也以數場演說教學獲得了學界的注目。在英國嶄露頭角後,他與好友赫歇爾則是前往歐陸的法國遊歷研修,在海峽的另一端,他與拉普拉斯等數學家相談甚歡,並對於法國學者組織感到敬佩。

在這兩名年輕的英國學者眼中,英國皇家學會顯得過時且流於形式,其中甚至僅有三分之一的學者有經歷過嚴謹的科學教育訓練。當他們回到倫敦後,便開始籌辦一個新的學會「倫敦天文學會」,學會吸引了大量年輕有為的學者加入,而巴貝奇與赫歇爾則是接下了一項重要任務:為英國政府制定新版的「航海曆」。

巴貝奇腦海中的「計算機」

自古以來,當船隻在茫茫大海航行時,最值得信賴的指標是垂掛於夜空的星座與天體。而航海曆便是詳細記載了天體運行數據的曆書,船員可透過查閱航海曆,再比對天體查詢自身究竟為於地球的何方。

編訂一本詳細記載天體運行的書籍,自然是少不了大量的數學運算工作。巴貝奇與赫歇爾投入工作後,很快的發現編訂航海曆的吃力不討好之處。

大量的計算工作得消耗大量的人力來進行,而且極為容易出錯。就算是擁有英國頂尖數學能力的他們親自下場,也難保永遠不會計算錯誤。這是當時所有在數字中掙扎奮鬥的從業者所面臨的共同問題,隨著文明的快速演進,計算需求的精密和難度也是不可同日而語。

那時人們仰賴著查詢他人先行計算完成的各類數值表來加快工作速度,但仍是缺乏效率與精確性。而製作數值表的工程同樣也是浩大且繁瑣,計算錯誤的問題也始終無法排除。

兩名高材生相互抱怨吐苦水後,那個疑問再次在巴貝奇腦海中浮現。

機械的極限到底在哪?

然後是:

假如把這項工作交給機械……一個由蒸汽機驅動的計算機器,那效率將會提升多少?

在巴貝奇腦海中,一個機器開始緩緩建構成形:

由無數的齒輪、軸承等精細零件組合而成,隨著蒸汽引擎的驅動,刻印於齒輪上的數字整齊且一絲不苟解答人類所提出的算式。是的,我們現今稱類似的產品為「計算機」。

巴貝奇並不是第一個想到計算機這項發明的人,也不是第一個開始製造的人。上文提及的萊布尼茲早在17世紀就依照他人的設計改良出齒輪軸承結構的計算機,但是這些設計的成品仍得依靠人手操作,也只能做到乘法的計算。要比效率,這些計算機可能還遠比不上在東亞、俄羅斯等國流傳的算盤。

但巴貝奇所構想的計算機械則是以計算多項式的數值表為目標,並且在計算過程中去除一切人力可能造成的失誤。以當時的科技,要製造這組機械一定是項大工程。而巴貝奇並非工程師出身,對於機械結構的理解相對缺乏,所以距離目標可說是遙不可及。

但是若是這項發明能真的問世,又能帶給世人多少的便利?

工業革命後的世界,「計算」已成為人們的日常工作之一。建築、交通、工業、航海、天文……甚至是戰爭都需要大量的計算工作。如果真的有機器能代替人類進行這些枯燥乏味、又極容易出錯的計算工作……甚至是加速計算的進行,那人類文明的步履又能同時加速多少?

Babbages_difference_engine_1832
Photo Credit: Sebastian Wallroth @ public domain
巴貝奇的1/7差分機模型,現藏於倫敦科學博物館

發明「差分機」

巴貝奇完成了雛形的規劃與設計。基於運作原理他將這項發明命名為「差分機」:利用反覆計算差分來得出多項式數值表的機器。巴貝奇先是自行製造了一個小型的差分機模型,證實了他的設計的可行性。隨後則是將設計圖和構想發函至英國政府和各大學術機構。

說到19世紀初的英國,那正是日不落帝國的正午之刻。在國內翻騰的蒸汽帶動各類機器日夜不停的運轉,科學家們則是執著於以望遠鏡仰望星空,紀錄與運算著天體的變化。而皇家艦隊和商船航行於世界各大洋之上,來往於諸多異國與海外殖民地進行頻繁的戰爭與貿易。

不管是政府還是學會,他們早已充分理解到計算的精確與速度的重要性。因此巴貝奇的提案獲得了當時政界與學界的廣泛支持。英國政府撥下一筆鉅款給巴貝奇作為研發經費,而巴貝奇的友人工程師布魯內爾(Isambard Kingdom Brunel)則是推薦了他知道最好的機械工匠們來幫助計畫的執行。

他們的目標是製造一個能計算到第6差分、儲存16位數的機械。要完成這目標,這機械不僅是龐大,又是同時是無比的精密。巴貝奇和工匠們努力將這機械化為現實,但是瓶頸接接踵而來。

根據巴貝奇的理想設計,差分機的總零件量超過了兩萬五千以上,而且均是考驗工匠手藝極限的精細零件。再加上巴貝奇個性上有個缺陷:「三心二意」,他經常更改設計,有時又跑去從時其他的研究或計畫,導致差分機的製作一延再延。

雪上加霜,在製作差分機的過程中,巴貝奇不斷面臨與至親死離的悲劇。首先是他摯愛的妻子喬治安娜,之後則是父親老巴貝奇,隨後次子、么子,以及他最寵愛的女兒——和母親同名的小喬治安娜也接連離世。

因為以上種種原因,差分機雖然被證實理論上可行,但是製造的進度卻是停滯不前。十幾年過去了,英國政府終於無法忍受差分機帶來的財政黑洞,巴貝奇失去了來自政府的金援,與他合作的工匠們也離開了計畫。

本文經《方格子》授權轉載,原文發表於此

責任編輯:彭振宣
核稿編輯:翁世航


猜你喜歡


加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

我們想讓你知道的是

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

打造第一個你在 AWS 上的應用程式

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

透過 AWS 增加你的雲端技能 在組織發揮你的影響力

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

填寫表單諮詢專人 快速在 AWS 找到適合你的快速上雲服務與工具!

了解更多:AWS 開發者系列


猜你喜歡