Re: [androidbrasil-dev] Android, Java e outras Linguagens

Apenas para conhecimento, já existe o MonoDroid. 

O mono é :  Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Xamarin, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.  (http://www.mono-project.com/Main_Page )

Hoje a  http://xamarin.com/  da suporte e grandes facilidades como apenas um Next Next Finish para você configurar o ambiente e usar o Visual Studio, C# e ele compila e gera um APK. 

(comentario on) Apenas uma observação: A plataforma Mono, o idealizar foi um brasileiro, bem como o kinect tambem foi obra de brasileiro ( comentario off )

Em 6 de fevereiro de 2012 08:43, Erick Petrucelli <erickpetru@gmail.com> escreveu:

Clebão, com todo respeito, mas sua explicação possui alguns equívocos. Vou tentar esclarecer melhor:

C# (ou VB.NET, Delphi.NET, Cobol.NET, J#, C++.NET, etc, e todas as outras mais de 50 linguagens suportadas pela plataforma .NET) também geram código intermediário como o Java (chamado MSIL, mas exatamente com o mesmo conceito do bytecode Java). Existem algumas outras linguagens/plataformas que se utilizem desta mesma ideia, embora Java e .NET sejam as mais conceituadas e relevantes.

Enfim, para qualquer uma destas linguagens, do ponto de vista estritamente técnico sobre a codificação, seria totalmente plausível para um compilador gerar código intermediário bytecode ao invés de MSIL, contanto que o compilador fosse criado para isso. Obviamente, para a máquina virtual Dalvik do Android, o código intermediário gerado é um pouco diferente, porém a estratégia seria a mesma. Caberia ao compilador da linguagem ser programado para gerar o código intermediário apropriado. Ou seja, se o Google quisesse, poderia criar compiladores para várias linguagens, transformando C# em bytecode Dalvik, por exemplo.

A dificuldade não está exatamente aí. Ocorre que transformar a sintaxe e a semântica de uma linguagem em um código intermediário é só uma parte da questão. O principal "detalhe" são realmente as bibliotecas de apoio, onde estão definidos todos os tipos, classes e métodos nativos do ambiente.

Então vamos a um exemplo prático, supondo um código C# como este:

using System;

... 

var hoje = DateTime.Now.ToString("dd/MM/yyyy");

E agora um código similar em Java:

import java.util.Date;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
...
DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
Date date = new Date();
string hoje = dateFormat.format(date);

Transformar os tokens de cada linguagem e sua sintaxe em um código intermediário não seria problema. Mas o que fazer em relação às bibliotecas utilizadas (usings e imports)? O Android possui seu próprio conjunto de bibliotecas (que mudam a cada versão do sistema), então escrevemos os códigos acessando essas bibliotecas. Claro que essas bibliotecas são muito parecidas com as bibliotecas do Java tradicional, afinal se basearam nele de certa forma.

Agora, para uma pessoa codificar em C# e compilar para Android, ou o compilador teria que conhecer os códigos equivalentes para traduzir todas as bibliotecas .NET utilizadas em bibliotecas Android equivalentes, o que é impossível, já que não existe equivalência para tudo, ou o programador teria que conhecer as bibliotecas da plataforma Android, o que é obviamente o mais indicado.

Mas então, se o programador vai ter de aprender a trabalhar com a plataforma de qualquer maneira, que diferença faz simplesmente permitir outra sintaxe? Tá, é uma questão de gosto e costume, mas acaba sendo a menor parte do aprendizado se acostumar com outra sintaxe de codificação (embora as linguagens do exemplo sejam muito parecidas em sintaxe de qualquer maneira, afinal são ambas baseadas no C++ e o C# em si foi totalmente criado "copiando" as boas ideias do Java).

Resumindo a história: o Google não teria grande trabalho para criar compiladores que traduzissem sintaxe e semântica das mais diversas linguagens do mercado em bytecode Dalvik. Por sua vez, o Google poderia se matar tentando fazer cada compilador entender uma chamada à biblioteca X e converter à biblioteca equivalente do Android e mesmo assim não ficaria confiável o suficiente (e muitas vezes não teria equivalência de qualquer maneira). Então, o programador teria de conhecer todas as bibliotecas Android de qualquer forma. Enfim, o ganho prático seria tão pequeno que o investimento não é justificável.

A única vantagem seria marketing, que é o motivo pelo qual a Microsoft criou (ou apoiou a criação) de tantos compiladores para tantas dezenas de linguagens para o MSIL da plataforma .NET. Mesmo assim, forçando todas elas a usarem as bibliotecas da plataforma, obviamente.

Espero que a explicação tenha ficado clara para todos. Ou seja Luiz, seu amigo tinha razão. Mas não tinha, ao mesmo tempo. Agora você já pode argumentar com ele para defender ou atacar a ideia. Boa sorte.

--

Att.

Diego Ampessan

Microsoft MTA

www.diegoampessan.com.br

Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seu poder ultrapassa os limites da imaginação  - "Albert Einstein "