高階語言不會是eye candy 高階語言compile出來之所以會比較慢/大, 是因為它引入的更多的附加物 如果引入OOP, 參考物件需更多的dereference... 如果引入try-catch之類的error-handling, error發生時需更多的處理時間... 如果引入VM, GC, 分配記憶體時需更多時間... ... 可是也因為引入附加物, 可能得到的好處可能有 runtime optimization, 程式易讀易改, 易debug, 與development tool更容易結合, 或更適合"某類型"的計算 而且像linked list, 一般的+-*/, 之前的observer pattern ,或相似簡單的algorithm 高低階語言compile出來的結果根本"差不多", 如果效率差不是因為附加物 那根本就是作者太弱, 語言未成熟 反過來說, 一些較複雜的algorithm, 或複雜的應用 你用低階語言也不一定做得出它的 performance 因為光要做出與高階語言特色能匹敵的library, 可能就是一件難事 例如有些語言, 提供你不限大小的型別去做運算 你用低階語言去實作, 參考, 組合, 包裝 .... 一些大數運算的library 可能弄了半天都沒有辦法做出那樣的 performance, 或寫出相同簡潔的程式. 個人意見 ※ 引述《Aurim (Who cares?)》之銘言： : ※ 引述《yauhh (喲)》之銘言： : : 所謂linked就是一個結構包含另一個結構. : : Linked list則是結構的包含方式比較有規律. : : 在這方面,我覺得要說語言不重要,在linked list上面不是如此. : : Linked list用C或C++寫才會特別把link帶出來. 用Python,談什麼link呢? : : 而真要說不被語言綁住的,是stack,queue,tree,graph這些language-free的東西. : 我說個有些人可能不愛聽的話，所有高階語言處理的資料都要放在計算機結構內。 : 這代表什麼呢？有的語言可能沒明確的指標，像Java，可是實際上物件型態的變數 : 都是動態物件，每個物件型態的變數都有個object reference，不像C++的物件有 : 分動態靜態。高階語言沒指標就不能實作linked list？那不是要哈哈哈了嗎？ : 有些人說linked list就是解決array有固定長度的問題，可是在我來看， : 每個電腦的記憶體量都是有限的，位址空間也是有限的。 : 說到底，大家都是在一個由CPU提供的byte/word/dword array中玩來玩去而已。 : 如果機械語言/組語能實作linked list，所有有array的語言就都可以實作它。 : 沒有人規定linked list的link一定要是指標或者以某個形態出現的啊。 : 你高興的話，只要能夠在現在的計算機結構下實作， : 你也可以把link隱含在自己發明的語言所提供的某種語意樣式裡。 : 其他資料結構沒有一個不可以這樣玩，第一次想到那樣的想法、發明那樣語言的時候， : 肯定很爽，我高中時很想自己來搞一個。 : 不過那又如何，現在的我來看，都是eye candy，拘泥於有形與無形的差別而已。 : 程式生產力真的有比較好嗎？有時候吃eye candy是要多付出代價的。 : Eye candy吃得愈多，離真正最底層的實作愈遙遠， : 對各種事務到底是怎麼運作的，就愈容易缺乏了解。 : 也許有的工作把愈底層的細節從真正要做的事情中抽離得愈遠愈好， : 但是也有的工作本來就是要從最底層的細節了解起，才能做得好的。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.138.35.146