語境 (context) 的問題
不管是程式設計或是生活之中，都常常要處理『語境』(context) 的問題。語境很微妙，但是處理不好的話，就會造成錯誤。
前些日子，我在乳齒象 (Mastodon) 上看到了某位去日本工作的工程師寫到
日本文化好像不太習慣溝通，都會預期你應該知道某些規矩，或是文件寫了就算數。且特別喜歡遵循規則，以致於生活中充滿各種只有一種功能的特殊工具，及流程中不知道原因的奇妙步驟。
我回了他
"不太習慣溝通，都會預期你應該知道某些規矩，或是文件寫了就算數" 這類的事情，在這本書「文化地圖」的說法，叫做 high context culture。
由於象友請我多舉一些例子來談… 嗯，那就來談談什麼是 context 吧。
先舉例解釋 context，比方說，「建國」兩個字，一旦參考了 context 之後，得到的意思很可能是幾種不一樣的結果。「建國」一詞在民進黨黨綱的語境裡、與國民黨黨歌的語境裡，就是不同的意思。在這邊例子裡，「建國」一詞是人講出的話，它是 content 的部分，而講這個話語的背景，就是 context 的部分。
人類的溝通很少是 context-free 的，因為如果使用 context-free 的語彙，通常只有專家看得懂。比方說，生物學的拉丁文學名，就真的只有一種語意，不隨語境而改變。
在軟體開發時，如果你用 json 格式來傳遞時間，表示時間使用了 ISO 8601 格式，且沒有加上時區。於是時區的部分就變成了 context ，要看接收端的程式開發者有沒有正確地引用 context 。如果沒有參考文件，又或是懶得讀參考文件，接收端的程式開發者很可能會使用 UTC 時區又或者使用當地時區來做為 context，於是就有可能產生兩種不同的結果。為了避免這種引用 context 可能造成的錯誤，就會有人考慮直接使用 timestamp 來當格式，至少它是 context-free ，於是又付出了人眼無法直接閱讀時間的設計代價。
根據文化地圖一書的說法：
如果一個地方的人，是一群人長久待在一起，比方說，農耕民族，所以共有許多知識與習俗。溝通的模式會走向 high-context ，因為省事。
另一方面，如果某民族是游牧民族，常常要四處走動，要跟各種不同背景的人溝通，溝通的模式走向 low-context 就是必需的。
最後，嚴格地來講，專業領域的語境 (context) 問題，往往簡單得多，因為通常早就有前人解過這類問題了，他們早就設計好了專業術語，往往是 context-free 的，就像生物學的拉丁文命名法一樣。
像前述在 json 裡傳遞時間的問題，也已經有了理想的解決方案：『使用 EDN 格式來取代 json 即可。』EDN 格式可以讓你自行定義擴充型別，此外，比較常用的擴充型別 time 與 UUID ，已經幫你先定好了。
生活或是翻譯之中會遇到的語境問題，我覺得這就相對困難得多。比方說，Peter Drucker 曾寫過一句 "Customer is Business"，如果沒有讀過別人的翻譯，我一輩子也想不出來，這句要翻譯成『客戶至上』。