Re: [討論] 請大家聊聊靜態語言的缺點

看板Soft_Job作者 (流水貫通)時間3年前 (2020/11/23 09:50), 3年前編輯推噓-3(5推 8噓 34→)
留言47則, 13人參與, 3年前最新討論串3/6 (看更多)
※ 引述《fshfsh (魚~*)》之銘言： : 繼上個系列串 : 我想問問大家認為靜態型別的缺點是什麼呢? : 本人寫Java也寫JS，最近也在碰Python : 我自己寫Java，一開始覺得宣告比較麻煩，需要思考這個變數是什麼型別 : (其實說實在，Java的變數最常使用也就幾個，我正常刷Leetcode除非特殊情況否則很少會想不出要用什麼型別的變數) : 優點是很明顯的，一旦後面的型別錯了，IDE直接跳錯，也不給編譯 這個問題實在是匪夷所思 以認知科學的觀點看，當然是靜態型別優於動態型別呀！ 就像offer文在討論薪水，在那邊 N 來 N 去 在許多重要性質不確定的情況下，很多東西是很難精確的下判斷的 不過如果貴圈的專注層次不在這裡，不在乎，那也就無所謂 就像你們也可以不在乎，要不要少用全域變數、靜態變數、Goto等 是一樣的道理 動態型別，應該只是配合缺乏電腦底層語言知識的人 (JAVA人不爽，修改原文) (應該只是讓學JAVA這種連指標都沒有，無關電腦底層知識語言的人) 一個方便的權宜作法吧！ 目的是為了配合它們的智商 (以這種智商來寫程式其實是很驚險的，不知道語言開發單位，為何要墮落至此) 現在連動態型別是優，靜態型別是缺點，這種說法都出來了 人有多大膽、地有多大產，說不定以後連牛頓定律都可以超越了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.32.249.24 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1606096237.A.C5C.html
噓
11/23 10:15, 3年前 , 1F
笑死，動態型別用最兇的是蛇蛇跟Js吧
11/23 10:15, 1F
蛇蛇是啥？
→
11/23 10:15, 3年前 , 2F
Java是到jdk後面幾個版本才支援動態好嗎？
11/23 10:15, 2F
噓
11/23 10:17, 3年前 , 3F
java 哪裡支援動態...java var 那只是語法糖，但實際上完
11/23 10:17, 3F
→
11/23 10:17, 3年前 , 4F
全是靜態好嗎
11/23 10:17, 4F
→
11/23 10:24, 3年前 , 5F
很多人吃這個語法糖吃得很開心，認為是進步的象徵，笑死
11/23 10:24, 5F
噓
11/23 11:11, 3年前 , 6F
牛頓早就被超越了
11/23 11:11, 6F
→
11/23 11:11, 3年前 , 7F
蛇 => python
11/23 11:11, 7F
謝~
噓
11/23 11:20, 3年前 , 8F
好啦我先
11/23 11:20, 8F
推
11/23 11:23, 3年前 , 9F
上半部講的很關鍵, 下半部又嗆, 只能推了 XDD
11/23 11:23, 9F
推
11/23 12:31, 3年前 , 10F
戰啦
11/23 12:31, 10F
噓
11/23 13:32, 3年前 , 11F
下一篇 為了配合你們智商才發明出自然程式語言 不然我們都
11/23 13:32, 11F
→
11/23 13:32, 3年前 , 12F
寫組語長大的
11/23 13:32, 12F
→
11/23 13:33, 3年前 , 13F
下下一篇 配合你們才出組語 我們都直接看機器碼
11/23 13:33, 13F
→
11/23 13:35, 3年前 , 14F
喔對阿 設計螺絲釘的比建築師的智商還高
11/23 13:35, 14F
艱苦人 你又來了 太久沒被修理 皮又在癢了
→
11/23 14:40, 3年前 , 15F
癢喔 來幫我抓抓
11/23 14:40, 15F
→
11/23 20:26, 3年前 , 16F
java的var是type inference 不是 dynamically-typed
11/23 20:26, 16F
→
11/23 20:27, 3年前 , 17F
動態靜態本來就各有所長戰這個很無聊
11/23 20:27, 17F
→
11/23 21:52, 3年前 , 18F
看到中間就笑了 誰支援一下工程師鄙視鍊
11/23 21:52, 18F
噓
11/24 00:39, 3年前 , 19F
牛頓定律早就被認為是過時了吧
11/24 00:39, 19F
→
11/24 07:12, 3年前 , 20F
以認知來講 型別並不會讓你更容易看的懂 命名才是
11/24 07:12, 20F
→
11/24 07:13, 3年前 , 21F
offer的舉例就兩件事情 怎麼會那些判斷因素與型別可
11/24 07:13, 21F
→
11/24 07:13, 3年前 , 22F
以類比呢
11/24 07:13, 22F
這是認知科學中，一個兩觀的問題 人對於事物的認知，通常可以有兩種層次，兩種觀點：構造觀、功能觀 例如： 衣服是布料做的(構造觀)，衣服可以用來保暖、修飾(功能觀) 車子有四個輪子(構造觀)，車子可以代步，幫忙交通(功能觀) 在程式設計的領域中，命名通常代表了對參數的功能觀(功能認知) 而參數的型別，則代表了對參數的構造觀(構造認知) 這兩觀互相獨立，互不干擾，兩觀的認知都有，代表你對它的了解很透徹 只有功能觀，有時候夠用，有時候不夠用 例如，呼叫Library，函式的命名可以讓你知道函式的功能抽象 (要達到這個目的，前提是命名要很精準扼要，爛命名就不行了) (如果函式的功能太過混雜，那麼命名要做到精準扼要，其實也不太可能) (所以系統架構組織設計很重要，函式功能分割規劃很重要) (低耦合性、高內聚性很重要，越扯越多...etc. 說不完) 對於一個函式的使用者而言，通常只要知道函式的功能抽象，就足夠了 但是對於函式的實作者來說，功能觀只是基本的出發點 他還必須對函式的構造(構造觀)，有一定的了解，才可實作函式 對於參數的操作，也是一樣的道理，參數的命名通常代表了參數在系統中的功能角色 好的參數命名可以讓我們從命名知道，這個參數是在做什麼的 但卻無法讓我們知道參數所占記憶體的大小，數值的上下限，系統對數值的處理方式等 基本的參數特性資訊 如果要處理是類似資料結構，記憶體配置等，這種底層基礎的操作， 那麼光是掌握到命名(功能觀)，其實是不太夠的
推
11/24 10:30, 3年前 , 23F
如果你有 first class types，你就會學到“構造”（types
11/24 10:30, 23F
→
11/24 10:30, 3年前 , 24F
）和“功能”（calc）是等價的，在本質上沒有區別
11/24 10:30, 24F
→
11/24 10:30, 3年前 , 25F
只是一般的語言強迫把它們斷裂成 type 和實作兩個東西，
11/24 10:30, 25F
→
11/24 10:30, 3年前 , 26F
規定某些地方只能寫 type，其他地方只能寫 value 而已
11/24 10:30, 26F
推
11/24 10:36, 3年前 , 27F
不懂在吵為什麼要 typecheck 的人怎麼不去吵為什麼需要編
11/24 10:36, 27F
→
11/24 10:36, 3年前 , 28F
譯器或直譯器
11/24 10:36, 28F
→
11/24 10:36, 3年前 , 29F
要證明你的 type 是正確的就是 typecheck，要證明你的實
11/24 10:36, 29F
→
11/24 10:36, 3年前 , 30F
作是正確的，就是看能不能編譯成執行檔（編譯式），或是
11/24 10:36, 30F
→
11/24 10:36, 3年前 , 31F
能不能跑起來（直譯式）啊
11/24 10:36, 31F
個人是非常不喜歡匿名函數的玩法 匿名函數完全以「實作」來作為操作的標的， 與用「函數名稱」來操作比起來，它既沒有抽象，也沒有辨識認知上的簡化 對於認知的操作來說，會非常的辛苦，而且沒有效率 例如，我在想：如果要將這句話：「把『車子』開過來」以匿名函數的方式來表達 也就是用車子的「構造描述」來代替「車子的命名」來操作 這句話將會變成什麼模樣 這種玩法，基本上是違反認知科學的效益原則的 有人玩得很高興，不知道他們的腦袋在想什麼
推
11/24 12:31, 3年前 , 32F
如果你是在跟人講話，用你的方式可能比較好，但是你的程
11/24 12:31, 32F
→
11/24 12:31, 3年前 , 33F
式要拿來跑的，不是拿來讓電腦“認知”的，每個東西是怎
11/24 12:31, 33F
→
11/24 12:31, 3年前 , 34F
麼被構造的、怎麼被推導的就該被講清楚，和認知科學一點
11/24 12:31, 34F
→
11/24 12:31, 3年前 , 35F
關係也沒有
11/24 12:31, 35F
人在讀寫程式的時候，就是人跟程式在講話，這個環節太重要了，怎麼可以忽略 程式語言的發明，是為人而生，還是為電腦而生 對於電腦來說，機器語言就夠了 程式語言在開發的時候，本來就要考慮人的認知習慣，怎麼會跟認知科學沒有關係 程式語言的世界中，奇門遁甲的東西太多了，有些東西的確為人類帶來了方便 也有些東西，我一直在懷疑是不是專門發明用來整人的
噓
11/24 13:46, 3年前 , 36F
那請問你 λx. x+1 這個函數你要取什麼名字 = =
11/24 13:46, 36F
→
11/24 13:46, 3年前 , 37F
你有 100 個地方需要這種小運算需要 delegate 的你就要
11/24 13:46, 37F
→
11/24 13:46, 3年前 , 38F
用 100 種名字宣告 100 個函數？
11/24 13:46, 38F
這個問題太簡單太低級了 如果是重複性高的小運算，用巨集就可以了 如果是重複性不高的小運算，通常就沒有切割包裝成函式或巨集的效益性
→
11/24 13:46, 3年前 , 39F
然後函數取對名子電腦就知道要怎麼跑了？
11/24 13:46, 39F
重點在人的認知習慣，不在電腦，沒有認真看本文齁
噓
11/24 13:47, 3年前 , 40F
喔喔原來是 csfgsj，不小心和你認真了
11/24 13:47, 40F
奇摩子不爽了，為何不能理性討論呢？
→
11/25 11:10, 3年前 , 41F
扯智商的在跟人家講理性討論 笑死
11/25 11:10, 41F
艱苦人每天都在吸笑氣，笑了那麼久，到底死了沒有
→
11/25 18:43, 3年前 , 42F
你構造內還是得看命名阿 基本型別你不看命名有什麼快
11/25 18:43, 42F
→
11/25 18:44, 3年前 , 43F
速的認知 已經結網成功能怎麼會變成一種單純的屬性
11/25 18:44, 43F
→
11/25 19:10, 3年前 , 44F
相近的功能(構造)以假亂真造成這社會的亂象
11/25 19:10, 44F
我沒有說死說一定要功能命名呀！ 當下物件的構造最能代表物件，當然就用構造命名 命名的來源可以是各式各樣的東西，如構造、功能、性質、外觀特徵等 重點是，對使用操作來說，那一個最具有代表性、辨識性，用起來最方便 以水管的管件來舉例，例如：彎頭、三通、大小頭 這些就是構造命名，並且從構造命名可以很輕易的推斷它們的作用及功能 但是像api這一類的東西，通常是以功能命名的方式比較適合 PS：熊熊想到念國中時，訓導處的管理組長，綽號叫「大龜頭」 這個綽號雖然不雅，但卻是一個很成功的命名，它來自被命名物件的外觀 只要說到大龜頭，大家都知道說在誰，這個綽號流傳一屆又一屆，全校都知道 ※ 編輯: csfgsj (218.32.249.24 臺灣), 11/26/2020 09:51:02
→
11/28 07:19, 3年前 , 45F
我說的是命名重要的多 如果你認為構造功能是種型別
11/28 07:19, 45F
→
11/28 07:20, 3年前 , 46F
那物件很適合你 我認為的是開發方面物件不是都是優點
11/28 07:20, 46F
→
11/28 07:20, 3年前 , 47F
有基本的就可以了 其他看函式
11/28 07:20, 47F
‣ 更多 csfgsj 的文章
文章代碼(AID): #1VknLjnS (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 6 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 csfgsj 的文章
文章代碼(AID): #1VknLjnS (Soft_Job)