ในโลกของการเขียนโปรแกรม มีเพียงไม่กี่หัวข้อที่ก่อให้เกิดการถกเถียงอย่างเร่าร้อนเท่ากับเรื่องสไตล์การเขียนโค้ด เมื่อไม่นานมานี้ ชุมชนเทคโนโลยีได้มีการพูดคุยกันอย่างเข้มข้นเกี่ยวกับผลงานของ Arthur Whitney นักวิทยาการคอมพิวเตอร์ผู้อยู่เบื้องหลังภาษาโปรแกรมที่มีอิทธิพลอย่าง K และ Q รวมถึงฐานข้อมูลประสิทธิภาพสูงอย่าง Kdb+ การสนทนามุ่งเน้นไม่ใช่ที่ตัวภาษาเอง แต่เป็นที่สไตล์การเขียนโค้ด C ของเขาที่หนาแน่นและกะทัดรัดอย่างน่าตกใจ ซึ่งสามารถบรรจุอินเทอร์พรีเตอร์ทั้งหมดไว้ในโค้ดเพียงไม่กี่สิบบรรทัด
การอภิปรายนี้ถูกจุดประกายจากการวิเคราะห์โดยละเอียดของโค้ด C ของ Whitney ที่เผยแพร่ต่อสาธารณะ สำหรับอินเทอร์พรีเตอร์อย่างง่าย ซึ่งเขียนในสไตล์ที่หลายคนอธิบายว่ายากจะทำความเข้าใจได้ โค้ดนี้เป็นตัวอย่างของแนวทางของ Whitney: การใช้มาโครที่มีตัวอักษรเดียวอย่างหนัก การเว้นช่องว่างขั้นต่ำ และการย่อฟังก์ชันทั้งหมดให้อยู่ในบรรทัดเดียว ขณะที่นักพัฒนาต่างศึกษาวิธีการเขียนโค้ดที่ก่อให้เกิดข้อโต้แย้งนี้ พวกเขากำลังตั้งคำถามพื้นฐานเกี่ยวกับว่าอะไรคือองค์ประกอบของโค้ดที่ดี และความกะทัดรัดขั้นสุดนั้นมาพร้อมกับต้นทุนที่สูงเกินไปหรือไม่
ความดึงดูดของความหนาแน่นและการเขียนโปรแกรมบนหน้าจอเดียว
ปรัชญาการเขียนโค้ดของ Arthur Whitney เกี่ยวข้องกับการทำให้หน่วยตรรกะทั้งหมดปรากฏอยู่บนหน้าจอเดียว แนวทางนี้ดึงดูดความสนใจอย่างมากจากนักพัฒนาที่ต้องต่อสู้กับการเดินทางผ่านฐานโค้ดขนาดมหึมา ชุมชนตระหนักดีว่าสไตล์ของ Whitney แสดงถึงความพยายามโดยเจตนาที่จะจัดการกับความซับซ้อนผ่านความกระชับอย่างยิ่งยวด แทนที่จะกระจายมันออกไป across หลายไฟล์และหลายฟังก์ชัน
ความหนาแน่นของมันสูงกว่าโปรแกรม C ส่วนใหญ่มากมาย แต่ก็ไม่ใช่อุปสรรคใหญ่โตต่อความเข้าใจหากคุณไม่พยายาม 'อ่านแบบคร่าวๆ'; คุณจำเป็นต้องอ่านมันทีละตัวอักษรจากบนลงล่าง
นักพัฒนาหลายคนยอมรับว่าเมื่อคุณปรับตัวเข้ากับความหนาแน่นได้แล้ว มันมีความสง่างามบางอย่างในการที่สามารถเห็นโค้ดที่เกี่ยวข้องทั้งหมดได้ในทันที ซึ่งขจัดภาระทางปัญญาในการเลื่อนผ่านหลายพันบรรทัดเพื่อทำความเข้าใจว่าส่วนต่างๆ ของระบบมีปฏิสัมพันธ์กันอย่างไร สไตล์นี้ดึงดูดเป็นพิเศษสำหรับผู้ที่ทำงานบนระบบทางคณิตศาสตร์หรือการเงินที่ซับซ้อน ซึ่งการเห็นภาพรวมเป็นสิ่งที่สำคัญที่สุด
ความกังวลเกี่ยวกับ кошмар ในการบำรุงรักษา
แม้จะมีเสน่ห์ทางปัญญา โปรแกรมเมอร์ C ที่มีประสบการณ์ต่างแสดงความกังวลอย่างจริงจังเกี่ยวกับผลกระทบในทางปฏิบัติของโค้ดที่หนาแน่นเช่นนี้ การพึ่งพามาโครของตัวประมวลผลล่วงหน้า C อย่างหนัก สร้างสิ่งที่หลายคนมองว่าเป็นความยุ่งเหยิงที่ดูแลรักษาไม่ได้ เมื่อมาโครกำหนดโครงสร้างพื้นฐานของภาษาใหม่และแนะนำตัวแปรโดยนัย พวกเขาโต้แย้งว่าผลลัพธ์ที่ได้กลายเป็นภาษาเฉพาะโดเมนใหม่ที่สร้างขึ้นบน C โดยพื้นฐาน
นักพัฒนามือเก่าชี้ให้เห็นว่าสไตล์นี้ละเมิดหลักการพื้นฐานทางวิศวกรรมซอฟต์แวร์ การขาดชื่อที่บอกรายละเอียด การไม่มีความคิดเห็น และความกะทัดรัดอย่างยิ่งยวด ทำให้โค้ดเกือบเป็นไปไม่ได้สำหรับใครก็ตามนอกจากผู้เขียนดั้งเดิมจะเข้าใจและแก้ไข ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ แนวทางนี้สมมติว่าคุณจะจดจำได้เสมอว่าคุณสร้างอะไรไป—ซึ่งเป็นสมมติฐานที่อันตรายในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ระดับมืออาชีพใดๆ
ความท้าทายในการดีบักก์นั้นน่าหนักใจเป็นพิเศษ เมื่อทุกบรรทัดประกอบด้วยการดำเนินการหลายอย่างและตัวประมวลผลล่วงหน้าได้เปลี่ยน C ที่ตรงไปตรงมาให้กลายเป็นสิ่งที่แตกต่างไปโดยสิ้นเชิง การระบุและแก้ไขข้อบกพร่องจึงยากขึ้นเป็นทวีคูณ สิ่งนี้มีความสำคัญอย่างยิ่งในระบบการเงินที่เทคโนโลยีของ Whitney ถูกนำไปใช้งาน
คำวิจารณ์ทั่วไปเกี่ยวกับสไตล์การเขียนโค้ดของ Whitney:
- พึ่งพา C preprocessor macros อย่างหนักในการสร้าง DSL
- ใช้ชื่อตัวแปรและฟังก์ชันเพียงตัวอักษรเดียว
- ขาดคอมเมนต์และเอกสารประกอบ
- เขียนฟังก์ชันทั้งหมดเป็นบรรทัดเดียว
- มีอาร์กิวเมนต์และการพึ่งพาตัวแปรแบบโดยนัย
- การดีบักและบำรุงรักษาทำได้ยาก
- ใช้ส่วนขยายของ C ที่ไม่ได้มาตรฐานทำให้มีข้อจำกัดด้านการพกพา
อิทธิพลของ APL หรือ ความพิเศษส่วนตัว?
ชุมชนแตกออกในประเด็นว่าสไตล์ C ของ Whitney แสดงถึงการขยายหลักการโปรแกรม APL หรือเป็นเพียงความชอบส่วนตัวเท่านั้น บางคนแย้งว่าโดยพื้นฐานแล้วเขากำลังเขียน APL โดยใช้ไวยากรณ์ C โดยนำลักษณะที่เป็นสัญลักษณ์และหนาแน่นของภาษาโปรแกรมอาเรย์มาใช้ในโค้ดการimplement ของเขา คนอื่นๆ ค้านว่าสไตล์นี้ไม่ค่อยเกี่ยวข้องกับ APL เอง แต่เกี่ยวข้องกับแนวทางการแก้ปัญหาของ Whitney แต่ละคนมากกว่า
สิ่งที่ชัดเจนคือสไตล์นี้มีความสม่ำเสมออย่างน่าทึ่งตลอดหลายทศวรรษของงานของ Whitney ตั้งแต่ตัวแปลภาษา J รุ่นแรกๆ ไปจนถึงการimplement K ในปัจจุบัน ความสม่ำเสมอนี้บ่งชี้ว่าแนวทางนี้เป็นไปโดยเจตนา ไม่ใช่โดยบังเอิญ อย่างไรก็ตาม ดังที่ผู้แสดงความคิดเห็นหนึ่งสังเกต แม้ภายในชุมชน APL ด้วยกัน สไตล์ C ของ Whitney ก็ถูกมองว่าสุดขั้วมากกว่าเป็นตัวแทนของแนวปฏิบัติทั่วไป
การโต้เถียงระหว่าง วิศวกรรม กับ ศิลปะ
ในแกนกลาง การอภิปรายสะท้อนให้เห็นถึงความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์: รหัสควรได้รับการปฏิบัติเป็นสิ่งประดิษฐ์ทางวิศวกรรม หรือการแสดงออกส่วนตัว? ผู้สนับสนุนแนวทางของ Whitney ชื่นชอบความงามทางคณิตศาสตร์และประสิทธิภาพของโค้ดที่หนาแน่น พวกเขาเห็นว่ามันเป็นความสำเร็จทางปัญญาที่แสดงถึงความเข้าใจอย่างลึกซึ้งในทั้งขอบเขตของปัญหาและภาษาโปรแกรม
นักวิจารณ์แย้งว่าการพัฒนาซอฟต์แวร์ระดับมืออาชีพต้องการการทำงานร่วมกันและความสามารถในการบำรุงรักษาเหนือสิ่งอื่นใด พวกเขาชี้ไปที่กฎของ Kernighan: การดีบักก์นั้นยากเป็นสองเท่าของการเขียนโปรแกรมในตอนแรก ดังนั้น หากคุณฉลาดที่สุดเท่าที่จะเป็นไปได้เมื่อคุณเขียนมัน แล้วคุณจะดีบักก์มันได้อย่างไร? หลักการนี้แนะนำว่ารหัสควรให้ความสำคัญกับความชัดเจนเหนือความฉลาดเฉลียว โดยเฉพาะในระบบการผลิตที่จัดการมูลค่าทางการเงินจำนวนมาก
การสนทนายัง касается พลวัตของทีมและการถ่ายทอดความรู้ รหัสที่หนาแน่นเช่นนี้สร้างสิ่งที่บางคนเรียกว่า ความปลอดภัยในงานผ่านความคลุมเครือ—ทำให้ตัวเองไม่สามารถแทนที่ได้โดยการเขียนโค้ดที่เข้าใจยาก แม้ว่าสิ่งนี้อาจเป็นประโยชน์ต่อโปรแกรมเมอร์แต่ละคนในระยะสั้น แต่มันสร้างความเสี่ยงอย่างมีนัยสำคัญให้กับองค์กรที่จำเป็นต้องบำรุงรักษาระบบที่สำคัญในระยะยาว
บริบทสมัยใหม่และความหมายของ AI
ที่น่าสนใจคือ การอภิปรายนี้ได้รับความเกี่ยวข้องใหม่ในยุคของผู้ช่วยเขียนโค้ด AI บางกคนกังวลว่าเมื่อมีโค้ดมากขึ้นที่ถูกเขียนด้วยความช่วยเหลือของ AI เราอาจเห็นการเพิ่มขึ้นของโค้ดที่เข้าใจยากซึ่งมนุษย์ทำความเข้าใจและแก้ไขได้ยาก สไตล์ Whitney เป็นตัวอย่างสุดขั้วของสิ่งที่อาจเกิดขึ้นเมื่อโค้ดให้ความสำคัญกับความกะทัดรัดเหนือการสื่อสาร
คนอื่นๆ เห็นคุณค่าที่อาจเกิดขึ้นในการศึกษาสไตล์นี้เป็นตัวอย่างของการแสดงความคิดที่ซับซ้อนอย่างกระชับได้อย่างไร แม้ว่านักพัฒนาส่วนใหญ่ไม่ควรลอกเลียนแบบแนวทางของ Whitney โดยตรง แต่การทำความเข้าใจมันอาจช่วยปรับปรุงวิธีที่เราคิดเกี่ยวกับการจัดระเบียบโค้ดและ abstraction ในสไตล์การเขียนโปรแกรมแบบดั้งเดิมมากขึ้น
ภาษาโปรแกรมและฐานข้อมูลหลักโดย Arthur Whitney:
- ภาษาโปรแกรม A, K, Q: ภาษาโปรแกรมแบบอาร์เรย์ที่ใช้กันอย่างแพร่หลายในวงการการเงิน
- Kdb+: ฐานข้อมูลประสิทธิภาพสูงที่สร้างขึ้นจากส่วนย่อยของ K
- Shakti: ตัวสืบทอดของ Kdb+ ที่ออกแบบมาสำหรับชุดข้อมูลขนาดเล็ก
- J: ภาษาโปรแกรมแบบอาร์เรย์แบบโอเพนซอร์ส (การพัฒนาในช่วงแรก)
บทสรุป
การโต้เถียงที่ยังคงดำเนินอยู่เกี่ยวกับสไตล์การเขียนโค้ด C ของ Arthur Whitney เปิดเผยคำถามที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับสิ่งที่ทำให้โค้ดดี แม้นักพัฒนาส่วนใหญ่จะเห็นพ้องว่าแนวทางของเขาไม่เหมาะสมสำหรับการพัฒนาซอฟต์แวร์แบบทีม หลายคนยอมรับในความสำเร็จทางปัญญาที่มันเป็นตัวแทน สไตล์นี้แสดงให้เห็นว่าฟังก์ชันการทำงานที่มีนัยสำคัญสามารถถูกแสดงออกด้วยความประหยัดอย่างน่าทึ่ง แม้ว่าความประหยัดนั้นจะมาพร้อมกับต้นทุนของความสามารถในการเข้าถึง
ดังที่ผู้แสดงความคิดเห็นหนึ่งสรุปความคิดเห็นที่แบ่งออกอย่างสมบูรณ์แบบ: บางคนเห็นว่าเทียบเท่ากับการอ่าน เนโครโนมิคอน และเป็นโรคจิตจักรวาล ในขณะที่คนอื่นๆ ชื่นชอบว่าสไตล์นี้ดูเหมือนจะ 'ปีนบันไดนามธรรม' ได้อย่างรวดเร็ว ท้ายที่สุดแล้ว การอภิปรายทำหน้าที่เป็นเครื่องเตือนใจที่มีคุณค่าว่าสไตล์การเขียนโค้ดเกี่ยวข้องกับการแลกเปลี่ยนระหว่างความกะทัดรัด ความชัดเจน และความสามารถในการบำรุงรักษา—การแลกเปลี่ยนที่ทีมพัฒนาทุกทีมต้องนำทางตามบริบทและความต้องการเฉพาะของพวกเขา
อ้างอิง: Learning to read Arthur Whitney's C to become Smart