O problema da implementação alternativa (Alternative Implementation Problem)

O problema da implementação alternativa

O autor fala sobre o problema das implementações alternativas, que se repete no mundo do software. A experiência do autor foi principalmente com a otimização de linguagens de programação com tipagem dinâmica.

• O projeto PyPy desenvolveu um compilador JIT avançado para Python, mas na prática quase não é usado. Como Python continua adicionando novos recursos e mudando, ficou difícil para o PyPy acompanhar isso.
• LuaJIT é muito bem avaliado, mas como a linguagem Lua continua adicionando novos recursos, o LuaJIT acabou ficando várias versões para trás.
• O JIT do TruffleRuby apresentou o desempenho mais impressionante, mas por ter compatibilidade de recursos insuficiente em comparação com o CRuby, teve implantação limitada.

Lição: implementações alternativas são uma escolha fadada ao fracasso

• Ao criar uma implementação alternativa, ela inevitavelmente fica subordinada às mudanças da implementação oficial.
• A implementação oficial controla a direção do projeto, e a implementação alternativa não tem opção além de correr atrás.
• Tradicionalmente, ao criar implementações JIT para linguagens interpretadas, como adicionar novos recursos ao interpretador é muito mais rápido, a implementação oficial pode avançar mais rápido que o JIT.

YJIT: implementação de um compilador JIT de Ruby dentro do CRuby

• YJIT é mais um JIT para Ruby, mas escolheu ser implementado dentro do próprio CRuby.
• Com isso, o YJIT pôde ser 100% compatível com todos os recursos do CRuby desde o início.
• Hoje ele se tornou o JIT oficial do Ruby e está implantado em Shopify, Discourse, GitHub e outros.

Uma lição em uma perspectiva mais ampla

• A linguagem Crystal, que é parecida com linguagens existentes mas não compatível com elas, também obteve apenas sucesso limitado.
• Algo que parece semelhante a uma linguagem existente, mas não é compatível com ela, só acaba confundindo as pessoas.
• Ao criar uma nova linguagem de programação, é melhor não tentar ser um subconjunto de uma linguagem existente e seguir seu próprio caminho.
• Assim, ela pode evoluir no seu próprio ritmo e direção, sem ficar presa ao desempenho, aos recursos ou às bibliotecas de outra implementação.

Opinião do GN⁺

• O “problema da implementação alternativa” descrito no texto é algo a que se deve prestar atenção não apenas em linguagens de programação, mas também ao criar diversos tipos de sistemas de software e hardware.
• Se você se preocupar apenas com estabilidade e compatibilidade, pode ficar difícil inovar. Mas, do ponto de vista dos usuários reais, compatibilidade é um fator muito importante. É essencial equilibrar novas tecnologias e facilidade de uso.
• Em uma perspectiva de longo prazo, é necessário refletir bastante sobre com quem um novo projeto será compatível e em que direção ele deve evoluir.
• Ao criar uma nova linguagem de programação, deixar apenas a sintaxe parecida com a de uma linguagem existente só aumenta a confusão. O mais desejável é deixar clara sua própria filosofia e direção.
• Mais do que competir no mercado, parece haver maior chance de sucesso no longo prazo ao apresentar soluções criativas e originais.

[GN⁺]

Comentários do Hacker News

• Ao desenvolver uma nova implementação alternativa, se ela tiver uma arquitetura diferente da versão existente, algo que é fácil na versão atual pode se tornar muito difícil na nova. Por exemplo, se um software proprietário faz load/save por seção, enquanto a nova versão carrega o documento inteiro na memória, talvez seja necessário alterar toda a arquitetura da nova versão para oferecer suporte ao recurso de adicionar anexos.
• Posicionar-se como alternativa a uma implementação existente é uma proposta perdedora. Projetos divulgados como "Python + X" têm dificuldade para competir com a versão oficial. Porém, se forem projetados para microcontrollers como o MicroPython, sem competir com o CPython e disputando com outros ambientes de programação para microcontrollers, podem ter sucesso.
• Apesar das alegações de compatibilidade, na prática muitas vezes a compatibilidade é baixa até mesmo para recursos antigos da linguagem, e isso acaba sendo um motivo para o fracasso de implementações alternativas. No caso de Ruby e Python, a falta de suporte a extensões nativas em C é um exemplo.
• Com base na experiência de fundar uma startup, em vez de perseguir funcionalidades básicas, teria sido melhor mostrar que a arquitetura poderia dar suporte a recursos corporativos e focar em algo realmente diferenciado.
• Desenvolvedores valorizam mais recursos da linguagem e interoperabilidade do que JIT. É mais fácil criar seu próprio projeto paralelo do que contribuir para um projeto existente, mas é preciso se perguntar para quem isso está sendo feito. É importante tomar cuidado para não cair em autoindulgência.
• Código wrapper causa sofrimento por fugir do padrão e ter documentação insuficiente. O ideal é adicionar apenas os recursos realmente necessários e usar os padrões/defaults.
• É semelhante aos problemas que o TiDB enfrentou por causa da compatibilidade com MySQL. Em teoria é um protocolo aberto, mas na prática é o Chrome que dita o rumo.
• Não houve menção ao Kotlin.