DEV Community: Gophernment

Aider: AI pair programming ใน terminal — เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

Gophernment — Sat, 29 Aug 2026 01:25:14 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | Aider 0.86.x, Claude Code 2.1.x, OpenAI Codex 0.150.x
⚠️ API/เวอร์ชันอาจเปลี่ยนแปลง — ตรวจสอบเอกสารล่าสุดก่อนใช้งาน

ถ้าคุณใช้ AI ช่วยเขียนโค้ดอยู่ตอนนี้ โฟลว์ของหลายคน (รวมถึงผมก่อนหน้านี้) คือเปิดเว็บแชตของ Claude หรือ GPT แล้วก็... ก๊อปโค้ดจาก editor แปะไป ถามว่า "ช่วยแก้บั๊กนี้หน่อย" รอคำตอบ แล้วก็ก๊อปโค้ดกลับมาแปะใน editor วนไปวนมา

โค้ดยาว ๆ แค่ไฟล์เดียว บางทีต้องก๊อปแปะเป็นสิบรอบ แถม AI ยังไม่เห็น context ของทั้งโปรเจกต์ มันเลยเดาเอาเองว่าไฟล์อื่น ๆ หน้าตาเป็นยังไง แล้วก็ให้โค้ดที่ไม่ตรงกับโค้ดจริงของเรามา

Aider เป็นหนึ่งในเครื่องมือที่แก้ปัญหานี้ — ให้ AI มา "จับคู่เขียนโค้ด" (pair programming) กับคุณใน terminal ตรง ๆ บทความนี้จะพาไปรู้จัก Aider แบบละเอียด แล้วปิดท้ายด้วยการเทียบหมัดต่อหมัดกับคู่แข่งสำคัญ 5 ตัว

Aider คืออะไร

Aider เป็นโปรแกรม command line ที่คุณเปิดในโฟลเดอร์โปรเจกต์ แล้วแชตกับ AI เพื่อสั่งให้มันแก้โค้ด ความต่างจากเว็บแชตคือ AI จะอ่านโค้ดจริงในเครื่องคุณ แก้ไฟล์จริง แล้วใช้ git commit การเปลี่ยนแปลงให้ด้วย message ที่สมเหตุสมผล

ตัวเลขที่ทางโปรเจกต์รายงานไว้: ดาวบน GitHub ราว 44,000 ดวง ติดตั้งไปแล้วกว่า 6.8 ล้านครั้ง ทำงานกับภาษาโปรแกรมได้มากกว่า 100 ภาษา (Python, JavaScript, Go, Rust, Ruby, PHP และอื่น ๆ)

เริ่มใช้งานง่าย ๆ

ติดตั้งแค่สองคำสั่ง ตัวแรกติดตั้ง installer แล้วตัวที่สองรันมันเพื่อ setup

python -m pip install aider-install
aider-install

ติดตั้งเสร็จ เข้าไปในโฟลเดอร์โปรเจกต์ แล้วเปิด Aider พร้อมระบุโมเดลกับคีย์ API

cd /to/your/project

# ใช้ DeepSeek
aider --model deepseek --api-key deepseek=<key>

# ใช้ Claude 3.7 Sonnet
aider --model sonnet --api-key anthropic=<key>

# ใช้ o3-mini
aider --model o3-mini --api-key openai=<key>

เปิดแล้วจะเข้าสู่หน้าจอแชตใน terminal พิมพ์สั่งงานภาษาไทยหรืออังกฤษก็ได้ เช่น "เพิ่มฟังก์ชัน validate email ในไฟล์นี้" แล้ว Aider จะแก้ไฟล์ให้ พร้อมโชว์ diff ของสิ่งที่เปลี่ยน

จุดเด่นของ Aider

หนึ่ง — เห็นทั้ง codebase Aider สร้าง "แผนที่" ของโปรเจกต์ทั้งก้อน ทำให้มันรู้ว่าไฟล์ไหนเรียกไฟล์ไหน จึงทำงานในโปรเจกต์ใหญ่ได้ดีกว่าการก๊อปโค้ดบางไฟล์ไปให้ AI เดา

สอง — git integration ทุกครั้งที่ Aider แก้โค้ด มันจะ commit ให้อัตโนมัติด้วย message ที่สมเหตุสมผล ใช้ git diff หรือ git log ตรวจย้อนได้เลย

สาม — เชื่อม LLM ได้เกือบทุกตัว จุดนี้คือสิ่งที่ทำให้ Aider ต่างจากคู่แข่งหลายตัว — มันไม่ผูกกับค่ายใดค่ายหนึ่ง ใช้ Claude, DeepSeek, OpenAI หรือแม้แต่ local model ผ่าน Ollama ก็ได้ เลือกเองตามงานและงบ

ข้อควรรู้ก่อนใช้จริง

ค่าใช้จ่าย — Aider เรียก LLM API โดยตรง ค่ายิง API ตกเป็นของคุณ (เลือกโมเดลให้เหมาะกับงาน)
ตรวจ diff ก่อนเสมอ — AI แก้โค้ดเก่งแต่ก็พลาดได้ ดู git diff ทุกครั้งก่อนปล่อยไป
เรื่อง privacy — ใช้โมเดล cloud โค้ดจะถูกส่งไปยังผู้ให้บริการนั้น ๆ ถ้ากังวลใช้ local model แทน

เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

ทีนี้มาดูภาพรวมตลาด — Aider อยู่ตรงไหนเมื่อเทียบกับตัวเด่น ๆ ทั้ง 5 ตัว

มิติ	Aider	Claude Code	OpenAI Codex	Cursor	GitHub Copilot	Cline
รูปแบบ	terminal CLI	terminal CLI	CLI + IDE + web	AI editor (VS Code fork)	IDE extension + CLI	SDK + extension + CLI
โอเพนซอร์ส	✅	❌	❌	❌	❌	✅
LLM	อิสระ (เกือบทุกตัว)	Claude เป็นหลัก	OpenAI เป็นหลัก	หลายค่าย	GPT + Claude	อิสระ (พกคีย์มาเอง)
Git commit	✅ อัตโนมัติ	✅	✅	✅ (ผ่าน editor)	✅	✅
ติดตั้ง	`pip install aider-install`	`npm i -g @anthropic-ai/claude-code`	`npm i -g @openai/codex`	โหลด app	ลง extension	marketplace / SDK
ราคา	ฟรี (จ่าย API เอง)	subscription / API	subscription / API	subscription	subscription	ฟรี (จ่าย API เอง)
เหมาะกับ	สาย terminal + อยากเลือก LLM เอง	สาย Claude ล้วน	สาย OpenAI ล้วน	อยากได้ editor ทั้งตัว	ใช้ editor เดิม เสริม AI	อยากปรับแต่งได้เต็มที่

อ่านตารางแล้วจะเห็นภาพชัด: จุดยืนของ Aider คือ "ตัวเดียวที่ทั้งโอเพนซอร์สและไม่ผูก LLM" ข้อดีคืออิสระและโปร่งใส ข้อเสียคือไม่มี editor UI สวย ๆ มาให้ (คุณต้องมี editor เอง) และต้อง setup คีย์ API เอง

เทียบแบบรวบรัด:

Claude Code — แรงและฉลาดมาก แต่ผูกกับ Claude และไม่โอเพนซอร์ส
OpenAI Codex — ระบบนิเวศ OpenAI แน่น แต่ก็ผูก OpenAI เช่นกัน
Cursor — ประสบการณ์ editor ดีที่สุด แต่เป็น closed source และเก็บค่าบริการรายเดือน
GitHub Copilot — ใช้กับ editor ที่มีอยู่แล้วสะดวก แต่จ่าย subscription และปรับแต่ง LLM ไม่ได้อิสระ
Cline — โอเพนซอร์สและยืดหยุ่นพอ ๆ กับ Aider แต่เป็น extension (ไม่ใช่ pure terminal) และพึ่งพา VS Code มากกว่า

เลือกยังไง

สาย terminal + อยากเลือก LLM เอง + ชอบโอเพนซอร์ส → Aider (หรือ Cline ถ้าอยากได้แบบมี UI ใน editor)
ใช้ Claude/OpenAI เจ้าเดียวอยู่แล้ว → Claude Code / Codex ตามค่ายที่ใช้
อยากได้ editor อัจฉริยะทั้งตัว → Cursor
ใช้ editor เดิม อยากเติม AI แบบไม่ต้องย้ายที่ → GitHub Copilot

ไม่มีตัวไหน "ดีที่สุด" แบบสัมบูรณ์ — มันขึ้นกับว่าโฟลว์ของคุณอยู่ที่ไหนอยู่แล้ว และยอมผูกกับค่ายไหนได้แค่ไหน

แหล่งอ้างอิง

Aider — https://aider.chat/
Aider Getting Started — https://aider.chat/#getting-started
Claude Code — https://www.anthropic.com/claude-code
OpenAI Codex — https://openai.com/codex
Cursor — https://cursor.com
GitHub Copilot — https://github.com/features/copilot
Cline — https://github.com/cline/cline

AI เขียน Go โบราณตลอด — JetBrains เลยทำ "กติกาการเขียน Go สมัยใหม่" ให้ agent แล้ว

Gophernment — Wed, 26 Aug 2026 05:52:28 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | ครอบคลุม Go 1.0–1.27
⚠️ ข้อมูลอัปเดต ณ วันที่เขียน — เวอร์ชัน/ฟีเจอร์อาจเปลี่ยนตามรอบ release ของ Go

ถ้าคุณเคยให้ AI coding agent เขียนโค้ด Go ให้ ลองสังเกตดูว่ามันเขียนออกมาเป็นยังไง ส่วนใหญ่แล้วมันจะเขียนแบบ "รุ่นพ่อ" ออกมา — ใช้ if a > b { return a } แทนที่จะใช้ max(a, b), เขียน loop หา element ทีละตัวแทน slices.Contains, หรือประกาศตัวแปรชั่วคราวเพื่อเอา pointer แทนที่จะใช้ new(...)

โค้ดแบบนี้รันได้นะ ไม่ผิดด้วย แต่มันไม่ใช่ Go แบบที่เราเขียนกันในปี 2026 แล้ว และนี่คือปัญหาที่ทีม JetBrains มองเห็น แล้วทำของชิ้นหนึ่งออกมาแก้ตรงจุด — ชื่อว่า go-modern-guidelines

ทำไม AI ถึงเขียน Go เก่า ทั้งที่ Go ออกฟีเจอร์ใหม่ตลอด

สาเหตุหลักมีสองอย่าง และมันซ้อนกันอยู่

อย่างแรก โมเดลภาษาเรียนรู้จากโค้ดบนโลก ซึ่งส่วนใหญ่เขียนขึ้นมาในช่วงหลายปีที่ผ่านมา โค้ด Go เก่า ๆ ที่วนอยู่ใน internet มหาศาลล้วนเป็นสไตล์ "ก่อนจะมีฟีเจอร์ใหม่" ทั้งนั้น โมเดลเลยจับ pattern แบบเก่ามาเป็น default

อย่างที่สอง Go ออกเวอร์ชันใหม่ทุก ๆ หกเดือน และแต่ละรอบก็มีของเล่นชิ้นเล็ก ๆ เข้ามาเรื่อย ๆ — min/max เข้ามาใน Go 1.21, for i := range n ใน Go 1.22, slices.Collect ใน 1.23, t.Context() ใน 1.24, errors.AsType ใน 1.26, และ encoding/json/v2 ใน 1.27 จังหวะมันไวกว่าที่โมเดลจะตามทัน

ผลลัพธ์คือ agent เขียนโค้ดที่ "ถูกแต่เชย" แล้วเราก็ต้องมาแก้ทีหลัง — ซึ่งก็คือสิ่งที่ Go team เองก็เห็นเหมือนกัน ถึงขั้นทำ analyzer ชื่อ modernize เอาไว้ auto-update โค้ดเก่าให้เป็น idiom ใหม่

แล้ว JetBrains แก้ยังไง

แทนที่จะรอให้โมเดลฉลาดขึ้นเอง ทีม JetBrains ทำสิ่งที่ตรงไปตรงมากว่ามาก คือเขียนกติกาให้ agent อ่านแล้วทำตาม

go-modern-guidelines เป็น repository ที่รวบรวม guideline 57 ข้อ ครอบคลุมตั้งแต่ Go 1.0 ยัน Go 1.27 แต่ละข้อประกอบด้วย "เขียนแบบนี้ ไม่ใช่แบบนี้" พร้อมโค้ดตัวอย่าง before/after ครบชุด แนวคิดง่าย ๆ คือให้ agent มี reference ที่ชัดเจนแทนที่จะเดาเอาเอง

ที่สำคัญคือมันไม่ใช่แค่เอกสารอ่านเล่น — ตัว guideline นี้ถูกแพ็กเป็น plugin/skill ให้ติดตั้งเข้าไปใน agent ได้ตรง ๆ รองรับทั้ง Junie, Claude Code, Codex, Cursor และ agent อื่น ๆ ผ่าน skills.sh พอติดตั้งแล้ว agent จะเรียกใช้ guideline นี้โดยอัตโนมัติตอนเจองานที่เกี่ยวกับ Go

ข้างในมีอะไรน่าสนใจบ้าง

ผมขอหยิบตัวอย่างที่เห็นแล้ว "นี่แหละ ที่ agent มักพลาด" มาให้ดูสักสองสามตัว

`min` / `max` แทนการเทียบเอง (Go 1.21)

// แบบเก่า
if a > b {
    return a
}
return b

// แบบใหม่
return max(a, b)

`slices.Contains` แทน loop หา (Go 1.21)

// แบบเก่า
found := false
for _, x := range items {
    if x == target {
        found = true
        break
    }
}

// แบบใหม่
found := slices.Contains(items, target)

`for i := range n` แทนการนับเอง (Go 1.22)

// แบบเก่า
for i := 0; i < n; i++ {
    doSomething(i)
}

// แบบใหม่
for i := range n {
    doSomething(i)
}

`errors.AsType` แทน `errors.As` แบบเก่า (Go 1.26)

// แบบเก่า
var e *MyError
if errors.As(err, &e) {
    handle(e)
}

// แบบใหม่ — ได้ตัวแปรตรง ๆ ไม่ต้องประกาศไว้ก่อน
if e, ok := errors.AsType[*MyError](err); ok {
    handle(e)
}

มีอีกเพียบ — clear(m) ล้าง map, maps.Clone/maps.Copy, slices.Sorted เรียงจาก iterator, sync.OnceValue สำหรับ memoize, context.AfterFunc สำหรับ cleanup ตอน cancel ไปจนถึงของใหม่สุดอย่าง generic methods และ encoding/json/v2 ที่เพิ่งเข้าใน Go 1.27

ลองใช้ดู

เริ่มใช้งานง่าย ๆ — ถ้าใช้ Claude Code ก็สั่งติดตั้ง marketplace แล้วให้มันโหลด skill นี้เข้าไปได้เลย (คำสั่งติดตั้งครบอยู่ใน README ของ repo) หรือถ้าใช้ agent ตัวอื่นที่รองรับ skills.sh ก็แค่รัน

npx skills add JetBrains/go-modern-guidelines

แค่นี้ agent ของคุณก็จะรู้จัก idiom ใหม่ ๆ ของ Go แทนที่จะยึดติดกับสไตล์เก่า ๆ ที่มันจำมาจากโค้ดบน internet

สรุป

ปัญหาที่ AI เขียน Go เชย ไม่ใช่เพราะโมเดลโง่ แต่เพราะข้อมูลเทรนเก่ากว่า release ล่าสุดของ Go ทางออกที่ JetBrains เสนอคือการยัด "ความรู้" เข้าไปใน context ของ agent ผ่าน guideline ที่ชัดเจน ซึ่งก็คือสิ่งที่ go-modern-guidelines ทำ — และมันไปทางเดียวกับ modernize analyzer ของ Go team เป๊ะ

สำหรับใครที่ปล่อยให้ AI เขียน Go บ่อย ๆ ผมว่านี่เป็น skill ที่คุ้มค่าติดไว้ ไม่ต่างจากใส่ style guide ให้ทีม dev เลย

แหล่งอ้างอิง

JetBrains/go-modern-guidelines — https://github.com/JetBrains/go-modern-guidelines
Go team — modernize analyzer (เครื่องมือ auto-update โค้ด Go เก่าให้เป็น idiom ใหม่)

จาก Vibe Coding สู่ Agentic Engineering — SDLC ใหม่ที่กำลังมาแทนที่

Gophernment — Sun, 16 Aug 2026 11:19:12 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | อ้างอิง: Whitepaper "The New SDLC With Vibe Coding" (พ.ค. 2026)
⚠️ ตัวเลขและเครื่องมือในบทความอาจเปลี่ยนตามเวลา

ลองนึกภาพตามนะครับ — เมื่อสิบปีก่อน ถ้าคุณจะเขียนฟีเจอร์ใหม่สักตัว คุณต้องนั่งไล่พิมพ์ syntax ให้ถูกต้องทีละบรรทัด ต้องรู้ว่าวงเล็บปิดตรงไหน semicolon อยู่ตรงไหน แล้วค่อยรันแล้วรอ error มาบอกว่าพิมพ์ผิดตรงไหนอีก

ตอนนี้ภาพนั้นกำลังหายไปเร็วมาก

มี whitepaper 51 หน้าเล่มหนึ่งชื่อ "The New SDLC With Vibe Coding" เขียนโดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis ตีพิมพ์บน Kaggle เมื่อเดือนพฤษภาคม 2026 มันพูดถึงเรื่องเดียวที่กำลังเขย่าวงการนักพัฒนา — การที่เราเปลี่ยนจาก "เขียนโค้ด" เป็น "เขียนเจตนา"

ตัวเลขที่เปิดมาทีแรกก็ทำเอาสะดุ้ง: ต้นปี 2026 มีนักพัฒนามืออาชีพ 85% ที่ใช้ AI coding agent เป็นประจำ ครึ่งหนึ่งใช้ทุกวัน และประมาณ 41% ของโค้ดใหม่ทั้งหมดถูก AI เขียนขึ้นมา

แล้วถ้าอยากเห็นภาพชัดที่สุดว่า "วงจรพัฒนาซอฟต์แวร์" (SDLC) เปลี่ยนไปยังไง ดูรูปนี้เลย — ฝั่งซ้ายคือวิธีที่เราทำงานกันมานับสิบปี ฝั่งขวาคือสิ่งที่กำลังมาแทนที่:

เห็นความต่างไหมครับ — ฝั่งซ้ายมนุษย์ต้องทำทุกขั้นตอนเรียงกันไปทีละเฟส แต่ฝั่งขวาเหลือแค่สองจุดที่มนุษย์ต้องอยู่จริง ๆ คือตอน "กำหนดเจตนา" กับตอน "ตรวจสอบคุณภาพ" ส่วนตรงกลางปล่อยให้ AI วน loop ไปเองจนกว่าจะผ่าน

แต่ก่อนจะไปต่อ ผมอยากให้เราเข้าใจคำหนึ่งให้ตรงกันก่อน เพราะมันเป็นหัวใจของเรื่องทั้งหมด

"vibe coding" คำนี้มาจากไหน

เดือนกุมภาพันธ์ 2025 Andrej Karpathy เขียนบรรยายวิธีเขียนโปรแกรมแบบใหม่ที่เขาเรียกว่า vibe coding — แนวคิดคือคุณ "ยอมแพ้ต่อ vibe เต็มตัว แล้วลืมไปเลยว่าโค้ดมีอยู่จริง" คุณแค่บอกสิ่งที่อยากได้เป็นภาษาธรรมดา รับผลลัพธ์จาก AI มาใช้ และถ้ามันพังก็ copy ข้อความ error กลับไปให้ AI แก้ให้

คำนี้ระเบิดขึ้นมาทันที เพราะมันไปแตะสิ่งที่คนทำกันอยู่เงียบ ๆ มานานแต่ไม่มีคำเรียก

แต่พอมันดัง คำก็เลยถูกใช้จนความหมายเลอะเทอะ — senior engineer ที่ใช้ AI ช่วย implement ฟีเจอร์ที่ spec ครบถ้วน ก็ถูกเรียก "vibe coding" เหมือนกับคนที่ prompt มั่ว ๆ แล้วยัดโค้ดขึ้น production ไปดื้อ ๆ

จนกระทั่งต้นปี 2026 Karpathy เองออกมายอมรับว่า framing เดิมมันแคบเกินไป และแนะนำคำใหม่คือ "agentic engineering" สำหรับปลายทางสายที่มีวินัยมากกว่า

เส้นแบ่งจริง ๆ ไม่ใช่ "ใช้ AI หรือไม่" แต่อยู่ที่ "ตรวจสอบแค่ไหน"

นี่คือประเด็นที่สำคัญที่สุดของ whitepaper — vibe coding กับ agentic engineering ไม่ใช่สองสิ่งที่แยกขาดจากกัน แต่อยู่บนเส้นเดียวกัน (spectrum) และสิ่งที่แยกสองปลายออกจากกันไม่ใช่เรื่องว่าใช้ AI หรือเปล่า แต่เป็นเรื่องว่าเราตรวจสอบผลลัพธ์จาก AI มากแค่ไหน

ลองไล่ดูทีละมิติ:

การระบุเจตนา — ฝั่ง vibe coding คือพิมพ์ prompt สบาย ๆ ไม่คิดเยอะ ฝั่ง agentic engineering คือมี spec, architecture doc และ memory file ครบถ้วน
การตรวจสอบ — ฝั่งหนึ่งคือ "เอ๊ะ มันดูใช้ได้มั้ง" อีกฝั่งคือมี test suite, CI/CD gate และ LM judge คอยตรวจ
การแก้ error — ฝั่งหนึ่ง copy error กลับไปให้ AI เฉย ๆ อีกฝั่งคือคนหาต้นตอให้เจอก่อน แล้วให้ AI implement ฟิกซ์

หัวใจจริง ๆ อยู่ที่กลไกตรวจสอบสองตัวที่ทำงานคู่กัน: tests ตรวจส่วนที่ "กำหนดได้" (ฟังก์ชันรับ input นี้ต้องคืน output นั้น) ส่วน evals ตรวจส่วนที่ "กำหนดไม่ได้" (agent เลือกเส้นทางถูกไหม ใช้ tool ถูกไหม ผลลัพธ์ถึงมาตรฐานไหม)

whitepaper พูดตรง ๆ ว่า ถ้าไม่มีทั้ง tests และ evals — ต่อให้ prompt เก่งแค่ไหน มันก็ยังเป็น vibe coding อยู่ดี

แล้วเราควรยืนตรงไหนของเส้นนี้? คำตอบคือขึ้นกับ "เดิมพัน" ของงาน — prototype ในวันหยุดก็ vibe coding ได้เต็มที่ แต่ API ที่คุมธุรกรรมการเงินต้อง agentic engineering เท่านั้น งานจริงส่วนใหญ่อยู่ตรงกลาง และทักษะที่แท้จริงคือรู้ว่าจะขีดเส้นตรงไหนของแต่ละงาน

ทักษะที่แท้จริงไม่ใช่ "prompt" แต่เป็น "context"

มี insight หนึ่งที่ whitepaper ย้ำหลายรอบ และผมว่ามันคือของขวัญที่ดีที่สุดในเล่ม: คุณภาพของโค้ดจาก AI ไม่ได้ขึ้นกับความฉลาดของ prompt แต่อยู่ที่คุณภาพของ context ที่เราป้อนให้มัน

นี่คือที่มาของคำว่า context engineering

ลองคิดแบบนี้ — ถ้าคุณจะให้สมาชิกใหม่มาช่วยเขียนโค้ดในโปรเจกต์ คุณจะไม่ยัดทุกอย่างให้เขารู้ในประโยคเดียว แต่คุณจะให้เขาอ่าน documentation ดู diagram รู้จัก convention ของทีม แล้วค่อยลงมือ

กับ AI ก็เหมือนกัน มันไม่ได้ต้องการ "คำสั่งที่แต่งมาฉลาด ๆ" แต่มันต้องการ context แบบเดียวกับที่มนุษย์เก่ง ๆ ต้องการถึงจะทำงานดีได้

context พวกนี้แบ่งเป็นสองชั้นที่สำคัญ:

Static context — โหลดตลอดเวลา เช่น AGENTS.md, CLAUDE.md, memory ของโปรเจกต์ มันแพง เพราะทุก token อยู่ในทุก interaction ไม่ว่าจำเป็นหรือไม่
Dynamic context — โหลดเฉพาะเมื่อต้องการ เช่น skill ที่ถูกเรียกเมื่อ task ตรง, เอกสารที่ดึงจาก RAG, ประวัติ session มันประหยัด เพราะจ่าย token เฉพาะตอนใช้

และกุญแจที่ทำให้จัดการสองชั้นนี้ได้คือ Agent Skills — แพ็กเกจความรู้ที่ agent โหลดเฉพาะเมื่องานเรียกใช้ แทนที่จะยัดทุกอย่างลง system prompt ตั้งแต่วินาทีแรก

ประโยคที่ผมชอบที่สุดในหัวข้อนี้คือ:

คำถามไม่ใช่ "จะหลอก AI ให้เขียนโค้ดดี ๆ ได้ยังไง" แต่อยู่ที่ "ถ้าจะมีสมาชิกใหม่มาช่วยงาน เขาต้องรู้อะไรบ้าง แล้วเราจะ encode ความรู้นั้นให้ AI ใช้ยังไง"

model ไม่ใช่ทุกอย่าง — แนวคิด Harness ที่คนส่วนใหญ่เข้าใจผิด

ตอนนี้ขอเปลี่ยนจังหวะหน่อย เพราะส่วนถัดไปคือจุดที่ผมเห็นคนเข้าใจผิดกันเยอะที่สุด

เวลาคนใช้ AI coding agent แล้วผลออกมาแย่ สัญชาตญาณแรกของเราคือโทษ model — "model นี้โง่" "รุ่นใหม่ยังไม่เก่ง" แต่ whitepaper บอกว่านั่นคือ intuition ที่ผิด และมันพาเราลงทุนผิดทาง

ความจริงคือ model เป็นแค่ "เครื่องยนต์" ตัวเดียวในโรงงาน — เครื่องยนต์อย่างเดียวผลิตรถออกมาไม่ได้ ต้องมีสายพาน เฟือง และเซนเซอร์ความปลอดภัยคอยประกอบ

สิ่งที่ห่อหุ้ม model อยู่รอบ ๆ — prompt, tools, sandbox, sub-agent, observability, guardrails — เรียกรวมว่า Harness

Agent = Model + Harness

หลักฐานที่ทำให้เรื่องนี้จับต้องได้จริง:

บน Terminal Bench 2.0 มีทีมหนึ่งดัน coding agent จากนอก Top 30 ขึ้นไป Top 5 ได้ โดยเปลี่ยนแค่ harness อย่างเดียว — ไม่เปลี่ยน model เลยแม้แต่ตัวเดียว
งานวิจัยของ LangChain ยกคะแนน agent บน benchmark เดียวกันขึ้น 13.7 คะแนน ด้วยการปรับแค่ system prompt, tools และ middleware รอบ model ที่ fixed ไว้

สรุปเป็นประโยคที่ควรแปะไว้หน้ามอนิเตอร์: เมื่อ agent ทำพลาด อย่าเพิ่งโทษ model — ความจริงส่วนใหญ่คือ configuration ที่พลาด ไม่ว่า tool จะหายไป กฎคลุมเครือ guardrail ไม่มี หรือ context เต็มไปด้วย noise

ปัญหา 80% — ทำไม AI ยังแทนเราไม่ได้ (และก็ไม่ควร)

แล้วทำไมเราถึงยังต้องการคนอยู่ตรงกลาง? whitepaper เรียกมันว่า "80% problem" — AI สร้างโค้ด 80% แรกของฟีเจอร์ได้เร็วมาก แต่ 20% ที่เหลือ ทั้ง edge case, error handling, จุด integration และ requirement ละเอียดอ่อน ต้องอาศัยความรู้เชิงลึกที่ model ยังไม่มี

และที่น่ากังวลกว่าคือ nature ของ error มันเปลี่ยนไปแล้ว — จาก "พิมพ์ syntax ผิด" กลายเป็น "เข้าใจ business logic ผิด", "ไม่ถามตอน requirement คลุมเครือ", "พลาด edge case" หรือ "ตัดสินใจ architecture ที่สร้างหนี้ระยะยาว" ซึ่งตรวจจับยากมากเพราะโค้ดมันดูถูก และอาจผ่าน test พื้นฐานด้วยซ้ำ

ตัวเลขที่หลายคนชอบอ้างว่า AI ทำให้เร็วขึ้น 25–39% ก็ต้องอ่านให้ละเอียด — งานวิจัยของ METR พบว่านักพัฒนาที่มีประสบการณ์ใช้ AI แล้วช้าลง 19% ในงานบางประเภท เพราะเวลาโดนกลืนไปกับการตรวจ แก้ และไล่บั๊กโค้ดที่ AI สร้าง

คนที่ใช้ AI ได้เก่งที่สุดจึงไม่ใช่คนที่รับทุกอย่างที่ AI ยื่นให้ แต่คือคนที่รู้ว่าเมื่อไหร่ควรให้ AI ทำ (งานที่ spec ชัด) และเมื่อไหร่ควรเก็บสมาธิของตัวเองไว้ (requirement คลุมเครือ, trade-off ทาง architecture, การ verify ความถูกต้อง)

เงินที่ซ่อนอยู่ใต้ vibe coding

ส่วนนี้สำคัญเป็นพิเศษสำหรับคนที่ต้องตัดสินใจในระดับทีมหรือองค์กร เพราะมันเปลี่ยนมุมมองจาก "เขียนได้เร็วแค่ไหน" เป็น "ต้นทุนรวมเท่าไหร่"

vibe coding ดูถูกมากตอนเริ่ม — จ่าย subscription เดือนละไม่กี่ร้อย แล้ว prompt ไปเรื่อย ๆ แต่ whitepaper ชี้ให้เห็นว่ามันมี OpEx ที่แฝงตัวและทบต้นอยู่สามก้อน:

Token burn — ยัดไฟล์ก้อนใหญ่แบบไม่มีโครงสร้างเข้า context แล้วให้ AI แก้ผิดซ้ำไปมา วน prompt เผา token เปลือง ๆ
Maintenance tax — โค้ดที่เกิดจาก prompt มั่ว ๆ ไม่มีโครงสร้าง พอบั๊กโผล่ทีหลัง 6 เดือน คนต้องนั่ง reverse-engineer "โค้ดสปาเก็ตตี้" กันเป็นวัน ๆ
Security remediation — ไม่มี eval harness คุม = สร้างโค้ดเร็ว = สร้างช่องโหว่เร็ว และค่าแก้ช่องโหว่ใน production แพงกว่าตอน design เป็นทวีคูณ

ฝั่ง agentic engineering กลับกัน — จ่าย upfront กับการออกแบบ API schema, เขียน test suite, จัดโครงสร้าง context ให้ดีตั้งแต่แรก ซึ่งแพงกว่าในตอนเริ่ม แต่ marginal cost ต่อฟีเจอร์ถัด ๆ ไปลดฮวบ เพราะ AI ทำงานอยู่ใน "โรงงาน" ที่มีกฎคุม output เลยมีโครงสร้าง ผ่าน test และตรง standard

ส่วน context engineering เองก็กลายเป็นกลยุทธ์การเงินไปโดยปริยาย — LLM คิดเงินทุก token ที่เราส่งไป การยัด repo 100,000 token เข้าทุก prompt คือการเผาเงินแบบไม่จำเป็น และทางแก้คือ intelligent model routing: ใช้ model ใหญ่แพงกับงานที่ซับซ้อน แต่ route งานง่าย ๆ (generate test, code review, CI/CD) ไปให้ model เล็กที่ถูกกว่ามาก

แล้วควรเริ่มยังไง

whitepaper ปิดท้ายด้วย checklist ที่เอาไปใช้ได้จริง ผมสรุปเฉพาะตัวที่คิดว่าสำคัญสุดมาให้

ถ้าคุณเป็น developer เริ่มจากสามอย่างนี้พอ:

ตั้ง AGENTS.md ให้โปรเจกต์ — เริ่มจากสิบบรรทัด: stack, convention, กฎตายตัว, workflow แล้วค่อยเพิ่มกฎทุกครั้งที่ agent ทำสิ่งที่ไม่อยากให้ทำซ้ำ
เขียน tests + evals ก่อน generate โค้ด — มันคือ "สัญญา" กับ AI สื่อเจตนาได้แม่นกว่า prompt ไหน ๆ
review ทุกบรรทัดที่จะ ship — ระแวงโค้ดที่ "ฉลาดเกินไป" เช็ค import ว่าเป็นแพ็กเกจจริง ตรวจ error handling ให้ครบ

ถ้าคุณเป็น leader เรื่องสำคัญสุดคือการยกระดับมาตรฐานของทีม:

ทำให้ context engineering เป็น practice ระดับทีม — AGENTS.md, system prompt และ eval suite ต้องถูก review ใน PR, version กับโปรเจกต์ และมีคนรับผิดชอบชัดเจน
ตั้งมาตรฐานที่ "eval" ไม่ใช่ "demo" — demo ผ่านแค่แปลว่าทำสำเร็จครั้งเดียว แต่ eval ผ่านแปลว่าทำสำเร็จทุกครั้ง

ทิ้งท้าย

ถ้าจะย่อ 51 หน้าให้เหลือบรรทัดเดียว ผมขอสรุปแบบนี้:

เราไม่ได้เลิกเขียนโค้ด — เราแค่เปลี่ยนจาก "เขียน syntax" เป็น "เขียนเจตนา" แล้วปล่อยให้เครื่องจักรรับผิดชอบการ implement ส่วนมนุษย์เก็บงานที่เหลือไว้: การตัดสินใจ รสนิยม และการตรวจว่าของที่ออกมาดีจริง

และจุดแบ่งระหว่าง vibe coding ที่น่ากลัว กับ agentic engineering ที่เชื่อถือได้ ไม่ได้อยู่ที่ tool ที่เราเลือกใช้ แต่อยู่ที่ ว่าเราตั้ง harness รอบ ๆ AI ไว้แน่นแค่ไหน

📚 อ้างอิง: The New SDLC With Vibe Coding — Addy Osmani, Shubham Saboo, Sokratis Kartakis (Kaggle, พฤษภาคม 2026)
🔗 อ่านต้นฉบับ: https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

Goish: พอร์ตรันไทม์ของ Go ทั้งตัวลงใน no_std Rust

Gophernment — Sat, 15 Aug 2026 02:40:33 +0000

📅 เขียนเมื่อ: สิงหาคม 2026 | Goish (goish.cogentica.ai)
⚠️ โปรเจกต์เพิ่งเปิดตัว — รายละเอียด/เวอร์ชันอาจเปลี่ยนแปลง ตรวจสอบจาก GitHub ก่อนใช้งาน

ถ้าคุณเขียน Go มาสักพัก คุณน่าจะเคยอยากได้สองอย่างพร้อมกัน — concurrency model ของ Go (goroutine, channel, select) กับ ความปลอดภัยด้าน memory ของ Rust (ownership, ไม่มี GC) ปกติแล้วสองอย่างนี้อยู่คนละโลก: Go ให้ runtime มาให้แต่มี garbage collector, Rust ให้ ownership มาแต่ concurrency ต้องประกอบเองจาก async/futures

มีคนพยายามเชื่อมสองโลกนี้เข้าด้วยกันแล้ว — ชื่อโปรเจกต์ว่า Goish ผลงานของ Chanwit Kaewkasi (@chanwit) วิศวกรชาวไทยจากโคราช ภายใต้บริษัท Cogentica AI

Goish คืออะไร

นิยามสั้น ๆ ที่เจ้าตัวเขียนไว้ในหน้าแรก: "A Rust runtime for Go people" — รันไทม์ของ Go สำหรับคนที่เขียน Go

ถ้าขยายให้ละเอียด: Goish คือการพอร์ต standard library และ runtime ของ Go 1.25 ลงไปใน Rust แบบ no_std — ไม่พึ่ง glibc, ไม่พึ่ง std ของ Rust, ไม่พึ่ง Tokio, ไม่มี garbage collector มัน ship ทุกอย่างมาเองตั้งแต่ _start, page allocator, size-class heap, M:N scheduler, channel, select!, sync primitives, ไปจนถึง net/http และ crypto/tls

ผลลัพธ์คือ binary ไฟล์เดียวแบบ static เหมือน Go — ldd รันแล้วบอกว่า "not a dynamic executable"

แต่สิ่งที่ทำให้ Goish ต่างจากโปรเจกต์ "เขียน Go ให้เป็น Rust" ทั่วไป คือวิธีที่มันให้เครดิตกับต้นทาง — เรื่องนี้แหละคือหัวใจของที่มาที่ไป

ทำไมถึงคิดทำตัวนี้ (ที่มาที่ไป)

แรงจูงใจหลักไม่ใช่ "อยากให้ Rust เขียนง่ายเหมือน Go" ธรรมดา ๆ แต่เป็นเรื่องของ compliance และ provenance

ลองนึกภาพ: ทีมคุณเขียน Go อยู่ แล้วต้องย้ายไป Rust (ด้วยเหตุผลเรื่อง memory safety หรือนโยบายบริษัท) ระหว่างทางคุณต้อง "พอร์ต" โค้ด — เอาโค้ดจาก Go มาเขียนใหม่เป็น Rust แล้วคำถามสำคัญก็ผุดขึ้น:

AES-GCM ใน binary ตัวนี้ เป็น implementation ที่ Go review แล้ว หรือเป็นของที่เราเขียนประมาณเอา?

เครื่องมือ supply-chain ยุคปัจจุบันอย่าง SLSA provenance หรือ SBOM ตอบคำถามนี้ไม่ได้ — มันอธิบายแค่ว่า binary ถูก build มาจากไหน (builder ไหน, commit อะไร, digest อะไร) แต่อธิบายไม่ได้ว่าโค้ดข้างในถูก port มาอย่างซื่อสัตย์แค่ไหน SBOM จะบันทึกว่า "goish 0.1.0" แล้วจบ — มันแยกไม่ออกว่า crypto ในนั้นคือของจริงหรือของก๊อป

Goish แก้ด้วยการบันทึกที่มาเป็นฟังก์ชันต่อฟังก์ชัน:

// go: sdk 1.25.5 crypto/internal/fips140/aes/gcm/gcm.go:31-46 newGCM

บรรทัดนี้เขียนไว้เหนือ port แต่ละตัว — บอกว่าโค้ดตรงนี้ port มาจากไฟล์ไหน บรรทัดไหน ใน Go 1.25.5 และมี CI ที่เปิด Go tree ขึ้นมาเช็คทุก commit ว่าตำแหน่งที่อ้างยังถูกต้องอยู่

ทำไมเรื่องนี้ถึงสำคัญตอนนี้? เพราะเส้นตายทางกฎหมายกำลังมา:

วันที่	เกิดอะไรขึ้น
11 ก.ย. 2026	EU CRA (Cyber Resilience Act) บังคับใช้ภาระการรายงาน — แจ้งเตือน 24 ชม. / แจ้งเต็ม 72 ชม. เมื่อเจอช่องโหว่ที่ถูกโจมตีจริง
21 ก.ย. 2026	ใบรับรอง FIPS 140-2 ย้ายเข้า "Historical List" — ใช้ต่อได้แต่ justify การจัดซื้อภาครัฐใหม่ไม่ได้
1 ม.ค. 2027	CNSA 2.0 กลายเป็นค่าเริ่มต้นสำหรับงาน NSS ของสหรัฐฯ
11 ธ.ค. 2027	ข้อกำหนดสำคัญของ CRA รวมถึง mandate เรื่อง machine-readable SBOM

พูดง่าย ๆ: ถ้าสินค้าคุณต้องผ่าน compliance พวกนี้ คุณต้องพิสูจน์ได้ว่าโค้ดทุกบรรทัดมาจากไหน — และสำหรับโค้ดที่ "แปล" มาจากที่อื่น การพิสูจน์นั้นต้องลงถึงระดับฟังก์ชัน ไม่ใช่ระดับ build

นี่คือเหตุผลที่ Goish เกิด

ใช้เทคนิคอะไรบ้าง

ส่วนนี้คือความเจ๋งทางวิศวกรรม — ถ้าไม่อยากอ่านเชิงลึก ข้ามไปหัวข้อถัดไปได้เลย

1. M:N Scheduler — พอร์ตแบบ verbatim จาก `runtime/proc.go`

Goish ไม่ได้ "เขียน scheduler ใหม่ให้คล้าย Go" — มันแปล runtime/proc.go ของ Go 1.25 มาทีละบรรทัด:

Per-P run queue แบบ lock-free SPMC (256 entry) + global overflow
Work stealing แบบ coprime-permuted (runqgrab / runqsteal / stealOrder)
Async preemption ผ่าน SIGURG (เทคนิคเดียวกับที่ Go ใช้หยุด goroutine ที่รันนานเกิน)
sysmon ตัวจัดการ timer heap + force-preempt
epoll netpoller แบบ per-P (โมเดลเดียวกับ nginx) — เวลา goroutine รอ I/O มันจะ park goroutine ไม่ใช่ block thread

2. Memory: page allocator + 67 size classes (แต่ไม่มี GC)

Goish เอาโครงสร้าง allocator ของ Go (mheap → mcentral → per-P mcache, 67 size classes) มาใช้ แต่ตัด garbage collector ออก — ให้ Rust ownership เป็นคน reclaim แทน

สำหรับ stack ของ goroutine มันใช้วิธีฉลาด: goroutine หนึ่งตัวได้ virtual reservation 1 MiB แบบ lazy-commit (kernel ค่อย commit หน้า 4 KiB เมื่อถูกแตะจริง) — แปลว่า goroutine ที่ทำงานตื้น ๆ เสีย memory จริงแค่ประมาณหนึ่ง page และถ้าอยากได้ความหนาแน่นสุดขีด ก็ใช้ go!(stack(2*KB), …) เพื่อขอ stack ขนาด 2 KiB จาก stack pool

ผลลัพธ์ตาม demo:

ts  vmsize_kb  vmrss_kb  vmpeak_kb  vmhwm_kb  threads
 0s    1105148      44800    1108444      49024   13   ← baseline
 2s    3069660    2406528    3069660    2406528   13   ← 1M parked
30s    3069660    2406528    3069660    2406528   13   ← steady-state

goroutine หนึ่งล้านตัว บน OS thread แค่ 13 เธรด — ~2.4 KiB RSS ต่อ goroutine

3. เขียนโค้ดที่ "อ่านแล้วเหมือน Go" แต่ compile ด้วย rustc

จุดเด่นที่สุดสำหรับคนเขียน Go — public API ใช้ type ตัวพิมพ์เล็กแบบ Go แทน type ของ Rust:

fn get(url: string) -> (int, string, string) {
    let (mut resp, err) = http::Get(url.clone());
    if err != nil {
        return (-1, fmt::Sprintf!("get %s: %v", url, err), string(""));
    }
    let (body, _) = io::ReadAll(&mut resp.Body);
    let _ = io::Closer::Close(&mut resp.Body);
    return (resp.StatusCode, string(body), resp.Header.Get("Content-Type"));
}

string, int, multi-return, if err != nil — ทั้งหมดคือ Rust จริง ๆ ที่ rustc compile ได้ แต่อ่านแล้วแทบไม่ต่างจาก Go และ Vec<u8> กับ &str ไม่โผล่ใน signature สาธารณะเลย

นี่คือ philosophy หลัก: "Port first, get idiomatic later" — พอร์ตโค้ด Go มาแบบเกือบ line-by-line ก่อน แล้วค่อย ๆ ปรับเป็น Rust idiom ทีละ module เมื่อทีมพร้อม

4. crypto/tls — พอร์ตครบ 100% พร้อมใบเสร็จทุกบรรทัด

ส่วนที่ภาคภูมิใจที่สุดคือ crypto/ — ครบ 1722/1722 declarations (100%) ทั้ง 66 packages รวมถึง crypto/internal/fips140* ทั้ง 35 packages ที่เป็น code path ของ FIPS validation และ net/http ครบ 639/639 functions (100%)

TLS 1.3 ที่รันจริงคือ crypto/tls ที่ port มา verbatim — ไม่ใช่ implementation ใหม่ที่เขียนเลียนแบบ

ประโยชน์ที่ได้

Binary เดียว ไม่มี libc ไม่มี ld.so — ลด attack surface เหลือแค่ตัว binary เอง เหมาะกับ scratch/distroless container, confidential VM, appliance image
Memory safety + concurrency model ของ Go — ได้ ownership ของ Rust (ไม่มี dangling pointer, ไม่มี data race) กับ goroutine/channel/select ของ Go ในตัวเดียว
Provenance ถึงระดับฟังก์ชัน — พิสูจน์ compliance (EU CRA, FIPS, CNSA) ได้ เพราะทุกฟังก์ชันมีที่มาอ้างอิง
ไม่มี GC ให้ tune — ไม่มี stop-the-world ไม่มี GC pause
เส้นทาง migrate จาก Go → Rust แบบค่อยเป็นค่อยไป — ไม่ต้องหยุดทุกอย่างเพื่อ rewrite ใหม่หมด

วิธีเริ่มต้น

ต้องการแค่ Rust 1.79+ และ Linux x86_64 (single-target ณ ตอนนี้)

git clone https://github.com/cogentica-ai/goish
cd goish

# build library
cargo build --target x86_64-unknown-linux-gnu --release

# demo: หนึ่งล้าน goroutine
cargo build --target x86_64-unknown-linux-gnu --release --example spawn_million
./examples/spawn_million.sh

# goginx: nginx clone ที่เขียนด้วย goish
cargo build --target x86_64-unknown-linux-gnu --release --example goginx

โค้ด "Hello" แบบ Goish หน้าตาประมาณนี้:

use goish::{fmt, go};

#[goish::main]
fn main() {
    go!(move || {
        fmt::Println!("hello from a goroutine");
    });
}

ข้อจำกัด (บอกตรง ๆ)

ยังไม่ใช่ Go compiler — คุณเขียน Rust ที่อ่านเหมือน Go ไม่ได้ compile ไฟล์ .go
Linux x86_64 เท่านั้น — target อื่นยังไม่อยู่ใน scope
ยังไม่ผ่าน security audit — TLS stack port มาแบบ machine-checked แต่ยังไม่มี external review (ดู SECURITY.md ก่อนใช้จริง)
ยัง port ไม่ครบทั้ง Go — crypto/ กับ net/http เสร็จแล้ว แต่ net, encoding, os ยังบางส่วน

สรุป

Goish ไม่ได้เป็นแค่ "Go runtime ใน Rust" — มันเป็นความพยายามตอบคำถามที่ใหญ่กว่านั้น: เมื่อเราต้องย้ายภาษาในโลกที่มีกฎหมายบังคับเรื่องที่มาของโค้ด เราจะพิสูจน์ได้ยังไงว่าโค้ดทุกบรรทัดไว้ใจได้

คำตอบของ Chanwit คือการพอร์ต Go แบบมี "ใบเสร็จ" ทุกบรรทัด แล้วเอา ownership ของ Rust มาแทน GC — ได้ทั้งความคุ้นเคยของ Go, ความปลอดภัยของ Rust, และหลักฐาน compliance ที่ตรวจซ้ำได้

โปรเจกต์นี้เพิ่งเปิด (สิงหาคม 2026) และยังพัฒนาอย่างต่อเนื่อง ถ้าสนใจเข้าไปดูได้ที่:

🌐 https://goish.cogentica.ai
💻 https://github.com/cogentica-ai/goish

เครดิต: บทความนี้อ้างอิงข้อมูลจากเว็บไซต์ goish.cogentica.ai และ README ของ github.com/cogentica-ai/goish — โปรเจกต์โดย Chanwit Kaewkasi (@chanwit) ภายใต้ Cogentica AI (ประเทศไทย)

⚠️ Goish ไม่เกี่ยวข้องกับ Google หรือ Go project — "Go" เป็นเครื่องหมายการค้าของ Google LLC

REPL — วิธีคุยกับคอมพิวเตอร์ที่ LISP สอนโลก

Gophernment — Wed, 05 Aug 2026 10:14:29 +0000

คุณเคยนึกไหมว่าก่อนที่จะมี >>> ใน Python,
ก่อน node console,
ก่อน Chrome DevTools —

การคุยกับคอมพิวเตอร์มันเป็นยังไง?

คำตอบคือ... คุณไม่ได้คุยกับมัน คุณเขียนโปรแกรมทั้งก้อนบน punch card, ยัดเข้าเครื่อง, รอ output ออกมา, แล้วค่อยรู้ว่ามี bug หรือเปล่า

REPL เปลี่ยนทั้งหมดนั้น

READ → EVAL → PRINT → LOOP

REPL ย่อมาจาก Read-Eval-Print Loop — วงจรง่าย ๆ สี่ขั้นตอน:

1. READ   — อ่านสิ่งที่คุณพิมพ์
2. EVAL   — ประมวลผลมัน
3. PRINT  — แสดงผลลัพธ์
4. LOOP   — กลับไปรอ input ถัดไป

วงจรนี้เกิดจาก LISP ในทศวรรษ 1960s — read, eval, และ print คือ primitive function สามตัวของภาษา

เวลาเราเฉลิมฉลอง LISP เรามักพูดถึง garbage collection, lambda, macro — แต่ REPL ต่างออกไป

REPL ไม่ใช่ "feature"... มันคือ วิธีคิด

ก่อน REPL: ยุคที่คอมพิวเตอร์ไม่คุยกับคุณ

ลองนึกภาพ programmer ปี 1965:

เขียนโค้ดบนกระดาษ
เจาะ punch card
ยื่นให้ operator
รอคิว (อาจเป็นชั่วโมง หรือเป็นวัน)
เครื่องรัน
ได้ output
เจอ bug — กลับไปข้อ 1

นี่คือ batch processing — ทั้งวงการเป็นแบบนี้

ลองเทียบกับวันนี้: คุณพิมพ์ 2 + 2 → enter → 4 ปรากฏในเสี้ยววินาที

REPL ทำให้วงจร feedback จาก "เป็นวัน" เหลือ "เป็นวินาที"

นี่คือการเปลี่ยน paradigm ที่ใหญ่กว่า feature ใด ๆ ที่ LISP คิด — มันเปลี่ยนวิธีที่มนุษย์ interact กับคอมพิวเตอร์ จาก "สั่งแล้วรอ" เป็น "สนทนา"

กำเนิดในห้องแล็บ AI ของ MIT

read-eval-print loop ไม่ได้เกิดจาก philosophy หรือ manifesto — มันเกิดจากความจำเป็น

AI researchers ที่ MIT กำลังเขียนโปรแกรมที่ต้องลองผิดลองถูกตลอดเวลา เขียนโปรแกรมทั้งก้อนไม่ได้ — เพราะยังไม่รู้ด้วยซ้ำว่าอยากให้มันทำอะไร

พวกเขาต้องการ ทดลองทีละ expression — เห็นผลลัพธ์ทันที แล้วปรับสมมติฐาน

LISP — ด้วยความที่ทุกอย่างเป็น expression, ทุก expression ให้ผลลัพธ์ — เหมาะกับวิธีนี้อย่างเป็นธรรมชาติ

คำว่า "read-eval-print loop" ปรากฏครั้งแรกใน MACLISP Reference Manual (1974, David Moon)
แต่หลักการนี้ถูกใช้จริงมาตั้งแต่ LISP I system ในปี 1960 (LISP 1.5 Programmer's Manual ปี 1962 คือฉบับที่สมบูรณ์และแพร่หลายที่สุดในยุคนั้น)

ทำไม REPL ถึงสำคัญกว่า "แค่ console"

REPL ไม่ใช่แค่ terminal ที่พิมพ์คำสั่งได้ มันเปลี่ยนวิธีที่เรา:

วิธีเก่า	วิธี REPL
อ่าน documentation → ท่องจำ → เขียน	ทดลอง → ดูผล → เข้าใจ
รอ compile ทั้งโปรเจกต์	ทดสอบทีละฟังก์ชัน
กลัวผิด เพราะแก้ยาก	ผิดได้เร็ว แก้ได้เร็ว
code คือ artifacts สำเร็จรูป	code คือ conversation

นี่คือรากฐานของ exploratory programming — ปรัชญาที่บอกว่าเราไม่จำเป็นต้องรู้ทุกอย่างก่อนเริ่มเขียน เราเรียนรู้ระหว่างเขียนได้

การเดินทางของ REPL — จากห้องแล็บ AI มาถึงมือคุณ

1960s — LISP

REPL ตัวแรกของโลก — read, eval, print ในวงจรอนันต์

1990–1991 — Python

Guido van Rossum เริ่มพัฒนา Python ปลายปี 1989 เปิดตัวสู่สาธารณะครั้งแรกในเดือนกุมภาพันธ์ 1991 — REPL (>>>) เป็นส่วนหนึ่งของภาษามาตั้งแต่แรก โดยเอาไอเดียมาจาก LISP และ ABC language (ภาษาที่ Guido ช่วยพัฒนาก่อนหน้านี้)

สิ่งที่ Python เพิ่ม: readability — REPL ที่อ่านง่าย, error message ที่มนุษย์เข้าใจ, และ philosophy "มาเพื่อให้คนเขียน, ไม่ใช่ให้ compiler อ่าน"

1995 — Ruby IRB

Matz สร้าง IRB (Interactive Ruby) — สำหรับคนที่อยากลอง Ruby แบบ real-time (Ruby มี DNA LISP — Matz บอกว่า "Ruby was a Lisp originally, in theory")

2006 — Firebug

Joe Hewitt สร้าง Firebug extension สำหรับ Firefox — เป็นครั้งแรกที่ browser มี interactive console แบบ REPL: inspect DOM, ทดลอง JavaScript, ดู network request — ทั้งหมดใน browser โดยไม่ต้องเปิด terminal แยก วงการ frontend dev เปลี่ยนไปตลอดกาล

2009 — Node.js REPL

Ryan Dahl ให้ JavaScript มี REPL นอก browser — frontend dev สามารถลอง JS แบบ interactive โดยไม่ต้องเปิด browser เลย

2011 — Chrome DevTools Console

ทีม Chrome ของ Google ต่อยอดจาก WebKit Inspector (ต้นแบบของ Safari) สร้าง DevTools ที่มี Console ในตัว — แนวคิด interactive debugging ใน browser ที่ Firebug บุกเบิกไว้ กลายเป็น standard ในทุก browser หลังจากนั้น

2014 — IPython / Jupyter Notebook

Fernando Pérez ต่อยอด REPL ของ Python ให้เป็น notebook — ผสมโค้ด, ผลลัพธ์, markdown, กราฟ ในหน้าเดียว นี่คือ REPL เวอร์ชันที่สมบูรณ์แบบที่สุดสำหรับ data science

2015 — Rust Playground

Rust — ภาษาที่ compile ช้าเป็นชั่วโมง — มี playground ออนไลน์ที่ทำตัวเป็น REPL: เขียน → รัน → เห็นผล → ปรับ → รันใหม่ — ทั้งหมดใน browser

สิ่งที่ REPL สอนเรา

Feedback loop ที่สั้นที่สุดคืออาวุธที่ทรงพลังที่สุด — programmer ที่ทดลองเร็ว เรียนรู้เร็วกว่า programmer ที่รอ compile
ภาษาไม่ควร "ถูกต้องตั้งแต่ compile" ควร "เรียนรู้ระหว่างเขียน" — REPL ทำให้ภาษากลายเป็นเครื่องมือคิด ไม่ใช่แค่เครื่องมือผลิต
Simple ideas win — read → eval → print → loop — 4 คำ, 4 ขั้นตอน, เปลี่ยนวิธีมนุษย์เขียนโค้ดไปตลอดกาล

อ่านเพิ่ม

MACLISP Reference Manual (1974) — ที่มาของคำว่า "read-eval-print loop"
Paul Graham — "Revenge of the Nerds" — "Lisp was the first language to have an interactive REPL"
Bret Victor — "Inventing on Principle" — ทำไม feedback ที่ทันทีถึงเปลี่ยนวิธีเราคิด
Jupyter Project — REPL สำหรับ data science

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

LISP — ภาษา 67 ปีก่อน ที่ยังมีชีวิตอยู่ในทุกภาษาที่คุณเขียน

Gophernment — Tue, 04 Aug 2026 23:13:21 +0000

คุณเขียน if-else ทุกวัน
คุณรัน code ใน terminal แล้ว REPL มันตอบกลับมา
คุณ lambda ใน Python, arrow function ใน JavaScript, closure ใน Rust

— ทั้งหมดนี้ เกิดจากภาษา LISP

และที่น่าทึ่งคือ... LISP ไม่เคยถูก planned ให้เป็นภาษาโปรแกรมด้วยซ้ำ

กระดาษแผ่นเดียวที่เปลี่ยนโลก

1958 — John McCarthy เริ่มพัฒนาแนวคิด LISP ที่ MIT
เมษายน 1960 — McCarthy วัย 32 ตีพิมพ์ paper ใน Communications of the ACM (vol. 3, หน้า 184-195)

"Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I"

ใน paper 12 หน้านี้ McCarthy เสนอไอเดียของภาษาโปรแกรมที่:

จัดการกับสัญลักษณ์ (symbols) ไม่ใช่แค่ตัวเลข
ใช้ recursion เป็นตัวควบคุมการทำงาน แทนการใช้ loop
เก็บ function เป็น first-class citizen — ส่งต่อกันได้เหมือนข้อมูล

McCarthy เขียนมันขึ้นมาเป็น ทฤษฎีทางคณิตศาสตร์ — ไม่ได้ตั้งใจ implement

แต่ก่อน paper จะตีพิมพ์ — ระหว่างปี 1958-59 Steve Russell นักศึกษา grad student อ่าน manuscript

"I told him, 'Steve, why don't you program this eval?' and he said to me, 'Oh, I misread what you meant. I thought you meant I should implement the interpreter.'"

— John McCarthy, ACM interview

นักศึกษา เขียน interpreter ให้ทฤษฎีของอาจารย์ — และภาษา LISP ก็เกิด

code ตัวแรกที่ Russell เขียน ใช้เวลาแค่ 2-3 วัน (ตัว LISP 1.5 Programmer's Manual ฉบับเต็มออกตามมาทีหลัง ในปี 1962)

สิ่งที่ LISP สร้างไว้ (และเราใช้มันทุกวัน)

1. if-then-else

ย้อนไปปี 1958 — ภาษาส่วนใหญ่มีแค่ GOTO กับ branch แบบ assembly

McCarthy ให้กำเนิด cond (conditional expression) — จุดเริ่มต้นของ if-else ที่เราเห็นแทบจะในทุกภาษา

(cond ((< x 0) 'negative)
      ((= x 0) 'zero)
      (t 'positive))

C, Java, Python, JavaScript, Go, Rust — ภาษาเหล่านี้ได้รับมรดกนี้มาหมด Conditional branching ในทุกภาษาสมัยใหม่มีโครงสร้างแบบเดียวกับที่ McCarthy คิดไว้ตั้งแต่ก่อนมนุษย์ไปดวงจันทร์

2. Garbage Collection

ก่อน LISP — programmer จัดการ memory เอง 100% ทุกบรรทัดของ malloc และ free

LISP สร้าง garbage collection ตัวแรกของโลก — ต้นฉบับคือ mark-and-sweep algorithm (implement โดย Daniel Edwards นักศึกษา MIT)

ทุกวันนี้ GC คือ default ในเกือบทุกภาษา high-level — Java, Python, JavaScript, Go, C#, Ruby ล้วนใช้แนวคิดนี้ต่อยอด

3. Lambda — function เป็นข้อมูล

(lambda (x) (* x x))

LISP ทำให้ function เป็น first-class citizen — ส่ง function เป็น parameter ได้, return function ได้, เก็บลง variable ได้เหมือนเป็น string หรือ integer

นี่คือต้นทางของ:

JavaScript — arrow function (x) => x * x (Brendan Eich ถูกจ้างไป Netscape เพื่อทำ Scheme ใน browser — แต่ management เปลี่ยนใจให้ syntax เหมือน Java)
Python — lambda x: x * x
Ruby — blocks, procs, lambdas (Matz บอกว่า "Ruby was a Lisp originally, in theory")
Java — lambda expressions (Java 8, 2014 — ใช้เวลา 19 ปีกว่าจะตามทัน)
C++ — lambda (C++11)

4. REPL — ปรัชญา "คุยกับภาษา"

Read-Eval-Print Loop — LISP ให้กำเนิดมันในทศวรรษ 1960s

ก่อนหน้านั้น: เขียน code → compile → run → debug → repeat
หลังจากนั้น: พิมพ์ expression → กด enter → เห็นผลทันที

ทุกวันนี้ถ้าคุณเปิด Python REPL (>>>), Node.js console, Ruby IRB, Chrome DevTools, Rust Playground, หรือ Elixir IEx — คุณกำลังนั่งอยู่ในห้องเรียนเดียวกับ programmer LISP เมื่อ 60 ปีที่แล้ว

5. Homoiconicity — code = data

'(+ 1 2)          ; ← นี่คือ list
(eval '(+ 1 2))   ; ← นี่คือ code ที่รัน list

LISP เขียนด้วย... LISP — code กับ data ใช้โครงสร้างเดียวกัน (S-expression)

แปลว่า โปรแกรมแก้โปรแกรมตัวเองได้ — ไม่ต้องใช้ parser แยก AST, ไม่ต้องเขียน transformer

นี่คือรากฐานของ macro system ที่ทรงพลังที่สุดในสายภาษาโปรแกรม

ไม่มีภาษาไหนทำได้เต็มระบบเท่า LISP — แต่แนวคิด "code as data" ไปอยู่ใน:

Elixir — macro (รับ AST, คืน AST)
Julia — macro + multiple dispatch ("We want a language that's homoiconic, with true macros like Lisp" — Julia manifesto, 2012)
Rust — macro system (proc macro)
Clojure — macro (ของ Clojure ก็คือ LISP dialect นั่นเอง)

มรดกจาก LISP

LISP (1958)
├── Scheme (1975) — minimalist, lexical scoping
│   ├── JavaScript (1995) — Brendan Eich ตั้งใจทำ Scheme-like ใน browser
│   │   └── arrow functions, closure, first-class functions
│   └── Racket (1995) — ภาษาเพื่อการสอนและการวิจัย
├── Common Lisp (1984) — ภาคอุตสาหกรรม, pragmatic
│   └── Emacs Lisp (1985) — editor scripting (GNU Emacs)
├── Clojure (2007) — LISP บน JVM, immutable by default
│   └── จุดประกาย functional programming ในโลก enterprise
└── Python, Ruby, Elixir, Julia, Rust, Swift — ทุกภาษาเอาแนวคิด LISP ไปปรับใช้

ทำไม LISP ถึงไม่ใช่ภาษาหลักวันนี้

ทั้งที่สร้างนวัตกรรมเกือบทุกอย่างที่เราใช้ — ทำไม LISP ถึงไม่ชนะ?

Paul Graham (ผู้ก่อตั้ง Y Combinator, แฟนพันธุ์แท้ LISP) อธิบายไว้ใน essay "Beating the Averages":

Syntax ต่างจากทุกอย่าง — วงเล็บทำให้คนกลัว
ไม่มี standard library ในยุคแรก — Common Lisp มากอบกู้ในปี 1984 แต่ช้าไปแล้ว
AI Winter — LISP ผูกกับ AI research; เมื่องบ AI หาย LISP ก็หายด้วย
Tooling — compiler ช้า, IDE ห่วย (เทียบกับ Visual Studio ยุค 90s)

Graham ยืนยันว่า:

"Lisp is a language that was discovered, not invented."

ฝั่งนักวิจารณ์ LISP (รวมถึงคนที่เคยใช้ใน production แล้วเปลี่ยนไปภาษาอื่น) ชี้ปัญหาเพิ่มเติมที่ Graham ไม่พูดถึง:

Dynamic typing ในระบบใหญ่ — refactoring ยาก, compiler จับ error ได้น้อย, debugging ใช้เวลานานใน codebase ระดับแสนบรรทัด
Performance จนถึงยุค 2000s — ก่อน SBCL และ Chez Scheme, LISP runtime บน hardware ยุคนั้นช้ากว่า C/C++ มากโดยเฉพาะงาน numerical
Fragmentation — Common Lisp กับ Scheme ไม่เคยตกลงกันได้; community แตกเป็นเสี่ยง ๆ แทนที่จะรวมพลัง

สรุป: ไม่มีสาเหตุเดียว — มันคือ perfect storm ของ syntax ต่าง + เกิดผิดเวลา + community แตก + ไม่มี corporate sponsor (ต่างจาก Java ที่ Sun ทุ่ม, C# ที่ Microsoft ทุ่ม)

มรดกที่มองไม่เห็น

บทความนี้ไม่ได้ตั้งใจจะบอกว่า "คุณควรเขียน LISP"

แต่ทุกครั้งที่คุณ:

numbers = [1, 2, 3]
squared = list(map(lambda x: x * x, numbers))

const result = data
  .filter(x => x.active)
  .map(x => x.value);

let squared: Vec<_> = numbers.iter().map(|x| x * x).collect();

— คุณกำลังเขียน LISP โดยไม่รู้ตัว

อ่านเพิ่ม

McCarthy's Original 1960 Paper — "Recursive Functions of Symbolic Expressions"
Paul Graham — "Beating the Averages"
Paul Graham — "Revenge of the Nerds"
Structure and Interpretation of Computer Programs (SICP) — ตำรา Scheme ในตำนานของ MIT
Rich Hickey — "Simple Made Easy" — ปรัชญาเบื้องหลัง Clojure

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

GNU — จุดเริ่มต้นของ Linux ที่หลายคนไม่เคยรู้

Gophernment — Tue, 04 Aug 2026 22:51:23 +0000

เวลาเราเรียก Linux — เรามักนึกถึงระบบปฏิบัติการที่รันเซิร์ฟเวอร์ 99% ของโลก รัน Android รัน Raspberry Pi แต่สิ่งที่หลายคนไม่รู้คือ Linux ไม่ใช่ "ระบบปฏิบัติการที่สมบูรณ์" ตั้งแต่แรก มันเป็นแค่ kernel — หัวใจที่คอยคุยกับฮาร์ดแวร์

ส่วน shell, compiler, text editor, core utilities — ทั้งหมดนั่นมาจาก โครงการ GNU

เรื่องราวของ GNU และ Linux มันเริ่มจากการที่เครื่องพิมพ์เครื่องหนึ่ง... พัง

📌 ออกเสียงอย่างไร: GNU อ่านว่า "กะ-นู" (hard g, พยางค์เดียว) — GNU's Not Unix

เรื่องเล่าจากเครื่องพิมพ์

ปี 1980 Richard Stallman ทำงานที่ MIT AI Lab เครื่องพิมพ์ Xerox ในห้องแล็บ jam กระดาษบ่อยมาก เขาเลยอยากแก้ซอฟต์แวร์ให้มันแจ้งเตือนตอน jam แต่ Xerox ไม่ยอมให้ source code

สำหรับคนยุค 2026 นี่คือเรื่องปกติ — บริษัทไม่ให้ source code ก็หาอันอื่นสิ

แต่สำหรับ Stallman และวัฒนธรรม hacker ใน MIT AI Lab ยุค 1970s — นี่คือการทรยศ

เพื่อนบ้าน hack รั้วบ้านคุณ และคุณไม่มีสิทธิ์แม้แต่จะรู้ว่ารั้วมันสร้างยังไง

Stallman เขียนไว้ในภายหลังว่า:

"ผมบอกตัวเองไม่ได้ว่า non-disclosure agreement มันไม่มีพิษมีภัย"

กำเนิด GNU

27 กันยายน 1983 — Stallman โพสต์ประกาศโครงการ GNU บน Usenet ภายใต้หัวข้อ "new Unix implementation"

"ผมเชื่อว่ากฎทอง (golden rule) กำหนดว่า ถ้าผมชอบโปรแกรมใด ผมต้องแบ่งปันมันกับคนอื่นที่ชอบมันด้วย ผมไม่สามารถเซ็นสัญญาไม่เปิดเผยข้อมูล (NDA) หรือสัญญาอนุญาตซอฟต์แวร์แบบปิด ด้วยจิตสำนึกที่ดีได้"

— Richard Stallman, GNU Initial Announcement, 27 ก.ย. 1983

เป้าหมาย: สร้างระบบปฏิบัติการแบบ Unix ที่ ทุกคนมีอิสระ ในการใช้ แก้ไข และแชร์

ฟรี ไม่ได้แปลว่า gratis (ของฟรี)
ฟรี แปลว่า libre (เสรีภาพ)

— Free Software Foundation

Stallman เริ่มเขียนทีละ component:

GNU Emacs — text editor ในตำนาน (1985)
GCC — GNU C Compiler (1987)
glibc — C library (1988)
Bash — shell ที่เราใช้กันมาจนถึงทุกวันนี้ (1989)
Coreutils, binutils, gdb... ไล่เรียงไปเรื่อย ๆ

ภายในปี 1990 — เกือบทั้งระบบปฏิบัติการพร้อมแล้ว ยกเว้น kernel

Hurd — kernel ที่ไม่มีวันเสร็จ

kernel ที่ GNU เลือกใช้คือ GNU Hurd — ออกแบบด้วยสถาปัตยกรรม microkernel บน Mach (CMU) ที่ทะเยอทะยานเกินยุค

ปัญหาคือ:

รอ Mach เป็น free software — CMU ล่าช้าในการปล่อย source code เพราะฝ่ายกฎหมาย
Multithreaded servers สื่อสารด้วย IPC — "very hard to debug" (คำพูดของ Stallman เอง)
Perfect is the enemy of good — ดีไซน์ซ้ำไปซ้ำมาเพื่อความ "สมบูรณ์แบบ" ทางทฤษฎี
Hurd 0.1 ออกปี 1996 — 6 ปีหลังจากเริ่มพัฒนา
Hurd 0.9 ออกธันวาคม 2016 — ล่าสุด และไม่เคยถึง 1.0

Stallman พูดตรง ๆ:

"GNU Hurd ไม่เหมาะสำหรับ production use และเราไม่รู้ว่ามันจะเหมาะเมื่อไหร่"

เด็กฟินแลนด์กับ kernel ของเขา

25 สิงหาคม 1991 — Linus Torvalds นักศึกษาปี 2 มหาวิทยาลัย Helsinki (อายุ 21 ปี) โพสต์บน Usenet group comp.os.minix:

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.

สังเกตว่า Linus เองก็พอร์ต bash และ gcc — GNU tools — มาตั้งแต่วันแรก

17 กันยายน 1991 — Linux 0.01 ออกสู่สาธารณะ (คนที่ตั้งชื่อว่า "Linux" คือ Ari Lemmke ผู้ดูแล ftp.funet.fi — Linus อยากให้ชื่อ "Freax" แต่ Lemmke ไม่ชอบ)

Linus เขียนใน release notes ของ 0.01:

"Sadly, a kernel by itself gets you nowhere… Most of the tools used with linux are GNU software and are under the GNU copyleft."

"น่าเศร้าที่ kernel อย่างเดียวมันไปไหนไม่ได้... เครื่องมือส่วนใหญ่ที่ใช้กับ linux คือซอฟต์แวร์ GNU"

ทำไม Linux ถึงสำเร็จ

ทั้งที่ Hurd มีคนเก่งกว่า มี philosophy ล้ำกว่า ทำไม Linux ถึงชนะ?

	GNU Hurd	Linux
สถาปัตยกรรม	Microkernel	Monolithic
ออกแบบโดย	นักทฤษฎี OS	"ค่าเทอมถูกกว่า Sun"
ปรัชญา	Perfect from day 1	Release early, release often
ทีม	อาสาสมัคร	ชุมชน (Git แจกตั้งแต่ 2005)

"Release early, release often" — หลักการที่ Linus สอนโลก open source โดยไม่ตั้งใจ

Linux 0.01 (ก.ย. 1991) — ~10,000 บรรทัด
Linux 0.12 (ก.พ. 1992) — เปลี่ยนไปใช้ GPL — นี่คือจุดเปลี่ยนสำคัญ
Linux 1.0 (มี.ค. 1994) — 176,250 บรรทัด
Linux 6.x (2024) — เกิน 30 ล้านบรรทัด

GNU + Linux = ?

เมื่อ Linux ถือกำเนิด มันขาด userspace tools — shell, compiler, basic utilities

GNU มีของทุกอย่าง — GCC compiler, Bash shell, coreutils

Linux + GNU tools = ระบบปฏิบัติการที่สมบูรณ์ ครั้งแรกที่โลกมี free Unix ทั้งระบบ

"It is due to Linux that we can actually run a version of the GNU system today."

— Richard Stallman

MCC Interim Linux (กุมภาพันธ์ 1992) — ผลงานของ Owen Le Blanc จาก Manchester Computing Centre — คือ distro แรกที่รวม Linux kernel กับ GNU userspace เข้าด้วยกัน ตามด้วย TAMU Linux และ SLS (Softlanding Linux System) ในสิงหาคม 1992

SLS เป็น distro แรกที่คนใช้กันเยอะ... แต่ package management ของมันพังไม่เป็นท่า จนทำให้ Ian Murdock วัย 20 ปี ประกาศบน Usenet ในเดือนสิงหาคม 1993 ว่าจะสร้าง distro ใหม่ที่ "maintained openly, in the spirit of GNU" — distro นั้นคือ Debian

ตามมาด้วย Slackware (กรกฎาคม 1993) ที่พัฒนาโดย Patrick Volkerding — เรียบง่าย ไม่มี dependency resolution แต่ stable จนกลายเป็น distro ที่เก่าแก่ที่สุดที่ยัง maintain อยู่จนถึงทุกวันนี้

เมื่อ Debian เปลี่ยนชื่อเป็น "Debian GNU/Linux" ในต้นปี 1994 ตามคำขอของ Stallman — การถกเถียงเรื่องชื่อก็เริ่มต้นขึ้น

GNU/Linux — การถกเถียงที่ยังไม่จบ

Stallman ยืนกราน: เรียกมันว่า "GNU/Linux" เพราะ:

GNU project เริ่มตั้งแต่ 1983 — 7-8 ปีก่อน Linux
Stallman อ้างอิงตัวเลขจากงานวิจัยภายในของ Red Hat (2001) และ gNewSense (2008) ว่า ใน distro หนึ่ง ๆ: โค้ด GNU ≈ 15-28%, โค้ด Linux kernel ≈ 1.5-3% (ตัวเลขนี้เป็นที่ถกเถียงในชุมชน — วัดยังไงให้นับ "หน่วย" ของโค้ดอย่างเที่ยงตรง)
ถ้าไม่มี GNU — Linus ต้องเขียน compiler, shell, utilities เองทั้งหมด

Linus ตอบกลับ:

"It doesn't really matter what people call Linux, as long as credit is given where credit is due."
— comp.os.linux.misc, 1996

และในหนังสารคดี Revolution OS (2001):

"Calling Linux in general 'GNU Linux' I think is just ridiculous."

แต่ Linus ก็ไม่ได้ดูถูก GNU — ในหนังสืออัตชีวประวัติ Just for Fun (2001) เขาเขียนว่า:

"Richard Stallman is the God of Free Software."

"Stallman, who deserves a monument in his honor for giving birth to the GPL…"

มรดกที่เรายังใช้อยู่ทุกวันนี้

ลองเปิด terminal แล้วพิมพ์:

$ ls --version | head -1
ls (GNU coreutils) 9.x

$ gcc --version | head -1
gcc (GCC) 14.x

$ bash --version | head -1
GNU bash, version 5.x

GNU คือวิญญาณของ Linux — kernel คือหัวใจ แต่ shell, compiler, utilities ที่เราใช้ทุกวันนี้ คือ GNU

ถ้าไม่มีโครงการ GNU: Linus ต้องเขียนทุกอย่างเองตั้งแต่ compiler, linker, shell... และ kernel "งานอดิเรก" ของเขาคงไม่รอด

และถ้าไม่มี Linux: GNU มีเกือบทุกอย่างยกเว้น kernel ที่รันได้จริง — Hurd ก็ยังเป็น prototype มาจนถึงทุกวันนี้

สองโครงการ — หนึ่งปรัชญา หนึ่ง pragmatic — มาบรรจบกันในเวลาที่เหมาะสมพอดี

สำหรับคนที่อยากอ่านเพิ่ม

The GNU Manifesto (1985) — Stallman ต้นฉบับ
The GNU Project — essay ของ Stallman
Linux 0.01 Release Notes — Torvalds, 1991
Linux 0.12 Release Notes (เปลี่ยนไปใช้ GPL) — Torvalds, ก.พ. 1992
Linus โพสต์แรกบน Usenet (25 ส.ค. 1991) — เก็บใน Wayback Machine
Just for Fun — Linus Torvalds autobiography (2001)
Revolution OS — หนังสารคดี open source

📅 สิงหาคม 2026 | ⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน

"iota ใน Go — อักษรกรีกตัวจิ๋วที่กลายเป็นเครื่องมือทรงพลัง"

Gophernment — Sun, 02 Aug 2026 03:53:36 +0000

📅 เขียนเมื่อ: กรกฎาคม 2026
⚠️ ตรวจสอบข้อมูลจาก Go Specification, APL documentation, และบันทึกของผู้พัฒนา

ถ้าคุณเขียน Go มาระยะหนึ่ง คุณคงเคยเห็น iota — เจ้า identifier ประหลาดที่ไม่มีใครรู้ว่ามันคืออะไรตอนเจอครั้งแรก

const (
    Monday = iota + 1  // 1
    Tuesday            // 2
    Wednesday          // 3
)

มันไม่ใช่ keyword, ไม่ใช่ type, ไม่ใช่ function — มันคืออะไรกันแน่?

และที่สำคัญ — ทำไมต้องชื่อ iota?

คำตอบพาเราย้อนกลับไปถึงปี 1962 — ถึงนักคณิตศาสตร์ชาวแคนาดาคนหนึ่ง และภาษาโปรแกรมมิ่งที่เปลี่ยนโลก

iota คืออะไรใน Go

ใน Go spec — iota คือ predeclared identifier ที่ใช้ เฉพาะใน const declaration เท่านั้น

มันทำสิ่งเดียว: นับเลขให้อัตโนมัติ

const (
    _ = iota          // 0 (skip)
    KB = 1 << (10 * iota)  // 1 << 10 = 1024
    MB                    // 1 << 20 = 1,048,576
    GB                    // 1 << 30
)

ค่า iota เริ่มที่ 0 และเพิ่มทีละ 1 ทุกครั้งที่เจอบรรทัดใหม่ใน const block — แม้ว่าบรรทัดนั้นจะไม่ได้ใช้ iota ก็ตาม

สิ่งที่ทำให้ iota ทรงพลังคือมันเป็น expression (ไม่ใช่แค่ตัวเลข) — คุณเอาไปคูณ บวก ลบ shift ได้หมด

const (
    Read    = 1 << iota  // 1 << 0 = 1
    Write                 // 1 << 1 = 2
    Execute               // 1 << 2 = 4
)

นี่คือวิธีมาตรฐานในการสร้าง enum, bitmask, และ constant series ใน Go — ทั้งหมดด้วย keyword เดียว

iota — อักษรกรีกตัวเล็กที่สุด

ก่อนจะเป็นชื่อใน Go — ιώτα (iota) คืออักษรตัวที่ 9 ของกรีกโบราณ: ι

มันคืออักษรที่ เล็กที่สุด ในภาษากรีก — แค่เส้นตรงหนึ่งเส้น ไม่มีหาง ไม่มีขีด

ในพระคัมภีร์ไบเบิล มีวลี famous: "not one iota" — แปลว่า "ไม่แม้แต่นิดเดียว" — เพราะ iota คือสิ่งที่เล็กที่สุด

และมันคือชื่อที่สมบูรณ์แบบสำหรับสิ่งที่ "เพิ่มทีละหนึ่ง"

จุดเริ่มต้น — APL และ Kenneth Iverson

นักคณิตศาสตร์ผู้สร้างภาษา

ปี 1962 — Kenneth E. Iverson ตีพิมพ์หนังสือ "A Programming Language" (ที่มาของชื่อ APL)

Iverson เป็นนักคณิตศาสตร์ชาวแคนาดา (ต่อมาได้ Turing Award ปี 1979) — เขาไม่ได้แค่ออกแบบภาษาใหม่ แต่ปฏิวัติวิธีคิดเรื่อง programming

แทนที่จะเขียน for i = 1 to 10 — Iverson คิดว่า programming ควรเหมือนคณิตศาสตร์: สั้น, สัญลักษณ์, และทรงพลัง

เกิดเป็น ⍳ (iota)

ใน APL, Iverson สร้าง operator ⍳ — เรียกว่า iota — ที่ทำสิ่งเดียว: สร้างลำดับเลข

⍳5    →  1 2 3 4 5
⍳10   →  1 2 3 4 5 6 7 8 9 10

(เชื่อกันว่าใน APL ดั้งเดิม ใช้ตัวอักษรกรีก ι จริง ๆ — Iverson notation ยุค 1957 ใช้สัญลักษณ์คณิตศาสตร์แบบกรีก ก่อนที่ APL จะพัฒนาชุดอักขระเฉพาะของตัวเอง จนได้สัญลักษณ์ ⍳ ที่เราเห็นใน APL สมัยใหม่)

ทำไมต้องชื่อ iota? — Iverson เลือกเพราะมันคือ อักษรที่เล็กที่สุด → เหมาะกับ operator ที่สร้าง "สิ่งที่เล็กที่สุด" (integer unit)

ปรัชญาของ Iverson: โปรแกรมมิ่งคือภาษาสำหรับ คิด — ไม่ใช่แค่ภาษาสำหรับ บอกคอมพิวเตอร์ให้ทำงาน

APL พิสูจน์ว่า: โค้ดหนึ่งบรรทัดที่เต็มไปด้วยสัญลักษณ์ประหลาด สามารถทำสิ่งที่ภาษาอื่นใช้ 50 บรรทัด

และ ⍳ (iota) คือหัวใจของแนวคิดนี้ — สร้างลำดับจากความว่างเปล่า ด้วยสัญลักษณ์เดียว

สิ่งที่ APL iota ทำได้ — มากกว่าแค่นับเลข

APL iota ไม่ได้สร้างแค่ 1 2 3 — มันสร้างได้ทุกมิติ:

⍳3 3   →  matrix 3×3 ของเลข 1..9
⍳2 3 4 →  array 3 มิติ

และเมื่อรวมกับ operator ตัวอื่นของ APL — ⍳ กลายเป็นอาวุธที่ทรงพลังอย่างไม่น่าเชื่อ:

+/⍳100   →  5050   (ผลรวม 1..100 — ใน 4 ตัวอักษร)

+/⍳100 — สี่ตัวอักษร คำนวณผลรวม 1 ถึง 100 — โค้ดที่ภาษาอื่นต้องใช้ loop

นี่คือเหตุผลที่ APL ถูกเรียกว่า "ภาษาโปรแกรมมิ่งที่ทรงพลังที่สุดต่อจำนวนตัวอักษร"

จาก APL สู่ Bell Labs — เส้นทางของ iota

Ken Thompson กับ APL

ช่วงปลายยุค 60 — Ken Thompson (ผู้สร้าง Unix) เป็นคนหนึ่งที่หลงรัก APL

เขาเขียน APL interpreter ด้วยตัวเอง — เช่นเดียวกับสมาชิกทีม Go อีกสองคน (Rob Pike และ Robert Griesemer) ที่ต่างคนต่างเคยเขียน APL interpreter มาก่อนเช่นกัน นี่คือจุดร่วมสำคัญที่ทำให้ทั้งสามคน "พูดภาษาเดียวกัน" เมื่อถึงเวลาออกแบบ Go

มีบันทึกว่า Thompson เคยพูดว่า APL เป็นหนึ่งในแรงบันดาลใจสำคัญในการออกแบบ Unix philosophy — "ทำสิ่งเดียวแต่ทำให้ดี"

เขาไม่ได้เอา APL syntax มาใช้ (Unix กับ Go ต่างจาก APL คนละขั้ว) — แต่เขาเอา วิธีคิด มา: abstraction ที่ทรงพลัง, ความกระชับ, และความงามทางคณิตศาสตร์

Bell Labs — แหล่งรวมคนที่รู้จัก iota

Bell Labs ช่วงยุค 70-80 คือสถานที่ที่รวมตัวนักคณิตศาสตร์-โปรแกรมเมอร์ที่เข้าใจ APL:

Ken Thompson — ผู้สร้าง Unix, เขียน APL interpreter เอง
Rob Pike — โตมาในยุคที่ APL เป็นตำนาน, เขียน APL interpreter เอง
Robert Griesemer — ผู้ร่วมสร้าง Go, ก็เขียน APL interpreter ด้วยตัวเองเช่นกัน

นี่คือเหตุผลที่แท้จริงที่ทำให้ชื่อ iota รู้สึก "ใช่" สำหรับทั้งทีม — ไม่ใช่แค่คนใดคนหนึ่งเสนอแล้วคนอื่นพยักหน้าตาม แต่ทั้งสามคนเข้าใจว่ามันคืออะไรและมาจากไหน

ทุกคนในทีมที่สร้าง Unix, Plan 9, และต่อมา Go — รู้ว่า iota คืออะไรและมาจากไหน

แนวคิด "sequence generator" ในตระกูล Unix

ระหว่างทางจาก APL สู่ Go — แนวคิด iota ไม่ได้หายไป:

C language (1972): enum — สร้าง constant sequence ได้ แต่ต้องประกาศชื่อ
Plan 9 C: ปรับปรุง enum ให้ cleaner ขึ้น
Limbo (Inferno OS): constant declaration ที่ใกล้เคียง Go มากขึ้น

Pike และทีมเห็นว่า — การสร้าง enum/constant series ใน C น่าเบื่อและ verbose — ต้องเขียนเลขเองทุกบรรทัด

// C — ต้องเขียนเลขเอง
enum {
    READ  = 1 << 0,
    WRITE = 1 << 1,
    EXEC  = 1 << 2,
};

เมื่อถึงเวลาออกแบบ Go — Pike รู้ดีว่าต้องมีอะไรดีกว่านี้

iota ใน Go — เกิดได้ยังไง

ปัญหาที่ต้องแก้

ทีม Go (Pike, Thompson, Griesemer) เริ่มออกแบบ Go ในปี 2007 — หนึ่งในเป้าหมายคือ: "ทำทุกอย่างให้ง่ายกว่า C"

constant declaration ใน C/C++ เป็นหนึ่งใน pain point:

ต้องเขียนค่าให้ทุก constant — แม้มันจะ predictable
enum กับ #define อยู่คนละโลก
bitmask/enum pattern ทำซ้ำซาก

ทีมต้องการอะไรที่:

กระชับ — ไม่ต้องเขียนเลขซ้ำ
flexible — ใช้กับ expression ได้ ไม่ใช่แค่ +1
ไม่ใช่ magic — อ่านแล้วเข้าใจทันทีว่าเกิดอะไรขึ้น

ตัวเลือกที่ทีมไม่เอา

Auto-increment แบบ enum — ใช้ได้แค่ +1, ทำ bitmask ไม่ได้
Preprocessor macro — Go ไม่มี preprocessor (ตั้งใจ)
Code generation — ซับซ้อนเกินสำหรับของง่าย ๆ

iota — ทางสายกลาง

Pike เสนอ iota — constant generator ที่:

Reset ทุก const block — scope ชัดเจน
เป็น expression — เอาไปคำนวณต่อได้
Reset เมื่อมี const keyword ใหม่ — predictable

const (
    _  = iota             // 0
    KB = 1 << (10 * iota)  // 1 << 10 = 1024
    MB                     // 1 << 20
    GB                     // 1 << 30
)

ส่วนชื่อ — ไม่ต้องคิดนาน: มันคือการยกย่อง (homage) ให้ APL — ภาษาที่สร้างแรงบันดาลใจให้กับคนสร้าง Unix, Plan 9, และ Go

วิธีใช้ iota แบบต่าง ๆ

1. Enum พื้นฐาน

type Season int

const (
    Spring Season = iota  // 0
    Summer                // 1
    Autumn                // 2
    Winter                // 3
)

2. Bitmask

type Permission uint8

const (
    Read    Permission = 1 << iota  // 1
    Write                           // 2
    Execute                         // 4
    Admin                           // 8
)

// ใช้:
var perm Permission = Read | Write  // 3

3. Skip values

const (
    _ = iota          // 0 (skip)
    Monday            // 1
    Tuesday           // 2
    Wednesday         // 3
    Thursday          // 4
    Friday            // 5
    Saturday          // 6
    Sunday            // 7
)

4. Multiple expressions ในบรรทัดเดียวกัน

const (
    bit0, mask0 = 1 << iota, 1<<iota - 1  // 1, 0
    bit1, mask1                           // 2, 1
    bit2, mask2                           // 4, 3
)

5. Jump pattern

const (
    a = iota * 2    // 0
    b               // 2
    c               // 4
    d               // 6
)

ทำไม iota ถึง "ใช่" สำหรับ Go

1. Philosophy match

Go มีหลักการ "หนึ่งวิธีที่ดีที่สุด" (one way to do it) — ต่างจาก Python ("หลายวิธีก็ดี") และ C++ ("มีทุกวิธี")

iota คือ "หนึ่งวิธี" ในการสร้าง enum/constant series — ใน Go คุณไม่ต้องเลือกว่าจะใช้ #define, enum, หรือ constexpr — มีแค่ iota

2. Zero cost abstraction

iota ไม่มี overhead — มันถูก resolve ตอน compile — runtime ไม่รู้ด้วยซ้ำว่ามี iota อยู่

3. Readability

เมื่อคุณเห็น iota — คุณรู้ทันทีว่า "อ๋อ ชุดนี้เป็นลำดับ"

const (
    Info = iota
    Warning
    Error
)

vs C:

enum {
    INFO = 0,
    WARNING,
    ERROR
};

น้อยกว่า — แต่บอกอะไรได้มากกว่า

4. Connection to history

iota เป็นหนึ่งใน easter egg ที่สวยงามของ Go — มันเชื่อมต่อกับ:

APL (1962) — ต้นกำเนิด
Bell Labs — สถานที่ที่ Thompson, Ritchie, Pike ทำงาน
Unix philosophy — ทำสิ่งเดียวให้ดี

นอกเรื่องนิดหน่อย — iota ในภาษาอื่น

หลังจาก Go ใช้ iota — หลายภาษาเริ่ม implement concept คล้าย ๆ กัน:

Rust: ไม่มี iota โดยตรง แต่ enum + #[repr] + strum crate ให้ความสามารถใกล้เคียง
Zig: enum มี auto-increment แต่ไม่ flexible เท่า iota
Swift: enum รองรับ raw value แต่ต้องระบุ type

ไม่มีใครทำได้สะอาดเท่า Go — เพราะไม่มีใครกล้าใช้ชื่อ iota (หรืออาจเพราะไม่มีใครรู้ว่ามันคืออะไร)

สิ่งที่ iota สอนเรา

ชื่อดีเปลี่ยนทุกอย่าง

iota ใน Go ทำแค่ auto-increment — เหมือน __COUNTER__ ใน C, enumerate ใน Python

แต่เพราะชื่อมัน — iota กลายเป็นมากกว่า feature: มันคือ เรื่องราว

ทุกครั้งที่โปรแกรมเมอร์ Go สงสัยว่า "iota คืออะไร" — พวกเขาย้อนกลับไปถึง APL, ถึง Kenneth Iverson, ถึง Bell Labs, ถึงประวัติศาสตร์ของภาษาโปรแกรมมิ่ง

และนั่นคือสิ่งที่ภาษาโปรแกรมมิ่งที่ดีทำ — ไม่ใช่แค่แก้ปัญหา แต่ เล่าเรื่อง

สรุป

iota เริ่มจากอักษรกรีกตัวเล็กที่สุด → กลายเป็น operator ใน APL (1962) → ถูกจดจำโดยทีม Bell Labs → และมาอยู่ใน Go ในฐานะ homage ให้กับประวัติศาสตร์ของ programming

มันใช้เวลา 50 ปี — จากแนวคิดทางคณิตศาสตร์ สู่ภาษาโปรแกรมมิ่งที่ใช้ใน production ทั่วโลก

และทั้งหมดเริ่มจากสัญลักษณ์เดียว: ι

// 50 ปีของการเดินทาง — ใน 4 บรรทัด
const (
    APL    = iota  // 1962
    Unix           // 1969
    Go             // 2009
)

ที่มา: Go Language Specification, "A Programming Language" โดย Kenneth Iverson (1962), Rob Pike's talks on Go design, Bell Labs oral history, APL Wiki

"Plan 9 — ระบบปฏิบัติการที่โลกลืม แต่เปลี่ยนวิธีคิดเรื่อง OS ไปตลอดกาล"

Gophernment — Sun, 02 Aug 2026 03:38:26 +0000

📅 เขียนเมื่อ: กรกฎาคม 2026
⚠️ อ้างอิงจากเอกสารต้นฉบับของ Bell Labs และบันทึกของผู้พัฒนา

ถ้าผมถามว่า "ระบบปฏิบัติการที่เจ๋งที่สุดในโลกคืออะไร" — คุณคงตอบ Linux, macOS, หรือ Windows

แต่ถ้าถาม Ken Thompson และ Dennis Ritchie — สองคนที่สร้าง Unix ขึ้นมา — พวกเขาจะตอบว่า Plan 9

Plan 9 คือระบบปฏิบัติการที่ Bell Labs สร้างขึ้นในช่วงปลายยุค 80 ถึงต้นยุค 90 โดยทีมเดียวกับที่สร้าง Unix แต่มันไม่ใช่แค่ "Unix เวอร์ชันใหม่" — มันคือการเริ่มต้นใหม่ทั้งหมด

และถึงแม้วันนี้แทบไม่มีใครใช้ Plan 9 — แนวคิดของมันแทรกซึมอยู่ในทุกระบบปฏิบัติการที่คุณใช้อยู่

จุดเริ่มต้น — "Unix เริ่มแก่แล้ว"

ปัญหาที่ Unix สะสมมา

Unix เกิดในปี 1969 — ตอนนั้นคอมพิวเตอร์คือเครื่องเดียวที่มี terminal ต่อพ่วง

พอยุค 80 มาถึง โลกเปลี่ยน — network กลายเป็นเรื่องปกติ, graphics เริ่มสำคัญ, distributed computing เริ่มเกิด

แต่ Unix ไม่ได้ถูกออกแบบมาเพื่อสิ่งเหล่านี้ มันถูก patch, extend, retrofit — จนกลายเป็นระบบที่ซับซ้อนเกินกว่าที่ผู้สร้างจะภูมิใจ

Ken Thompson เคยพูดประมาณว่า: "Unix เริ่มต้นด้วยความเรียบง่าย แต่มันค่อย ๆ สะสมความซับซ้อนเข้าไปเรื่อย ๆ — ถึงเวลาที่ต้องเริ่มใหม่"

ทำไมต้องชื่อ Plan 9

ชื่อ "Plan 9" มาจากหนัง B-movie สุดคลาสสิกเรื่อง "Plan 9 from Outer Space" (1959) ของ Ed Wood — ที่ได้ชื่อว่าเป็น "หนังที่แย่ที่สุดตลอดกาล"

แต่ชื่อนี้ไม่ได้หมายความว่า OS นี้แย่ — มันคือมุกวงในของทีม Bell Labs ที่ชอบตั้งชื่อแปลก ๆ (Unix เองก็เป็นมุก — มันล้อ Multics)

หัวใจของ Plan 9 — "ทุกอย่างคือไฟล์" จริง ๆ

จาก Unix สู่ Plan 9 — ทำให้สุดทาง

Unix มีแนวคิด famous: "everything is a file"

filesystem เป็นไฟล์ → /home/user/document.txt
devices เป็นไฟล์ → /dev/sda, /dev/tty
processes เป็นไฟล์ → /proc/1234

แต่มันมีข้อยกเว้น — network sockets, graphics, window system — สิ่งเหล่านี้ไม่ใช่ไฟล์ใน Unix

Plan 9 เอาแนวคิดนี้ไป สุดทาง — ใน Plan 9, ทุกอย่างคือไฟล์ ไม่มีข้อยกเว้น

9P — โปรโตคอลเดียวที่เชื่อมทุกอย่าง

หัวใจของ Plan 9 คือ 9P — โปรโตคอลที่ทำให้ทุกอย่างสื่อสารกันผ่าน filesystem

หน้าต่าง GUI → mount เป็นไฟล์
network connection → mount เป็นไฟล์  
เครื่องอื่นใน network → mount เป็นไฟล์

ลองนึกภาพ: คุณ ls ดูไฟล์ในเครื่องคนอื่นได้เหมือนกับเป็น local disk — โดยไม่ต้องใช้ NFS, Samba, หรืออะไรซับซ้อนเลย

ตัวอย่างจริง: ถ้าผมเปิดหน้าต่าง editor (acme) ใน Plan 9 — หน้าต่างนั้นคือไฟล์ใน /mnt/acme/ คุณสามารถ echo "hello" > /mnt/acme/body แล้วข้อความก็จะไปโผล่ใน editor ทันที

GUI ของ Plan 9 ไม่ใช่ "โปรแกรมที่วาดรูปบนจอ" — มันคือ "filesystem ที่บังเอิญแสดงผลเป็นกราฟิกได้"

Namespace — มุมมองส่วนตัวของทุก process

ใน Linux, ทุก process มองเห็น filesystem เดียวกัน

ใน Plan 9, แต่ละ process มี namespace ของตัวเอง — คุณสามารถ mount, unmount, และจัดเรียง filesystem ใหม่ได้โดยไม่กระทบ process อื่น

Process A: /bin → /usr/local/bin
Process B: /bin → /remote/machine/bin

สอง process นี้เห็น filesystem คนละชุด — แต่รันอยู่บนเครื่องเดียวกัน

แนวคิดนี้คือต้นกำเนิดของ Linux namespaces ที่ใช้ใน Docker และ container ทุกวันนี้

ชีวิตใน Plan 9 — หน้าตาเป็นยังไง

Rio — หน้าต่างที่ไม่มี title bar

Rio คือ window system ของ Plan 9 — และมัน minimal สุด ๆ

ไม่มี taskbar, ไม่มี desktop icons, ไม่มี minimize button — มีแต่หน้าต่างที่คุณจัดการด้วยเมาส์ 3 ปุ่ม

ปุ่มซ้าย = เลือกข้อความ
ปุ่มกลาง = execute (รันข้อความที่เลือก)
ปุ่มขวา = เมนู (New, Resize, Delete ฯลฯ)

ลองนึกภาพการใช้งานจริง:

คุณเปิดหน้าต่าง terminal ขึ้นมา — พิมพ์ ls -la — ผลลัพธ์โผล่ในหน้าต่าง คุณใช้ปุ่มซ้ายลากเลือกชื่อไฟล์ที่สนใจ → กดปุ่มกลาง → Plan 9 เอาไฟล์นั้นมาเป็น argument ให้คำสั่งถัดไปโดยอัตโนมัติ

หรือใน editor: คุณพิมพ์ man 9p ใน buffer → ลากคลุม → ปุ่มกลาง → หน้าต่าง man page โผล่ขึ้นมาทันที

ไอเดียคือ: คุณไม่ต้อง copy-paste — คุณแค่เลือกแล้ว execute ทุกอย่างที่เลือกคือ command ได้หมด

นี่คือ UX ที่ต่างจากสิ่งที่เราใช้ทุกวันนี้โดยสิ้นเชิง — ไม่มี clipboard, ไม่มี Ctrl-C/Ctrl-V — แต่เมื่อคุณชินแล้ว มันเร็วและ natural กว่ามาก

Acme — editor ที่เป็นมากกว่า editor

Acme คือ text editor ในตำนานที่ Rob Pike สร้าง — และมันก็คือ "หน้าต่างที่ควบคุมด้วยเมาส์แบบ hypertext"

ทุกคำใน Acme เป็น clickable link
คุณพิมพ์คำสั่ง shell ลงไปใน buffer แล้วคลิก execute ได้เลย
ไฟล์ทุกไฟล์ที่เปิดอยู่คือหน้าต่างที่จัดการได้ด้วย mouse gesture

Acme ดู primitive สำหรับยุคนี้ — แต่มันคือต้นแบบของ IDE สมัยใหม่: code + terminal + file browser อยู่ในหน้าต่างเดียวกัน

Plumbing — messsage bus ก่อนจะมี D-Bus

Plumbing คือระบบส่งข้อความระหว่างโปรแกรมใน Plan 9

คุณ click ที่ URL → มันส่งไปให้ browser
คุณ click ที่ error message → มันเปิดไฟล์ไปที่บรรทัดนั้น

ทุกอย่างเชื่อมกันด้วยไฟล์ — และ plumbing ก็คือไฟล์พิเศษที่อ่านเขียนข้อความได้

มรดกของ Plan 9 — สิ่งที่อยู่รอดมาจนถึงวันนี้

1. UTF-8 — เกิดบนกระดาษรองจานในร้านอาหารแห่งหนึ่ง

คืนหนึ่งในปี 1992 — Ken Thompson กับ Rob Pike นั่งกินข้าวที่ร้านอาหารสไตล์ diner แห่งหนึ่งใน New Jersey

พวกเขาคุยกันเรื่องปัญหาที่โลกคอมพิวเตอร์มี encoding เป็นร้อย ๆ แบบ — ASCII, Latin-1, Shift-JIS — แต่ละตัวใช้กับภาษาเดียว

ทั้งคู่หยิบกระดาษรองจานขึ้นมา แล้วออกแบบ UTF-8 — encoding ที่ backward compatible กับ ASCII และรองรับทุกภาษาในโลก

วันนี้ UTF-8 ใช้ใน 98% ของเว็บทั้งโลก

และมันถูกออกแบบระหว่างการพัฒนา Plan 9 — โดยคนของ Plan 9

2. `/proc` filesystem — เกิดใน Unix แต่ Plan 9 ทำให้มันเป็นอย่างที่เราใช้

Linux users รู้จัก /proc — filesystem ที่เก็บข้อมูล process:

cat /proc/cpuinfo    # ดู CPU
cat /proc/meminfo    # ดูหน่วยความจำ

/proc เกิดครั้งแรกใน Unix รุ่น 8 (1984) โดย Tom Killian — ผู้เขียน paper "Processes as Files" ที่นำเสนอใน USENIX เดือนมิถุนายน 1984 ซึ่งเกิดก่อน Plan 9 จะเริ่มพัฒนาด้วยซ้ำ

แต่ /proc ใน Unix 8 เป็นแบบ flat — หนึ่ง process = หนึ่งไฟล์

Plan 9 คือคนที่พัฒนาแนวคิดนี้ต่อไป — ทำให้แต่ละ process เป็น directory ที่มีหลายไฟล์ย่อย (ใช้ ls ดู, cat อ่านค่าต่าง ๆ ได้) — กลายเป็น hierarchical /proc แบบที่เราใช้กันทุกวันนี้

Linux สืบทอด hierarchical model นี้มาจาก Plan 9 — และทุกวันนี้ /proc กลายเป็นมาตรฐาน

3. Linux Namespaces — Container ทั้งหมดมีรากจาก Plan 9

Docker, Kubernetes, container ทั้งหมด — ใช้ Linux namespaces ในการแยก process

แนวคิด "แต่ละ process มีมุมมองของระบบที่แตกต่างกัน" — เกิดใน Plan 9

พูดให้เห็นภาพ: Plan 9 คิดเรื่อง per-process namespace ตั้งแต่ปลายยุค 80 — ส่วน Linux namespaces ที่เป็นรากฐานของ Docker และ container ทั้งหมด เพิ่งมาใน kernel ราวปี 2008 หรือเกือบ 20 ปีให้หลัง

4. Go — ภาษาโปรแกรมที่สืบทอด DNA จาก Plan 9

Go ถูกสร้างโดย Rob Pike, Ken Thompson, และ Robert Griesemer — สามคนที่เคยทำงานบน Plan 9

และ Go ก็เต็มไปด้วยแนวคิดจาก Plan 9:

Goroutines — lightweight threads → ต้นแบบคือ lightweight processes ของ Plan 9
Channels — สื่อสารด้วยการส่งข้อความ → ต้นแบบคือ 9P และ plumbing
Gofmt — ทุกคนเขียนโค้ดหน้าตาเหมือนกัน → ต้นแบบคือ philosophy "หนึ่งวิธีที่ดีที่สุด" ของ Plan 9
Static binary — compile เป็นไฟล์เดียว → ต้นแบบคือ Plan 9 binaries

Go คือ Plan 9 ในร่างของภาษาโปรแกรม

ทำไม Plan 9 ถึงไม่รุ่ง

ปัญหาที่แก้ไม่ได้

Chicken-and-egg problem — ไม่มี applications เพราะไม่มี users → ไม่มี users เพราะไม่มี applications
Licensing — ยุค 90 Bell Labs ถูกขายต่อหลายมือ (AT&T → Lucent → ...) ทำให้ license ของ Plan 9 ซับซ้อน
Linux ชนะไปแล้ว — ตอน Plan 9 เริ่ม stable (กลางยุค 90), Linux กำลังโตเร็วและมี ecosystem ใหญ่กว่า
Hardware support — Plan 9 รองรับ hardware น้อยมาก เทียบกับ Linux/Windows

แต่ปัญหาหลักคือ: Plan 9 ไม่ได้พยายามจะ "ดีกว่า Unix นิดหน่อย" — มันพยายามจะ "ใหม่หมด"

และโลกไม่พร้อมจะเปลี่ยน OS ทั้งระบบเพื่อไอเดียใหม่ ๆ — ถึงแม้ไอเดียเหล่านั้นจะดีกว่า

Plan 9 ในปี 2026

Plan 9 ยังมีชีวิตอยู่ — ในรูปแบบของ 9front (community fork) และ Plan 9 from User Space (port ของ tools บน Linux/macOS)

มีกลุ่ม enthusiasts ที่ใช้ Plan 9 เป็น daily driver — เล็ก แต่บ้าพลัง

และทุก concept ที่ Plan 9 เคยคิด — ถูก implement ใหม่ใน Linux ในอีก 20 ปีต่อมา

สิ่งที่ Plan 9 สอนเรา

"แนวคิดที่ดีไม่ได้แปลว่าจะชนะ — แต่มันจะถูกขโมย"

Plan 9 ล้มเหลวในฐานะผลิตภัณฑ์ — แต่ชนะในฐานะแนวคิด

ทุก container ที่รันอยู่บน Kubernetes...
ทุก UTF-8 byte ที่ส่งผ่าน network...
ทุก Go routine ที่ทำงานอยู่บน cloud...

ทั้งหมดมี DNA ของ Plan 9 อยู่ในนั้น

ที่มา: Bell Labs Technical Journal, Plan 9 manual pages, Rob Pike's personal blog (herpolhode.com), 9fans.net, Wikipedia

Russ Cox — คนที่ทำให้ Go เป็น ecosystem ไม่ใช่แค่ภาษา

Gophernment — Fri, 31 Jul 2026 03:09:23 +0000

📅 กรกฎาคม 2026
⚠️ อ้างอิงจากแหล่งปฐมภูมิ ตรวจสอบแล้ว — แต่เช็คข้อมูลล่าสุดก่อนแชร์

ถ้า Pike, Thompson, และ Griesemer คือคนสร้าง Go

Russ Cox คือคนที่ทำให้ Go โตจากภาษาใน Google เป็น ecosystem ที่คนทั้งโลกใช้ เขาเป็นคนเขียน gofmt คนออกแบบ Go modules คนคิด Minimal Version Selection algorithm คนเขียน compatibility promise และปัจจุบันเป็น Go tech lead — คนที่ตัดสินใจว่า Go จะไปทางไหนต่อ

ทุกครั้งที่คุณพิมพ์ go build แล้วมันทำงานในไม่กี่วินาที นั่นคือ Cox

เด็ก Plan 9 จาก MIT

ตอนที่เพื่อนวัยเดียวกันใช้ Windows หรือ Mac Russ Cox ใช้ Plan 9 — ระบบปฏิบัติการที่ Rob Pike, Ken Thompson, และ Dennis Ritchie สร้างที่ Bell Labs

เขาใช้มันเป็นระบบปฏิบัติการหลักทุกวัน

ตอนเรียน MIT Cox ทำงานกับ Pike โดยตรงในโปรเจกต์ Plan 9 ร่วมเขียน paper "Security in Plan 9" (USENIX 2002) ทั้งที่ยังเป็นนักศึกษา

แต่พอเว็บเริ่มสำคัญ Plan 9 ไม่มีเว็บเบราว์เซอร์ที่ใช้งานได้

แทนที่จะย้ายไปใช้ OS อื่น Cox ทำสิ่งที่ programmer ดี ๆ จะทำ: port Plan 9 ทั้งระบบมาที่ Unix

plan9port คือ Plan 9 userspace ที่รันบน Linux และ macOS คุณสามารถใช้ acme editor, sam editor, rc shell, plumber — เครื่องมือทั้งหมดของ Plan 9 — บนเครื่องธรรมดา

Cox ใช้ Acme เป็น editor หลักทุกวัน มาจนถึงทุกวันนี้

นี่คือจุดที่ Pike สังเกตเห็นเขา "เด็กคนนี้เข้าใจ Plan 9 ดีพอที่จะ port มันมาทั้งระบบ"

Google Code Search และ RE2

Cox ฝึกงานที่ Google ระหว่างเรียนปริญญาเอกที่ MIT

งานที่ทำให้เขาเป็นที่รู้จักคือ RE2 — regular expression engine ที่เขาเขียนให้ Google Code Search

ปัญหาของ regex engine ทั่วไปคือ catastrophic backtracking: บาง pattern ใช้เวลาค้นหาเป็นนาที, ชั่วโมง, หรือพังเลย เพราะ algorithm แบบ backtracking มี worst-case ที่ exponential

Cox ใช้ automata theory จากงานวิจัยของเขา ออกแบบ RE2 ที่การันตี linear time เสมอ ไม่ว่า pattern จะซับซ้อนแค่ไหน

RE2 ถูกใช้ใน production ที่ Google ตั้งแต่ปี 2006 — Google Code Search, Google Sheets, และต่อมาเป็น regexp package ใน Go standard library

เขาเขียนบทความสามตอนที่กลายเป็น reference ของวงการ regex: "Regular Expression Matching Can Be Simple And Fast", "Regular Expression Matching: the Virtual Machine Approach", "Regular Expression Matching in the Wild"

2008 — Pike ชวนเข้าร่วมทีม Go

Cox กำลังจะจบปริญญาเอกที่ MIT (วิทยานิพนธ์ "An Extension-Oriented Compiler") ตอนที่ Pike มาชวน

Pike พูดว่า: "เราพยายามเอาทุกอย่างที่เรารักเกี่ยวกับการพัฒนา software บน Plan 9 มาทำให้มันใช้ได้กับการเขียน software ที่เราอยากเขียนที่ Google นายอยากช่วยไหม"

Cox ตอบ: "Yeah, of course"

เขากลายเป็น member คนที่ 4 ของทีม Go — ต่อจาก Pike, Thompson, Griesemer

gofmt — โปรเจกต์แรก

งานแรกของ Cox ในทีม Go คือ gofmt

ธันวาคม 2009 เขาเขียน blog post ประกาศ gofmt — เครื่องมือที่ format โค้ด Go ให้หน้าตาเหมือนกันหมดโดยอัตโนมัติ

ฟังดูเป็นเรื่องเล็ก แต่ gofmt คือหนึ่งในการตัดสินใจที่ฉลาดที่สุดในประวัติศาสตร์ Go

ก่อน gofmt ทีม Go เสียเวลาเถียงกันเรื่อง style ว่า bracket ควรอยู่บรรทัดเดียวกับ if หรือบรรทัดใหม่ indent ควรเป็น tab หรือ space ควรเว้นวรรคหลัง comma ไหม

หลัง gofmt ปัญหานี้หายไปตลอดกาล

ทุกวันนี้ทุกโปรเจกต์ Go ในโลกหน้าตาเหมือนกัน ไม่ว่าคุณจะอ่านโค้ดของ Google, ของ startup, หรือของ open source contributor

`go` command — คุณใช้มันทุกวันโดยไม่เคยคิดถึงมัน

Cox เป็นคนออกแบบ go command — go build, go test, go get — ทั้งหมดที่คุณพิมพ์ทุกวัน

แต่ผลงานที่เปลี่ยน Go ไปตลอดกาลคือ Go modules

Go Modules — จุดเปลี่ยนของ Go ecosystem

ก่อน Go 1.11 การจัดการ dependency ใน Go คือหายนะ

go get ดึงโค้ดจาก version control โดยตรง ไม่มี versioning ไม่มี lock file Dependency ของโปรเจกต์หนึ่งอาจ silently upgrade แล้วพังโปรเจกต์อีกโปรเจกต์

กุมภาพันธ์ 2018 Cox เปิดตัว vgo — prototype ของ Go modules ที่เขาเขียนคนเดียว

แล้วเขาก็ทำสิ่งที่แทบไม่มีใครทำ: เขียน blog post 10 ตอนอธิบายการตัดสินใจทุกอย่าง

ทำไมต้อง semantic import versioning
Minimal Version Selection คืออะไร และทำไมมันดีกว่า SAT solving แบบ npm
reproducible builds ทำงานยังไง
หลักการของ versioning ใน Go

Minimal Version Selection (MVS) เป็น algorithm ที่ Cox คิดขึ้นมาเอง แทนที่จะพยายามหา "best possible combination" ของ dependency versions แบบ npm (ซึ่งใช้ SAT solver และใช้เวลานานมาก) MVS เลือก version ต่ำสุดที่ satisfy requirement ของทุก module

ผลลัพธ์: go mod tidy ทำงานใน 2 วินาที แทนที่จะ resolve dependency tree เป็นนาที

Go modules กลายเป็นมาตรฐานใน Go 1.13 และเป็น default ใน Go 1.16

Go Compatibility Promise — โค้ด 10 ปี compile ได้

สิงหาคม 2023 Cox เขียน blog post "Backward Compatibility, Go 1.21, and Go 2"

ประโยคเปิดของ post นั้นกลายเป็นคำขวัญของ Go:

"Boring is good. Boring is stable. Boring means being able to focus on your work, not on what's different about Go."

Cox เป็นคน maintain compatibility promise ของ Go review ทุก change ที่อาจ break backward compatibility

ลองนึกถึงภาษาอื่นที่โค้ดปี 2012 ไม่สามารถ compile ด้วย compiler ปี 2026 ได้โดยไม่ต้องแก้

Go ทำได้ เพราะ Cox และทีมทุ่มเทให้ compatibility เป็นพระเจ้า

Transparent Decision-Making

สิ่งที่ Cox เปลี่ยนวิธีทำงานของทีม Go ไม่ใช่แค่โค้ด แต่คือ กระบวนการ

เขาเป็นคนออกแบบ Go proposal process — ทุกการเปลี่ยนแปลงใหญ่ต้องผ่าน proposal สาธารณะบน GitHub พร้อม design doc ที่อธิบายปัญหา, ทางเลือก, และเหตุผล

เขาเขียน blog post 6 ตอนอธิบายกระบวนการนี้: "Clarity & Transparency", "Large Changes", "Scaling Discussions" "Enabling Experiments", "Representation"

ไม่มี "คนเก่งที่สุดในห้องตัดสินใจ" ทุกการตัดสินใจของ Go ตั้งแต่ Go 1.0 ถึงวันนี้ถูกบันทึกไว้เป็นลายลักษณ์อักษร

นี่คือสิ่งที่ Cox เรียกว่า "language design in the service of software engineering" — การออกแบบภาษาไม่ใช่ศิลปะของอัจฉริยะ แต่เป็นวิศวกรรมที่มีกระบวนการ มีเหตุผล มีบันทึก

ปรัชญา

GitHub bio ของ Cox เขียนว่า: "Go Hacker. Mistake maker."

เขาไม่เคยแกล้งทำเป็นรู้ทุกอย่าง และนั่นคือสิ่งที่น่านับถือที่สุด

ตอนให้สัมภาษณ์ GoTime ปี 2018 เขาพูดถึงความคาดหวังตอนแรก:

"My hope was that maybe a few people would notice, and ideally whatever the next big language to come along would steal the concurrency and the interface ideas from Go, and that would be our tiny little contribution to making programming a little bit better. Obviously, that didn't happen, but I'm okay with how it turned out instead."

"หวังว่าไม่กี่คนจะสังเกตเห็น" — แล้ว Go ก็กลายเป็นภาษาที่ใช้ใน production ทั่วโลก

อีกด้านของ Cox — นักคณิตศาสตร์

Cox ไม่ใช่แค่วิศวกร Go

เขาเป็น President ของ OEIS Foundation (Online Encyclopedia of Integer Sequences) — ฐานข้อมูลลำดับจำนวนเต็มที่ใหญ่ที่สุดในโลก นักคณิตศาสตร์และนักวิทยาศาสตร์คอมพิวเตอร์ใช้ OEIS เป็น reference มาตั้งแต่ปี 1964

ผลงานล่าสุดบน blog ของเขา (2024-2026) ส่วนใหญ่เป็นเรื่อง floating-point formatting — ลงลึกถึงระดับ "Pull a New Proof from Knuth's Fixed-Point Printer" และ "Fast Unrounded Scaling: Proof by Ivy"

เขาใช้ Ivy ภาษา calculator แนว APL ที่ Rob Pike เขียน พิสูจน์ความถูกต้องของ algorithm เชิงคณิตศาสตร์

นี่คือคนที่วันหนึ่งออกแบบ Go modules, อีกวันใช้ formal proof พิสูจน์ว่า floating-point formatter ทำงานถูกต้อง

ผลงานอื่น ๆ

ก่อน Go, Cox มีผลงานอีกมาก:

Vx32 sandboxing system (USENIX 2008)
Vivaldi network coordinate system (SIGCOMM 2004) — ใช้หา latency ระหว่าง node ใน distributed system โดยไม่ต้องวัดทุกคู่
Xoc extensible compiler (ASPLOS 2008)

หลัง Go:

Go Memory Model — เขียนบทความอธิบาย memory model ของ Go และ hardware memory models (2021-2022)
Transparent Telemetry — ระบบเก็บข้อมูลการใช้งาน Go toolchain แบบโปร่งใส (2022)
Coroutines for Go — proposal สำหรับ coroutine ใน Go (กรกฎาคม 2023)
xz backdoor analysis — วิเคราะห์ timeline ของ backdoor ใน xz library (2024)

ทุกวันนี้

Cox ยังเป็น Go tech lead ทำงานที่ Google Cambridge, MA ใช้ Acme editor ทุกวัน

เขียน blog ที่ research.swtch.com อย่างสม่ำเสมอ 150+ บทความและยังเพิ่มขึ้นเรื่อย ๆ

2024-2026: เขียนเรื่อง Go Changes, Go Testing By Example, floating-point formatting series, hash-based bisect debugging, differential coverage

เขาไม่ได้เป็น keynote speaker ที่มีคนดูเป็นหมื่น แต่ทุกครั้งที่เขาเขียนอะไร คนในทีม Go และ community อ่าน

Cox กับโปรแกรมเมอร์ไทย

go mod tidy ที่ทำงานใน 2 วินาที คือ Cox

gofmt ที่ทำให้โค้ดทุกโปรเจกต์หน้าตาเหมือนกัน คือ Cox

Compatibility promise ที่ทำให้โค้ด Go ปี 2012 ยัง compile ได้ในปี 2026 คือ Cox

และวัฒนธรรม "ตัดสินใจแบบโปร่งใส เขียนเหตุผลให้อ่านได้" ที่กลายเป็น DNA ของ Go community

คือสิ่งที่ Cox สร้าง

สรุป

Rob Pike, Ken Thompson, Robert Griesemer คือคนสร้าง Go

แต่ Russ Cox คือคนที่ทำให้มันอยู่รอด

ที่มา: swtch.com/~rsc, research.swtch.com, go.dev/blog, GoTime #77, github.com/rsc, github.com/google/re2, pdos.csail.mit.edu/~rsc

Robert Griesemer — ศิษย์ของ Wirth ผู้เขียน spec ให้ Go และทำให้ generics เป็นจริง

Gophernment — Fri, 31 Jul 2026 03:06:38 +0000

📅 กรกฎาคม 2026
⚠️ ตรวจสอบข้อมูล ณ วันที่เขียน — API และเวอร์ชันอาจเปลี่ยนแปลงภายหลัง

เวลาพูดถึงคนสร้าง Go ทุกคนรู้จัก Rob Pike กับ Ken Thompson

แต่คนที่สามบน whiteboard วันนั้น คนที่เขียน Go specification คนที่ออกแบบ type inference algorithm ให้ Go คนที่ผลักดัน generics ตั้งแต่ proposal จนถึง implementation

เขาไม่ใช่คนที่คุณเห็นบนเวทีบ่อย ๆ ไม่มี Twitter ไม่ใช่หน้าเป็นข่าว

Robert Griesemer

ศิษย์ของ Niklaus Wirth

Griesemer เกิดปี 1964 ที่สวิตเซอร์แลนด์ จบปริญญาเอกจาก ETH Zurich หนึ่งในมหาวิทยาลัยวิศวกรรมที่ดีที่สุดในยุโรป

อาจารย์ที่ปรึกษาของเขาคือ Hanspeter Mössenböck ภายใต้การดูแลของ Niklaus Wirth — ผู้สร้างภาษา Pascal, Modula, และ Oberon

ถ้าคุณเคยเขียน Pascal ตอนเรียนมหาวิทยาลัย คุณใช้ภาษาที่ Wirth ออกแบบ Wirth ได้รับ Turing Award ปี 1984 จากผลงานการออกแบบภาษาโปรแกรมมิ่งทั้งตระกูล

Griesemer เติบโตมาในโรงเรียนแห่งนี้ วิทยานิพนธ์ปริญญาเอกของเขาชื่อ "A programming language for vector computers" (1993) เน้นการออกแบบภาษาให้กับฮาร์ดแวร์เฉพาะทาง

และร่องรอยของ Wirth อยู่ใน Go จนถึงทุกวันนี้ Go specification ใช้ Wirth Syntax Notation (EBNF variant) ซึ่งเป็น notation ที่ Wirth คิดค้นขึ้นมา นี่ไม่ใช่เรื่องบังเอิญ

ก่อน Go: จาก HotSpot สู่ V8

ก่อนจะมาเป็นหนึ่งในสามคนสร้าง Go Griesemer มีผลงานที่โลกใช้กันทุกวัน

Object Oberon ขยายภาษา Oberon ของ Wirth ให้มี object-oriented features นี่คือจุดเริ่มต้นของความคิดเรื่อง type system ที่ต่อมาทำให้ Go แตกต่างจากภาษา C-family ทั่วไป

Java HotSpot VM Griesemer ร่วมเขียน compiler ให้ HotSpot ซึ่งเป็น JVM implementation ที่ทำให้ Java เร็วพอสำหรับ enterprise และรันอยู่ในเซิร์ฟเวอร์เป็นล้านเครื่องทั่วโลก

V8 JavaScript engine เขาเป็นหนึ่งในทีมแรก ๆ ของ V8 ที่ Google engine ตัวนี้ทำให้ Chrome เร็วขึ้นหลายเท่า ทำให้ Node.js เกิด และเปลี่ยน JavaScript จากภาษาที่คนดูถูกว่า "ช้า" เป็นภาษาที่เร็วพอจะรัน server-side ได้

Sawzall ภาษา data processing ของ Google ที่ Griesemer ทำร่วมกับ Pike และทีม Google อีกหลายคน เป็นประสบการณ์ที่ทำให้เขาเห็นว่า "ภาษาสำหรับงานเฉพาะทาง" ควรหน้าตาเป็นยังไง

Paxos Made Live (2006) paper ที่อธิบายความท้าทายในการ implement Paxos algorithm ในระบบ production แสดงให้เห็นว่า Griesemer ไม่ใช่แค่นักทฤษฎีภาษา แต่ยังเข้าใจ distributed systems engineering ด้วย

21 กันยายน 2007 — วันที่สามคนยืนหน้า whiteboard

Go FAQ บันทึกวันที่นี้ไว้อย่างชัดเจน:

"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007."

สามคนนี้มาจากคนละโลก Pike คือ systems programmer จาก Bell Labs Thompson คือตำนาน Unix ทีสร้างภาษา B และร่วมสร้าง UTF-8 ส่วน Griesemer มาจากโลกของ type theory, formal semantics, และ compiler design

นี่คือสิ่งที่ทำให้ทีมนี้สมบูรณ์ Pike กับ Thompson คิดจากมุม developer experience ส่วน Griesemer คิดจากมุม "ภาษาแบบนี้ type system ควรเป็นยังไง"

และผลลัพธ์ที่จับต้องได้ที่สุดจากมุมของ Griesemer คือ Go specification

Go Spec — มหากาพย์เงียบ

Go language specification คือเอกสารที่ programmer Go ทุกคนเปิดอ่านตอนสงสัยว่า syntax แบบนี้ถูกต้องไหม ภาษาเวอร์ชันนี้เปลี่ยนอะไรไปจากเวอร์ชันก่อน

Griesemer เป็น primary author ของ spec นี้

การเขียน spec ไม่ใช่งานที่มีคนปรบมือให้ แต่คือสิ่งที่ทำให้ Go เป็นภาษาที่ compiler ทุกตัว (gc, gccgo, TinyGo) ทำงานตรงกัน เพราะทุกอย่างถูกนิยามไว้ชัดเจน ไม่มี "มันควรจะทำงานแบบนี้แหละ" หรือ "แล้วแต่ implementation"

spec ใช้ Wirth Syntax Notation ภาษาที่อาจารย์ของ Griesemer คิดค้นขึ้นเมื่อ 40 ปีก่อน นั่งอยู่ในเอกสารภาษาใหม่ที่รันอยู่ใน production เป็นล้านเครื่องทั่วโลก

Type Inference — สิ่งที่ทำให้ Go generics ใช้งานได้จริง

นี่คือผลงานที่แสดง DNA ของ Griesemer ชัดที่สุด

Go มี type inference ตั้งแต่แรก (:=) แต่ของที่ยากคือ type inference สำหรับ generics ที่เขาออกแบบให้กับ Go 1.18

Griesemer เป็นคนออกแบบ type unification algorithm ที่ทำให้คุณเขียน slices.Sort(list) แทนที่จะต้องเขียน slices.Sort[MyType](list) ได้

เขายังเป็นคนเขียน blog post บน go.dev (ตุลาคม 2023) อธิบายการทำงานของ type inference อย่างละเอียด ตั้งแต่หลักการจนถึง edge case

ประโยคหนึ่งใน post นั้นสรุปปรัชญาของเขาได้ดี:

"Type inference is an optional mechanism: if type arguments make code clearer, by all means, write them down."

ไม่ใช่ "type inference จะเดาทุกอย่างให้คุณ" แต่คือ "type inference จะช่วยคุณในที่ที่มันแน่ใจ และให้คุณควบคุมในที่ที่มันไม่แน่ใจ"

นี่คือ pragmatic language design — ให้เครื่องมือกับ programmer แต่ไม่บังคับ

Generics — 10 ปีที่ทำให้มันถูกต้อง

Generics ใน Go ใช้เวลา design นานกว่าทศวรรษ ไม่ใช่เพราะ Go team ขี้เกียจ แต่เพราะพวกเขาไม่ยอมปล่อยอะไรที่ "เกือบดี"

Griesemer กับ Ian Lance Taylor เป็นสองคนหลักที่เขียน proposal "The Next Step for Generics" (มิถุนายน 2020)

เขาเป็นคนออกแบบ:

Type inference algorithm
Interface-based constraint system
~ (approximation) syntax สำหรับ type constraints
Square brackets [] สำหรับ type parameters (การเลือกที่ถกเถียงกันมาก แต่เขายืนยันว่าดีกว่า <> เพราะไม่ชนกับ comparison operators)

ทุกครั้งที่คุณเขียน func Sort[T cmp.Ordered](list []T) คุณกำลังใช้ type system ที่ Griesemer ออกแบบ

ปรัชญาการทำงาน

คนที่เคยร่วมงานกับ Griesemer บอกตรงกัน: เขาเป็นคนเงียบ ถามทีตอบที comment ใน code review เฉียบและสั้น

Go spec ทุกเวอร์ชันคือลายเซ็นของเขา ไม่มีน้ำ ไม่มี buzzword แต่เป๊ะ

มีคนเล่าว่าในทีม Go ถ้า spec บอกว่า "implementation-defined" Griesemer จะถามทันทีว่าทำไม แล้วช่วย redesign จนมันไม่ต้องเป็น undefined อีก

นี่คือ DNA ที่มาจาก Wirth: ทำให้ทุกอย่าง explicit ใน spec ทำให้ compiler implement ได้ตรงกันทุกตัว

การปรากฏตัวต่อสาธารณะ

Griesemer ไม่ใช่คนที่คุณเห็นบ่อยบนเวที conference แต่ก็ไม่ใช่ว่าไม่เคยขึ้นเลย

เขาพูดที่ GopherCon SG 2017 (keynote: "Exporting Go"), GopherCon 2016, dotGo 2016, Gopherpalooza 2019, GopherCon 2020, GopherCon 2021 (ร่วมกับ Ian Lance Taylor), และ GopherCon 2023

นอกจากนี้ยังเคยให้สัมภาษณ์ใน GoTime podcast

แต่เมื่อเทียบกับ Pike ที่มีบล็อก 150+ บทความและเป็น keynote speaker ระดับโลก หรือ Thompson ที่ได้ Turing Award

Griesemer เลือกที่จะให้งานพูดแทนตัวเขา

Blog post บน go.dev ที่ Griesemer เขียนเองมีไม่กี่ครั้ง: "The Next Step for Generics" (2020) และ "Type Inference" (2023)

แต่ทุกครั้งที่มีคนเปิด Go spec ทุกครั้งที่มีคนใช้ generics ทุกครั้งที่ type inference เดา type ได้ถูกต้องโดยที่คุณไม่ต้องประกาศ

นั่นคือลายเซ็นของเขา

ทุกวันนี้

Griesemer ยังทำงานที่ Google เป็นหนึ่งใน maintainer หลักของ Go

เขาไม่ใช่ "อดีตผู้สร้าง Go" เขาคือ "คนที่ยังสร้าง Go อยู่ทุกวันนี้"

Griesemer กับโปรแกรมเมอร์ไทย

Go spec ที่เขาเขียน คือเหตุผลที่คุณอ่าน type error แล้วไม่ต้องเดาว่ามันแปลว่าอะไร

Go generics ที่เขาออกแบบ คือเหตุผลที่คุณไม่ต้องเขียน interface{} แล้ว type-assert ไปมา

และปรัชญาที่เขาสืบทอดมาจาก Wirth "ทำให้ของซับซ้อนง่ายด้วย specification ที่ดี" คือสิ่งที่โปรแกรมเมอร์ไทยทุกคนได้ประโยชน์ ไม่ว่าเราจะรู้ชื่อเขาหรือไม่

สรุป

Robert Griesemer คือ proof ว่าคุณไม่จำเป็นต้องดังเท่า Pike หรือ Thompson ถึงจะเปลี่ยนโลก

คุณแค่ต้องเขียน spec ให้ดีพอ

ที่มา: Go FAQ (go.dev), Wikipedia, Go blog (go.dev/blog), Go spec (go.dev/ref/spec), ETH Research Collection (research-collection.ethz.ch), Google Research (research.google/people/author96/), GoTime podcast, Griesemer's Type Inference post (Oct 2023)

Rob Pike — ผู้ชายที่เกลียดความซับซ้อน และสร้าง UTF-8 กับ Go

Gophernment — Thu, 30 Jul 2026 02:35:15 +0000

📅 กรกฎาคม 2026
⚠️ อ้างอิงจากแหล่งปฐมภูมิ ตรวจสอบแล้ว — แต่เช็คข้อมูลล่าสุดก่อนแชร์

ถ้าคุณพิมพ์ภาษาไทยแล้วไม่พัง
เขียน Go แล้วรู้สึกว่ามันง่ายเกินคาด
หรือสงสัยว่าทำไมภาษาใหม่ ๆ ถึงไม่มี inheritance

คุณกำลังใช้ของที่ผู้ชายคนหนึ่งใช้เวลา 40 ปีทำ

Rob Pike

เด็กเนิร์ดแคนาดา

Rob Pike เกิดปี 1956 โตมาในยุคที่คอมพิวเตอร์ยังเป็นเครื่องจักรขนาดห้อง

จบ BS จาก University of Toronto แล้วไปต่อที่ Caltech เขาสนใจ operating system กับ programming language ตั้งแต่วันแรก

ปี 1980 ได้งานที่ Bell Labs บ้านของ Unix, C และภาษาโปรแกรมมิ่งอีกนับไม่ถ้วน

ที่นั่นเขาได้ร่วมงานกับ Ken Thompson (ผู้สร้าง Unix) และ Dennis Ritchie (ผู้สร้าง C) สองคนที่วงการนี้เรียกว่าระดับเทพ

ยุค Bell Labs

สร้าง window system ตัวแรกของ Unix

ปี 1981 Pike เขียน window system ตัวแรกให้ Unix ก่อนที่โลกจะมี Windows หรือ Mac GUI ด้วยซ้ำ ต่อมาพัฒนาเป็น Blit terminal (1984) ที่มี overlapping windows

Plan 9 — OS ที่ล้ำเกินยุค

ทีม Pike, Thompson, Ritchie สร้าง Plan 9 ระบบปฏิบัติการที่เอาแนวคิด "ทุกอย่างคือไฟล์" ไปสุดทาง

ใน Unix พวก filesystem, network, devices ต่างก็เป็นไฟล์ แต่ยังมีข้อยกเว้น Plan 9 ทำแม้กระทั่งหน้าต่าง GUI ก็เป็นไฟล์ คุณ mount window ของคนอื่นมาดูผ่าน network ได้เลย

Plan 9 ล้ำมาก แต่ไม่เคยเป็น mainstream โลกไปทาง Windows กับ Linux แทน

แต่แนวคิดของ Plan 9 กลายเป็น DNA ของทุกอย่างที่ Pike ทำต่อมา

Inferno — Plan 9 เวอร์ชัน network

ต่อจาก Plan 9 พวกเขาสร้าง Inferno OS ที่ออกแบบให้รันบน network ตั้งแต่เกิด

มาพร้อมภาษา Limbo ที่หน้าตาเหมือน Go เวอร์ชันดั้งเดิม แต่ก่อน Limbo ก็ยังมี Newsqueak ภาษาที่ Pike เขียนตอนปี 1989 สำหรับ experiment เรื่อง concurrency โดยเฉพาะ

นี่คือจุดที่สำคัญ goroutine และ channel ที่เราใช้ใน Go ทุกวันนี้ มีต้นแบบตรง ๆ จาก Newsqueak (1989) → Alef (1992) → Limbo (1995) → Go (2009) สาย DNA นี้ตรงมาก คนเขียน Go ส่วนใหญ่ไม่รู้ว่า concurrency model ที่ตัวเองใช้ทุกวัน อายุเกือบ 40 ปีแล้ว

Inferno ก็เหมือน Plan 9 ล้ำเกินไปสำหรับยุคนั้น

UTF-8 — ของที่คุณใช้ทุกวันโดยไม่รู้ตัว

นี่คือหนึ่งใน origin story ที่ดีที่สุดของวงการคอมพิวเตอร์

กันยายน 1992 Pike ได้เมลจากคณะกรรมการ X/Open ให้ช่วยรีวิวข้อเสนอ encoding ใหม่ชื่อ FSS/UTF Pike ลิสต์สิ่งที่ encoding ที่ดีควรทำได้ แล้วพบว่า FSS/UTF ขาดไปอย่างน้อยหนึ่งข้อ

เย็นวันนั้น Pike กับ Ken Thompson ไปกินข้าวที่ร้านอาหารใน New Jersey Ken Thompson เป็นคนออกแบบ bit-packing ของ UTF-8 บนกระดาษรองจาน (placemat) Pike นั่งดูอยู่ตรงหน้า

คืนนั้นพวกเขาโทรกลับไปหา X/Open บอกว่าพร้อมจะ implement ให้เสร็จภายในวันจันทร์

วันศุกร์สัปดาห์เดียวกัน Plan 9 รันบน UTF-8 เต็มระบบ (บันทึกใน source code: 4 กันยายน 1992 เวลา 19:51:55)

หัวใจของ UTF-8 คือ backward compatibility กับ ASCII ตัวอักษร A-Z ยังใช้ 1 byte เหมือนเดิม แต่ภาษาไทย จีน ญี่ปุ่น เติมอีกไม่กี่ byte

วันนี้ UTF-8 ใช้กับเกือบ 98% ของเว็บทั้งโลก ทุกครั้งที่คุณส่งข้อความภาษาไทยแล้วไม่พัง คุณกำลังใช้ของที่ Thompson ออกแบบและ Pike นั่งดูอยู่ข้าง ๆ ในร้านอาหารเย็นนั้น

Pike เคยแก้ความเข้าใจผิดด้วยตัวเอง: "UTF-8 was designed, in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992" — ไม่ใช่ IBM เป็นคนออกแบบ

หนังสือ The Unix Programming Environment

ปี 1984 Pike เขียนหนังสือ "The Unix Programming Environment" ร่วมกับ Brian Kernighan (อีกหนึ่งตำนาน Bell Labs)

หนังสือเล่มนี้สอนปรัชญา Unix: เขียนโปรแกรมที่ทำอย่างเดียวแต่ทำให้ดี, ต่อท่อเชื่อมกัน, ใช้ text เป็น interface ปรัชญานี้กลายเป็นกระดูกสันหลังของ Go ในอีก 25 ปีต่อมา

Google และการเกิดของ Go

ที่มา: ตำนาน 45 นาทีที่เปลี่ยนทุกอย่าง

ปี 2002 Pike ย้ายไป Google

ตามตำนานที่ Pike เองเรียกว่า "origin myth" วันหนึ่งปี 2007 มี build ของ Google binary ใหญ่ตัวหนึ่งที่ใช้เวลานานมาก (คนเล่ากันว่า 45 นาที) Pike หันไปคุยกับ Robert Griesemer ระหว่างรอ Ken Thompson มาร่วมวง

21 กันยายน 2007 ทั้งสามคนเริ่มร่างภาษาใหม่บน whiteboard ในห้องประชุมของ Google

เป้าหมายชัด: compile เร็วแม้ codebase จะใหญ่แค่ไหน, ไม่มี inheritance ไม่มี exception, concurrency ในตัว (goroutine + channel สืบทอดมาจาก Newsqueak และ Limbo), และ garbage collection ที่ไม่ทำให้ช้า

Pike เสนอชื่อ "go" เพราะสั้น พิมพ์ง่าย

Go เปิดตัว

พฤศจิกายน 2009 Google open source Go

สิ่งที่ทำให้ Go ต่าง: มันไม่ใช่ academic language ไม่มี paper รองรับ ไม่มี type system ซับซ้อน มันคือภาษาของวิศวกรที่อยากทำงานให้เสร็จ

Compile เป็น static binary ไฟล์เดียว ไม่มี dependency hell และมี gofmt โค้ดทุกคนหน้าตาเหมือนกัน เลิกเถียงเรื่อง style ได้เลย

Go 1.0 ปล่อยมีนาคม 2012 และรักษา backward compatibility มาจนถึงทุกวันนี้

Go ชนะเพราะอะไร

Pike ออกแบบ Go ด้วยหลักการเดียวที่สรุปเป็นชื่อ talk ปี 2012 ของเขา: "Less is exponentially more."

ไม่ใช่แค่ทำน้อย ๆ แต่มันคือการตัดทุกอย่างที่ไม่จำเป็นออก จนเหลือแต่ของที่ต้องมีจริง ๆ

Go เลือกตัด inheritance (ใช้ composition + interface แทน), exception (ใช้ error return value), generic (ตอนแรก เพิ่มใน Go 1.18)

ทุกอย่างที่ Go ไม่มี คือสิ่งที่ Pike มองว่าเป็นภาระ ไม่ใช่ฟีเจอร์

ผลที่ได้: Go กลายเป็นภาษาเบอร์หนึ่งของ cloud infrastructure Docker, Kubernetes, Terraform, Prometheus ทั้งหมดเขียนด้วย Go

ปรัชญาของ Pike

Pike ไม่ใช่คนที่พูดเยอะ แต่ของที่พูดมักคม

"Less is exponentially more." หัวใจของ Go และทุกอย่างที่ Pike ทำ

"Object-oriented design is the roman numerals of computing." (2004) OOP คือเลขโรมันของวงการคอมพิวเตอร์ ใช้ได้แต่ไม่ควรเป็นค่า default

"Concurrency is not parallelism." ชื่อ talk ปี 2012 ที่กลายเป็นประโยคคลาสสิก concurrent ไม่ใช่ parallel

"A little copying is better than a little dependency." ก็อปโค้ดนิดหน่อย ดีกว่าเพิ่ม dependency ใหม่ทั้งตัว (Go proverb)

"Clear is better than clever." โค้ดที่ชัดเจน ดีกว่าโค้ดที่ฉลาด (Go proverb)

"Don't communicate by sharing memory; share memory by communicating." อย่าสื่อสารด้วยการแชร์ memory ให้แชร์ memory ด้วยการสื่อสาร หัวใจของ goroutine + channel

ทุกวันนี้

Pike ไม่ได้เกษียณ (ถึง Wikipedia จะพยายามเขียนแบบนั้นหลายรอบ แต่ไม่มีแหล่งอ้างอิง)

เขาเรียกตัวเองว่า "Professional dilettante" ยัง review Go code อยู่ ยังเขียนโค้ดใหม่ ๆ ลง GitHub เรื่อย ๆ

ผลงานล่าสุด: Ivy (เครื่องคิดเลขแนว APL), ภาษา Lisp ของตัวเอง, เครื่องมือภาษาญี่ปุ่น

2024 พูดที่ GopherConAU ในหัวข้อ "What We Got Right, What We Got Wrong" ยอมรับทั้งสิ่งที่ Go ทำถูก (spec, gofmt, compatibility, concurrency) และสิ่งที่พลาด (async/await ดีกว่า CSP? concurrency กับ parallelism อธิบายผิดมาตลอด?)

2025 โพสต์ "On Bloat" ชวนคิดว่า package เล็ก ๆ กลายเป็นปัญหาได้ยังไงเมื่อมี dependents เยอะ

มกราคม 2026 ลงลึกเรื่อง high-precision math ใน Ivy

ยัง active บน Mastodon และ Bluesky ใช้ชีวิตระหว่างสหรัฐฯ กับออสเตรเลียกับ Renée French ภรรยาที่เป็น illustrator และเป็นคนวาด Go gopher ที่เราเห็นกันทุกวันนี้

Pike กับโปรแกรมเมอร์ไทย

UTF-8 ทำให้ภาษาไทยอยู่บนเว็บได้โดยไม่พัง ก่อนหน้านั้น TIS-620 กับ Windows-874 ชนกันตลอด

Go เป็นภาษาที่บริษัทเทคไทยใช้กันเยอะขึ้น Agoda, LINE MAN Wongnai, SCB TechX ทั้งหมดมี Go ใน production

ปรัชญา "less is exponentially more" ของ Pike ยิ่งสำคัญในยุคที่ AI สร้างโค้ดได้เป็นล้านบรรทัด ทำน้อยแต่ดี ไม่ใช่ทำเยอะแล้วงง

สรุป

Rob Pike ใช้เวลา 40 ปีทำโจทย์เดียว: ทำยังไงให้คอมพิวเตอร์ง่ายสำหรับมนุษย์

UTF-8 ที่เราใช้ทุกวัน Go ที่รันบนเซิร์ฟเวอร์เป็นล้านเครื่อง ปรัชญา "less is exponentially more" ที่กลายเป็น DNA ของ developer รุ่นใหม่

ทั้งหมดเริ่มจากผู้ชายคนหนึ่งที่รอ C++ compile 45 นาที แล้วคิดว่า "เราทำได้ดีกว่านี้"

ที่มา: Wikipedia, go.dev, Rob Pike's blog (commandcenter.blogspot.com), UTF-8 history (Pike's own account 2003), Go FAQ, GitHub (github.com/robpike), Wikiquote

DEV Community: Gophernment

Aider: AI pair programming ใน terminal — เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

Aider คืออะไร

เริ่มใช้งานง่าย ๆ

จุดเด่นของ Aider

ข้อควรรู้ก่อนใช้จริง

เทียบหมัดต่อหมัดกับคู่แข่ง 5 ตัว

เลือกยังไง

แหล่งอ้างอิง

AI เขียน Go โบราณตลอด — JetBrains เลยทำ "กติกาการเขียน Go สมัยใหม่" ให้ agent แล้ว

ทำไม AI ถึงเขียน Go เก่า ทั้งที่ Go ออกฟีเจอร์ใหม่ตลอด

แล้ว JetBrains แก้ยังไง

ข้างในมีอะไรน่าสนใจบ้าง

min / max แทนการเทียบเอง (Go 1.21)

slices.Contains แทน loop หา (Go 1.21)

for i := range n แทนการนับเอง (Go 1.22)

errors.AsType แทน errors.As แบบเก่า (Go 1.26)

ลองใช้ดู

สรุป

แหล่งอ้างอิง

จาก Vibe Coding สู่ Agentic Engineering — SDLC ใหม่ที่กำลังมาแทนที่

"vibe coding" คำนี้มาจากไหน

เส้นแบ่งจริง ๆ ไม่ใช่ "ใช้ AI หรือไม่" แต่อยู่ที่ "ตรวจสอบแค่ไหน"

ทักษะที่แท้จริงไม่ใช่ "prompt" แต่เป็น "context"

model ไม่ใช่ทุกอย่าง — แนวคิด Harness ที่คนส่วนใหญ่เข้าใจผิด

ปัญหา 80% — ทำไม AI ยังแทนเราไม่ได้ (และก็ไม่ควร)

เงินที่ซ่อนอยู่ใต้ vibe coding

แล้วควรเริ่มยังไง

ทิ้งท้าย

Goish: พอร์ตรันไทม์ของ Go ทั้งตัวลงใน no_std Rust

Goish คืออะไร

ทำไมถึงคิดทำตัวนี้ (ที่มาที่ไป)

ใช้เทคนิคอะไรบ้าง

1. M:N Scheduler — พอร์ตแบบ verbatim จาก runtime/proc.go

2. Memory: page allocator + 67 size classes (แต่ไม่มี GC)

3. เขียนโค้ดที่ "อ่านแล้วเหมือน Go" แต่ compile ด้วย rustc

4. crypto/tls — พอร์ตครบ 100% พร้อมใบเสร็จทุกบรรทัด

ประโยชน์ที่ได้

วิธีเริ่มต้น

ข้อจำกัด (บอกตรง ๆ)

สรุป

REPL — วิธีคุยกับคอมพิวเตอร์ที่ LISP สอนโลก

READ → EVAL → PRINT → LOOP

ก่อน REPL: ยุคที่คอมพิวเตอร์ไม่คุยกับคุณ

กำเนิดในห้องแล็บ AI ของ MIT

ทำไม REPL ถึงสำคัญกว่า "แค่ console"

การเดินทางของ REPL — จากห้องแล็บ AI มาถึงมือคุณ

1960s — LISP

1990–1991 — Python

1995 — Ruby IRB

2006 — Firebug

2009 — Node.js REPL

2011 — Chrome DevTools Console

2014 — IPython / Jupyter Notebook

2015 — Rust Playground

สิ่งที่ REPL สอนเรา

อ่านเพิ่ม

LISP — ภาษา 67 ปีก่อน ที่ยังมีชีวิตอยู่ในทุกภาษาที่คุณเขียน

กระดาษแผ่นเดียวที่เปลี่ยนโลก

สิ่งที่ LISP สร้างไว้ (และเราใช้มันทุกวัน)

1. if-then-else

2. Garbage Collection

3. Lambda — function เป็นข้อมูล

4. REPL — ปรัชญา "คุยกับภาษา"

5. Homoiconicity — code = data

มรดกจาก LISP

ทำไม LISP ถึงไม่ใช่ภาษาหลักวันนี้

มรดกที่มองไม่เห็น

อ่านเพิ่ม

GNU — จุดเริ่มต้นของ Linux ที่หลายคนไม่เคยรู้

เรื่องเล่าจากเครื่องพิมพ์

กำเนิด GNU

Hurd — kernel ที่ไม่มีวันเสร็จ

เด็กฟินแลนด์กับ kernel ของเขา

ทำไม Linux ถึงสำเร็จ

GNU + Linux = ?

GNU/Linux — การถกเถียงที่ยังไม่จบ

มรดกที่เรายังใช้อยู่ทุกวันนี้

สำหรับคนที่อยากอ่านเพิ่ม

"iota ใน Go — อักษรกรีกตัวจิ๋วที่กลายเป็นเครื่องมือทรงพลัง"

`min` / `max` แทนการเทียบเอง (Go 1.21)

`slices.Contains` แทน loop หา (Go 1.21)

`for i := range n` แทนการนับเอง (Go 1.22)

`errors.AsType` แทน `errors.As` แบบเก่า (Go 1.26)

1. M:N Scheduler — พอร์ตแบบ verbatim จาก `runtime/proc.go`

2. `/proc` filesystem — เกิดใน Unix แต่ Plan 9 ทำให้มันเป็นอย่างที่เราใช้

`go` command — คุณใช้มันทุกวันโดยไม่เคยคิดถึงมัน