การทำ abstraction ในซอฟต์แวร์กำลังทำลายอารยธรรมหรือไม่? (2021)

 (datagubbe.se)
2 คะแนน โดย GN⁺ 2025-02-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประเด็นกังวลของ Jonathan Blow ที่ว่า “abstraction ทำให้ความสามารถในการบำรุงรักษาซอฟต์แวร์ที่จำเป็นอ่อนแอลง” นั้นมีน้ำหนักในแง่ของ การถ่ายทอดความรู้ แต่ตัวอย่างจำนวนมากที่เขายกมาประกอบกลับตีความประวัติศาสตร์และบริบทผิดไป
  • ข้อถกเถียงเรื่อง “five nines”, ซอฟต์แวร์ที่แข็งแกร่ง, การชะงักงันของความก้าวหน้าทางเทคโนโลยี และผลิตภาพที่ลดลง มักไม่แยกแยะระหว่าง อุปกรณ์ผู้บริโภคกับระบบความพร้อมใช้งานสูง หรือพึ่งพาตัวอย่างที่เลือกมาเป็นบางส่วน
  • ความกังวลเรื่องการสูญเสียความรู้ระดับต่ำมีเหตุผลอยู่บ้าง แต่ C, assembly, Rust, การพอร์ตระบบปฏิบัติการ, การศึกษาด้านคอมไพเลอร์ และกิจกรรมโอเพนซอร์สยังคงเป็นช่องทางรักษา ขีดความสามารถเชิงระบบ อยู่
  • abstraction อย่างระบบปฏิบัติการ, ระบบไฟล์, เครือข่าย, multitasking และ framework เพิ่มความซับซ้อนก็จริง แต่ก็ช่วยรองรับการเปลี่ยนแปลงของฮาร์ดแวร์และความคาดหวังของผู้ใช้ พร้อมทั้งเพิ่ม ความสามารถในการพอร์ต·ผลิตภาพ·การเข้าถึงการสร้างสรรค์
  • ความเสี่ยงที่ใหญ่กว่า abstraction เองคือ churn อย่างต่อเนื่อง, แพลตฟอร์มที่ถูกล็อก, โฆษณา·tracker·telemetry, และการอ่อนแอลงของความเป็นส่วนตัวกับเสรีภาพ ขณะเดียวกันก็ต้องรักษาฐานทักษะทางเทคนิคสำหรับดูแลระบบสำคัญต่อไป

จุดยืนพื้นฐานต่อข้อกล่าวอ้างของ Blow

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

ข้อถกเถียงเรื่อง “five nines” และความแข็งแกร่ง

  • Blow อ้างว่าในอดีตการขายระบบคอมพิวเตอร์ใช้ “five nines” หรือ เวลาทำงาน 99.999% เป็นถ้อยคำด้านคุณภาพ แต่แล็ปท็อปในปัจจุบันทำไม่ได้ถึงระดับนั้น
  • ข้อที่ว่า five nines หมายถึง downtime ประมาณ 5 นาทีต่อปีนั้นถูกต้อง แต่ข้ออ้างว่าตัวชี้วัดนี้เคยใช้ขายแล็ปท็อปผู้บริโภคหรือโปรแกรมประมวลผลคำนั้นน่าจะผิด
    • five nines มักใช้กับด้านต่าง ๆ เช่น ศูนย์รับแจ้งเหตุฉุกเฉินแบบ 911, ระบบโรงพยาบาล, การประมวลผลธุรกรรมทางการเงิน
    • มักใช้ควบคู่กับสัญญาระยะยาวที่กำหนดรายละเอียดว่าสถานการณ์ใดไม่นับเป็น downtime
    • บริษัทอย่าง IBM และ Amazon ยังขายระบบและบริการลักษณะนี้อยู่
  • ข้อกล่าวอ้างว่าไม่มีซอฟต์แวร์ที่แข็งแกร่งออกมาเป็นเวลาหลายสิบปีก็มีตัวอย่างโต้แย้ง
    • iPhone สามารถทำงานได้หลายสัปดาห์หรือหลายเดือนโดยไม่ต้องรีบูต
    • เซิร์ฟเวอร์ไฟล์และพรินต์ของ Novell มีกรณี uptime 16 ปี
    • อุปกรณ์ Unix, Windows, VMS และระบบ turnkey อย่าง IBM i ก็ถูกกล่าวถึงเป็นกรณีของความพร้อมใช้งานระยะยาว

การโต้แย้งเรื่องความก้าวหน้าทางเทคโนโลยีและผลิตภาพ

  • เห็นด้วยบางส่วนกับคำกล่าวที่ว่า “บริษัทเทคโนโลยีไม่ผลักดันเทคโนโลยีอีกต่อไป” แต่บริษัทที่ให้ความสำคัญกับเงินมากกว่าก็มีมาตั้งแต่อดีตแล้ว
  • ด้านที่ดู “น่าเบื่อ” อย่างระบบไฟล์, เว็บเซิร์ฟเวอร์, ฐานข้อมูล และภาษาโปรแกรมมิง ก็ยังคงถูกพัฒนาและปรับปรุงต่อไป
  • ชั้น abstraction, virtualization และ containerization ที่ Blow ไม่ชอบเองก็ได้รับการปรับปรุงผ่านความพยายามจำนวนมาก และไม่ได้กลายเป็น สิ่งที่ไม่ใช่ความก้าวหน้าทางเทคโนโลยี เพียงเพราะไม่ชอบมัน
  • ข้อกล่าวอ้างว่าผลิตภาพของพนักงาน Facebook เข้าใกล้ศูนย์นั้นตั้งอยู่บนสมมติฐานที่มองผลิตภัณฑ์ของ Facebook แค่ในฐานะฟังก์ชันของแพลตฟอร์มโซเชียล
    • พนักงานของบริษัท Facebook รวมงานหลากหลาย เช่น กฎหมาย, บัญชี, กราฟิกดีไซน์, การดูแลระบบ, วิจัย, HR, ผู้จัดการระดับกลาง
    • ยังมีธุรกิจอื่นอย่าง Instagram, WhatsApp และ Oculus VR
    • ผลิตภัณฑ์จริงของ Facebook คือแพลตฟอร์มส่งโฆษณา และงานเก็บข้อมูลส่วนบุคคลกับข้อมูลส่วนตัวเพื่อแปลงเป็นโฆษณาแบบกำหนดเป้าหมาย แม้ผู้ใช้จะไม่เห็นเป็นฟังก์ชัน แต่ก็ปรากฏเป็นรายได้

ความรู้ระดับต่ำและสองด้านของ abstraction

  • ยอมรับว่าเป็นความจริงที่โปรแกรมเมอร์จำนวนมากชอบสภาพแวดล้อมที่ไม่ต้องจัดการ memory allocation และ pointer
  • มองว่า abstraction ที่มากเกินไป เช่น การใช้ JavaScript framework ที่ไม่จำเป็นเพื่อเรนเดอร์บล็อกเรียบง่าย หรือแอปเดสก์ท็อปที่ทำงานช้าอยู่ในเบราว์เซอร์ที่ bundled มา เป็นปัญหา
  • อย่างไรก็ตาม จำนวนคนที่ใช้ C ได้ในปัจจุบัน และปริมาณโค้ด C·assembly ที่เขียน อาจมากกว่าในอดีต
    • Linux และ NetBSD ยังคงถูกพอร์ตไปยังเป้าหมายหลากหลายที่ดูเหมือน CPU
    • Rust มุ่งเน้นความแข็งแกร่ง ขณะเดียวกันก็ให้ pointer และการจัดการหน่วยความจำ
    • Harvard CS50 สอนเรื่อง memory layout, pointer, malloc(), free() ผ่านคอร์สสาธารณะ
  • Garbage collection และ functional programming ไม่ใช่ abstraction ใหม่
    • Lisp ให้ทั้งสองอย่างมาตั้งแต่ปลายทศวรรษ 1950
    • Lisp ยังถูกใช้ในสภาพแวดล้อม “ฮาร์ดคอร์” อย่าง NASA Jet Propulsion Lab
  • COBOL ไม่ได้ถูกกล่าวถึงในการบรรยายของ Blow แต่เป็นภาษาระดับสูงที่เป็นรากฐานของโครงสร้างพื้นฐานธนาคารและการเงิน และมีบทบาทสำคัญต่อระดับอารยธรรมปัจจุบัน

กรณี “Unix 3 สัปดาห์” ของ Ken Thompson

  • การที่ Ken Thompson สร้าง assembler, editor และ kernel พื้นฐานได้ใน 3 สัปดาห์ถือเป็นผลงานที่โดดเด่นมาก
  • อย่างไรก็ตาม ซอฟต์แวร์ ณ เวลานั้นแข็งแกร่งแค่ไหน เป็นมิตรต่อผู้ใช้เพียงใด และมีฟีเจอร์อะไรบ้างนั้นไม่ชัดเจน
  • เงื่อนไขการทำงานในตอนนั้นต่างจากเงื่อนไขของนักพัฒนาปัจจุบันอย่างมาก
    • ปัจจุบันการพัฒนามีองค์ประกอบอย่างเอกสาร, code review, daily standup, การจัด backlog, user story, unit test, ความต้องการของลูกค้า, A/B test, commit message, มาตรฐานการเขียนโค้ดขององค์กร
    • สภาพแวดล้อมแบบ open office ที่ถูกรบกวน กับสภาพแวดล้อมการทำงานส่วนตัวแบบ Bell Labs ก็อาจแตกต่างกัน
  • กรณีของ Thompson เพียงกรณีเดียวไม่ใช่หลักฐานว่าโปรแกรมเมอร์ในอดีตโดยรวมมีผลิตภาพสูงกว่า
    • Thompson ยังเคยเข้าร่วม Multics ซึ่งขึ้นชื่อเรื่องความล่าช้า
    • โครงการใหญ่ ๆ อย่าง IBM OS/360 ก็ล่าช้าเป็นเวลานาน และ Frederick P. Brooks เขียนหนังสือ 『The Mythical Man-month』 ในปี 1975 จากประสบการณ์เหล่านี้

ความก้าวหน้าของซอฟต์แวร์และความคาดหวังของผู้ใช้

  • โดยรวมแล้วคอมพิวเตอร์แข็งแกร่งกว่าหลายสิบปีก่อน และโปรแกรมเมอร์ก็น่าจะมีผลิตภาพอย่างน้อยเท่าอดีต
  • แต่ในบางกรณี การเริ่มต้นทำงานซับซ้อนขึ้น ซึ่งอาจลดผลิตภาพช่วงแรกได้
  • ผู้ใช้ยุคใหม่ไม่อยากเรียน RPN เพื่อคำนวณเลขง่าย ๆ หรือเขียน directive ของ troff เพื่อทำใบปลิว
  • อินเทอร์เฟซที่สะดวกและฟีเจอร์ขั้นสูงเพิ่มความซับซ้อนและเวลาพัฒนา ไม่ว่าจะเกี่ยวกับ abstraction หรือไม่ก็ตาม
  • กรณีใน Amiga OS รุ่นเก่าที่เครื่อง crash ระหว่างคัดลอกไฟล์และทำให้พาร์ทิชันฮาร์ดไดรฟ์เสียหาย แสดงให้เห็นว่าระบบในอดีตไม่ได้เสถียรกว่าเสมอไป
    • OS สำหรับคอมพิวเตอร์บ้านยุคใหม่มี memory protection และ journaling file system ทำให้ปัญหาแบบเดียวกันเกิดขึ้นน้อยกว่ามาก
    • Windows 10 Home ก็มีข้อบกพร่อง แต่ก็รวมความก้าวหน้าเหล่านี้ไว้ด้วย

ข้ออ้างว่า “เมื่อก่อนทำได้เลย”

  • การคัดลอกและรันโปรแกรม

    • การคัดลอกโปรแกรมจากคอมพิวเตอร์เครื่องหนึ่งไปยังอีกเครื่องหนึ่งแล้วรัน ยังคงทำได้หากเป็นสถาปัตยกรรมเป้าหมายและเงื่อนไขการคอมไพล์เดียวกัน
    • มีกรณีที่ไบนารีแบบ static link ของ slack-term ที่ build ด้วย Go ทำงานได้บน Raspberry Pi หลายเครื่อง
    • อย่างไรก็ตาม ช่วงเวลาที่โปรแกรมแบบ standalone เป็นเรื่องทั่วไปต้องย้อนกลับไปถึงยุค C64 หรือ PC/XT และแม้แต่ Deluxe Paint IV บน Amiga ก็พึ่งพาไฟล์เสริมหลายไฟล์และไลบรารีฟังก์ชัน third-party
    • เกม Amiga บางเกมใช้ฟลอปปีดิสก์แบบ track-loaded ที่ข้ามระบบไฟล์ ทำงานคล้าย container แบบยุคนั้น แต่มีข้อเสียคือขัดขวางการติดตั้งลงฮาร์ดดิสก์และ multitasking

  • ข้ออ้างว่าแค่ CPU เหมือนกันโค้ดก็รันได้

    • คำกล่าวที่ว่าหากอยู่บน CPU เดียวกัน แค่โหลด machine code เข้า memory แล้วชี้ program counter ก็อาจรันได้นั้นเป็นไปได้ในเชิงทฤษฎี
    • แต่สำหรับงานจริงอย่างการแสดงผลกราฟิก, การเล่นเสียง, การรับ input, การเขียนดิสก์ ความแตกต่างของฮาร์ดแวร์เป็นปัญหาใหญ่
    • คอมพิวเตอร์บ้านที่ใช้ Z80 ในอดีต แม้ CPU เหมือนกัน แต่ฮาร์ดแวร์รอบข้างต่างกัน ทำให้การพอร์ตจริงทำได้ยาก
    • กลับกัน โปรแกรมที่มีระดับ abstraction สูงกว่าอย่าง Basic สามารถพอร์ตข้ามเครื่องหลายแบบได้ง่ายกว่า
    • เมื่อ Apple เปิดตัวเดสก์ท็อปไลน์ที่ใช้ ARM การพึ่งพา abstraction แทนการผูกติดกับฮาร์ดแวร์โดยตรงอาจลดภาระการพอร์ตไปยัง CPU ใหม่

  • ระบบปฏิบัติการและการเข้าถึงฮาร์ดแวร์

    • ระบบปฏิบัติการไม่ได้แค่แย่งความสามารถของ CPU ไป แต่เพิ่มความสามารถอย่างระบบไฟล์, networking และ multitasking
    • ผู้ใช้อย่าง Twitch streamer ที่ต้องรันเกมพร้อมโปรแกรมอื่น ต้องการ multitasking ที่แบ่งใช้ทรัพยากรฮาร์ดแวร์อย่างถูกจัดการและคาดการณ์ได้
    • ซอฟต์แวร์บางส่วนบน Amiga และ Atari เข้าถึงฮาร์ดแวร์·หน่วยความจำโดยตรงโดยไม่ทำตามสเปกและ abstraction ที่ผู้ผลิตให้ไว้ จึงพังแม้มีการอัปเกรดเล็ก ๆ อย่างหน่วยความจำหรือฮาร์ดดิสก์
    • ซอฟต์แวร์ที่เขียนให้สอดคล้องกับสเปกและ abstraction ยังสามารถขายต่อได้หลังฮาร์ดแวร์เปลี่ยนไป

  • กราฟิก, โปรแกรมไม่ลงลายเซ็น, LSP

    • การวาดพิกเซลบนหน้าจอยังคงทำได้ในหลายภาษา และ Mode 13h ก็เข้าถึงผ่าน VGA BIOS ซึ่งเป็นชั้น abstraction ของฮาร์ดแวร์ยุคแรก
    • โค้ดที่พึ่งพาฮาร์ดแวร์ VGA เฉพาะไม่สามารถพอร์ตได้ แต่โปรแกรมกราฟิกที่ใช้ abstraction ของ Windows สามารถทำงานได้ในสภาพแวดล้อมหลากหลาย ตั้งแต่ Hercules ถึง true-color XGA
    • การรันโปรแกรมที่ไม่ลงลายเซ็นก็ยังทำได้ และมีกรณีคอมไพล์ WordGrinder ใช้เอง
    • ความไม่พอใจบางส่วนของ Blow ใกล้เคียงกับปัญหาที่ผู้ผลิตฮาร์ดแวร์·ซอฟต์แวร์ล็อกระบบและลดสิทธิ์ผู้ใช้ มากกว่าเรื่อง abstraction
    • สำหรับ Language Server Protocol โดยรวมเห็นด้วยกับฝั่ง Blow แต่ LSP แก้ปัญหามากกว่าแค่ “คลิกเมธอดเพื่อไปยัง definition”

เกม, ประสิทธิภาพ, multitasking

  • แอปเพิ่มผลิตภาพยุคใหม่จำนวนมากมีกรณีประสิทธิภาพตกและ input lag รุนแรง
  • สาเหตุส่วนหนึ่งคือ abstraction แต่ปัญหาที่ใหญ่กว่าคือโค้ดแย่และการเลือกเครื่องมือไม่เหมาะกับงาน
  • แม้แต่โปรแกรมที่ใช้แพลตฟอร์มและ UI toolkit เดียวกัน ก็อาจให้ประสิทธิภาพที่ผู้ใช้รู้สึกได้ต่างกันมากบนเครื่องเดียวกัน
  • ปัญหาที่ Blow ยกมาเรื่องเกมกู้คืนความละเอียดหน้าจอหลัง Alt-Tab เป็นประสบการณ์ที่แย่และควรปรับปรุง
  • แต่เกม DOS ในอดีตเรียบง่ายเพราะไม่ต้องสนใจ process อื่น
    • หากจะเล่น Doom บน Windows 3.1 ต้องบันทึกงาน ปิดโปรแกรม ออกจาก Windows แล้วค่อยเริ่มเกม
    • เกม Amiga จำนวนมากก็ boot จากฟลอปปีดิสก์ ยึดเครื่องทั้งหมด และมักกลับสู่ OS อย่างเรียบร้อยไม่ได้
  • multitasking ของเกมในปัจจุบัน แม้ยังไม่สมบูรณ์แบบ แต่ถือว่าดีขึ้นกว่าอดีต

การสูญเสียความรู้และความเร็วของการเปลี่ยนแปลง

  • Blow มองว่าความรู้แบบการจัดการ sprite ใน Unity กำลังกลายเป็นความรู้จิปาถะแทนความเข้าใจเชิงลึก
  • เห็นด้วยว่าความเร็วของการเปลี่ยนแปลงซอฟต์แวร์และฮาร์ดแวร์สมัยใหม่มักเร็วมากจนยากจะตามอย่างมีความหมาย
  • แต่เรื่องนี้ใกล้เคียงกับปัญหา ความสม่ำเสมอตามเวลา และโมเดลการกระจายซอฟต์แวร์ มากกว่า abstraction เอง
  • กระแสการปล่อยอะไรบางอย่างทุก 4 สัปดาห์อาจทำให้ผู้ใช้ได้ประสบการณ์ที่เสถียรได้ยาก
  • หากเปลี่ยน UI บ่อย ผู้ใช้จะต้องต่อสู้กับรายละเอียดของอินเทอร์เฟซที่เปลี่ยนไปเรื่อย ๆ แทนที่จะได้ทำงานจริง

ความซับซ้อนคือปัญหาที่มนุษย์สร้างขึ้น

  • Blow อ้างว่าหากตัดสินใจลดความซับซ้อนก็ลดได้ และเราหลงคิดว่าการเพิ่ม abstraction จะช่วยประหยัดเวลา
  • หากใช้ framework ที่ถูกต้องกับงานที่ถูกต้อง ก็ช่วยนักพัฒนาเว็บได้มาก
  • ขณะเดียวกันก็ยังสงสัยต่อท่าทีที่พยายามใช้เบราว์เซอร์ทำทุกอย่างตั้งแต่ word processing ไปจนถึงเกม หรือรีบย้ายไปใช้ framework ใหม่ทันทีทุกครั้งที่มีออกมา
  • ความซับซ้อนของซอฟต์แวร์ไม่ได้เป็นปัญหาของโปรแกรมเมอร์อย่างเดียว แต่ตลาดและสภาพแวดล้อมองค์กรก็ร่วมสร้างขึ้นด้วย
    • การเมืองในองค์กร, การประชุมไร้สาระ, ซอฟต์แวร์รายงานเวลาที่เข้าใจยาก, deadline ที่ผู้อื่นกำหนด, ความต้องการลูกค้าที่จุกจิก, การตัดสินใจบริหารแปลก ๆ, การประเมินกำหนดการจาก requirement นามธรรม, การ debug legacy code ล้วนส่งผลต่อการเลือกของนักพัฒนา
  • ความซับซ้อนเป็นปัญหาที่มนุษย์สร้างขึ้น และหากลดความซับซ้อนในที่ทำงานได้ ระยะยาวก็อาจลดความซับซ้อนของซอฟต์แวร์ได้ด้วย

นักพัฒนารุ่นใหม่และความสามารถในการสร้าง engine

  • ข้อกล่าวอ้างของ Blow ที่ว่านักพัฒนาเกมรุ่นใหม่ไม่เคยเขียน engine เอง และไม่นานอาจลืมความสามารถนั้นในระดับหมู่คณะ ดูใกล้เคียงกับตรรกะทางลาดลื่น
  • คนส่วนใหญ่ที่มี C64, Amiga, 286 PC ไม่ได้กลายเป็นนักพัฒนาระดับต่ำ และหลายคนก็ไม่ได้เป็นโปรแกรมเมอร์
  • abstraction และ game engine สำเร็จรูปช่วยให้สร้างสรรค์ได้โดยไม่ต้องเรียนรู้การจัดการหน่วยความจำระดับต่ำ, pointer, algorithm
  • เด็กยุคนี้อยากสร้างสิ่งที่คล้ายเกม AAA ที่ซื้อในร้าน และความคาดหวังต่อเกมสมัยใหม่สูงกว่ายุค C64 หรือ Amiga มาก
  • เส้นทางเรียนรู้เทคโนโลยีระดับต่ำยังคงมีอยู่
    • Linux ดึงดูดนักพัฒนารุ่นใหม่ผ่านชุมชนโอเพนซอร์ส และกระตุ้นความสนใจในภาษาระบบอย่าง Rust, C, C++
    • dwm เป็น window manager ที่ตั้งค่าด้วยการแก้ซอร์สโค้ด C
    • มีนักพัฒนารุ่นใหม่ที่ใช้ C และ Z80 assembly, คนที่สร้าง Linux distribution ตั้งแต่ต้น, คนที่สร้างฮาร์ดแวร์เอง, และนักพัฒนา C ที่รัน OS วิจัยบนฮาร์ดแวร์สมัยใหม่
    • หลักสูตรวิทยาการคอมพิวเตอร์และวิศวกรรมไฟฟ้ายังคงสอนพื้นฐานอย่าง C, assembly, การออกแบบคอมไพเลอร์
    • การเข้าถึงเครื่องมือโปรแกรมมิง, เอกสาร, วิดีโอการสอน และแหล่งความรู้อย่าง MIT OpenCourseWare ถูกลงและดีขึ้นกว่าอดีต

ข้อสรุปสุดท้าย: ปัญหาที่ใหญ่กว่า abstraction

  • บทสรุปของ Blow ใกล้เคียง survivalism ที่นำมาใช้กับเทคโนโลยี และพอเข้าใจอุปมาว่าเมื่อไฟดับก็ต้องมีคนรู้วิธีก่อไฟ
  • สังคมพึ่งพาความสามารถในการรันโปรแกรมบางอย่างได้แทบตลอดเวลา
    • หากล้มเหลว อาจเกิดผลร้ายแรง เช่น เศรษฐกิจโลกพังทลาย หรือระบบสาธารณสุขของประเทศล้มเหลว
    • บันทึกทางประวัติศาสตร์และสมัยใหม่ถูกเก็บเป็นดิจิทัลมากขึ้นเรื่อย ๆ จึงต้องเข้าถึงได้ต่อไปในอนาคต
  • ความซับซ้อนเปราะบาง และ abstraction อาจสร้างความไม่รู้ที่เป็นอันตรายได้ บล็อกธรรมดาไม่จำเป็นต้องใช้ shadow DOM ในการเรนเดอร์ และ IRC client ที่มีภาพก็ไม่จำเป็นต้องใช้เปลือกเบราว์เซอร์
  • อย่างไรก็ตาม churn ต่อเนื่องที่มนุษย์สร้างขึ้นก็เป็นสาเหตุใหญ่ของความเปราะบางเช่นกัน
    • การพัฒนาแบบ “Agile” มีเจตนาไม่ให้ปล่อยสิ่งที่ยังไม่เสร็จและยังไม่ผ่านการทดสอบ แต่ในความเป็นจริงกลับมี release ที่ยังไม่สมบูรณ์ออกมาอย่างต่อเนื่อง
    • ระบบโฆษณา, tracker และ telemetry ทำงานคล้าย backdoor ตามการออกแบบโดยพฤตินัย เพิ่มทั้งช่องโหว่และความไม่สบายใจ
  • ปัญหาที่ใหญ่กว่าของโลกดิจิทัลคือความเป็นส่วนตัวและเสรีภาพ
  • เหตุผลที่เราอาจไม่สามารถ interface กับฮาร์ดแวร์โดยตรงได้ ไม่ใช่เพราะเราเลือก abstraction แต่เพราะสถานการณ์ที่เหลือแต่แพลตฟอร์มซึ่งถูกล็อกและควบคุมจากระยะไกลมากขึ้นเรื่อย ๆ

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

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

 
GN⁺ 2025-02-10
ความคิดเห็นจาก Hacker News

  • ผมสอน วิชาระบบ ที่ Montana State ซึ่งครอบคลุมตั้งแต่ทรานซิสเตอร์ไปจนถึงระบบคอมพิวติ้งจริง ๆ และตอนเริ่มคอร์สก็มีนักศึกษาบางคนที่ไม่รู้ด้วยซ้ำว่าระบบไฟล์คืออะไรอย่างถูกต้อง
    แม้ Blow จะมีบางจุดที่ผิดในรายละเอียด แต่ผมคิดว่าสำหรับนักศึกษาสายเทคโนโลยี เราควรพิจารณาการศึกษาแบบ NAND-to-Tetris อย่างจริงจังตั้งแต่ระดับมัธยมปลาย
    เราใช้โมเดล “เก่า ๆ” อย่าง Little Man Computer หรืออีมูเลเตอร์ MIPS แบบภาพง่าย ๆ ซึ่งอาจไม่สมจริง แต่ให้ความรู้สึกว่าเรามาจากไหนด้วยระดับความซับซ้อนที่คนทั่วไปเข้าใจได้
    พอดูตำราสถาปัตยกรรม 64 บิตที่คนแนะนำกันทุกวันนี้ก็ได้แต่หัวเราะ และการเชื่อมโยงเทคโนโลยีกลับไปถึงรากของมันเป็นปัญหาที่ยากจริง ๆ

    • แนวคิดเรื่องไฟล์และระบบไฟล์มีประโยชน์แม้กับผู้ใช้คอมพิวเตอร์ทั่วไปที่ไม่ได้สนใจการทำงานภายใน
      ปัญหาอยู่ที่ระบบปฏิบัติการมือถือและบริษัทซอฟต์แวร์พยายามทำให้ข้อมูลผู้ใช้อยู่ใน สวนปิดที่มีกำแพงล้อมภายในแอป ให้มากที่สุด
      แม้คุณจะทำงานกับไฟล์อยู่แล้ว ก็ยังบังคับให้ “นำเข้า” ข้อมูลเดิมเข้าไปในที่เก็บของตัวเอง และเมื่อแก้ไขแล้วก็ต้อง “ส่งออก” หรือ “แชร์” เป็นสำเนาใหม่เอง
    • ผมเองก็ค่อนข้างเป็นคนแก่ขี้บ่นอยู่เหมือนกัน แต่ผมเลิกคาดหวังกับคนรุ่น “นักศึกษา大学” ทุกวันนี้แล้ว
      ตอนนี้ผมกำลังเรียนปริญญาโทสาขาวิศวกรรมอุตสาหการที่ Montana State และต้องรับมือกับนักศึกษาปริญญาเอกที่ทำ อนุพันธ์ย่อย ง่าย ๆ ไม่ได้แทบทุกวัน
      เทอมที่แล้วในวิชาคณิตศาสตร์ระดับ 400 ก็มีนักศึกษาที่ไม่รู้วิธีบวกเมทริกซ์สองตัวเข้าด้วยกัน
      นักศึกษาปี 4 สาขาวิทยาการคอมพิวเตอร์ไม่รู้จักระบบไฟล์ก็น่าแปลก แต่เมื่อเทียบกับเรื่องเหลือเชื่อที่ผมเห็นที่นี่แล้วกลับดูธรรมดาไปเลย
      บรรยากาศต่างจากตอนที่ผมเข้าเรียนมหาวิทยาลัยครั้งแรกในยุค 2000 มากจนน่าหดหู่ แต่ก็ทำให้ผมมั่นใจกับแนวโน้มตลาดงานฤดูใบไม้ผลิปีหน้าอย่างน่าประหลาด
    • ขึ้นอยู่กับสาขา วิทยาการคอมพิวเตอร์กับวิศวกรรมคอมพิวเตอร์·วิศวกรรมไฟฟ้าเป็นคนละ领域กัน
      แม้ชื่อจะบอกอย่างนั้น แต่ วิทยาการคอมพิวเตอร์ ไม่ใช่วิชาที่ว่าด้วยตัวคอมพิวเตอร์เอง และถึงคอมพิวเตอร์จะเป็นเครื่องมือที่จำเป็น แก่นของมันคือการทำ abstraction ของโดเมนและการสร้างแบบจำลองภาษา รวมถึงการนำไปใช้
      เช่นเดียวกับที่นักดาราศาสตร์แค่ต้องใช้กล้องโทรทรรศน์ได้เท่าที่จำเป็น นักวิทยาการคอมพิวเตอร์ก็แค่ต้องใช้คอมพิวเตอร์ได้เท่าที่จำเป็น
      การวางคอมพิวเตอร์ไว้เป็นศูนย์กลางจักรวาลและใช้เป็นจุดตั้งต้นของวิทยาการคอมพิวเตอร์เป็นความผิดพลาดใหญ่ และในเชิงประวัติศาสตร์ก็เป็นที่มาของความสับสนมากมาย
      แม้แต่การเขียนโปรแกรม “ระดับต่ำ” สุดท้ายก็ยังเป็น abstraction และภาษา เพียงแต่ใช้ภาษาของอุปกรณ์คอมพิวติ้งเพื่อจำลอง abstraction ของโดเมนที่กำลังอภิปรายเท่านั้น
    • ผมเรียนสถาปัตยกรรมคอมพิวเตอร์ด้วย MIPS ในยุคที่ MIPS ยังถูกใช้ในผลิตภัณฑ์จริง และมันก็ดีในตอนนั้นและยังดีในตอนนี้
      เวลาว่างผมดีคอมไพล์แอสเซมบลี MIPS และฟังก์ชันเล็ก ๆ ก็สามารถแปลงกลับเป็นโค้ด C ที่สอดคล้องกันได้ด้วยมือโดยไม่ต้องใช้เครื่องมืออื่น
    • การสอนเป็นเรื่องที่ปะทะตรง ๆ กับข้ออ้างที่ว่า “ข้อมูลที่ส่งต่อระหว่างรุ่นถูกเจือจางลง”
      แต่มันไม่ได้ถูกเจือจาง การสอนยังมีอยู่ หนังสือและคอมพิวเตอร์ก็มีอยู่ เราจึงไม่จำเป็นต้องเรียกครูว่าเป็นนักกวีพเนจร
      สุดท้ายนี่ก็เป็นแค่อีกบล็อกโพสต์หนึ่งที่พูดถึงบล็อกโพสต์ และไม่รู้ว่าบล็อกเกอร์เหล่านั้น “สำคัญ” แค่ไหน แต่ก็มีกลิ่นของบล็อกเพื่อบล็อกอยู่ดี

  • เมื่อนักพัฒนาเว็บสูงวัยวิจารณ์ abstraction เขามักเล็งไปที่นักพัฒนา React; เมื่อนักพัฒนา Python วิจารณ์ ก็เล็งไปที่นักพัฒนาเว็บสูงวัย; และเมื่อนักพัฒนาแอปพลิเคชัน C++ วิจารณ์ ก็เล็งไปที่นักพัฒนา Python
    นักพัฒนาเฟิร์มแวร์ก็เล็งไปที่นักพัฒนาแอปพลิเคชัน ส่วนวิศวกรไฟฟ้าก็เล็งไปที่นักพัฒนาเฟิร์มแวร์
    การขีดเส้นว่า abstraction ที่มากเกินไป อยู่ตรงไหนโดยใช้ระดับที่ตัวเองรู้เป็นเกณฑ์ แล้วเรียกทุกอย่างหลังจากนั้นว่า “ฆ่าอารยธรรม” นี่ก็เป็นท่าทีที่น่าทึ่งทีเดียว

    • ใช่เลย บางทีก็แทบเหมือนคำพูดไร้สาระแบบ “เคมีคือฟิสิกส์ประยุกต์ ฟิสิกส์คือคณิตศาสตร์ประยุกต์ ดังนั้นคณิตศาสตร์คือที่สุด”

  • มีข้อชี้แนะดี ๆ หลายอย่าง และเพราะผมเองก็เคยดูการนำเสนอนั้นมาแล้ว ผมคิดว่าคำวิจารณ์เป็นเรื่องสำคัญ
    แต่ที่ Blow พูดว่า “เราไม่สามารถแค่วาดพิกเซลบนหน้าจอได้” นั้นถูกต้อง
    ผมทำงานเป็น โปรแกรมเมอร์เอนจินเกม ในบริษัทเกมขนาดกลาง และการจ้างคนที่จะมาดูแลโค้ดกราฟิกส์นั้นยากขึ้นมาก
    API รุ่นเดียวกับ DX12 เรียกร้องจากโปรแกรมเมอร์สูงขึ้นอย่างมหาศาลเมื่อเทียบกับรุ่นก่อนหน้าอย่าง DX11 และการทำอะไรสักอย่างด้วย API นี้ก็เป็นงานใหญ่ในตัวมันเอง
    Microsoft เองก็เคยยอมรับว่าการเรียน DX12 โดยไม่มีประสบการณ์กับ API กราฟิกส์รุ่นก่อนนั้นยากสุด ๆ แต่ตอนนี้ผมหาคำอ้างอิงนั้นในเอกสารไม่เจอแล้ว
    ข้อโต้แย้งที่ว่า “API แบบนี้มีไว้สำหรับนักพัฒนาที่ต้องการรีดขีดจำกัดของการ์ดจอและทำ optimization ระดับต่ำมาก ๆ” ก็ถูกอยู่บางส่วน แต่ตอนนี้มันกลายเป็นมาตรฐานอุตสาหกรรมไปแล้ว และแทบสอนให้คนที่ไม่มีประสบการณ์เดิมไม่ได้
    ถ้าไม่มีอะไรเปลี่ยน กลุ่มกำลังคนที่จ้างได้ จะหดตัวลงเรื่อย ๆ

    • หลังดูการนำเสนอของ Blow ผมรู้สึกว่าผมไม่ได้แปลกที่หงุดหงิดกับการที่งานพื้นฐานกลายเป็นเรื่องยากอย่างไร้เหตุผล
      แม้แต่การวาดปุ่มเดียวบนหน้าจอเวลาทำแอปพลิเคชันซอฟต์แวร์ก็ยากเกินไป จนคนส่วนใหญ่แค่ใช้ Progressive Web App ที่ช้ากว่าสมรรถนะที่เป็นไปได้ 100 เท่า
      ในปี 2025 ตัวเลือกที่ดีที่สุดสำหรับแอปพลิเคชัน GUI จริง ๆ คือ Java Swing กับ Qt หรือเปล่า
    • ผมเห็นด้วยกับประเด็นหลัก แต่ DX12 เดินไปในทิศทางตรงข้ามกับ abstraction มันเป็น API ระดับต่ำกว่า OpenGL ที่ถูก abstraction ไว้สูงมาก
    • หรือไม่ก็อาจเป็นการกลับมาของ “นักพัฒนาฝึกหัด”
    • สิ่งที่ควรปรับปรุงเหนือสิ่งอื่นใดคือ การสอนและการจัดทำเอกสาร ของ API ใหม่ ๆ เหล่านี้
      มีแนวคิดใหญ่ ๆ ที่เชื่อมทุกอย่างเข้าด้วยกันอยู่ แต่ในเอกสารแทบไม่บอกใบ้เลย ต้องเข้าร่วมเซสชันฝึกอบรมหรือคุยกับคนที่รู้อยู่แล้วจึงจะเรียนรู้ได้

  • ผมมองว่าสิ่งอย่าง JavaScript ฝั่งเซิร์ฟเวอร์และ React ทำให้การพัฒนาซอฟต์แวร์เว็บเละเทะมาก เมื่อเทียบกับสิ่งที่มันทำจริง ๆ
    เด็ก ๆ สมัยนี้บางคนไม่รู้ด้วยซ้ำว่าสิ่งที่เรนเดอร์ในเบราว์เซอร์คือ HTML คิดว่าเบราว์เซอร์เรนเดอร์ React เอง
    แถม CEO ของ Vercel ยังพูดอะไรโง่สุด ๆ ว่า React คือ เคอร์เนล Linux ของการพัฒนา

    • เป็นคำกล่าวอ้างที่แปลก แต่เขาพูดแบบนั้นจริง ๆ
      https://news.ycombinator.com/item?id=42824720
      ผมอยู่มานานพอจะจำยุค vanilla js, jQuery, Knockout, Angular 1 ได้ แต่ตอนนั้นความสับสนพื้นฐานก็มีอยู่เสมอ
      React บางครั้งแค่ JSX อย่างเดียวก็ใช้ได้อย่างสมเหตุสมผล
      ผมกลับโทษเครื่องมือที่ขับเคลื่อนด้วยเงิน VC อย่าง Vercel, Next, Apollo, Prisma และขยะที่เหล่าอินฟลูเอนเซอร์สายเว็บเดฟรับเงินมาใส่เต็มเว็บมากกว่า
      คิดดูแล้ว ทุกส่วนของการทำซอฟต์แวร์บวมขึ้นหมด ตั้งแต่บอร์ด Notion ไปจนถึงการเลือกฐานข้อมูลที่น่าสงสัย
    • เห็นด้วยว่ามันแย่มากที่มีนักพัฒนารุ่นใหม่จำนวนมากเขียนโปรแกรมไม่ได้ถ้าไม่มี React
      แต่ในฐานะคนที่ทำงานได้ดีแม้ไม่มีไลบรารี ผมอยากเสริมว่า DOM เป็นหนึ่งใน API ที่แย่ที่สุดที่มนุษย์เคยประดิษฐ์ขึ้น และ “reactive programming” เป็นโมเดลที่เหนือกว่าวิธีแบบเก่า
      NextJS ทำให้การพัฒนาเครื่องมือที่สั่งสมมาหลายปีถอยหลัง และช้ากว่า Vite มาก
      หน้าเว็บที่ไม่มีปฏิสัมพันธ์ใด ๆ ใน NextJS ที่ build แบบ static กลับดาวน์โหลด JavaScript 100KB เพื่อไม่ทำอะไรเลย
      Facebook พยายามแก้ด้วย “compiler” สำหรับ React ทั้งที่จริง ๆ แค่ทำให้คอมโพเนนต์ไม่ re-render โดยไม่จำเป็นตั้งแต่แรกก็พอ
      เมื่อเทียบกับ Preact ซึ่งแทบจะแทนกันได้ตรง ๆ React ใหญ่มหึมา และแสดงให้เห็นว่า Facebook ไม่ใส่ใจแค่ไหน
    • คำว่า “สิ่งที่เบราว์เซอร์เรนเดอร์คือ HTML” นั้นน่าขันตรงที่จริง ๆ แล้วผิด และฝ่ายที่คิดว่าเบราว์เซอร์เรนเดอร์ React ต่างหากที่ถูก
      HTML เป็นรูปแบบ serialization และเบราว์เซอร์ใช้มันเพื่อสร้าง DOM ในหน่วยความจำ
      React ไม่ได้ serialize อะไรเป็น HTML เลย แต่เรนเดอร์ลง DOM โดยตรง
      การที่ความเห็นนี้ผิดแต่ยังได้โหวตสูง แสดงชัดว่าเธรดนี้มีลักษณะเป็น “คนแก่ชกใส่ก้อนเมฆ”
    • ในบริบทของการแก้ DOM ด้วย JavaScript ผมไม่เข้าใจว่าคำว่า “เบราว์เซอร์เรนเดอร์ HTML” หมายถึงอะไร
      ตามความเข้าใจของผม HTML คืออินพุตของเบราว์เซอร์ แล้วเบราว์เซอร์แปลงมันเป็น DOM จากนั้นจึงนำไปสู่การวาดหน้าจอและการจัดการอินพุต ฯลฯ
      ความแตกต่างนี้สำคัญ เพราะ React หรือไลบรารี JavaScript ตระกูล virtual DOM ไม่ได้สร้าง HTML แต่สร้าง คำสั่งจัดการ DOM ที่เขียนด้วย JavaScript
    • ผมนึกว่าแก่นของ React คือถ้าไม่เปิด JavaScript ก็ใช้งานไม่ได้เลย และทำให้มันยุ่งเหยิงพอที่ Facebook จะซ่อนพฤติกรรมอันตรายของตัวเองไว้ข้างในได้อย่างมีประสิทธิภาพเสียอีก
      ข้อชี้แนะดี ๆ ของ Blow มีอยู่มาก แต่ผมคิดว่าเขามองข้ามไปว่า ความถดถอยจำนวนมากไม่ได้มาจากการล่องลอยระหว่างรุ่นคนหรือ entropy ของข้อมูล แต่มาจาก เจตนาร้าย อย่างโจ่งแจ้งของคนที่มีอำนาจตัดสินใจ

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

    • Blow กำลังทำเกมหนึ่งมาจะเกือบ 10 ปีแล้ว แถมเป็นเกมที่ไม่จำเป็นต้องประดิษฐ์เครื่องจักรใหม่ด้วยซ้ำ
      Muratori ก็ยังทำเกมที่เริ่มเมื่อ 10 ปีก่อนไม่เสร็จ
      ในทางกลับกัน ด้วยเกมเอนจินสมัยใหม่ รวมถึงอย่าง Raylib ทุกวันนี้แม้ในเกมแจมสุดสัปดาห์ก็ยังทำผลงานที่ดูดีพอสมควรได้ และเกม Sokoban ของ Blow ก็น่าจะทำได้ในราว 6 เดือน โดยเฉพาะถ้ามีทีมประมาณ 10 คน
    • อยากรู้ว่าคุณไม่เห็นด้วยกับ Casey Muratori ตรงไหนเป็นการเฉพาะ
      ผมดูคอนเทนต์ของเขามาบ้าง และในหัวข้อที่เขารู้ เขาดูถ่อมตัวแต่ก็มีความเห็นชัดเจน และผมคิดว่า Handmade Hero ก็ทำได้ยอดเยี่ยม
    • ข้ออ้างหลักของ Muratori ดูเหมือนจะเป็นว่าซอฟต์แวร์สมัยใหม่ช้า และผมคิดว่าข้อนี้ถูก 100%
      เวลาที่ Jira ใช้เพื่อแสดง ticket หนึ่งใบ เวลาที่ Slack ใช้สลับห้องแชต หรือการที่ VSCode ตามความเร็วพิมพ์ปกติไม่ทัน มันบ้ามากจริง ๆ
    • ผมสงสัยว่าจริงหรือเปล่า
      เขาดูเหมือนโยนคำวิจารณ์กว้าง ๆ แล้วก็หายไปไม่ทำอะไรอีก
      จะบอกว่าเขามีผลงานยิ่งใหญ่ก็พูดยาก ผมมองว่าเขาทำงานได้ในระดับโอเค
      เกมที่ออกมามีแค่สองเกม และใกล้เคียงกับปริศนามากกว่าเกม เล่นจบครั้งเดียวแล้วแทบไม่มีเหตุผลให้กลับไปเล่นอีก
      Braid ก็โอเค ส่วน The Witness ก็แค่เหมือน Flow
      หลังจากนั้นเขาทำภาษาโปรแกรมมิ่งมา 10 ปีแล้ว แต่ไม่เผยแพร่เพราะ “ยังไม่เสร็จ”
      ดูเหมือนหลังจากโชคดีทำเงินได้ เขาก็มองว่าตัวเองมีพรสวรรค์กว่าความเป็นจริงมาก

  • สภาพแวดล้อมซอฟต์แวร์สมัยใหม่มีปัญหามากมายจริง ๆ และผมก็คิดว่า การทำ abstraction มากเกินไป เป็นปัญหาด้วย
    แต่สุดโต่งอีกฝั่งก็แย่เช่นกัน และก็มีแนวโน้มจะโรแมนติไซส์อดีตมากเกินไป
    การแครชและการรีบูตก็เป็นปัญหา ระบบอย่าง Amiga มีปัญหาความเข้ากันได้ระหว่างเวอร์ชันฮาร์ดแวร์ และแม้แต่ระบบที่ให้ความสำคัญกับ compatibility ก็ไม่ได้ปลอดจาก incompatibility
    แม้แต่ใน Windows 11 ซึ่งเป็นระบบสมัยใหม่ที่ไม่เสถียรที่สุด คอมพิวเตอร์ของผมก็ยังเสถียรกว่าคอมพิวเตอร์เครื่องใด ๆ ที่ผมใช้ก่อนปี 2010 มาก และยังรันซอฟต์แวร์สำหรับ Windows 95 ได้
    คอมพิวเตอร์ที่ใช้ได้ในชีวิตประจำวันย่อมดีกว่าคอมพิวเตอร์ที่ใช้ไม่ได้

  • การทำให้ง่ายขึ้นทั้งหมดไม่ได้เป็น abstraction และ abstraction ทั้งหมดก็ไม่ได้เป็นการทำให้ง่ายขึ้นเช่นกัน
    แต่บ่อยครั้ง abstraction เกิดขึ้นระหว่างการไล่ตามความเรียบง่าย
    ผมไม่คิดว่า abstraction จะฆ่าซอฟต์แวร์หรืออารยธรรม แต่ abstraction ที่ย่ำแย่ ซึ่งสร้างขึ้นโดยอ้างเหตุผลเรื่องความเรียบง่ายในระยะสั้น จะลดความยืดหยุ่น ความคล่องตัว และการเข้าถึงลง
    ถ้าดู syntactic sugar ของแทบทุกภาษา จะมีจุดหนึ่งที่ความเรียบง่ายเฉพาะส่วนซึ่งได้มาจากนัยเฉพาะบางอย่าง ไม่สามารถใช้เป็นเหตุผลรองรับความซับซ้อนที่เพิ่มขึ้นของเครื่องมือทั้งชุดได้อีกต่อไป
    ในภาษาที่มีไวยากรณ์มากมาย ผู้คนไม่ได้ทำพลาดเพราะองค์ประกอบใดองค์ประกอบหนึ่งโดยเฉพาะ แต่เพราะการใช้เครื่องมือเพื่อแก้ปัญหาซับซ้อนให้ดีนั้น กลายเป็นเรื่องยากเสียเอง
    ความซับซ้อนที่ async และ coroutine ใน Kotlin เพิ่มเข้ามาในประสบการณ์ของผมเมื่อจัดการโค้ดที่ “คล้ายเธรด” นั้น แตกต่างอย่างสิ้นเชิงจากวิธีที่ Elixir/Erlang จัดการปัญหาประเภทเดียวกัน
    ทั้งสองต่างให้ abstraction และการทำให้ง่ายขึ้นสำหรับปัญหาเก่าอย่างการคำนวณแบบขนานและอะซิงโครนัส แต่แบบแรกเอาความเรียบง่ายหลายชั้นมาคูณกันจนกลับสร้างสิ่งที่ซับซ้อนขึ้นมา ส่วนแบบหลังใกล้เคียงกับ abstraction ที่เรียบง่ายจริง ๆ และทำงานได้เลย

  • ผู้เขียนดูเหมือนจะอยู่ในคนรุ่นที่อายุน้อยกว่า จึงเหมือนพลาดประเด็นของ Blow ไปโดยไม่รู้
    น่าขันที่บทความนั้นเองดูเหมือนเป็นตัวอย่างแบบที่ Blow พูดถึง
    คล้ายกับถ้าพูดว่า Figma กำลังทำลายโลกการออกแบบในระดับที่ไม่เคยมีมาก่อน ด้วยการทำให้ UX, UI และแนวทางการจัดการผลิตภัณฑ์ที่แย่ของ Figma เองกลายเป็นเรื่องปกติ แล้วได้รับปฏิกิริยาจากดีไซเนอร์รุ่นใหม่ที่งุนงงว่าทุกอย่างก็ปกติดี
    ความรู้นั้นมีอยู่เพราะเติบโตมาในสภาพแวดล้อมนั้น แต่พวกเขาไม่ได้เติบโตมาแบบนั้น และสิ่งที่เป็นวัฒนธรรมกับประสบการณ์ก็ไม่ใช่เรื่องที่จะเรียนรู้จากที่ไหนได้ง่าย ๆ

    • สรุปว่าข้อโต้แย้งคือ “ผิดเพราะยังเด็กและไม่มีประสบการณ์” อย่างนั้นหรือ? อาจเป็นไปได้ แต่ยังขาดอยู่ว่าผิดตรงไหนกันแน่
      การโจมตีตัวบุคคล แบบนี้ไม่ได้ช่วยเติมอะไรให้การสนทนาเลย
    • ช่วยอธิบายเพิ่มเติมได้ไหมว่า Figma กำลังทำลายโลกการออกแบบอย่างไร?
    • จุดไหนที่มองว่าผู้เขียนพลาดไป?
    • ไม่รู้สึกเลยว่าผู้เขียนเป็นคนรุ่นใหม่กว่า ส่วนเนื้อหาที่เหลือก็ไม่จริงเช่นกัน
    • ข้อโต้แย้งของ Blow ถูกโต้แย้งได้ดีแล้ว จึงไม่จำเป็นต้องยกเรื่องอายุขึ้นมา แต่ผู้เขียนก็ดูมีความเป็นไปได้ว่าอย่างน้อยน่าจะอยู่ช่วงกลางวัย 40 ปี Amiga เป็นที่นิยมในช่วงปลายยุค 80
      ตรงข้ามกับคำกล่าวที่ว่า “ข้ออ้างว่าซอฟต์แวร์กำลังก้าวหน้านั้นเป็นเท็จอย่างชัดเจน” ผมยังใช้คอมพิวเตอร์ Amiga ที่รักอยู่บ่อย ๆ
      ไม่กี่สัปดาห์ก่อน ตอนคัดลอกไฟล์ลงฮาร์ดไดรฟ์ Amiga จู่ ๆ คอมพิวเตอร์ก็แครช และไม่ใช่เพราะผมทำอะไรผิด แต่เพราะระบบปฏิบัติการของคอมพิวเตอร์บ้านรุ่นเก่าไม่ได้เสถียรนัก
      ผลคือพาร์ทิชันฮาร์ดไดรฟ์เสียหาย ระบบปฏิบัติการตรวจสอบไฟล์ซิสเต็มใหม่ไม่ได้ สุดท้ายจึงไม่มีทางเลือกนอกจากฟอร์แมตพาร์ทิชันใหม่
      ผมไม่ค่อยรู้เรื่องการออกแบบ แต่ก็พอบอกได้ว่าข้อกล่าวหาเกี่ยวกับ Figma นั้นผิดโดยสิ้นเชิงเหมือนกับข้อกล่าวหาของ Blow
      นั่นคือ ความโหยหาอดีต ที่กำลังพูดอยู่ อินเทอร์เฟซผู้ใช้มีสิ่งเละเทะอยู่เสมอ ซอฟต์แวร์ก็เช่นกัน และทุกอย่างก็เช่นกัน
      เราจดจำแต่ข้อดีของตัวอย่างระดับบนสุดในอดีต และลืมทั้งของห่วย ๆ รวมถึงความล้มเหลวของสิ่งที่ออกแบบมาดีไปด้วย

  • ปัญหาคือ abstraction ที่ไม่ได้คิดให้ลึกพอ
    มี abstraction จำนวนมากที่เห็นได้ชัดว่าเป็นร่างแรกหรือความพยายามครั้งแรก แต่เพราะ การบูชาความเร็ว และความโอหังของอุตสาหกรรมเทคโนโลยี จึงถูกปล่อยออกไปทั้งอย่างนั้นก่อนจะได้ขัดเกลาหลายรอบ
    เมื่อ abstraction แบบนั้นกลายเป็นส่วนหนึ่งของโปรเจกต์ยอดนิยม คนอื่น ๆ ก็ลอกตามด้วยพฤติกรรมเลียนแบบ ภายใต้ธงคลุมเครือที่เรียกว่า “best practice”
    ทำกระบวนการนี้ซ้ำไป 10–20 ปี ก็จะได้ความยุ่งเหยิงมหึมา
    ที่แย่กว่านั้นคือ ในสังคมที่เทคโนโลยีกลับทำให้เกิดการเข้าสังคมมากเกินไปอย่างย้อนแย้ง ฉันทามติทางสังคมที่ไม่อยากถูกจับได้ว่าเป็น “คนหลอกลวง” ยังคงผลักดันให้วิธีแก้ปัญหาที่ยังไม่สุกงอมแพร่ต่อไป
    ผมชอบงานนำเสนอของ Jonathan Blow ครั้งนั้น และกลับไปดูใหม่อย่างน้อยปีละครั้ง ผมมองว่าเขาไม่ได้พูดอะไรเพื่อก่อข้อถกเถียง แต่หลายคนโมโหหรือรู้สึกเจ็บจี๊ด เพราะลึก ๆ แล้วนักพัฒนาจำนวนมากรู้ว่าตัวเองไม่ได้ปล่อยงานออกมาด้วยความพยายามอย่างดีที่สุด และไม่ได้ชี้นำคนรุ่นใหม่อย่างเหมาะสม
    เรามาถึงวัฒนธรรมที่การแสวงหาความใหม่เป็นเรื่องประจำวัน และบางครั้งยังถูกยกย่องด้วย
    ในอดีต วิธีแก้ปัญหาที่ผ่านการพิจารณามาเพียงพอคือมาตรฐานทางวัฒนธรรม แต่ตอนนี้สิ่งใหม่กลายเป็นมาตรฐาน โดยไม่เกี่ยวว่ามันดีจริงหรือไม่
    เราสามารถขุดคุ้ยรายละเอียดข้อโต้แย้งของ Blow ได้ไม่รู้จบ แต่หลักฐานก็ปรากฏอยู่ตรงหน้าเต็มไปหมด
    และในกรอบเวลาที่ยาวพอ สิ่งนั้นอาจนำไปสู่ การล่มสลายของอารยธรรม ได้ และเมื่อดูปริมาณของสิ่งที่พังอยู่ในโลก ก็อาจกล่าวได้ว่ามันกำลังเกิดขึ้นแล้ว

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