Entendo as diferenças entre idiomas interpretados e compilados, mas se alguém puder fornecer alguns exemplos de situações em que é provável que alguém use idiomas interpretados sobre idiomas compilados, bem como situações em que provavelmente usará idiomas compilados em idiomas interpretados, seria seja realmente útil.
Respostas:
(Que eu saiba) não existe uma "linguagem" interpretada ou uma "linguagem" compilada.
Os idiomas especificam a sintaxe e o significado das palavras-chave, construções de fluxo e várias outras coisas do código, mas não conheço nenhum idioma que especifique se deve ou não ser compilado ou interpretado nas especificações de idioma.
Agora, se a sua pergunta é quando você usa um compilador de linguagem versus um intérprete de linguagem, ele realmente se resume aos prós / contras do compilador versus o intérprete e ao objetivo do projeto.
Por exemplo, você pode usar o compilador JRuby para facilitar a integração com as bibliotecas java em vez do interpretador MRI ruby. Provavelmente, também existem razões para usar o intérprete de MRI ruby no JRuby, embora eu não esteja familiarizado com o idioma e não possa falar sobre isso.
Touted benefícios dos intérpretes:
Benefícios apontados pelos compiladores:
No entanto, aposto que em 90% dos casos é mais ou menos assim: quero escrever este software em blub porque o conheço bem e deve fazer um bom trabalho. Usarei o interpretador de blub (ou compilador) porque é o método canônico geralmente aceito para escrever software no blub.
Portanto, TL; DR é basicamente uma comparação caso a caso dos intérpretes versus os compiladores do seu caso de uso específico.
Além disso, FFI: Foreign Function Interface, em outras palavras, interface para interoperar com outros idiomas. Mais leitura na wikipedia
Um ponto importante aqui é que muitas implementações de linguagem realmente fazem algum tipo de híbrido de ambas. Atualmente, muitas linguagens comumente usadas compilam um programa em um formato intermediário, como bytecode, e executam isso em um intérprete. É assim que Java, C #, Python, Ruby e Lua são tipicamente implementados. De fato, é sem dúvida o modo como a maioria dos idiomas em uso atualmente é implementada. Portanto, o fato é que hoje a linguagem interpreta e compila seu código. Algumas dessas linguagens possuem um compilador JIT adicional para converter o código de bytes em código nativo para execução.
Na minha opinião, devemos parar de falar sobre linguagens interpretadas e compiladas porque elas não são mais categorias úteis para distinguir as complexidades das implementações de linguagem atuais.
Quando você pergunta sobre os méritos das linguagens interpretadas e compiladas, provavelmente quer dizer outra coisa. Você pode estar perguntando sobre o mérito da tipagem estática / dinâmica, os méritos da distribuição de executáveis nativos, as vantagens relativas da compilação JIT e AOT. Todos esses são problemas que se confundem com a interpretação / compilação, mas são problemas diferentes.
Antes de tudo, uma linguagem de programação pode ser tanto interpretada como compilada. Interpretação e compilação são apenas métodos de geração de código executável a partir do código fonte. Com um intérprete, o código-fonte está sendo lido e interpretado por um intérprete que, em seguida, executa o código como ele o interpreta. Um compilador, por outro lado, lê o código-fonte e gera um arquivo binário executável a partir do código-fonte - para que o programa possa ser executado como um processo separado independentemente.
Agora, antes que alguém se pergunte ... Sim, C / C ++ / C # / Java podem ser interpretados e sim, scripts JavaScript e Bash podem ser compilados. Se há intérpretes ou compiladores de trabalho para esses idiomas, é outra questão.
Agora, para realmente responder à pergunta, quando usaremos "linguagem interpretada" em vez de "linguagem compilada". A questão em si é um pouco confusa, mas presumo que isso significa quando preferir a interpretação à compilação. Uma das desvantagens da compilação é que ela gera alguma sobrecarga devido ao processo de compilação - o código-fonte precisa ser compilado no código de máquina executável, para que não seja adequado para tarefas que exigem um atraso mínimo ao invocar o código-fonte para executar um programa. Por outro lado, o código fonte compilado é quase sempre mais rápido que o código fonte interpretado equivalente devido à sobrecarga causada pela interpretação do código. Os intérpretes, por outro lado, podem invocar e executar o código fonte com muito pouca sobrecarga de invocação, mas à custa do desempenho em tempo de execução.
No final, é quase impossível mencionar casos de uso definidos quando preferir um após o outro, mas, por exemplo, um caso (para o meu significado muito irreal) seria quando o código-fonte do programa muda dinamicamente entre invocações de programas e a sobrecarga de compilação é muito alta. alto para que seja uma escolha viável. Nesse caso, provavelmente seria desejável interpretar o código fonte em vez de compilar.
No entanto, há algo que pode ser considerado um exemplo do mundo real: ocultar o código-fonte na implantação. Com nativamentecódigo compilado, o desenvolvedor implementa o código macine executável do programa e dos dados. Com o código interpretado, o próprio código-fonte precisa ser implantado, o que pode ser inspecionado e submetido a engenharia reversa com muito menos esforço do que o que é fazer engenharia reversa do código de máquina nativo. Uma exceção a isso são linguagens como C # e Java, que são compiladas no idioma / bytecode imediato (MSIL para C # e bytecode Java para Java), que são implementadas e compiladas "just in time" no tempo de execução, como um intérprete. No entanto, existem os chamados decompiladores para MSIL e Java Bytecode que podem reconstruir o código-fonte original com uma precisão relativamente boa e, como tal, esses produtos de engenharia reversa são muito mais triviais do que os produtos de engenharia reversa implementados no código de máquina nativo.
Posso pensar nos seguintes cenários quando você usaria uma linguagem interpretada :
Posso pensar nos seguintes cenários quando você deseja compilar seu código:
No final, o grande dilema é entre produtividade (quantas linhas de código você precisa escrever) e desempenho (com que rapidez seu programa será executado).
Como as linguagens interpretadas, quando transformadas em informações da CPU, têm mais informações, elas podem contar com reflexão e digitação dinâmica que aumentam bastante a produtividade . Outra vantagem das linguagens interpretadas é que elas são independentes da plataforma, desde que haja um intérprete para a plataforma.
Como a CPU não deve transformar o código do idioma no código da máquina e executá-lo ao mesmo tempo, como no caso interpretado, os idiomas compilados produzem programas mais rápidos. Além disso, um sistema construído em uma linguagem compilada é mais seguro, pois pode detectar problemas em tempo de compilação, o que basicamente significa que você vê um erro ao digitá-lo (com IDEs modernos) em vez de vê-lo apenas quando você executa o programa (é claro) , isso não corrige erros lógicos).
Sabendo disso, os idiomas interpretados são adequados para:
E os idiomas compilados são adequados quando:
Além dos motivos mencionados pelos outros, há um caso de uso particularmente importante para escolher uma interpretação ad hoc sobre qualquer forma de compilação ou qualquer abordagem híbrida.
Caso uma linguagem de programação seja usada como protocolo de comunicação e quando a latência da resposta seja importante, faz mais sentido evitar perder tempo na compilação e em qualquer pré-processamento possível.
Isso se aplica aos idiomas dos agentes, por exemplo, ou à maneira como, digamos, Tcl / Tk é normalmente usado.
Outro motivo possível para continuar com a interpretação é quando um intérprete de idioma é usado para iniciar por si próprio ou por uma linguagem mais elaborada e de nível superior, e sua simplicidade é mais importante que o desempenho do processo de inicialização.
Para quase qualquer outro caso de uso possível, a compilação (ou uma abordagem híbrida) é mais adequada.