抽象化。

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

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

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

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


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

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

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

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

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





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