¿Por qué la gente reescribe algunas bibliotecas en muchos lenguajes de programación?

13

Hay algunas bibliotecas, que están disponibles en sus versiones escritas en muchos lenguajes de programación diferentes, como por ejemplo Lucene , que está escrito en Java (como dicen, Java 100% puro), pero también tiene sus versiones en C ++, C, Perl , Ruby, Lisp y algunos otros idiomas. Y estoy hablando de implementaciones en estos idiomas, no solo de interfaces FFI .

¿Porqué la gente hace eso? Puedo ver una razón obvia: la implementación y distribución (y probablemente también el desarrollo) más fácil cuando un proyecto tiene menos dependencias. ¿Pero hay algo más? ¿En qué situaciones vale la pena?

programming-languages libraries mik01aj
fuente
44
Puede ser muy costoso comunicarse a través de las fronteras naturales de su entorno de ejecución.
1
@Thor: Sin embargo, algunos lenguajes / entornos fomentan positivamente el cruce de fronteras naturales (C es un ejemplo común de esto, y es un tema fuerte entre los programadores de Tcl). Sospecho que se relaciona principalmente con la gestión de la memoria (y ocasionalmente de otros recursos); Realmente no es bueno tener dos administradores de memoria en el mismo proceso, especialmente si no fueron diseñados para coexistir. Al final, supongo que todo se reduce a las suposiciones que haces y las operaciones que a su vez hacen inadmisibles ...
Donal Fellows

Respuestas:

16

Algunas razones por las que lo hice (reescribir el código C en Haskell, en mi caso):

  • despliegue más fácil: solo una cadena de compilación
  • Menos dependencias (para obtener más adopción)
  • más portátil (por ejemplo, a Windows) si el código está en un lenguaje de alto nivel
  • para agregar soporte para paralelismo que no se hace fácilmente en bajo nivel C
  • para hacer el código un poco más seguro con sus recursos
  • para hacer que el código sea más fácil de confiar
  • más idiomático (tipos fuertes, API más simple, más reutilización)
Don Stewart
fuente
19

Normalmente, la reimplementación de una biblioteca para que sea "nativa" a una plataforma particular permite:

  • Implementación y distribución más simples.
  • Depuración más fácil
  • API más idiomáticas adecuadas para su plataforma exacta
  • A menudo, mejor rendimiento (la interoperabilidad de plataformas puede ser una molestia)
  • Solucionando problemas de diseño que todavía están en el original por compatibilidad

Por ejemplo, comencé el proyecto Noda Time como un puerto de Joda Time . Simplemente no es práctico usar Joda Time directamente desde .NET ... realmente no desea tener que girar una JVM solo para hacer cálculos de fecha y hora, así como para averiguar cómo hacer la interoperabilidad entre los dos. Un puerto automatizado (a la J #) podría haber sido factible, pero el resultado final no habría sido una API agradable e idiomática para usar desde C #.

Jon Skeet
fuente
11

Algunas personas lo hacen para ayudar a aprender un nuevo idioma. Escogen una biblioteca con la que estaban familiarizados en un idioma anterior, ven que hay una necesidad en el nuevo y comienzan a portarla.

Portar algo familiar es la mejor manera de enfocarse solo en las partes del idioma de un nuevo idioma, y ​​no preocuparse realmente por el dominio del problema.

También tiene el beneficio adicional de que, una vez hecho, no se descarta el código, como lo serían muchos proyectos de muestra encontrados en un libro o tutorial, en realidad puede ser algo que la comunidad puede usar, agregar, refactorizar, discutir, etc.

Neil N
fuente
0

A veces estás desarrollando una plataforma donde la herramienta en la que se escribió el software (Java en el caso de Lucene) no es una opción. Si desea las funciones sin tener que volver a diseñar el código desde cero, puede transferir el código.

Blrfl
fuente