Dlaczego ludzie przepisują niektóre biblioteki na wiele języków programowania?

Istnieje kilka bibliotek, które są dostępne w swoich wersjach napisanych w wielu różnych językach programowania, na przykład Lucene , która jest napisana w Javie (jak mówią 100% czysta Java), ale ma również swoje wersje w C ++, C, Perl , Ruby, Lisp i niektóre inne języki. Mówię o implementacjach w tych językach, a nie tylko interfejsach FFI .

Dlaczego ludzie to robią? Widzę jeden oczywisty powód: łatwiejsze wdrażanie i dystrybucja (i prawdopodobnie także programowanie), gdy projekt ma mniej zależności. Ale czy jest coś jeszcze? W jakich sytuacjach warto?

Niektóre powody, dla których to zrobiłem (w moim przypadku przepisz kod C w Haskell):

• łatwiejsze wdrożenie: tylko jeden łańcuch kompilacji
• mniej zależności (aby uzyskać więcej adopcji)
• bardziej przenośny (np. do systemu Windows), jeśli kod jest w języku wysokiego poziomu
• aby dodać obsługę równoległości, która nie jest łatwa do wykonania na niskim poziomie C.
• aby kod był nieco bezpieczniejszy dzięki swoim zasobom
• aby łatwiej zaufać kodowi
• bardziej idiomatyczny (silne typy, prostsze API, więcej ponownego użycia)

Zwykle ponowne wdrożenie biblioteki, aby była „natywna” na konkretnej platformie, umożliwia:

• Prostsze wdrażanie i dystrybucja
• Łatwiejsze debugowanie
• Więcej idiomatycznych interfejsów API odpowiednich dla konkretnej platformy
• Często lepsza wydajność (interop platformy może być uciążliwy)
• Naprawianie problemów projektowych, które są nadal oryginalne w celu zapewnienia zgodności

Na przykład rozpocząłem projekt Noda Time jako port Joda Time . Po prostu nie jest praktyczne korzystanie z Joda Time bezpośrednio z .NET ... tak naprawdę nie chcesz uruchamiać JVM tylko po to, aby wykonać obliczenia daty i godziny, a także dowiedzieć się, jak zrobić interop między dwójka. Zautomatyzowany port (a la J #) mógł być wykonalny, ale efekt końcowy nie byłby przyjemnym i idiomatycznym API do użycia z C #.

Niektóre osoby robią to, aby pomóc w nauce nowego języka. Wybierają bibliotekę, z którą byli zaznajomieni w poprzednim języku, widzą, że jest potrzebna w nowej wersji, i zaczynają ją przenosić.

Przeniesienie czegoś znajomego jest najlepszym sposobem, aby skupić się tylko na części językowej nowego języka i nie martwić się domeną problemową.

Ma również tę dodatkową zaletę, że po zakończeniu nie wyrzuca kodu, jak wiele przykładowych projektów znalezionych w książce lub samouczku, może być czymś, czego społeczność może używać, dodawać, refaktoryzować, dyskutować itp.

Czasami tworzysz platformę, na której narzędzie, w którym zostało napisane oprogramowanie (Java w przypadku Lucene) nie jest opcją. Jeśli chcesz funkcji bez konieczności ponownego projektowania kodu od zera, możesz go przenieść.