Почему люди переписывают некоторые библиотеки на многие языки программирования?

13

Есть некоторые библиотеки, которые доступны в своих версиях, написанных на разных языках программирования, например, Lucene , который написан на Java (как говорится, на 100% чистой Java), но также имеет свои версии на C ++, C, Perl , Ruby, Lisp и некоторые другие языки. И я говорю о реализации на этих языках, а не только интерфейсы FFI .

Почему люди так делают? Я вижу одну очевидную причину: развертывание и распространение (и, возможно, разработка) легче, когда у проекта меньше зависимостей. Но есть ли что-нибудь еще? В каких ситуациях это стоит?

programming-languages libraries mik01aj
источник
4
Общение через естественные границы вашей среды исполнения может быть очень дорогим.
1
@Thor: Тем не менее, некоторые языки / окружения положительно поощряют пересечение естественных границ (C является типичным примером этого, и это сильная тема среди программистов Tcl). Я подозреваю, что это относится главным образом к управлению памятью (и иногда другими ресурсами); на самом деле нехорошо иметь два менеджера памяти в одном процессе, особенно если они не предназначены для сосуществования. В конце концов, я полагаю, что все сводится к тому, какие предположения вы делаете, и какие операции они, в свою очередь, делают недопустимыми ...
Donal Fellows

Ответы:

16

Некоторые причины, по которым я это сделал (переписать C-код в Haskell, в моем случае):

  • более простое развертывание: только одна цепочка сборки
  • меньше зависимостей (чтобы получить больше принятия)
  • более переносимый (например, в Windows), если код написан на языке высокого уровня
  • добавить поддержку параллелизма, которую нелегко сделать на низком уровне C
  • сделать код немного более безопасным с его ресурсами
  • сделать код легче доверять
  • более идиоматический (сильные типы, более простой API, больше повторного использования)
Дон стюарт
источник
19

Как правило, переопределение библиотеки как «родной» для конкретной платформы позволяет:

  • Упрощенное развертывание и распространение
  • Более простая отладка
  • Больше идиоматических API, подходящих для вашей конкретной платформы
  • Часто лучшая производительность (взаимодействие с платформой может быть проблемой)
  • Устранение проблем дизайна, которые до сих пор в оригинале для совместимости

Например, я начал проект Noda Time как порт Joda Time . Просто не практично использовать Joda Time непосредственно из .NET ... вы действительно не хотите раскручивать JVM просто для вычисления даты и времени, а также для того, чтобы выяснить, как сделать взаимодействие между два. Автоматизированный порт (в стиле J #) мог бы быть выполнимым, но конечный результат не был бы приятным и идиоматическим API для использования из C #.

Джон Скит
источник
11

Некоторые люди делают это, чтобы помочь выучить новый язык. Они выбирают библиотеку, с которой они были знакомы на предыдущем языке, видят необходимость в новом и начинают переносить ее.

Портирование чего-то знакомого - лучший способ сосредоточиться только на языковых частях нового языка, а не беспокоиться о проблемной области.

Он также имеет дополнительное преимущество, заключающееся в том, что он не выбрасывает код, как многие примеры проектов, найденные в книге или учебном пособии, это может быть то, что сообщество может использовать, добавлять, реорганизовывать, обсуждать и т. Д.

Нил Н
источник
0

Иногда вы разрабатываете для платформы, на которой инструмент, на котором написано программное обеспечение (Java в случае Lucene), не вариант. Если вам нужны функции без необходимости реинжиниринга кода с нуля, вы портируете код.

Blrfl
источник