สู่ซอฟต์แวร์ที่เข้าใจได้

 (gracefulliberty.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเขียนโปรแกรมนั้นอ่าน ทดสอบ และบำรุงรักษาได้ยาก อีกทั้งความเข้าใจโปรเจกต์มักกระจุกอยู่กับคนจำนวนน้อย ดังนั้นแทนที่จะ ใช้ LLM ทำให้การเขียนโค้ดเป็นอัตโนมัติ จำเป็นต้องมี abstraction ที่ลดขอบเขตของสิ่งที่ต้องใช้โค้ดลงตั้งแต่ต้น
  • LLM แพร่หลายไปทั้งในหมู่นักพัฒนาและคนที่ไม่ใช่นักพัฒนา แต่ปัญหาอย่าง ผลกระทบทำลายสิ่งแวดล้อม, การอิงโค้ดที่ถูกขโมยมา, ผลลัพธ์ไม่สม่ำเสมอ และการก่อให้เกิดการพึ่งพา ยังคงเป็นเรื่องใหญ่
  • จุดเริ่มต้นคือการกลับแนวปฏิบัติที่เขียนโค้ดก่อนแล้วค่อยเติมเอกสาร โดยย้ายไปสู่ literate programming ที่ เขียนเอกสารก่อน แล้วให้โค้ดตามมาภายหลัง
  • การเขียนโปรแกรมเชิงภาพแบบ GUI และการเขียนโปรแกรมด้วยภาษาธรรมชาติแบบ deterministic อาจทำให้โค้ดเป็นเพียงหนึ่งในหลายรูปแบบการแสดงผล แต่สภาพแวดล้อมเชิงภาพจำเป็นต้องออกแบบด้านการเข้าถึง เช่น การผสานกับ screen reader
  • ความพยายามก่อนหน้าอย่าง Eve และ Inform รวมถึงเครื่องมืออย่าง Entangled และ ReTangled แสดงให้เห็นความเป็นไปได้ในการสร้างซอฟต์แวร์ในรูปแบบที่ทั้งมือใหม่และผู้เชี่ยวชาญเข้าใจได้

LLM ไม่ใช่โมเดลเป้าหมาย

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

ใช้ abstraction แทน automation

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

การเขียนโปรแกรมที่เอกสารมาก่อน

  • ก้าวแรกของซอฟต์แวร์ที่เข้าใจได้คือ การทำเอกสาร
    • หากต้องการให้คนอื่นเข้าใจซอฟต์แวร์ ก็ต้องอธิบายซอฟต์แวร์นั้น
  • วิธีทั่วไปคือเขียนโค้ดก่อน แล้วค่อยเติม doc-comment หรือ ตัวอย่างการใช้งานภายหลัง
  • วิธีที่เสนอคือกลับลำดับ โดยเขียนเอกสารก่อน แล้วค่อยแนบโค้ดเข้าไปภายหลัง
    • อธิบายให้มนุษย์เข้าใจก่อนว่าโปรแกรมทำอะไร แล้วจึงบอกคอมพิวเตอร์ว่าต้องทำอะไร
    • แนวคิดนี้เป็นที่รู้จักในชื่อ literate programming
  • ในแนวทางนี้ แทนที่จะอ่านโค้ดของคนอื่นทันทีแล้วอนุมานเจตนา เราจะอ่านเอกสารก่อนเพื่อเข้าใจเจตนา แล้วจึงตรวจดูโค้ด
  • Entangled เป็นการใช้งานแนวทางนี้ที่ดี
    • เป็น bidirectional tangler ที่ดึงโค้ดจากเอกสารไปวางในไฟล์ซอร์สโค้ดที่เหมาะสม
    • สามารถแก้ไข code block ในเอกสารได้ และเนื้อหาที่แก้ในไฟล์โค้ดปกติก็จะถูกเผยแพร่กลับไปยัง code block ในเอกสารด้วย
    • ยังใช้เครื่องมือเดิมอย่างการทดสอบ การรีแฟกเตอร์ และการจัดรูปแบบโค้ดต่อไปได้ โดยไม่ต้องมีการรองรับ literate programming เป็นพิเศษ
    • tangler เพิ่ม overhead ให้ระบบ build เพียงเล็กน้อย และถือว่าน้อยเป็นพิเศษเมื่อเทียบกับ compiler
  • แนวทางนี้ไม่ได้กำจัดความซับซ้อนของโค้ดเอง แต่สามารถแทนที่ LLM ในส่วนของการทำความเข้าใจโค้ดของผู้อื่นได้

กำจัดโค้ด: GUI และหลายรูปแบบการแสดงผล

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

ทำให้ภาษาธรรมชาติเป็น deterministic abstraction

  • ตรงข้ามกับคำกล่าวว่า LLM ยกระดับ abstraction ขึ้นอีกชั้น LLM ใกล้เคียงกับ automation layer มากกว่า abstraction
  • abstraction layer ต้องคาดการณ์ได้และเชื่อถือได้ โดยเจตนาระดับสูงต้องถูกแสดงอย่างถูกต้องและสม่ำเสมอในระดับต่ำ
  • LLM ตีความ prompt แบบอาศัยความน่าจะเป็นและคาดเดาเจตนา จึงทำงานอย่างคาดการณ์ไม่ได้
    • มันทำให้กระบวนการประมาณผลลัพธ์ของงานแบบสุ่มกลายเป็นอัตโนมัติ
    • หากเรียกว่า abstraction ก็ใกล้เคียงกับ abstraction ที่สูญเสียข้อมูลมาก
  • ความก้าวหน้าของ natural language processing (NLP) เปิดโอกาสให้สร้าง pipeline ที่คาดการณ์ได้ จากภาษาธรรมชาติไปสู่ภาษาเครื่อง
  • เป้าหมายคือการพิมพ์อินพุตเหมือน prompt ของ LLM แต่ได้โปรแกรมที่คาดการณ์ได้และแข็งแรงทุกครั้ง
    • ไม่กลั่นงานของคนอื่นออกมาเป็นค่าเฉลี่ยของโค้ดที่ถูกขโมย แต่สร้างโดยตรงผ่านนิยาม
  • แนวทางนี้สามารถผูกเอกสารกับโค้ดให้แน่นแฟ้นยิ่งขึ้น
    • หากแทนที่ส่วนโค้ดใน literate programming ด้วยภาษาธรรมชาติ ก็อาจเหลือเพียงเอกสาร
    • ข้อความที่อธิบายวิธีทำงานของโปรแกรมให้มนุษย์เข้าใจ อาจเป็นข้อความที่สื่อสารกับเครื่องไปพร้อมกันได้
  • การเขียนโปรแกรมด้วยภาษาธรรมชาตินี้ต้องเป็น deterministic
    • NLP สามารถใช้เพื่อ parse ความหมายจากไวยากรณ์ โดยไม่ต้องพึ่งความสามารถในการสร้างของโมเดล transformer
    • ไวยากรณ์ที่ parse แล้วสามารถแปลงโดยตรงเป็น intermediate representation ที่ถูก compile ตามข้อกำหนดของแพลตฟอร์ม เหมือนภาษาโปรแกรมอื่น ๆ
  • คล้ายกับ Inform แต่จินตนาการถึงรูปแบบที่มีการรับรู้ไวยากรณ์ระดับสูงกว่าและเชื่อมกับเครือข่ายนิยามที่กว้างกว่า
  • ด้วยคุณภาพแบบ deterministic prompt จึงกลายเป็นโค้ดได้อย่างน่าเชื่อถือและสม่ำเสมอ ซึ่งเป็น abstraction layer ที่แท้จริง และต่างจาก LLM โดยพื้นฐาน

ความพยายามก่อนหน้า: Eve และ Inform

  • ไอเดียเหล่านี้ไม่ใช่เรื่องใหม่ และเคยมีความพยายามนำไปใช้งานมาก่อน
  • Eve เป็นทั้งภาษาโปรแกรมและ IDE ที่พยายามทำให้การเขียนโปรแกรมเข้าถึงมนุษย์ได้มากขึ้น
    • ใช้แนวทาง literate programming
    • ฝังภาษาโปรแกรมเชิงข้อมูลเฉพาะโดเมนไว้ในเอกสารที่อธิบายพฤติกรรมของซอฟต์แวร์
    • โค้ดขึ้นกับเอกสาร และสภาพแวดล้อมการเขียนโปรแกรมทั้งหมดก็สะท้อนสิ่งนี้
  • Eve ยังพยายามขยายไอเดียนี้ต่อไป โดยแทนที่ภาษาของตัวเองด้วย NLP query
    • ยังไม่พร้อมรับมือความซับซ้อนของการประมวลผลภาษาธรรมชาติ
    • ในปี 2016 NLP ที่พัฒนามากกว่านั้นยังไม่ใช่สิ่งที่บริษัทที่ไม่ได้เน้นแมชชีนเลิร์นนิงเข้าถึงได้ง่าย
    • ยังทดลอง แนวทางที่เน้น GUI ด้วย
  • อดีตผู้ร่วมพัฒนา Eve ก็พูดถึงความกังวลคล้ายกันเกี่ยวกับความซับซ้อนของโปรเจกต์และข้อจำกัดของ LLM
  • Eve สิ้นสุดลงเพราะเป็น โปรเจกต์ทะเยอทะยานที่ได้เงินลงทุนจาก VC แต่ทำรายได้ไม่สำเร็จ จึงไม่มีโอกาสได้เห็นว่าไอเดียเหล่านี้จะออกผลอย่างไร
  • Inform เป็นภาษา declarative สำหรับสร้าง interactive fiction และแสดงให้เห็นว่าแนวคิดเช่นนี้อาจนำไปใช้ได้กว้างขึ้น
  • แม้มีความเป็นไปได้ว่าภาษาธรรมชาติจะเป็น abstraction ที่รั่วโดยพื้นฐาน แต่ศักยภาพในการทำให้คนทั่วไปควบคุมคอมพิวเตอร์ของตนเองได้โดยตรงนั้นควรได้รับความสนใจมากกว่านี้

ขั้นถัดไปและงานที่เสนอ

  • กำลังพัฒนา ReTangled ในฐานะโปรเจกต์เพื่อสร้างซอฟต์แวร์ที่เข้าใจได้
    • เป็น bidirectional tangler ที่เข้ากันได้กับ Entangled และเขียนด้วย Rust
    • เป้าหมายคือขยาย literate programming ให้มากที่สุดเท่าที่ทำได้ และผสานกับ toolchain เดิมอย่างแนบแน่นในระดับที่สมเหตุสมผล
    • ขณะนี้ยังอยู่ในช่วงพัฒนาเริ่มต้น และยินดีรับการมีส่วนร่วม
  • มีแผนจะเขียนบทความที่สมบูรณ์ยิ่งขึ้นสำหรับ visual programming, literate programming และ natural language programming อย่างละหัวข้อ
  • ในระดับชุมชน มีข้อเสนอให้เดินตามรอย Eve แต่ใช้แนวทางที่แตกต่างออกไปเล็กน้อย
  • เป้าหมายคือการสร้าง สภาพแวดล้อมการเขียนโปรแกรมแบบภาพหรือภาษาธรรมชาติ ที่มีเอกสารดี เข้าถึงได้ และเป็นประโยชน์ได้ตั้งแต่มือใหม่จนถึงผู้เชี่ยวชาญ
  • จุดเริ่มต้นคือการทำเอกสารซอฟต์แวร์ให้ดีขึ้น และเป้าหมายสุดท้ายคือการพลิกแนวคิดของการเขียนโปรแกรมเอง

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นบน Lobste.rs

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

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

  • เหมือนว่าโปรแกรมเมอร์ได้ทอดทิ้ง คนที่ไม่ใช่โปรแกรมเมอร์ ไปแล้ว
    Visual Basic ตายไปแล้ว, PHP แบบไม่ใช้เฟรมเวิร์กก็ดูไม่คึกคัก และ Access ก็แทบจะตายแล้ว ยังเหลือเครื่องมือคล้ายฐานข้อมูลอย่าง Notion หรือ Airtable อยู่บ้าง
    โปรแกรมเมอร์รักการเขียนโค้ดมากเกินไป จนหลายคนห่างไกลจากวิธีแก้ปัญหาเรียบง่ายสำหรับปัญหาเรียบง่าย
    ครั้งหนึ่ง Python เคยกวาดโลกของคนที่ไม่ใช่โปรแกรมเมอร์ เพราะมันดูเรียบง่าย และเครื่องมืออย่าง Pandas ก็ดูใช้ง่ายด้วย น่าสนใจว่ามีโปรแกรมเมอร์จำนวนมากที่มองว่า Python หรือ Pandas ไม่ค่อยดี เช่น พอเห็นโค้ดที่ใช้ Pandas จัดการสิ่งที่ทำได้ง่าย ๆ ด้วยไลบรารีมาตรฐาน ก็รู้สึกเอียนพอสมควร
    เมื่อก่อนคนที่ไม่ใช่โปรแกรมเมอร์ก็สร้างหน้า HTML ใส่สีและรูปภาพกันได้ ทุกวันนี้ถ้าขอให้โปรแกรมเมอร์ทำเว็บไซต์แบบสแตติกให้ ก็มักพ่วงความซับซ้อนเหลือเชื่อมาด้วย บางส่วนก็จำเป็น แต่ส่วนใหญ่ไม่จำเป็นเลย ถ้าเอาขั้นตอนที่โปรแกรมเมอร์ใช้ทำเว็บไซต์เรียบง่ายไปให้คนที่ไม่ใช่โปรแกรมเมอร์ คนที่เมื่อ 20 ปีก่อนคงสนุกกับการแก้ HTML ก็คงกรีดร้องแล้ววิ่งหนีไป
    เป็นเรื่องย้อนแย้งและน่ากังวลอย่างยิ่งที่ทุกวันนี้บางอย่างกลับยากขึ้นมาก

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

  • เห็นด้วยกับหลายส่วนของบทความ เช่น ผม/ฉันชอบ literate programming แต่ไม่ได้คิดว่าการเขียนโปรแกรมเองนั้นแย่
    การเขียนโปรแกรมบางแบบแย่ และการเขียนโปรแกรมที่ทำกันในบริษัท BigTech โดยมากก็มักแย่ แต่การเขียนโปรแกรมเพื่อตัวเองหรือคนที่รักยังคงสนุกอยู่
    ไม่เคยรู้จัก Entangled มาก่อน แต่ดูเป็นไอเดียที่ดี และแก้ปัญหา LSP กับเครื่องมือเดิมไม่รับรู้ ซึ่งเป็นความเจ็บปวดใหญ่ที่สุดของ literate programming ด้วยเหตุนี้ที่ผ่านมาเลยใช้ literate programming เป็นหลักกับภาษาประกาศอย่างการตั้งค่า NixOS
    ถ้าเป็น literate programming แบบสองทาง ก็อาจทำให้ชีวิตสบายขึ้นเวลาต้องใช้ภาษาที่ไม่ใช่แบบประกาศ คิดว่าจะลองใช้ ReTangled ดู

    • การเขียนโปรแกรมไม่ได้แย่ ผม/ฉันเห็นด้วยกับผู้เขียนจนถึงประโยคนั้น แต่พอมีคำว่า “ยอมรับ GUI กันเถอะ” ความสนใจก็ลดลง
      GUI ดูเหมือนมีอยู่เป็นหลักเพื่อให้ผู้บริหารระดับสูงขึ้นไปเชื่อว่าพนักงานกำลังทำสิ่งที่พวกเขาเข้าใจและทำเองได้
      เคยเรียนเครื่องมือ ETL แบบลากแล้ววางเชิงภาพ สิ่งที่ติดอยู่ในหัวคือคงยากที่จะสร้างสิ่งที่แทบเหมือนระบบแรกขึ้นมาใหม่ และก็คงยากที่จะทำ version control ทั้งระบบ ระบบทดแทน cron แบบลากแล้ววางเชิงภาพที่บริษัทตอนนั้นใช้ในปี 2010 ก็คล้ายกัน
      ผู้บริหารลากแล้ววางได้ง่าย แต่คนทำงานจริงกลับ หาข้อผิดพลาด รักษาเวอร์ชัน/แบ็กอัป และนำกลับมาใช้ซ้ำได้ยากขึ้น
    • ถ้าฟังก์ชันนั้นเป็นวัตถุประสงค์หลัก แนะนำให้ใช้ Entangled จนกว่า stitching ใน ReTangled จะทำงานได้
    • ในกระบวนการยกระดับสิ่งที่ใช้แล้วสนุกเป็นช่วง ๆ ให้กลายเป็นสิ่งที่ผู้ใช้จะชอบได้จริง มีช่วงที่หนักหนาสาหัสอยู่
      การทำต้นแบบที่น่าสนุกให้พร้อมขึ้น production ต้องใส่เรื่องการจัดการข้อผิดพลาด, serialization, deserialization, การฉายภาพชนิดข้อมูล และอื่น ๆ อีกมาก หนึ่งในกฎของผม/ฉันคือประสบการณ์ผู้ใช้ที่ยอดเยี่ยมแทบจะมาพร้อมโครงสร้างภายในที่เละเทะเสมอ
      โดยส่วนตัวไม่ได้สนุกกับส่วนใหญ่ของเรื่องนั้น และในอดีตก็เคยใช้ทางลัดหรือไม่ทำงานส่วนนั้นไปเลย

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

  • เรามีเป้าหมายเดียวกัน และผมครุ่นคิดมาหลายปีแล้วว่าเทคสแต็กแบบไหนจะให้คำตอบที่ตรงกับสิ่งที่ผมอยากใช้จริง ๆ
    ผมเคยเปิดโปรเจกต์หนึ่งชื่อ Curv ออกมา แต่ก็เป็นเพียงส่วนเล็ก ๆ ของระบบที่สวยงามกว่านั้นมาก ซึ่งยังอยู่แค่ในหัว
    คนอื่นอีกหลายพันคนก็ทุ่มเทกับปัญหานี้เหมือนกัน ด้วยขนาดของปัญหา ดูเหมือนว่าต้องใช้ งานเป็นทีม แต่ในความเป็นจริง ส่วนใหญ่กลับเป็นโปรเจกต์เล็ก ๆ ของคนคนเดียว คนที่มีวิสัยทัศน์แรงกล้าที่สุดมักไม่อยากประนีประนอมวิสัยทัศน์ของตัวเองเพื่อเป้าหมายของทีม ผมก็ไม่รู้เหมือนกันว่าควรแก้เรื่องนี้อย่างไร
    โปรเจกต์ที่ให้แรงบันดาลใจมีทั้งวิสัยทัศน์ Dynabook ของ Alan Kay, Smalltalk ที่สืบต่อมาจากแนวคิดนั้น, STEPS Toward the Reinvention of Programming ซึ่งเป็นโปรเจกต์ถัดมาของ Alan Kay, งานของ Bret Victor โดยเฉพาะผลงานอันน่าทึ่งของเขาอย่าง Dynamicland
    คอมมูนิตี้ที่สนใจหัวข้อนี้มี Feeling of Computing ซึ่งเมื่อก่อนเรียกว่า Future of Coding ถ้ามีอะไรเพิ่มเติมก็ช่วยบอกด้วย

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

  • ถ้าสนใจ สภาพแวดล้อมการเขียนโปรแกรมเชิงภาพ ที่สมบูรณ์ Glamorous Toolkit เป็นตัวอย่างที่ดีของทิศทางที่เป็นไปได้ https://gtoolkit.com/
    ผมยังไม่คิดว่ามันเป็นรูปแบบที่เสร็จสมบูรณ์แล้ว แต่เป็นเครื่องมือที่ผลักสิ่งที่มีอยู่เดิมไปได้ไกลกว่า ในยุคของโค้ดที่สร้างโดย LLM ก็มีประเด็นให้พูดถึงสภาพแวดล้อมแบบอิงภาพด้วย

    • ผมลองไล่ดูเว็บไซต์ของ Glamorous Toolkit แล้ว แต่จับไม่ได้เลยว่ามันคืออะไร ช่วยสรุปเป็นไม่กี่ประโยคได้ไหม?

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