Pourquoi les gens réécrivent-ils certaines bibliothèques dans de nombreux langages de programmation?

13

Il existe certaines bibliothèques, qui sont disponibles dans leurs versions écrites dans de nombreux langages de programmation différents, comme par exemple Lucene , qui est écrit en Java (comme on dit, 100% Java pur), mais a également ses versions en C ++, C, Perl , Ruby, Lisp et quelques autres langues. Et je parle d' implémentations dans ces langages, pas seulement des interfaces FFI .

Pourquoi les gens font ça? Je peux voir une raison évidente: le déploiement et la distribution (et probablement aussi le développement) plus faciles quand un projet a moins de dépendances. Mais y a-t-il autre chose? Dans quelles situations cela en vaut-il la peine?

programming-languages libraries

— mik01aj
source

4

Il peut être très coûteux de communiquer au-delà des frontières naturelles de votre environnement d'exécution.

1

@Thor: Pourtant, certains langages / environnements encouragent positivement le franchissement des frontières naturelles (C est un exemple courant de cela, et c'est un thème fort parmi les programmeurs Tcl). Je soupçonne que cela concerne principalement la gestion de la mémoire (et parfois d'autres ressources); ce n'est vraiment pas bon d'avoir deux gestionnaires de mémoire dans le même processus, surtout s'ils n'ont pas été conçus pour coexister. En fin de compte, je suppose que cela dépend de quelles hypothèses vous faites, et quelles opérations elles rendent à leur tour inadmissibles…

— Donal Fellows

16

Quelques raisons pour lesquelles je l'ai fait (réécrire le code C dans Haskell, dans mon cas):

déploiement plus facile: une seule chaîne de génération
moins de dépendances (pour gagner en adoption)
plus portable (par exemple pour Windows) si le code est dans une langue de haut niveau
ajouter un support pour le parallélisme pas facile à faire en bas niveau C
pour rendre le code un peu plus sûr avec ses ressources
pour rendre le code plus fiable
plus idiomatique (types forts, API plus simple, plus de réutilisation)

— Don Stewart
source

19

En général, la réimplémentation d'une bibliothèque pour être «native» sur une plate-forme particulière permet:

Déploiement et distribution simplifiés
Débogage simplifié
Des API plus idiomatiques adaptées à votre plateforme exacte
Performances souvent meilleures (l'interopérabilité de la plateforme peut être pénible)
Correction des problèmes de conception qui sont toujours dans l'original pour la compatibilité

Par exemple, j'ai commencé le projet Noda Time en tant que port de Joda Time . Il n'est tout simplement pas pratique d'utiliser Joda Time directement à partir de .NET ... vous ne voulez vraiment pas avoir à faire tourner une machine virtuelle Java uniquement pour faire des calculs de date et d'heure, ainsi que pour savoir comment faire l'interopérabilité entre les deux. Un port automatisé (à la J #) aurait pu être faisable, mais le résultat final n'aurait pas été une API agréable et idiomatique à utiliser à partir de C #.

— Jon Skeet
source

11

Certaines personnes le font pour aider à apprendre une nouvelle langue. Ils choisissent une bibliothèque qu'ils connaissaient dans une langue précédente, voient qu'il y en a un besoin dans la nouvelle et commencent à la porter.

Porter quelque chose de familier est le meilleur moyen de se concentrer uniquement sur les parties linguistiques d'une nouvelle langue et de ne pas vraiment se soucier du domaine problématique.

Il a également l'avantage supplémentaire, une fois terminé, de ne pas jeter le code comme le seraient de nombreux exemples de projets trouvés dans un livre ou un didacticiel, il peut en fait être quelque chose que la communauté peut utiliser, ajouter, refactoriser, discuter, etc.

— Neil N
source

0

Parfois, vous développez une plate-forme où l'outil dans lequel le logiciel a été écrit (Java dans le cas de Lucene) n'est pas une option. Si vous voulez les fonctionnalités sans avoir à repenser le code à partir de zéro, vous portez le code.

— Blrfl
source