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

Respostas:

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