ภาษา D programming language ยังคงสร้างการถกเถียงในชุมชนนักพัฒนาต่อไป โดยการอพสุดล่าสุดเน้นย้ำทั้งความสามารถทางเทคนิคที่น่าประทับใจและอุปสรรคที่ป้องกันการรับเอาไปใช้อย่างกว้างขวาง แม้ว่า D จะเสนอฟีเจอร์ที่น่าสนใจเช่น compile-time function execution, design by contract และ uniform function call syntax แต่ภาษานี้ก็ยังดิ้นรนเพื่อหาตำแหน่งของตัวเองในภูมิทัศน์การเขียนโปรแกรมที่มีการแข่งขันสูง
คุณสมบัติหลักของภาษา D:
- ตัวสร้างอัตโนมัติตามลำดับของฟิลด์
- การออกแบบโดยสัญญาด้วยบล็อก
in,out, และinvariant - ตัวดำเนินการดอลลาร์ ($) สำหรับการย่อความยาวของอาร์เรย์
- การดำเนินการฟังก์ชันในเวลาคอมไพล์ (CTFE)
- เฟรมเวิร์กการทดสอบหน่วยที่มีในตัว
- คำสั่ง switch แบบครอบคลุมด้วย
final switch - ไวยากรณ์การเรียกฟังก์ชันแบบเหมือนกัน (UFCS) ที่อนุญาตให้
f(a)≡a.f() - การนำเข้าแบบมีขอบเขตและเลือกสรร
- ตัวสร้างเอกสารที่มีในตัว
ปัญหาใหญ่เรื่อง Garbage Collection
หนึ่งในอุปสรรคที่สำคัญที่สุดที่ D เผชิญคือความสัมพันธ์กับ garbage collection นักพัฒนาจำนวนมากจากชุมชน C และ C++ ซึ่งเป็นกลุมเป้าหมายหลักของ D พบว่า garbage collector เป็นปัญหาสำหรับกรณีการใช้งานของพวกเขา ปัญหานี้เกินกว่าการหลีกเลี่ยง GC allocation เพียงอย่างเดียว - มันสร้างสิ่งที่บางคนเรียกว่าปัญหาแบบไวรัสที่การดำเนินการพื้นฐานเช่นการจัดการสตริงกลายเป็นเรื่องยากโดยไม่ทำให้เกิด garbage collection
สมาชิกชุมชนหลายคนได้พยายามใช้ D กับ attribute @nogc แต่กลับพบว่าการดำเนินการพื้นฐานต้องการการแก้ไขปัญหาอย่างกว้างขวาง ข้อจำกัดนี้บังคับให้นักพัฒนาต้องยอมรับ garbage collector หรือใช้เวลามากในการเขียนฟังก์ชันพื้นฐานใหม่ ทำให้ D ดูน่าสนใจน้อยลงสำหรับ systems programming ที่การควบคุมหน่วยความจำเป็นสิ่งสำคัญ
ความหลากหลายของฟีเจอร์เป็นดาบสองคม
ชุดฟีเจอร์ที่กว้างขวางของ D แม้จะน่าประทับใจ แต่ก็ถูกวิพากษ์วิจารณ์ว่าสร้างความซับซ้อนโดยไม่มีประโยชน์ที่ชัดเจน ภาษานี้รองรับประเภทพารามิเตอร์หลายแบบสำหรับฟังก์ชัน รวมถึง in, out, inout, ref, scope และ return ref ในการผสมผสานต่างๆ ความยืดหยุ่นนี้สามารถทำให้การดำเนินการง่ายๆ ซับซ้อนโดยไม่จำเป็น โดยเฉพาะสำหรับนักพัฒนาที่มาจากภาษาที่เรียบง่ายกว่า
สำหรับผม D ล้มเหลวในการแทนที่ C++ เพราะขาดการออกแบบ มันเป็นการผสมผสานของฟีเจอร์ที่ยอดเยี่ยมมากกว่า แต่เมื่อคุณเริ่มเรียนรู้รายละเอียด สิ่งง่ายๆ ก็สามารถซับซ้อนมากได้
ความพยายามของภาษาในการรองรับ programming paradigm หลายแบบ - ตั้งแต่โค้ดแบบ procedural สไตล์ C ไปจนถึง functional programming สมัยใหม่ - หมายความว่านักพัฒนาต้องนำทางผ่านวิธีการมากมายเพื่อทำสิ่งเดียวกันให้สำเร็จ แม้ว่าความยืดหยุ่นนี้จะทรงพลังในมือของผู้ที่มีประสบการณ์ แต่มันสร้าง learning curve ที่สูงชันสำหรับผู้เริ่มต้น
ช่องว่างด้าน Tooling และ Ecosystem
ประสบการณ์การพัฒนารอบๆ D ยังคงเป็นความกังวลที่สำคัญ การใช้งาน language server protocol (LSP) ปัจจุบันดิ้นรนกับฟีเจอร์ขั้นสูงของ D เช่น template และ named argument ทำให้ workflow การพัฒนาสมัยใหม่เป็นเรื่องยาก ช่องว่างด้าน tooling นี้กลายเป็นปัญหามากขึ้นเมื่อนักพัฒนารุ่นใหม่คาดหวัง IDE support ที่แข็งแกร่งเป็นข้อกำหนดพื้นฐาน
ความท้าทาย ecosystem ขยายเกินกว่า tooling ไปถึงความพร้อมใช้งานของไลบรารี ไม่เหมือนภาษาอย่าง Rust หรือ Go ที่สร้าง package ecosystem ที่มีขนาดใหญ่ได้อย่างรวดเร็ว นักพัฒนา D มักพบว่าตัวเองต้องเขียน binding สำหรับไลบรารี C ที่มีอยู่หรือใช้งานฟังก์ชันตั้งแต่เริ่มต้น งานพิเศษนี้ทำให้การรับเอาไปใช้ลดลง โดยเฉพาะสำหรับโปรเจกต์เชิงพาณิชย์ที่มี deadline ที่เข้มงวด
ปัจจัย Marketing และ Sponsorship
การขาด corporate backing ของ D ตัดกันอย่างชัดเจนกับภาษาสมัยใหม่ที่ประสบความสำเร็จ Go ได้รับประโยชน์จากการสนับสนุนของ Google, Rust มีการสนับสนุนเริ่มต้นจาก Mozilla และ Kotlin เพลิดเพลินกับการส่งเสริมของ JetBrains D พึ่งพาความกระตือรือร้นของชุมชนและความทุ่มเทของ core maintainer เป็นหลัก ซึ่งจำกัดการมองเห็นและทรัพยากรสำหรับการพัฒนา ecosystem
ช่องว่างการสนับสนุนนี้ส่งผลกระทบไม่เพียงแค่ marketing แต่ยังรวมถึงความพยายามในการพัฒนาอย่างต่อเนื่องที่จำเป็นเพื่อแก้ไขปัญหาพื้นฐานเช่น garbage collection dependencies และการปรับปรุง tooling หากไม่มีการสนับสนุนจากสถาบันที่สำคัญ D จะดิ้นรนเพื่อแข่งขันเพื่อ developer mindshare กับทางเลือกที่ได้รับทุนสนับสนุนอย่างดี
อุปสรรคหลักในการนำไปใช้:
- Garbage Collection: ลักษณะที่แพร่กระจายทำให้การเขียนโปรแกรม
@nogcเป็นเรื่องยาก - ความซับซ้อน: มีหลายวิธีในการทำงานเดียวกัน
- เครื่องมือ: การสนับสนุน LSP ที่ไม่ดี การรวม IDE ที่จำกัด
- ระบบนิเวศ: มีไลบรารีน้อยกว่าเมื่อเปรียบเทียบกับ Rust , Go หรือ C++
- การสนับสนุนจากองค์กร: ไม่มีบริษัทใหญ่สนับสนุนเหมือนคู่แข่ง
- เส้นโค้งการเรียนรู้: ชุดฟีเจอร์ที่กว้างขวางสร้างการเรียนรู้เบื้องต้นที่ชัน
ความเป็นเลิศทางเทคนิคพบกับความเป็นจริงในทางปฏิบัติ
แม้จะมีความท้าทายเหล่านี้ D ยังคงดึงดูดนักพัฒนาที่ชื่นชมความซับซ้อนทางเทคนิค ฟีเจอร์เช่น compile-time function execution, design by contract programming และ dollar operator สำหรับ array indexing แสดงให้เห็นนวัตกรรมที่แท้จริงในการออกแบบภาษา uniform function call syntax ทำให้ method chaining ที่สง่างามซึ่งหลายคนพบว่าอ่านง่ายกว่า function composition แบบดั้งเดิม
อย่างไรก็ตาม ความเป็นเลิศทางเทคนิคเพียงอย่างเดียวไม่ได้พิสูจน์ว่าเพียงพอสำหรับการรับเอาไปใช้อย่างกว้างขวาง ภูมิทัศน์ภาษาการเขียนโปรแกรมให้รางวัลไม่เพียงแค่การออกแบบที่ดี แต่ยังรวมถึงการพิจารณาในทางปฏิบัติเช่นความเป็นผู้ใหญ่ของ ecosystem, การสนับสนุนจากองค์กร และคุณภาพของ developer tooling
การอภิปรายที่ดำเนินต่อไปรอบๆ D สะท้อนความตึงเครียดที่กว้างขวางกว่าในการพัฒนาภาษาการเขียนโปรแกรมระหว่างความหลากหลายของฟีเจอร์และการใช้งานในทางปฏิบัติ ในขณะที่ D เสนอความสามารถที่ทรงพลังสำหรับผู้ที่เต็มใจลงทุนเวลาเพื่อเชี่ยวชาญ ความซับซ้อนและช่องว่าง ecosystem ยังคงจำกัดความน่าสนใจต่อนักพัฒนากระแสหลักที่แสวงหาเครื่องมือที่พิสูจน์แล้วและได้รับการสนับสนุนอย่างดีสำหรับโปรเจกต์ของพวกเขา
อ้างอิง: 10 features of D that I love