Re: [討論] 請大家聊聊 JavaScript的缺陷

[TonyQ (得理饒人)]

        是說應該要定義什麼是好什麼是爛,
        我是覺得啦, 能解決問題叫好, 不能解決問題叫爛.

        但這就有一個操作空間, 就個人對語言的掌握程度/能力程度,
        會影響到一個人對語言的判斷.


        像是有人對直譯器(interpreter) 的理解不夠,
        對 contract based 的程式邏輯掌握度不夠.

        所以騎個腳踏車還需要裝兩個輪子(TS/TSX)在旁邊輔助, 才能正常寫程式.

        這是能力的問題.


        但雖然裝輔助輪慢了點, 久了總是會到終點了, 歡喜甘願就好.


        當然, 自古以來許多人能力不好就怪環境不好,
        這自然是可以理解的, 但這種情況要互相討論, 可能就有點高處不勝寒了.


        動態語言跟強型別語言本來從開發工作,
        開發方法, 工作做法都會不一樣,

        拿十字鍬去伐木, 砍不斷樹是自然的.


        所謂的缺點跟優點是相對於要解決的問題的,
        就以控制 dom event, render html/css , 發起請求等來說, 他已經夠好了.

        該有的語法特色都有, 喜歡 class 的也終於在 ES6 邁向皆大歡喜.

        主流的 async 處理方針, async/await 也都在ES7 都跟上了.


        如果我們今天說的是十年前, CORS 還沒發展好, fetch 不完整,
        display 還沒好好的實裝, float 還很難用沒有 flexbox 的年代.

        要說的話就是要引用的基礎類別有點多, 計算量有點大.


        當年還要面對 js interface 不統一的問題 (該死的 document.all ),
        而且當時還要引入 jQuery 才有 selector.


        但到這個年代,早期最被詬病的那些問題早就都有解法,
        要討論優點跟缺點, 要同時把要解決問題拉出來談, 不然這都是瞎談.


        不然直接說一句 js 要移殖 c++ 程式很難寫, 大家就散會就好.
        (啊 其實也有 wasm 可以用啦)


        每個語言都有他的樣態跟生態, 跨語言比較的盲點就在,
        你會其中一個, 但你不會另一個啊.

        你不懂得理解兩個不同的語言的差異之處啊.


        程式只是工具, 人才是決定 code 是不是垃圾的載體.

--

      網頁上拉近距離的幫手              實現 GMail豐富應用的功臣   

        數也數不清的友善使用者體驗      這就是ｊａｖａｓｃｒｉｐｔ

                                                歡迎同好到 AJAX 板一同討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.44.97 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1605454758.A.173.html
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/15/2020 23:40:16
推 kangan987: 推
推 shter: 其實我覺得選擇多本來是好事，但就會出現被人為限制的問題
→ shter: 比如 new 的對象，有傳統 function this prototype 寫法
→ shter: 也有 ES6 後為了迎合物件導向而給的 class
→ shter: 但往往一堆專案為了統一也法而限制開發人員要用何種寫法
→ shter: 然後選擇舊寫法的人常被新寫法的人當雷包、老古板在看
基本上看 code 寫的乾不乾淨，如果寫的乾淨清楚，用啥都行。

寫不乾淨就別跟我談什麼套件語法，
好好練基本功吧。

組織函式，組織功能，訂好介面是所有語言必要的項目。

syntax 是用來幫助這些事情的，不是拿來當藉口的。

※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 01:16:38
→ as30385438: 當然不是用啥都行，稍有規模的公司都有coding style吧
→ as30385438: 為了style的一致性用舊語法寫應該是滿常見的
這其實還是回到團隊共識問題，正常來說，架構師會選擇對當時最適合的結構。
不一定是舊的也不一定是新的，舊 code 也能翻新，只是需要轉換過程。
→ drakd4d: 我個人是覺得TypeScript目的是增加多人協作時的可維護性
→ drakd4d: 你自幹的時候，當然你的大腦掌握了全局，但別人在讀你的
→ drakd4d: 程式碼時可不見得是這樣
→ drakd4d: 要開發快速當然不要去搞什麼TS，但人多的時候欲速則不達
多人協作強調的是工作方法論跟模組切分的能力，用 TS 並不意味著你可以更好的做到這些事情。
推 gocreating: 推寫不好就怪工具
→ samuel1988: 這篇可以被戰，就我所知人才不會去寫前端xd
→ samuel1988: 聰明人不會浪費時間處理特例和例外。
→ jobintan: 當年寫jq的都去寫angular/react/vue了，哪年ARV三大會不
→ jobintan: 被別的技架（如webassembly）取代都不知道，也只能說，
→ jobintan: 長江後浪推前浪，一代新物換舊物，想吃工程這行飯，就得
→ jobintan: 持續學習，讓自己的技能與知識與時俱進才行。
→ jobintan: sorry，打錯，是技術框架。:P
→ onlyeric23: js是要編譯的喔
interpreter 那段是要討論 js 是有機會從 runtime 再塞東西進來的，在一些情境下，這是個要留意的特點。
推 LERICAL: 推
→ siriusu: 從單兵作戰角度看也許是這樣，但不要忘記軟體工程討論的
→ siriusu: 不只是單兵作戰，避免 antipattern 也應該考慮在語言能
→ siriusu: 力之中；講 js 有他的任務有歷史包袱無可厚非但我不覺得
→ siriusu: 相比其他語言精通起來學習成本高不是一個缺陷
again ，這是相對於目標的。如果我們今天談的是 ui handling ，放眼望去在所有語言(如 windows form or android)，要處理 dsp 跟 requesting，同時不 block UI thread ，這些都是複雜的。

如果單談可以快速寫個 for 或 資料處理，純語言面特性。

我還真沒看過有人嫌 js 難上手的，畢竟不用裝複雜的環境，語法內建就靈活，array 就能當 list 用還不需要定義長度。
object 內建就是 map。

js 談的就是好寫，被靠北的多是 async 的複雜度跟 error handling ，

async 是相對於 ui 的需求，
error handling 其實不是做不到，該有的語法都有，
但我覺得本質上就是語法特性太好寫，大家根本懶得寫 error handling 。


所以要說 js 的學習成本高，
很多人都會說一些特別比較不好懂。

但說真的，寫這麼久 js ，
真的要用到那些不好懂的東西還真的少。

所以，好歹定義一個情境他解題起來，比其他語言差吧。

我剛有想到一個啦，他的 reduce api 開爛了，在拿來對 collection 拿來做加總之類操作時，實在是很難寫。

不過可以用別的簡單方法替代，就是有點鳥。


寫久了對他哪邊好哪邊不好，自然會很清楚。

另外只要你倚賴語言，所有語言都有 antipattern，要避免 antipattern 靠的是對「情境」的瞭解。

也是我這篇在強調的，你不能把語言跟工具脫離於情境。

ex. Lua 我寫過覺得不是個好寫的語言，但他在 game 曾經有過輝煌的歲月。

有些 dsl 被創造出來是有其目的跟意義的，這不是任務跟歷史價值，而是他的需求。

也不用拿著一把刀解決所有的問題，要用適當的工具解決適當的問題。
※ 編輯: TonyQ (114.136.69.202 臺灣), 11/16/2020 09:04:29
※ 編輯: TonyQ (114.136.69.202 臺灣), 11/16/2020 09:05:51
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 09:16:57
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/16/2020 09:22:04
→ leo5916267: 我覺得ts 方便的點在於我們看到變數時我們知道他的資
→ leo5916267: 料結構長怎樣，不然只能爬code然後console 看他吐出
→ leo5916267: 什麼樣
問題是你沒辦法讓整個世界照 ts 的規矩走,
而且還有 any 的存在, 這只是個不會到達的理想國.

而且即使他宣稱是這個結構, 實務上他還是可以傳入不是這個結構的程式給你.

噓 CoNsTaR: 天氣預報也會報錯啊，所以你也反對天氣預報嗎？「你不能
→ CoNsTaR: 讓世界的天氣照著天氣預報走」XDDXXD
所以你每天早上都看天氣預報決定自己要做什麼反應嗎?

選用基礎環境工具意味著你每件事情都不得不參考他,
你幹嘛花這麼大的代價綁住自己只為了一個看不見的餅.


這就跟當初 java 體系一堆人跑去搞 scala/groovy, 因為不喜歡 java的一些特性,
有些人會寫的很爽, 我不反對, 事實上也是.

但他們要紅就得自己去感染世界,
而不是宣稱在原本世界的人都是蠢人吧. 誰蠢都還有得討論咧.


拿出情境, 拿出案例, 講清楚哪個案例他更有優勢,
如果你覺得自己可以完全不學 js, 只在 ts 世界度過一輩子, 那ts 肯定很適合你.

但如果你得回到 js 世界, 恭喜你, 你學習成本一定大於只學 js 的人.

※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:10:20
推 CoNsTaR: 你平常看不懂別人在做什麼的時候都不會問“你在做什麼”
→ CoNsTaR: 嗎？別人給你的回答就像是程式語言的 type，雖然因為語
→ CoNsTaR: 言精細度的關係，別人可能沒辦法很清楚的解釋他在做什麼
→ CoNsTaR: ，但是它可以給你一個 idea
→ CoNsTaR: 而在程式裡，type 和 value 的關係比現實生活中用嘴巴講
→ CoNsTaR: 的要強多了
→ CoNsTaR: 雖然大部分語言都沒有一個像 Idris, Agda 這樣完備的 typ
→ CoNsTaR: e system，來保證所有的 type 都是正確的（甚至可以當作
→ CoNsTaR: 數學、邏輯命題驗證系統來用，也不可能會出現你講的偷塞
→ CoNsTaR:  any 的事情），但是我也不認為大部分的人都有能力用像 I
→ CoNsTaR: dris Agda 那樣精確的語言來寫程式，ts 對於 js 已經是一
→ CoNsTaR: 個 improvement，而且也是一個符合大部分人的能力的 impr
→ CoNsTaR: ovement（不會太難），不認為有什麼好 criticize 的

→ as30385438: 覺得還是類比錯誤，js到ts幾乎是無痛學習吧
就我學過 Java,JS,vbscript,jscript, ruby, python, php 等語言的經驗,
js 到 ts 我不覺得是無痛學習喔,
這種看起來很像, 但有專屬語法的東西學起來反而特別煩.

設定環境也是痛, 設定 IDE 也是痛, 找更相容的套見也是痛,
但你要覺得無痛我沒意見, 只是我對無痛提反對一票.


→ as30385438: 對於有其他語言經驗的人來說，學習成本低到不行
→ as30385438: 扣掉一些進階特性ts一樣是你認識的那個js而已
問題還是我幹嘛學 ts ?

(btw 其實我會寫 ts 啦, 幹嘛假設我不會? 我只是懶得寫 ts. 理由同原文.)

推 jason82714: 推 寫不好就怪工具
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:39:31
噓 CoNsTaR: 看了你的回覆，提醒你，理論電腦科學的根基就是 type 和
→ CoNsTaR:  calculus，任何東西只要能夠在電腦中出現，一定能夠有 i
→ CoNsTaR: ntroduction 和 elimination rule，也一定可以 reduce
→ CoNsTaR:  成一個 NF，並且它的根本就是離散的而非連續的，所以在
→ CoNsTaR: 電腦的世界裡根本就無法存在像你講的“不能用 type 描述
→ CoNsTaR: ”或“只能 ill typed 描述”的東西，問題只是你的 type
→ CoNsTaR:  system 願不願意把自己做得這麼精確而已，因為會讓很多
→ CoNsTaR: 沒有數理邏輯底子的人不會用，如果你想要，你可以完全只
→ CoNsTaR: 寫 well typed 的程式（就像你講的不要回到 js），完全沒
→ CoNsTaR: 有做不到的事情，問題是我不認為大部分的人有能力做到這
→ CoNsTaR: 樣，而 ts 正是這樣 compromise 下的產物
拆開來每個字都看得懂, 合起來怎麼看都覺得在浪費我時間.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:40:58
推 CoNsTaR: Java,JS,vbscript,jscript, ruby, python, php...
→ CoNsTaR: 好吧，我不該在這裡和你認真的，就繼續你的 OO 治理世界
→ CoNsTaR: 吧
推 CoNsTaR: 如果你真的知道 type theory 和任何一個與 lambda calcul
→ CoNsTaR: us 等價的 calculi 在做什麼，我想你大概就可以合起來也
→ CoNsTaR: 看懂了，但我想你還是算了
        確實沒什麼興趣看你念經.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:50:32
推 CoNsTaR: 如果你沒自信懂這些，那我想你應該也沒有自信可以批評 ty
→ CoNsTaR: pe 的用處才對？
→ CoNsTaR: 這是我想要講的
        我是很佩服你這麼有自信說這些話,
        但我覺得這讀起來沒證明任何事情. XD

        你要講什麼都可以, 這世界不缺人自言自語.

        但要講讓別人聽得懂, 那就需要些技巧了.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:54:36
推 CoNsTaR: 我認為這些都是理論電腦科學的基礎中的基礎，不認為這需
→ CoNsTaR: 要什麼“神奇的技巧來解釋”
→ CoNsTaR: 但我可以把它說得更清楚一點：
→ CoNsTaR: 任何 term 都有 I/E rules，而且都能夠 reduce 成 NF，
→ CoNsTaR: 而且 NF 具有相等性（題外話，甚至不同 NF 也能有等價性
→ CoNsTaR: ，參考 Homotopy Type Theory），加上電腦不處理連續的
→ CoNsTaR: 問題
→ CoNsTaR: 所以，任何可以用電腦解決的問題都可以是 well typed 的
→ CoNsTaR: 程式，而且不存在可以用電腦解決，但只能 ill typed 的程
→ CoNsTaR: 式（唯一的例外大概就是 random access array 和 input/o
→ CoNsTaR: utput，但相關的解決方案也已經存在很久了）
→ CoNsTaR: 從以上你之前說的“無法讓整個世界照著 ts 走”就是有問
→ CoNsTaR: 題的敘述（如果把它理解成“無法把所有程式都寫成 well t
→ CoNsTaR: yped 的程式”的話）
→ CoNsTaR: 雖然看起來很像又把之前講的重複一遍，但這是我能想到最
→ CoNsTaR: 不佔篇幅又最貼近問題的講法了
        這些沒辦法拿來證 ts 是 compromise 的選擇喔.

        文不對題在任何作文通常都是零分啦.

        另外 無法讓整個世界照著 ts 走, 並不是讓整個世界寫成 well-type 的程式,
        而是無法解決使用 ts 的引入成本在此刻仍然很高的問題.

        我談的是一直是 cost.


        事實上如果把 any 視為是一種 type, well-type 並不困難.
        本來 js 世界要達到抽性別共用就是把 object 這一層抽象掉才達成的.

        而 any 就是被創造出來相容這件事情的.


        但這種繞圈子的說法我覺得不是在討論問題而是在抬槓了.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 15:38:46
推 CoNsTaR: any 就是 compromise...
→ CoNsTaR: type 不是 first class 也是 compromise
→ CoNsTaR: 不能把 forall 寫在任何地方也是 compromise...
→ CoNsTaR: 而造成這些 compromise 的原因就是因為要照顧只會寫像 js
→ CoNsTaR:  這種語言的人
→ CoNsTaR: 你不能說因為有這些 compromise 所以 ts 也沒比 js 好到
→ CoNsTaR: 那，甚至進而又反過來說 ts 做的改變是反而是不好的
→ CoNsTaR: 另外，當你要討論一個語言的缺陷的時候，你不能說因為它
→ CoNsTaR: 引入的 cost 比較低所以缺陷比較小，我猜這也是為什麼很
→ CoNsTaR: 多人覺得你的 claim 不能 hold 的原因
有人, 不等於很多人.

反過來, 也有人支持我的 claim.
另外我沒宣稱 ts 是不好的, 我說的是他有他適合的用途, 也有他的問題.

cost 低當然是一個優點, cost 高就是一個缺點, 為什麼不能說,
你的邏輯看起來充滿著選擇性呢.
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 16:00:03
推 CoNsTaR: 當你在討論語言的時候，缺點/優點不能 imply 缺陷...
→ CoNsTaR: 舉例：
→ CoNsTaR: 缺點/優點：效能高/語法容易/工具健全/容易取得...
→ CoNsTaR: 缺陷：不能表達某個在 System-F 中可以表達的 term/不能
→ CoNsTaR:  deduce 某個 term 的 type/不能區分某兩個不同的 term..
→ CoNsTaR: .
→ CoNsTaR: just to be correct，我說的很多人意思是在那些不認同的
→ CoNsTaR: 人之中的很多人，不是試圖說有多少人不認同
        說真的, i don't care what you think.

推 CoNsTaR: 像是這篇很多人提到的 NaN 之類的問題不是都屬於缺陷的
→ CoNsTaR: 部分嗎？
→ CoNsTaR: 例如 NaN 屬於數字，意思就是它無法區分 NaN 和數字之間
→ CoNsTaR: 的不同
→ CoNsTaR: 我只是想要說，如果你想討論有/沒有哪些缺陷，你不能只
→ CoNsTaR: 說引入 cost 低所以缺陷都不存在，我想你也同意這點
        沒用到就不算是缺陷.
        就跟我們不會說菜刀砍不了樹, 電鋸切不了魚是缺陷一樣.

        NaN 搭配 isNaN 來說有他的用法,
        也可以考慮在 parse 之前先做檢查.

        NaN 是不是個問題也要看前後文.
        我不會說缺陷不存在, 但重點是你想拿他來做什麼.


        另外我也沒有想討論有沒有缺陷, 我想討論的是,
        在討論這些缺陷之前, 我們要解決的問題跟這些缺陷到底有沒有關係.


※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 16:34:58
→ newhandfun: 前幾樓要不要直接回文啊？這也打太長
推 abraxas: 不錯哦，問題都在人身上了，這樣也沒啥好討論啦
→ s06yji3: 工具也是有差
噓 lturtsamuel: 你是不是對機器語言瞭解不夠才要裝程式語言當輔助輪
這麼說也沒錯啊，這輔助輪棒的呢。
推 musie: 唸過PL的人 在這邊幫沒念書的人上課 我是覺得白費力氣
→ musie: 你就讓他在他的世界活得好好的, 不是很好 他也不介意
→ musie: 那些複雜的Church-Turning, Curry-Howard 一點意義
我 2006 年就修過 PL 了，但這串到底誰在談 PL 啊，靠北，PL 是這樣談的嗎？ XD
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:09:40
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:10:31
推 musie: 你真的修過PL會不知道Curry–Howard–Lambek correspons.
→ musie: 帶來的意義? type = logic = catgory?
→ musie: 說啥type跟calc分開 你好像不知道他們就是等價的
啊我沒講的東西，你要假設我不會我是沒意見，PL 一個三學分的課我確實只修了些該學的。
但你可以不要罵錯我沒講的東西嗎？
我可從來沒否定型別的價值，我只是在意成本。XDDDD
推 musie: 抱歉.. 上面那一句不是你講的 你連那個概念都還沒有
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:26:25
→ strlen: 聽起來像是「這爛工具用久了還是有好用的地方啦」 古有為
→ strlen: 賦新詞強說愁 今有為寫程式強說讚？笑死
→ strlen: 不可否認JS爛是有背景因素啦 就是各家大廠對前端各懷鬼胎
→ strlen: 惡性競爭下來的權宜之計 權久了莫名奇妙就做大了 但原因
→ strlen: 是一回事 爛不爛又是另一回事
倒也沒有要說 js 沒有爛的部分，看大老那本 js the good part 的人都不會反對js 有爛的部分。為了 js 強說讚的大老很多，我們大腿抱緊包好。

只是 ts 是不是解決 js 爛的方法，抱著問號而已。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:38:03
推 m3gl4a: 想不到tonyQ大大還蠻懂css,沒flexbox的時代切版很累
推 dophin332: 推情境和要解決的問題是關鍵.