เจอรัลด์ ซัสแมน: การเขียนโปรแกรมควรสนุก (2022) [วิดีโอ]
(youtube.com)- เจอรัลด์ ซัสแมนกล่าวว่า ตั้งแต่ปี 1962 เขาได้ผ่านสภาพแวดล้อมคอมพิวเตอร์ยุคแรกอย่าง IBM 7094, PDP-6, Mac Hack 6 และ Maxima และยังคงยึดถือ ความสุขจากตัวการเขียนโปรแกรมเอง มาโดยตลอด
- การเขียนโปรแกรมไม่ใช่การโค้ดดิ้งที่ย้ายสเปกลงสู่โค้ดแบบเชิงกล แต่ใกล้เคียงกับ การออกแบบวิศวกรรมเชิงนามธรรม ที่ค่อย ๆ ค้นหาสเปกและการติดตั้งใช้งานที่เป็นไปได้ไปพร้อมกันภายใต้เป้าหมายที่ยังไม่สมบูรณ์
- เขามองโครงสร้าง eval/apply ของ Lisp ควบคู่กับปฏิสัมพันธ์ในสมการของ Maxwell และมองการเขียนโปรแกรมว่าเป็นกิจกรรมสร้างสรรค์ที่จัดการกับปัญหาเชิงแนวคิดอย่างลึกซึ้งไม่ต่างจากฟิสิกส์ คณิตศาสตร์ และปรัชญา
- บั๊กไม่ใช่แค่ความล้มเหลว แต่เป็นโอกาสในการเรียนรู้ที่เกิดจากมนุษย์ผู้มีขอบเขตจำกัดพยายามแก้ปัญหาด้วยแผนที่ทำให้ง่ายลง และเป็นส่วนหนึ่งของ “การแก้ปัญหาด้วยการดีบักแผนที่เกือบถูกต้อง”
- ประสบการณ์ด้าน automatic differentiation, การขยาย generic operation ของ Scheme และการเขียนกลศาสตร์คลาสสิกให้อยู่ในรูปโปรแกรมที่รันได้ แสดงให้เห็นว่าการเขียนโปรแกรมช่วยทำให้ศาสตร์อื่นชัดเจนขึ้นได้ และเขาเน้นว่าความสนุกจะสมบูรณ์เมื่อมีการแบ่งปันในรูปแบบ free/libre software
การออกแบบและการสำรวจที่ไกลเกินกว่าการโค้ด
- ซัสแมนเริ่มใช้คอมพิวเตอร์ตั้งแต่เป็นนักเรียนมัธยมในปี 1962 และได้สัมผัสงานคอมพิวติ้งผ่าน Columbia Science Honors Program
- คอมพิวเตอร์ยุคแรกอย่างตระกูล IBM 7094 มีราคาหลายล้านดอลลาร์, อ้างที่อยู่ได้เพียง 2^15 คำขนาด 36 บิต และทำงานด้วยรอบเวลาประมาณ 2 ไมโครวินาที
- หลังเข้า MIT เขาได้ใช้คอมพิวเตอร์อย่าง DEC PDP-6 ซึ่งระบบนั้นอ้างที่อยู่ได้ 2^18 คำขนาด 36 บิต
- หน่วยความจำขนาดใหญ่จำเป็นต่อระบบจัดการสัญลักษณ์ยุคแรกอย่าง Maxima
- MIT สั่งหน่วยความจำขนาดใหญ่จาก Fabritek ใช้เวลาผลิตราว 1 ปี และตามบันทึกมีราคาราว 380,000 ดอลลาร์
- เนื่องจากหน่วยความจำนี้ใหญ่มากในยุคนั้น จึงถูกตั้งชื่อว่า Moby ตามชื่อวาฬ
- เขาเคยมีส่วนร่วมกับปัญญาประดิษฐ์ การออกแบบคอมพิวเตอร์แบบใหม่ การประดิษฐ์ภาษาโปรแกรม การจำลองเชิงตัวเลขทางกลศาสตร์ท้องฟ้า และการเขียนระบบสัญลักษณ์ขนาดใหญ่ แต่แก่นกลางยังคงเป็นความรักต่อการเขียนโปรแกรม
- การเขียนโปรแกรมไม่ใช่งานเชิงกลที่แปลงสเปกที่กำหนดไว้อย่างชัดเจนให้เป็นโค้ดที่รันได้
- สเปกที่ดีมักไม่ได้ถูกส่งลงมาจากเบื้องบน
- เราต้องสำรวจสิ่งที่ทำได้จริงก่อน แล้วจึงเขียนสเปกให้สอดคล้องกับสิ่งที่บรรลุได้จริง
- เพราะฉะนั้น การเขียนโปรแกรมจึงเป็น การสำรวจร่วมกัน เพื่อค้นหาทั้งสเปกและการติดตั้งใช้งานที่เป็นไปได้ภายใต้เป้าหมายที่กำหนดไว้เพียงบางส่วน
- ต่างจากวิศวกรรมเชิงกายภาพ การเขียนโปรแกรมถูกจำกัดมากกว่าด้วย ความสามารถในการจัดระเบียบความคิด มากกว่าข้อจำกัดทางกายภาพอย่างค่าคลาดเคลื่อน รัศมีการตัด หรือความคลาดเคลื่อนของความต้านทาน
- โปรแกรมเมอร์เลือกสรรการแทนค่า อัลกอริทึม และระดับของ abstraction ขณะทำงานกับเครื่องเสมือนขนาดมหึมา
การเขียนโปรแกรมในฐานะศิลปะสร้างสรรค์
- เพื่ออธิบายความรู้สึกของการเขียนโปรแกรม ซัสแมนอ้างถึงงานเขียนของ Edgar Allan Poe ที่อธิบายว่าเขาเขียน 「The Raven」 อย่างไร
- Poe บอกว่างานชิ้นนั้นไม่ได้เกิดจากความบังเอิญหรือสัญชาตญาณ แต่ค่อย ๆ สำเร็จขึ้นเป็นลำดับเหมือนการแก้โจทย์คณิตศาสตร์ พร้อมเผยให้เห็นกระบวนการอันซับซ้อนของการเลือก การลบ การแทรก และการแก้ไข
- กระบวนการนี้ใกล้เคียงกับความรู้สึกของการเขียนโปรแกรมจริงมากกว่าการแปลงสเปกเป็นโค้ด
- การเขียนโปรแกรมใกล้เคียงกับ ศิลปะสร้างสรรค์ ไม่ต่างจากสถาปัตยกรรม ดนตรี คณิตศาสตร์ หรือฟิสิกส์ทฤษฎี
- คณิตศาสตร์คือกิจกรรมแห่งการประดิษฐ์ทฤษฎีบทที่งดงาม
- ฟิสิกส์ทฤษฎีคือกิจกรรมแห่งการประดิษฐ์คำอธิบายของโลกทางกายภาพ
- การเขียนโปรแกรมก็เป็นกิจกรรมแห่งการประดิษฐ์และขัดเกลาแนวคิดกับโครงสร้างเช่นกัน
โครงสร้างที่ eval/apply และสมการของ Maxwell เปิดให้เห็น
- ประสบการณ์เรียน Lisp 1.5 และอินเทอร์พรีเตอร์ eval/apply ในปีหนึ่งที่ MIT เป็นจุดเปลี่ยนชีวิตของซัสแมน
- eval รับนิพจน์และสภาพแวดล้อม ประเมินตัวดำเนินการและโอเปอแรนด์เพื่อสร้าง procedure และอาร์กิวเมนต์ ส่วน apply รับ procedure และอาร์กิวเมนต์ มัดอาร์กิวเมนต์เข้ากับพารามิเตอร์เชิงรูปแบบ แล้วกลับไปประเมินบอดี
- ซัสแมนมองว่าโครงสร้างนี้ใช้ได้กับทุกภาษาโปรแกรมและแม้แต่วิธีทำงานของคอมพิวเตอร์เอง
- ในช่วงเวลาเดียวกัน เขาเรียนวิชาแม่เหล็กไฟฟ้าและได้รับความประทับใจอย่างมากจากสมการของ Maxwell
- Maxwell เพิ่มพจน์ displacement current เพื่อแก้ความไม่สอดคล้องกันระหว่างการอนุรักษ์ประจุกับสมการเดิม
- ผลลัพธ์คือสมการคลื่นแม่เหล็กไฟฟ้า และการเชื่อมโยงว่าความสว่างคือคลื่นแม่เหล็กไฟฟ้า
- มีความคล้ายคลึงอย่างลึกซึ้งระหว่างปฏิสัมพันธ์ของ eval/apply กับโครงสร้างในสมการของ Maxwell ที่สนามไฟฟ้าและสนามแม่เหล็กก่อให้เกิดการเปลี่ยนแปลงซึ่งกันและกัน
- ความคล้ายคลึงนี้ยังเชื่อมโยงไปถึงความสัมพันธ์ของ ตัวแปรคู่กัน เช่น ตำแหน่งกับโมเมนตัม พลังงานกับเวลา
- การเขียนโปรแกรมทำให้เราพบปัญหาเชิงปรัชญาอยู่เป็นประจำ
- การที่ชื่อ
Chicagoในโปรแกรมจะอ้างถึงเมืองจริงได้อย่างไรนั้นไม่ใช่เรื่องตรงไปตรงมา - วัตถุสองชิ้นจะเหมือนกันหรือไม่ มักเผยออกมาเมื่อเราเปลี่ยนแปลงชิ้นหนึ่งแล้วอีกชิ้นเปลี่ยนตามหรือไม่ และ การเปลี่ยนค่า (mutation) ก็เชื่อมโยงกับปัญหาเรื่องอัตลักษณ์
- โปรแกรมแบบ pure functional ไม่มีการเปลี่ยนค่า จึงต้องมองอัตลักษณ์ในอีกแบบหนึ่ง
- ภายในนิพจน์ที่ถูก quote ไว้ หลักการที่ว่า “สิ่งที่เท่ากันสามารถแทนกันได้” อาจใช้ไม่ได้
- ประพจน์อย่าง “อีกาทุกตัวเป็นสีดำ” ก็ทำให้ความหมายของหลักฐานซับซ้อนขึ้นได้แบบเดียวกับ Raven Paradox ของ Hempel
- การที่ชื่อ
วิธีรับมือกับบั๊ก
- ซัสแมนมองบั๊กไม่ใช่ความล้มเหลวที่น่าอาย แต่เป็น โอกาสในการเรียนรู้
- เขาบอกว่าการดีบักด้วยเครื่องมือที่ดีอาจสนุกเหมือนการผจญภัย และบั๊กควรมีชื่อ เช่น fencepost error หรือ reader-writer bug
- บั๊กยังเป็นผลลัพธ์ของกลยุทธ์การออกแบบที่ทรงพลังด้วย
- มนุษย์ไม่สามารถคิดทุกอย่างพร้อมกันได้ จึงต้องวางแผน
- แผนต้องอาศัยการทำให้เรื่องซับซ้อนง่ายลง และการทำให้ง่ายลงย่อมทำให้มีส่วนที่ตกหล่น
- ผลก็คือเกิดบั๊กขึ้น และการดีบักก็คือกระบวนการค่อย ๆ ปรับแผนที่เกือบถูกต้องให้ไปในทิศทางที่ต้องการ
- ซัสแมนเรียกวิธีนี้ว่า “การแก้ปัญหาด้วยการดีบักแผนที่เกือบถูกต้อง”
- ตัวอย่างการออกแบบฟิลเตอร์ไฟฟ้าแสดงให้เห็นกลยุทธ์นี้
- เพื่อสร้างฟิลเตอร์ที่มีการตอบสนองระหว่าง 30Hz ถึง 3kHz เขาแยกตัวประกอบ system function
- แล้วนำตัวต้านทานและคาปาซิเตอร์มาประกอบเป็นวงจรย่อยที่ต้องการ
- แต่แต่ละวงจรย่อยตั้งอยู่บนสมมติฐานว่า “ไม่มีกระแสไหลออก” ดังนั้นเมื่อนำมาต่อรวมกันจึงเกิด loading bug
- การเพิ่มแอมพลิไฟเออร์เป็นแพตช์สามารถแก้ปัญหานี้ได้ในบางกรณี
- ไม่ใช่ทุกบั๊กที่จะสนุก
- ซัสแมนวิจารณ์ว่า C และ C++ เต็มไปด้วยกับดัก
- เขายังเชื่อมโยงสถานการณ์ที่ต้องมีเคอร์เนลใหม่บ่อย ๆ เพราะบั๊กด้านการจัดการหน่วยความจำเข้ากับโค้ดที่เขียนด้วย C
- ใน Python เองก็มีตัวอย่างของความไม่สม่ำเสมอ เช่น
{}คือ dictionary แต่{1}เป็น set และ tuple ถูกกำหนดด้วยเครื่องหมายจุลภาคไม่ใช่วงเล็บ
automatic differentiation และฟิสิกส์ที่รันได้จริง
- ในปี 1992 ซัสแมนไปอยู่กับกลุ่มของ Kip Thorne ที่ Caltech และได้เรียนสัมพัทธภาพทั่วไป โดยเขาบอกว่าใช้โปรแกรมเป็นสื่อสำหรับเก็บรักษาความรู้
- ระหว่างคิดเรื่องอนุพันธ์ของฟังก์ชันร่วมกับ Dan ซึ่งเป็นผู้ออกแบบชิป floating-point ของ Hewlett-Packard เขาได้ค้นพบ forward-mode automatic differentiation ขึ้นใหม่อย่างอิสระ
- เป้าหมายไม่ใช่ symbolic differentiation ที่ต้องมองเข้าไปในตัวฟังก์ชัน และไม่ใช่การประมาณเชิงตัวเลข
- แกนสำคัญคือ chain rule
- หากขยายจำนวนให้เป็น differential object ที่มีทั้งส่วนจำกัดและส่วนอนันต์เล็ก การประกอบฟังก์ชันก็จะทำให้ chain rule ทำงานโดยอัตโนมัติ
- เพราะใช้ Scheme เขาจึงสามารถนิยามตัวดำเนินการเลขคณิตพื้นฐานใหม่ให้รองรับ differential object ได้ และซัสแมนบอกว่าเขาลงมือทำแบบ “hack attack” ตลอดทั้งคืน
- หลังจากนั้นมีหลายคนเข้ามาช่วยขัดเกลาการหาอนุพันธ์ของ higher-order function, อนุพันธ์หลายตัวแปร และการขยาย primitive operation ของ Scheme แบบไดนามิก
- Abelson ช่วยจัดระเบียบทฤษฎีที่ถูกต้องของอนุพันธ์หลายตัวแปร
- Jeff Siskind, Barak Pearlmutter และ Alexey Radul ช่วยดีบักบั๊กที่ละเอียดอ่อนในอนุพันธ์ของ higher-order function
- Hansen คิดวิธีขยาย primitive operation ของ Scheme แบบไดนามิกให้มีประสิทธิภาพ
- งานนี้ต่อยอดไปสู่ระบบ Scmutils ที่เขาใช้ร่วมกับ Jack Wisdom เพื่อการสอนและวิจัยด้านกลศาสตร์คลาสสิกและเรขาคณิตเชิงอนุพันธ์
- หนังสือ Structure and Interpretation of Classical Mechanics ของซัสแมนและ Wisdom เป็นความพยายามที่จะทำให้ความเข้าใจในกลศาสตร์คลาสสิกชัดเจนขึ้นผ่านเทคนิคเชิงคำนวณ
- สัญกรณ์สมการแบบ Lagrange ดั้งเดิมคลุมเครือหากไม่มีความรู้ทางวัฒนธรรมประกอบ และยังมีปัญหาในมุมมองเรื่องชนิดของฟังก์ชัน
- เมื่อเขียนด้วยสัญกรณ์เชิงฟังก์ชันและโค้ด Scheme แนวคิดทางคณิตศาสตร์ก็กลายเป็น โปรแกรมที่ชัดเจนและรันได้จริง
- ในตัวอย่าง harmonic oscillator ระบบสามารถคำนวณสมการการเคลื่อนที่ที่ถูกต้องจากมวล ค่าคงที่สปริง และตำแหน่ง รวมถึงความสัมพันธ์ของความถี่เชิงมุมได้
ความสนุกที่สมบูรณ์เมื่อได้แบ่งปัน
- ซัสแมนสรุปความสนุกของการเขียนโปรแกรมไว้หลายด้าน
- ความสุขจากการค้นพบความคล้ายคลึงอย่างลึกซึ้งระหว่างโลกที่ต่างกัน
- ความสุขจากการได้เผชิญปัญหาที่นักปรัชญาครุ่นคิดกันมานานในงานจริง
- ความสุขของการล่าตามรอยบั๊ก
- ความสุขของการค้นพบแนวคิดและ abstraction ที่ดี
- ความสุขของการใช้โปรแกรมทำให้ศาสตร์อื่นชัดเจนขึ้น
- ความสนุกของการเขียนโปรแกรมจะสมบูรณ์เมื่อได้แบ่งปันงานกับผู้อื่น และเขาสนับสนุนให้ใช้และสร้าง free/libre software
- ซัสแมนเสียดายที่ต้องบันทึกผ่าน Zoom และบอกว่าเขาอยากได้ซอฟต์แวร์ที่อ่าน แก้ไข และแบ่งปันต่อได้
- สำหรับเสรีซอฟต์แวร์และเสรีภาพของซอฟต์แวร์ เขาแนะนำให้ดู ปรัชญาซอฟต์แวร์เสรีของ GNU และขอให้เข้าร่วมและบริจาคให้กับ Free Software Foundation
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมชอบส่วนนี้มาก: “เขียนโปรแกรมในฐานะ วิธีจดจำอะไรบางอย่าง ความทรงจำของผมคือโปรแกรมที่ผมเขียนไว้ เมื่อผมเรียนเรื่องอย่างคณิตศาสตร์ ฟิสิกส์ หรือชีววิทยา แล้วเขียนโปรแกรมเพื่อแสดงมันไว้ ภายหลังกลับมาอ่านก็ไม่คลุมเครือและเข้าใจง่าย เท่ากับเป็นการเก็บความรู้ไว้แบบนั้น”
https://www.infoq.com/presentations/Expression-of-Ideas/
เป็นหัวข้อที่ใกล้เคียงกับข้อความอ้างอิงข้างต้นมาก และพูดถึงว่าการเขียนโปรแกรมช่วยให้เข้าใจสิ่งอย่างคณิตศาสตร์และฟิสิกส์ได้ลึกขึ้นอย่างไร
เช่น วิธีที่ยาแก้ปวดออกฤทธิ์ช่วยให้เข้าใจคีย์ล็อกเกอร์หรือการโจมตีแบบคนกลางได้ และเมื่อดู “การตรวจไวยากรณ์” ของ DNA ระหว่างไมโทซิส ก็เรียนรู้ภาพรวมของการคอมไพล์ได้
พฤติกรรมของลูกสุนัขที่กลืนทุกอย่างที่เห็น ก็เหมือนกับการให้ข้อมูลทดสอบเกี่ยวกับสภาพแวดล้อมรอบตัวแก่มากพอแก่ระบบภูมิคุ้มกัน ซึ่งคล้ายกับแมชชีนเลิร์นนิง และแนวคิดด้านความมั่นคงปลอดภัยไซเบอร์จำนวนมากก็เข้าใจได้ผ่านชีววิทยา
ผมเป็นคนคิดเป็นภาพ เลยเข้าใจคณิตศาสตร์อย่างแท้จริงได้ยาก แต่การเขียนโค้ดช่วยให้สร้างภาพและความสัมพันธ์ในหัวได้
โชคดีที่ได้รู้เรื่องนี้ตั้งแต่เด็ก ไม่อย่างนั้นคงหลงทางไปแล้ว
ปัญหา การตัดสินใจ เหตุผล ข้อเท็จจริงที่ใช้เป็นหลักฐาน และทางเลือกที่พิจารณาแล้ว ล้วนเป็นความรู้ และคำสั่งแต่ละคำสั่งที่ป้อนด้วยภาษาโปรแกรมก็เป็นการตัดสินใจอย่างหนึ่งเช่นกัน
การออกแบบซอฟต์แวร์อาจดำเนินยาวนานพอจนลืมการตัดสินใจและบริบทก่อนหน้า และอาจยาวนานพอจนคนออกไป ความรู้หายไป แล้วคนใหม่เข้ามาโดยขาดความรู้
การทำให้คอมพิวเตอร์เข้าใจซอร์สโค้ดไม่ใช่ส่วนที่ยาก ส่วนที่ยากกว่าคือทำให้คนอื่นเข้าใจว่าสิ่งใดถูกทำสำเร็จไปแล้ว และทำงานได้ดีขึ้นเร็วขึ้น
เมื่อสมองและความทรงจำอย่างเดียวไม่พอ เราต้องอาศัยเทคโนโลยีอย่างการเขียน การพิมพ์ และซอฟต์แวร์ เพื่อจดจำและจัดระเบียบก้อนความรู้ที่ใหญ่ขึ้น
ปัญหาใหญ่ที่สุดในคณิตศาสตร์สำหรับผมก็คือ ผมไว้ใจไม่ได้ว่าตัวเองจะไม่ทำผิด และก็ไว้ใจไม่ได้ด้วยว่าจะพบข้อผิดพลาด
คอมไพเลอร์หรืออินเทอร์พรีเตอร์ช่วยทำให้ผมสังเกตเห็น
ครั้งหนึ่งเคยฟังบรรยายของ Sussman ใต้ดินที่ NYU กับนักศึกษาปริญญาเอกด้านประสาทวิทยาประมาณ 20 คน
เขาพูดเรื่องความสามารถในการตีความ AI มานานก่อนที่หัวข้อนี้จะเป็นกระแสเสียอีก
ผมถามคำถามหนึ่งไป แล้วเขาก็จับได้ทันทีว่ามีคนเรียนวิศวกรรมไฟฟ้าอยู่ในห้อง จึงเดินไปที่กระดานอีกด้านและแสดงให้เห็นว่าสามารถหาวิธีการทำงานของออปแอมป์จากหลักการพื้นฐานได้อย่างไร
คนคนนี้มีพลังและปัญญามหาศาล และสร้างความประทับใจอย่างลึกซึ้งแน่นอน
ยังไม่ได้ดูวิดีโอ แต่ผมนึกถึงคำอ้างของ Alan J. Perlis ที่ Sussman กับ Abelson ใช้ในคำอุทิศของ SICP ทันที
เนื้อหาคือ ในวิทยาการคอมพิวเตอร์ การรักษาความสนุกของการคำนวณไว้เป็นเรื่องสำคัญมาก และในยุคแรก ๆ มันสนุกจริง ๆ
บางครั้งลูกค้าได้รับความเสียหาย และเราเริ่มรับฟังคำร้องเรียนเหล่านั้นอย่างจริงจัง แต่ก็เป็นมุมมองว่าเราไม่ได้มีหน้าที่รับผิดชอบต่อการใช้เครื่องจักรเหล่านี้ให้สำเร็จ ปราศจากข้อผิดพลาด และสมบูรณ์แบบ
แก่นสำคัญคือ เรามีหน้าที่ผลักเครื่องจักรเหล่านี้ ส่งมันไปในทิศทางใหม่ ๆ และรักษาความสนุกไว้ หวังว่าวิทยาการคอมพิวเตอร์จะไม่สูญเสียความรู้สึกสนุก และอย่าทำตัวเหมือนมิชชันนารีหรือคนขายคัมภีร์ไบเบิล
อย่ารู้สึกว่ากุญแจสู่การคำนวณที่ประสบความสำเร็จอยู่ในมือเราเท่านั้น สิ่งที่เรามีอยู่ในมือคือปัญญา หรือความสามารถในการมองเครื่องจักรเหล่านี้ให้เป็นสิ่งที่มากกว่าตอนที่เราเพิ่งพบมันครั้งแรก และทำให้มันยิ่งใหญ่ขึ้น
สำหรับคนที่เหลือส่วนใหญ่ซึ่งทำโปรแกรมนับถั่ว จากมุมของคนที่จ่ายเงินเดือน การไม่ทำถั่วหายแม้แต่เม็ดเดียวนั้นสำคัญกว่ามาก เมื่อเทียบกับว่าเราสนุกแค่ไหนหรือขยายความเป็นไปได้ได้มากเพียงใด
ไม่ใช่บั๊ก แต่เป็น ก้อนความสนุก เล็ก ๆ ต่างหาก /s
ชื่อที่ดีกว่าน่าจะใกล้เคียงกับ “วิทยาการคอมพิวเตอร์เชิงวิชาการ นั้นสนุก หรือควรจะสนุก”
ใจความคือการค้นพบอุปมา การคิดเชิงปรัชญา การดีบัก การคิดไอเดียดี ๆ และการได้ความชัดเจนนั้นล้วนสนุก แต่สิ่งเหล่านี้ส่วนใหญ่เป็นความหรูหราของอาจารย์ที่ได้รับเงินให้ทำกิจกรรมแบบนั้น และดูจะไม่ค่อยเข้ากับโลกที่ว่า “ลูกค้าต้องการสิ่งนี้ภายในสุดสัปดาห์นี้” นอกจากความเพลิดเพลินเชิงโต้แย้งของการดีบัก
“การเขียนโปรแกรม” ส่วนใหญ่คงควรมองว่าใกล้กับวิชาสายอาชีพอย่าง การเชื่อมโลหะ มากกว่า
ถ้าจะพัฒนาเทคนิคการเชื่อมแบบใหม่ นั่นเหมาะจะเป็นโจทย์วิจัยระดับบัณฑิตศึกษา แต่ช่างเชื่อมและโปรแกรมเมอร์ส่วนใหญ่ทำงานกับเครื่องมือที่รู้จักกันดีและระบบที่ค่อนข้างเรียบง่าย
นักเรียนสายอาชีพอาจไม่อยากเสียเวลาเรียน MIT/GNU Scheme แล้วไม่เคยใช้มันอีกเลยในชีวิตการทำงาน แต่สำหรับนักศึกษาสายวิชาการ มันอาจคุ้มค่าเหมือนนักภาษาศาสตร์ที่เรียนอ่านและเขียน Linear B
งานอะไรก็สนุกได้ทั้งนั้น แต่ท้ายที่สุด เงื่อนไขอย่างความสามารถและความมั่นคงทางอารมณ์ของเพื่อนร่วมงานและผู้จัดการ การออกแบบและความปลอดภัยของพื้นที่ทำงาน ค่าตอบแทนที่พอเลี้ยงชีพได้ และวัฒนธรรมองค์กรที่ยอมปล่อยงานลวก ๆ ผ่านไปหรือไม่ มีผลมากกว่า และอาชีพเฉพาะทางอื่น ๆ อย่างการเขียนโปรแกรมระบบควบคุมอุตสาหกรรมก็เช่นเดียวกัน
คุณจะได้รู้ว่าคนที่อยากรู้อยากเห็น รอบคอบ และมีความรู้ ไม่ว่าจะเรียนเองหรือไม่ ในทุกอาชีพจะทำงานได้ดีกว่าคนที่ไม่เป็นแบบนั้น
สมัยก่อนตอนทำงานเป็นช่างเชื่อม คนฉลาด มีแรงจูงใจ และอยากรู้อยากเห็นก็ทำได้ดีกว่าคนที่แค่มาฆ่าเวลา
ดังนั้นผมเห็นด้วยว่าการเขียนโปรแกรมคล้ายกับการเชื่อมโลหะ แต่ในความหมายที่ต่างจากที่ตั้งใจไว้
SICP เปลี่ยนวิธีคิดของผมเกี่ยวกับโค้ด การทำ abstraction และความเป็นโมดูลไปอย่างสิ้นเชิง ขณะที่เพื่อนร่วมงานข้าง ๆ กำลังแฮ็กด้วย Pascal หรือ C
ผมสามารถสร้างแบบจำลองทางความคิดของปัญหาด้วย Lisp/Scheme ได้ ในขณะที่เพื่อนร่วมงานต้องทำ abstraction ไว้ในหัว แล้วนำไปใช้งานจริงในภาษาที่ต้องจดจ่อกับรายละเอียดระดับต่ำ
ดังนั้นผมจึงรู้สึกขอบคุณตลอดไปที่ได้เจอ SICP ตั้งแต่เนิ่น ๆ
การเขียนโปรแกรมด้วยภาษาใดอาจทำให้สนุกขึ้นหรือสบายใจขึ้นได้
สำหรับ C++ ผมคงไม่มีวันรู้สึกสบายใจกับมันได้เลย
ดีที่ได้ฟังมุมมองต่อการเขียนโปรแกรมจากหนึ่งในผู้เขียน SICP และเกร็ดเล่าในช่วงไม่กี่นาทีแรกก็น่าสนใจดี
พอบอกพนักงานว่าจำเป็นจริง ๆ เพราะวันรุ่งขึ้นจะไปพบ Sussman เขาก็โทรไปที่ Harvard co-op และทราบว่าที่นั่นมีเหลืออยู่หนึ่งเล่ม ผมจึงเรียก Uber ไปที่ร้านหนังสือ Harvard แล้วซื้อ SICP มา
วันรุ่งขึ้นผมไปที่ห้องทำงานของ Sussman ที่ MIT บังเอิญ Abelson ก็อยู่ด้วยและกำลังจะออกพอดี ทั้งสองคนจึงเซ็นชื่อบน SICP ของผมให้
Sussman ยังเสริมว่า “ถ้ามาเร็วกว่านี้อีก 15 นาที ภรรยาผมก็คงได้เซ็นให้ด้วย!” และจนถึงตอนนั้นผมไม่รู้เลยว่าภรรยาของเขาเป็นผู้ตรวจแก้ SICP
ผมยังมีรูปสวย ๆ ที่ถ่ายกับพ่อมดทั้งสองคนนี้ พร้อมหนังสือสีม่วงที่เพิ่งได้ลายเซ็นมา
อยากดูวิดีโอนี้เร็ว ๆ
ผมยังไม่ได้ลองทำ SICP อย่างจริงจัง แต่ยืมหนังสือไว้แล้ว และเคยฟังเลกเชอร์ระหว่างซ่อมบ้าน
คำพูดของ Sussman จากเลกเชอร์ SICP เรื่องการทำความเข้าใจสิ่งที่ซับซ้อน ผมมักใส่ไว้ในงานนำเสนอเกี่ยวกับสถาปัตยกรรม และเป็นสไลด์ที่ผู้คนมักจดกันอย่างลนลานเสมอ
พูดตรง ๆ คือผมรักการเขียนโปรแกรมมาหลายปี และช่วงหนึ่งมันเคยเป็นงานอดิเรกหลักด้วย
ผมเคยลองภาษาใหม่ ๆ หรือซอฟต์แวร์ใหม่ ๆ อ่านหนังสือโปรแกรมมิ่ง และเข้าร่วมแชตต่าง ๆ อย่าง libera/freenode
แต่พอมาเป็นฟรีแลนซ์และต้องโฟกัสกับการส่งมอบโค้ดที่ใช้ได้ดีอย่างรวดเร็วในบริบทที่เล็กลง ความหลงใหลนั้นก็ลดลง
โดยรวมแล้วอาจเป็นเรื่องดีในฐานะวิศวกร แต่ ความสนุกและการเรียนรู้ จำนวนมากหายไปจากงานประจำวัน
งานฟรีแลนซ์และคอนซัลติ้งมักเป็นการแก้ปัญหา หรือถึงขั้นเหมือนการยิงปัญหาให้หายไปให้เร็วที่สุด และความงดงามไม่ใช่สิ่งจำเป็น
ถ้าอยากเป็น builder ที่สร้างเครื่องมือ สิ่งนั้นคงไม่ค่อยเกิดขึ้นในงานฟรีแลนซ์ แต่ถ้าย้ายไปบทบาทคอนซัลแทนต์ก็อาจเป็นไปได้
ผมมองว่าคอนซัลแทนต์เป็นความสัมพันธ์ระยะยาวกว่า จึงน่าพิจารณาเป็นก้าวถัดไป