เหตุใดภาษาการเขียนโปรแกรมหลายภาษาจึงถูกนำมาใช้ในการพัฒนาผลิตภัณฑ์หรือซอฟต์แวร์หนึ่งชิ้น

ฉันเป็นนักเรียนที่จบการศึกษาเมื่อเร็ว ๆ นี้มีวัตถุประสงค์เพื่อเริ่มต้นปริญญาโทของฉันในสาขาวิทยาศาสตร์คอมพิวเตอร์ ฉันเจอโครงการโอเพ่นซอร์สหลายโครงการที่น่าสนใจและสนับสนุนให้ฉันสนับสนุนพวกเขา (CloudStack, OpenStack, moby และ Kubernetes เพื่อบอกชื่อไม่กี่) สิ่งหนึ่งที่ฉันพบว่าส่วนใหญ่มีเหมือนกันคือการใช้ภาษาโปรแกรมหลายภาษา (เช่น Java + Python + Go หรือ Python + C ++ + Ruby) ฉันได้ดูคำถามอื่น ๆ นี้แล้วซึ่งเกี่ยวข้องกับวิธีการใช้ภาษาโปรแกรมหลายภาษาในการสื่อสารซึ่งกันและกัน: จะมีสองโปรแกรมที่แตกต่างกันด้วยสองภาษาที่ต่างกันได้อย่างไร?

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

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

โปรเจคจบลงด้วยการใช้หลายภาษาด้วยเหตุผลหลักหกประการ:

1. ประโยชน์ด้านราคาของการใช้รหัสซ้ำในภาษาอื่น
2. ความต้องการที่จะรวมและรองรับรหัสดั้งเดิม;
3. ความพร้อมใช้งานของ coders สำหรับภาษาเฉพาะ
4. ความต้องการภาษาพิเศษสำหรับความต้องการพิเศษ
5. อคติภาษาดั้งเดิม และ
6. การจัดการโครงการไม่ดี (ใช้หลายภาษาโดยไม่ได้วางแผน)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฉันดูเหมือนจะไม่เข้าใจเหตุผลว่าทำไมภาษาหลาย ๆ ภาษาที่ใช้ในผลิตภัณฑ์หรือซอฟต์แวร์เดียวกัน

มันค่อนข้างง่าย: ไม่มีภาษาการเขียนโปรแกรมเดียวที่เหมาะสำหรับทุกความต้องการและเป้าหมาย

อ่านหนังสือการเขียนโปรแกรมภาษาเชิงวัจนปฏิบัติของ Michael L. Scott

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

ภาษาการเขียนโปรแกรมอื่น ๆ ชอบประสิทธิภาพการทำงาน (ภาษาระดับต่ำจำนวนมากที่มีการใช้งานที่คอมไพล์แล้วเช่น C ++, Rust, Go, C, แอสเซมเบลอร์และภาษาเฉพาะเช่น OpenCL ... ); มักจะเปคของพวกเขาช่วยให้บางพฤติกรรมที่ไม่ได้กำหนด เมื่อประสิทธิภาพของรหัสมีความสำคัญควรใช้ภาษาเหล่านี้

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

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

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

ขอให้สังเกตว่าค่าใช้จ่ายในการพัฒนามีความสำคัญมากขึ้นเรื่อย ๆ ในทุกวันนี้ (ไม่ใช่ในปี 1970- ในเวลานั้นคอมพิวเตอร์ที่มีราคาแพงมากหรือในแอพพลิเคชั่นแบบฝังตัวบางตัวที่มีผลิตภัณฑ์จำนวนมาก) กฎง่ายๆ (โดยประมาณมาก) คือนักพัฒนาที่มีทักษะสามารถเขียนเกี่ยวกับ 25,000 บรรทัดของรหัสที่มา (debugged & เอกสาร) ในแต่ละปีและไม่ขึ้นอยู่กับภาษาการเขียนโปรแกรมที่ใช้มากนัก

วิธีการทั่วไปคือการฝังภาษาสคริปต์บางภาษา (หรือบางภาษาเฉพาะโดเมน ) ในแอปพลิเคชันขนาดใหญ่ แนวคิดการออกแบบนี้ (เกี่ยวข้องกับภาษาเฉพาะโดเมน) มีการใช้มานานหลายทศวรรษ (ตัวอย่างที่ดีคือEmacs source code editorโดยใช้ Elisp สำหรับการเขียนสคริปต์ตั้งแต่ทศวรรษ 1980) จากนั้นคุณจะใช้ล่ามแบบฝังได้อย่างง่ายดาย (เช่นGuile , Lua , Python, ... ) ภายในแอปพลิเคชันขนาดใหญ่ การตัดสินใจที่จะฝังล่ามในแอพพลิเคชั่นขนาดใหญ่นั้นจะต้องทำเร็วมากและมีผลกระทบทางสถาปัตยกรรมที่แข็งแกร่ง จากนั้นคุณจะใช้สองภาษา: สำหรับเนื้อหาระดับต่ำที่ต้องทำงานอย่างรวดเร็วภาษาระดับต่ำเช่น C หรือ C ++; สำหรับสคริปต์ระดับสูง, DSL หรือภาษาสคริปต์อื่น ๆ

โปรดสังเกตว่าซอฟต์แวร์ที่ให้สามารถทำงานได้ภายในระบบปฏิบัติการส่วนใหญ่ในปัจจุบัน(รวมถึง Linux, Windows, Android, MacOSX, Hurd, ... ) ในกระบวนการร่วมมือหลายแห่งโดยใช้เทคนิคการสื่อสารระหว่างกระบวนการบางประเภท สามารถใช้กับคอมพิวเตอร์หลายเครื่อง (หรือหลายเครื่อง) โดยใช้เทคนิคการคำนวณแบบกระจาย (เช่นcloud computing , HPC, ไคลเอนต์เซิร์ฟเวอร์, เว็บแอปพลิเคชั่น , ฯลฯ ... ) ในทั้งสองกรณีมันง่ายที่จะใช้ภาษาการเขียนโปรแกรมหลายภาษา (เช่นรหัสแต่ละโปรแกรมที่รันบนกระบวนการเดียวหรือคอมพิวเตอร์ในภาษาโปรแกรมของตัวเอง) อ่านระบบปฏิบัติการ: สามชิ้นง่ายสำหรับเพิ่มเติม นอกจากนี้อินเตอร์เฟซฟังก์ชั่นต่างประเทศ(เช่นJNI ), ABI s, การเรียกประชุมฯลฯ ... อำนวยความสะดวกในการผสมหลายภาษาในโปรแกรมเดียวกัน (หรือปฏิบัติการ ) - และคุณจะพบรหัสกำเนิดเช่นSWIGเพื่อช่วย

ในบางกรณีคุณจะต้องผสมเขียนโปรแกรมภาษาต่างๆ: การใช้งานเว็บต้อง Javascript หรือ Webassembly (ภาษาเท่านั้นทำงานภายในเว็บเบราเซอร์ส่วนใหญ่) เพื่อเป็นส่วนหนึ่งที่ทำงานอยู่ในเบราว์เซอร์ (มีกรอบการสร้างเหล่านี้เช่นocsigen ) รหัสเคอร์เนลต้องการสิ่งบางอย่าง (เช่นการจัดตารางเวลาหรือการจัดการในระดับต่ำของการขัดจังหวะ) ที่จะเขียนบางส่วนในการประกอบเพราะ C หรือ C ++ ไม่สามารถแสดงสิ่งที่เป็นสิ่งจำเป็นที่มีคำสั่ง RDBMS ควรใช้ SQL, GPGPU s ความต้องการเมล็ดคอมพิวเตอร์เขียนในOpenCLหรือCUDAจัดการด้วยรหัสโฮสต์ C หรือ C ++ ฯลฯ บางภาษาได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการผสม (เช่นasmคำสั่งใน C,โค้ดชิ้นในGCC MELTปลายของฉันฯลฯ ... )

ในบางกรณีคุณใช้เทคนิคmetaprogramming : บางส่วนของโครงการซอฟต์แวร์ขนาดใหญ่ของคุณจะมีรหัส (เช่นใน C หรือ C ++) ที่สร้างขึ้นโดยเครื่องมืออื่น ๆ (อาจเป็นเครื่องมือเฉพาะโครงการ) จากการทำให้เป็นระเบียบแบบ ad-hoc: parser generators คอมไพเลอร์) เช่นกระทิงหรือANTLRเข้ามาในใจ แต่ยังเป็น SWIG หรือ RPCGEN และสังเกตว่าGCCมีเครื่องสร้างรหัส C ++ มากกว่าหนึ่งโหล (หนึ่งสำหรับ DSL ภายในภายใน GCC) ทั้งหมดภายในเครื่อง ดูตัวอย่างนี้ด้วย ขอให้สังเกตว่าmetabugsหายาก อ่านเพิ่มเติมเกี่ยวกับคอมไพเลอร์ bootstrappingและเกี่ยวกับhomoiconicityและreflection(มันคุ้มค่าที่จะเรียนรู้Lispเล่นกับSBCLและอ่านSICPดูที่ไลบรารีที่รวบรวม JITเช่นGCCJITในโปรแกรมขนาดใหญ่บางโปรแกรมคุณอาจสร้างรหัสที่รันไทม์โดยใช้กฎเหล่านี้โปรดระวังกฎที่สิบของ Greenspun ) ดูการพูดคุยของCircuit Less Traveledที่ FOSDEM2018

บางครั้งคุณต้องการให้คำอธิบายประกอบอย่างเป็นทางการของรหัสของคุณ (เช่นเพื่อช่วยให้ผู้วิเคราะห์นักวิเคราะห์คงที่คอมไพเลอร์) โดยใช้ภาษาคำอธิบายประกอบพิเศษบางอย่าง (ซึ่งอาจถูกมองว่าเป็น DSL บางส่วน) มองหาACSLด้วยFrama-Cเพื่อใส่คำอธิบายประกอบโปรแกรม C (โปรแกรมที่สำคัญต่อความปลอดภัย) หรือOpenMP pragmas สำหรับ HPC Caveat: การเขียนคำอธิบายประกอบดังกล่าวอาจต้องใช้ทักษะและเวลาในการพัฒนาจำนวนมาก

BTW นี่แสดงให้เห็นว่าทักษะบางอย่างเกี่ยวกับคอมไพเลอร์และล่ามมีประโยชน์สำหรับนักพัฒนาซอฟต์แวร์ทุกคน (แม้จะไม่ได้ทำงานกับคอมไพเลอร์) ดังนั้นอ่านDragon Bookแม้ว่าคุณจะไม่ได้ทำงานกับคอมไพเลอร์ หากคุณใช้รหัสล่ามของคุณเอง (หรือถ้าคุณออกแบบ DSL) ให้อ่านเสียงกระเพื่อมเป็นชิ้นเล็กชิ้นน้อย

ดูเพิ่มเติมนี้และว่าและว่าและว่าคำตอบของฉันที่เกี่ยวข้องกับคำถามของคุณ

ศึกษาซอร์สโค้ดของโครงการซอฟต์แวร์ฟรีขนาดใหญ่หลายโครงการ (บนGitHubหรือจากการแจกจ่าย Linuxของคุณ) เพื่อเป็นแรงบันดาลใจและการตรัสรู้

นอกจากนี้ภาษาการเขียนโปรแกรมบางภาษามีการพัฒนาโดยการเพิ่มคำอธิบายประกอบ (เป็น pragmas หรือความคิดเห็น ) ให้กับภาษาที่มีอยู่ สำหรับตัวอย่างคิดACSL (ความคิดเห็นนามสกุลอธิบายโปรแกรม C เพื่อเปิดใช้งานการพิสูจน์ของพวกเขาโดยม่า-C ) หรือของOpenCL (ภาษา C ในการเขียนโปรแกรม GPGPUs) หรือOpenMPหรือOpenACC #pragmasหรือสามัญประเภทคำอธิบายประกอบเสียงกระเพื่อม

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

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

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

โปรเจ็กต์สองสามใช้หลายภาษาภายในแอปพลิเคชันเช่นแกนกลางในภาษาระดับต่ำกว่าที่สามารถรวมปลั๊กอินในภาษาสคริปต์ ในระบบนิเวศบางระบบ (เช่น JVM หรือ. NET) ภาษาที่แน่นอนที่ใช้ไม่สำคัญเกินไปเนื่องจากหลายภาษาในรันไทม์ภาษาเดียวกันมีความสามารถในการทำงานร่วมกันได้ดี ตัวอย่างเช่นฉันสามารถเขียนโครงการใน Scala ที่ใช้ไลบรารี Java ที่มีอยู่และรวมฟังก์ชั่นการเขียนสคริปต์เข้ากับ Groovy

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

นี่มีสองรูปแบบและองค์กรจำนวนมากที่ตกอยู่ระหว่างสอง:

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

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

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

ฉันสามารถมีส่วนร่วมเป็นตัวอย่างของโครงการการเขียนโปรแกรมที่ได้รับการทำงานเป็นเวลา 32 ปีและดูเหมือนว่ายังมีชีวิตเหลืออยู่ในนั้น มันเป็นการค้ามากกว่าโอเพ่นซอร์ส

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

มีส่วนเสริมเขียนใน C ++ ซึ่งเริ่มเมื่อหัวหน้าโครงการที่ผ่านมาเชื่อว่า C ++ / MFC / Windows / x86 กำลังจะแทนที่สถาปัตยกรรมและแพลตฟอร์มอื่น ๆ ทั้งหมดดังนั้นจึงจำเป็นต้องเสนอ C ++ ให้กับ สามารถจ้างพนักงานได้ สิ่งต่าง ๆ ไม่เป็นไปตามที่เขาคาดไว้

นอกจากภาษาโดเมนและ C ++ แล้วผู้พัฒนาทำงานใน LISP ซึ่งใช้ในการเขียนกรณีทดสอบโดยใช้ล่ามที่ฝังอยู่ในชุดทดสอบ เราพิจารณาแทนที่ LISP ด้วย Java ในจุดหนึ่ง แต่มันกลับกลายเป็นว่าโชคดีที่เราไม่ได้ทำ

นอกจากนี้ยังมี wrapper สำหรับ API หลักของมันเขียนด้วย C # สิ่งนี้ทำเมื่อลูกค้าร้องขอเพื่อให้พวกเขาสามารถเขียนแอปพลิเคชันของตนอีกครั้งใน C # มันถูกสร้างขึ้นโดยสคริปต์ Perl ซึ่งอ่านไฟล์ส่วนหัว C สำหรับ API รวมถึงไฟล์การกำหนดค่าที่สำคัญและเขียนรหัส C # สำหรับกระดาษห่อ การประมวลผลข้อความทั้งหมดใน Perl นั้นทำได้ง่ายกว่าการใช้ C ++

มันมีระบบการสร้างของตัวเองและต้องการพวกเขาเพราะภาษาโดเมนไม่สามารถคล้อยตามระบบการสร้างตาม หนึ่งสำหรับแพลตฟอร์มเหมือน UNIX ถูกเขียนในเชลล์สคริปต์ Perl และบางโปรแกรมขนาดเล็กในภาษาโดเมน แพลตฟอร์มหนึ่งสำหรับ Windows เขียนด้วยภาษาแบตช์ Perl และโปรแกรมขนาดเล็กเดียวกันในภาษาโดเมน ระบบการสร้าง VMS แบบเก่าเขียนขึ้นใน DCL แต่ไม่ได้ใช้มานานกว่าทศวรรษ

มีบางโปรแกรม YACC / Bison ในคอมไพเลอร์สำหรับภาษาโดเมน มีรหัสทดสอบบางอย่างสำหรับแพลตฟอร์ม Apple ที่เขียนด้วย Objective-C ++ เว็บไซต์ภายในของทีมบางส่วน (ใช้สำหรับการจัดการโครงการไม่ใช่ส่วนหนึ่งของสิ่งที่ส่งมอบ) เขียนใน ASP และอื่น ๆ เป็นสคริปต์ CGI ใน Perl

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

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

ในบางกรณีมีเครื่องมือที่คุณต้องใช้ (เช่นชุดเครื่องมือ UI ของระบบปฏิบัติการ) ซึ่งสามารถเข้าถึงได้ง่ายจากภาษาที่กำหนด ตัวอย่างเช่นบน iOS และ macOS หากคุณต้องการเขียนแอปพลิเคชัน GUI โดยใช้ UIKit และ AppKit การเขียนใน Swift หรือ Objective-C เป็นวิธีที่เร็วและง่ายที่สุดในการทำ (อาจมีการผูกสำหรับภาษาอื่น ๆ แต่อาจอยู่เบื้องหลังระบบปฏิบัติการรุ่นล่าสุดที่คุณกำลังสร้างดังนั้นอาจไม่มีคุณสมบัติทั้งหมด)

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

ดังนั้นหากคุณเขียนแอปพลิเคชัน Windows และ macOS คุณสามารถเขียนหลักตรรกะใน C ++ และใช้ C # สำหรับ UI บน Windows และ Swift สำหรับ UI บน macOS ประหยัดเวลาเพราะคุณไม่จำเป็นต้องเขียนตรรกะหลักสองครั้งและจัดการกับชุดข้อบกพร่องต่าง ๆ ในทั้งสองแอพ ฯลฯ แต่ก็ยังอนุญาต UI ดั้งเดิมที่แท้จริงซึ่งไม่ตอบสนองต่อตัวหารร่วมที่ต่ำที่สุดระหว่างแพลตฟอร์มเช่นการใช้งาน ห้องสมุด UI ข้ามแพลตฟอร์มจะ

นอกเหนือจากความจริงที่ว่าภาษาการเขียนโปรแกรมบางภาษาสามารถเหมาะสมกว่าสำหรับงานเฉพาะบางอย่างมีความเป็นจริงในทางปฏิบัติ

ในความเป็นจริงในทางปฏิบัติมี 2 ประเด็นที่สำคัญอย่างยิ่งที่ต้องพิจารณา:

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

และแน่นอนว่ามักมีส่วนเฉพาะของแอปพลิเคชันที่มีความต้องการที่แตกต่างกันโดยสิ้นเชิงเช่น:

• พื้นที่อ่อนไหวด้านประสิทธิภาพได้รับการพัฒนาในภาษาที่รวบรวม ภาษาตัวอย่าง: C ++
• พื้นที่ที่จะต้องมีราคาถูกง่ายต่อการเปลี่ยนแปลงและปรับแต่งได้พัฒนาในภาษาสคริปต์ ภาษาตัวอย่าง: Lua
• โครงร่าง GUI ภาษาตัวอย่าง: HTML
• การติดตั้ง ตัวอย่างภาษา / เครื่องมือ: WiX
• สร้าง. ตัวอย่างภาษา / เครื่องมือ: มีจำนวนรายการมากเกินไปโดยปกติจะมีหลายรายการพร้อมกัน

และยิ่งไปกว่านั้นมีเครื่องมือไม่กี่ตัวที่ใช้งานโดย codebase ที่มีความซับซ้อนซึ่งส่วนมากให้การปรับแต่งและปลั๊กอินที่จำเป็นด้วยภาษาอื่น

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

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

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

คำถามนี้ (และบางคำตอบ) ดูเหมือนจะถือว่าแอปพลิเคชั่นเป็นบล็อคโค้ดขนาดใหญ่ซึ่งไม่จำเป็นต้องเป็นกรณีนี้

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

ฉันทำงานบนแพลตฟอร์มธนาคารออนไลน์ที่มีเป้าหมายเล็ก ๆ เพื่อมุ่งไปยังธนาคารชุมชนขนาดเล็กและสหภาพเครดิต แพลตฟอร์มนี้มีองค์ประกอบหลายอย่าง - ส่วนหน้าของเว็บ, เลเยอร์ฐานข้อมูล, เลเยอร์การสื่อสารของบุคคลที่สามเป็นต้นทั้งหมดนี้เป็นแอพพลิเคชั่นอิสระที่ทำงานบนเซิร์ฟเวอร์ที่แตกต่างกันและมีระบบปฏิบัติการที่แตกต่างกัน คุณมีจาวาสคริปต์ที่ทำงานบนฝั่งไคลเอ็นต์ในเบราว์เซอร์คุณมีหน้าสร้าง Perl บนฝั่งเซิร์ฟเวอร์คุณมีบริการหลายอย่างที่เขียนใน C ++ ทำหน้าที่เป็นเลเยอร์นามธรรมระหว่างรหัส Perl และตัวประมวลผลหลักของธนาคารอีกชุดหนึ่งของแอปพลิเคชัน C ++ ที่ ข้อความเส้นทางระหว่างเลเยอร์ต่างๆการใช้งานของ C ++ และสคริปต์ Perl เพื่อตรวจสอบสถานะของกระบวนการต่าง ๆ และรายงานสถานะของมันไปยังจอมอนิเตอร์ภายใน ฯลฯ ฯลฯ เป็นต้น

แอปพลิเคชันเสาหินยังคงมีอยู่ แต่แม้ว่าพวกเขาจะสามารถใช้ประโยชน์จากภาษาที่แตกต่างกันด้วยเหตุผลที่แตกต่างกัน คุณสามารถเขียน 90% ของแอปพลิเคชันใน Java แต่ใช้ JNI เพื่อใช้ประโยชน์จาก C หรือ C ++ สำหรับส่วนที่มีความสำคัญต่อประสิทธิภาพ

ฉันต้องการจะชี้ให้เห็นอินสแตนซ์ที่เฉพาะเจาะจงของ 'ภาษาที่แตกต่างกันและมีจุดแข็งที่แตกต่างกัน': FORTRAN

เดิมที Fortran ได้รับการพัฒนาเพื่อให้วิศวกรทำการวิเคราะห์เชิงตัวเลขได้ง่ายขึ้นและมีความพยายามอย่างมากในการทำให้คอมไพเลอร์ของ Fortran ปล่อยรหัสตัวเลขที่มีประสิทธิภาพมาก ในทางกลับกันตั้งแต่วันแรก ๆ การใช้คอมพิวเตอร์ระเบิดไปในทิศทางนับพันไม่มีสิ่งใดที่เกี่ยวข้องกับการวิเคราะห์เชิงตัวเลขและการพัฒนาภาษาการเขียนโปรแกรมได้ดำเนินไปตามความเหมาะสมในการเพิกเฉยต่อโลกแห่งความเป็นจริง

SO: มันคือวันนี้และคุณพบว่าตัวเองทำงานให้กับ บริษัท ที่มีสินค้าที่มีความเป็นธรรมแผ่กิ่งก้านสาขามากที่สุดของมันเขียนใน (พูด) Java (ผมพูดจากประสบการณ์ส่วนตัวที่นี่) แต่คุณพบว่าหนึ่งในคุณสมบัติหลักของผลิตภัณฑ์จะได้รับการวิเคราะห์เชิงตัวเลขอีกรูปแบบและรหัสที่ดีที่สุดสำหรับการวิเคราะห์นั้นมีอยู่แล้วบนเน็ต - ใน Fortran แล้วคุณจะทำอย่างไร? คุณดาวน์โหลดหนึ่งในรหัส Fortran, หาอินเทอร์เฟซ [เช่นอากิวเมนต์ของรูทีนย่อยที่สูงที่สุด], ทำการหุ้ม JNI wrapper ใน C และห่อเป็นคลาส Java BAM! คุณต้องพัฒนาเป็นสามภาษาพร้อมกัน [โดยเฉพาะหากคุณพบว่ารหัส Fortran ของคุณใช้บล็อกทั่วไป - เช่นที่จัดเก็บข้อมูลแบบสแตติก - และจะต้องแก้ไขเพื่อความปลอดภัยของเธรด]

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

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

ผลิตภัณฑ์จะต้องมี

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

ภาษาที่อาจจะดีสำหรับการเขียนเวลาทำงานของผลิตภัณฑ์นั้นไม่น่าเป็นไปได้ที่จะดีสำหรับการรวมผลิตภัณฑ์เข้าด้วยกัน และอื่น ๆ

อย่างไรก็ตามขั้นตอนการเขียนผลิตภัณฑ์อาจไม่สามารถทำได้อย่างเหมาะสมใน 1 ภาษา

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

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

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

การพัฒนาซอฟต์แวร์มีความก้าวหน้าจนถึงจุดที่คุณสามารถใช้ภาษาการเขียนโปรแกรมที่แตกต่างกันในโครงการเดียวกันและคุณสามารถทำให้มันใช้งานได้

ถ้าอย่างนั้นมีคำถามว่าทำไมคุณจะใช้มากกว่าหนึ่งภาษา

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

อีกเหตุผลหนึ่งคือสถานการณ์ที่ภาษา X เป็นสิ่งที่ใช้บนแพลตฟอร์ม A เป็นอย่างมากภาษา Y นั้นใช้ในแพลตฟอร์ม B มาก แต่ภาษา Z นั้นรองรับทั้งสองแพลตฟอร์ม ดังนั้นรหัสทั่วไปจะถูกเขียนในภาษา Z ซึ่งรวมกับ X หรือ Y แล้วขึ้นอยู่กับแพลตฟอร์ม

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