JetBrains ได้ประกาศแผนการสำหรับภาษาโปรแกรมมิ่งใหม่ที่จะให้นักพัฒนาเขียนโค้ดในรูปแบบที่เป็นภาษาอังกฤษพื้นฐานเพื่อสร้างแอปพลิเคชันข้ามหลายแพลตฟอร์ม แม้ว่าบริษัทจะวางตำแหน่งสิ่งนี้เป็นขั้นตอนถัดไปในการทำนามธรรมของการเขียนโปรแกรม แต่ชุมชนนักพัฒนากำลังตั้งคำถามอย่างจริงจังว่าแนวทางนี้จะได้ผลจริงหรือไม่
นักพัฒนาตั้งคำถามเกี่ยวกับแนวคิดพื้นฐาน
ชุมชนโปรแกรมเมอร์กำลังแสดงความสงสัยอย่างลึกซึ้งเกี่ยวกับวิสัยทัศน์ของ JetBrains นักพัฒนาหลายคนชี้ให้เห็นว่าความพยายามที่คล้ายกันนี้เคยถูกทำมาแล้วซ้ำๆ ตลอดประวัติศาสตร์คอมพิวเตอร์ โดยมีผลลัพธ์ที่หลากหลายในแง่ดีที่สุด ความกังวลหลักมุ่งเน้นไปที่ว่าภาษาธรรมชาติสามารถให้ความแม่นยำที่จำเป็นสำหรับการพัฒนาซอฟต์แวร์ที่ซับซ้อนได้หรือไม่
สมาชิกชุมชนหลายคนได้เปรียบเทียบกับ COBOL ซึ่งพยายามทำให้การเขียนโปรแกรมเป็นเหมือนภาษาอังกฤษมากขึ้นเมื่อหลายทศวรรษที่แล้ว คนอื่นๆ อ้างอิงถึง AppleScript และ HyperTalk เป็นตัวอย่างของความพยายามในการเขียนโปรแกรมด้วยภาษาธรรมชาติในอดีต ธีมที่เกิดขึ้นซ้ำๆ ในการอภิปรายเหล่านี้คือ แม้ว่าภาษาเหล่านี้จะใช้งานได้สำหรับกรณีการใช้งานเฉพาะ แต่พวกมันไม่เคยได้รับการยอมรับอย่างกว้างขวางที่ JetBrains ดูเหมือนจะตั้งเป้าหมายไว้
ความพยายามในการพัฒนาภาษาโปรแกรมมิ่งแบบภาษาธรรมชาติในอดีต:
- COBOL (ทศวรรษ 1960) - ภาษาที่มุ่งเน้นธุรกิจด้วยไวยากรณ์ที่คล้ายภาษาอังกฤษ
- AppleScript (ทศวรรษ 1990) - ภาษาสคริปต์แบบภาษาธรรมชาติสำหรับระบบอัตโนมัติของ Mac
- HyperTalk (ทศวรรษ 1980) - ภาษาที่คล้ายภาษาอังกฤษสำหรับ HyperCard
- Inform 7 (ทศวรรษ 2000) - ภาษาธรรมชาติสำหรับสร้างนิยายแบบโต้ตอบ
ความท้าทายทางเทคนิคและความกังวลเรื่องการกำหนดผลลัพธ์
จุดอภิปรายหลักมุ่งเน้นไปที่การนำไปใช้ทางเทคนิค นักพัฒนากำลังตั้งคำถามว่าการสร้างโค้ดที่ขับเคลื่อนด้วย AI จะมีการกำหนดผลลัพธ์และสามารถทำซ้ำได้หรือไม่ หากนักพัฒนาสองคนใช้ข้อกำหนดภาษาอังกฤษเดียวกันในเวลาที่ต่างกันหรือกับโมเดล AI ที่แตกต่างกัน พวกเขาจะได้ผลลัพธ์เดียวกันหรือไม่ ความไม่แน่นอนนี้อาจสร้างปัญหาร้ายแรงสำหรับการควบคุมเวอร์ชัน การดีบัก และการพัฒนาแบบร่วมมือ
ชุมชนยังกังวลเกี่ยวกับความสามารถในการดีบัก เมื่อโค้ดถูกสร้างจากคำอธิบายภาษาอังกฤษระดับสูง การติดตามบั๊กกลับไปยังแหล่งที่มาจะยากขึ้นมาก ชั้นนามธรรมนี้อาจซ่อนรายละเอียดการนำไปใช้ที่สำคัญซึ่งนักพัฒนาต้องเข้าใจเมื่อเกิดปัญหา
ข้อกังวลของนักพัฒนาเกี่ยวกับแนวทางของ JetBrains :
- ความแน่นอนเชิงกำหนด: ข้อกำหนดภาษาอังกฤษเดียวกันจะสร้างโค้ดที่เหมือนกันทุกประการในโมเดล AI ที่ต่างกันหรือช่วงเวลาที่ต่างกันหรือไม่?
- การดีบัก: จะติดตามข้อผิดพลาดในโค้ดที่ AI สร้างขึ้นกลับไปยังข้อกำหนดภาษาอังกฤษได้อย่างไร?
- ความแม่นยำ: ภาษาธรรมชาติสามารถให้ความแม่นยำที่จำเป็นสำหรับซอฟต์แวร์ที่ซับซ้อนได้หรือไม่?
- ประสิทธิภาพ: IDE ของ JetBrains ในปัจจุบันยังคงมีปัญหาเรื่องการใช้ทรัพยากรและความเสถียร
ปัญหาคุณภาพ IDE ที่มีอยู่บดบังฟีเจอร์ใหม่
บางทีการวิจารณ์ที่แหลมคมที่สุดมาจากผู้ใช้ JetBrains ปัจจุบันที่ต้องการให้บริษัทมุ่งเน้นไปที่การแก้ไขปัญหาที่มีอยู่แทนที่จะพัฒนาฟีเจอร์ทดลองใหม่ นักพัฒนาหลายคนรายงานว่า IDE ของ JetBrains ใช้ทรัพยากรมากขึ้นและมีความเสถียรน้อยลงในการอัปเดตล่าสุด
ผมอยากให้ jetbrains ทำงานเพื่อให้ intellij ไม่กินทรัพยากรมากและไม่ค้างเมื่อทำงานกับโปรเจกต์ขนาดใหญ่แทน
ผู้ใช้กำลังประสบปัญหาการขัดข้อง ปัญหาประสิทธิภาพ และบั๊กที่ส่งผลต่องานประจำวันของพวกเขา นักพัฒนาบางคนแนะนำว่า JetBrains ควรจัดลำดับความสำคัญในการปรับปรุงผลิตภัณฑ์ปัจจุบันก่อนที่จะแตกแขนงไปสู่การพัฒนาภาษาทดลอง
แนวทางทางเลือกได้รับการสนับสนุน
แทนที่จะเป็นการเขียนโปรแกรมด้วยภาษาธรรมชาติ นักพัฒนาหลายคนสนับสนุนแนวทางที่มีโครงสร้างมากขึ้นสำหรับการพัฒนาที่ช่วยเหลือด้วย AI บางคนแนะนำให้ใช้ภาษาที่มีความสามารถในการตรวจสอบอย่างเป็นทางการ เช่น Lean หรือภาษาที่มีระบบประเภทที่แข็งแกร่งซึ่งสามารถตรวจจับข้อผิดพลาดก่อนรันไทม์
คนอื่นๆ เสนอว่าเครื่องมือ AI ควรมุ่งเน้นไปที่การสร้างโค้ดในภาษาที่มีอยู่และเข้าใจได้ดีพร้อมการรับประกันความปลอดภัยที่แข็งแกร่ง แนวทางนี้จะให้ประโยชน์ของความช่วยเหลือจาก AI ในขณะที่รักษาความแม่นยำและความสามารถในการดีบักที่การพัฒนาซอฟต์แวร์ระดับมืออาชีพต้องการ
การอภิปรายเผยให้เห็นชุมชนที่ให้ความสำคัญกับความน่าเชื่อถือและความสามารถในการบำรุงรักษามากกว่าฟีเจอร์ทดลอง ในขณะที่ JetBrains ยังคงพัฒนาภาษาคล้ายภาษาอังกฤษนี้ต่อไป การตอบสนองของนักพัฒนาแสดงให้เห็นว่าพวกเขาอาจเผชิญกับความท้าทายในการยอมรับอย่างมีนัยสำคัญเมื่อเปิดตัวในที่สุด
อ้างอิง: JetBrains working on higher-abstraction programming language