เหตุใดแอปพลิเคชัน Linux มักวางภาษาที่เขียนด้วยสรุป

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

ฉันสามารถเข้าใจการรู้ถึงความแตกต่างระหว่าง GTK + กับ QT สร้างความแตกต่างเพียงเพราะข้อกำหนดการรวมเดสก์ท็อป แต่ C vs C ++ เทียบกับ Python vs Assembly vs ฯลฯ ? จริงๆ?

ตัวอย่างเช่น: foo เป็น blah blah ง่าย ๆ ที่เขียนด้วย C / GTK +

ฉันคิดว่าผู้ใช้ Linux แบบดั้งเดิม (คนจรจัด geeky ที่ติดตั้งระบบด้วยตัวเอง) ดูแลข้อมูลดังกล่าว (เทคโนโลยีใดที่อยู่เบื้องหลังเครื่องมือนี้) ฉันยังเป็นหนึ่งในคนที่น่ารักที่จะงดการติดตั้งและใช้งานแพ็คเกจเพราะมันใช้เทคโนโลยีบางอย่างที่ฉันไม่ชอบ บางคนเรียกว่าพฤติกรรมทางศาสนาแบบนี้แน่นอน โง่งั้นเหรอ?

อย่างไรก็ตามฉันสามารถนึกได้สองเหตุผล:

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

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

นี่เป็นเพียงการเดาแน่นอน

ความรู้สึกของฉันมันเกี่ยวข้องกับเสรีภาพซอฟต์แวร์ที่สองในสี่ :

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

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

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

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

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

ในส่วนขยายไปยังคำตอบ jasonwryans' :

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

ของหลักสูตรนี้เหมาะสมถ้าคุณเป็นโปรแกรมเมอร์

คุณเห็นข้อสรุปที่ไหน ในพื้นที่เก็บข้อมูลหรือแพคเกจเช่น. deb หรือ. rpm

หากคุณสร้างจากแหล่งข้อมูลอาจเป็นประโยชน์ในการระบุว่าคุณจะต้องติดตั้งสิ่งอื่น ๆ (compliler, library, build-tools)

Unix และตอนนี้ LInux และ BSD มีฐานซอฟต์แวร์ที่แตกหักอยู่เสมอและมีฐานฮาร์ดแวร์ที่หลากหลายกว่าในอดีตที่ผ่านมา สิ่งสำคัญคือต้องรู้ว่าซอฟต์แวร์บางตัวทำงานในเครื่องบุกรุกที่คุณมีในระบบของคุณหรือคุณสามารถรวบรวมซอร์สโค้ดได้ หากคุณไม่มีล่าม Lisp สามัญหรือล่าม Tcl หรือล่ามอะไรก็ตามคุณไม่ต้องการรบกวนแหล่งดาวน์โหลดเพียงเพื่อดูว่าคุณไม่สามารถเรียกใช้งานได้

การมีคำอธิบายว่าภาษาใดที่ป้องกันไม่ให้เสียเวลามากมาย

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

จากมุมมองของฉันข้อมูลดังกล่าวมีความสำคัญต่อการดึงดูดผู้มีส่วนร่วมใหม่รวมถึงให้ผู้ใช้ที่คาดหวังทราบถึงความสามารถในการทำงานของมันในทันทีว่ามันอาจนำมาซึ่งการผนวกรวมแอปพลิเคชันเข้ากับระบบของพวกเขา

• แง่มุมทั่วไปคือไลบรารีที่ใช้เมื่อเรียกใช้แอปพลิเคชัน

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

• อีกแง่มุมหนึ่งคือไลบรารีที่ใช้และสิ่งที่จำเป็นต้องมีเพื่อรวบรวมแอปพลิเคชัน

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

• อีกแง่มุมหนึ่งคือความตั้งใจที่จะดึงดูดผู้มีส่วนร่วม

นักพัฒนาส่วนใหญ่มีความต้องการสำหรับภาษาจำนวนน้อยหรืออาจขาดประสบการณ์ในภาษาอื่น เพื่อให้ผู้คนจำนวนมากมีส่วนร่วมในแอปพลิเคชันบางโครงการได้แยกแหล่งข้อมูลของพวกเขาออกเป็นสองภาษาที่แตกต่างกัน (เช่น Wesnoth, Vega Strike, Naev เพียงเพื่อตั้งชื่อไม่กี่คน) หนึ่งในนั้นสำหรับแอปพลิเคชันหลัก (เช่น C หรือ C ++) อีกอันหนึ่งสำหรับการปรับเปลี่ยนได้ง่าย (เช่น Python หรือ Lua) นี่คือลิงค์ไปยังบทของ "สถาปัตยกรรมของแอปพลิเคชันโอเพนซอร์ซ" ที่อธิบายถึงวิธีการและสิ่งที่เกิดขึ้นใน Wesnoth

• ในที่สุดก็เห็นได้ชัดว่ามีอคติและอคติต่อภาษาต่างๆมากมาย

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

ฉันคิดว่ามันเกี่ยวข้องกับการโฆษณาการแสดงมากมาย แอปพลิเคชันที่เขียนด้วยภาษาที่รวบรวม (C, C ++, ... ) จะทำงานได้ดีกว่าหนึ่งที่เขียนในภาษาสคริปต์ (perl, python, ... )

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

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

เกี่ยวกับขนาด: การเพิ่มล่ามสำหรับภาษาเพิ่มเติมพร้อมกับโมดูลมาตรฐานและโมดูลเสริมที่ใช้โดยทั่วไปสามารถเพิ่มหลายร้อยเมกะไบต์ได้อย่างง่ายดายเพื่อความต้องการในการจัดเก็บ เช่นเดียวกันสำหรับตระกูลไลบรารีโดยเฉพาะที่เกี่ยวข้องกับสภาพแวดล้อมเดสก์ท็อปหลักเช่น Gnome และ KDE สิ่งที่แย่กว่านั้นคือการวิ่งnไปยังn+1โปรแกรม Perl อาจไม่เพิ่มความต้องการในการใช้งานหน่วยความจำมากนักเนื่องจากสามารถแชร์หน่วยความจำได้มากมาย แต่จะมาจากnโปรแกรม Perl และโปรแกรม Python 0 โปรแกรมnโปรแกรม Perl และ 1 Python โปรแกรมส่งผลให้มีการใช้งานหน่วยความจำอย่างมาก สิ่งนี้กลายเป็นปัญหามากขึ้นเมื่อคนโง่ที่เขียนซอฟต์แวร์ฟรีทุกคนมีภาษาสคริปต์ / radtool ที่ชื่นชอบของพวกเขาที่พวกเขาต้องการตั้งโปรแกรมใน ... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ....

เกี่ยวกับการพกพา: ภาษาที่ตีความแล้วจำนวนมาก (รวมถึงเฟรมเวิร์กไลบรารี) ใช้ประโยชน์อย่างมากจากคุณสมบัติที่อาจมีอยู่ในระบบเดสก์ท็อป / เซิร์ฟเวอร์ Linux ขนาดใหญ่ แต่ไม่จำเป็นต้องมีในระบบขนาดเล็ก / ฝัง / MMU การพึ่งพาการ.soโหลดโมดูลแบบไดนามิกที่รันไทม์คำนึงถึง ...