Que problemas podem surgir da emulação de conceitos de outras línguas?


12

Eu já li muitas vezes na web que, se o seu idioma não suportar algum conceito, por exemplo, orientação a objetos ou talvez chamadas de função, e isso for considerado uma boa prática nesse outro contexto, você deve fazê-lo.

O único problema que vejo agora é que outros programadores podem achar seu código muito diferente do habitual, dificultando a programação. Que outros problemas você acha que podem surgir disso?


3
As pessoas vão tirar sarro de você, para uma coisa :-)
Karl Bielefeldt

Traduzi um analisador de funções aninhadas de D para java uma vez, mas admito que não é o código mais limpo que já escrevi (uma grande função com uma interface e várias classes implementando-o definidas dentro dela)
ratchet freak

Respostas:


23

Um dos problemas é que você pode escrever muito código para expressar algo da maneira que fará em outro idioma, enquanto há um jeito mais direto no idioma usado.

Por exemplo, em uma resposta no Stack Overflow , expliquei como os contratos de código, conceito usado no .NET Framework, podem ser parcialmente emulados no PHP que não os suporta. Acabei escrevendo muito código para nada, já que a mesma coisa era possível com matrizes simples.

De maneira mais geral, cada idioma tem sua própria cultura, suas melhores práticas, seu próprio estilo.

  • Se eu começar a escrever código C # como se fosse C, seria feio.

  • Se eu apreender Haskell como um desenvolvedor Java que foi forçado a usar Haskell, mas não quer entender seus pontos fortes e apenas clonar os conceitos de Java, o código que eu escreveria sofrerá.

  • etc.

Não há nada errado em tentar aprimorar o idioma (por exemplo, melhorar o C # introduzindo unidades de medida como em F #), mas se você estiver fazendo isso demais, talvez deva escolher um idioma diferente que realmente atenda às suas necessidades.


+1 Boa resposta e obrigado pelos termos de pesquisa adicionais com a adição de unidades de medida ao C #, como no F #.

2
Como alguém que uma vez deixou o emprego por ter sido forçado a usar Java, meus 2 centavos: não se pode ser forçado a usar Haskell, alguém se apaixona por ele e depois o suga até o ponto sem retorno. Haskell é como um buraco negro lindo você só quer cair - e ao contrário de um real, você ainda vivo para contar o conto :)
Cetin Sert

talvez você deva escolher outro idioma ... exceto quando não tiver escolha, como JavaScript do lado do cliente. (Mesmo assim, não tendo escolha não é desculpa para a implementação de emulação OOP baseado em classe em uma linguagem protótipo É muito mais eficiente para apenas aprender a língua funciona..)
kojiro

@kojiro: ou outro emprego. Eu mesmo tive o mesmo problema quando fui forçado a usar o PHP e estava constantemente tentando modificar a linguagem, inclusive escrevendo meu próprio compilador. Uma solução menos louca foi mudar meu trabalho e começar a trabalhar apenas em projetos que não usam PHP.
Arseni Mourzenko

1
@Cetin Sert: concordo, Haskell é uma excelente linguagem. Mas se alguém não quiser aprender e não entender programação funcional, seria difícil apreciar Haskell.
Arseni Mourzenko 18/09/12

10

A queda na legibilidade já é um problema: diminui drasticamente o número de pessoas que poderiam manter seu projeto em potencial sem um treinamento extenso de você.

Além do que, além do mais,

  • A implementação do paradigma estrangeiro pode custar mais do que a economia potencial de seu uso
  • Sua adaptação da funcionalidade estrangeira pode ser incorreta, aumentando os custos de manutenção
  • Sua adaptação da funcionalidade externa pode levar sua pilha de tecnologia aos limites além dos exigidos pela sua implementação nativa.

2
Certa vez, tive que emular o despacho dinâmico C ++ (tabelas virtuais etc.) no vanilla C e me deparei com exatamente esse problema: programadores em C que não entendiam o despacho dinâmico não conseguiram contribuir ou manter o projeto.
comingstorm 18/09/12

4

Não é tão boa ideia quanto aparece no papel.

Exemplo 1: Se você tem idade suficiente, pode se lembrar dos dias em que C era o novo garoto da cidade. Os programadores de Pascal e Ada não gostavam dos aparelhos de abertura e fechamento concisos de C. Eles # definiram begine endabrir chaves e fechar chaves, e pronto! CAda! O resultado infeliz foi feio da perspectiva de Ada ou C.

Exemplo 2, pessoal: Uma das coisas que eu realmente gostei no Common Lisp Object System é que é antes, depois e em torno dos métodos. Eles podem ser muito úteis em vários lugares. Então, eu emulei esse conceito em C ++ em alguns locais selecionados. A única maneira de emular essas construções no C ++ é exigir que o desenvolvedor de uma classe derivada chame o método com o mesmo nome da classe pai no lugar certo no código. Isso colocou um requisito para os desenvolvedores que derivaram das minhas classes que eram um pouco estranhos à programação em C ++ e, talvez, contra a base da programação em C ++. Não importa o quão bem documentado esse requisito fosse, as pessoas simplesmente não seguiram as diretrizes porque ele não se encaixava perfeitamente no paradigma C ++.


2

Que problemas podem surgir da emulação de conceitos de outras línguas?

Abstrações com vazamento.


Pode ser bom incluir mais alguns detalhes em sua resposta. O artigo relata um caso em que uma abstração falha em capturar uma otimização de desempenho significativa, mas eu diria que problemas maiores surgem de um comportamento inconsistente em caso de canto e garantias inconsistentes; um exemplo desse último seria a tentativa do C # de emular outparâmetros em uma estrutura que realmente não os suporta; O C # pressupõe que todas as funções sempre gravam em todos os seus outparâmetros, mas os métodos não C # chamados pelos métodos C # não oferecem essa garantia.
Supercat

1

Pode ser proibitivamente difícil. Imagine tentar implementar o LINQ de C # em seu aplicativo Java. Ou que tal apenas adicionar fechamentos lexicais a um idioma? Você precisaria escrever um novo compilador, o que praticamente lhe dá um novo idioma.

Ou, nos casos em que você não precisa implementar seu próprio idioma, imagine tentar implementar métodos de coleta usando funções de ordem superior (como mapa) em um idioma que não tenha blocos de código ou funções lambda ou fechamentos ou funções como primeiro objetos de classe. Toda função de ordem superior deve ser declarada como uma interface e implementada explicitamente, e todos os estados que seriam capturados em um fechamento devem ser explicitamente armazenados na classe de implementação. É uma digitação extra e muito mais difícil de ler, que geralmente não vale a pena.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.