Lisp: เป็นไอซิงหรือเป็นเค้ก?

 (dthompson.us)
2 คะแนน โดย GN⁺ 2024-06-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Spring Lisp Game Jam 2024 มีการส่ง 48 เกม ทำสถิติใหม่ และผลงานที่ส่งเข้ามาแบ่งออกชัดเจนระหว่างแนวทางที่วาง Lisp ไว้ด้านบน กับแนวทางที่ทำให้สแต็กทั้งตัวเป็น Lisp
  • แนวทางไอซิง วาง Lisp เป็นชั้นสคริปต์บนโปรแกรมที่ใช้ C/Rust/Lua จึงสร้างผลลัพธ์ได้รวดเร็ว แต่ผูกติดกับภาษาเชิงสแตติกและ toolchain ชั้นล่างอย่างมาก
  • แนวทางเค้ก เขียนโปรแกรมส่วนใหญ่ด้วย Lisp และลดการใช้ C FFI ให้น้อยที่สุด จึงได้สิทธิ์ควบคุมที่ลึกกว่า แต่มีต้นทุนสูงขึ้นในการทำไลบรารี เขียน wrapper และ deploy บนเว็บ
  • ใน Game Jam นั้น Fennel+love2d และ S7+raylib ใกล้เคียงกับไอซิง ส่วน Guile+Chickadee เป็นเค้ก และ Hoot+HTML5 canvas ก็ใกล้เคียงกับเค้กมากกว่า เพราะมี toolchain Wasm ที่ใช้ Scheme เป็นฐาน
  • ยิ่งสัดส่วน Lisp มากขึ้น ก็ยิ่งเพิ่ม live hacking, ความปลอดภัยด้านหน่วยความจำ, ลดขอบเขต Lisp/C และเพิ่มความสามารถในการแฮ็ก โดยโปรเจกต์อย่าง Guix, Trial และ Pre-Scheme ก็แสดงทิศทางเดียวกัน

สถานะผลงานที่ส่งใน Spring Lisp Game Jam 2024

  • Spring Lisp Game Jam 2024 จบลงเมื่อหนึ่งสัปดาห์ก่อน และมีการส่ง 48 เกม สร้างสถิติใหม่ของ jam
  • หลังจากนั้น ผู้เข้าร่วมใช้เวลาหนึ่งสัปดาห์เล่นและให้คะแนนเกมของกันและกัน
  • การกระจายผลงานตามภาษาเป็นดังนี้
    • Guile: 15 เกม, 31%
    • Fennel: 10 เกม, 21%
    • Clojure: 5 เกม, 10%
    • Common Lisp: 5 เกม, 10%
    • Racket: 4 เกม, 8%
    • Elisp: 4 เกม, 8%
    • S7: 3 เกม, 6%
    • Kawa: 1 เกม, 2%
    • Owl: 1 เกม, 2%
  • สัดส่วน Guile: {p:31}
  • เหตุผลที่ไม่ได้รวม implementation ของ Scheme ไว้ในหมวด scheme เดียว คือสเปกของ Scheme มีขนาดเล็ก และ Guile, Racket, S7, Kawa เป็น implementation ที่มีวัตถุประสงค์ต่างกัน
  • ใน jam ครั้งนี้ Guile มีผลงานส่งมากที่สุดเป็นครั้งแรก
    • จากเกม Guile 15 เกม มี 11 เกมเป็นเกมเว็บที่สร้างด้วย Hoot
    • Hoot เป็นคอมไพเลอร์ Scheme-to-WebAssembly ที่ Spritely Institute กำลังพัฒนา
    • ใน 11 เกมนั้น มี 2 เกมเป็นโปรเจกต์ทางการของ Spritely
    • Spritely Institute ขอให้ลองสร้างเกมด้วย Hoot ก่อน jam เริ่ม และผู้เข้าร่วมจำนวนมากก็ตอบรับ
  • โดยทั่วไป ภาษาที่ได้รับความนิยมที่สุดใน jam นี้คือ Fennel ซึ่งเป็น Lisp ที่คอมไพล์เป็น Lua
  • เกม 3 เกมที่ใช้ S7 ก็เป็นกรณีตัวอย่างที่เชื่อมโยงกับวิธีใช้ Lisp ในการพัฒนาเกมเช่นกัน

วิธีใช้ Lisp เป็นไอซิง

  • แพตเทิร์นไอซิง คือแนวทางที่วาง Lisp เหมือนภาษาสคริปต์บน “เค้ก” ที่สร้างด้วยภาษาเชิงสแตติกอย่าง C หรือ Rust
  • โดยทั่วไปจะฝัง Lisp interpreter ไว้ในโปรแกรมที่ใหญ่กว่า
  • หากต้องการเขียนส่วนระดับสูงของแอปพลิเคชันด้วย Lisp นี่อาจเป็นเส้นทางที่เร็วที่สุด
    • ต้องมี interpreter หรือคอมไพเลอร์ที่เหมาะสม
    • ต้องมีวิธีเพิ่ม hook ที่แอปพลิเคชันต้องใช้ด้วย
  • หากส่วนหลักของโปรแกรมเขียนด้วย C หรือ Rust ก็สามารถคอมไพล์เป็น WebAssembly ด้วย emscripten เพื่อ deploy บนเว็บได้
  • สามารถได้ผลลัพธ์ที่น่าพอใจอย่างรวดเร็ว แต่จะผูกแน่นกับภาษาเชิงสแตติกและ toolchain ของภาษานั้น
  • ตัวอย่างสำคัญมีดังนี้
    • S7 คือ Scheme ที่ฝังได้
    • Guile ก็ใช้ขยายโปรแกรม C ได้ แต่โดยปกติจะ dynamic link กับ libguile มากกว่าจะใส่ interpreter เข้าไปในไฟล์ executable
    • Fennel ใช้ประโยชน์จากแอปพลิเคชันเดิมที่มีจุดขยาย Lua โดยคอมไพล์ภาษาที่คล้าย Lisp ให้เป็น Lua

วิธีใช้ Lisp เป็นเค้ก

  • แพตเทิร์นเค้ก คือแนวทางที่ implement สแต็กซอฟต์แวร์ให้เป็น Lisp มากที่สุดเท่าที่ทำได้
  • แทนที่จะใส่ Lisp เข้าไปในโปรแกรมที่ไม่ใช่ Lisp ก็เขียนโปรแกรมส่วนใหญ่ด้วย Lisp
  • หากจำเป็นก็เรียก shared library ผ่าน foreign function interface (FFI) แต่ควรลดการใช้นั้นให้น้อยที่สุด
  • ใช้เวลานานกว่าจะได้ผลลัพธ์
    • ต้อง implement ไลบรารีที่ไม่มีใน Lisp implementation ที่เลือกเอง
    • สำหรับ C shared library ที่หลีกเลี่ยงไม่ได้ ก็ต้องเขียน wrapper
    • โปรเจกต์ไม่ได้เป็น target ของ emscripten ได้ง่าย ทำให้การ deploy บนเว็บยากขึ้น
  • แนวทางนี้แตะกับข้อถกเถียงคลาสสิกเรื่อง embed vs. extend
  • Guile ใช้เป็นไอซิงได้เช่นกัน แต่จุดแข็งจะเด่นกว่าเมื่อใช้เป็นเค้ก
    • วิสัยทัศน์แรกเริ่มของ Guile คือทำให้โปรแกรมอื่นเหมือน Emacs ด้วยการเพิ่ม Scheme interpreter เข้าไป
    • แนวปฏิบัติที่ดีในปัจจุบันคือเขียนโปรแกรมด้วย Scheme ตั้งแต่ต้น
  • Common Lisp ก็เป็นตัวอย่างที่ดีของแนวทางเค้ก
    • implementation อย่าง SBCL ให้ C FFI ที่ดี
    • สามารถคอมไพล์เป็น executable แบบ native ที่มีประสิทธิภาพ จึงลดสถานการณ์ที่อยากใช้ C ด้วยเหตุผลด้าน performance

ไอซิงและเค้กจากกรณีตัวอย่างใน Game Jam

  • Fennel + love2d

    • love2d เป็นตัวเลือกยอดนิยมมายาวนานสำหรับการพัฒนาเกมโดยคนเดียวหรือทีมขนาดเล็ก
    • love2d เป็นโปรแกรม C++ ที่ฝัง Lua interpreter ไว้ จึงเป็น target ที่ดีของ Fennel
    • Linux distribution ส่วนใหญ่แพ็กเกจ love2d ไว้ จึงรันไฟล์ .love แบบ native ได้ง่าย
    • ด้วย emscripten จึงสามารถ deploy เกม love2d บนเว็บได้ด้วย
    • ดังนั้นเกม Fennel ส่วนใหญ่จึงใช้ love2d
    • ./soko.bin และ Gnomic Vengeance ใช้สแต็กนี้
    • Fennel+love2d เป็นตัวอย่างสมบูรณ์ของ Lisp as icing
    • Fennel อยู่บนสุดของสแต็ก และแทบไม่มีเส้นทางให้กระจาย Lisp ลงไปยังชั้นล่าง
    • จนถึงตอนนี้ นี่คือสแต็กพัฒนาเกม Lisp ที่ประสบความสำเร็จที่สุด

  • S7 + raylib

    • ใน jam ครั้งนี้ มีสองเกมคือ GhostHop และ Life Predictor ที่ใช้สแต็ก S7+raylib
    • Raylib เป็นไลบรารี C ที่มี binding สำหรับภาษาระดับสูงหลายภาษา และได้รับความนิยมมากขึ้นในช่วงไม่กี่ปีที่ผ่านมา
    • S7 ก็ implement ด้วย C และฝังได้ง่าย ทำให้ชุดผสมนี้ deploy บนเว็บด้วย emscripten ได้ง่าย
    • S7+raylib ก็เป็นกรณีของ Lisp as icing และน่าจับตาว่าจะได้รับความนิยมมากขึ้นใน jam ต่อ ๆ ไปหรือไม่

  • Guile + Chickadee

    • Chickadee เป็นไลบรารีเกมสำหรับ Guile และ implement ส่วนที่น่าสนใจเกือบทั้งหมด รวมถึง rendering ด้วย Scheme
    • ใน jam ล่าสุด มีสองเกมคือ Turbo Racer 3000 และ Bloatrunner ที่สร้างด้วย Chickadee
    • Guile+Chickadee เป็นกรณีของ Lisp as cake
    • Chickadee ห่อหุ้มไลบรารี C บางส่วนสำหรับงานระดับต่ำอย่างการโหลดรูปภาพ เสียง และฟอนต์ แต่โค้ดของตัวเองเขียนด้วย Scheme ล้วน
    • คณิตศาสตร์เมทริกซ์และเวกเตอร์ก็ implement ด้วย Scheme ทั้งหมด
    • มีชุด rendering primitive ที่เทียบได้กับ love2d และ raylib และสิ่งนี้ก็ implement ด้วย Scheme เช่นกัน
    • ขณะที่ไลบรารีเกม Lisp อื่น ๆ มักใช้ไลบรารี C อย่าง nanosvg แต่ Chickadee ก็มีความคืบหน้าในการ implement การ render กราฟิกเวกเตอร์ด้วย Scheme
    • Chickadee ผลักขีดจำกัดของคอมไพเลอร์และ virtual machine ของ Guile และระหว่างทาง Guile ก็ได้รับการปรับปรุงด้วย
    • อย่างไรก็ตาม เนื่องจากส่วนใหญ่พัฒนาโดยคนคนเดียวในเวลาว่างที่จำกัด จึงใช้เวลานานกว่าจะมีฟีเจอร์เทียบเท่าไลบรารีพัฒนาเกมที่ได้รับความนิยมกว่า
    • แม้ในสถานะปัจจุบัน ก็ทำงานได้ค่อนข้างดีสำหรับจุดประสงค์นั้น

  • Hoot + HTML5 canvas

    • Hoot เป็นคอมไพเลอร์ Scheme-to-WebAssembly
    • Hoot ไม่ได้นำ Guile VM ที่เขียนด้วย C ไปคอมไพล์เป็น Wasm ด้วย emscripten
    • แต่ implement toolchain Wasm แบบครบชุด และ backend ใหม่สำหรับคอมไพเลอร์ Guile ที่ emit Wasm โดยตรง
    • Hoot เขียนด้วย Scheme ทั้งหมด
    • ต่างจากโปรแกรม C ที่คอมไพล์ด้วย emscripten ซึ่ง target ไปยัง Wasm 1.0 แบบ linear memory, Hoot target ไปยัง Wasm 2.0 ที่มี heap type ซึ่งจัดการโดย GC
    • ด้วยโครงสร้างนี้ binary ของ Hoot จึง ไม่ deploy พร้อม garbage collector
    • จึงเล็กกว่า Lisp runtime ที่คอมไพล์ด้วย emscripten มาก
    • Wasm binary ของเกม Hoot เกมหนึ่งมีขนาดต่ำกว่า 2MiB และ love.wasm ของเกม love2d ที่ตรวจสอบมีขนาดเกือบ 6MiB
    • โปรแกรม Hoot ทำงานร่วมกับ JavaScript ได้ง่าย
      • ส่ง object ของ Scheme ไปยัง JavaScript ได้ง่าย
      • ส่ง object ของ JavaScript ไปยัง Scheme ได้ด้วย
      • เพราะ object ทั้งสองฝั่งถูกจัดการใน heap เดียวกัน
    • Browser API เข้าถึงได้ผ่าน Wasm import ดังนั้นสำหรับเกมแล้ว API HTML5 canvas ที่มีในตัวจึงเป็นตัวเลือก rendering 2D ที่ง่าย
    • ใน jam ครั้งนี้มีเกมที่ใช้ Hoot 11 เกม รวมถึง Cirkoban และ Lambda Dungeon
    • Hoot+HTML5 canvas เป็นรูปแบบที่ส่วนใหญ่เป็นเค้กหนา ๆ และมีไอซิงบางส่วนผสมอยู่
    • การบูต Hoot ใช้เวลา 1 ปีและเงินทุนจำนวนมาก
    • ไม่ได้ใช้ emscripten แต่สร้าง toolchain ของตัวเอง และขยายคอมไพเลอร์ Guile ด้วย
    • ยังมี Wasm interpreter ที่ทำงานบน Guile VM ด้วย
    • ในทางกลับกัน canvas API เป็นระดับสูงมาก
    • วิธีที่ใกล้เคียงกับเค้กมากกว่าคือเรียก WebGL หรือ WebGPU ผ่าน JS FFI ของ Hoot
    • แผนในอนาคตอยู่ที่ฝั่ง WebGL/WebGPU และเพื่อให้ทำได้ จำเป็นต้องปรับปรุง Wasm GC
    • เป้าหมายอีกอย่างคือ port Chickadee ไปยัง Hoot เพื่อให้เกม Chickadee เล่นได้ง่ายทั้งแบบ native และในเบราว์เซอร์เหมือนเกม love2d

ข้อจำกัดและข้อดีของแนวทางเค้ก

  • แนวทางเค้กก็มีข้อจำกัดชัดเจน
  • สภาพแวดล้อมสมัยใหม่ไม่ใช่โลกของ Lisp machine และแม้แต่เค้ก Lisp ที่สูงที่สุด ส่วนใหญ่ก็ยังวางอยู่บนเค้กที่ใหญ่กว่าซึ่งทำจาก C
  • ระบบ Lisp สมัยใหม่จะไปแตะชั้นล่างในบางจุด
    • Emacs อยู่บน C core
    • Guile VM เขียนด้วย C
    • Hoot รันบน JavaScript engine ขนาดใหญ่ที่ใช้ C++ เป็นฐาน เช่น V8
    • เกม Hoot ในปัจจุบัน render ด้วย HTML5 canvas ไม่ใช่ WebGL/WebGPU
    • การใช้ OpenGL ต้องใช้ libGL
    • Chickadee ใช้ guile-opengl ซึ่งเรียก libGL ผ่าน C FFI
    • ยังมี libpng, FreeType และอื่น ๆ
  • ปัญหาด้านทรัพยากรมีมากเกินไปที่จะเขียนทุกอย่างใหม่ด้วย Lisp
  • ถึงอย่างนั้น การยึดบางส่วนของสแต็กกลับมาจากภาษาอย่าง C ก็เป็นชัยชนะเล็ก ๆ
  • ส่วนที่เขียนด้วย Lisp แฮ็กได้ง่ายกว่า และบางส่วนยังทำ live hacking ระหว่างที่โปรแกรมกำลังรันได้ด้วย
  • โดยทั่วไป runtime ที่จัดการด้วย GC ให้ความปลอดภัยด้านหน่วยความจำ
  • เมื่อการเรียก FFI ลดลง overhead จากการข้ามขอบเขต Lisp/C ก็ลดลง และความปลอดภัยก็สูงขึ้นด้วย
  • ยิ่งสัดส่วน Lisp ในสแต็กมากขึ้น ก็ยิ่งใกล้เคียงกับเค้กมากกว่าไอซิง

ตัวอย่างเค้กนอกเหนือจากเกม

  • Guix เป็นตัวอย่างที่ดีว่าแนวทางเค้กทรงพลังได้เพียงใด
  • Guix นำโมเดล functional packaging ของโปรเจกต์ Nix มา implement ใหม่ โดยแทนที่ภาษา Nix ด้วย Guile
  • เหตุผลคือ code staging, การแชร์โค้ด และการเพิ่มความสามารถในการแฮ็ก
  • Guix ยังใช้ init system ที่เขียนด้วย Guile แทน systemd และตัวเลือกนี้ก็มาจากเหตุผลเดียวกัน
  • ในช่วงแรก Guix ถูกวิจารณ์ได้ง่ายว่าเป็นการสร้างล้อขึ้นใหม่โดยไม่มีเหตุผล แต่หลังผ่านไป 10 ปี ความดื้อดึงในการใช้ Lisp ให้มากที่สุดกลายเป็นหัวใจของความสำเร็จของโปรเจกต์
  • เมื่อผู้ใช้เรียนรู้ idiom ของ Guix และ Guile เล็กน้อย ก็จะได้ความสามารถอันทรงพลังในการปรับแต่งระบบปฏิบัติการตามต้องการ
  • Guix อาจมองได้ว่าเป็นประสบการณ์ที่ใกล้เคียง Lisp machine ที่สุดบนฮาร์ดแวร์สมัยใหม่
  • ฝั่ง Common Lisp มี game engine Trial เป็นกรณีที่ implement หลายส่วนด้วย Common Lisp แทนที่จะห่อหุ้มไลบรารี C
  • โปรเจกต์อย่าง Pre-Scheme ทำให้คาดหวังได้ว่าสักวันหนึ่งชั้นที่อยู่ใต้ runtime ที่จัดการด้วย GC ก็อาจ implement ด้วย Lisp ได้เช่นกัน
    • Pre-Scheme พัฒนาและใช้งานสำเร็จใน Scheme 48
    • ด้วย NLnet grant จึงคาดหวังการฟื้นคืนชีพในแบบสมัยใหม่ได้

ทิศทางสู่การสร้างสแต็กด้วย Lisp ให้มากขึ้น

  • ทิศทางนั้นใกล้เคียงกับ เค้ก
  • จำเป็นต้องมีโปรเจกต์มากขึ้นที่ผลักขอบเขตของสิ่งที่ Lisp ทำได้ต่อไป
  • สิ่งที่น่าสนใจที่สุดใน Lisp Game Jam ไม่ใช่ตัวเกมเอง แต่เป็นความคืบหน้าเล็ก ๆ ในการยึดเค้กคืนมาหนึ่งชิ้นจาก C ที่เก่าและแห้งแล้ง
  • ในการพัฒนาเกมด้วย Guile จะพยายามผลักขีดจำกัดต่อไปผ่านโปรเจกต์ Chickadee
  • ข้อสรุปไม่ใช่การเขียนใหม่ด้วย Rust แต่คือ การเขียนใหม่ด้วย Lisp

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

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

 
GN⁺ 2024-06-03
ความคิดเห็นจาก Hacker News

  • รู้สึกยินดีเป็นพิเศษเพราะช่วงนี้แทบไม่เห็นบทความที่ เปรียบเทียบแนวทางด้านซอฟต์แวร์ แบบเป็นกลางเลย
    ต่อให้พยายามหาบทความแนวนั้น เดี๋ยวนี้ผลค้นหาก็มักแพ้ สแปม SEO อยู่บ่อย ๆ
    Janet ดูเหมือนถูกสร้างมาสำหรับเกม และก็ดูมีองค์ประกอบแบบ “มีแบตเตอรี่มาพร้อมใช้” อย่างเว็บเซิร์ฟเวอร์หรือกราฟิกมากกว่าที่คิด เลยแปลกใจนิดหน่อยที่ไม่ค่อยเห็นเกมที่ใช้ Janet
    มองว่าเป็นภาษาที่น่าลองดูสักครั้งสำหรับสาย Lisp และงานเกม

  • ดีใจที่ s7 ได้รับความสนใจ
    เคยใช้เขียน Scheme ใน Scheme for Max ซึ่งเป็นส่วนขยายโอเพนซอร์สที่ใส่ Scheme interpreter ลงในสภาพแวดล้อมดนตรีคอมพิวเตอร์ Max/MSP และมันอยู่กึ่งกลางระหว่าง Guile, Clojure และ Common Lisp ขณะเดียวกันก็เล็กมากและฝังใช้งานได้ง่าย
    อีกข้อดีคือใช้ ไลเซนส์ BSD ที่ผ่อนปรนกว่าของ Guile มาก
    ถ้าชอบแมโครของ Common Lisp ที่มี environment แบบ first-class ก็มีโอกาสสูงที่จะชอบ s7 ด้วย
    มันใช้งานบน WASM ได้ง่ายมาก และกำลังใช้แบบนั้นอยู่ในโปรเจ็กต์ด้านการศึกษาดนตรี
    การทำฟังก์ชันทั่วไปสำหรับเรียกฟังก์ชัน JS จาก Scheme และเรียก Scheme จาก JS ย้อนกลับก็ไม่ยาก ทำให้โฟลว์โดยรวมลื่นมาก

    • ขอเพิ่มอีกหนึ่งเสียงให้ s7
      เคยฝัง s7 กับ SQLite เป็นเอนจินที่ไม่รวมกราฟิกในแอปเนทีฟบน iOS และ Android ได้สำเร็จ
      มันเร็วมาก, FFI ดี, เสถียร, ขนาดเล็ก และได้ประโยชน์อย่างมากจากโค้ดที่แชร์กันระหว่างแอปมือถือ, unit test ที่เร็วมาก และชุดเครื่องมือที่สะอาด
      สุดท้ายย้ายไปใช้ Fennel ซึ่งเป็น Lisp ที่ใช้งานได้จริงกว่าสำหรับมือถือ
      ตอนนั้นแทบมีแค่ทีมเราที่ใช้ s7 บนมือถือ ขณะที่ Lua พบได้ทั่วไปกว่ามากในฐานะภาษาสำหรับขยายความสามารถบนมือถือ และสถานะความเข้ากันได้กับ r7rs Scheme ก็มีผลด้วย
      ตอนพัฒนาบนเดสก์ท็อปใช้ Guile แต่ตอนปล่อยใช้งานใช้ s7 เลยเจอความไม่เข้ากันแบบละเอียดอ่อนอยู่บ่อย ๆ เช่น ลำดับการประเมินพารามิเตอร์
      ทั้ง s7 และ Fennel ต่างก็มีโปรเจ็กต์และชุมชนที่ยอดเยี่ยม

  • ขอแนะนำ Spritely Institute เป็นพิเศษ รวมถึงบล็อกของที่นั่นด้วย
    ไม่อยากสปอยล์ว่าที่นี่ทำอะไร แต่เป็นทั้งหัวข้อและองค์กรที่คุ้มค่ากับการขุดลึก
    แค่อ่านบล็อก ลิงก์ที่เกี่ยวข้อง และโปรเจ็กต์ต่าง ๆ ก็ใช้เวลาไปมากกว่า 10 ชั่วโมงแล้ว
    https://spritely.institute/archive/

    • ดูเหมือนเป็นที่ที่ดึงดูดคนเก่ง ๆ และกำลังทำสิ่งที่เจ๋งมากพอสมควร

  • สรุปที่ว่า “เราไม่ได้อยู่ในโลกของเครื่อง Lisp แต่เราอยู่ในโลกของ PDP-11 ที่ถูกแต่งให้ดูดี” น่าประทับใจมาก
    แต่ก็สงสัยว่ามี “icing” ที่ใช้ร่วมกับ sdl ด้วยไหม

    • จะเรียก CPU แบบดั้งเดิมว่า PDP-11 ที่ถูกแต่งให้ดูดี ก็คงไม่ค่อยถูกนัก
      มันคล้ายกันตรงที่เป็นเครื่องแบบ von Neumann ที่ใช้หน่วยความจำไม่มี tag แต่ตั้งแต่ราวกลางทศวรรษ 80 ที่ไมโครโปรเซสเซอร์ 32 บิตกลายเป็นเรื่องปกติและเทคโนโลยีคอมไพเลอร์ Lisp พัฒนาไปตามนั้น CPU แบบดั้งเดิมก็เริ่มแซงเครื่อง Lisp แล้ว
      ส่วนเรื่อง “หน่วยความจำไม่มี tag” เองก็ดูไม่แน่ว่าจะอยู่ต่อไปเสมอ เมื่อดูแนวทางอย่าง CHERI และก็ยังมีโอกาสที่ สถาปัตยกรรมสไตล์ LispM จะกลับมาแบบจริงจังได้
    • ชอบ PDP-11 มากจริง ๆ
      เคยวาง PDP-11/45 ไว้ในห้องนั่งเล่นอยู่หลายปี ก่อนจะเปลี่ยนทีหลังเป็น H-11 LSI-11/2 หลายเครื่องที่มีฟลอปปีดิสก์ 8 นิ้วสองตัวเพื่อประหยัดพื้นที่
      PDP-11 ไม่ได้เป็นแค่ต้นแบบดั้งเดิมของ Unix เท่านั้น แต่ยังออกแบบมาได้ดีในเชิงแนวคิดด้วย
      เหมือนที่เราชอบรูทีนที่ “พอดีหนึ่งหน้าจอ” พื้นที่ address ตรงแบบเล็ก ๆ ของ PDP-11 ก็ช่วยบังคับให้โมดูลไม่ใหญ่เกินไปและส่งเสริมความเป็นโมดูลาร์
      ทุกวันนี้มันไม่พอไหม? แน่นอน โดยเฉพาะกับบิ๊กดาต้าที่ทรมานมาก
      แต่ที่ PDP-11 ประสบความสำเร็จและยังทิ้งร่องรอยมาถึงตอนนี้ ก็มีเหตุผลเชิงแนวคิดอยู่
    • น่าแดกดันที่ตอนนี้เรากำลังมุ่งไปสู่เครื่อง C ที่มี การทำ memory tagging ในฮาร์ดแวร์
      เพราะไม่มีวิธีอื่นที่จะซ่อม C ได้ และมีโค้ดจำนวนมากเกินไปที่คงไม่มีวันถูกเขียนใหม่
    • ชอบช่วงท้ายมากกว่า: “จะให้เขียนใหม่ด้วย Rust เหรอ? ไม่มีทาง! เขียนใหม่ด้วย Lisp สิ!”
    • Lisp ไม่เหมาะกับ CPU สมัยใหม่เพราะ ลำดับชั้นของหน่วยความจำ
      Lisp มักจัดการกับลิสต์เป็นหลัก และลิสต์สามารถพาไปไล่ pointer ทั่วทั้งหน่วยความจำได้
      บน CPU รุ่นเก่า หน่วยความจำโดยมากมีเวลาเข้าถึงแบบสุ่มที่ใกล้เคียงกันจึงไม่ใช่ปัญหา แต่ CPU สมัยใหม่ไม่สามารถไล่ตาม memory pointer ได้ด้วยความเร็วเท่าเดิม และต้องทำตามกฎเรื่อง locality เพื่อให้ได้ประสิทธิภาพ
      เพราะแบบนั้น อัลกอริทึมที่ใช้สิ่งอย่างอาร์เรย์ใน C หรือ Fortran จึงย่อมเร็วกว่าฉบับที่อิงลิสต์ของ Lisp เสมอ

  • รู้สึกตื่นเต้นกับความคืบหน้าล่าสุดของ Guile Scheme
    ต่างจากตอนที่เห็นครั้งล่าสุด มันกลายเป็นภาษาที่มีคอมไพเลอร์จริงจัง ไม่ได้เป็นแค่ภาษาอินเทอร์พรีเตอร์อีกต่อไป และตอนนี้ก็สามารถคอมไพล์เป็น WASM ได้ด้วย Hoot
    คุ้นเคยกับ Clojure, uLisp และ Common Lisp อยู่แล้ว แต่ Guile Scheme ให้ความรู้สึกเหมือน Common Lisp ที่ตัดส่วนเกินออกไปเยอะ และโดยเฉพาะถ้า Guix กับ Shepard ลงหลักปักฐานได้ ก็อยากมี Lisp แบบคอมไพล์ได้ไว้ใช้งาน
    สงสัยว่ามีแหล่งเรียนรู้ดี ๆ สำหรับเรียน Guile Scheme อย่างมีประสิทธิภาพนอกจาก Little Lisper กับ SICP ไหม

  • กำลังคิดจะลองใช้ Guile กับสิ่งที่จะทำต่อจากนี้อยู่พอดี เลยอ่านอย่างเพลิน
    งานฝั่ง WASM ก็ดูออกมาดีด้วย

  • ไม่นานมานี้ได้ทำต้นแบบบอสไฟต์ 3D ด้วย Clojure: https://prototype-game.pages.dev

    • ยอดเยี่ยมมาก
      แต่ก่อนเคยเกลียดการพัฒนาเว็บทุกรูปแบบ แต่ ClojureScript ทำให้มันสนุกได้จริง และอยากให้ถูกใช้อย่างแพร่หลายกว่านี้
    • บนมือถือบังคับไม่ได้
      ไว้จะลองใหม่อีกทีตอนอยู่หน้าพีซี
    • เจ๋งมาก
      อยากรู้ว่าใช้ไลบรารีอะไรอยู่
    • พูดด้วยความรักต่อสิ่งที่ทำขึ้นมา มันทำให้นึกถึง Avatar - Legends of the Arena
      เป็นหนึ่งในเกมที่ชอบมากจริง ๆ ตอนเด็ก
      https://www.youtube.com/watch?v=dcJFldES9dg

  • มีการขอให้ใส่ลงในตารางแล้ว แต่ตอนนี้อาจเป็นข่าวเก่าไปแล้วก็ได้
    อ้างอิง:
    https://lispy-gopher-show.itch.io/logos-lisp-legend/devlog/7...
    https://itch.io/post/10013482

  • ทั้งที่มี https://ianthehenry.com/posts/janet-game/ แต่ Janet กลับไม่ถูกใส่มา
    แม้ว่าปีลิขสิทธิ์ของบทความจะระบุเป็น 1899~1907 แต่ก็น่าเสียดายที่มันไม่ได้ดูวินเทจขนาดนั้น

    • ดูเหมือนว่า Janet จะตกหล่นไป
      สำหรับงานสคริปต์ ตอนนี้กลับไปใช้ Fennel อีกครั้ง เพราะสามารถหยิบไลบรารี Lua จำนวนมากมาใช้ได้ทันที และรันได้แทบทุกที่โดยไม่มีปัญหา แม้แต่บน a-Shell ของ iPad
    • เคยพิจารณา Janet อย่างจริงจังมาก แต่ไม่เห็นเส้นทางตรงไปสู่เป้าหมายอย่างเว็บแอปและ WebGL (ThreeJS)
      ในเธรดนี้มีข้อมูลอ้างอิงที่มีประโยชน์ และอาจกลับมาลองอีกครั้งในภายหลังได้: https://janet.zulipchat.com/#narrow/stream/409517-help/topic...
      ทั้งที่มีเส้นทางสู่โปรดักชันที่พิสูจน์แล้วอยู่แล้ว แต่ก็ยังทำอะไรบางอย่างที่พอเล่นได้เสร็จทันเวลาแบบเฉียดฉิว และคำว่า “พอเล่นได้” ก็อาจจะชมเกินไปหน่อยด้วยซ้ำ

  • อยากรู้มากว่าเขาสร้างเกมอะไรด้วย Emacs Lisp
    ไม่ใช่ตัวเลือกแรกที่นึกถึงเมื่อนึกถึงการเขียนโปรแกรมเกม

    • GNU Emacs มีเกมผจญภัยแบบข้อความ Dunnet ติดมาให้เป็นค่าเริ่มต้น
      เดิมที Dunnet เขียนโดย Ron Schnell ในปี 1982 เป็นโปรแกรม Maclisp ที่ทำงานบน TOPS-20
      ในปี 1992 มันถูกพอร์ตมาเป็น Emacs Lisp แต่ไม่ได้เป็นแค่การพอร์ตอย่างเดียว เพราะมีการเพิ่มห้อง ไอเท็ม และปริศนาใหม่ ๆ และลบเนื้อหาที่อิงกับ MIT ออก
      ตัวอย่างเช่น คอมพิวเตอร์ “endgame” ช่วงท้ายเกม เดิมอยู่ที่ MIT และใช้ชื่อ MIT-SALLY โดยเข้าถึงผ่าน Chaosnet แต่ในเวอร์ชัน GNU Emacs ได้ลบการอ้างอิง MIT แบบเก่าเหล่านี้ออก
      แทนที่ด้วยสิ่งอย่าง VAX 11/780 ที่คนรู้จักกันกว้างกว่า แต่ก็ยังจงใจคงบรรยากาศตามยุคสมัยไว้
      https://en.wikipedia.org/wiki/Dunnet_(video_game)
      ต้นฉบับอยู่ที่นี่: https://github.com/Quogic/DunnetPredecessor/blob/master/foo....
    • https://bcardoso.itch.io/shoggy
      https://lcolonq.itch.io/slgj2024-game-boy-gizmo
      https://asquared31415.itch.io/disassembly
      https://grindingstone.itch.io/pendulum
    • ในชุดติดตั้งพื้นฐานมี snake และ tetris มาด้วย
    • Malyon เป็นอินเทอร์พรีเตอร์ Z-machine และโดยรวมแล้วทำงานได้ดี