SICP: หนังสือวิทยาการคอมพิวเตอร์เพียงเล่มเดียวที่ควรค่าแก่การอ่านสองรอบ? (2010)

 (simondobson.org)
4 คะแนน โดย GN⁺ 2024-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการให้ยืมหนังสือแก่นักศึกษาคนหนึ่งเพื่ออ่านช่วงฤดูร้อน Simon Dobson ได้ยืนยันอีกครั้งว่า SICP คือหนังสือวิทยาการคอมพิวเตอร์ที่มีอิทธิพลต่อเส้นทางอาชีพและความสนใจด้านงานวิจัยของเขามากที่สุด
  • ต่างจากการเรียนเขียนโปรแกรมเบื้องต้นที่เน้น Pascal หนังสือเล่มนี้เริ่มจากค่า ชื่อ การผูกโยง และการควบคุม แล้วแสดงให้เห็นว่าการเขียนโปรแกรม สามารถเป็นอะไรได้บ้าง
  • เชื่อมโยงตั้งแต่ lambda abstraction, การคำนวณลำดับสูง, stream, lazy evaluation, interpreter และ compiler, garbage collection, virtual memory, machine code ไปจนถึง ภาษาเฉพาะโดเมน ภายใน Scheme
  • อิทธิพลที่ใหญ่ที่สุดอยู่ที่ การออกแบบแบบแบ่งชั้น ซึ่งประกอบระบบซับซ้อนขึ้นจากภาษาหลายระดับ และมุมมองที่เห็นวิทยาการคอมพิวเตอร์เป็นศาสตร์ของ “ทำอย่างไร” มากกว่า “คืออะไร”
  • หนังสือที่ซื้อในปี 1988 ยังคงควรค่าแก่การอ่านซ้ำในเชิงปฏิบัติแม้ในปี 2010 และ SICP ยังคงเป็นตำราพื้นฐานที่ยืนยาวของวิทยาการคอมพิวเตอร์

การพบกับ SICP ครั้งแรก

  • หลังจาก Simon Dobson ให้ยืม Structure and Interpretation of Computer Programs แก่นักศึกษาเพื่ออ่านช่วงฤดูร้อน เขาก็นึกขึ้นได้ว่าหนังสือเล่มนี้ใกล้เคียงที่สุดกับงานเขียนที่ เป็นรากฐาน สำหรับเขาในวิทยาการคอมพิวเตอร์ทั้งหมด
  • ชื่อเต็มอย่างเป็นทางการคือ Structure and Interpretation of Computer Programs โดย Hal Abelson และ Jerry Sussman จัดพิมพ์โดย MIT Press ในปี 1984 และเรียกกันว่า SICP ด้วย
  • หนังสือยังคงตีพิมพ์อยู่ และมีเนื้อหาทั้งเล่มให้อ่านออนไลน์
  • Dobson ได้รู้จักหนังสือเล่มนี้ในฐานะตำราแนะนำ หลังจากเรียนวิชาเขียนโปรแกรมวิชาแรกจบในช่วงปีสองของปริญญาใบแรกที่ Newcastle upon Tyne
  • สำหรับเขาในเวลานั้น ซึ่งกำลังค้นหาเส้นทางในวิทยาการคอมพิวเตอร์ SICP ไม่ได้เป็นหนังสือว่าด้วย “การเขียนโปรแกรมในยุคนั้น” ที่มี Pascal เป็นตัวแทน แต่เป็นหนังสือที่แสดงให้เห็น รูปแบบของการเขียนโปรแกรมที่เป็นไปได้

แนวคิดที่ค่อย ๆ สร้างขึ้นภายใน Scheme

  • SICP เริ่มจากองค์ประกอบพื้นฐานของการเขียนโปรแกรม ได้แก่ ค่า ชื่อ การผูกโยง และการควบคุม ก่อนขยายไปสู่หัวข้อที่กว้างขวาง
    • lambda abstraction และ การคำนวณลำดับสูง
    • โครงสร้างข้อมูลซับซ้อนที่บรรจุการคำนวณไว้
    • ความเป็นโมดูล, ความเปลี่ยนแปลงได้
    • stream
    • lazy evaluation
    • การสร้าง interpreter และ compiler
    • การจัดการพื้นที่เก็บข้อมูล, garbage collection, virtual memory
    • machine code
    • ภาษาเฉพาะโดเมน
  • ขอบเขตที่ครอบคลุมกว้างจนน่าตกใจ แต่ด้วยงานเขียนและการจัดโครงสร้างของผู้เขียน หนังสือจึงยังคงความสอดคล้องไว้ได้
  • โดยเฉพาะอย่างยิ่ง หนังสือจัดการทุกแนวคิดภายในกรอบของภาษาเดียวคือ Scheme และสร้างแนวคิดถัดไปต่อยอดจากสิ่งที่เรียนมาก่อนหน้า

การออกแบบโปรแกรมในฐานะการออกแบบภาษา

  • คุณลักษณะที่สองของ SICP ซึ่งส่งอิทธิพลอย่างมาก คือการที่ Hal Abelson และ Jerry Sussman มองทุกอย่างเป็น แบบฝึกหัดในการออกแบบภาษา
  • หนังสือเน้น การออกแบบแบบแบ่งชั้น ซึ่งประกอบระบบซับซ้อนจากภาษาหลายระดับ
    • แต่ละระดับถูกสร้างขึ้นโดยการนำชิ้นส่วนที่ถือว่าเป็นสิ่งพื้นฐานในระดับนั้นมาประกอบกัน
    • ชิ้นส่วนที่สร้างขึ้นในระดับหนึ่งจะถูกใช้เป็นองค์ประกอบพื้นฐานของระดับถัดไป
    • ภาษาของแต่ละระดับมีองค์ประกอบพื้นฐาน วิธีการประกอบ และวิธีการสร้าง abstraction ที่เหมาะกับระดับรายละเอียดนั้น
  • abstraction แบบลำดับชั้นเป็นสิ่งที่นักวิทยาการคอมพิวเตอร์คุ้นเคยอยู่แล้ว แต่ความแตกต่างสำคัญในที่นี้คือมุมมองที่ว่าแต่ละชั้น ต้องเขียนโปรแกรมได้
  • ในมุมมองนี้ ชั้นต่าง ๆ ไม่ได้เป็นเพียงกลไกสำหรับซ่อนข้อมูล แต่เป็นวิธีจัดการกับการคำนวณและการแปลง
  • ในภาษาโปรแกรมกระแสหลัก การแบ่งชั้นลักษณะนี้มักต่อยอดไปเป็นการขยายตัวภาษาเองได้ยาก
    • Java ยังคงเป็น Java ตั้งแต่บนลงล่าง มี class และ library แต่ไม่มีโครงสร้างควบคุมใหม่
    • แม้โครงสร้างภาษาเฉพาะสำหรับโดเมนหนึ่งจะมีประโยชน์ ก็ยากที่จะเพิ่มเข้าไปในภาษาได้อย่างง่ายดาย
    • ในทางกลับกัน หากอยากห้ามไม่ให้ใช้โครงสร้างบางอย่างในโดเมนใดโดเมนหนึ่ง ก็ไม่สามารถนำออกจากภาษาได้
    • Java-ME ตัดฟังก์ชันบางส่วนออกเพื่อให้รันบนอุปกรณ์ขนาดเล็กได้ แต่ไม่ใช่วิธีที่ทำได้โดยไม่ต้องเขียน compiler ใหม่

“ทำอย่างไร” มากกว่า “คืออะไร”

  • อิทธิพลสำคัญประการที่สามคือมุมมองของ SICP ต่อสิ่งที่วิทยาการคอมพิวเตอร์จัดการจริง ๆ
  • SICP มองการปฏิวัติคอมพิวเตอร์ว่าเป็นการปฏิวัติทั้งวิธีคิดและวิธีแสดงความคิด
  • หนังสืออธิบายสิ่งนี้ว่าเป็น ญาณวิทยาเชิงกระบวนการ (procedural epistemology)
    • หากคณิตศาสตร์คลาสสิกให้กรอบในการจัดการ “คืออะไร” อย่างแม่นยำ
    • การคำนวณก็ให้กรอบในการจัดการ “ทำอย่างไร” อย่างแม่นยำ
  • Dobson เคยยึดมุมมองว่าคอมพิวเตอร์เป็นเหมือนกล้องจุลทรรศน์แบบใหม่ ที่ทั้งช่วยแนวทางเดิมและเปิดทางสู่วิทยาศาสตร์ใหม่
  • แง่มุม “ทำอย่างไร” ของวิทยาการคอมพิวเตอร์ปรากฏซ้ำในหลายด้าน
    • การอธิบายพฤติกรรมของเครือข่ายเซนเซอร์ที่ปรับตัวได้โดยสะท้อนปรากฏการณ์ที่ถูกติดตั้งเฝ้าดูอยู่ตลอดเวลา
    • การตีความข้อมูลขนาดใหญ่ที่ถูกขุดและผสานจากทั่วทั้งเว็บ
    • การจับเก็บวิธีการและกระบวนการทางวิทยาศาสตร์เพื่อนำไปทำให้อัตโนมัติ
  • ความอุดมสมบูรณ์ของพื้นที่เหล่านี้ส่งเสริมการบูรณาการผ่านภาษาโปรแกรมมากกว่าซอฟต์แวร์แบบแพ็กเกจ และทำให้ interface กับโครงสร้างยังคง ยืดหยุ่นและทดลองได้ ด้วยภาษาอย่าง R

ทำไมหนังสือเก่ายังคงถูกอ่าน

  • ภายในหนังสือของ Dobson มีวันที่ซื้อระบุไว้ว่าเดือนกันยายน 1988 และเมื่อมองจากปี 2010 หนังสือที่มีอายุเกือบ 22 ปีเล่มนี้ยังคงเกี่ยวข้องอยู่
  • เขามองว่า SICP แทบจะเป็นหนังสือวิทยาการคอมพิวเตอร์เพียงเล่มเดียวในวัยประมาณนั้นที่ อ่านซ้ำได้อย่างมีประโยชน์ ไม่ใช่เพียงเพราะความสนใจทางประวัติศาสตร์
  • ในหนังสือคณิตศาสตร์ เนื้อหาที่คงอยู่ยาวนานไม่ใช่เรื่องหายาก แต่ในวิทยาการคอมพิวเตอร์ซึ่งแนวคิดเคลื่อนไหวรวดเร็วและมีหัวข้อชั่วคราวจำนวนมาก เรื่องนี้พบได้ยาก
  • การที่เนื้อหาของ SICP แทบไม่ล้าสมัย แสดงให้เห็นว่าหนังสือจับ แนวคิดแกนหลัก ของวิทยาการคอมพิวเตอร์ไว้ได้ดี
  • ด้วยเหตุนี้ SICP จึงเป็นหนึ่งในหนังสือวิทยาการคอมพิวเตอร์ไม่กี่เล่มที่ควรค่าแก่การอ่านมากกว่าหนึ่งครั้ง และได้รับการประเมินว่าเป็นหนังสือที่กลั่นแก่นแท้ของสาขาออกมาให้เข้าถึงได้และผ่านบททดสอบของกาลเวลา เช่นเดียวกับ Lectures on Physics ของ Feynman ในสาขาฟิสิกส์
  • ในการอัปเดตวันที่ 27 มกราคม 2024 หนังสือเล่มนี้ยังถูกรวมไว้ใน annotated Lisp bibliography ในรายการ Structure and interpretation of computer programs ด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-17
ความคิดเห็นบน Hacker News

  • “คลาสสิก” อย่าง SICP พูดถึงการออกแบบโปรแกรม แต่ทุกวันนี้ดูเหมือนว่า การออกแบบระบบ จะเป็นทักษะที่สำคัญกว่ามาก
    ไม่แน่ใจว่าระบบแบบกระจายถือเป็นส่วนหนึ่งของ “วิทยาการคอมพิวเตอร์” หรือไม่ แต่ในทางปฏิบัติเป็นปัญหาที่ต้องแก้บ่อยกว่า
    ผมมักทำระบบให้เรียบง่ายที่สุดเท่าที่ทำได้ ใช้เครื่องมือ observability หา จุดที่การออกแบบยังไม่พอ แล้วค่อยหยิบโครงสร้างข้อมูลหรือวิธีแก้แบบ “วิทยาการคอมพิวเตอร์จ๋า” มาใช้เมื่อจำเป็น
    ในกรณีส่วนใหญ่ สัญกรณ์ Big-O และความซับซ้อนด้านเวลาในการรัน ไม่สำคัญ และสามารถแก้ปัญหาได้มากมายด้วยอาร์เรย์กับ CPU ที่เร็ว
    แม้จะเกิดปัญหาด้านประสิทธิภาพ ก็ต้องเริ่มจาก profiling เพื่อหาคอขวดก่อน
    วิทยาการคอมพิวเตอร์ไม่ได้สอนดีนักว่าแคชหน่วยความจำของ CPU ทำงานอย่างไร
    อัลกอริทึมกราฟที่ดูเท่อาจมีความซับซ้อนด้านเวลาในการรันดี แต่ทำลายประสิทธิภาพของ CPU cache จนช้ากว่าอาร์เรย์ที่ใช้แคชได้ดี
    ปัญหาที่พบบ่อยกว่าในโลกจริงคือการรับมือกับ fault tolerance, ความถูกต้องของ distributed lock และ queue, รวมถึง scalability ของระบบ
    ผมมีพื้นฐานด้านคอมพิวเตอร์/วิศวกรรมไฟฟ้า เลยอาจมีอคติอยู่บ้าง

    • การออกแบบระบบต้องมีมุมมองด้านการ implement ดังนั้นแม้จะขยับขึ้นไปทำงานออกแบบในระดับที่สูงขึ้นของห่วงโซ่คุณค่า ก็ข้ามประสบการณ์ระดับล่างไม่ได้
      ผมเรียนเรื่อง CPU memory cache จากหนังสือของ Hennessy และ Patterson ในเทอมแรกของปริญญาตรี CS เมื่อ 30 ปีก่อน และเข้าใจว่ายังใช้กันอยู่จนถึงตอนนี้
      fault tolerance, ความถูกต้องของ distributed lock และ queue, scalability ของระบบ ก็เรียนใน CS ระดับปริญญาตรีเช่นกัน และผมไม่ได้มีพื้นฐานพิเศษด้านวิศวกรรมคอมพิวเตอร์/วิศวกรรมไฟฟ้า
    • CS กับการพัฒนาซอฟต์แวร์ในภาคสนามเปลี่ยนไปเล็กน้อย
      งานสร้าง framework, database engine, เครื่องมือ version control ยังมีอยู่ และงานเหล่านี้ต้องใช้ ความรู้ CS เชิงลึก อย่างอัลกอริทึมและโครงสร้างข้อมูลทุกวัน
      แต่งานแบบนั้นมีน้อยลงกว่าเดิม และมักใช้ Postgres แทนการ implement DB engine เองเพื่อแอป
      งานส่วนใหญ่คือ การ implement business logic และถึงการรู้ว่าฐานข้อมูลทำงานภายในอย่างไรจะช่วยให้ได้ผลลัพธ์ที่ดีกว่า แต่ก็สามารถสร้างซอฟต์แวร์ที่ใช้งานได้มากมายโดยไม่รู้ว่า index ถูกจัดเก็บบนดิสก์อย่างไร
      บัณฑิต CS จำนวนมากเข้าใจผิดว่างานของตัวเองคือการเขียน framework แต่ในความเป็นจริงคือการใช้ framework ที่มีอยู่และ implement business logic พร้อมใช้พื้นฐาน CS เพื่อเข้าใจ framework นั้นอย่างลึกซึ้ง
    • โดยดั้งเดิมแล้ว สาขาฐานข้อมูลให้ความสำคัญมากกับการแก้ ปัญหาอัลกอริทึม เมื่อต้องจัดการข้อมูลขนาดใหญ่กว่าที่จะใส่ไว้ในหน่วยความจำได้ทั้งหมด
      ข้อมูลอยู่เป็น “page” บนดิสก์ และใน RAM มี “page slot” จำนวนคงที่
      การย้าย page ระหว่างดิสก์กับ RAM นั้นช้า จึงต้องลดให้มากที่สุด
      ด้วยเหตุนี้ แม้ปัญหาที่ดูเล็กน้อยก็กลายเป็นเรื่องน่าสนใจ ในวิทยาการคอมพิวเตอร์แบบคลาสสิกไม่มีแนวคิดแยกต่างหากที่เรียกว่า “join” เพราะมันไม่ได้ซับซ้อนพอจะต้องตั้งชื่อ
      เราอาจมองงานวิจัยด้านอัลกอริทึมว่าเป็นแก่นแท้บริสุทธิ์ได้ง่าย แต่ก็อาจมองได้ว่าประสิทธิภาพของอัลกอริทึมมีความหมายเฉพาะในบริบทของข้อมูลและฮาร์ดแวร์บางแบบเท่านั้น
      นั่นทำให้งานน่าสนใจขึ้น และความเชี่ยวชาญด้านอัลกอริทึมยังมีประโยชน์ เพราะไม่ใช่ว่าทุกที่จะแค่เอาไลบรารีหรือวิธีแก้แบบตำราอาหารไปใช้ก็พอ
    • ที่พูดมาถูก แต่ผมคิดว่าไม่ใช่แค่ junior เท่านั้น โปรแกรมเมอร์ที่มีประสบการณ์มากก็ยังมักลำบากกับ การเขียนโค้ดระดับยุทธวิธี
      ตอนนี้ผมกำลังลำบากกับคอมโพเนนต์ที่ต้องแก้เล็กน้อยตัวหนึ่ง ซึ่งมี state มากเกินจำเป็นและจัดการ abstraction สองชุดพร้อมกัน
      มันประมวลผลไฟล์ โดยใช้ทั้ง file system และ database สำหรับเก็บ state และผมประหลาดใจมากที่การออกแบบเละเทะแค่ไหน
      ผมใช้เวลาหลายวันเพื่อหลีกเลี่ยงไม่ให้ทำแบบเดิมคือแปะเพิ่มเข้าไปจนเข้าใจยากกว่าเดิม
      วัฒนธรรม pull request ดูเหมือนทำให้คนอนุมัติขยะอะไรก็ได้โดยไม่มีเวลาคิดกับโค้ดจริง ๆ ให้ลึก
      อยากให้ code review แบบเจอหน้ากันกลับมา
    • สงสัยว่าเคยอ่าน Software Design for Flexibility: How to Avoid Programming Yourself into a Corner ของ Chris Hanson และ Gerald Jay Sussman หรือยัง
      เป็นหนังสือที่ออกในปี 2021

  • ลิงก์สำเนาฟรีของหนังสือในบทความเสียแล้ว
    https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
    https://web.mit.edu/6.001/6.037/sicp.pdf
    จนถึงวันนี้ผมยังไม่เคยเห็นเวอร์ชัน PDF อย่างเป็นทางการมาก่อน
    ราวปี 2001 มีเฉพาะเวอร์ชัน HTML ที่เปิดให้อ่านฟรี และมีคนแปลงเป็น TeXinfo: https://www.neilvandyke.org/sicp-texi/
    ถ้าตอนนี้อยากเรียนตาม SICP สามารถรันโค้ดใน MIT Scheme หรือ DrRacket ได้: https://www.neilvandyke.org/racket/sicp/

    • สำหรับคนที่อยากลอง MIT Scheme แม้ผู้ดูแลปัจจุบันจะไม่ได้ให้ไฟล์ .dmg แล้ว แต่สามารถดาวน์โหลดและ build MIT Scheme เวอร์ชัน x86_64 ได้
      รีลีสปัจจุบัน (v12.1) ทำงานได้บน Mac ที่รัน Sequoia ด้วย Intel CPU หรือบน Apple silicon ผ่าน Rosetta
      แต่คอมไพเลอร์ native code ค่อนข้างเสียอยู่ และ SICP ก็น่าจะไม่จำเป็นต้องใช้
      ดูเหมือนว่าบน macOS ก่อน Monterey จะใช้งานได้ ดังนั้น dependency ที่ Apple จัดให้อาจเปลี่ยนไป แต่ผมยังไม่ได้ไล่ตรวจสอบ
      ถ้าไม่ได้จำเป็นต้องใช้ MIT Scheme และไม่อยากลำบากกับการคอมไพล์ Racket อาจเป็นตัวเลือกที่ดีกว่า
    • ข้อหนึ่งที่ควรรู้คือ ผมแนะนำให้ทำด้วย Racket
      เท่าที่ทราบมีโหมด SICP โดยเฉพาะ
      ผมเคยลองทำด้วย GNU Guile แต่มีความต่างทางไวยากรณ์เล็ก ๆ ระหว่าง Guile กับ MIT Scheme ทำให้ค่อนข้างยุ่งยาก
    • ถ้าอยากอ่านในเบราว์เซอร์ ผมจำได้ว่าเวอร์ชัน TeXinfo เป็นแหล่งของ เวอร์ชัน HTML5 ที่ดูดี
      จัดรูปแบบดีกว่าต้นฉบับของ MIT: https://sarabander.github.io/sicp/
    • ควรรู้ไว้ว่า “ภาษาแห่งภาพ” ในบทที่ 2 ไม่ได้รับการรองรับใน MIT Scheme ปี 2024
      ในอดีตเคยมีแพ็กเกจ แต่ไม่มีการดูแลรักษามาเกือบ 20 ปีแล้ว
      ในทางกลับกัน DrRacket มีแพ็กเกจเฉพาะสำหรับทำโจทย์เหล่านั้น
    • DrRacket มี SICP และ HTDP รวมอยู่ในแพ็กสำหรับการศึกษา

  • สามารถดู วิดีโอบรรยายที่บันทึกไว้ในปี 1986 ซึ่ง Abelson และ Sussman สอนเนื้อหาของหนังสือเล่มนี้ได้
    คำอธิบายเรื่องวิธีสร้างและผูก abstraction หลายชั้นยังมีประโยชน์สำหรับผมทั้งส่วนตัวและตอน mentoring จนถึงตอนนี้
    ในวิดีโอคือ lesson 3A ช่วง 1:07:55
    https://m.youtube.com/playlist?list=PLE18841CABEA24090

    • มุก Kabbalah ทำให้หัวเราะได้ทุกครั้ง
    • เวลาดูวิดีโอแบบนี้แล้วรู้สึกน่าทึ่งที่คนเหล่านี้ไม่รู้เลยว่าอนาคตจะมีอะไรตามมา

  • The Elements of Programming Style คุ้มค่าจะอ่านสามรอบ และผมได้ประโยชน์จากการอ่านซ้ำมากกว่านั้นหลายเท่า
    ถ้าสนใจ ผมมีรีวิวที่เขียนไว้เมื่อปี 2010: https://reprog.wordpress.com/2010/03/06/programming-books-pa...

    • ตอนแรกผมนึกว่าหมายถึง Elements of Programming ของ Stepanov กับ McJones และพูดตามตรง ผมก็แนะนำและประเมินหนังสือเล่มนั้นแบบเดียวกันได้
      https://elementsofprogramming.com/

  • ส่วนที่ผมชอบที่สุดใน SICP และจำได้มาหลายปีคือแนวคิดเรื่อง การเขียนโปรแกรมแบบตั้งความปรารถนา
    คือการสร้างบางอย่างจากบนลงล่าง โดยสมมติว่ามี routine ระดับล่างอยู่แล้ว
    จากนั้นค่อยสร้าง routine ระดับล่างเหล่านั้นจริง ๆ ไล่ลงไปจนถึงฐาน
    ผมคิดว่าวิธีคิดนี้เข้ากันได้ดีกับการพัฒนาแบบ test-driven
    คือเขียน test ก่อนสำหรับฟังก์ชันที่อยากให้มี แล้วจึงไปทำให้ความปรารถนานั้นเป็นจริง
    นักพัฒนาส่วนใหญ่ดูเหมือนจะสร้างจากล่างขึ้นบน แล้วสุดท้ายได้บางอย่างที่ไม่มีใครต้องการ

    • เหตุผลที่ทำแบบนั้นก็เพราะต้องการประสิทธิภาพและความเป็นธรรมชาติ
      เราอาจบังเอิญปรารถนาสิ่งที่ยังไม่รู้ธรรมชาติที่แท้จริงของมัน และผลคือเกิดความยุ่งเหยิงเปราะบางที่ฐาน
      โดยทั่วไปมักเป็นแบบนั้น เพราะธรรมชาติเชิงอัลกอริทึมของสิ่งต่าง ๆ มีน้อยครั้งที่จะเป็นไปตามสัญชาตญาณ
      การเริ่มจากด้านล่างก็เหมือนเริ่มจากควาร์กที่เรามีจริง ๆ ไม่ใช่จาก “ขอให้มีเวทมนตร์”
      ไม่มีเวทมนตร์อยู่จริง และเมื่อไปถึงฐานก็มีควาร์กแทนอนุภาคเวทมนตร์ อีกทั้งระหว่างทางเรายังสูญเสียเบาะแสเชิงบริบทที่จะช่วยแปลงระหว่างฟิสิกส์สองแบบนั้นไปด้วย
      ทั้งสองแนวทางล้วนมีประโยชน์ เพราะบางครั้งการแก้ปัญหาลึก ๆ ก็ต้องกล้าปรารถนา
      แต่โดยส่วนตัว ผมชอบใส่เวทมนตร์ไว้ในชั้นที่อยู่ถัดลงมาจากชั้นบนสุดมากกว่า
      คือสร้างจากล่างขึ้นบน แล้วก่อนถึง business logic ก็สร้าง ชั้นเวทมนตร์เพื่อความสะดวก ที่แปลงไปมาระหว่างภาษาทางธุรกิจ
      แบบนั้นปรับแต่งได้ และไม่สร้างความยุ่งเหยิงที่พันกันลงไปถึงฐาน
    • ดร. Donald Knuth ก็ใช้แนวทางคล้าย ๆ กันตอนเขียน TeX
      เขาเริ่มจากเขียนรูปแบบการจัดหน้า/การแท็กที่ดูเหมาะสมก่อน จากนั้นจินตนาการวิธีการเขียนโปรแกรมที่เหมาะกับ markup—ดังนั้นจึงเป็น macro—แล้วจึงลงมือ implement
      ผมกำลังลองใช้แนวทางคล้ายกันกับงานของผมที่พยายามสร้างไลบรารีสำหรับจำลอง G-code ใน OpenSCAD
      เมื่อไม่นานมานี้เพิ่งเขียนใหม่เป็น OpenPythonSCAD แบบ “บริสุทธิ์” จึงหวังว่าจะใช้งานได้ดี
    • โลกของ Smalltalk รองรับแนวทางแบบนี้ได้ดีด้วยวิธีเขียนโค้ดใน debugger
      ลองใช้ Pharo ดูก็ดี

  • SICP เป็นหนังสือที่ดีที่สุดสำหรับอ่านเป็น เล่มแรก เมื่อต้องการศึกษาวิทยาการคอมพิวเตอร์
    ผมเขียนโปรแกรมเป็นงานอดิเรกมาหลายปี เคยอ่านหนังสือเรื่อง structured programming และสัมผัสภาษาหลายภาษาตั้งแต่ Pascal ไปจนถึง Common LISP แล้วมาใช้ Abelson & Sussman ในวิชาวิทยาการคอมพิวเตอร์ระดับปริญญาตรี ซึ่งเปิดโลกมาก
    หนังสือแสดงให้เห็นความเรียบง่าย ความงดงาม และความเป็นเชิงโต้ตอบของ Scheme พร้อมสอนว่าวิทยาการคอมพิวเตอร์คือการซ้อนชั้น abstraction หลายรูปแบบขึ้นไป
    เริ่มจาก procedural abstraction และ data abstraction ไปจนถึงการนิยาม domain-specific language เองและ implement compiler ของมัน และกระทั่งนิยามฮาร์ดแวร์ใหม่ภายในซอฟต์แวร์
    ทุกอย่างดูเป็นธรรมชาติมาก และมีเพียงปรมาจารย์ตัวจริงเท่านั้นที่ทำให้มันดูเป็นแบบนั้นได้
    แต่ควรซื้อ ฉบับพิมพ์ครั้งที่ 2 ไม่ใช่ฉบับพิมพ์ครั้งที่ 1 หรือฉบับที่ใหม่กว่านั้น
    ฉบับล่าสุดใช้ Python แทน Scheme ซึ่งไม่ค่อยดีนัก

  • อยากชอบ SICP จริง ๆ แต่ Lisp เป็นตัวถ่วง
    ผมชอบ Haskell กับ Standard ML
    สงสัยว่ามีใครเคยเจอประสบการณ์คล้ายกันไหม
    ถ้ามีหนังสือที่มีจิตวิญญาณคล้าย SICP แต่ใช้ภาษาอื่นเป็นสื่อ ก็น่าสนใจ
    ไม่ได้อยากทำ SICP ด้วย JavaScript

    • คุณอาจสนใจบทความปี 1987 ชื่อ A Critique of Abelson and Sussman or Why Calculating is Better than Scheming: https://dl.acm.org/doi/10.1145/24697.24706
      ผู้เขียนเสนอให้ใช้ KRC หรือ Miranda เป็นทางเลือกแทน Scheme
      ผมไม่ค่อยรู้จัก KRC แต่ Miranda เป็นภาษา functional programming แบบ static typing ที่มีอิทธิพลต่อ Haskell
    • SICP ไม่ใช่หนังสือเกี่ยวกับ Lisp แต่ใช้ คุณสมบัติเฉพาะของ Lisp เพื่อแสดงแนวคิดสำคัญที่ทำซ้ำในภาษาอื่นได้ยาก
      ถ้ามีหนังสือที่คล้าย SICP โดยไม่ใช้ Scheme หรือ Lisp หนังสือนั้นก็คงจะแตกต่างจาก SICP ไปเลย หรืออย่างน้อยก็สอนสิ่งเดียวกันไม่ได้
      จากประสบการณ์ Haskell กับ ML เข้าใจยากกว่า Scheme มาก เลยสงสัยว่ายากตรงไหน
    • ผมอยากชอบ SICP จริง ๆ และถ้าได้อ่านเมื่อ 15 ปีก่อนก็คงชอบ
      ผมเพิ่งเริ่มอ่านเมื่อเดือนที่แล้ว แต่รู้สึกว่ามันครอบคลุมกว้างเกินไป
      หนังสือไล่ผ่านหลักการทางคณิตศาสตร์ที่น่าสนใจมากมายเกินไป และพอเริ่มสนุกก็ย้ายไปหัวข้อถัดไป
      พูดอีกอย่างคือมันตื้นเกินไป
      มองย้อนกลับไป ผมคงเคยดูคอร์สหรือเอกสารที่แตกแขนงจาก SICP มาเยอะแล้วด้วย พอแต่ละหัวข้อถูกแนะนำจึงอดคิดว่า “เรื่องนี้อีกแล้ว” ไม่ได้ ซึ่งก็ไม่ได้ช่วยเลย
    • เข้าใจความรู้สึกนั้น Lisp ผลักผมออกมา และเป็นเพราะผมไม่ฉลาดพอ
      ถึงอย่างนั้นก็ฝืนทำจนจบ และเพราะไม่ฉลาดพอจะรับมือกับ Lisp ได้ง่าย ๆ เลยกลับได้เรียนรู้อย่างมหาศาล
      เพราะใช้เวลาอ่านโค้ดมากเกินไป ผมเลยรู้สึกว่าได้เรียนรู้มากกว่าที่จะได้เรียนถ้าเป็นภาษาที่คุ้นเคย
      SICP มีเวอร์ชัน Python ด้วย
      ผมไม่ได้ทำจนจบเอง แค่กวาดตาดูคร่าว ๆ จึงไม่ใช่คำแนะนำ แต่ขอทิ้งลิงก์ไว้เป็นหลักฐานว่ามีอยู่จริง
      https://wizardforcel.gitbooks.io/sicp-in-python/content/0.ht...
    • ผมมองว่า Functional Programming in Scala หรือที่เรียกกันว่า Red Book of Scala เป็นหนังสือที่สอนให้คิดในแบบเดียวกับ SICP แม้จะใช้ภาษาที่มี type
      บนชั้นหนังสือของผม สองเล่มนี้ก็วางอยู่ข้างกัน และคุ้มค่าแก่การอ่านแน่นอน

  • ตอนอ่านรอบที่สอง ผมขุดลงไปในเชิงอรรถและบรรณานุกรม และตรงนั้นก็มีโลกใบใหญ่ที่งดงามอยู่ด้วย
    ถ้าจำไม่ผิด มีบทความที่ Sussman กับทีมออกแบบ โปรเซสเซอร์แบบ programmable ที่ทำขึ้นเฉพาะ เพื่อคำนวณคุณสมบัติของวัตถุท้องฟ้า เช่น วิถีโคจร
    เนื้อหาชวนมึนตึ้บเหมือนเช่นเคย

  • SICP ทำให้ผมเข้าใจตั้งแต่เนิ่น ๆ ว่า มี programming model หลายแบบ ในช่วงที่ผมเรียนปริญญาตรีและเพิ่งรู้จักโมเดลอยู่จำกัดไม่กี่แบบ
    เป็นหนึ่งในหนังสือที่ทำให้รู้สึกว่าไม่ว่าจะอ่านเอกสารของภาษา ไลบรารี หรือเฟรมเวิร์กใด ก็น่าจะจับทิศทางได้

    • หนึ่งในวิชา programming ที่ดีที่สุดที่ผมเคยเรียนในมหาวิทยาลัยคือวิชา comparative programming languages ซึ่งเรียนหลายภาษา ภาษาละประมาณ 2 สัปดาห์

  • ข้าง ๆ SICP ผมยังจัดให้ซีรีส์ The Little * ทั้งชุดเป็นสื่อที่ควรอ่านมากกว่าหนึ่งรอบด้วย
    Types and Programming Languages ก็ดี
    สำหรับงานที่ผมทำ นี่คือวิทยาการคอมพิวเตอร์ที่นำไปใช้ได้จริง แต่แค่อ่านอย่างเดียวไม่ได้ ต้อง implement ด้วย
    ถ้าไม่ทวนซ้ำก็จะลืมบางส่วนไป
    โดยส่วนตัว อาจเพราะผมรู้จักและเคารพคนนั้นด้วย ผมจึงกลับไปอ่านหนังสือและบทความของ Dijkstra ซ้ำค่อนข้างบ่อย
    ทุกวันนี้นำไปใช้โดยตรงได้ยากแล้ว แต่ดีต่อสมอง และโดยส่วนตัวผมมองว่าเขาเป็นนักเขียนที่ยอดเยี่ยม