作者TonyQ (得理饶人)
看板Soft_Job
标题Re: [讨论] 请大家聊聊 JavaScript的缺陷
时间Sun Nov 15 23:39:15 2020
是说应该要定义什麽是好什麽是烂,
我是觉得啦, 能解决问题叫好, 不能解决问题叫烂.
但这就有一个操作空间, 就个人对语言的掌握程度/能力程度,
会影响到一个人对语言的判断.
像是有人对直译器(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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1605454758.A.173.html
※ 编辑: TonyQ (61.231.44.97 台湾), 11/15/2020 23:40:16
1F：推 kangan987: 推 11/16 00:15
2F：推 shter: 其实我觉得选择多本来是好事，但就会出现被人为限制的问题 11/16 00:40
3F：→ shter: 比如 new 的对象，有传统 function this prototype 写法 11/16 00:41
4F：→ shter: 也有 ES6 後为了迎合物件导向而给的 class 11/16 00:41
5F：→ shter: 但往往一堆专案为了统一也法而限制开发人员要用何种写法 11/16 00:42
6F：→ shter: 然後选择旧写法的人常被新写法的人当雷包、老古板在看 11/16 00:42
基本上看 code 写的乾不乾净，如果写的乾净清楚，用啥都行。
写不乾净就别跟我谈什麽套件语法，
好好练基本功吧。
组织函式，组织功能，订好介面是所有语言必要的项目。
syntax 是用来帮助这些事情的，不是拿来当藉口的。
※ 编辑: TonyQ (61.231.44.97 台湾), 11/16/2020 01:16:38
7F：→ as30385438: 当然不是用啥都行，稍有规模的公司都有coding style吧 11/16 01:30
8F：→ as30385438: 为了style的一致性用旧语法写应该是满常见的 11/16 01:31
这其实还是回到团队共识问题，正常来说，架构师会选择对当时最适合的结构。
不一定是旧的也不一定是新的，旧 code 也能翻新，只是需要转换过程。
9F：→ drakd4d: 我个人是觉得TypeScript目的是增加多人协作时的可维护性 11/16 02:21
10F：→ drakd4d: 你自干的时候，当然你的大脑掌握了全局，但别人在读你的 11/16 02:22
11F：→ drakd4d: 程式码时可不见得是这样 11/16 02:22
12F：→ drakd4d: 要开发快速当然不要去搞什麽TS，但人多的时候欲速则不达 11/16 02:23
多人协作强调的是工作方法论跟模组切分的能力，用 TS 并不意味着你可以更好的做到这些事情。
13F：推 gocreating: 推写不好就怪工具 11/16 02:37
14F：→ samuel1988: 这篇可以被战，就我所知人才不会去写前端xd 11/16 06:40
15F：→ samuel1988: 聪明人不会浪费时间处理特例和例外。 11/16 06:44
16F：→ jobintan: 当年写jq的都去写angular/react/vue了，哪年ARV三大会不 11/16 07:40
17F：→ jobintan: 被别的技架（如webassembly）取代都不知道，也只能说， 11/16 07:41
18F：→ jobintan: 长江後浪推前浪，一代新物换旧物，想吃工程这行饭，就得 11/16 07:41
19F：→ jobintan: 持续学习，让自己的技能与知识与时俱进才行。 11/16 07:42
20F：→ jobintan: sorry，打错，是技术框架。:P 11/16 07:48
21F：→ onlyeric23: js是要编译的喔 11/16 07:49
interpreter 那段是要讨论 js 是有机会从 runtime 再塞东西进来的，在一些情境下，这是个要留意的特点。
22F：推 LERICAL: 推 11/16 07:57
23F：→ siriusu: 从单兵作战角度看也许是这样，但不要忘记软体工程讨论的 11/16 07:58
24F：→ siriusu: 不只是单兵作战，避免 antipattern 也应该考虑在语言能 11/16 07:58
25F：→ siriusu: 力之中；讲 js 有他的任务有历史包袱无可厚非但我不觉得 11/16 07:58
26F：→ siriusu: 相比其他语言精通起来学习成本高不是一个缺陷 11/16 07:58
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
27F：→ leo5916267: 我觉得ts 方便的点在於我们看到变数时我们知道他的资 11/16 12:03
28F：→ leo5916267: 料结构长怎样，不然只能爬code然後console 看他吐出 11/16 12:03
29F：→ leo5916267: 什麽样 11/16 12:03
问题是你没办法让整个世界照 ts 的规矩走,
而且还有 any 的存在, 这只是个不会到达的理想国.
而且即使他宣称是这个结构, 实务上他还是可以传入不是这个结构的程式给你.
30F：嘘 CoNsTaR: 天气预报也会报错啊，所以你也反对天气预报吗？「你不能 11/16 14:01
31F：→ CoNsTaR: 让世界的天气照着天气预报走」XDDXXD 11/16 14:01
所以你每天早上都看天气预报决定自己要做什麽反应吗?
选用基础环境工具意味着你每件事情都不得不参考他,
你干嘛花这麽大的代价绑住自己只为了一个看不见的饼.
这就跟当初 java 体系一堆人跑去搞 scala/groovy, 因为不喜欢 java的一些特性,
有些人会写的很爽, 我不反对, 事实上也是.
但他们要红就得自己去感染世界,
而不是宣称在原本世界的人都是蠢人吧. 谁蠢都还有得讨论咧.
拿出情境, 拿出案例, 讲清楚哪个案例他更有优势,
如果你觉得自己可以完全不学 js, 只在 ts 世界度过一辈子, 那ts 肯定很适合你.
但如果你得回到 js 世界, 恭喜你, 你学习成本一定大於只学 js 的人.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:10:20
32F：推 CoNsTaR: 你平常看不懂别人在做什麽的时候都不会问“你在做什麽” 11/16 14:16
33F：→ CoNsTaR: 吗？别人给你的回答就像是程式语言的 type，虽然因为语 11/16 14:16
34F：→ CoNsTaR: 言精细度的关系，别人可能没办法很清楚的解释他在做什麽 11/16 14:16
35F：→ CoNsTaR: ，但是它可以给你一个 idea 11/16 14:16
36F：→ CoNsTaR: 而在程式里，type 和 value 的关系比现实生活中用嘴巴讲 11/16 14:16
37F：→ CoNsTaR: 的要强多了 11/16 14:16
38F：→ CoNsTaR: 虽然大部分语言都没有一个像 Idris, Agda 这样完备的 typ 11/16 14:16
39F：→ CoNsTaR: e system，来保证所有的 type 都是正确的（甚至可以当作 11/16 14:16
40F：→ CoNsTaR: 数学、逻辑命题验证系统来用，也不可能会出现你讲的偷塞 11/16 14:16
41F：→ CoNsTaR: any 的事情），但是我也不认为大部分的人都有能力用像 I 11/16 14:16
42F：→ CoNsTaR: dris Agda 那样精确的语言来写程式，ts 对於 js 已经是一 11/16 14:16
43F：→ CoNsTaR: 个 improvement，而且也是一个符合大部分人的能力的 impr 11/16 14:16
44F：→ CoNsTaR: ovement（不会太难），不认为有什麽好 criticize 的 11/16 14:16
45F：→ as30385438: 觉得还是类比错误，js到ts几乎是无痛学习吧 11/16 14:17
就我学过 Java,JS,vbscript,jscript, ruby, python, php 等语言的经验,
js 到 ts 我不觉得是无痛学习喔,
这种看起来很像, 但有专属语法的东西学起来反而特别烦.
设定环境也是痛, 设定 IDE 也是痛, 找更相容的套见也是痛,
但你要觉得无痛我没意见, 只是我对无痛提反对一票.
46F：→ as30385438: 对於有其他语言经验的人来说，学习成本低到不行 11/16 14:17
47F：→ as30385438: 扣掉一些进阶特性ts一样是你认识的那个js而已 11/16 14:18
问题还是我干嘛学 ts ?
(btw 其实我会写 ts 啦, 干嘛假设我不会? 我只是懒得写 ts. 理由同原文.)
48F：推 jason82714: 推 写不好就怪工具 11/16 14:36
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:39:31
49F：嘘 CoNsTaR: 看了你的回覆，提醒你，理论电脑科学的根基就是 type 和 11/16 14:37
50F：→ CoNsTaR: calculus，任何东西只要能够在电脑中出现，一定能够有 i 11/16 14:37
51F：→ CoNsTaR: ntroduction 和 elimination rule，也一定可以 reduce 11/16 14:37
52F：→ CoNsTaR: 成一个 NF，并且它的根本就是离散的而非连续的，所以在 11/16 14:37
53F：→ CoNsTaR: 电脑的世界里根本就无法存在像你讲的“不能用 type 描述 11/16 14:37
54F：→ CoNsTaR: ”或“只能 ill typed 描述”的东西，问题只是你的 type 11/16 14:37
55F：→ CoNsTaR: system 愿不愿意把自己做得这麽精确而已，因为会让很多 11/16 14:37
56F：→ CoNsTaR: 没有数理逻辑底子的人不会用，如果你想要，你可以完全只 11/16 14:37
57F：→ CoNsTaR: 写 well typed 的程式（就像你讲的不要回到 js），完全没 11/16 14:37
58F：→ CoNsTaR: 有做不到的事情，问题是我不认为大部分的人有能力做到这 11/16 14:37
59F：→ CoNsTaR: 样，而 ts 正是这样 compromise 下的产物 11/16 14:37
拆开来每个字都看得懂, 合起来怎麽看都觉得在浪费我时间.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:40:58
60F：推 CoNsTaR: Java,JS,vbscript,jscript, ruby, python, php... 11/16 14:47
61F：→ CoNsTaR: 好吧，我不该在这里和你认真的，就继续你的 OO 治理世界 11/16 14:47
62F：→ CoNsTaR: 吧 11/16 14:47
63F：推 CoNsTaR: 如果你真的知道 type theory 和任何一个与 lambda calcul 11/16 14:49
64F：→ CoNsTaR: us 等价的 calculi 在做什麽，我想你大概就可以合起来也 11/16 14:49
65F：→ CoNsTaR: 看懂了，但我想你还是算了 11/16 14:49
确实没什麽兴趣看你念经.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:50:32
66F：推 CoNsTaR: 如果你没自信懂这些，那我想你应该也没有自信可以批评 ty 11/16 14:53
67F：→ CoNsTaR: pe 的用处才对？ 11/16 14:53
68F：→ CoNsTaR: 这是我想要讲的 11/16 14:53
我是很佩服你这麽有自信说这些话,
但我觉得这读起来没证明任何事情. XD
你要讲什麽都可以, 这世界不缺人自言自语.
但要讲让别人听得懂, 那就需要些技巧了.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:54:36
69F：推 CoNsTaR: 我认为这些都是理论电脑科学的基础中的基础，不认为这需 11/16 15:24
70F：→ CoNsTaR: 要什麽“神奇的技巧来解释” 11/16 15:24
71F：→ CoNsTaR: 但我可以把它说得更清楚一点： 11/16 15:24
72F：→ CoNsTaR: 任何 term 都有 I/E rules，而且都能够 reduce 成 NF， 11/16 15:24
73F：→ CoNsTaR: 而且 NF 具有相等性（题外话，甚至不同 NF 也能有等价性 11/16 15:24
74F：→ CoNsTaR: ，参考 Homotopy Type Theory），加上电脑不处理连续的 11/16 15:24
75F：→ CoNsTaR: 问题 11/16 15:24
76F：→ CoNsTaR: 所以，任何可以用电脑解决的问题都可以是 well typed 的 11/16 15:24
77F：→ CoNsTaR: 程式，而且不存在可以用电脑解决，但只能 ill typed 的程 11/16 15:24
78F：→ CoNsTaR: 式（唯一的例外大概就是 random access array 和 input/o 11/16 15:25
79F：→ CoNsTaR: utput，但相关的解决方案也已经存在很久了） 11/16 15:25
80F：→ CoNsTaR: 从以上你之前说的“无法让整个世界照着 ts 走”就是有问 11/16 15:25
81F：→ CoNsTaR: 题的叙述（如果把它理解成“无法把所有程式都写成 well t 11/16 15:25
82F：→ CoNsTaR: yped 的程式”的话） 11/16 15:25
83F：→ CoNsTaR: 虽然看起来很像又把之前讲的重复一遍，但这是我能想到最 11/16 15:25
84F：→ CoNsTaR: 不占篇幅又最贴近问题的讲法了 11/16 15:25
这些没办法拿来证 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
85F：推 CoNsTaR: any 就是 compromise... 11/16 15:55
86F：→ CoNsTaR: type 不是 first class 也是 compromise 11/16 15:55
87F：→ CoNsTaR: 不能把 forall 写在任何地方也是 compromise... 11/16 15:55
88F：→ CoNsTaR: 而造成这些 compromise 的原因就是因为要照顾只会写像 js 11/16 15:55
89F：→ CoNsTaR: 这种语言的人 11/16 15:55
90F：→ CoNsTaR: 你不能说因为有这些 compromise 所以 ts 也没比 js 好到 11/16 15:55
91F：→ CoNsTaR: 那，甚至进而又反过来说 ts 做的改变是反而是不好的 11/16 15:55
92F：→ CoNsTaR: 另外，当你要讨论一个语言的缺陷的时候，你不能说因为它 11/16 15:55
93F：→ CoNsTaR: 引入的 cost 比较低所以缺陷比较小，我猜这也是为什麽很 11/16 15:55
94F：→ CoNsTaR: 多人觉得你的 claim 不能 hold 的原因 11/16 15:55
有人, 不等於很多人.
反过来, 也有人支持我的 claim.
另外我没宣称 ts 是不好的, 我说的是他有他适合的用途, 也有他的问题.
cost 低当然是一个优点, cost 高就是一个缺点, 为什麽不能说,
你的逻辑看起来充满着选择性呢.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 16:00:03
95F：推 CoNsTaR: 当你在讨论语言的时候，缺点/优点不能 imply 缺陷... 11/16 16:07
96F：→ CoNsTaR: 举例： 11/16 16:07
97F：→ CoNsTaR: 缺点/优点：效能高/语法容易/工具健全/容易取得... 11/16 16:07
98F：→ CoNsTaR: 缺陷：不能表达某个在 System-F 中可以表达的 term/不能 11/16 16:07
99F：→ CoNsTaR: deduce 某个 term 的 type/不能区分某两个不同的 term.. 11/16 16:07
100F：→ CoNsTaR: . 11/16 16:07
101F：→ CoNsTaR: just to be correct，我说的很多人意思是在那些不认同的 11/16 16:07
102F：→ CoNsTaR: 人之中的很多人，不是试图说有多少人不认同 11/16 16:07
说真的, i don't care what you think.
103F：推 CoNsTaR: 像是这篇很多人提到的 NaN 之类的问题不是都属於缺陷的 11/16 16:28
104F：→ CoNsTaR: 部分吗？ 11/16 16:28
105F：→ CoNsTaR: 例如 NaN 属於数字，意思就是它无法区分 NaN 和数字之间 11/16 16:28
106F：→ CoNsTaR: 的不同 11/16 16:28
107F：→ CoNsTaR: 我只是想要说，如果你想讨论有/没有哪些缺陷，你不能只 11/16 16:28
108F：→ CoNsTaR: 说引入 cost 低所以缺陷都不存在，我想你也同意这点 11/16 16:28
没用到就不算是缺陷.
就跟我们不会说菜刀砍不了树, 电锯切不了鱼是缺陷一样.
NaN 搭配 isNaN 来说有他的用法,
也可以考虑在 parse 之前先做检查.
NaN 是不是个问题也要看前後文.
我不会说缺陷不存在, 但重点是你想拿他来做什麽.
另外我也没有想讨论有没有缺陷, 我想讨论的是,
在讨论这些缺陷之前, 我们要解决的问题跟这些缺陷到底有没有关系.
※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 16:34:58
109F：→ newhandfun: 前几楼要不要直接回文啊？这也打太长 11/16 17:00
110F：推 abraxas: 不错哦，问题都在人身上了，这样也没啥好讨论啦 11/16 21:40
111F：→ s06yji3: 工具也是有差 11/16 22:52
112F：嘘 lturtsamuel: 你是不是对机器语言了解不够才要装程式语言当辅助轮 11/17 00:23
这麽说也没错啊，这辅助轮棒的呢。
113F：推 musie: 念过PL的人 在这边帮没念书的人上课 我是觉得白费力气 11/17 00:41
114F：→ musie: 你就让他在他的世界活得好好的, 不是很好 他也不介意 11/17 00:42
115F：→ musie: 那些复杂的Church-Turning, Curry-Howard 一点意义 11/17 00:49
我 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
116F：推 musie: 你真的修过PL会不知道Curry–Howard–Lambek correspons. 11/17 10:14
117F：→ musie: 带来的意义? type = logic = catgory? 11/17 10:14
118F：→ musie: 说啥type跟calc分开 你好像不知道他们就是等价的 11/17 10:15
啊我没讲的东西，你要假设我不会我是没意见，PL 一个三学分的课我确实只修了些该学的。
但你可以不要骂错我没讲的东西吗？
我可从来没否定型别的价值，我只是在意成本。XDDDD
119F：推 musie: 抱歉.. 上面那一句不是你讲的 你连那个概念都还没有 11/17 10:22
※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:26:25
120F：→ strlen: 听起来像是「这烂工具用久了还是有好用的地方啦」 古有为 11/17 10:30
121F：→ strlen: 赋新词强说愁 今有为写程式强说赞？笑死 11/17 10:30
122F：→ strlen: 不可否认JS烂是有背景因素啦 就是各家大厂对前端各怀鬼胎 11/17 10:32
123F：→ strlen: 恶性竞争下来的权宜之计 权久了莫名奇妙就做大了 但原因 11/17 10:32
124F：→ strlen: 是一回事 烂不烂又是另一回事 11/17 10:32
倒也没有要说 js 没有烂的部分，看大老那本 js the good part 的人都不会反对js 有烂的部分。为了 js 强说赞的大老很多，我们大腿抱紧包好。
只是 ts 是不是解决 js 烂的方法，抱着问号而已。
※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:38:03
125F：推 m3gl4a: 想不到tonyQ大大还蛮懂css,没flexbox的时代切版很累 11/17 14:24
126F：推 dophin332: 推情境和要解决的问题是关键. 11/20 08:44