作者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/m.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