Bu cevabın mükemmel kapsama alanı vardır ve farklı dillerin neden bir projeye farklı faydalar sağlayabileceği ile ilgili bağlantılara sahiptir. Ancak, projelerin neden birden çok dil kullanmaya başladığı konusundaki dil uygunluğundan biraz daha fazlası var.
Projeler altı ana sebepten dolayı birden fazla dil kullanıyor:
- Diğer dillerde yazılmış kodları kullanmanın maliyet avantajları;
- Eski kodu dahil etme ve yerine getirme ihtiyacı;
- Belirli diller için kodlayıcıların bulunması;
- Uzmanlık ihtiyaçları için özel dillere olan ihtiyaç;
- Eski dil önyargıları; ve
- Kötü proje yönetimi (planlanmamış çoklu dil kullanımı).
1-4 Sebepleri, doğrudan onlara hitap etmenin, bir projenin daha hızlı, daha verimli, daha kaliteli bir ürünle ve daha kolay ve uzun vadeli destekle sonuçlanmasına yardımcı olabileceği yönündeki olumlu sebeplerdir. Nedenler 5 ve 6 negatif, ihtiyaç duyulan değişime direnç belirtileri, zayıf planlama, etkin olmayan yönetim veya tüm bu faktörlerin bir kombinasyonu. Bu olumsuz faktörler maalesef "tesadüfi" çoklu dil kullanımının ortak nedenleridir.
Yeniden kullanımın maliyet avantajı olan 1. Sebep , hem açık kaynaklı yazılımın daha büyük rolü hem de web üzerinde doğru kod bileşenlerini bulmak için gelişmiş yetenekler nedeniyle bir projede birden fazla dilin kullanılmasına izin vermek için giderek daha güçlü bir neden haline geldi. Geçmiş yılların "hepsini içsel olarak kodlayalım" felsefesi, ekonomik gerçekler karşısında solmaya devam ediyor ve aslında herhangi bir yeni proje için en uygun maliyetli yaklaşım değil. Bu da, bir proje içinde tek bir dilin kullanılmasının daha az yaygın bir şekilde uygulanmasına yönelik fırsatlar sağlar.
Özellikle iyi yönetilen açık kaynak bileşenlerini yeniden kullanan bir proje söz konusu olduğunda, çoklu dillerin kullanımı büyük toplam maliyet avantajları sağlayabilir çünkü yeniden kullanılan bileşenlerin her ikisi de iyi tasarlanmış arayüzlerin arkasına gizlenmiştir ve bağımsız olarak sıfır maliyetli harici gruplar tarafından korunurlar. En iyi senaryolarda, dillerin bu tür yeniden kullanım yoluyla karıştırılması, proje için işletim sistemi bileşenleri kullanmaktan daha pahalı değildir. Microsoft'un tarayıcılarında açık kaynaklı yazılımların geniş çapta benimsemesinden daha iyi bir örnek olmadığını biliyorum.
Eski kodu yerine getirme gereği nedeni 2 , herhangi bir büyük projenin tehlikesinde göz ardı edilir. Bununla birlikte, birçok sorun eski kodu, yeni bir dilde kolayca yeni bir kodla değiştirilebileceğini varsayarsak inanılmaz derecede riskli olabilir. Eski kod, hatta eski kötü kod, genellikle eski ürünü kullanan topluluk tarafından beklenen özelliklerin örtük bir “sözleşmesi” ne kadar tutar getirir. Bu topluluk oldukça sık bir şirket için büyük bir gelir kaynağı veya devlet yazılımı için temel destek kaynağıdır. Basitçe atmak, zımni sözleşmenin, sürmekte olan müşterileri kovalayabilir ve başka seçenekler mevcutsa, bir şirketi iflas edebilir.
Aynı zamanda, değil eski bir dilde eski kodu yerine o toptan değiştirilmesi kadar tehlikeli olabilir. En kötü örnek, bilgisayar doktorları tarafından değil, tıp doktorları tarafından tasarlanan MUMPS (şaka yapmaz) adlı bir dilde kodlanmış çok sayıda hayati sisteme sahip olan ABD Gaziler İdaresi'dir. Kimse MUMPS'u öğrenmek istemez ve bunu bilenler ise tam anlamıyla ölüyorlar. Bu nedenle programcılar, daha yaygın, daha güçlü ve daha iyi korunan diğer dilleri kullanmaya devam etmeye çalışsalar bile MUMPS'u barındırmalıdır.
Bu tür çok dilli kullanım dikkatli bir planlama gerektirir. Bu planlama, bir yandan onlarca yıllık müşteri bilgisini kaybetmekle diğer yandan yazılımı destekleme yeteneğini kaybetmek arasında bıçak kenarını yönlendirmelidir. Eski kodu iyi tanımlanmış arayüzlerin arkasına izole eden ve davranışlarını iyi belgelendikten sonra eski kodu değiştirmek için yeni daha güçlü bir kod sağlayan teknikler yardımcı olabilir. Ancak bu eski senaryo hiçbir zaman kolay değildir ve pek çok şirketin ve örgütün geniş bir yelpazedeki ölçeğinin ölümünün nedeni olmuştur (ve olmaya da devam edecektir).
Neden 3 , çeşitli diller için kodlayıcıların kullanılabilirlik, projelerin tehlike görmezden pragmatik bir faktördür. Bununla birlikte, proje düzenleyicileri, belirli bir dilin hedefleri için en iyisi olduğunu (eğer kendileri için mevcut olan dil uzmanlığı havuzu ile çelişiyorsa), ürünün hem programının hem de kalitesinin öğrenmeden zarar göreceğini düşünüyor olabilir. yeni bir dil öğrenmeye çalışan programcılar kavisli.
Daha rasyonel bir yaklaşım, projenin dil ihtiyaçlarını fonksiyonel alanlara dayalı olarak analiz etmektir. Örneğin, projeye dikkatlice bakmak, örneğin bazı daha az kullanılan bir dilde kodlama uzmanlığı gerektiren bazı özel algoritmaları uygulamak için yüksek değerli kodun yalnızca küçük bir "tepe noktası" olduğunu gösterebilir. Herhangi bir büyük projenin diğer bölümleri genellikle daha yaygın diller tarafından kolayca veya iyi yönetilen açık kaynak ürünleri tarafından (hatta daha iyisi) yerleştirilebilir. Bu nedenle bir projeyi dilin ihtiyaçlarına göre analiz etmek, özel dillerde özel uzmanlık kiralamak veya kiralamak için çok daha gerçekçi ve uygun maliyetli bir yaklaşım sağlayabilir ve aynı zamanda tek bir projedeki diller arasındaki arayüzleri keskinleştirmeye yardımcı olabilir.
Sebep 4 , farklı ihtiyaçlar için farklı diller kullanarak, proje ihtiyaçlarının bu tür bir analizini yapmaktan hemen ve sorunsuzca takip eder. Bu konuda da dikkatli olunmalıdır, çünkü tek bir proje için destek için çok fazla dil seçmek, hem destek hem de bileşenler arasındaki arayüzlerde karmaşık bir patlamaya neden olabilir. Maliyet açısından en güvenli rota her zaman ilk kullanım için azami fırsatları bulmaktır, özellikle proje ihtiyaçlarını özelleştirmeden çok daha azını karşılayacak iyi paketler varsa. Daha sonra, belirlenen ihtiyaçların çoğuna hitap edebilecek az sayıda dilde bir tür karar verilmelidir. Yeniden yoğun kullanımda, bu genellikle bir tür yapıştırıcı kodu olacaktır.
Projenin bazı üyeleri bir diğeri gibi olduğu için, benzer yeteneklere sahip birden fazla dil seçmek genellikle iyi bir fikir değildir . Bununla birlikte, özel dil becerilerinden faydalanacak iyi tanımlanmış, iyi tanımlanmış bir yetenek altkümesi varsa, bu, yeni kod geliştirme için birden çok dil kullanmak için iyi bir neden olabilir.
Sebep 5 , kullanılan dillerde ihtiyaç duyulan değişikliklere direnç, ciddi proje bozulmalarına ve iç çekişmelere neden olabilir. Kullanıcı DaveoBu cevap üzerine yapılan yorumda, bazı proje personeli için değişim çok zor olabilir. Aynı zamanda, değişime direnç hiçbir zaman basit bir mesele değildir, bu yüzden tam olarak bu kadar çekişmeye neden olabilir. Eski dil becerilerinin kullanılması, eski dil yeteri kadar güçlü ise bir projenin verimliliğini artırabilir ve sorunsuz çalışan ve kaliteye saygılı bir ekipte mükemmel kalitede bir ürüne yol açabilir. Bununla birlikte, eski dil becerileri, birçok eski dilin artık gelişmiş özellikler, bileşen kullanılabilirliği, açık kaynak seçenekleri ve akıllı araç kiti desteği açısından daha yeni dillerle tamamlanamadığı gerçeğiyle dengelenmelidir.
Hem o zaman, hem de şimdi, daha zayıf, daha az okunabilir veya daha az üretken bir dil kullanmaya devam etmek için en yaygın (ve ironik, en sık doğru) tek argüman eski dilin daha verimli kod üretilmesine olanak sağlamasıydı. Bu, meclis dili kullanıcılarının FORTRAN ve LISP'te programlamanın ortaya çıkması sık sık acı çektiği zaman, 1950'lere kadar uzanan eski bir argümandır. Artık kod verimliliği argümanının geçerliliğine sahip olabileceği bir örnek, işletim sistemi çekirdeği gibi işlem yoğun bir kodda görülebilir, burada C, C'nin C ++ 'a göre tercih edilen dil olduğu halde kalır (basit verimliliğin ötesinde olsa da).
Ancak, yeni binyılın global olarak ağa bağlı ve güçlü bir şekilde makine destekli proje ortamlarında, bir proje dilini seçmek için temel argüman olan kod verimliliği daha da güçlendi. Yapay zeka uygulamalarının toplu pazarlanmasına olanak sağlayan aynı bilgisayar ve ağ donanım patlaması da, insan programlamanın maliyetlerinin, göreceli olarak ucuz donanım ve bulut yazılımlar üzerinde verimsiz kod yürütme işlemlerinin göreceliğini azalttığı anlamına gelir. Bu, daha yeni bileşen kütüphanesi dilleri, açık kaynak seçenekleri ve gelişmiş akıllı araç kitleri için daha fazla kullanılabilirlikle birleştirildiğinde, bir dili yalnızca verimlilik nedenleriyle tutmanın çok dar olduğu durumların sayısı. Uygulandığı durumlarda bile,
Bir projenin eski dillerle kalması için daha zorlayıcı bir neden, bir projenin personelini değiştirmek için herhangi bir nedenden dolayı çok az veya hiç seçeneğe sahip olmaması durumunda ortaya çıkar. Bu, örneğin büyük bir eski ürün hattı tamamen sadece mevcut personelin akıcı olduğu bir dilde kodlandığında olabilir. Bu gibi durumlarda, proje ya eski dilde programlamaya çalışmanın yolunu sürdürmeli ya da mevcut personeli yeni bir dilin nasıl kullanılacağı konusunda eğitmeye çalışmalıdır.
Eski dil personelini yeni bir dilde eğitmek başlı başına bir tehlike olabilir. Halen yeni eğitilmiş ve C'den C ++ 'a geçişi olan bir projenin bir nesnesine, nesne yönelimli yöntemlerin avantajlarını anlamadığı için şikayette bulunduğu bir durumu hala hatırlıyorum. Koduna baktığımda, daha önceki 103 C işlevini tek bir C ++ nesne sınıfı için 103 yönteme dönüştürmüştü ... ve bunun nasıl bir şeyin işe yarayacağını görmedi.
Daha derin olan mesaj, insanlar yıllarca ya da yıllarca tek bir dilde ve dil tarzında programlandıklarında, yeni yollarla “düşünmelerini” sağlama zorluğunun, iyi eğitim programlarında bile neredeyse aşılmaz hale gelebileceğidir. Bazı durumlarda başka bir seçenek olmayabilir, ancak mevcut eğilimler ve yöntemler ile daha uyumlu olan genç tasarımcıları ve programcıları getirmek.
Sebep 6 , kötü proje yönetimi, kendisi için konuşur. Bir projede dil seçimi ve kullanımı her zaman açıkça göz önünde bulundurulmalı ve değerlendirilmeli ve sadece kazara olmasına izin verilmemelidir. En azından, dil seçimi bir projenin uzun vadeli kaderi ve destek maliyetlerinde büyük bir fark yaratabilir ve bu nedenle her zaman dikkate alınmalı ve planlanmalıdır. MUMPS olma!