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

[CoNsTaR ((const *))]

※ 引述《TonyQ (得理饒人)》之銘言：
: ※ 引述《as30385438 (LCH)》之銘言：
: : 光是在obj後面.一下就會跑出各種method和argument/return type
: : 就不知道能避免多少低級錯誤和省下查文件翻code的時間了
: : 所以說用TS會拖慢開發速度的人
: : 我真的不知道他是在做什麼神奇的專案需要用到諸多JS的神奇特性
:         project scan 就是需要時間, 你檔案數多到一個程度, 就是慢.
:         webpack 有那麼多 tooltip 再加速效能, 難道是假的.
:         說真的, 這段話反過來說也是可以還給你的.
:         連自己的 type 跟 convention 都掌握不好的, 是有什麼好靠邀的.
:         另外 js 的 autocomplete,
:         就算是十五年前我用 aptana 就有 autocomlete,
:         真的這麼喜歡有 type 寫個 jsdoc 就好.
:         (還是不知道什麼是 jsdoc?)
:         是要多聰明才覺得 typescript 是唯一達成 autocomplete 的方法.

我想 auto complete 可以算是開發工具的部分
（我猜任何語言理論上都可以有 auto complete，所以和語言本身無關）
而且在這篇沒看到原原 Po 提到，暫不討論


:         而且我還是那句話, 你今天碰到 ts 世界以外的模組,
:         你是要怎麼 autocomplete 跟省時間.
:         你高興把自己關進籠子裡面是你的事情,
:         但有些人覺得這是找自己麻煩的事情,
:         不是你一句神奇專案才花時間可以帶過的.

無法理解
我們今天比較的是 ts 和 js 本身有/沒有哪個缺陷
而不是哪個能不能用另一個的模組


: : 相關的webpack config也只要設定一次, 何樂而不為呢
:         是每個專案你都得設一次.
: : 當然你可以說, 只要平常規範足夠好, 大家團隊意識夠強
: : 加上每個人記憶力超凡, 寫過的每個function是做什麼的都不會忘
:         不需要的
: : 每個人都是完美的JS programmer不會踩到一些不該踩的坑
: : 那當然用JS也不會有太大問題
:         一樣是不需要的

套句你講的話，「可是別人就連要去注意這些問題都不想啊」


:         而且寫 ts 還是可以踩雷坑,
:         不要講的好像那些 bad pattern 在 ts 可以被語言層防住.
:         寫 ts 你不管好還是會有人寫 magic number,
:         還是會有人濫用 any, 還是會有人亂切責任跟 function.
:         就我在前端是界打滾的經驗, 前端世界要解決的問題,

建設道路、制定交通準則你不管好還是會有人亂開車
但不代表這樣就不該建設道路、制定交通準則

然後不知道 magic number、責任亂切和 types 的關係在哪裡？


:         最大的挑戰一直就是毫無意義的 include,
:         跟缺乏 management 的 codebase.
: : 但我們都知道,
: : 人 是一定會犯錯的
: : 的確, TS不能解決所有問題, 但要把這鍋推給TS就有點詭異了
: : 這個邏輯有點像：「反正用了也只是從30分到60分, TS真糞」
:         你可以舉例的時候不要一直帶入自己的偏好嗎
:         如果是我來舉例的話, 大概就是30分變20分吧, TS真糞.
:         這種舉例有什麼意思嗎?

我猜原原 Po 這邊講的分數是能做的事情的範圍的意思
（從他說的「的確，TS 不能解決所有問題」得知）

因為 ts 提供了方法來做 js 不能做的事情，所以 30 -> 60
我理解成「還沒到 100，但可以做的事變廣了」的意思

請問你 30 -> 20（能掌控的事變少）的根據是什麼？
是你自己提出的不該作為參考的個人喜好嗎？


:         你喜歡他可以美化他我沒意見, 但今天在討論中,
:         你有辦法就舉出真的改善了什麼, 舉案例出來, 有道理的沒人會反駁你.

例：改善了本應被 rejected 的 term 竟然會被 accepted 的問題

不要跟我說講這不切實際
如果你真的有能力來 judge 一個系統的好壞（像你這篇在做的）
你就一定知道這樣會造成的所有 consequences 是什麼

套句你說的，如果你連 types 可以做什麼都要別人舉例來告訴你，你又有什麼能力去批
評它？


:         但透過這種莫名其妙的比方, 甚至你原文也承認有需要更多設定,
:         有設定就有編譯時間耗損, 然後你只是輕描淡寫的說你覺得代價不大.
:         但我就是覺得這代價他不願意扛啊
:         這什麼亞利安星球反駁法.

我想代價大不大不是這裡的重點（不同情境代價都可能不同）
我們討論為什麼一個系統比另一個更健全（更少「缺陷」）


: : TS本來就是以盡量不破壞JS原有特性下改進JS的可讀性
:         嚴格來說, TS 破壞 JS syntax 的一致性,

兩個不同語言，如果不看語言出生的時間，我也可以說 js 破壞 ts 語法的一致性

我想原原 Po 這邊講的是，和你去用其他語言相比
ts 可能會讓 js 使用者感覺更親切


:         但他最後轉回 JS,
:         所以你說不破壞JS原有特性我是可以理解.
:         (廢話 轉成 js 是要怎麼破壞 js 的一致性)

？？
無關的語言也都可以互相編譯成對方，不太懂你括號內的意思


:         但不一致的 syntax 就會造成學習負擔.
:         jsx 當初出來也被幹譙過一樣的事情, 但當初大家忍是因為這樣可以換來,
:         跟 html 相關的 markup 表達, 確實有助於語意理解.
:         但這件事情也不是沒有代價的, 幹譙的聲音一直也都有,

這邊先學 ts 的人也會因為各種不一致而得到「學習 js 的負擔」啊
我覺得學東西有成本是很 obvious 的，否則還要學嗎？


:         我角度看這也是 react 遲遲無法一統江湖的核心因素之一.
: : 拿any來說, 敝公司的tsconfig中是有設定nonImplicitAny
: : 新寫的code中要用上any也必須給reviewer足夠好的理由
: : 在prototype偷塞東西這種事情也是沒事不會做
:         所以你解決問題的方法是靠 reviewer 把關啊,
:         不是靠 TS 幫你把關啊, 你到底是來幫 ts 講話的還是黑 ts 的

ts 把問題從「任意程式該不該被接受」
變成了「任意一個 any 是否有被使用的理由」
我覺得這還滿明顯的


: : 除了一些很底層的模組, 例如支援mixin之類的
:         see?
: : 不要因一時貪圖方便造成後續難以維護
: : 我認同大大說的, 的確沒有辦法控制整個世界照我們想要的規矩走
: : 但這不是我們不能在力所能及的範圍內做到最好的藉口
:         我個人覺得所謂的做到最好, 不是學會最屌的強型別,
:         而是組織好程式用最低的成本達成目標.
:         我說了, 輔助輪再怎麼樣會有輔助效果, 但他不是沒有代價的,

calculus 和 type 是相輔相成的
對於電腦來說，calculus 做的事更能被看見，但 type 絕對不只是輔助輪


以下這部分看起來和討論語言的缺陷沒什麼關係，容我略過
:         有些人從一進這個世界就付出這些代價, 自然已經感覺不到代價.
:         我前面幾篇都反覆再強調一件事情, 所有工具都有他要解決的目標情境,
:         但 JS 世界或許現在的人不太在意,
:         偶爾就會看到一些明顯沒這種知識的 application,
:         程式碼的組織跟程式碼的龐複程度還是嚴重的影響到下載速度跟體驗.
:         特別是 client rendering 的程式.
:         今天如果我們談的是 web base 的 ts code,
:         跟我們談 node base 的 ts code, node 我會覺得還好,
:         web 我就覺得有點浪費.
:         我們討論到這裡, 任何一個可能的專案情境都沒舉出來,
:         我實在是不知道我們在談什麼.


:         我今天談的不是 TS 有多糞,  而是沒掌握 JS 的人到底有啥好說 JS 糞的.

用你自己說的話來講，沒掌握 type 和計算之間的關係的人到底有啥好說 type 只是計算
的輔助輪而已的


:         這當然是個戰文, 但我就想看有多少人可以戰這個議題, 然後講得周全.
:         對 TS 的優點講來講去就是 type check,
:         剛有個推文寫了,  無法明確定義 type 的是不好的工程師.
:         不好意思, 問題被錯置了, 誰跟你說無法定義 type,
:         是不需要用這種方式定義 type.

目前 introduce 一個 value 到一個 type （你講的定義 type）的方式有兩種，nominal
 和非 nominal
請問你宣稱存在的某種定義方式是哪一種？


:         用相同邏輯, 我才想問,
:         不靠 TS 就搞不清楚 type 的, 是能當什麼工程師.

能不需要看 type annotations 就可以快速掌握一個 proof 在做什麼的確是很好的能力/
天份
但這並不 support js 不能 attach type annotations 的事實


:         我從還沒 typescript 的年代就寫了很久的 js 了啦,
:         如果今天我們是在 ES6 class 還沒出來的年代,
:         (這是當年 typescript 最大的賣點),
:         這些倡議我都覺得有些道理, 這個年代,
:         我們再用能 autocomplete 來說明這件事情,
:         我也是會想問, 啊是寫了多偉大的東西. 需要這樣才能做好.

我想這還是不能論證 js/ts 有/沒有什麼缺陷
或 ts 有沒有改善 js 哪個缺陷


:         命題是想談新手好上手, 還是要談老手(我)對 ts 跟 js 的理解,
:         這些最好是講清楚, 不然被開群嘲我也不知道該怎麼救.
:         這世界上自以為自己是進步的人很多, 當年 rails 喊的多紅,
:         其實 typescript 也曾經吸引過一票人, 後來那些人多數都退坑了.
:         這次到底是再來一次, 還是能長久, 我倒是樂於看戲.
:         不要急著以為別人都不知道這些事情, 我們是看著規格一路發展過來的...

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 174.112.166.163 (加拿大)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1605527149.A.743.html
推 alihue: 推推
※ 編輯: CoNsTaR (174.112.166.163 加拿大), 11/16/2020 20:07:33
推 LERICAL: 推
推 laputaflutin: 推，尤其是道路那段舉例
→ laputaflutin: 不知道為什麼談個語言缺陷可以歪到談autocomplete
→ laputaflutin: 就拿null問題就好，歷史因素造成很多語言都有這種
→ laputaflutin: 缺陷，新的語言幾乎都用Maybe, Option來解決null
→ laputaflutin: 這不就語言層的缺陷
推 art1: 因為有人先提到「光是在obj後面.一下就會跑出各種method和
推 keke0421: good
→ art1: argument/return type
→ laputaflutin: 當然js也有相應的package，不過如果未來ES標準
→ laputaflutin: 也加入就更好了
推 as30385438: 我是原文，autocomplete當然是IDE或plugin提供的功能
→ as30385438: 但用ts有type後IDE就不需要用「猜」的了，精準得多
→ as30385438: 當然用JSDoc也行，但個人覺得JSDoc花的成本還比type
→ as30385438: 高多了，然後感覺TonyQ可能現在做的事情越來越高了
→ as30385438: 最近發文都高來高去下不來了，離實務開發越來越遠
→ as30385438: 目前所待的公司產品已經發展了四年了，這一年引入ts後
→ as30385438: 所有RD一致認同前端部分code quality好上了一個層次
→ as30385438: 然後我還是不能理解引入ts的成本哪裡高了，至少維護
→ as30385438: 年的專案，花個半天把ts設定好，有很浪費時間嗎...
→ as30385438: 學習成本以接觸過一般OO語言的工程師來說也幾乎是0
→ as30385438: 至少我沒聽過有誰或寫js，換成ts就不會寫了，需要花
→ as30385438: 個把天學習，如果有的話麻煩分享一下
推 lturtsamuel: 有了ts誰還寫什麼jsdoc 又不是整個專案都要ts 只寫個
→ lturtsamuel: .d檔也行 註解都不一定能好好更新了為什麼會相信jsdo
→ lturtsamuel: c就可以？型別都寫不好的人我怎麼相信他jsdoc能寫好
→ lturtsamuel: ？
推 lturtsamuel: 講得好像ts在走下坡一樣...現在大部分有規模的函式庫
→ lturtsamuel: 都有definitely typed，react也越來越多人用ts寫 你
→ lturtsamuel: 說它會被wasm幹掉我還比較相信
推 caasih: 推只寫 .d 檔也行，甚至只定義用到的部分， ts 能這樣做就
→ caasih: 是在幫你把關介面。至於嫌棄編譯速度的，可以改用OCaml 。
推 dream1124: 在我看他就是心情不好，連發數篇文章嘩眾取寵罷了。
→ dream1124: 寫過ts就知道能提供型態資訊給轉譯器差了多少
→ dream1124: 他大概還以為那會迫使大家像是寫舊版java狂宣告型態
→ dream1124: 其實只要專案和模組輸出的物件有宣告就好用又差不多了
→ dream1124: 更別提javac有型態推論後，寫法其實跟ts也越來越像
→ dream1124: 下班還要費力跟他論戰真是辛苦了。他想寫js就讓他繼續
→ dream1124: 這大概就是因為新科技讓他以前培養的技能無用而不爽吧
→ dream1124: 哦對了，現在就算是寫js還有多少新專案不用轉譯器啊？
→ dream1124: 框架和建置工具預設就幫你啟用 babel 了
→ dream1124: 接著既然都要用轉譯器，那為啥不直上 tsc 就好？
推 windclara: 我還聽過有人覺得自己能只使用Txt寫JS而洋洋得意…
推 johnny055279: 說到底，工程師都活在自己的世界啦！只有自己熟悉
→ johnny055279: 的工具最棒惹
→ TonyQ: "感覺"真是個可怕的東西。
→ TonyQ: coding quality 基本上如果能靠 ts 變好，那表示門檻太低。
→ TonyQ: 本來太差。
→ dreamnook: js本身特性是真的很容易導致本來太差
→ dreamnook: 因為其他語言是連compiler都不給過（咦
推 BEARlol: M$大概都三流工程師才會開發ts 寫個程式都要輔助輪
→ newhandfun: 可能是本碼農太魯，實務上真的還是有規範比沒規範好
→ newhandfun: 的......
→ testPtt: 不知道用ts還是js的三流工程師比較多?
→ TonyQ: 是說 ts 是發展在 es6 還沒開始的年代，當年確實需要更好的
→ TonyQ:  class syntax 來 migrate 非 js 世界的人。
→ TonyQ: 這在我前幾篇文章都有寫到，要無腦黑也不用把別人的論點忽
→ TonyQ: 視吧。
→ TonyQ: 另外有時候有些東西是一流或二流的工程師開發給"還是"三流
→ TonyQ: 的人用的，
→ TonyQ: 像是你們不會用 scratch 寫程式，但可視化對缺乏抽象執行流
→ TonyQ: 程構成的人來說卻很重要。
→ TonyQ: 不會因為用 scratch 都是小朋友，就等於開發 scratch 是弱
→ TonyQ: 者吧。
→ TonyQ: 這種論述自己講起來真的不會心虛嗎？
→ TonyQ: 另外，我很喜歡舉 rails 的例子是，rails 當初也是打著新科
→ TonyQ: 技要淘汰老古板的姿態。
→ TonyQ: 新科技從來不是問題，react 我學他跟使用的年度是 2014 年
→ TonyQ: 。
→ TonyQ: webpack 甚至早一點的 grunt ，我們也都是在某些適當的場景
→ TonyQ: 首批採用的人。
→ TonyQ: typescript 也不是什麼新東西，他現在會比較紅是因為 angul
→ TonyQ: ar 決定採用 ts 為基礎語言。
→ TonyQ: 在那之前我們早就看著他發展，並且也試著用過一陣子。
→ TonyQ: 要說我們是因為新東西而不願意接受，我不反對這可能是個人
→ TonyQ: 偏好的差異，但這東西要說他是新東西，那就肯定是個菜鳥了
→ TonyQ: 。
→ testPtt: 我4感覺這好像20年前學c的看不起vb一樣喇
→ TonyQ: 我覺得比較像是八年前寫 rails 的，看不起寫 php 的啦。
推 BEARlol: 原來M$花大錢開發給三流工程師用的 不是內部需求
→ BEARlol: 真是佛心公司 花錢開發這麼大的project 給新人練功 但以
→ BEARlol: 後還是寫js
→ TonyQ: yahoo 當年傾全公司之力開發了 yui ，應用在該司所有的產品
→ TonyQ: 上。現在 yui 已成歷史的眼淚了。
→ TonyQ: google 開發 GWT 意圖簡化 client developing 成本，已經很
→ TonyQ: 久沒聽到他了。
→ TonyQ: google 開發 dart 本來意圖取代 js ，現在也轉方針了。
→ TonyQ: 前車很多可以鑑，這些失敗的嘗試都是英勇的挑戰，但英勇的
→ TonyQ: 挑戰不代表成功的挑戰。
推 BEARlol: 好了啦 事實是ts解決很多工程師覺得很重要的問題
→ BEARlol: 推不推得動不是一間公司可以決定的事
→ BEARlol: 但他們就是覺得這個東西是有意義的
→ BEARlol: ts 的熱門度已經證明很多事了
→ BEARlol: 不同意就算了 你的主觀想法也要爭 很好笑
→ TonyQ: 討論區不就是每個人自己寫自己的看法，你的事實說也是蠻有
→ TonyQ: 趣的。 XDD
→ TonyQ: 是你自己說ms 推的東西一定是棒棒的，被反例反駁才在那邊 5
→ TonyQ: 43...
→ TonyQ: 這很難看。XD
→ BEARlol: ...
推 TurnV: 來晚了，只能站牆外看戲了
推 mepowerlmay: 果然看到tonyq