2011年6月5日 星期日

抽象化。

前一陣看到一個有趣的議題~它描述資訊世界中,眾多的抽象化處理。
雖然為我們帶來很多便利;提升不少程式設計師的產力。
但卻也在這個世界埋下了,有機會造成崩壞的因子。

它舉了 TCP/IP 為例子,TCP 是一個"可靠的網路傳輸協定,但是它卻是建在 IP 這個不可靠的通訊協定上。
這可以有兩種說法~一種是,利用 TCP 的各種確認機制盡力達到"非常可靠"。另一種說法就是…拿上層的協定來催眠自己,說這整個過程沒有問題了!!

(目前 TCP/IP 我完全沒有什麼概念,並沒有辦法很細節的解釋上面的例子)

不過,這個議題還是引起我的注意~~
它另外題到了 SQL語法的例子;相同動作,不同 query 的語法,會造成效率很大的差距。
這就是一個很常見,在抽象化之後,被架空的結構。
也就是就你眼前所見,完全沒辦法理解它發生的原因。因為底層有太多太多的步驟被包裝成來了!!
當這些包裝的發展越來越好的時候,能進入這個圈子的人就變多了~
可是懂得包裝下,複雜繁鎖、重重機關的人將變少了


大量的工具、語法,幫我們把背後的工作都包裝起來~
SQL 我們不用寫排序、列表的程式,不用去看現在最快的演算法是什麼。只要會下 SQL query 就好了。
寫 Email、寫網誌~我們不用手刻檔頭、不用自己加標籤。
在系統上,我們寫入檔案,不用管它要寫到哪個磁柱的那個磁區。它的上層還有 Block map , Block group 才到記憶體的 page layer 。
多的是抽象處理時,帶來的便利~~~

不過不知道哪天、哪個程式上,產生了一個 bug 會讓整個系統崩潰,讓大家措手不及。

避免那個世界末日的來臨?
在程式語言上,可能可以在編譯器上動手腳。確認程設工程師的語義。提高面對不同寫作習慣的理解~~bababa。
( 這些可能就是現在寫編譯器的人在做的事吧? 好好奇喔…)

但是程式言自己本身語法的正交性,這個就是天生的了…已經問世的語言,他們大概沒辦法在語法上做什麼太大的更動…除非是砍掉重練。

目前我還只是初涉資訊這個領域,對於發展的過程、歷史大多一知半解,打打嘴砲。或許改天了解更多之後,會再對這個議題有不同的看法~^ ^





題外話~~抽象化聯想到的一些往事……
大學在修量子物理時,就大量使用很多抽象的算子、算符來代替每個粒子位置、動量…
看到題目時,常常就只是無腦的把它的算符列一列,式子套一套就衝了。
埋頭算了一大票~~回頭看時,都忘記我算的這些都東東都不單單只是個數字,都還有他們要滿足的物理定律。
這應該也可以算是抽象化造成錯誤的直覺……。
裡頭…也因此有人的想法被架空了~~~ㄏㄏ

沒有留言:

張貼留言