การอภิปรายที่กำลังเติบโตในชุมชนโปรแกรมเมอร์มุ่งเน้นไปที่วิธีที่ลำดับของส่วนประกอบโค้ดส่งผลต่อทั้งประสบการณ์ของนักพัฒนาและการสนับสนุนเครื่องมือ การอภิปรายนี้เน้นความแตกต่างพื้นฐานระหว่างภาษาต่างๆ เช่น Python และ Rust โดยเฉพาะอย่างยิ่งเกี่ยวกับวิธีที่ไวยากรณ์ส่งผลต่อการเติมข้อความอัตโนมัติของ IDE และการค้นพบโค้ด
ปัญหาการเติมข้อความอัตโนมัติใน List Comprehensions
List comprehensions ของ Python นำเสนอความท้าทายที่เป็นเอกลักษณ์สำหรับนักพัฒนาและเครื่องมือของพวกเขา เมื่อเขียน [line.split() for line in text.splitlines()] โปรแกรมเมอร์ต้องอ้างอิงตัวแปรก่อนที่จะมีการประกาศ สิ่งนี้สร้างประสบการณ์ที่น่าหงุดหงิดที่ IDE ไม่สามารถให้คำแนะนำที่เป็นประโยชน์ได้จนกว่าการแสดงออกทั้งหมดจะเสร็จสมบูรณ์ ตัวแปร line ปรากฏขึ้นก่อนใน comprehension แต่ไม่ได้ถูกกำหนดจนกว่าจะถึงส่วน for ที่อยู่ภายหลังในคำสั่ง
รูปแบบการอ้างอิงย้อนกลับนี้บังคับให้นักพัฒนาต้องเดาชื่อเมธอดหรือเขียน comprehension แบบไม่เป็นลำดับ แล้วจึงกลับไปกรอกส่วนที่ขาดหาย นักพัฒนา Python ที่มีประสบการณ์หลายคนได้นำวิธีแก้ปัญหาชั่วคราวมาใช้ เช่น การเขียนส่วน for ก่อนเพื่อเปิดใช้งานการเติมข้อความอัตโนมัติ จากนั้นจึงกลับไปทำการแสดงออกให้เสร็จสมบูรณ์
การเปรียบเทียบไวยากรณ์ของภาษาโปรแกรม
| ภาษา | รูปแบบไวยากรณ์ | ตัวอย่าง | การสนับสนุนจาก IDE |
|---|---|---|---|
| Python | List Comprehension | [line.split() for line in text.splitlines()] |
จำกัดจนกว่าจะเขียนเสร็จ |
| Rust | Method Chaining | text.lines().map(|line| line.split_whitespace()) |
ระบบเติมคำอัตโนมัติเต็มรูปแบบ |
| JavaScript | Method Chaining | text.split(" ").map(word => word.length) |
ระบบเติมคำอัตโนมัติเต็มรูปแบบ |
| SQL | แบบดั้งเดิม | SELECT columns FROM table WHERE condition |
การแนะนำคอลัมน์แบบจำกัด |
| PRQL | แบบ Pipe-based | from table | select columns | filter condition |
ความตระหนักรู้บริบทที่ดีกว่า |
Method Chaining ให้การสนับสนุนเครื่องมือที่ดีกว่า
ภาษาที่รองรับ method chaining เช่น Rust และ JavaScript ให้ประสบการณ์การพัฒนาแบบเชิงเส้นมากกว่า ใน Rust ที่เป็น text.lines().map(|line| line.split_whitespace()) แต่ละขั้นตอนสร้างขึ้นอย่างเป็นธรรมชาติจากขั้นตอนก่อนหน้า ทันทีที่นักพัฒนาพิมพ์ชื่อตัวแปร โปรแกรมแก้ไขของพวกเขาสามารถแนะนำเมธอดที่ใช้ได้ทันทีตามประเภทที่ทราบ
แนวทางแบบซ้ายไปขวานี้สอดคล้องกับวิธีที่นักพัฒนาหลายคนคิดเกี่ยวกับการแปลงข้อมูล โค้ดอ่านเหมือนไปป์ไลน์ที่ข้อมูลไหลจากการดำเนินการหนึ่งไปยังอีกการดำเนินการหนึ่ง ทำให้ทั้งการเขียนและการอ่านเป็นธรรมชาติมากขึ้น
SQL เผชิญความท้าทายที่คล้ายกัน
การอภิปรายขยายไปเกินกว่าภาษาโปรแกรมมิ่งทั่วไปไปยัง SQL ซึ่งประสบปัญหาคล้ายกัน SQL แบบดั้งเดิมต้องการการเขียนส่วน SELECT ก่อนส่วน FROM ทำให้เป็นไปไม่ได้สำหรับเครื่องมือในการให้คำแนะนำคอลัมน์ที่มีความหมายจนกว่าแหล่งข้อมูลจะถูกระบุในภายหลังในคิวรี
ภาษาคิวรีสมัยใหม่หลายภาษาและส่วนขยาย SQL ได้แก้ไขปัญหานี้โดยอนุญาตไวยากรณ์แบบ FROM-first เครื่องมือเช่น PRQL และส่วนขยายสำหรับฐานข้อมูลเช่น DuckDB ตอนนี้รองรับการเรียงลำดับคิวรีที่เป็นธรรมชาติมากขึ้นซึ่งช่วยให้ IDE ช่วยเหลือได้ดีขึ้น
วิธีแก้ไขด้วย Pipe Operator
ภาษาโปรแกรมมิ่งเชิงฟังก์ชันหลายภาษาได้นำ pipe operators มาใช้เพื่อแก้ปัญหาแบบซ้ายไปขวา ภาษาเช่น F# , Elixir และ R ใช้ไวยากรณ์ pipe เพื่อเชื่อมโยงการดำเนินการในลำดับการอ่าน แนวทางนี้รวมประโยชน์ของการโปรแกรมเชิงฟังก์ชันกับความสามารถในการอ่านและการสนับสนุนเครื่องมือที่ดีขึ้น
ฉันคิดถึง pipe operator ของ F# ในภาษาอื่นๆ มันเป็นธรรมชาติมากที่จะคิดถึงไปป์ไลน์การแปลงฟังก์ชัน
Pipe operator ได้รับการเสนอสำหรับ JavaScript แต่ยังคงติดอยู่ในการอภิปรายของคณะกรรมการ ซึ่งเน้นความท้าทายในการพัฒนาไวยากรณ์ภาษาที่มีอยู่แล้ว
ภาษาโปรแกรมที่มี Pipe Operators
- F#: ตัวดำเนินการ
|>สำหรับการเชื่อมโยงฟังก์ชัน - Elixir:
|>สำหรับไปป์ไลน์การแปลงข้อมูล - R:
|>และ%>%( magrittr ) สำหรับเวิร์กโฟลว์การวิเคราะห์ข้อมูล - OCaml:
|>สำหรับการประกอบฟังก์ชัน - Clojure: มาโครแบบ threading
->และ->> - Haskell: มีไลบรารีไปป์ไลน์หลากหลายรูปแบบ
- PHP 8.5: กำลังจะรองรับ pipe operator ในอนาคต
เกินกว่าการเติมข้อความอัตโนมัติ: ความเข้าใจโค้ด
ในขณะที่การสนับสนุนเครื่องมือขับเคลื่อนการอภิปรายนี้เป็นส่วนใหญ่ ประโยชน์ขยายไปถึงผู้อ่านที่เป็นมนุษย์ด้วย โค้ดที่ไหลแบบซ้ายไปขวาโดยทั่วไปต้องการการกระโดดทางจิตใจระหว่างส่วนต่างๆ ของการแสดงออกน้อยกว่า การเรียกฟังก์ชันที่ซ้อนกันซับซ้อนบังคับให้ผู้อ่านแยกวิเคราะห์จากด้านในออกไปด้านนอก ในขณะที่ method chains และ pipes อนุญาตให้อ่านตามลำดับ
อย่างไรก็ตาม นักพัฒนาไม่ทุกคนเห็นด้วยว่าซ้ายไปขวาดีกว่าในทุกกรณี บางคนโต้แย้งว่า comprehensions ของ Python แม้จะมีความท้าทายในการเติมข้อความอัตโนมัติ แต่ยังคงอ่านได้มากกว่าสำหรับการดำเนินการที่ซับซ้อน การอภิปรายมักจะลงเอยด้วยความชอบส่วนบุคคลและกรณีการใช้งานเฉพาะ
อนาคตของไวยากรณ์การโปรแกรม
เมื่อผู้ช่วยเขียนโค้ดที่ขับเคลื่อนด้วย AI กลายเป็นที่แพร่หลายมากขึ้น บางคนตั้งคำถามว่าการยศาสตร์ไวยากรณ์สำคัญมากเท่าไหร่ เครื่องมือเหล่านี้สามารถเอาชนะข้อจำกัดของรูปแบบการอ้างอิงย้อนกลับได้โดยการเข้าใจบริบทลึกกว่า IDE แบบดั้งเดิม
อย่างไรก็ตาม หลักการพื้นฐานยังคงมีความเกี่ยวข้อง: ภาษาโปรแกรมมิ่งได้รับประโยชน์จากไวยากรณ์ที่สนับสนุนทั้งความเข้าใจของมนุษย์และความช่วยเหลือของเครื่องมือ ภาษาที่ประสบความสำเร็จมากที่สุดในอนาคตน่าจะเป็นภาษาที่พิจารณาประสบการณ์นักพัฒนาเป็นเป้าหมายการออกแบบหลัก ไม่ใช่ความคิดเสริม
อ้างอิง: Left to Right Programming