聊聊學習編程語言

學習編程需要什麼前提條件

數學和編程的關係

import math
# 使用勾股定理
a = 3
b = 4



     




c = math.pow(a*a + b*b, 1/2)
print('勾', a, '股', b, '弦', c)

語文和編程的關係

常見的判斷流程代碼

英語和編程的關係

經濟條件和編程的關係

C 語言為什麼使用如此廣泛

操作系統的原生語言

在 Linux 上 man epoll

3L 和 ABI 規範

#include <stdio.h>
int main()
{
   printf("Hello, World!");
   return 0;
}

$ ldd a.out
        linux-vdso.so.1 (0x00007ffc4bfb0000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6b48f24000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6b48c20000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6b48a09000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b4866a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6b494ab000)

數學符號關鍵字

1. 最臭名昭著的數學符號誤解，就是=號。在 C 語言中，這個符號實際上對內存的讀取和寫入操作，但在數學上這是一個“相等”的聲明。這導致了大量的因為 if (foo = bar) 的 BUG 誕生。PASCAL 語言用 := 作為賦值符號，可以說是對這種錯誤的一個糾正。
2. * 號，同時具備“乘法”“聲明指針”“解引用”三個含義，具體是什麼意思，取決於這個符號寫在什麼地方。這也是 C 語言代碼閱讀和學習比較困難的一個原因。

#include <stdio.h>
 
int main ()
{
   int  var = 20;   
   int  *ip;   /* 指針變量的聲明，這裡的星號表示聲明的是一個指針 */
   ip = &var;  


     




/* 等號表示賦值，把 var 的地址寫入 ip 變量的內存中 */
 
   /* 使用指針訪問值，這裡的星號表示“解引用操作符”，即讀取指針指向的內存塊內容 */
   printf("*ip 變量的值: %d\n", *ip );
   return 0;
}

1. 在數學上，函數可以理解為對某種規律的描述：你可以輸入自變量，獲得返回值。然而，我們往往把“函數”當成一個功能處理過程去編寫，這就導致了“就算相同的輸入，也不會有相同的輸出”的“函數”的出現。我們表面上好像是用函數在計算一些結果，實際上是利用這些函數的“副作用”去完成一些功能。這種表達和實際的差異，也是造成大量 BUG 的原因。
2. 由於變量對應著內存，所以代碼中的變量，並不能單純的認為是一個數值的容器。譬如在 C 語言中，你如果返回了一個局部變量的指針，這個指針指向的變量內容，很可能在下次使用時，被不知道什麼數據所覆蓋。所以使用 C 語言必須要理解所謂“堆”和“（堆）棧”的差別。如果你認為局部變量不好用而使用“堆”裡的變量，那麼就必須注意自己進行內存的回收釋放，否則就又掉進了“內存洩漏”的坑裡。
3. C 語言中的變量，雖然有各種類型，但實際上編譯器幾乎不會自動的對其進行什麼操作，於是不管是什麼類型，其實都代表的一塊內存而已。類型不同僅僅是代表不同長度的內存塊。而在不同編譯器和不同操作系統下，同樣的類型對應的長度還不一樣，這就更增加了這門語言的複雜性。譬如 32 位系統下的 long int 是 4 個字節，64 位系統下則是 8 個字節。本來這種長度差異不太應該影響程序員編碼，但很多 C 的庫又設計成使用 指針+長度 的方式來傳參，所以變量長度變得不得不關心了。同樣的問題還有結構體的字節對齊問題。

自帶內存管理的語言們

內存為什麼需要管理

Java：你媽覺得你冷

CLASSPATH

內存管理

• 基礎類型變量，譬如 int/boolean 這些（注意 String 並不是基礎類型），永遠都是值傳遞，你也沒法關心是在堆上還是棧上。
• 對象類型變量，所有的 Object 的子類和數組這些，永遠都是引用傳遞（類似指針），所以肯定是在堆上。
• 如果你硬是想弄一個基礎類型的數據容器，譬如存放 int 類型的“對象”，那麼你需要進行“裝箱”這種儀式，幸好新的 JDK 已經從語言層面支持了。

異常機制

FileInputStream in;
try {
  in = new FileInputStream(file);  // 正常流程就這兩行
  in.read(filecontent);
} catch (FileNotFoundException e) {
  e.printStackTrace();
} catch (IOException e) {
  e.printStackTrace();
} finally {
  try{
    in.close();
  } catch (IOExeption e) {
    e.printStackTrace();
  }
}

1. NullPointerException 這個異常是由於你調用了一個內容為 null 的對象的方法或者屬性。由於 null 這個值非常特殊，它可以被賦值給任何類型的對象，所以很難被簡單的發現。什麼情況下，一個 Object 變量被賦值為 null 呢？很可能是在調用一個 HashMap 的 get() 方法後，沒有判斷返回是 null 導致的。有一些 API 調用會返回 null，這個是非常需要注意的。
2. ConcurrentModifyException 如果有兩個以上的線程，在同時操作一個容器變量，就可能會出現。譬如一個線程正在用迭代器遍歷，另外一個線程在插入元素。大多數情況下解決方法也比較簡單，就是用 synchronized 關鍵字來“鎖”住這個容器變量就可以了。當然如果迭代器遍歷循環代碼裡，又調用到另外一個容器的方法，那麼就有可能發生“死鎖”。當然也可以用一些支持併發的容器，來解決可能的併發修改問題，Java 提供了一整套“併發”所需的庫（ java.concurrentcy.* ），包括各種形式的鎖、線程安全容器等。

併發支持

C#：我全都要

• Java 不是沒有值拷貝的變量類型嗎？C# 有，叫 struct
• Java 反對使用“輸出參數”，C++ 使用輸出參數很普遍，C# 都有，既可以返回一個對象而沒有心理負擔，也可以用 out/ref 關鍵字做輸出參數。
• 異常處理 try-catch，C# 也有，但不會像 Java 一樣強迫你處理
• RTTI、反射，C# 全有
• Java 的 Annotation，C# 叫 Atrribute
• Interface Java 有，C++ 沒有，C# 還是有，而且比 Java 的更徹底：要訪問一個接口的方法，只能通過接口類型的變量訪問，通過真實實現類型的變量是無法通過編譯的。
• JavaBean 苦口婆心推廣 Setter/Getter 的寫法，C# 直接用語言實現掉，就是 Property 特性。
• C++ 可以重載運算符，Java 不可以，所以 C# 也可以自定義+ - * /運算符

Go：專門為服務器端設計的語言

• 所有的源碼編譯出來就是一個二進制，全部都是靜態鏈接。（在服務器上一般只運行這個程序，也不需要動態更新或者和其他程序共用動態庫啥的）
• 包依賴功能自動和 git 綁定，你不喜歡用 git 也不行。（客戶端開發，特別是遊戲客戶端開發，工程裡面包含太多二進制文件，用 git 會特別的慢，所以你別用 Go 寫客戶端吧。）
• 沒有什麼引用傳遞，全是值傳遞，如果不想複製一個巨大的數據塊，就用指針。這個指針不能像 C 語言一樣進行數學運算 ++ --，但還是要叫“指針”，而不是換成什麼別的名字遮掩一下。
• 局部變量返回之後，就變成了堆上的變量，所以也可以垃圾回收了。（不需要手工指定使用堆還是堆棧，就算你用new()指定了，可能也是白忙活）
• 自帶併發“協程”，但又不是異步的，一樣需要你把容器類型變量鎖起來，或者你用線程安全的容器，用起來和多線程幾乎一樣。
• 把 select、chan 這種東西直接弄到語言裡面，儘管這功能完全可以用庫的方式提供，但 Go 就是要讓你膜拜一下。
• 沒有 try-catch-finally 捕捉異常這種玩意，只有 defer 關鍵字，你就是要用 finally 的寫法去幹捕捉異常的事情。
• 用註釋來生成文檔有什麼特別的，看我用註釋來寫程序：go 源碼的註釋可以寫一段 C 語言代碼並且調用！

package main

/*
#include <stdio.h>
void c_print(char* str) {
  printf("%s\n", str);
}
*/
import "C"

func main() {
  s := "hello C"
  cs := C.CString(s)
  C.c_print(cs)
}

面嚮對象語言是一個騙局嗎？

OO 三特性

• 封裝：歷來就有“失血模型”和“充血模型”的爭議。在 WEB 開發領域，由於存在大量的數據庫 CRUD 操作，所以不管你的類有什麼屬性，大多數都是那麼幾個方法，所以把方法和屬性封到一塊，看起來沒啥必要，反而增加了大堆類似而重複的代碼。
• 繼承：繼承會破壞封裝，讓父類的行為被改變，所以不要繼承！用組合來代替繼承！多繼承是邪惡的，所以只能單繼承，如果你需要一個對象同時可以是幾個不同的“類型”，那麼你只能為這些類型每個都定義一個“接口”，增加一大堆代碼。如果“繼承樹”一開始設計的不合理，極有可能需要修改“樹幹中”的某一個節點，也就是某個基類，導致下游一大堆的子類被迫要修改。
• 多態：這個特性是爭論最小的特性，但是也有人覺得，其實就是一種 switch case 嘛，最高級的程序員（食材）往往只需要最簡單的語法（做法）……

類爆炸、構造器混亂和“基於對象”

某種語言的對象構造順序

C++ 到底是什麼？

並不是 C 語言

class Parent {
public:
    int iparent;
    Parent ():iparent (10) {}
    virtual void f() { cout << " Parent::f()" << endl; }
    virtual void g() { cout << " Parent::g()" << endl; }
    virtual void h() { cout << " Parent::h()" << endl; }

};

class Child : public Parent {
public:
    int ichild;
    Child():ichild(100) {}
    virtual void f() { cout << "Child::f()" << endl; }
    virtual void g_child() { cout << "Child::g_child()" << endl; }
    virtual void h_child() { cout << "Child::h_child()" << endl; }
};

class GrandChild : public Child{
public:
    int igrandchild;
    GrandChild():igrandchild(1000) {}
    virtual void f() { cout << "GrandChild::f()" << endl; }
    virtual void g_child() { cout << "GrandChild::g_child()" << endl; }
    virtual void h_grandchild() { cout << "GrandChild::h_grandchild()" << endl; }
};

上面代碼一個 GrandChild 對象的內存結構

動態綁定：把指針玩出花兒來

Parent *obj = new Child()

靜態綁定：真正的架構師語言

1. 不需要實現 interface，只要“語言簽名”對的上，都能直接用
2. 編譯時會檢查出所有的錯誤
3. 通過使用泛型類的繼承，可以實現對方法調用的“反射”

template <typename T>
void const& DoSomething (T const& a) 
{ 
    a.DoSomething();
} 

編程語言分類學

編譯、虛擬機、腳本

• 編譯型語言具有最好的效率，也是歷史最悠久的語言類型。C 語言就是這類語言的代表。編譯型語言在環境兼容和內存管理方面，往往不盡如人意，但是還是有很多後續的編譯型語言在這方面做了長足的改進，譬如 Go 語言。作為環境兼容性“差”的另外一面，編譯型語言生成的程序，在已經兼容的環境中，部署方面往往會比較簡單，譬如用 Delphi（Object Pascal） 寫的 GUI 程序，編譯之後只有一個可執行 exe 文件，拷貝到目標機器上就能運行。
• 在“虛擬機”下運行的語言，往往都具有非常豐富的運行時動態特性，譬如 JAVA 和 C#，反射功能只是一個最基本的操作，它們還可以運行時更新代碼，甚至可以支持很多不同的語言在同一個虛擬機上跑（如 Jython 就是用 Python 語言跑在 JAVA 虛擬機上）。比較有趣的是，幾乎所有這類的語言，都號稱要“跨操作系統”。事實上它們也基本上都做到了這點，但是真正用於編寫 PC 或者服務器的跨操作系統的項目非常少，反而在手機、遊戲領域，JAVA（安卓） 和 C#（Unity） 這些語言卻應用非常廣泛。最後說說性能，在 JIT（Just In Time）技術的加持下，很多虛擬機字節碼，實際上擁有了和編譯語言一樣的基礎性能，而那些無法 JIT 的代碼，往往是編譯型語言不支持的一些動態特性。所以除了部署安裝這類語言編寫的軟件，需要額外按照個環境（JRE/.NET）以外，使用起來沒有什麼實質上的差異。
• 腳本語言的歷史其實一點也不比其他語言更短，儘管它們被認為是最容易學習，但性能最差的一批。這類語言的一般都具有所謂的“動態類型”特性，也就是你可以不理睬變量的類型，直接把變量思維萬能的信息盒子。甚至一些常用的數據結構，也被一種很容易使用的方式嵌入在語言中，譬如世界上最好的語言 PHP 就可以使用其萬能的[ ]中括號——它既可以是數組，又可以是列表，還可以是哈希表。腳本徵服“跨操作系統”難題，採用的另外一種方法：讓自己的源碼變得方便移植。其實這個方法，C 語言很早就嘗試過，所謂的 ANSI C，就是明白無法讓 C 語言編譯出來的程序在任何環境運行，那就讓 C 語言的源碼變得可以在任何環境編譯吧，雖然這個嘗試現在來看不是太成功，因為我們使用 C 語言的一個重要理由，就是用來對操作系統進行控制，不同的操作系統提供的 API 本身就差異很大。腳本類語言只需要在不同的操作系統上，實現一遍自己的解析器，就可以成為所謂的跨操作系統了。其中一些語言（譬如 Python），還會連帶把自己的常用庫也移植到不同的操作系統上，而另外一些語言，壓根就沒有什麼庫，它的設計目的就是“寄生”（嵌入）到其他語言編寫的程序中（如 Lua），所有需要移植的“庫”，都是被嵌入的那種語言自己需要解決的問題。

1. 人是第一要素：也就是這個項目的開發人員，最適合用哪種語言。一般來說腳本語言的開發速度是最快的，如果是複雜多變的需求，首選腳本語言。
2. 運行環境的依賴因素：如果要開發一個“跨語言”可用的庫，C 語言幾乎是唯一的選擇；如果要開發一款遊戲，希望運行在不同的平臺上，使用帶虛擬機的語言，或者是某種腳本語言，譬如 TypeScript 可能是一個好的選擇，很多遊戲引擎、框架本身也會選擇這一類語言。如果開發的程序可預見的，和某些環境依賴非常密切，那麼就不要自找麻煩，直接選擇環境相關的“官方語言”。
3. 性能幾乎是最後的一個考慮要素，除非有非常明確的性能測試結果，不要輕易用這個標準來選擇語言。

通用型和專用型

select name, age, address from User where name = 'Tom';

編程語言的理解思路：用什麼手段，解決了什麼問題

提高開發效率

跨平臺

安全性

和遊戲有什麼關係呢？

為什麼是 C++ ？

為什麼不是 C++ ？

Talk is cheap, show me the code