Re: [討論] 請大家聊聊 JavaScript的缺陷
※ 引述《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 的方法.
而且我還是那句話, 你今天碰到 ts 世界以外的模組,
你是要怎麼 autocomplete 跟省時間.
你高興把自己關進籠子裡面是你的事情,
但有些人覺得這是找自己麻煩的事情,
不是你一句神奇專案才花時間可以帶過的.
: 相關的webpack config也只要設定一次, 何樂而不為呢
是每個專案你都得設一次.
: 當然你可以說, 只要平常規範足夠好, 大家團隊意識夠強
: 加上每個人記憶力超凡, 寫過的每個function是做什麼的都不會忘
不需要的
: 每個人都是完美的JS programmer不會踩到一些不該踩的坑
: 那當然用JS也不會有太大問題
一樣是不需要的
而且寫 ts 還是可以踩雷坑,
不要講的好像那些 bad pattern 在 ts 可以被語言層防住.
寫 ts 你不管好還是會有人寫 magic number,
還是會有人濫用 any, 還是會有人亂切責任跟 function.
就我在前端是界打滾的經驗, 前端世界要解決的問題,
最大的挑戰一直就是毫無意義的 include,
跟缺乏 management 的 codebase.
: 但我們都知道,
: 人 是一定會犯錯的
: 的確, TS不能解決所有問題, 但要把這鍋推給TS就有點詭異了
: 這個邏輯有點像:「反正用了也只是從30分到60分, TS真糞」
你可以舉例的時候不要一直帶入自己的偏好嗎
如果是我來舉例的話, 大概就是30分變20分吧, TS真糞.
這種舉例有什麼意思嗎?
你喜歡他可以美化他我沒意見, 但今天在討論中,
你有辦法就舉出真的改善了什麼, 舉案例出來, 有道理的沒人會反駁你.
但透過這種莫名其妙的比方, 甚至你原文也承認有需要更多設定,
有設定就有編譯時間耗損, 然後你只是輕描淡寫的說你覺得代價不大.
但我就是覺得這代價他不願意扛啊
這什麼亞利安星球反駁法.
: TS本來就是以盡量不破壞JS原有特性下改進JS的可讀性
嚴格來說, TS 破壞 JS syntax 的一致性,
但他最後轉回 JS,
所以你說不破壞JS原有特性我是可以理解.
(廢話 轉成 js 是要怎麼破壞 js 的一致性)
但不一致的 syntax 就會造成學習負擔.
jsx 當初出來也被幹譙過一樣的事情, 但當初大家忍是因為這樣可以換來,
跟 html 相關的 markup 表達, 確實有助於語意理解.
但這件事情也不是沒有代價的, 幹譙的聲音一直也都有,
我角度看這也是 react 遲遲無法一統江湖的核心因素之一.
: 拿any來說, 敝公司的tsconfig中是有設定nonImplicitAny
: 新寫的code中要用上any也必須給reviewer足夠好的理由
: 在prototype偷塞東西這種事情也是沒事不會做
所以你解決問題的方法是靠 reviewer 把關啊,
不是靠 TS 幫你把關啊, 你到底是來幫 ts 講話的還是黑 ts 的
: 除了一些很底層的模組, 例如支援mixin之類的
see?
: 不要因一時貪圖方便造成後續難以維護
: 我認同大大說的, 的確沒有辦法控制整個世界照我們想要的規矩走
: 但這不是我們不能在力所能及的範圍內做到最好的藉口
我個人覺得所謂的做到最好, 不是學會最屌的強型別,
而是組織好程式用最低的成本達成目標.
我說了, 輔助輪再怎麼樣會有輔助效果, 但他不是沒有代價的,
有些人從一進這個世界就付出這些代價, 自然已經感覺不到代價.
我前面幾篇都反覆再強調一件事情, 所有工具都有他要解決的目標情境,
但 JS 世界或許現在的人不太在意,
偶爾就會看到一些明顯沒這種知識的 application,
程式碼的組織跟程式碼的龐複程度還是嚴重的影響到下載速度跟體驗.
特別是 client rendering 的程式.
今天如果我們談的是 web base 的 ts code,
跟我們談 node base 的 ts code, node 我會覺得還好,
web 我就覺得有點浪費.
我們討論到這裡, 任何一個可能的專案情境都沒舉出來,
我實在是不知道我們在談什麼.
我今天談的不是 TS 有多糞, 而是沒掌握 JS 的人到底有啥好說 JS 糞的.
這當然是個戰文, 但我就想看有多少人可以戰這個議題, 然後講得周全.
對 TS 的優點講來講去就是 type check,
剛有個推文寫了, 無法明確定義 type 的是不好的工程師.
不好意思, 問題被錯置了, 誰跟你說無法定義 type,
是不需要用這種方式定義 type.
用相同邏輯, 我才想問,
不靠 TS 就搞不清楚 type 的, 是能當什麼工程師.
我從還沒 typescript 的年代就寫了很久的 js 了啦,
如果今天我們是在 ES6 class 還沒出來的年代,
(這是當年 typescript 最大的賣點),
這些倡議我都覺得有些道理, 這個年代,
我們再用能 autocomplete 來說明這件事情,
我也是會想問, 啊是寫了多偉大的東西. 需要這樣才能做好.
命題是想談新手好上手, 還是要談老手(我)對 ts 跟 js 的理解,
這些最好是講清楚, 不然被開群嘲我也不知道該怎麼救.
這世界上自以為自己是進步的人很多, 當年 rails 喊的多紅,
其實 typescript 也曾經吸引過一票人, 後來那些人多數都退坑了.
這次到底是再來一次, 還是能長久, 我倒是樂於看戲.
不要急著以為別人都不知道這些事情, 我們是看著規格一路發展過來的...
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是javascript
歡迎同好到 AJAX 板一同討論。
--
推這篇
你寫程式只顧自己的type跟convention?都沒有別人的?
team 要有一套自己的 type 跟 conention 啊。 不然咧,使用 ts 也是一種 team principle 啊。
3
npm 的問題,我試著安裝了一下 因為說是去年7月遇到的,所以我使用 2020/06/30 發佈的 node 12.18.2 搭配 npm 6.14.5 在只有裝 archiver-utils 的情況下,他很平,可能比我婆軟體還平 archiver-utils 底下沒有 node_modules , readable-stream 底下也沒有34
在開始之前,先說個笑話 ※ 引述《keev (a)》之銘言: : 我會試著反駁 互相交流 然而下面這串推文直接被無視 : 推 vi000246: 還要學打包工具 好麻煩 11/03 00:222
聽到你說 C# 一樣有 js 四捨五入的問題,我驚呆了,你肯定沒有嘗試過,沒關係,我幫 你試過了! 真不知道你的自信哪裡來的 我承認浮點數是個棘手的問題,但是有的語言會謹慎處理,有的語言就是隨便處理,事實X
其實我覺得戰場大家自己拉開的亂七八糟, 我也不過就是逐一回覆, autocomplete 我也說了根本不是語言的重點, 是其他人重視,這樣可以說你們在討論缺陷, 我在討論 autocomplete 我也覺得是有趣。3
你完全搞不清楚狀況喔。 dotnet 的 Math.Round() 預設是 四捨六入(五遇到前面為基數才進位)的設計,也就是 銀行家捨入法,也就是第三個參數為 ToEven 模式,我指定 AwayFromZero 是因為想走四 捨五入。 拔掉這個,走四捨六入也行,dotnet 就是照本宣科來,根本沒有你說的浮點數精確錯誤3
JavaScript 的概數運算確實沒有實作 IEEE 754 的標準, IEEE 754 中,Nearest value rounding 的方法有兩種: 1. Banker's rounding - 取到最接近的「偶數」 2. 取到最遠離 0 的數(效率佳) 但搞不清楚狀況的是對該語言不熟就隨便拿一個 function 來做概數的人,1
其實我上一篇已經有提到 Rounding mode 的選擇是關鍵了了, 然後那個不叫四捨六入...... 另外 tofixed 又誰跟你說他是四捨五入了.... 他是用浮點數的定位表示法(fixed-point notation) 計算的, 詳細實作有點囉嗦, 自己翻論文.8
不太認同, 如果今天的task是計算1加到10000 從紙上開始 1 + 2 + 3...一直算到10000可以解決問題 用等差數列的公式也可以解決問題 寫段code直接寫個function讓function可以支援不同的min, max也同樣能解決問題 這些方法都能解決問題?難道他們都是好方法嗎?17
我想 auto complete 可以算是開發工具的部分 (我猜任何語言理論上都可以有 auto complete,所以和語言本身無關) 而且在這篇沒看到原原 Po 提到,暫不討論 : 而且我還是那句話, 你今天碰到 ts 世界以外的模組, : 你是要怎麼 autocomplete 跟省時間.2
有誰可以告訴我,JavaScript 的 toFixed()為什麼遇到1,4,7這幾個數字後面的5不會 進位呢? --
27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A 代表他能力不算差17
[問卦] Python怎麼那麼難懂啊?variable type 不清楚,幹這數字到底是float還是int? function return type 也沒標記 function argument type 不知道是啥 oop語法有夠難懂 每次看python 的code都好痛苦5
Re: [請益] 比物件導向更先進的程式設計思想?JavaScript 是一個基於原型(Prototype-based)的程式語言 在本質上很難將它歸類為程序導向語言,或是物件導向語言 類別: JavaScript 中沒有類別(Class)的概念,但是有物件(object)的概念 而這個物件概念的物件,則是以GUI的 Widget為主9
Re: [討論] 請大家聊聊靜態語言的缺點問靜態和動態有缺點。怎麼不想想你公司是怎樣型態 如果你們公司成員 新舊和程度不一樣 就需要靜態語言處理程式,強制要成員遵守並規範。只要規範好,一般猴子也會按照著寫程 式。 動態語言吃的是開發人員素質,要自律,要對程式碼負責。6
Re: 不想唸碩士了,想去刷題想作一下補充,維護legacy code應該算是比較吃經驗跟工程技術: 1. 判別code smell 2. 了解原code的邏輯 (願意而且能夠讀懂別人的程式碼) 3. 還要能改得對 看這位大大應該是解題能力強、做大型專案的能力也強,把code寫對跟寫好對你3
Re: [討論] 請大家聊聊靜態語言的缺點借題發揮一下:static typed for the win 不過還是先切題回答「靜態語言的缺點」: 在大部分常用的靜態語言中,的確可能出現 valid program 不好標注 type 的情況 不過到底有多難標注就完全看是哪個語言跟哪個版本了 -----3
[請益] 模仿專案想請問一下各位版友,我是剛進 Web 圈沒多久的前端工程師。 未來想換工作的時候,為了讓自己有多點東西可以說 所以就想寫一個專案是有模仿到現在所接觸的專案(用Vue.js的) 現在所接觸到的專案前端大多都是自己寫的,所以印象算很深刻 但會轉成用 React 寫,然後後端自己刻刻看,功能一定不可能跟現在摸的專案一模一樣- 語言是最基礎到沒什麼好說嘴的東西 你應該學的是應用, 語言只是幫助你完成應用的工具 例如你想寫 image processing, 就挑一個喜歡的語言 然後看看有什麼 framework / tool 可以幫忙實作出想要的東西 大多數語言不外乎就是 primitive type / io / object oriented / syscall / etc