Re: [討論] 請大家聊聊靜態語言的缺點
借題發揮一下:static typed for the win
不過還是先切題回答「靜態語言的缺點」:
在大部分常用的靜態語言中,的確可能出現 valid program 不好標注 type 的情況
不過到底有多難標注就完全看是哪個語言跟哪個版本了
-----
個人有碰過的語言依據學習順序大概是這樣
C -> Java -> Python/Ruby/JS/ObjC -> Scala/Kotlin -> Haskell/Idris
(差不多時期學的用斜線表示)
我對這個問題的偏好也從「靜態」轉「動態」再轉回「靜態」
下面大概聊一下我在學習不同語言的時候的感想
-----
##「靜態」轉「動態」
- Java -> Python,覺得 Python 好方便,不用寫長長的 main,且不用宣告變數型態。
## 在各種常見動態語言中遊蕩(?
- 學了 Ruby 後覺得 map/filter 等等使用 block 的函數實在太方便了。而 Python
相對應的答案是 list comprehension。當時不明白明明可以用 Library 解決的問題, 為什麼要使用另外的語法,後來學了 Haskell 才完全了解這東西應該怎麼用,
不過這是另外一個話題。
- 學了 JS 後覺得 Ruby block 語法比較沒有一致性,在 JS 全部用 anonymous
function 就解決了。也大概在這個時間點了解所謂 first order function
是怎麼一回事。
因為差不多在這個時期同時有在接 Android/iOS 專案,所以 Java/ObjC 碰得不少。
ObjC 雖然有 lambda ,但語法異常複雜以至於有這個網站
http://fuckingblocksyntax.com/
而當時 Java 才剛開始有 lambda solution,必須要靠 compiler plugin 才能支援,
但還是 desugar 成 class Function<T, R>,所以在 Java-like lang 寫 lambda
要標註 function type 實在醜,所以在這個時期最喜歡的是支援動態型別、
first order functions 的語言 JS。
## 「動態」轉「靜態」
不過上述問題在 scala/kotlin 等新興語言都有改善。以下是不同語言的 map function
比較:
- Java 8: List<R> map(Function<T, R> f)
- Scala: def map[B](f: (A) => B): List[B]
- Kotlin: fun <R> map(f: (T) -> R): List<R>
- Haskell: map :: (a -> b) -> [a] -> [b]
基本上大部分的情境中 function type annotation 現在應該都不是什麼大問題
當然 OO Lang 還要考慮繼承,所以還有 variance 的問題(不過在這邊就先忽略不談
## Type Annotation 很花時間是指?
Type inference 現在應該都是基本了,所以宣告變數需要重複寫 type 應該已經不是
個問題了。其他常被提到的則跟 sum type/product type 有關。
Product type 基本上就是一個 class 有多個 value members。但 Sum type 大家可能就
比較不熟悉。
舉例來說,一個 function 他需要同時支援 type A 跟 type B 作為唯一的 argument
基本上我知道的語言中,大概有三種方式:
1. 讓 A, B 實作同一個 interface/super class
2. Union Type, typescript/flowtype: type AorB = A | B
3. Tagged Union Type, Haskell: data AorB = A A | B B
其中 scala/kotlin 屬於 1. 但不像 Java 一樣宣告起來麻煩:
sealed abstract class Base
case class A() extends Base
case class B() extends Base
當然還是比 Haskell 的一行多了一些。而 TypeScript 更可以 inline 宣告。
到這邊為止,大部分的語言應該在九成五的 case 都不需要太多成本就能 cover 了。
## Haskell/Idris
當然還是有某些狀況下,type 很難被正確 annotate,例如如果 input 小於某個數字,
就回傳 String 否則回傳 Int。雖然可以用上面提到的 sum type,但是如果我們確定
input 一定大於指定數字,所以不想要處理 String 作為 output 的話,那就要用到
dependent type 了。
而如果使用有 dependent type 的語言,絕大多數的 program 都可以被 annotate
不過問題是:
1. 學習門檻高,大部分的基礎程式課程連 generic 都不會講,更不用講 DT
2. 大部分的語言不支援 DT
## 結論
靜態語言跟動態語言只是一個非常粗略的分法,其中可以討論的面向從純技術層面
到團隊營運跟產品性質都有關係。如果可以在討論的時候舉一些例子會比較有趣 :D
不過一般來說我還是覺得靜態語言比較好一些。
--
typecheck 對於成功 type checked 的程式碼的關係就相當
於 compile 對於成功編譯出來的執行檔的關係一樣
計算和類型本來就是等價的,不知道為什麼有很多人在討論
靜態型別的優缺點,但都沒看到有人在講編譯式語言的優缺
點
強型別對程式碼的好處不就像是編譯式對程式的好處一樣嗎
?
理想上同意,但實務上可能會有一些詭異的狀況
推
7
就是囉嗦開發時間長而已 其他就沒什麼缺點了 所以說看情形去使用語言 要做個穩定的大專案還是靜態語言妥當 我只是寫個一次性的自動化腳本X
這個問題實在是匪夷所思 以認知科學的觀點看,當然是靜態型別優於動態型別呀! 就像offer文在討論薪水,在那邊 N 來 N 去 在許多重要性質不確定的情況下,很多東西是很難精確的下判斷的 不過如果貴圈的專注層次不在這裡,不在乎,那也就無所謂1
寫MCU的話,看來看去只能用靜態的語言 因為記憶體真的是小不拉基的(了不起10K給你使用),能用記憶體時都要斤斤計較, 一些常見的資料結構使用時要非常非常的小心,像是Linked list之類的 一不小心,記憶體沒有回收,就可能造成死當的情況發生 一些型態沒有宣告就使用的話,那可能真的會造成MCU的災難9
問靜態和動態有缺點。怎麼不想想你公司是怎樣型態 如果你們公司成員 新舊和程度不一樣 就需要靜態語言處理程式,強制要成員遵守並規範。只要規範好,一般猴子也會按照著寫程 式。 動態語言吃的是開發人員素質,要自律,要對程式碼負責。18
首Po繼上個系列串 我想問問大家認為靜態型別的缺點是什麼呢? 本人寫Java也寫JS,最近也在碰Python 我自己寫Java,一開始覺得宣告比較麻煩,需要思考這個變數是什麼型別 (其實說實在,Java的變數最常使用也就幾個,我正常刷Leetcode除非特殊情況否則很少會想不出要用什麼型別的變數)
17
[問卦] Python怎麼那麼難懂啊?variable type 不清楚,幹這數字到底是float還是int? function return type 也沒標記 function argument type 不知道是啥 oop語法有夠難懂 每次看python 的code都好痛苦17
Re: [討論] 請大家聊聊 JavaScript的缺陷我想 auto complete 可以算是開發工具的部分 (我猜任何語言理論上都可以有 auto complete,所以和語言本身無關) 而且在這篇沒看到原原 Po 提到,暫不討論 : 而且我還是那句話, 你今天碰到 ts 世界以外的模組, : 你是要怎麼 autocomplete 跟省時間.13
[請益] Database String Array Type各位大大好 小弟是一間小公司裡 負責部分核心業務的軟體工程師 為了日益多樣的客群,被安排要規劃新的設計 程式語言使用的是Java,資料庫是Postgres8
Re: [討論] 請大家聊聊 JavaScript的缺陷不太認同, 如果今天的task是計算1加到10000 從紙上開始 1 + 2 + 3...一直算到10000可以解決問題 用等差數列的公式也可以解決問題 寫段code直接寫個function讓function可以支援不同的min, max也同樣能解決問題 這些方法都能解決問題?難道他們都是好方法嗎?2
Re: [討論] 請大家聊聊 JavaScript的缺陷project scan 就是需要時間, 你檔案數多到一個程度, 就是慢. webpack 有那麼多 tooltip 再加速效能, 難道是假的. 說真的, 這段話反過來說也是可以還給你的. 連自己的 type 跟 convention 都掌握不好的, 是有什麼好靠邀的. 另外 js 的 autocomplete,3
Re: [請益] 比物件導向更先進的程式設計思想?喜歡換一個思考模式嗎?歡迎進入 FP 1. compose 是 FP 語言中的基石 (O) 2. stateless FP 語言原則上沒變數概念,等號兩邊是等價的 (O) 3. 可驗證/高度抽象化,FP 的 type system 往往比 oo 系列的表達力更強 (O) ---