Notation ในฐานะเครื่องมือสำหรับการคิด (1979)
(jsoftware.com)- Notation เป็นเครื่องมือสำคัญที่ช่วยการคิด และมีบทบาทแกนกลางทั้งในคณิตศาสตร์และภาษาโปรแกรม
- ภาษา APL ถูกพัฒนาขึ้นเพื่อพยายามผสานข้อดีของสัญกรณ์ทางคณิตศาสตร์เข้ากับความสามารถในการรันและความเป็นสากลของภาษาโปรแกรม
- คุณลักษณะของ Notation ที่ดี ได้แก่ ความกระชับ ความชัดเจน ความชี้นำ ความสามารถในการซ่อนรายละเอียดระดับล่าง และความสามารถในการพิสูจน์เชิงรูปแบบ
- สามารถ แสดงและแปลง โครงสร้างทางคณิตศาสตร์ที่หลากหลาย เช่น พหุนาม การแปลง และกราฟ ด้วย APL ได้อย่างมีประสิทธิภาพ
- การนำ Notation มาใช้และการเรียนรู้ ควรเกิดขึ้นอย่างเป็นธรรมชาติภายในบริบท และความเป็นโครงสร้างรวมถึงความอเนกประสงค์ของ Notation ก็มีความสำคัญเช่นกัน
Notation ในฐานะเครื่องมือสำหรับการคิด
- ในสาขาวิทยาศาสตร์อย่างเคมีและพฤกษศาสตร์ ระบบการตั้งชื่อที่เป็นระบบก็ช่วยเร่งความก้าวหน้าของศาสตร์นั้น ๆ
- George Boole เน้นย้ำว่าภาษาเองก็เป็นเครื่องมือของการคิด
- สัญกรณ์ทางคณิตศาสตร์เป็นตัวอย่างเด่นของภาษาที่ช่วยสนับสนุนการคิด โดยลดภาระทางความคิดและเพิ่มพลังในการคิด
- A.N. Whitehead และ Charles Babbage ต่างก็เน้นย้ำความสำคัญของสัญกรณ์ทางคณิตศาสตร์
ศักยภาพของภาษาโปรแกรมในฐานะเครื่องมือสำหรับการคิด
- ภาษาโปรแกรมมีจุดแข็งในด้าน ความอเนกประสงค์ และ ความชัดเจน
- สามารถทดลองไอเดียผ่านคอมพิวเตอร์ และทำการทดลองทางความคิดที่ชัดเจนได้
- อย่างไรก็ตาม ภาษาโปรแกรมส่วนใหญ่ยังมีบทบาทเป็นเครื่องมือสำหรับการคิดที่ด้อยกว่าสัญกรณ์ทางคณิตศาสตร์
- APL ถูกออกแบบให้เป็น Notation ที่สนับสนุนการคิด โดยมุ่งไปที่ความชัดเจนและความแม่นยำ
คุณลักษณะสำคัญของ Notation ที่ดี
- ความง่ายในการแสดงปัญหา: ควรสามารถแสดงโครงสร้างที่ได้มาจากปัญหาโดยตรงได้อย่างง่ายดาย
- ความชี้นำ: รูปแบบที่แสดงออกมาควรสื่อถึงปัญหาที่คล้ายกันหรือปัญหาที่ขยายต่อได้
- การซ่อนรายละเอียดระดับล่าง: มีโครงสร้างที่ช่วยทำให้รายละเอียดที่ซับซ้อนเรียบง่ายลงเพื่อสนับสนุนการคิด
- ความกระชับ: ควรทำให้สามารถแสดงสิ่งต่าง ๆ ได้กว้างขวางด้วยสัญลักษณ์และกฎให้น้อยที่สุด
- ความสามารถในการพิสูจน์เชิงรูปแบบ: Notation ควรเอื้อต่อการพิสูจน์แบบเป็นทางการและการอนุมานเชิงนิรนัย
แนะนำเทคนิคสัญกรณ์พื้นฐานของ APL
- ใช้โครงสร้างแบบอาเรย์ เช่น เวกเตอร์และเมทริกซ์ ได้อย่างเป็นธรรมชาติ
- ฟังก์ชันและโอเปอเรเตอร์จะถูกนำไปใช้กับเวกเตอร์/เมทริกซ์ในระดับองค์ประกอบโดยอัตโนมัติ
- แสดงการประกอบฟังก์ชันด้วยโอเปอเรเตอร์ เช่น reduction(
/), scan(\) และ inner product(.) - สามารถสร้างนิพจน์ที่หลากหลายได้ด้วยสัญลักษณ์พื้นฐาน เช่น
⍳,⌽,⍴,+,×,* - ทุกฟังก์ชันใช้กฎให้ความสำคัญกับด้านขวา จึงเขียนนิพจน์ได้อย่างเป็นธรรมชาติโดยไม่ต้องพึ่งวงเล็บ
ตัวอย่างการแก้ปัญหาและการส่งเสริมการคิด
- แสดงลำดับทางคณิตศาสตร์ เช่น จำนวนสามเหลี่ยมและแฟกทอเรียล ได้ด้วยสูตรที่เรียบง่าย
- จัดการการดำเนินการอย่างการแทนพหุนาม การคูณ และการหาอนุพันธ์ ได้อย่างกระชับด้วยกฎที่สอดคล้องกัน
- ทฤษฎีกราฟ (ต้นไม้, transitive closure, spanning tree) ก็สามารถแสดงได้อย่างชัดเจนด้วยการดำเนินการกับอาเรย์
- สามารถขยายไปใช้กับหลายสาขา เช่น การเรียงสับเปลี่ยน พีชคณิตบูลีน และการแปลงระบบจำนวน (การแยกตัวประกอบเฉพาะ)
การพิสูจน์เชิงรูปแบบและการคิดอย่างมีโครงสร้าง
- เนื่องจากทุกการดำเนินการและนิพจน์ถูกแสดงในรูปที่สามารถรันได้อย่างชัดเจน จึงตรวจสอบอัตโนมัติด้วยคอมพิวเตอร์ได้
- มีการนำเสนอตัวอย่างการพิสูจน์เชิงรูปแบบหลายแบบ เช่น การอุปนัยทางคณิตศาสตร์ การไล่ครบทุกกรณี และการแจกแจงอัตลักษณ์
- พิสูจน์อย่างเป็นทางการถึง identity ของ reduction และ scan รวมถึงสมบัติการเปลี่ยนหมู่และการแจกแจงของการดำเนินการ inner product
- พิสูจน์ฟังก์ชันสมมาตรของนิวตัน รวมถึงสูตรการคูณพหุนามและการหาอนุพันธ์โดยตรง
เปรียบเทียบ APL กับสัญกรณ์คณิตศาสตร์แบบดั้งเดิม
- APL ให้ทั้งการนิยามฟังก์ชันอย่างชัดเจน การดำเนินการกับอาเรย์ที่สอดคล้องกัน และระบบสัญลักษณ์ที่หลากหลาย
- ใช้กฎการประมวลผลจากขวาไปซ้ายกับทุกการดำเนินการ แทนการกำหนดลำดับความสำคัญหลายระดับ
- ลดความซับซ้อนของการใช้สัญลักษณ์ทางคณิตศาสตร์ และสนับสนุน formal manipulation
- ไวยากรณ์กระชับและกฎมีความสม่ำเสมอ จึงเป็นประโยชน์ทั้งต่อผู้เริ่มต้นและผู้มีประสบการณ์
วิธีนำเสนอและเรียนรู้ Notation
- เน้นแนวทางที่ไม่ต้องมี "บทเรียนภาษา" แยกต่างหาก แต่แนะนำเฉพาะสัญกรณ์ที่จำเป็นอย่างเป็นธรรมชาติภายในบริบท
- เรียนรู้สัญลักษณ์ใหม่อย่างเป็นสัญชาตญาณผ่านสถานการณ์ปัญหาที่เป็นรูปธรรม
- สิ่งสำคัญไม่ใช่ความยากของ Notation เอง แต่คือการตระหนักถึงความเป็นไปได้และการต่อยอดที่มันชี้ให้เห็น
ความเป็นไปได้ในการขยาย APL และข้อเสนอแนะ
- เสนอการขยายฟังก์ชันให้รองรับการจัดการจำนวนเชิงซ้อน
- มีความจำเป็นต้องทำให้ฟังก์ชัน unique elements และ summary เป็นมาตรฐาน
- การเพิ่มโอเปอเรเตอร์ที่ทั่วไปยิ่งขึ้นอาจช่วยรองรับหัวข้อเพิ่มเติม เช่น เวกเตอร์แคลคูลัส
- มุ่งยกระดับความชัดเจนของการออกแบบภาษาและความสามารถในการให้เหตุผล
สมดุลระหว่างประสิทธิภาพและความชัดเจน
- แนะนำให้กำหนด Notation ที่ชัดเจนและวิเคราะห์ได้ก่อน แล้วค่อยเพิ่มประสิทธิภาพผ่านการปรับให้เหมาะสม
- การทำให้อัลกอริทึมชัดเจนยังช่วยต่อยอดไปสู่การปรับให้เหมาะสมภายหลังและการ optimize โดยคอมไพเลอร์
- นิพจน์พื้นฐานที่เขียนด้วย APL มีศักยภาพที่จะมีส่วนช่วยทั้งการสำรวจเชิงวิชาการและการประยุกต์ใช้ในอุตสาหกรรม
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มองสัญกรณ์ได้ง่าย ๆ ว่าเป็นเพียง “การแทนนิพจน์หนึ่งด้วยอีกนิพจน์หนึ่ง” คล้ายการขยายของเชลล์ แต่จริง ๆ แล้วลึกซึ้งกว่านั้นมาก
อาจารย์เคยอธิบายว่า การค้นพบอันยิ่งใหญ่มักปรากฏมาพร้อมกับ สัญกรณ์ใหม่ และสัญกรณ์ใหม่ก็หมายถึง “วิธีคิดแบบใหม่ต่อปัญหานี้”
ผมคิดว่าปัญหาที่ยังแก้ไม่ได้จำนวนมากในปัจจุบันก็อาจแก้ได้ หากมีสัญกรณ์ที่ทรงพลังเกิดขึ้น
วิธีนี้ทรงพลังจริง ๆ แต่ใกล้เคียงแนว Lisp ส่วนแนว APL หรือ Clojure จะเน้นทำให้ชนิดพื้นฐานมีประโยชน์มากจริง ๆ
เป็นแนวทางที่แทนที่จะมีโครงสร้างข้อมูล 10 แบบพร้อมฟังก์ชันอย่างละ 10 ตัว ก็มีโครงสร้างข้อมูล 1 แบบพร้อมฟังก์ชัน 100 ตัว ดังนั้นใน APL แทนที่จะสร้าง DSL ก็มักเป็นการออกแบบและจัดวางข้อมูลอย่างระมัดระวัง แล้วส่วนที่เหลือก็เข้าที่เอง
Richard Feynman ตอนเป็นวัยรุ่นเรียนตรีโกณมิติแล้วไม่ชอบสัญกรณ์ของไซน์และโคไซน์ จึงสร้างสัญลักษณ์คณิตศาสตร์ของตัวเองเพื่อทำให้สูตรเรียบง่ายขึ้นและลดสิ่งรบกวน
ต่อมาเขายังสร้างวิธีคิดและวิธีแสดงออกทางฟิสิกส์ขึ้นมาใหม่พร้อมกัน เช่น Feynman diagrams และ slash notation
ตัวอย่างเล็ก ๆ คือเมื่อ CoffeeScript ออกมา การย่อลambda และความสะดวกทางไวยากรณ์หลายอย่างทำให้วิธีเขียน JavaScript เปลี่ยนไปมาก และทำให้คิด อ่าน และแก้ไขได้ง่ายขึ้น
สาย SML/Haskell และตระกูล Lisp ก็ให้ความรู้สึกคล้ายกัน
คิดว่าน่าจะชอบคลิปสั้น ๆ ของ Brian Greene และ Barry Mazur นี้ด้วย: https://youtu.be/8wQepGg8tHA
ในเชิงประวัติศาสตร์ สิ่งที่เบียด APL ออกไปไม่ใช่แค่คีย์บอร์ดแปลก ๆ แต่ยังเป็น Lotus 1-2-3 ของ IBM และ MS Excel ที่ตามมาไม่นาน
วิศวกร แวดวงวิชาการ นักบัญชี และ MBA ต้องการเครื่องมือที่ดีกว่า TI-59 หรือ HP-12C ขณะที่ฝั่งวิทยาการคอมพิวเตอร์กำลังหมกมุ่นกับการประมวลผลสัญลักษณ์, AI และ LISP สุดท้ายอุตสาหกรรมจึงเข้ามายึดพื้นที่นั้นไป
น่าเสียดายที่เป็นความบังเอิญ เพราะ APL น่าจะมีอิทธิพลมากกว่าสเปรดชีตอย่างมาก และแก้ปัญหาได้มากกว่าด้วย
วิสัยทัศน์เดิมคือสัญกรณ์คณิตศาสตร์ที่สอดคล้องกัน เขียนด้วยมือได้ และรันได้ แต่สุดท้ายก็ไม่เคยบรรลุ
หากสนใจ บทความนี้ควรค่าแก่การอ่าน: https://mlajtos.mu/posts/new-kind-of-paper
คุณแก้ปัญหาได้โดยไม่ต้องจ่ายเงิน และจะมีค่าใช้จ่ายเมื่อแจกจ่ายผลลัพธ์ที่คอมไพล์แล้วให้ลูกค้าที่จ่ายเงิน
ถ้าโซลูชันพอดีกับส่วนย่อยบางอย่าง ก็อาจย้ายไป April แล้วให้บริการผ่าน Common Lisp ได้เช่นกัน
อย่างไรก็ดี คนฝั่ง APL โดยทั่วไปค่อนข้างเป็นนักวิชาการมาก จึงทำงานวิศวกรรมได้รวดเร็วและกระชับก็จริง แต่ถ้าในบริษัทซอฟต์แวร์ทั่วไปคุณเริ่มพูดเรื่องอันดับของฟังก์ชันหรือฟังก์เตอร์แบบ Naperian เพื่อนร่วมงานอาจสงสัยว่าคุณต้องการความช่วยเหลือทางการแพทย์หรือไม่
ส่วนสำคัญของการพัฒนาซอฟต์แวร์คือการประดิษฐ์ภาษาทางเทคนิคที่ค่อนข้างเป็นทางการ เพื่อแสดงวิธีที่ลูกค้าและผู้ใช้พูดและคิด แต่ในภาษาตระกูล Iverson เรื่องนี้ทำได้ไม่ง่าย
Java บังคับให้ระบุอยู่นานว่าคำทางธุรกิจใดเข้าและออกจากแต่ละเมธอด และในแง่นั้นจึงทำให้แมปแนวคิดขององค์กรเข้ากับโค้ดได้ง่าย
ใน APL ก็สามารถตั้งชื่อให้ข้อมูลและฟังก์ชันได้ แต่ทันทีที่นำชื่อยาว ๆ และโครงสร้างเนมสเปซเข้ามาเพื่อแมปองค์กรภายนอกเข้ากับโค้ด ก็จะสูญเสียความกระชับและความสง่างามไป
แม้แต่ในระบบชนิดที่ประณีตของตระกูล ML นักพัฒนาก็ยังลำบากในการเชื่อมโยงออนโทโลยีกึ่งภาษาที่ประดิษฐ์ขึ้นกับองค์กรและกระบวนการโดยตรง และมักเลือกใช้แนวคิดเชิงคณิตศาสตร์หรือเชิงวิชาการมากกว่า
ถ้ามีคนที่ทำได้ทั้งสองอย่างก็เป็นไปได้ แต่โดยทั่วไป แค่แปลไปสู่โลกของลูกค้าได้ดีก็มักเพียงพอแล้ว
ปีที่แล้ว The Array Cast เผยแพร่บทสัมภาษณ์ Iverson ปี 1982 อีกครั้ง: https://www.arraycast.com/episodes/episode92-iverson
ค่อนข้างน่าสนใจและเข้าถึงง่ายกว่าปาฐกถา Turing
APL ในปี 1979 ไม่ใช่ภาษาประหลาดและชายขอบเหมือนทุกวันนี้
ตอนนั้นภาษาโปรแกรมยังไม่ได้เป็นปรากฏการณ์มหาชนระดับโลกเหมือนตอนนี้ แทบทั้งหมดจึงดูประหลาดและค่อนข้างชายขอบ และ C เองก็ยังค่อนข้างใหม่ในเวลานั้น
ถ้ามองแบบใจกว้างสักหน่อย APL ดูเหมือน abstraction ที่ไม่ห่างจาก C แบบหนาแน่นมากนัก และเปิดให้เขียนโปรแกรมคอมพิวเตอร์ได้โดยไม่ต้องลงมือทำการจัดการพอยน์เตอร์บนอาร์เรย์เอง
มีตำราไม่น้อยที่สอนคณิตศาสตร์ด้วยไวยากรณ์ APL [1] หรือ J [2]
เดิมที Iverson ใช้ APL เป็นไวยากรณ์ที่ดีกว่าสำหรับคณิตศาสตร์ และการทำเป็นภาษาโปรแกรมเกิดขึ้นตามมาอีกหลายปีหลังจากนั้น
[1] https://alexalejandre.com/about/#apl
[2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
เมื่อก่อนเคยฟังพอดแคสต์เรื่อง ทฤษฎีชนิด ที่ตอนนี้เลิกทำไปแล้ว เนื้อหาลึกลับเข้าใจยากมาก
แนวคิดพื้นฐานเชื่อมโยงกับแนวคิดที่มีประโยชน์อื่น ๆ
สมมติฐาน Sapir-Whorf ก็คล้ายกัน แต่จะน่าสนใจกว่าเมื่อคิดกลับด้าน
ภาษาที่ไม่สมบูรณ์แบบย่อมมีบางสิ่งที่คิดไม่ได้หรือคิดได้ยาก และถ้าเป็นเช่นนั้น ก็ทำให้เราถามได้ว่า มีสิ่งใดบ้างที่เราไม่อาจทั้งแสดงออกและคิดได้ด้วยภาษาที่เราใช้อยู่
ในที่นี้ “ภาษา” และ “ความคิด” สามารถมองให้กว้างกว่าปกติได้
เช่น กฎของปฏิสัมพันธ์ทางสังคมกำหนดวิธีที่เราปฏิสัมพันธ์กันหรือไม่? Zeynep Tufekci กล่าวไว้ใน “Twitter and Teargas” ว่า Twitter ทำให้แฟลชม็อบเป็นไปได้ แต่ทำให้การเปลี่ยนแปลงทางสังคมที่ยั่งยืนเกิดขึ้นได้ยาก
กลไกทางสังคมอย่างการติดตามใครสักคน การแสดงความคิดเห็น หรือการกดไลก์ กำหนดหรือทำให้วิธีที่เราปฏิสัมพันธ์กันเป็นไปได้หรือไม่? กลไกแบบอื่นอาจทำให้การคิดร่วมกันเป็นกลุ่มดีขึ้นได้
ดนตรีก็เช่นกัน ไม่ใช่ในฐานะระบบสัญกรณ์ แต่ดนตรีแสดงบางสิ่งที่แสดงออกได้ไม่ดีนักด้วยวิธีอื่นหรือไม่?
จากมุมมองของคนที่เรียนภาษาต่างประเทศมาหลายภาษา มีหลายสิ่งที่คิดได้เฉพาะในบางภาษา และคิดเป็นภาษาอังกฤษซึ่งเป็นภาษาแม่ได้ยาก
ตัวอย่างเช่น “гулять” ในภาษายูเครนและรัสเซียมีความหมายมากมายที่ภาษาอังกฤษจับไว้ไม่ได้ ดังนั้นก่อนจะเรียนภาษาเหล่านั้น จึงไม่เคยคิดถึงความหมายเหล่านั้นมาก่อน
“Гулять” แปลตามตัวอักษรว่า “เดิน” แต่ยังใช้ในความหมายของการออกไปแสวงหาประสบการณ์ รวมถึงประสบการณ์ทางเพศด้วย
อาจมีคนบ่นว่าใครบางคนแต่งงานเร็วเกินไปว่า “не нагулялся” หรือ “ยังเดินไม่พอ”
ในภาษาอังกฤษก็มีสำนวนคล้าย ๆ อย่าง “sow his wild oats” แต่เมื่อกริยาเดียวอย่าง “เดิน” บรรจุความหมายได้มากเช่นนั้น วิธีคิดเรื่องการเดินผ่านชีวิตก็เปลี่ยนไป
ตอนเรียนภาษาอาหรับก็มีความหมายและความคิดมากมายที่เกิดขึ้นได้เฉพาะในภาษานั้นเช่นกัน ไม่ใช่เพราะอธิบายเป็นภาษาอังกฤษไม่ได้ แต่เพราะไม่มี สัญกรณ์ ที่จะแสดงออกอย่างกระชับ จึงต้องใช้ข้อความยาว
บางคนชอบเดินทางไปสู่ความคิดอื่นผ่านภาษา ขณะที่บางคนกลับชะงักงันต่อหน้าความเป็นไปได้นั้น
เช่นเคย ความสำเร็จอยู่ที่สมดุลและการมีทั้งสองด้าน
แม้จะเป็นเรื่องที่ชัดเจนอย่างยิ่งสำหรับนักคณิตศาสตร์หรือนักวิทยาการคอมพิวเตอร์ แต่แนวคิดนี้กลับเป็นที่ถกเถียงกันมากในหมู่นักภาษาศาสตร์และ “นักการศึกษา”
สิ่งเทียบเคียงทางภาษาศาสตร์คือ สมมติฐาน Sapir-Whorf ซึ่งอ้างว่าภาษาที่เราเรียนรู้เป็นตัวกำหนดวิธีคิด
ภาษาธรรมชาติเป็นวัตถุทางวัฒนธรรม และการทำแผนที่วัฒนธรรมแม้เพียงในรูปของลำดับบางส่วนแบบอ่อน ๆ ก็ถูกมองเหมือนเป็นข้อห้ามในแวดวงวิชาการ
เรื่องนี้ส่งผลอย่างมากต่อการศึกษา เพราะบางครั้งนักเรียนไม่ได้เรียนรู้สัญกรณ์ที่จะช่วยให้พวกเขาให้เหตุผลกับปัญหาที่พบได้จริง ๆ
พูดตามตรง ส่วนนี้ผมไม่ค่อยเข้าใจ
ข้อเท็จจริงที่ว่าผู้พูดภาษาใด ๆ ก็สามารถเรียนคณิตศาสตร์หรือโปรแกรมคอมพิวเตอร์แบบเดียวกันได้ แสดงให้เห็นสิ่งนั้น
ยังน่าสงสัยด้วยว่าภาษาพูดหรือภาษาเขียนจำเป็นต่อความคิดจริงหรือไม่
อย่างน้อยก็มีขอบเขตใหญ่ของความคิดที่เป็นไปได้แม้ไม่มีภาษา และมนุษย์เองก็เคยไม่มีคำพูดหรือมีน้อยมากมาก่อน โดยความคิดและเจตนาที่จะสื่อสารเป็นสิ่งที่ก่อให้เกิดคำและภาษา
ดังนั้นการมองภาษาที่เรียนรู้มาเป็นโมเดลพื้นฐานของความคิดจึงรู้สึกแปลก
เช่น บางคนอ้างว่า ถ้าสังคมหนึ่งเรียกสีของทะเลและสีของหญ้าด้วยคำเดียวกัน คนในสังคมนั้นก็จะไม่สามารถสัมผัสรับรู้ความแตกต่างระหว่างสองสีนั้นได้
ไม่ใช่แค่เข้ารหัสประสบการณ์เป็นความทรงจำในลักษณะที่คล้ายกัน แต่ถึงขั้นมองไม่เห็นความแตกต่าง
ข้ออ้างที่ว่าเสียงที่ไม่มีในภาษาหนึ่งจะไม่ได้ยินเลยก็คล้ายกัน
การอภิปรายเรื่องสัญกรณ์ในที่นี้ใกล้เคียงกับแนวคิดที่ว่าคำศัพท์สามารถใช้ในการสำรวจได้มากกว่า
กล่าวคือ ไม่ใช่แค่บอกว่าได้ยินเสียงบางอย่าง แต่บอกได้ว่าได้ยินดนตรี และได้ยินการดำเนินคอร์ดบางแบบ เป็นต้น
ตอนนี้กำลังพัฒนาโปรเจกต์ด้วย APL
เป็นงานที่อยู่ในแบ็กล็อกมานาน แต่ตอนนี้เริ่มเขียนโค้ดจริงแล้ว
มีช่วงเวลาค่อนข้างยาวระหว่างตอนที่เริ่มสนใจ กับตอนที่สามารถเขียนได้มากกว่าระดับ one-liner
ช่วงต้นของกระบวนการนั้นได้พบเปเปอร์นี้และอ่านซึมซับเข้าไป และตอนนี้แนวคิดเหล่านั้นกลายเป็นฐานรากของความคิดอย่างสมบูรณ์
จริง ๆ แล้วกำลังสอน NAATOT ในโปรแกรมสถาปัตยกรรม
ไม่ใช่สถาปัตยกรรมซอฟต์แวร์ แต่เป็นฝั่งการออกแบบสถาปัตยกรรม
ใช้ฉบับที่ตัดต่อให้คงแก่นของ Iverson ไว้ และเหลือคณิตศาสตร์/การเขียนโปรแกรมจริงไว้เพียงเท่าที่จำเป็นเพื่อแสดงประเด็นหลัก และท้าทายให้นักเรียนคิดถึงความเป็นไปได้ของเครื่องมือออกแบบและการแสดงออกในแบบที่ต่างออกไป
กล่าวคือ มันว่าด้วยกระบวนการก่อรูปความคิด และวิธีแสดงออกต่อทั้งตนเองและผู้อื่น
หากมีโอกาสทำในโปรแกรมที่ยืดหยุ่นและเปิดกว้างกว่านี้ ก็อยากลองจัดคลาสที่ให้นักเรียนสร้าง ระบบสัญลักษณ์/สัญกรณ์ ของตนเองเพื่อนำไปใช้กับพื้นที่ของการออกแบบสถาปัตยกรรม
เสียดายที่ทำ แอปจดโน้ต Freeform ที่เคยทำอยู่ไม่สำเร็จ
เป็นแอปที่คอมไพล์เป็นเว็บเพจแบบสแตนด์อโลนผ่าน SVG และผมคิดว่ามันเป็นไอเดียที่ยอดเยี่ยมจริง ๆ สำหรับคอนเทนต์เชิงเทคนิคที่พบได้บ่อยในสาขา STEM
ตัวอย่างโน้ตเคมีเก่าอยู่ที่นี่: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html
สงสัยว่าตอนนี้ใช้ระบบแบบไหนอยู่
เป็นเวลาหลายปีที่ผมมอง APL เหมือนเวทมนตร์อย่างหนึ่ง จนเมื่อต้นปีนี้จึงหาเวลามาเรียน
ผมทึ่งที่ APL สามารถยัดโค้ดได้มากมหาศาลในขนาดที่พอใส่ลงในทวีตเดียว
สนุกดี แต่เขียนยาก
พอเขียนเสร็จแทบทุกครั้งจะคิดว่า “ฉันใช้เวลานานขนาดนี้เพื่อเขียนสิ่งนี้เลยหรือ?” แล้วก็ลังเลว่าควรใช้เครื่องมืออื่นไหม
แต่ในความเป็นจริง เครื่องมืออื่นน่าจะใช้เวลานานกว่านี้มาก ซึ่งขัดกับสัญชาตญาณพอสมควร
ส่วนที่รู้สึกว่ายากและกินเวลา จริง ๆ แล้วคือกระบวนการที่เราถูกบังคับให้จัดระเบียบข้อกำหนดของปัญหาให้อยู่ในรูปแบบที่บีบอัดมากขึ้น
คล้ายกับการไต่เส้นทางที่ชันกว่าแต่สั้นกว่ามาก จึงรู้สึกเหนื่อยกว่า แต่จริง ๆ แล้วงานน้อยกว่า
เพราะอย่างนั้นจึงรู้สึกว่าควรเรียนและใช้ APL
โดยส่วนตัวผมไม่เห็นด้วยกับสมมติฐานของบทความที่ว่า “สัญกรณ์ทางคณิตศาสตร์ขาดความเป็นสากล และต้องตีความต่างกันตามหัวข้อ ผู้เขียน และบริบท”
ผมคิดว่าสัญกรณ์ที่แยกขาดจากการทำให้ปัญหาเป็นภาพและหลักมนุษยปัจจัยมีต้นทุนสูง
นักวิชาการบางคนชอบสัญกรณ์ที่ซ่อนความซับซ้อนไว้มาก ๆ เพื่อสร้างความเข้าใจแบบ “ยูเรกา” หรือความเท่าเทียมที่คาดไม่ถึง แต่ในบางกรณีกลับทำให้คลุมเครือและเกิดข้อผิดพลาดได้ง่าย
ถึงอย่างนั้น มันก็ยังเป็นเครื่องมือสำคัญในการถ่ายทอดกระบวนการคิดจริง ๆ
ผมคิดว่าการมีเพียง สัญกรณ์มาตรฐาน เดียวสำหรับสาขาหนึ่งหรือสาขาใกล้เคียงกัน ค่อนข้างกดทับแง่มุมเชิงสร้างสรรค์ เชิงศิลป์ และเชิงสำรวจของการให้เหตุผลและการแก้ปัญหา
ยังมีคำอธิบายยอดเยี่ยมของ Terry Tao เกี่ยวกับสัญกรณ์ด้วย: https://news.ycombinator.com/item?id=23911903
ในคณิตศาสตร์มีความพยายามสร้างระบบให้เหตุผลแบบ “เอนเทอร์ไพรซ์” อย่าง Lean, Coq และในกรณีแบบนี้ ระบบสัญกรณ์ที่เป็นสากลก็สมเหตุสมผล
แต่ถ้าเป็นการสำรวจส่วนตัว การหยิบอะไรก็ได้มาปะติดปะต่ออาจดีกว่า
โดยส่วนตัวแล้ว ผมลำบากกับเรื่องนี้มากกว่าในด้านการศึกษา
ในวิชาอย่างพีชคณิต หากครูไม่จัดการการตัดสินใจและความชอบส่วนตัวเกี่ยวกับสัญกรณ์อย่างสม่ำเสมอหรือตรงไปตรงมา ผมจะลำบาก และเมื่อได้ศึกษาทฤษฎีชนิดข้อมูลกับทฤษฎีการพิสูจน์เชิงกล ความสามารถทางคณิตศาสตร์ของผมก็ดีขึ้นมาก
มองว่าแนวคิด “การทำให้รายละเอียดอยู่ในความควบคุม” ในบทความยังไม่ได้ขุดลงไปลึกพอ
หลังจากอ่านและเขียนแอปพลิเคชัน APL มานาน ก็ได้รู้ว่าแนวคิดนี้ชี้ไปยัง วิธีจัดการความซับซ้อน ที่ต่างจาก abstraction โดยพื้นฐาน
พวกเราถูกล้อมด้วยกำแพง abstraction อย่าง API, ไลบรารี, โมดูล, แพ็กเกจ, อินเทอร์เฟซ และผลลัพธ์ก็คือปัญหาที่คุ้นเคย เช่น หอคอย abstraction สูง ๆ, นักพัฒนาที่คอยต่อ API, การตัดขาดจากฮาร์ดแวร์, ความยากในการให้เหตุผลเรื่องประสิทธิภาพ
APL ทำให้แนวทางอีกแบบหนึ่งสะดวกมาก
แทนที่จะออกแบบ abstraction ก็ออกแบบข้อมูลอย่างรอบคอบให้จัดการได้ง่ายด้วย expression เรียบง่าย
คือใช้ primitive operation โดยตรงในจุดที่ปกติจะมีฟังก์ชันไลบรารีหรือศัพท์ของ DSL
ตัวอย่างเช่น สามารถสร้างโครงสร้างคล้าย hashmap ที่มีค่าเป็นเวกเตอร์และคีย์ที่ถูก intern ด้วยตารางสตริง อาร์เรย์คีย์ และอาร์เรย์ค่า แล้วจัดการการแทรก การแสดงผล และการลบได้โดยตรงด้วย expression ของ APL
ข้อดีของวิธีนี้คือแต่ละ expression ไม่ใช่กล่องดำ จึงปรับให้เข้ากับความต้องการเฉพาะได้อย่างเป็นธรรมชาติ
ถ้าเป็นการแทรก hashmap ทั่วไปคงต้องมีโค้ดสำหรับเพิ่มคีย์ใหม่ แต่ตรงนี้ใช้ invariant ร่วมกันได้ว่าเพียงเพิ่มค่าให้คีย์ที่มีอยู่แล้ว
ถ้าเป็น API ไลบรารีก็คงต้องมี code path ที่ไม่ได้ใช้, ฟังก์ชันแทรกหลายรูปแบบ หรือ type inference ที่ซับซ้อนเพื่อกำจัด dead code
แนวทางแบบนั้นทำให้ข้อกังวลที่ไม่เกี่ยวกับโดเมนรั่วเข้ามาใน codebase
แทนที่จะซ่อนรายละเอียด หากทำให้รายละเอียดอยู่ภายใต้การควบคุม เราจะเข้าถึงรายละเอียดเฉพาะโดเมนได้เท่าที่จำเป็น และปล่อยรายละเอียดที่ไม่เกี่ยวข้องให้อยู่เงียบ ๆ เป็นฉากหลังจนกว่าจะต้องใช้
แน่นอนว่าต้องคุ้นเคยกับ expression ของ APL มาก แต่คิดว่าไม่ได้เป็นภาระมากไปกว่าการเรียน ecosystem อย่าง Python แบบลึกซึ้งนัก
ในทางปฏิบัติ สัญลักษณ์ APL จะค่อย ๆ หายไปเป็นฉากหลัง และเริ่มมองเห็นเป็นวลีที่มีความหมาย เหมือนอ่านคำกับวลีภาษาอังกฤษ ไม่ใช่อ่านทีละตัวอักษร
ในภาษาส่วนใหญ่เป็นไปไม่ได้ แต่ถ้าภาษากระชับและมีพลังในการสื่อความมากพอ ก็กลับมาทำได้ในขอบเขตค่อนข้างใหญ่
นึกถึงอยู่เสมอว่า Arthur Whitney เกลียดการเลื่อนหน้าจอมากจริง ๆ
ไม่จำเป็นต้องเปิดไฟล์ 20 ไฟล์แล้วไล่ตาม “ไปยัง definition”
ถ้าโปรแกรมทั้งโปรแกรมอยู่ในหน้าเดียว สิ่งเหล่านั้นก็หายไป และใช้การขยับสายตาในการนำทางแทน
รู้สึกจริงจังว่าควรใช้เวลาเรียนมัน
มันเชื่อมโยงลึกกับความลำบากที่เจอในช่วงหลายสัปดาห์ที่ผ่านมา
กำลังดู โค้ด Python legacy ที่ผูกติดกันแน่นเกินไป และความพยายาม “ปรับปรุง” ทั้งหมดก่อนหน้านี้ล้วนเป็นการโปะ abstraction เพิ่มบน data model ที่ผิด
อ่านโค้ดแบบเส้นตรงแล้วไม่อาจรู้ได้ว่า method ไหนจะเปลี่ยนแปลง object อินพุต
บางอันเปลี่ยน บางอันไม่เปลี่ยน และบางครั้งก็คืน argument อินพุตตัวเดิมกลับมาโดยไม่เปลี่ยนอะไรเลย
ถ้าต้องเลือกระหว่างทะเลแห่งทางอ้อมที่ factory คืน calculator หลายตัวซึ่งไม่ได้แชร์แม้แต่อินเทอร์เฟซเดียวกัน กับ magic string ที่ยังพอวิเคราะห์และเข้าใจได้ ผมขออย่างหลังดีกว่า
เพราะทุก operation เป็น O(n)
แม้จะใช้ operator ทั่วไปได้ แต่ก็ต้องเข้าใจอย่างรอบคอบว่าคู่ค่าหมายถึงอะไรในตรรกะของโดเมน และจะรักษาโครงสร้างที่ถูกต้องในแต่ละ operation อย่างไร
คนที่อ่านโปรแกรมครั้งแรกจะลำบากกับการเข้าใจความหมายของโดเมนธุรกิจพอ ๆ กัน ไม่ใช่กับ primitive operation
ถ้ามีการพัฒนาขึ้น ก็มองว่าไม่ใช่เพราะเอาความซับซ้อนไปไว้ที่อื่น แต่เพราะเห็นโค้ดและค่าจริงพร้อมกัน
สิ่งที่ทำให้การเขียนโปรแกรมซับซ้อนง่ายขึ้นคือการเห็น ข้อมูล ณ เวลารันและ operation ของโค้ด เคียงข้างกัน และนั่นคือเหตุผลที่เครื่องมือ IDE พยายามปรับปรุง debugger กับ inspector อยู่เรื่อย ๆ เพื่อแสดงให้เห็นว่าโปรแกรมทำอะไรในแต่ละขั้น
ในบริบทนี้ ไม่ว่าจะ abstract operation บางส่วนหรือ abstract data structure บางส่วน การสร้าง abstraction ใหม่ที่ดีและกระชับก็ยังเป็นเรื่องดีอยู่ดี
โค้ดแทรกในตัวอย่างส่วนใหญ่ไม่ใช่งานเพิ่มที่ต้องการ แต่เป็นการเกลาข้อมูลเพื่อแปลงรูปแบบที่ interpreter ให้ป้อนเข้าได้ให้เป็นรูปแบบที่ต้องการ
⍪←คือการเพิ่มจริง ๆ ส่วน↓⍉↑()()()ใกล้เคียงกับการ parse และแปลงอินพุตเพื่ออ้อมข้อจำกัดของ APL และ parser อินพุตของ interpreterโค้ดลบก็ต้องสร้าง Boolean array ที่ไม่เกี่ยวกับ problem domain เช่น ต้องห่อ
'buggy'เพื่อค้นหาเป็นองค์ประกอบเดี่ยวของอาร์เรย์ซ้อนคำว่า “สร้าง hashmap ของค่าเวกเตอร์” ก็ทำให้เข้าใจผิด เพราะไม่มีการ hashing จริง
ไม่มีการตรวจคีย์ซ้ำ ปรับการเลือก hash หรือปรับความเร็วกับการกระจายไม่ได้ และคีย์ถูกต่อท้ายตามลำดับทำให้ค้นหาช้า
ใน Dyalog APL ยังมี I-Beam 1500 ซึ่งเป็นคำสั่ง interpreter แบบเวทมนตร์ที่ทำเครื่องหมายอาร์เรย์ให้เป็นเป้าหมายของ internal hashing เพื่อการค้นหาเร็ว แต่ก็ต้องจำไว้เสมอว่า abstraction ภายในรั่วออกมา
ไอเดียดี ๆ ของการออกแบบภาษาและเครื่องมือ เช่น “หลุมแห่งความสำเร็จ”, “มีวิธีเดียวเท่านั้น”, “วิธีแรกที่นึกออกควรเป็นวิธีที่ถูก”, “งานที่ต่างกันควรดูต่างกัน” ขาดหายไปจาก APL
ใน Python หรือ C# syntax อย่าง
kv={'a':1, 'b':2}ทำงานได้เลย และถ้าลืมวงเล็บหรือโคลอนก็จะดูผิดอย่างชัดเจน อีกทั้ง editor กับ compiler ยังช่วยได้การใช้งาน APL พึ่งพาฟังก์ชัน interpreter แบบเวทมนตร์อย่าง
⎕NGET,⎕CSV,⎕JSONสำหรับ input/output และการจัดการ error, logging, debugging ก็อ่อนexpression ทั้งก้อนถูก execute เป็นหนึ่งเดียว และเพราะ hook กับ fork จึงแยกย่อยได้ยาก
สุดท้ายแล้ว ต้องมี sense ที่แม่นยำต่อรูปทรงอาร์เรย์หลากหลายแบบ, ทำไม
⊂3ถึงดูเหมือนไม่ทำอะไรเลย, ความต่างระหว่าง⊆กับ⊂, scalar extension ฯลฯ จึงจะทดลองและเรียนรู้ได้แม้แต่ pattern ที่ควรเข้าถึงได้ทันทีอย่าง “ถ้ามีคีย์ก็อัปเดต ถ้าไม่มีก็เพิ่ม” ใน APL ก็ยังต้องกลับมาคิดตั้งแต่วิธี branch
สิ่งที่ใน Python แค่ใช้
if/elseกับkey in mapหรือใน C# ใช้if/elseกับmap.Contains(key)ก็ผ่านไปได้ กลับพาให้ใน APL ต้องตกลงไปคิดเรื่องการ implement ฟีเจอร์พื้นฐานขึ้นใหม่คล้ายกับข้ออ้างของ Aaron Hsu แต่ให้ความรู้สึกเหมือน Up-Goer 5 หรือ Toki Pona ที่พูดว่า “รถดับเพลิง” ไม่ได้ ต้องพูดว่า “รถของคนที่ทำงานหยุดไฟ”
[1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
[3] https://aplwiki.com/wiki/Scalar_extension
[4] https://xkcd.com/1133/