※ 引述《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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1605527149.A.743.html ※ 编辑: CoNsTaR (174.112.166.163 加拿大), 11/16/2020 20:07:33