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

13

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?

programming-languages libraries mik01aj
źródło
4
Komunikacja poza naturalnymi granicami środowiska wykonywania może być bardzo droga.
1
@Thor: Jednak niektóre języki / środowiska pozytywnie zachęcają do przekraczania naturalnych granic (C jest tego częstym przykładem i jest silnym tematem wśród programistów Tcl). Podejrzewam, że dotyczy to głównie zarządzania pamięcią (i czasami innymi zasobami); naprawdę nie jest dobrze mieć dwóch menedżerów pamięci w tym samym procesie, zwłaszcza jeśli nie zostały zaprojektowane do współistnienia. W końcu przypuszczam, że sprowadza się to do założeń, które przyjmujesz i jakich operacji z kolei czynią niedopuszczalnymi…
Donal Fellows

Odpowiedzi:

16

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)
Don Stewart
źródło
19

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 #.

Jon Skeet
źródło
11

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.

Neil N.
źródło
0

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ść.

Blrfl
źródło