作者csfgsj (流水贯通)
看板Soft_Job
标题Re: [讨论] 请大家聊聊静态语言的缺点
时间Mon Nov 23 09:50:31 2020
※ 引述《fshfsh (鱼~*)》之铭言：
: 继上个系列串
: 我想问问大家认为静态型别的缺点是什麽呢?
: 本人写Java也写JS，最近也在碰Python
: 我自己写Java，一开始觉得宣告比较麻烦，需要思考这个变数是什麽型别
: (其实说实在，Java的变数最常使用也就几个，我正常刷Leetcode除非特殊情况否则很少会想不出要用什麽型别的变数)
: 优点是很明显的，一旦後面的型别错了，IDE直接跳错，也不给编译
这个问题实在是匪夷所思
以认知科学的观点看，当然是静态型别优於动态型别呀！
就像offer文在讨论薪水，在那边 N 来 N 去
在许多重要性质不确定的情况下，很多东西是很难精确的下判断的
不过如果贵圈的专注层次不在这里，不在乎，那也就无所谓
就像你们也可以不在乎，要不要少用全域变数、静态变数、Goto等 是一样的道理
动态型别，应该只是配合缺乏电脑底层语言知识的人
(JAVA人不爽，修改原文)
(应该只是让学JAVA这种连指标都没有，无关电脑底层知识语言的人)
一个方便的权宜作法吧！ 目的是为了配合它们的智商
(以这种智商来写程式其实是很惊险的，不知道语言开发单位，为何要堕落至此)
现在连动态型别是优，静态型别是缺点，这种说法都出来了
人有多大胆、地有多大产，说不定以後连牛顿定律都可以超越了
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 218.32.249.24 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1606096237.A.C5C.html
1F：嘘 hegemon: 笑死，动态型别用最凶的是蛇蛇跟Js吧 11/23 10:15
蛇蛇是啥？
2F：→ hegemon: Java是到jdk後面几个版本才支援动态好吗？ 11/23 10:15
3F：嘘 alihue: java 哪里支援动态...java var 那只是语法糖，但实际上完 11/23 10:17
4F：→ alihue: 全是静态好吗 11/23 10:17
5F：→ hegemon: 很多人吃这个语法糖吃得很开心，认为是进步的象徵，笑死 11/23 10:24
6F：嘘 SuperCry: 牛顿早就被超越了 11/23 11:11
7F：→ kiv9137: 蛇 => python 11/23 11:11
谢~
8F：嘘 mirror0227: 好啦我先 11/23 11:20
9F：推 maik060: 上半部讲的很关键, 下半部又呛, 只能推了 XDD 11/23 11:23
10F：推 ab4daa: 战啦 11/23 12:31
11F：嘘 strlen: 下一篇 为了配合你们智商才发明出自然程式语言 不然我们都 11/23 13:32
12F：→ strlen: 写组语长大的 11/23 13:32
13F：→ strlen: 下下一篇 配合你们才出组语 我们都直接看机器码 11/23 13:33
14F：→ strlen: 喔对阿 设计螺丝钉的比建筑师的智商还高 11/23 13:35
艰苦人 你又来了 太久没被修理 皮又在痒了
15F：→ strlen: 痒喔 来帮我抓抓 11/23 14:40
16F：→ casd82: java的var是type inference 不是 dynamically-typed 11/23 20:26
17F：→ casd82: 动态静态本来就各有所长战这个很无聊 11/23 20:27
18F：→ hduek153: 看到中间就笑了 谁支援一下工程师鄙视链 11/23 21:52
19F：嘘 snow0112: 牛顿定律早就被认为是过时了吧 11/24 00:39
20F：→ superpandal: 以认知来讲 型别并不会让你更容易看的懂 命名才是 11/24 07:12
21F：→ superpandal: offer的举例就两件事情 怎麽会那些判断因素与型别可 11/24 07:13
22F：→ superpandal: 以类比呢 11/24 07:13
这是认知科学中，一个两观的问题
人对於事物的认知，通常可以有两种层次，两种观点：构造观、功能观
例如：
衣服是布料做的(构造观)，衣服可以用来保暖、修饰(功能观)
车子有四个轮子(构造观)，车子可以代步，帮忙交通(功能观)
在程式设计的领域中，命名通常代表了对参数的功能观(功能认知)
而参数的型别，则代表了对参数的构造观(构造认知)
这两观互相独立，互不干扰，两观的认知都有，代表你对它的了解很透彻
只有功能观，有时候够用，有时候不够用
例如，呼叫Library，函式的命名可以让你知道函式的功能抽象
(要达到这个目的，前提是命名要很精准扼要，烂命名就不行了)
(如果函式的功能太过混杂，那麽命名要做到精准扼要，其实也不太可能)
(所以系统架构组织设计很重要，函式功能分割规划很重要)
(低耦合性、高内聚性很重要，越扯越多...etc. 说不完)
对於一个函式的使用者而言，通常只要知道函式的功能抽象，就足够了
但是对於函式的实作者来说，功能观只是基本的出发点
他还必须对函式的构造(构造观)，有一定的了解，才可实作函式
对於参数的操作，也是一样的道理，参数的命名通常代表了参数在系统中的功能角色
好的参数命名可以让我们从命名知道，这个参数是在做什麽的
但却无法让我们知道参数所占记忆体的大小，数值的上下限，系统对数值的处理方式等
基本的参数特性资讯
如果要处理是类似资料结构，记忆体配置等，这种底层基础的操作，
那麽光是掌握到命名(功能观)，其实是不太够的
23F：推 CoNsTaR: 如果你有 first class types，你就会学到“构造”（types 11/24 10:30
24F：→ CoNsTaR: ）和“功能”（calc）是等价的，在本质上没有区别 11/24 10:30
25F：→ CoNsTaR: 只是一般的语言强迫把它们断裂成 type 和实作两个东西， 11/24 10:30
26F：→ CoNsTaR: 规定某些地方只能写 type，其他地方只能写 value 而已 11/24 10:30
27F：推 CoNsTaR: 不懂在吵为什麽要 typecheck 的人怎麽不去吵为什麽需要编 11/24 10:36
28F：→ CoNsTaR: 译器或直译器 11/24 10:36
29F：→ CoNsTaR: 要证明你的 type 是正确的就是 typecheck，要证明你的实 11/24 10:36
30F：→ CoNsTaR: 作是正确的，就是看能不能编译成执行档（编译式），或是 11/24 10:36
31F：→ CoNsTaR: 能不能跑起来（直译式）啊 11/24 10:36
个人是非常不喜欢匿名函数的玩法
匿名函数完全以「实作」来作为操作的标的，
与用「函数名称」来操作比起来，它既没有抽象，也没有辨识认知上的简化
对於认知的操作来说，会非常的辛苦，而且没有效率
例如，我在想：如果要将这句话：「把『车子』开过来」以匿名函数的方式来表达
也就是用车子的「构造描述」来代替「车子的命名」来操作
这句话将会变成什麽模样
这种玩法，基本上是违反认知科学的效益原则的
有人玩得很高兴，不知道他们的脑袋在想什麽
32F：推 CoNsTaR: 如果你是在跟人讲话，用你的方式可能比较好，但是你的程 11/24 12:31
33F：→ CoNsTaR: 式要拿来跑的，不是拿来让电脑“认知”的，每个东西是怎 11/24 12:31
34F：→ CoNsTaR: 麽被构造的、怎麽被推导的就该被讲清楚，和认知科学一点 11/24 12:31
35F：→ CoNsTaR: 关系也没有 11/24 12:31
人在读写程式的时候，就是人跟程式在讲话，这个环节太重要了，怎麽可以忽略
程式语言的发明，是为人而生，还是为电脑而生
对於电脑来说，机器语言就够了
程式语言在开发的时候，本来就要考虑人的认知习惯，怎麽会跟认知科学没有关系
程式语言的世界中，奇门遁甲的东西太多了，有些东西的确为人类带来了方便
也有些东西，我一直在怀疑是不是专门发明用来整人的
36F：嘘 CoNsTaR: 那请问你 λx. x+1 这个函数你要取什麽名字 = = 11/24 13:46
37F：→ CoNsTaR: 你有 100 个地方需要这种小运算需要 delegate 的你就要 11/24 13:46
38F：→ CoNsTaR: 用 100 种名字宣告 100 个函数？ 11/24 13:46
这个问题太简单太低级了
如果是重复性高的小运算，用巨集就可以了
如果是重复性不高的小运算，通常就没有切割包装成函式或巨集的效益性
39F：→ CoNsTaR: 然後函数取对名子电脑就知道要怎麽跑了？ 11/24 13:46
重点在人的认知习惯，不在电脑，没有认真看本文齁
40F：嘘 CoNsTaR: 喔喔原来是 csfgsj，不小心和你认真了 11/24 13:47
奇摩子不爽了，为何不能理性讨论呢？
41F：→ strlen: 扯智商的在跟人家讲理性讨论 笑死 11/25 11:10
艰苦人每天都在吸笑气，笑了那麽久，到底死了没有
42F：→ superpandal: 你构造内还是得看命名阿 基本型别你不看命名有什麽快 11/25 18:43
43F：→ superpandal: 速的认知 已经结网成功能怎麽会变成一种单纯的属性 11/25 18:44
44F：→ superpandal: 相近的功能(构造)以假乱真造成这社会的乱象 11/25 19:10
我没有说死说一定要功能命名呀！
当下物件的构造最能代表物件，当然就用构造命名
命名的来源可以是各式各样的东西，如构造、功能、性质、外观特徵等
重点是，对使用操作来说，那一个最具有代表性、辨识性，用起来最方便
以水管的管件来举例，例如：弯头、三通、大小头
这些就是构造命名，并且从构造命名可以很轻易的推断它们的作用及功能
但是像api这一类的东西，通常是以功能命名的方式比较适合
PS：熊熊想到念国中时，训导处的管理组长，绰号叫「大龟头」
这个绰号虽然不雅，但却是一个很成功的命名，它来自被命名物件的外观
只要说到大龟头，大家都知道说在谁，这个绰号流传一届又一届，全校都知道
※ 编辑: csfgsj (218.32.249.24 台湾), 11/26/2020 09:51:02
45F：→ superpandal: 我说的是命名重要的多 如果你认为构造功能是种型别 11/28 07:19
46F：→ superpandal: 那物件很适合你 我认为的是开发方面物件不是都是优点 11/28 07:20
47F：→ superpandal: 有基本的就可以了 其他看函式 11/28 07:20