İnsanlar neden bazı kütüphaneleri birçok programlama diline yeniden yazıyor?

13

Sürümlerinde birçok farklı programlama dilinde yazılmış, örneğin Java ile yazılmış Lucene (dedikleri gibi,% 100 saf Java) gibi sürümleri bulunan, ancak C ++, C, Perl sürümleri olan bazı kütüphaneler vardır. , Ruby, Lisp ve diğer bazı diller. Ve sadece FFI arayüzlerinden değil, bu dillerdeki uygulamalardan bahsediyorum .

İnsanlar bunu neden yapıyor? Belli bir nedeni görebiliyorum: bir projenin daha az bağımlılığı olduğunda dağıtım ve dağıtım (ve muhtemelen geliştirme) daha kolay. Ama başka bir şey var mı? Hangi durumlarda buna değer?

programming-languages libraries

— mik01aj
kaynak

4

Uygulama ortamınızın doğal sınırları boyunca iletişim kurmak çok pahalı olabilir .

1

@Thor: Yine de bazı diller / ortamlar doğal sınırları geçmeyi olumlu yönde teşvik ediyor (C bunun yaygın bir örneğidir ve Tcl programcıları arasında güçlü bir temadır). Ben esas olarak bellek (ve bazen diğer kaynak) yönetimi ile ilgili olduğundan şüpheleniyorum; aynı süreçte iki bellek yöneticisine sahip olmak gerçekten iyi değil, özellikle de bir arada var olmak için tasarlanmamışlarsa. Sonunda, hangi varsayımları yaptığınıza ve bunların hangi operasyonların kabul edilemez hale geldiğine inanıyorum…

— Donal Fellows

16

Bunu yapmamın bazı nedenleri (benim durumumda Haskell'de C kodunu yeniden yaz):

daha kolay dağıtım: sadece bir yapı zinciri
daha az bağımlılık (daha fazla evlat edinme)
kod üst düzey bir dilde ise daha taşınabilir (örneğin Windows için)
düşük C seviyesinde kolayca yapılmayan paralellik desteği eklemek
kodu kaynaklarıyla biraz daha güvenli hale getirmek için
kodun daha kolay güvenilmesini sağlamak için
daha deyimsel (güçlü türler, daha basit API, daha fazla yeniden kullanım)

— Don Stewart
kaynak

19

Genellikle bir kütüphanenin belirli bir platforma "özgün" olarak yeniden uygulanması aşağıdakileri sağlar:

Daha basit dağıtım ve dağıtım
Daha kolay hata ayıklama
Tam platformunuza uygun diğer deyimsel API'lar
Genellikle daha iyi performans (platform birlikte çalışma bir ağrı olabilir)
Uyumluluk için hala orijinal olan tasarım sorunlarını düzeltme

Örneğin, Noda Time projesine Joda Time'ın limanı olarak başladım . Joda Time'ı doğrudan .NET içinden kullanmak pratik değildir ... sadece tarih ve saat hesaplamaları yapmak için bir JVM'yi döndürmek zorunda kalmazsınız. iki. Otomatik bir bağlantı noktası (la la J #) mümkün olabilir , ancak sonuç C # 'dan kullanmak için hoş ve deyimsel bir API olmazdı.

— Jon Skeet
kaynak

11

Bazı insanlar bunu yeni bir dil öğrenmeye yardımcı olmak için yapar. Daha önceki bir dilde tanıdık oldukları bir lib seçiyorlar, yeni dilde bir ihtiyaç olduğunu görüyorlar ve onu aktarmaya başlıyorlar.

Tanıdık bir şeyi taşımak, yalnızca yeni bir dilin dil bölümlerine odaklanmanın en iyi yoludur ve sorunlu alan hakkında gerçekten endişelenmeyin.

Ayrıca, bir kez yapıldığında, bir kitapta veya öğreticide bulunan birçok örnek proje gibi kod atmaktan başka bir yararı vardır, aslında topluluğun kullanabileceği, ekleyebileceği, yeniden düzenleyen, tartıştığı vb.

— Neil N
kaynak

0

Bazen yazılımın yazıldığı aracın (Lucene'nin durumunda Java) bir seçenek olmadığı bir platform için geliştiriyorsunuzdur. Kodu sıfırdan yeniden yapılandırmak zorunda kalmadan özellikleri istiyorsanız, kodu taşırsınız.

— Blrfl
kaynak