Re: [讨论] 请大家聊聊 JavaScript的缺陷

楼主: CoNsTaR ((const *))   2020-11-16 19:45:47
※ 引述《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 也曾经吸引过一票人, 后来那些人多数都退坑了.
: 这次到底是再来一次, 还是能长久, 我倒是乐于看戏.
: 不要急着以为别人都不知道这些事情, 我们是看着规格一路发展过来的...
作者: alihue (wanda wanda)   2020-11-16 19:58:00
推推
作者: LERICAL (统二布丁)   2020-11-16 20:26:00
作者: laputaflutin (很恐怖,不要问)   2020-11-16 20:55:00
推,尤其是道路那段举例不知道为什么谈个语言缺陷可以歪到谈autocomplete就拿null问题就好,历史因素造成很多语言都有这种缺陷,新的语言几乎都用Maybe, Option来解决null这不就语言层的缺陷
作者: art1 (人,原来不是人)   2020-11-16 21:08:00
因为有人先提到“光是在obj后面.一下就会跑出各种method和
作者: keke0421 (zrae)   2020-11-16 21:08:00
good
作者: art1 (人,原来不是人)   2020-11-16 21:09:00
argument/return type
作者: laputaflutin (很恐怖,不要问)   2020-11-16 21:09:00
当然js也有相应的package,不过如果未来ES标准也加入就更好了
作者: as30385438 (LCT)   2020-11-16 21:11:00
我是原文,autocomplete当然是IDE或plugin提供的功能但用ts有type后IDE就不需要用“猜”的了,精准得多当然用JSDoc也行,但个人觉得JSDoc花的成本还比type高多了,然后感觉TonyQ可能现在做的事情越来越高了最近发文都高来高去下不来了,离实务开发越来越远目前所待的公司产品已经发展了四年了,这一年引入ts后所有RD一致认同前端部分code quality好上了一个层次然后我还是不能理解引入ts的成本哪里高了,至少维护年的专案,花个半天把ts设定好,有很浪费时间吗...学习成本以接触过一般OO语言的工程师来说也几乎是0至少我没听过有谁或写js,换成ts就不会写了,需要花个把天学习,如果有的话麻烦分享一下
作者: lturtsamuel (港都都教授)   2020-11-17 00:06:00
有了ts谁还写什么jsdoc 又不是整个专案都要ts 只写个.d档也行 注解都不一定能好好更新了为什么会相信jsdoc就可以?型别都写不好的人我怎么相信他jsdoc能写好?讲得好像ts在走下坡一样...现在大部分有规模的函式库都有definitely typed,react也越来越多人用ts写 你说它会被wasm干掉我还比较相信
作者: caasih   2020-11-17 02:40:00
推只写 .d 档也行,甚至只定义用到的部分, ts 能这样做就是在帮你把关接口。至于嫌弃编译速度的,可以改用OCaml 。
作者: dream1124 (全新开始)   2020-11-17 07:34:00
在我看他就是心情不好,连发数篇文章哗众取宠罢了。写过ts就知道能提供型态资讯给转译器差了多少他大概还以为那会迫使大家像是写旧版java狂宣告型态其实只要专案和模组输出的物件有宣告就好用又差不多了更别提javac有型态推论后,写法其实跟ts也越来越像下班还要费力跟他论战真是辛苦了。他想写js就让他继续这大概就是因为新科技让他以前培养的技能无用而不爽吧哦对了,现在就算是写js还有多少新专案不用转译器啊?框架和建置工具默认就帮你启用 babel 了接着既然都要用转译器,那为啥不直上 tsc 就好?
作者: windclara (null)   2020-11-17 08:07:00
我还听过有人觉得自己能只使用Txt写JS而洋洋得意…
作者: johnny055279 (巴辣松)   2020-11-17 08:46:00
说到底,工程师都活在自己的世界啦!只有自己熟悉的工具最棒惹
作者: TonyQ (自立而后立人。)   2020-11-17 09:02:00
"感觉"真是个可怕的东西。coding quality 基本上如果能靠 ts 变好,那表示门槛太低。本来太差。
作者: dreamnook (亚龙)   2020-11-17 09:10:00
js本身特性是真的很容易导致本来太差因为其他语言是连compiler都不给过(咦
作者: BEARlol (yogaisgood)   2020-11-17 09:24:00
M$大概都三流工程师才会开发ts 写个程式都要辅助轮
作者: newhandfun (新手方)   2020-11-17 09:35:00
可能是本码农太鲁,实务上真的还是有规范比没规范好的......
作者: testPtt (测试)   2020-11-17 09:46:00
不知道用ts还是js的三流工程师比较多?
作者: TonyQ (自立而后立人。)   2020-11-17 09:48:00
是说 ts 是发展在 es6 还没开始的年代,当年确实需要更好的class syntax 来 migrate 非 js 世界的人。这在我前几篇文章都有写到,要无脑黑也不用把别人的论点忽视吧。另外有时候有些东西是一流或二流的工程师开发给"还是"三流的人用的,像是你们不会用 scratch 写程式,但可视化对缺乏抽象执行流程构成的人来说却很重要。不会因为用 scratch 都是小朋友,就等于开发 scratch 是弱者吧。这种论述自己讲起来真的不会心虚吗?另外,我很喜欢举 rails 的例子是,rails 当初也是打着新科技要淘汰老古板的姿态。新科技从来不是问题,react 我学他跟使用的年度是 2014 年。webpack 甚至早一点的 grunt ,我们也都是在某些适当的场景首批采用的人。typescript 也不是什么新东西,他现在会比较红是因为 angular 决定采用 ts 为基础语言。在那之前我们早就看着他发展,并且也试着用过一阵子。要说我们是因为新东西而不愿意接受,我不反对这可能是个人偏好的差异,但这东西要说他是新东西,那就肯定是个菜鸟了。
作者: testPtt (测试)   2020-11-17 10:02:00
我4感觉这好像20年前学c的看不起vb一样喇
作者: TonyQ (自立而后立人。)   2020-11-17 10:05:00
我觉得比较像是八年前写 rails 的,看不起写 php 的啦。
作者: BEARlol (yogaisgood)   2020-11-17 10:11:00
原来M$花大钱开发给三流工程师用的 不是内部需求真是佛心公司 花钱开发这么大的project 给新人练功 但以后还是写js
作者: TonyQ (自立而后立人。)   2020-11-17 10:15:00
yahoo 当年倾全公司之力开发了 yui ,应用在该司所有的产品上。现在 yui 已成历史的眼泪了。google 开发 GWT 意图简化 client developing 成本,已经很久没听到他了。google 开发 dart 本来意图取代 js ,现在也转方针了。前车很多可以鉴,这些失败的尝试都是英勇的挑战,但英勇的挑战不代表成功的挑战。
作者: BEARlol (yogaisgood)   2020-11-17 10:24:00
好了啦 事实是ts解决很多工程师觉得很重要的问题推不推得动不是一间公司可以决定的事但他们就是觉得这个东西是有意义的ts 的热门度已经证明很多事了不同意就算了 你的主观想法也要争 很好笑
作者: TonyQ (自立而后立人。)   2020-11-17 10:27:00
讨论区不就是每个人自己写自己的看法,你的事实说也是蛮有趣的。 XDD是你自己说ms 推的东西一定是棒棒的,被反例反驳才在那边 543...这很难看。XD
作者: BEARlol (yogaisgood)   2020-11-17 10:34:00
...
作者: TurnV (TurnV)   2020-11-22 23:42:00
来晚了,只能站墙外看戏了
作者: mepowerlmay (用心,找对人)   2020-11-30 00:39:00
果然看到tonyq

Links booklink

Contact Us: admin [ a t ] ucptt.com