ว่าด้วย “ความโง่เขลาของการเขียนโปรแกรมด้วยภาษาธรรมชาติ” ของ Dijkstra

 (cs.utexas.edu)
2 คะแนน โดย GN⁺ 2025-04-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มุมมองที่โทษ สัญลักษณ์เชิงรูปแบบ ว่าเป็นสาเหตุของความยากในการเขียนโปรแกรม ก่อให้เกิดความคาดหวังที่ผิดว่าหากเครื่องเข้าใจภาษาธรรมชาติได้ ภาระของมนุษย์จะลดลง
  • อันตรายของภาษาเครื่องในยุคแรกถูกบรรเทาลงบางส่วนด้วย ภาษาการเขียนโปรแกรมระดับสูง แต่แก่นสำคัญที่ว่ายังต้องมีคำสั่งที่แม่นยำก็ยังคงอยู่ เพียงแค่คำตอบที่ผิดเปลี่ยนเป็นข้อความแสดงข้อผิดพลาด
  • อินเทอร์เฟซภาษาธรรมชาติไม่ใช่วิธีแบ่งงานกันทำ แต่สามารถเพิ่ม ต้นทุนของความร่วมมือและการสื่อสาร ระหว่างมนุษย์กับเครื่อง ทำให้ภาระของทั้งสองฝ่ายมากขึ้น
  • พัฒนาการของคณิตศาสตร์แสดงให้เห็นว่า ระบบสัญลักษณ์เชิงรูปแบบ ที่บุคคลอย่าง Vieta, Descartes, Leibniz และ Boole สร้างขึ้น เป็นเครื่องมือหลักในการจัดการความคิดที่ซับซ้อน
  • หากการเขียนโปรแกรมด้วยภาษาธรรมชาติถูกใช้เป็นอินพุตและเอาต์พุตพื้นฐานตั้งแต่แรก วิทยาการคอมพิวเตอร์ก็อาจกลายเป็นทางอ้อมอันยาวไกลเพื่อย้อนกลับไปหาระบบเชิงรูปแบบที่ ใช้งานได้จริง ในท้ายที่สุด

ความคาดหวังและความเข้าใจผิดต่อการเขียนโปรแกรมด้วยภาษาธรรมชาติ

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

วิธีที่สัญลักษณ์เชิงรูปแบบขยายขีดความสามารถของความคิด

  • ในประวัติศาสตร์คณิตศาสตร์ แนวทางแบบภาษาธรรมชาติหรือพึ่งภาพเป็นหลักได้แสดงข้อจำกัดซ้ำแล้วซ้ำเล่า
    • คณิตศาสตร์กรีกหยุดชะงักเพราะคงอยู่กับกิจกรรมเชิงภาษาและเชิงภาพ
    • “algebra” แบบมุสลิมเคยลองใช้สัญลักษณ์อยู่ช่วงสั้น ๆ ก่อนจะหวนกลับไปสู่แนวทางเชิงวาทศิลป์และเลือนหายไป
    • ยุโรปตะวันตกหลุดพ้นจากความพยายามด้านความแม่นยำเชิงภาษาของลัทธิสกอลาสติกยุคกลางได้ด้วย สัญลักษณ์เชิงรูปแบบที่ออกแบบอย่างมีสติ โดยบุคคลอย่าง Vieta, Descartes, Leibniz และต่อมาคือ Boole
  • ข้อดีของข้อความเชิงรูปแบบอยู่ที่การจัดการที่ถูกต้องนั้นต้องเพียงแค่สอดคล้องกับกฎง่าย ๆ ไม่กี่ข้อ
    • ความเป็นแบบแผนนี้กลายเป็นเครื่องมือในการตัดความไร้ความหมายหลายชนิดที่หลีกเลี่ยงได้ยากในภาษาธรรมชาติออกไป
  • การใช้สัญลักษณ์เชิงรูปแบบไม่ใช่ภาระ แต่ใกล้เคียงกับการเป็น อภิสิทธิ์
    • ด้วยสัญลักษณ์เชิงรูปแบบ งานที่แต่เดิมมีเพียงอัจฉริยะเท่านั้นที่ทำได้ กลับกลายเป็นสิ่งที่นักเรียนก็เรียนรู้ได้
    • ประโยคในคำนำของรายงานทางเทคนิคฉบับหนึ่งเมื่อปี 1977 ที่ว่า “เพื่อความชัดเจน เราจึงหลีกเลี่ยงแม้กระทั่งสัญลักษณ์มาตรฐานของตัวเชื่อมเชิงตรรกะ” แสดงให้เห็นว่าความเข้าใจผิดแบบนี้ไม่ได้จำกัดอยู่แค่คนคนเดียว
  • “ความเป็นธรรมชาติ” ของภาษาธรรมชาตินำไปสู่การสร้างประโยคที่ความไร้ความหมายไม่ปรากฏชัดได้อย่างง่ายดาย

วิทยาการคอมพิวเตอร์ในโลกที่อนุญาตให้ใช้แต่ภาษาธรรมชาติ

  • หากตั้งแต่แรกอินพุตและเอาต์พุตของอุปกรณ์ประมวลผลข้อมูลทำได้ด้วย ภาษาพื้นเมือง เท่านั้น วิทยาการคอมพิวเตอร์ก็คงใกล้เคียงกับ “black art” ที่มุ่งไปสู่ระบบเชิงรูปแบบที่นิยามไว้ชัดเจนเพียงพอ
    • การทำให้อินเทอร์เฟซแคบลงจนใช้งานได้จริงอาจต้องอาศัยภูมิปัญญาของคนทั้งโลก
    • และเมื่อพิจารณาจากประวัติศาสตร์มนุษย์ ก็อาจต้องใช้เวลาอีกหลายพันปี
  • ยังมีความกังวลประกอบด้วยว่า กระแสการศึกษาในโลกตะวันตกที่ห่างไกลจากการฝึกฝนทางปัญญา ทำให้ความสามารถของผู้คนในการใช้ภาษาของตนเองลดลงอย่างมาก
    • เขายกตัวอย่างว่าทั้งในบทความวิชาการ รายงานทางเทคนิค และสิ่งพิมพ์ของภาครัฐ หากอ่านอย่างละเอียดก็จะพบถ้อยคำไร้ความหมายอยู่มาก
    • ปรากฏการณ์นี้ถูกเรียกว่า “The New Illiteracy” และยังเป็นคำเตือนต่อผู้สนับสนุนที่ไม่มีความเข้าใจเชิงเทคนิคพอจะคาดการณ์ความล้มเหลวของการเขียนโปรแกรมด้วยภาษาธรรมชาติ
  • ตอนจบลงด้วยความสงสัยว่า เครื่องที่เขียนโปรแกรมด้วยภาษาธรรมชาติ ไม่ว่าจะใช้ Dutch, English, American, French, German หรือ Swahili ก็อาจใช้งานยากพอ ๆ กับที่สร้างมันขึ้นมา

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

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

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

  • การปกป้อง LLM ตรงนี้ก็ดีอยู่ แต่ผมสงสัยว่าถ้าลองทำกลับกันจะเป็นอย่างไร ลองเอาโปรเจกต์ที่มีความซับซ้อนระดับกลางมา แล้วใช้ LLM ที่ชอบแปลงโค้ดกลับเป็นภาษาธรรมชาติ
    มันจะอธิบายพฤติกรรมและข้อกำหนดที่อยู่ในซอร์สโค้ดได้อย่างสมเหตุสมผล โดยไม่สูญเสียรายละเอียดมากพอที่จะสร้างโปรแกรมนั้นขึ้นมาใหม่ได้หรือไม่? คำอธิบายภาษาธรรมชาตินั้นจะให้เหตุผลได้ง่ายกว่าหรือเปล่า?
    ผมคิดว่ามีเหตุผลที่ แอป vibe coding ที่ผู้คนเอามาโชว์มักจะค่อนข้างเรียบง่าย มีระดับหนึ่งที่ความซับซ้อนและความแม่นยำจัดการได้ยาก และแม้จะนิยามด้วยภาษาอังกฤษธรรมดาได้ แต่ก็ยังน่าสงสัยว่าคำอธิบายนั้นอธิบายได้ดีกว่าภาษาที่ขยายต่อได้ เข้าใจได้ และแม่นยำหรือไม่
    ผมคิดว่าเหตุผลที่เอกสารกฎหมายไม่ใช้ภาษาอังกฤษธรรมดา ก็มีมากกว่าแค่การสร้างกำแพงกีดกันไม่ให้คนทั่วไปเข้าถึง

    • ยกตัวอย่างจากอีกสาขา พยากรณ์อากาศและประกาศด้านการบิน จะเผยแพร่ในรูปแบบที่ย่อและเข้ารหัสอย่างมาก เช่น สภาพอากาศของซิดนีย์ ออสเตรเลียตอนนี้เป็นประมาณ METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0
      นักบินใหม่แทบทุกคนจะถามว่า “ทำไมไม่เขียนเป็นคำพูด?” และจริง ๆ แล้วแอปวางแผนการบินส่วนใหญ่ก็แปลงโค้ดนี้เป็นร้อยแก้วให้
      แต่เหล่านักบินมืออาชีพหรือเจ้าหน้าที่ควบคุมการจราจรทางอากาศชอบรูปแบบโค้ดมากกว่าเยอะ เพราะเป็นบรรทัดเดียวจึง กระชับ รูปแบบถูกนิยามไว้อย่างดี ทำให้รู้แน่ชัดว่าต้องไปหาข้อมูลที่ต้องการตรงไหน และไม่กำกวม ชัดเจน
      คณิตศาสตร์กับการเขียนโค้ดก็เหมือนกัน เมื่อถึงระดับความชำนาญระดับหนึ่ง ความซับซ้อนและความซ้ำซ้อนของภาษาธรรมชาติมีต้นทุนมากกว่าประโยชน์ ดูเหมือนจะใช้ได้กับทุกสาขาเฉพาะทาง
    • ผมคิดว่าเป็นเรื่องของ working memory มากกว่าความแม่นยำ เหตุผลที่มนุษย์เข้าใจเวอร์ชันร้อยแก้วขนาดใหญ่ได้ยาก น่าจะคล้ายกับเหตุผลที่ LLM จัดการเวอร์ชันร้อยแก้วขนาดใหญ่ได้ยาก คือมี working memory จำกัด
      การดึงข้อมูลกลับมาจากร้อยแก้วใช้เวลามาก และคนที่อ่านข้อความยาว ๆ ก็จะเริ่มขีดเส้นใต้ จดบันทึก และสร้างรูปแบบย่อของตัวเอง
      รูปแบบที่บีบอัดและ abstraction ช่วยลดภาระของ working memory และการค้นหาข้อมูล ดังนั้นจึงอาจไม่ใช่แค่ปัญหาความแม่นยำของภาษาเท่านั้น
    • ภาษาสามารถบรรจุบริบทได้มหาศาล ตัวอย่างเช่น ประโยคว่า “อยากได้แอปนำทางรุ่นใหม่สำหรับขับรถ และอยากเลือกสี่แยกที่ไม่อยากผ่านเด็ดขาดได้” มีความซับซ้อนต่ำ แต่เข้ารหัสข้อมูลจำนวนมหาศาล
      คุณอาจคิดว่าจากประโยคนั้นไปสู่แอปที่ใช้งานได้จริงต้องมีรายละเอียดการใช้งานจำนวนมาก แต่ด้วยข้อมูลแค่นั้นก็มีความเป็นไปได้ที่จะไปถึงแอปที่ทำงานได้และแก้ความต้องการของผม
      และถ้าสามารถสร้างได้เพียงพอด้วยสิ่งนั้น คำขออย่าง “เปลี่ยนมันเป็นสี cornflower blue ได้ไหม?” ก็ง่ายขึ้น และผู้ใช้ก็สามารถปรับปรุงซ้ำจากตรงนั้นได้
    • แน่นอนว่าเราสร้าง abstraction ที่รั่วไหล และเรื่องแบบนั้นก็เกิดขึ้นในเอกสารกฎหมายด้วย
      ถ้าให้แค่ ISA กับไดรเวอร์จอแสดงผล แล้วบอกให้ LLM สร้างแอปกราฟิกด้วยแอสเซมบลี ก็คงไม่ได้อะไรเลย
      แต่ถ้ามี abstraction กองทับกันเป็นภูเขา ก็อาจทำได้
      ไม่ได้พยายามปกป้อง LLM แต่ผมมองว่าถ้าให้ abstraction ที่ถูกต้องและคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้ เราจะเข้าใกล้ได้มากขึ้นมาก
    • มีเหตุผลที่เอกสารกฎหมายไม่ใช่ภาษาอังกฤษธรรมดา ส่วนหนึ่งของความแม่นยำในถ้อยคำกฎหมายเป็นเพราะความหมายของคำเฉพาะบางคำถูกนิยามไว้อย่างแม่นยำกว่าเดิมแล้วผ่าน บรรทัดฐานคำพิพากษาของศาล

  • นึกถึงคำพูดเก่าของ Hal Abelson
    “ภายใต้แนวทางของเราต่อหัวข้อนี้ มีความเชื่อมั่นว่า ‘วิทยาการคอมพิวเตอร์’ ไม่ใช่วิทยาศาสตร์ และความสำคัญของมันแทบไม่เกี่ยวกับคอมพิวเตอร์เลย การปฏิวัติคอมพิวเตอร์คือการปฏิวัติวิธีที่เราคิดและวิธีที่เราแสดงความคิด แก่นแท้ของการเปลี่ยนแปลงนี้คือการเกิดขึ้นของสิ่งที่น่าจะเรียกได้เหมาะที่สุดว่า epistemology เชิงกระบวนการ นั่นคือการศึกษารูปแบบของความรู้จากมุมมองเชิงคำสั่ง ตรงข้ามกับมุมมองเชิงประกาศมากกว่าที่สาขาคณิตศาสตร์คลาสสิกใช้ คณิตศาสตร์ให้กรอบสำหรับจัดการแนวคิดเรื่อง ‘อะไรคืออะไร’ อย่างแม่นยำ การคำนวณให้กรอบสำหรับจัดการแนวคิดเรื่อง ‘จะทำอย่างไร’ อย่างแม่นยำ”

    • ประเด็นสำคัญคือ การคำนวณคือการทำให้สิ่งต่าง ๆ เกิดขึ้น การเขียนโค้ดด้วย LLM เพิ่มชั้น abstraction ขึ้นมาอีกชั้นหนึ่ง แต่ไม่ได้ทำให้ความจำเป็นด้านความแม่นยำและความถูกต้องของ “สิ่งที่เกิดขึ้น” หายไป
      ไม่ว่าจะมีเดโมสวยหรูและคำประกาศว่า “การเขียนโค้ดตายแล้วเพราะ AI” มากแค่ไหน งานจริงส่วนใหญ่ก็ย้ายไปอยู่ที่การเตรียมข้อมูลก่อน การประมวลผลหลัง และการประเมินผลรอบ ๆ AI
      มันดีในแง่ที่ทำให้การเข้าถึงการเขียนโปรแกรมง่ายขึ้น แต่ไม่สามารถแทนที่การเขียนโปรแกรมได้จริง ๆ
    • สิ่งที่สอนกันในหลักสูตรวิทยาการคอมพิวเตอร์ทุกวันนี้ ดูจะไม่ใช่ไปในทิศทางนั้นแน่ ๆ
    • Hal Abelson กำลังทำให้นักวิทยาการคอมพิวเตอร์สาย functional programming ทั่วโลกเดือดดาลได้อย่างสบาย ๆ

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

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

  • /s: เพราะเรายังไปไม่ไกลพอ ผู้คนสร้างโปรแกรมคอมพิวเตอร์ด้วยภาษาธรรมชาติ แต่แทนที่จะทำแบบนั้นควร รันพรอมป์โดยตรง
    “คุณคือระบบกราฟิก คุณเป็นสิ่งที่จัดการว่ามีอะไรอยู่บนหน้าจอ คุณสามารถรับคำขอจากทุกโปรแกรมให้สร้างและลบ ‘หน้าต่าง’ ได้ และยังรับคำขอเพิ่มเติมให้วาดข้อความ เส้น วงกลม ฯลฯ ลงในหน้าต่างที่เคยสร้างไว้ได้ด้วย รายการต่าง ๆ จะเป็นสีอะไรก็ได้
    นอกจากนี้ คุณต้องส่งข้อมูลการคลิกเพิ่มเติมไปยังฝ่ายที่สร้างหน้าต่างที่ผู้ใช้คลิกเมาส์
    ตัวจัดการหน้าต่างเป็นโปรแกรมพิเศษ และสามารถบอกคุณได้ว่าหน้าต่างใดแสดงอยู่ที่ไหนบนทุกมอนิเตอร์ที่เชื่อมต่อกับระบบ”
    แล้วก็ “คุณคือโปรแกรมทิกแทกโท มีระบบกราฟิกที่จัดการว่ามีอะไรอยู่บนหน้าจอ คุณสามารถสั่งระบบนั้นให้สร้างและลบ ‘หน้าต่าง’ ได้ และสั่งให้วาดข้อความ เส้น วงกลม ฯลฯ ลงในหน้าต่างที่เคยสร้างไว้ได้ รายการต่าง ๆ จะเป็นสีอะไรก็ได้
    กราฟิกที่คุณวาดควรแสดงเกมทิกแทกโทที่ผู้ใช้คลิกเมาส์เพื่อเล่นแต่ละตา ถ้าผู้ใช้ชนะ…
    เพิ่มโฆษณาในเกม เว้นแต่ผู้ใช้จะสมัครสมาชิกแบบคิดเงินต่อคลิก”
    แค่นี้ก็น่าจะพอให้เกมทำงานได้แล้ว
    ถ้าจะบันทึก ก็ต้องมีพรอมป์อีกอัน “คุณคือระบบไฟล์ คุณเป็นสิ่งที่ทำให้ข้อมูลคงอยู่ถาวรบนดิสก์…”
    และยังต้องมี “คุณคือระบบปฏิบัติการมัลติทาสก์ คุณทำให้ LLM หลายตัวรู้สึกว่ากำลังควบคุม CPU และหน่วยความจำของระบบอย่างสมบูรณ์ คุณ…” ด้วย
    หวังว่าจะได้เห็นสิ่งนี้ใน ต้นเดือนเมษายน ปีหน้า

    • พรอมป์แบบนี้ในปัจจุบันถูกใช้งานภายในด้วยการ สร้างและรันโค้ด Python

  • “ภาษาเครื่องแทบไม่มีความซ้ำซ้อนในทุกรูปแบบ จึงถูกมองอย่างรวดเร็วว่าเป็นอินเทอร์เฟซระหว่างมนุษย์กับเครื่องจักรที่อันตรายโดยไม่จำเป็น ส่วนหนึ่งเพื่อตอบสนองต่อการรับรู้นี้ จึงมีการพัฒนาสิ่งที่เรียกว่า ‘ภาษาโปรแกรมระดับสูง’ ขึ้น และเมื่อเวลาผ่านไป เราก็ได้เรียนรู้วิธีเพิ่มการป้องกันความผิดพลาดโง่ ๆ ได้ในระดับหนึ่ง การที่ความผิดพลาดโง่ ๆ จำนวนมากในตอนนี้นำไปสู่ข้อความแสดงข้อผิดพลาดแทนคำตอบที่ผิด ถือเป็นการปรับปรุงที่สำคัญ”
    รู้สึกว่าเราในฐานะกลุ่มคนกระโดดเข้าสู่การเขียนโปรแกรมด้วย LLM เร็วเกินไป ผมชอบมากที่ Rust พัฒนามาในแนวทางที่ชี้ให้เห็น ความผิดพลาดโง่ ๆ และทำให้วิธีแก้ชัดเจนขึ้นมาก
    ในฐานะนักพัฒนา ผมยังคงมีบริบทและความเข้าใจเกี่ยวกับโค้ดที่กำลังทำอยู่ และคอมไพเลอร์ก็บอกข้อผิดพลาดที่ชัดเจนพร้อมวิธีแก้ให้ ในทางกลับกัน การใช้ LLM ให้ความรู้สึกเหมือนเกมเดาแบบกึ่งฉลาด
    คอมไพเลอร์ Rust เหมือนอาจารย์ที่สอนศิษย์ ส่วน LLM เหมือนบัณฑิตที่มั่นใจในตัวเองและกำลังแก้คำพูดของอาจารย์ ผมชอบแนวทางของ Rust มากกว่าเยอะ และถ้าเป็นไปได้ก็อยากให้พัฒนาไปไกลกว่านี้

    • Rust และภาษาอื่น ๆ มี type inference ส่วน LLM มีสิ่งที่เรียกว่า “inference” LLM แสร้งทำเป็นเข้าใจ และคำโกหกนั้นสักวันจะต้องมีราคาที่ต้องจ่าย

  • ภาษาธรรมชาติเป็นสื่อที่แย่สำหรับการถ่ายทอดกฎและคำสั่ง สถานการณ์ปัจจุบันของสหรัฐฯ เป็นตัวอย่างที่ดี
    เรายังถกเถียงกันอยู่เลยว่ากฎหมายและบทแก้ไขรัฐธรรมนูญบางข้อหมายถึงอะไร ความหมายของคำเปลี่ยนไปตามเวลา และบริบททางประวัติศาสตร์ก็พร่องลง
    ถ้าสามารถควบคุมเครื่องจักรด้วยภาษาธรรมชาติได้ก็คงดี แต่ในฐานะคนที่เขียนโปรแกรมมาตั้งแต่กลางยุค 80 ผมมองว่า ความแข็งทื่อของภาษาคอมพิวเตอร์ ตั้งแต่ BASIC จนถึง Go สร้างสมดุลที่ดี มันทำให้ฝ่ายที่ออกคำสั่งต้องรับผิดชอบมากพอในการระบุให้ชัดเจนว่าเครื่องควรทำอะไร

  • ผมไม่เห็นด้วยกับข้ออ้างนี้ในระดับหนึ่ง ในบริษัทจริง ๆ ไอเดียฟีเจอร์ใหม่มักเริ่มจากในหัวของคนฝ่ายธุรกิจบางคน คนคนนี้คงไม่พูดภาษาเชิงรูปแบบใด ๆ
    ดังนั้นไม่ว่าจะมองอย่างไร การทำฟีเจอร์ให้เป็นจริงก็ต้องมีการแปลจากภาษาธรรมชาติเป็นภาษาเครื่อง
    โดยปกติ ขั้นแรกซึ่งคือการแปลจากภาษาธรรมชาติเป็นภาษาเชิงรูปแบบ จะทำโดย นักวิเคราะห์ธุรกิจและโปรแกรมเมอร์ ถ้าอย่างนั้นมีเหตุผลอะไรที่จะไม่ลองให้คอมพิวเตอร์ช่วยในกระบวนการนั้น?

    • คอมพิวเตอร์ช่วยในกระบวนการนั้นได้และควรช่วย แต่ประเด็นของ Dijkstra คือ a) ความยากจำนวนมากในไอเดียของมนุษย์ถูกค้นพบในระหว่างการเปลี่ยนภาษาธรรมชาติให้เป็นภาษาเชิงรูปแบบ และ b) การกระทำนั้นเองฝึกฝนตัวตนด้านตรรกะเชิงรูปแบบของเรา
      ดังนั้นเขาไม่ได้โต้แย้งแค่ความคิดที่ว่าเราควรระบุสเปกโปรแกรมด้วยภาษาธรรมชาติเท่านั้น แต่ยังโต้แย้งความคิดที่ว่าถ้าตัดความจำเป็นที่เราต้องเข้าใจภาษาเชิงรูปแบบออกไปแล้ว ความสามารถในการสร้างระบบซับซ้อนของเราจะเพิ่มขึ้นด้วย
      “การแปล” จำนวนมากจริง ๆ แล้วไม่ใช่การแปล แต่เป็นการแก้ ความคลุมเครือทางตรรกะ ความไม่สอดคล้อง และสมมติฐานที่ผิด หากรับ Dijkstra อย่างจริงจัง เรื่องเหล่านี้จำนวนมากก็ทำได้แม้ในภาษาธรรมชาติ เพราะมีโปรแกรมเมอร์ที่ทำการทำให้เป็นรูปแบบมาตลอดชีวิตอยู่ตรงนั้น
      ยังมีอาชีพอื่นที่ต้องใช้การคิดเชิงรูปแบบอย่างมาก เช่น คณิตศาสตร์ นอกจากนี้ ในการแปลงบทพิสูจน์เก่า ๆ ให้เป็นบทพิสูจน์ด้วยคอมพิวเตอร์ ก็พบรูโหว่และช่องว่างในบทพิสูจน์จำนวนมากที่เคยได้รับการยอมรับอย่างกว้างขวาง
      แม้จะมีไม่มากที่ถูกพลิกกลับ แต่เราก็ยังไม่มีบทพิสูจน์ที่สมบูรณ์ของทฤษฎีบทสุดท้ายของ Fermat https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
    • ดูเหมือนคุณยังไม่เข้าใจประเด็นของ Dijkstra อย่างเต็มที่ เขาไม่ได้บอกว่าอย่าใช้เครื่องมือช่วยแปล แต่เขาบอกว่า การไม่คิดด้วยสัญลักษณ์เชิงรูปแบบ ทำร้ายความคิด
      ถ้าไม่คิดอยู่ในระบบเชิงรูปแบบ ไอเดียก็จะแย่ลง เพราะคุณไม่ได้ปฏิบัติต่อความคิดของตัวเองในฐานะสิ่งที่เป็นเชิงรูปแบบ
      สำหรับตัวอย่างว่าจะ “แปล” ไอเดียของ “คนฝ่ายธุรกิจ” อย่างไร เขาคงไม่มีความเห็นมากนัก จากมุมมองของเขา ไอเดียของคนฝ่ายธุรกิจนั้นตื้นและแย่อยู่แล้ว เพราะไม่ได้ยึดตามรูปแบบนิยม และไม่คุ้มค่าที่จะแปล
    • ขั้นแรกไม่ใช่จากภาษาธรรมชาติไปเป็นภาษาเชิงรูปแบบ แต่คือการ ถ่ายทอดไอเดียในหัวออกมาเป็นภาษาธรรมชาติ การทำขั้นตอนนั้นให้ดีพอที่คอมพิวเตอร์จะเปลี่ยนเป็นสิ่งที่มีประโยชน์ได้ต่างหากที่ยาก
    • ถ้าทำแบบนั้น คุณจะไม่รู้ว่าคอมพิวเตอร์กำลังทำอะไรอยู่ ใจความของบทความนี้คือกระบวนการเขียนไอเดียออกมาอย่างเป็นรูปแบบนั้นมีคุณค่าในตัวเอง
      หาก “ให้คอมพิวเตอร์ช่วยตรงกลาง” คุณจะชนเข้ากับปัญหาทันทีว่า เพื่อให้ได้ผลลัพธ์ที่ดีพอจากเครื่องจักร คุณจะต้องใช้ภาษาธรรมชาติที่เป็นรูปแบบมากขึ้นเรื่อย ๆ
    • ธุรกิจแต่ละแบบ กิจกรรมแต่ละอย่าง ก็มี ภาษาเชิงรูปแบบ ของตัวเองไม่ใช่หรือ?
      แม้จะไม่ได้เป็นรูปแบบเท่าภาษาโปรแกรม แต่ก็มีอยู่แน่นอน
      เมื่อพยายามนิยามกระบวนการใด ๆ ต่อให้ไม่รู้ตัว สุดท้ายก็จะเอนเอียงไปทางการทำให้เป็นรูปแบบ

  • “การที่ความผิดพลาดโง่ ๆ จำนวนมากนำไปสู่ข้อความแสดงข้อผิดพลาดแทนที่จะเป็นคำตอบที่ผิด ถือเป็นการปรับปรุงที่สำคัญ แม้แต่การปรับปรุงนี้ก็ใช่ว่าทุกคนจะชอบ บางคนมองว่าข้อความแสดงข้อผิดพลาดที่เพิกเฉยไม่ได้ น่ารำคาญกว่าผลลัพธ์ที่ผิด และเมื่อประเมินข้อดีเชิงเปรียบเทียบของภาษาโปรแกรมมิง ก็ดูเหมือนว่ายังมีคนที่ถือว่า ‘ความง่ายในการเขียนโปรแกรม’ เท่ากับการทำผิดพลาดที่ตรวจไม่พบได้ง่าย”
    ถ้าไม่รู้ว่าใครเขียน คงดูเหมือนเป็นคำพูดที่แทงใจดำ คนที่เกลียด Rust ตรง ๆ

    • Rust? ตั้งแต่เมื่อไหร่ที่ Rust เป็นจุดสูงสุดของ ความปลอดภัยด้านชนิดข้อมูลแบบสแตติก?
      หลังจากได้ใช้ Scala อยู่พักหนึ่ง ซึ่งเป็นภาษาที่แสดง invariant ที่แข็งแกร่งกว่าด้วยชนิดข้อมูลได้มากกว่า Rust ผมก็ไม่ได้มองว่าคุณสมบัตินั้นเป็นชัยชนะที่ชัดเจนในทุกสถานการณ์อีกต่อไป ไม่ได้คิดว่า “ชนิดข้อมูลที่แข็งแกร่งกว่า == ดีกว่าเสมอ” อีกแล้ว
      “การไม่ยอมให้ทำผิดพลาด” มีราคาที่ต้องจ่าย ถ้าระบบชนิดข้อมูลเข้มงวดจริง ๆ งานเชิงสำรวจจะยากขึ้นพอสมควร อาจทำให้วนลูปทดลองอย่างรวดเร็วไม่ได้ด้วย
      การเปลี่ยนแปลงเล็ก ๆ อาจบังคับให้ต้องออกแบบโปรแกรมครึ่งหนึ่งใหม่เพื่อให้ระบบชนิดข้อมูลพอใจอีกครั้ง
      นี่คือ trade-off เหมือนกับทุกอย่าง เหมาะกับผลิตภัณฑ์ปลายทางที่แข็งแรง แต่เป็นอุปสรรคต่อการทดลองอย่างรวดเร็ว
      มีคนอธิบายประเด็นนี้ในบริบทของ Rust กับการพัฒนาเกมไว้ดี: https://loglog.games/blog/leaving-rust-gamedev/
      แต่ปัญหานี้ไม่ได้จำกัดอยู่แค่ Rust หรือการพัฒนาเกมเท่านั้น
    • ผมนึกว่าคงหมายถึงคนที่ชอบ PHP ยุค fractal-of-bad-design หรือ JavaScript แบบ wat-talk อย่างจริงจัง
      ความโง่เขลาบางประเภทดูเหมือนจะอยู่เหนือกาลเวลา
    • ในฐานะคนที่เกลียด Rust ปัญหาคือ ข้อความแสดงข้อผิดพลาด ที่โผล่มาทั้งที่ไม่มีข้อผิดพลาด ระบบชนิดข้อมูลของ Rust ไม่ได้จำลอง RAM, CPU หรืออุปกรณ์ใด ๆ ได้อย่างถูกต้อง
      สิ่งที่เขาพูดถึงตรงนี้คือภาษาแบบอินเทอร์พรีเตอร์
      เขายังเป็นหนึ่งในนักคณิตศาสตร์ที่ปัจจุบันเรียกกันว่านักวิทยาการคอมพิวเตอร์ ซึ่ง “อัลกอริทึม” ของเขาแทบจะเป็นแค่การกล่าวคณิตศาสตร์ซ้ำในอีกรูปแบบ และไม่จำเป็นต้องใช้อุปกรณ์ เป็นคนที่โดยนิสัยแล้วเป็นปฏิปักษ์ต่อกิจกรรมอันน่าอับอายอย่างการเขียนโปรแกรมคอมพิวเตอร์จริง ๆ

  • การระบุสเปกและสร้างแอปพลิเคชันด้วยภาษาธรรมชาตินั้นค่อนข้างคล้ายกับการมี เอกสารออกแบบเกม ก่อนเริ่มทำโปรโตไทป์เกม
    แต่เมื่อคุณสร้างสิ่งที่ต้องการส่วนใหญ่ได้แล้ว ตัว implementation จะกลายเป็นมาตรฐาน และ GDD ก็มักถูกทิ้ง เพราะมันคลาดเคลื่อนจากเกมจริง
    การยืนกรานว่าทุกครั้งที่มีการเปลี่ยนแปลง ต้องอ่าน GDD, implement ฟีเจอร์ แล้วซิงก์ GDD กลับให้ตรงอีกครั้งนั้นยุ่งยากและในทางปฏิบัติไม่ค่อยได้ผล ผมไม่เคยเห็นมันเกิดขึ้นจริง
    ถ้าวันหนึ่ง AI/LLM สามารถเขียนโค้ด Linux หรือ Windows เวอร์ชันถัดไปตั้งแต่ศูนย์ได้ด้วยชุดพรอมป์ต์เพียงอย่างเดียว สมมติฐานทั้งหมดก็จะเปลี่ยนไป แต่ตอนนี้ชัดเจนว่ายังไปไม่ถึงจุดนั้น และก็ไม่รู้ว่าอนาคตจะไปถึงหรือไม่

  • ภาษาธรรมชาติค่อนข้างเหมาะกับการอธิบาย ข้อกำหนดเชิงเทคนิค ของระบบที่ซับซ้อน กล่าวคือเหมาะกับการอธิบายว่าเหตุใดจึงเลือก implementation ปัจจุบันแทน implementation อื่นที่เป็นไปได้ ไม่ใช่อธิบายตัวโค้ด implementation ปัจจุบันเอง
    มันเหมาะกับการใส่สิ่งที่โค้ดควรต้องทำ ไม่ใช่สิ่งที่โค้ดกำลังทำอยู่ กล่าวอีกอย่างคือเหมาะกับการบรรจุส่วนที่ขาดหายซึ่งอยู่ในที่อย่าง Jira ไม่ใช่ใน repository
    นอกจากนี้ หากระบบทั้งระบบถูกอธิบายด้วยกฎภายนอก และสามารถบังคับใช้กฎเหล่านั้นกับ codebase ทั้งหมดได้ ก็อาจให้ความสามารถในการ refactor ที่ดีขึ้นด้วย
    เราใช้ภาษาโปรแกรมมิงกันมา เพราะมันใช้ง่ายในบริบทของระบบอัตโนมัติและคอมพิวเตอร์ และพูดตรง ๆ ก่อนยุค LLM มันก็เป็นวิธีเดียวด้วย
    ภาษาโปรแกรมมิงให้ความไม่กำกวมในระดับเฉพาะที่ แต่ทันทีที่มีใครคัดลอกและวางโค้ดบางส่วน มันก็หยุดทำงานในระดับภาพรวม
    คุณมั่นใจได้ไหมว่าส่วนนั้นเป็นโปรแกรมที่ถูกต้อง โดยยังรักษาข้อจำกัดระดับสูงทั้งหมดที่มันต้องปฏิบัติตามไว้? ถ้าคอมไพล์ผ่าน มันก็เป็นโปรแกรมที่รันได้ แต่คำจำกัดความของการรันนั้นค่อนข้างหลวม ใน C++ แม้แต่โปรแกรมที่ทำให้หน่วยความจำพังทั้งหมดก็ยังรันได้