Por que as pessoas reescrevem algumas bibliotecas para muitas linguagens de programação?

13

Existem algumas bibliotecas, disponíveis em suas versões escritas em várias linguagens de programação diferentes, como, por exemplo , Lucene , que é escrita em Java (como se costuma dizer, 100% Java puro), mas também possui versões em C ++, C, Perl , Ruby, Lisp e algumas outras línguas. E eu estou falando sobre implementações nessas linguagens, não apenas interfaces FFI .

porque as pessoas fazem aquilo? Eu posso ver um motivo óbvio: implantação e distribuição (e provavelmente desenvolvimento também) mais fácil quando um projeto tem menos dependências. Mas há mais alguma coisa? Em que situações vale a pena?

programming-languages libraries

— mik01aj
fonte

4

Pode ser muito caro se comunicar através das fronteiras naturais do seu ambiente de execução.

1

@ Thor: No entanto, algumas linguagens / ambientes incentivam positivamente a passagem de fronteiras naturais (C é um exemplo comum disso, e é um tema forte entre os programadores de Tcl). Suspeito que esteja relacionado principalmente ao gerenciamento de memória (e ocasionalmente a outros recursos); não é realmente bom ter dois gerenciadores de memória no mesmo processo, especialmente se eles não foram projetados para coexistir. No final, acho que se resume ao que suposições que você faz, e que as operações que, por sua vez tornar inadmissível ...

— Donal Fellows

16

Algumas razões pelas quais eu fiz isso (reescreva o código C em Haskell, no meu caso):

implantação mais fácil: apenas uma cadeia de construção
menos dependências (para obter mais adoção)
mais portátil (por exemplo, para Windows) se o código estiver em um idioma de alto nível
adicionar suporte ao paralelismo que não é fácil de executar em nível C baixo
para tornar o código um pouco mais seguro com seus recursos
para tornar o código mais fácil de confiar
mais idiomático (tipos fortes, API mais simples, mais reutilização)

— Don Stewart
fonte

19

Normalmente, reimplementar uma biblioteca para ser "nativa" para uma plataforma específica permite:

Implantação e distribuição mais simples
Depuração mais fácil
APIs idiomáticas adequadas para sua plataforma exata
Muitas vezes, melhor desempenho (a interoperabilidade de plataforma pode ser uma dor)
Corrigindo problemas de design que ainda estão no original para compatibilidade

Por exemplo, iniciei o projeto Noda Time como uma porta do Joda Time . Simplesmente não é prático usar o Joda Time diretamente do .NET ... você realmente não precisa criar uma JVM apenas para fazer cálculos de data e hora, além de descobrir como fazer a interoperabilidade entre os dois. Uma porta automatizada (à la J #) pode ter sido viável, mas o resultado final não seria uma API agradável e idiomática para usar em C #.

— Jon Skeet
fonte

11

Algumas pessoas fazem isso para ajudar a aprender um novo idioma. Eles escolhem uma biblioteca com a qual estavam familiarizados em um idioma anterior, veem que há uma necessidade dela no novo e começam a substituí-la.

Portar algo familiar é a melhor maneira de focar apenas as partes do idioma de um novo idioma, sem realmente se preocupar com o domínio do problema.

Ele também tem o benefício adicional de, uma vez feito, não ser jogar fora o código, como seriam muitos exemplos de projetos encontrados em um livro ou tutorial; pode ser algo que a comunidade possa usar, adicionar, refatorar, discutir etc.

— Neil N
fonte

0

Às vezes, você está desenvolvendo para uma plataforma em que a ferramenta em que o software foi escrito (Java no caso de Lucene) não é uma opção. Se você deseja os recursos sem precisar reorganizar o código do zero, você o portará.

— Blrfl
fonte