推 Ting1024:看來A會覺得很委屈。>< 05/13 10:42
→ TonyQ:「有效能的價值是比寫不出來的高」這件事情只有在「客戶不滿 05/13 10:51
→ qrtt1:有人適合奮不顧身地開疆闢土,要快速發展得靠他。 05/13 10:51
→ TonyQ:意」的前提下才成立。不然都有高效率的靜態語言,弄一個比較 05/13 10:51
→ qrtt1:有人適合精細地檢視特定的細節,怪異的bug與tuning得靠他 05/13 10:52
→ TonyQ:慢得動態語言來寫而且還是一樣創造價值的人,就可以證明你的 05/13 10:52
→ qrtt1:顯然 A, B 是不同屬性的人。 05/13 10:52
→ TonyQ:論點謬誤了。 05/13 10:52
→ fashionguy:TonyQ你指的應該是語言的效率問題,但我指的是PG的 05/13 11:47
→ fashionguy:架構與寫法問題,比如只需要呼叫一次的方法卻寫在迴圈 05/13 11:48
→ fashionguy:中之類的問題。 05/13 11:49
→ fashionguy:這種差異無關乎語言,但是取決於PG的經驗與能力 05/13 11:51
→ TonyQ:我的意思是,效率這回事是只有在他需要的時候才有用。 05/13 11:53
→ TonyQ:不是無止盡的追求好就好,不然就不會有人用比較慢得語言。 05/13 11:53
→ TonyQ:以你的例子來講,關鍵點不是工程師寫出的效能不好,(若真追 05/13 11:54
→ TonyQ:求效能,還有很多方式可以改善,作不完的。),而是 05/13 11:54
→ TonyQ:「用戶不滿意效能」<這句。 05/13 11:54
→ TonyQ:而你改善效能的標的,通常也僅止於「讓用戶滿意效能」,所以 05/13 11:54
→ TonyQ:使用者需求 drive 你的技術需求。 05/13 11:54
→ TonyQ:而不單純是追求寫得更快這件事情,在你的例子你可能覺得那只 05/13 11:55
→ TonyQ:是技能的問題,但那是基本的效能調校。 05/13 11:55
→ TonyQ:高階的效能調校(cache、改演算法等),大多是牽扯專案架構 05/13 11:56
→ TonyQ:的整體結構,並且會有對應的限制、開發上的複雜度,到那個層 05/13 11:56
→ TonyQ:次就不只是要考慮效能問題了。 05/13 11:56
→ TonyQ:舉個例子,concurrent高又需要即時互動的系統,可能甚至就得 05/13 11:56
→ TonyQ:採用 nodejs 這類能作為前端大量 client 承載的系統作為第一 05/13 11:57
→ TonyQ:個入口或者 api server,但是也會因為這樣而帶來技術複雜度 05/13 11:58
→ TonyQ:跟專案複雜度。 05/13 11:58
→ TonyQ:而且追求效能到一個程度之後,基本上事情大多也只是取捨。 05/13 12:00
→ TonyQ:我的意見是,與其追求效能更好,倒不如積極研究找出哪裡讓系 05/13 12:03
→ TonyQ:統變慢的能力,能作這個的價值恐怕還比改善效能來得高許多。 05/13 12:04
推 thinkniht:@TonyQ:怎麼不用回文的方式回呢? 05/13 12:09
→ fashionguy:to TonyQ:我很認同你的看法,所以同我本篇的一開頭, 05/13 14:30
→ fashionguy:我回這篇的目的是不希望有些新手看完後直接內化為 05/13 14:31
→ fashionguy:「這種能力不重要」所以半點也不努力。 05/13 14:33
→ fashionguy:如果基本的調校都做不到,也沒法進入到你說的地步囉 05/13 14:37