ไวยากรณ์ของภาษาโปรแกรมขึ้นอยู่กับการนำไปใช้หรือไม่

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

การตีความ (byte-ตีความแล้ว?) ภาษาเช่น Python, Lua ฯลฯ มักจะมีรูปแบบที่ผ่อนปรนและง่ายและโดยทั่วไปจะพิมพ์น้อยกว่าหรือไม่ต้องการให้ผู้พัฒนาเขียนประเภทตัวแปรในซอร์สโค้ดอย่างชัดเจน

ภาษาที่คอมไพล์เช่น C, C ++, Pascal ฯลฯ มักจะมีไวยากรณ์ที่เข้มงวดโดยทั่วไปมีประเภทและส่วนใหญ่ต้องการรหัส / เวลาในการพัฒนามากขึ้น

ภาษาที่มีการใช้งานอย่างเป็นทางการคือJIT-Compiledเช่น Java / C # มักจะเป็นการประนีประนอมระหว่างสองคนข้างต้นกับคุณสมบัติที่ดีที่สุดของทั้งสองอย่าง

ภาษาโปรแกรมคอมไพล์ที่ทันสมัยกว่าบางภาษาเช่น D และ Vala (และการนำ GNU GJC ไปใช้ของ Java) อาจเป็นข้อยกเว้นของกฎนี้และคล้ายกับไวยากรณ์และคุณลักษณะของภาษาที่รวบรวม JIT เช่น Java และ C #

คำถามแรกของฉันคือสิ่งนี้เกี่ยวข้องกันจริงหรือ? หรือนี่เป็นเรื่องบังเอิญที่ภาษาที่ถูกตีความส่วนใหญ่มีไวยากรณ์ง่าย ๆ JIT-Compiled มีไวยากรณ์และคุณสมบัติในระดับปานกลางเป็นต้น

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

ไม่มีการเชื่อมต่อใด ๆ ระหว่างความหมายและไวยากรณ์ ภาษาที่คอมไพล์ Homoiconic เช่น Scheme มาพร้อมกับซินแทกซ์ที่เรียบง่าย เมตา - คอมไพล์ระดับต่ำเช่น Forth นั้นเรียบง่ายกว่านั้น ภาษาที่รวบรวมไว้อย่างเคร่งครัดบางภาษานั้นสร้างขึ้นจากไวยากรณ์ที่น่ารำคาญ (คิดว่า ML, Haskell) OTOH, Python syntax มีน้ำหนักมากมากในแง่ของกฎไวยากรณ์จำนวนหนึ่ง

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

แนวโน้มทั่วไปคือภาษาที่พัฒนามานานเกินไปและไม่ได้มีการป้องกันการออกแบบใด ๆ กับการเบี่ยงเบนทางไวยากรณ์ไม่ช้าก็เร็วจะพัฒนาเป็นสิ่งที่น่ารังเกียจทางไวยากรณ์

ส่วนใหญ่เป็นเรื่องบังเอิญ

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

ไวยากรณ์ภาษาจะมีผลกระทบ - ตัวอย่างเช่นปาสคาลได้รับการออกแบบอย่างระมัดระวังเพื่อที่จะสามารถใช้คอมไพเลอร์ผ่านเดียว - คือผ่านมากกว่าหนึ่งแหล่งที่มาและคุณมีรหัสเครื่อง excutable ในทางกลับกัน Ada ไม่สนใจเรื่องนี้และ Ada คอมไพเลอร์ก็ยากที่จะเขียน - ซึ่งส่วนใหญ่ต้องการมากกว่าหนึ่งรอบ (คอมไพเลอร์ Ada ที่ดีมากที่ฉันใช้เมื่อหลายปีก่อนคือคอมไพเลอร์ 8 รอบอย่างที่คุณอาจจินตนาการว่ามันช้ามาก)

หากคุณดูที่ภาษาเก่า ๆ เช่น Fortran (เรียบเรียง) และ BASIC (ตีความหรือเรียบเรียง) พวกเขามี / มีไวยากรณ์ที่เข้มงวดมากและกฎความหมาย [ในกรณีของ BASIC นั่นไม่ใช่ตั๋วเงินแบบเก่าคุณต้องย้อนกลับไปก่อนหน้านั้นกับต้นฉบับ]

ในอีกทางหนึ่งการดูสิ่งที่มีอายุมากกว่าอื่น ๆ เช่น APL (ความสนุกมากมาย) สิ่งนี้มีการพิมพ์แบบไดนามิกและแปลก ๆ มันถูกตีความโดยทั่วไปเช่นกัน แต่สามารถรวบรวมได้เช่นกัน

ไวยากรณ์แบบผ่อนปรนเป็นวิธีที่ยากหากหมายความว่าคุณมีสิ่งที่เป็นทางเลือกหรือสามารถอนุมานได้ก็หมายความว่าภาษานั้นมีความสมบูรณ์เพียงพอที่จะถูกเลือกสรร จากนั้นอีกครั้ง BASIC มีหลายปีที่ผ่านมาเมื่อคำสั่ง "LET" กลายเป็นทางเลือก!

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

นี่คือตัวอย่างจากส่วนบนของหัวของฉัน:

• APL: การพิมพ์แบบไดนามิก ตีความโดยทั่วไป มาจาก 1960's / 1970's
• พื้นฐาน: การพิมพ์ที่แข็งแกร่งหรือไดนามิก ตีความหรือเรียบเรียง 1970 และอีกมากมาย
• Fortran: การพิมพ์ที่แข็งแกร่ง รวบรวม ปี 1960 หรือก่อนหน้า
• Algol68: การพิมพ์ที่แข็งแกร่ง รวบรวม ปี 1960
• PL / 1: การพิมพ์ที่แข็งแกร่ง รวบรวม ปี 1960
• ปาสกาล: การพิมพ์ที่แข็งแกร่ง รวบรวม ปี 1970 (แต่ในปี 1980 มีคอมไพเลอร์ P-System คล้ายกับคอมไพเลอร์ JIT!)
• การใช้งานของ Fortran และอื่น ๆ โดย DEC ในวันแรกได้รวบรวมและตีความบางส่วน
• Smalltalk: การพิมพ์แบบไดนามิก แปลเป็น bytecode ซึ่งแปลความหมาย ปี 1980
• อารัมภบท: ความแปลกประหลาดมากขึ้น การทำงาน. เรียบเรียง (Turbo Prolog ทุกคน?) ปี 1980
• C: การพิมพ์ที่แข็งแกร่ง (ฮ่าฮ่า) รวบรวม 1960's..today
• Ada: การพิมพ์ที่แข็งแกร่ง uber รวบรวม ปี 1980
• Perl: การพิมพ์แบบไดนามิก (ไวยากรณ์ที่แข็งแกร่ง) ตีความ ปี 1990 (?)

ฉันสามารถไปต่อ

• มุม Nitpickers: ภาษาที่แปลหลายภาษาถูกโทเค็นหรือ "คอมไพล์ไบต์" ในเวลาที่พวกเขาโหลด / อ่าน สิ่งนี้ทำให้การดำเนินการในภายหลังของล่ามง่ายขึ้นมาก บางครั้งคุณสามารถบันทึกโค้ดที่คอมไพล์ด้วยไบต์ได้ บางครั้งคุณทำไม่ได้ มันยังคงตีความ

Update: เพราะฉันยังไม่ชัดเจนพอ

การพิมพ์อาจแตกต่างกันอย่างกว้างขวาง

การพิมพ์แบบคงที่เวลาคอมไพล์คงเป็นเรื่องปกติ (เช่น C, Ada, C ++, Fortan, ฯลฯ ) นี่คือที่ที่คุณประกาศสิ่งประเภทและเป็นวิธีที่ตลอดไป

นอกจากนี้ยังเป็นไปได้ที่จะมีการพิมพ์แบบไดนามิกซึ่งสิ่งที่รับประเภทที่ได้รับมอบหมาย ตัวอย่างเช่น PHP และพื้นฐานบางต้นและ APL ที่คุณจะกำหนดจำนวนเต็มให้กับตัวแปรและจากนั้นเป็นประเภทจำนวนเต็ม หากภายหลังคุณกำหนดสตริงให้กับมันแสดงว่าเป็นประเภทสตริง และอื่น ๆ

แล้วมีการพิมพ์หลวม ๆ เช่น PHP ที่คุณสามารถทำสิ่งที่แปลกประหลาดอย่างแท้จริงเช่นกำหนดจำนวนเต็ม (อ้างถึงดังนั้นสตริงของมัน) ให้กับตัวแปรแล้วเพิ่มตัวเลขลงไป (เช่น '5' + 5 จะส่งผลให้ 10) นี่คือดินแดนแห่งที่แปลกประหลาด แต่บางครั้งก็มีประโยชน์มาก

อย่างไรก็ตามคุณสมบัติเหล่านี้ได้รับการออกแบบเป็นภาษา การนำไปปฏิบัตินั้นทำให้เกิดขึ้น

ฉันคิดว่ามันเป็นวิธีอื่น: การใช้งานขึ้นอยู่กับไวยากรณ์ ตัวอย่างเช่นหากไวยากรณ์ของคุณอนุญาตให้มีการสะท้อนการดำเนินการจะต้องระบุรันไทม์ที่สนับสนุน

โดยทั่วไปฉันเห็นด้วยอย่างรวดเร็วว่าการสังเกตของคุณส่วนใหญ่เป็นผลมาจากประวัติศาสตร์ ที่กล่าวถึงเหตุผลพื้นฐานเดือดลงไปที่บางสิ่งเช่นนี้:

The more modern a language is, the more comfortable it should be to use.

(ไม่พูดจริงๆเพียงแค่สูตรของตัวเอง.) เมื่อผมเขียนนี่ผมหมายถึงสิ่งที่คุณเรียกว่าcomfortable best features of bothแม่นยำยิ่งขึ้นฉันไม่ต้องการพูดหรือต่อต้านการพิมพ์สแตติก / ไดนามิกหรือไวยากรณ์เข้มงวด / ผ่อนปรน แต่เป็นสิ่งสำคัญที่จะต้องเห็นจุดเน้นของนักพัฒนาและเพิ่มระดับความสะดวกสบายเมื่อทำงานกับภาษา

ต่อไปนี้เป็นเหตุผลบางประการที่ยังไม่ได้กล่าวถึงในคำตอบก่อนหน้าซึ่งอาจให้แนวคิดบางประการแก่คุณว่าทำไมคุณจึงสังเกตสิ่งเหล่านี้ (และเรียงตามประวัติของการพัฒนาโปรแกรม lanugage):

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

• โค้งการเรียนรู้จับมือกับสิ่งนั้น ในอดีตเรามีภาษาไม่มากนักและใช้เวลาในการเรียนรู้ภาษาที่คุ้มค่า แม้ว่านั่นหมายถึงการลงทุนมากเวลา ความสะดวกสบายจะเพิ่มขึ้นอีกครั้งหากคุณใช้ภาษาที่นักพัฒนาสามารถเรียนรู้ได้อย่างรวดเร็ว ความซับซ้อนของทุกชนิด (f.ex. , ไวยากรณ์ที่เกี่ยวข้องซับซ้อน) เป็นอันตรายต่อสิ่งนี้และด้วยเหตุนี้จะลดลงมากขึ้นในภาษาใหม่

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

ดังนั้นโดยทั่วไปภาษาการเขียนโปรแกรมและคอมไพเลอร์ได้เห็นการพัฒนาคล้ายกับแอพพลิเคชั่นผู้ใช้ทั่วไป:

1. ขั้นตอนแรก: มันเป็นสิ่งที่ยอดเยี่ยมที่จะมี แต่เทคโนโลยีล้ำสมัยที่ทำให้เลือดไหลออกมานั้นแทบจะทำให้ค่าใช้จ่ายด้านความสะดวกสบาย / ความสามารถในการใช้งาน / สิ่งที่ไม่ดี
2. การปรับปรุงเทคโนโลยี: เราสามารถสร้างสิ่งเหล่านี้ได้อย่างแข็งแกร่งเร็วขึ้นและง่ายขึ้น
3. โฟกัสหันไปหาผู้ใช้: เช่นเดียวกับการเคลื่อนไหว Web2.0 ที่เน้นประสบการณ์ของผู้ใช้ภาษาการเขียนโปรแกรมใหม่จะมุ่งเน้นไปที่มุมมองของนักพัฒนา

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

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

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

ในอดีตภาษาการเขียนโปรแกรมและการใช้งานอาจมีการพัฒนาเพื่อให้เหมาะสมกับข้อ จำกัด ของฮาร์ดแวร์เช่นล่ามอาจพอดีใน 4k หรือ 16k หรือว่าคอมไพเลอร์อาจเสร็จสิ้นในเวลาน้อยกว่าหนึ่งนาทีของ CPU เมื่อเครื่องทำงานได้เร็วขึ้นก็เป็นไปได้ที่จะรวบรวมโปรแกรมที่เคยตีความใหม่บางโปรแกรมให้เร็วที่สุดเท่าที่โปรแกรมเมอร์สามารถกดปุ่มส่งคืนหรือตีความซอร์สโค้ดโปรแกรมที่คอมไพล์ไว้ก่อนหน้านี้เร็วกว่าฮาร์ดแวร์ที่เก่ากว่าเล็กน้อย