Com a popularização de linguagens como Java e C#, e sua forte adoção no mercado de TI, é comum nos depararmos com debates sobre as diferenças entre linguagens interpretadas e linguagens compiladas. Mas na hora de classificar uma linguagem como interpretada ou compilada, a coisa esquenta e ninguém entra em acordo! Mas afinal, o que é uma linguagem interpretada e o que é uma linguagem compilada?

Antes de mais nada, vamos definir nosso glossário:

O dicionário da língua portuguesa define Compilar:

do Latim compilare
v. tr.
reunir; ajuntar

Enquanto a definição de Interpretar, é:

do Latim interpretare
v. tr.
tornar claro o sentido de; explicar; traduzir; fazer juízo a respeito de.

Pelas definições desses dois verbos, já podemos perceber que seus significados não se opõe, mas se complementam. Então como classificar uma linguagem de programação como sendo de um jeito ou de outro? Bem, a resposta é simples, definindo o contexto ou ponto de vista! E como estamos analisando linguagens de programação, nosso contexto é arquitetura de linguagens de programação.

Na computação, a compilação é o processo que reúne o código fonte e o transforma em algo que faça mais sentido para o computador. Do ponto de vista do código fonte, toda linguagem de programação é compilada.

O produto final do processo de compilação de uma linguagem diz muito sobre seu design. Linguagens como C e C++ são compiladas estaticamente, e seus códigos fontes são transformados diretamente em linguagem de máquina. Enquanto as linguagens mais modernas como Java, C# e Python têm seus códigos fontes transformados em uma linguagem intermediária (específica de cada linguagem), que será interpretada pela máquina virtual da linguagem quando o programa for executado.

Este processo de interpretação da linguagem intermediária durante a execução do programa, consiste na tradução dos comandos da linguagem intermediária para linguagem de máquina. Sendo assim, em tempo de execução, o código intermediário pode ser encarado como um “código fonte” que será compilado dinamicamente pelo interpretador da linguagem em código de máquina.

Obviamente, ter este processo de compilação embutido na execução do programa tem um custo. E esse custo não é barato! Por isso, nos últimos anos muito foi investido para otimizar este processo, resultando em todas as técnicas de Just In Time Compiling e Ahead of Time Compiling que permitem as linguagens interpretadas alcançarem performance excepcionais.

Finalmente, com base nestas definições, podemos dizer que C e C++ são linguagens compiladas. Enquanto Java, C# e Python, mesmo com as técnicas de JIT e AOT, são linguagens interpretadas, afinal, esta é uma definição da arquitetura da linguagem de programação.

A publicação da vaga para Desenvolvedor Ninja tem dado o que falar por aqui. Temos recebido algumas respostas bem relevantes. Parece que começamos nossa busca com o pé direito. No entanto, alguns candidatos ao clã estão perguntado mais detalhes sobre nossas Missões Ninja.

É difícil definir um padrão para esse tipo de trabalho. Mas recentemente, um de nossos Ninjas, especializado em Linux concluiu uma missão bem interessante.

Com pouca experiência com a Plataforma Win32, ele criou um componente COM, estendendo um componente oferecido pelo Windows para melhorar e simplificar a interação com o Powerbuilder. Suas armas foram:

1. Milhares de tabs do Firefox com a documentação do MSDN.
2. VIM como editor de texto para atender seu requinte masoquista.
3. GCC para compilar o código escrito no Linux para Windows.
4. O código fonte do Wine 1.0 para compreender melhor a relação entre alguns elementos da arquitetura COM.
5. Templates em C++ para simplificar o código e evitar repetições.

Mesmo com armas um tanto inusitadas, a chave do sucesso foi a técnica. Sua consciência de que ele não dominava a plataforma o levou a adotar abordagens mais conservadoras e seguras na hora de criar o código. Resultado: Missão cumprida!

No desenvolvimento de todo sistema multi-usuário, surge a questão: Precisamos de um controle de acesso às funcionalidades! Como faremos?

Antigamente, ao ler a palavra “funcionalidades”, a equipe se lançava em uma cruzada para mapear todas as funcionalidades do sistema e então criar um padrão único para o controle de acesso. Quem não se lembra das detestáveis matrizes de acesso?

Essa abordagem é ruim, pois restringe o controle de acesso à operações comuns a todos os elementos do sistema.

A melhor prática para autorização em sistemas é o Role Based Access Control (RBAC), que foca em permissões. Uma permissão é tão granular quanto exigir o seu projeto. Um usuário pode ter permissão para incluir um Produto, permissão para visualizar um botão da interface, permissão para acessar uma página, permissão para listar apenas os Clientes com renda entre R$ 350,00 e R$ 3000,00.

Sistemas como Microsoft Active Directory e PostgreSQL estão entre os que utilizam RBAC. E para os desenvolvedores, é possível encontrar componentes que implementam RBAC, como o ActiveRBAC do Ruby on Rails.