มีกลไกใดที่ทำให้ภาษาการเขียนโปรแกรมมีเสถียรภาพมากขึ้น (ใช้งานร่วมกันได้) สำหรับการเปลี่ยนแปลงหรือไม่?


14

มีภาษาการเขียนโปรแกรมจำนวนมาก บางคนเติบโตและเป็นที่นิยมมาก ผู้คนใช้ภาษาเหล่านี้บ่อยขึ้นเรื่อย ๆ ผู้ก่อตั้งภาษาดังกล่าว (หรือผู้ก่อตั้งองค์กร / ชุมชน) อาจพยายามใช้การเปลี่ยนแปลงเพื่อทำให้ภาษาดีขึ้น แต่บางครั้งมันก็ยากที่จะเปลี่ยนแปลงเนื่องจากความเข้ากันได้แบบย้อนหลังและสิ่งที่น่าเกลียดดังกล่าวมีอยู่แล้วในภาษามานานหลายปีและมีการใช้งานโดยผู้ใช้หลายคน

มีหลักการหรือขั้นตอนสถาปัตยกรรมใด ๆ ในระหว่างขั้นตอนการออกแบบภาษาซึ่งสามารถช่วยทำให้มีเสถียรภาพมากขึ้นดังนั้นนักออกแบบภาษาจะไม่กลัวที่จะทำลายความเข้ากันได้แบบย้อนหลังหรือไม่?


2
ความมั่นคงของภาษาไม่รวมการเปลี่ยนแปลงใด ๆ ที่ทำลาย คุณช่วยชี้แจงคำถามของคุณได้ไหม?
Simon Bergot

เสถียรภาพมากขึ้นหมายถึงฉันมีการเปลี่ยนแปลงน้อยลง (หวังว่าเพราะพวกเขาไม่จำเป็น) ตรงข้ามกับการเปลี่ยนแปลงที่เข้ากันไม่ได้ คุณสนใจเรื่องไหนหรือคุณถามทั้งสองเรื่องด้วยตนเอง?

@Simon วิธีการออกแบบภาษาที่เมื่อคุณพยายามที่จะเพิ่มคุณสมบัติใหม่คุณไม่กลัวที่จะเบรกกลับเปรียบเทียบ
Viacheslav Kondratiuk

@delnan ให้พูดทั้งสอง
Viacheslav Kondratiuk

@viakondratiuk ไม่กลัวว่าจะมีบางสิ่งที่ภาษาสามารถเปลี่ยนได้ คำถามที่ดีกว่าอาจเป็น "วิธีการออกแบบภาษาเพื่อให้การเพิ่มคุณสมบัติใหม่ไม่ทำให้เกิดการเปลี่ยนแปลงที่แตกหัก "
svick

คำตอบ:


6

ความมั่นคงทางภาษาไม่ใช่การตัดสินใจทางเทคนิค มันเป็นสัญญาระหว่างผู้เขียนภาษาและผู้ใช้

ผู้เขียนโฆษณารุ่นที่ระบุว่ามีเสถียรภาพมากขึ้นหรือน้อยลง ภาษาที่มีความเสถียรน้อยกว่าคือการเปลี่ยนแปลงที่ผู้เขียนสามารถทำได้มากขึ้น ผู้ใช้แต่ละคนที่สนใจภาษาสามารถตัดสินใจได้ว่าเขาต้องการลงทุนเวลาในการเรียนรู้คุณสมบัติใหม่ ๆ หรือพัฒนาแอปพลิเคชั่นที่อาจเสียไปจากการอัพเดทในเดือนหน้า

การใช้ภาษาที่ไม่เสถียรอาจเป็นเรื่องที่น่าสนใจเพราะคุณสนใจในแนวคิดใหม่หรือคุณต้องการความช่วยเหลือด้วยการแสดงความคิดเห็น หากคุณเป็นธุรกิจคุณอาจต้องรอให้เทคโนโลยีมีความเสถียรมากขึ้นก่อนที่จะลงทุนเวลาของคุณคุณใส่ใจสิ่งต่าง ๆ เช่นเวลาออกสู่ตลาดและประสบการณ์ผู้ใช้

ดังนั้นนี่คือปัญหาการสื่อสารและความน่าเชื่อถือ ดูการพัฒนาภาษาสนิม พวกเขาชัดเจนเกี่ยวกับสิ่งที่กำลังเปลี่ยนแปลงและสิ่งที่พวกเขารักษา เมื่อพวกเขาต้องการชะลอการตัดสินใจเกี่ยวกับคุณลักษณะที่กำหนดพวกเขาใช้สิ่งที่พวกเขาเรียกประตูเกท ในอีกด้านหนึ่งทีมเชิงมุมต้องเผชิญกับความโกรธอย่างมากต่อการประกาศ 2.0 ของพวกเขาเพราะการเปลี่ยนแปลงใหญ่กว่าที่คาดไว้

แม้แต่ผู้เขียนห้องสมุดก็ต้องสื่อสารเกี่ยวกับความเสถียรของ apis เทคโนโลยีใด ๆ ที่คนอื่นใช้ต้องสร้างความสมดุลระหว่างความมั่นคงและความสมบูรณ์แบบ ผู้ผลิตรถยนต์ไม่สามารถเปลี่ยนตำแหน่งของคันเหยียบและนักออกแบบแล็ปท็อปจะไม่ประดิษฐ์รูปแบบแป้นพิมพ์ใหม่ด้วยเหตุผลเดียวกัน: คุณไม่ได้ช่วยเหลือผู้ใช้ของคุณหากคุณไม่สามารถตัดสินใจได้ว่าจะใช้ผลิตภัณฑ์ของคุณอย่างไร


5
  • โปรดระวังว่าภาษาเปลี่ยนไปตลอดชีวิตโดยไม่คำนึงว่าภาษานั้นจะได้รับการออกแบบไว้ล่วงหน้าดีเพียงใด แทนที่จะพยายามจัดส่งภาษาที่ยอดเยี่ยมที่สุดในโลกทันทีให้ลองใช้ประโยชน์และขยายออกไปก่อน ปานกลางถึงปานกลางซึ่งฉันสามารถใช้งานได้จริงมีค่ามากกว่าภาษาโปรแกรมที่ยอดเยี่ยมใด ๆ ที่มีอยู่ในทฤษฎีเท่านั้น
  • พิจารณาเครื่องมืออำนวยความสะดวกเพื่อให้สามารถขยายไวยากรณ์ได้เช่นมาโคร มาโครไม่ใช่สิ่งที่ดีโดยอัตโนมัติและมีประสิทธิภาพมากเกินไป บางภาษามีไวยากรณ์ที่ยืดหยุ่นได้ตั้งแต่เริ่มต้นซึ่งจะช่วยลดความต้องการแมโคร สองสถานการณ์ที่ควรพิจารณา:

    • ฉันสามารถแนะนำผู้ให้บริการรายใหม่เช่น|>โดยไม่ต้องออกจากภาษาได้หรือไม่ ฉันสามารถเลือกลำดับความสำคัญและการเชื่อมโยงสำหรับตัวดำเนินการนี้ได้หรือไม่
    • ฉันต้องทำพิธีอะไรมากสำหรับฟังก์ชั่นอินไลน์ / แลมบ์ดา / การปิด
    • ฉันสามารถใช้ไวยากรณ์ภาษาที่มีอยู่เพื่อใช้ไวยากรณ์ลูป foreach ได้หรือไม่ เช่น Ruby และ Scala สามารถทำสิ่งนี้ผ่านทางไวยากรณ์การเรียกเมธอดแบบยืดหยุ่นด้วย lambdas
  • พิจารณาสิ่งอำนวยความสะดวกเพื่อให้ความหมายขยาย ความต้องการทั่วไปคือ:

    • ผู้ประกอบการมากไปโดยที่ผู้ใช้กำหนดประเภทสามารถกำหนดความหมายของตัวเองให้กับผู้ประกอบการที่มีอยู่ สิ่งนี้ทำให้ภาษาสนุกยิ่งขึ้นในแอปพลิเคชั่นที่เน้นหนัก
    • การบรรทุกเกินพิกัดตามตัวอักษร ฉันสามารถทำให้ตัวอักษรสตริงเป็นประเภทสตริงของตัวเองได้หรือไม่ ฉันสามารถทำให้ตัวอักษรตัวเลขทั้งหมดในขอบเขตปัจจุบันเป็น bignums ได้หรือไม่
    • โปรโตคอล Metaobject หากภาษาไม่มีลักษณะฉันสามารถนำไปใช้ในระบบวัตถุปัจจุบันได้หรือไม่? ฉันสามารถใช้ลำดับการแก้ปัญหาวิธีอื่นได้หรือไม่ ฉันสามารถสลับวิธีจัดเก็บวัตถุหรือวิธีการจัดส่งได้อย่างไร
  • มีการทดสอบการถดถอย มีการทดสอบมากมาย ไม่เพียงเขียนโดยนักออกแบบภาษา แต่ยังโดยผู้ใช้ เมื่อเพิ่มคุณสมบัติการทดสอบเหล่านี้แบ่งน้ำหนักอย่างระมัดระวังประโยชน์ของคุณสมบัตินั้นเทียบกับประโยชน์ของความเข้ากันได้ย้อนหลัง
  • กำหนดเวอร์ชันภาษาของคุณ ไม่เพียง แต่ในเอกสารของคุณ แต่ยังอยู่ในซอร์สโค้ดเองด้วย เมื่อคุณทำเช่นนั้นส่วนเดียวของภาษาของคุณที่ไม่สามารถเปลี่ยนแปลงได้คือไวยากรณ์ pragma รุ่นนี้ ตัวอย่าง: แร็กเก็ตอนุญาตให้คุณระบุภาษา Perl ช่วยให้คุณสามารถuse v5.20เปิดใช้งานคุณสมบัติย้อนหลังที่เข้ากันไม่ได้ของ Perl v5.20 use feature 'state'นอกจากนี้คุณยังสามารถโหลดคุณลักษณะเดียวอย่างชัดเจนเช่น ที่คล้ายกัน: from __future__ import divisionงูใหญ่
  • ลองพิจารณาออกแบบภาษาของคุณด้วยวิธีที่ทำให้ได้คำที่สงวนไว้ไม่กี่คำ เพียงเพราะการclassแนะนำคลาสไม่ได้หมายความว่าฉันจะไม่สามารถตั้งชื่อตัวแปรclassเฉพาะที่ได้ ในทางปฏิบัติผลลัพธ์นี้ในคีย์เวิร์ดที่แนะนำการประกาศตัวแปรหรือเมธอดซึ่งตรงข้ามกับประเพณี C-like ของการใช้ชื่อชนิดเพื่อแนะนำการประกาศ อีกทางเลือกหนึ่งคือใช้ sigils สำหรับคุณ$variablesเช่นเดียวกับใน Perl และ PHP

บางส่วนของคำตอบนี้ได้รับอิทธิพลจากคำพูดของ Guy Steele“ Growing a Language” (1998) ( pdf ) ( youtube )


บางประเด็นของคุณพูดถึงโปรแกรมเมอร์ที่ใช้ภาษาที่สามารถขยายและบางคนพูดถึงนักออกแบบของภาษาที่สามารถขยายได้ ทั้งสองไม่เกี่ยวข้องกันใช่หรือไม่? และฉันคิดว่าคำถามกำลังพูดถึงชนิดหลัง
svick

@svick ความคิดคือภาษานั้นสามารถขยายได้โดยผู้ใช้ปลายทางที่สามารถขยายและทดลองได้มากโดยไม่ต้องเปลี่ยนภาษาเอง โปรโตคอล Metaobject, การบรรทุกเกินพิกัดของผู้ปฏิบัติงานและระบบมาโครเป็นวิธีที่จะเปิดประตูทิ้งไว้เพื่อการเปลี่ยนแปลงในภายหลัง สิ่งใดก็ตามที่ดำเนินการผ่านประตูเหล่านี้จะไม่ทำลายภาษาพื้นฐาน น่าเสียดายที่ประตูเหล่านี้อาจต้องได้รับการออกแบบใหม่ในภายหลัง นั่นคือที่ตั้งของคำตอบของ Simon เริ่มต้น: ก่อนที่คุณจะสัญญาว่าจะมีความเสถียรลองทดสอบเบต้าเพื่อดูว่าภาษาของคุณใช้ได้จริงหรือไม่
amon

1

ฉันคิดว่าขั้นตอนที่สำคัญคือการโปรโมตตัวจัดการแพ็กเกจซึ่งสามารถจัดการเวอร์ชันของภาษาเองได้

ตัวอย่างเช่นฉันใช้ SBT สำหรับ Scala หรือ Leiningen สำหรับ Clojure ทั้งของพวกเขาให้ฉันประกาศรุ่นของภาษาที่ฉันต้องการที่จะใช้งานต่อโครงการ ดังนั้นจึงเป็นเรื่องง่ายที่จะเริ่มโครงการสีเขียวในภาษาเวอร์ชันล่าสุดขณะที่อัพเกรดโครงการที่มีอยู่ในปัจจุบันอย่างสะดวกสบายยิ่งขึ้นถ้าเคย

แน่นอนขึ้นอยู่กับภาษาสิ่งนี้อาจทำให้คุณต้องรอให้ไลบรารี่ที่เกี่ยวข้องถูกโอนย้ายไปเป็นเวอร์ชันที่คุณต้องการ


กับข้อสรุปว่าภาษามากที่สุดที่เป็นไปได้ควรจะกำหนดไว้ในแพคเกจ / โมดูลที่นำเข้าได้มากที่สุด
jk

ใช่ แต่ไม่จำเป็นเสมอไป ตัวอย่างเช่นคอมไพเลอร์ของ Scala เกิดขึ้นที่จะเขียนใน Scala แต่เมื่อคุณตั้งรุ่น Scala ใน sbt มันถูกดึงมาเป็น Jar และใช้ในการรวบรวมแหล่งที่มาของคุณ แม้ว่ามันจะเป็นไบนารีแบบทึบแสงก็น่าจะทำได้เช่นกัน ตอนนี้มีเหตุผลในการกำหนดภาษาให้มากที่สุดเท่าที่จะเป็นไปได้ควรกำหนดไว้ในแพ็คเกจที่สามารถนำเข้าได้ แต่สิ่งเหล่านั้นจะครอบคลุมในคำตอบของอมร
Andrea
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.