C++ e Java (longo e off-topic) (Era:Onde foi que eu errei?)

[Nelson Posse Lago <PROTECTED>]

ATENCAO: Esta mensagem e' uma divagacao longa e totalmente "off-topic".

On Wed, Apr 03 2002 at 01:27:19pm -0300, Jorge F. Del Teglia wrote:
> At 09:53 3/4/2002 -0300, Fabio Kon wrote:
> >Alexandre Freire da Silva writes:
> > > talvez vc tenha errado em fazer o ep em c++???
> >C++ is cool!!!
> C++ é ótimo em muitas dimensões, mas acho que não precissamente na 
> produtividade...

Bom, acho que a mensagem original era so' uma piada, mas como eu ja'
queria mandar uma mensagem assim antes, la' vai:

Em primeiro lugar, eu tenho pouco experiencia de programacao e C++ e' a
unica linguagem que eu conheco (alem de C), entao meu ponto de vista
certamente e' "suspeito". No entanto, eu concordo com o Fabio: C++ is
cool, cool pra caramba mesmo. A primeira e maior razao, IMHO, e' que,
diferentemente de Java, ela e' baseada numa padronizacao aberta que tem
uma implementacao completa e consistente em software livre (GCC/G++). Eu
sei que a Sun tem sido otima em varios aspectos com relacao a Java, mas
nao da' pra negar que a Sun domina a especificacao da linguagem *e* a
unica implementacao viavel da linguagem; se amanha eles resolverem cobrar
US$500 pela JVM e implementarem extensoes "bacanas" na linguagem a partir
dai', praticamente todo mundo que usa Java vai ter que migrar para a JVM
nova e pagar para a Sun, porque ninguem pode legalmente pegar o fonte que
existe e estende-lo em uma direcao diferente da que a Sun pretende. Eu nao
creio que eles vao fazer isso, mas eu nao basearia um projeto grande e
serio em java nessas condicoes (pra coisas pequenas isso nao representa um
problema, claro: sempre da' para, em ultimo caso, reescrever); num ambito
muito menor, a Sun domina e direciona o "mercado" de Java da mesma maneira
que a M$ faz com o mercado de "desktops". O fato de a Sun, ate' o momento,
ter se mostrado muito mais etica que a M$ nao e' garantia de nada com
relacao ao futuro.

Voltando ao C++: Ela permite que voce faca codigo limpo, claro e elegante
com um nivel de performance proximo do C e, melhor, com um nivel razoavel
de produtividade. O problema e' que ela *tambem* permite que voce faca
codigo sujo, obcuro, com nivel de performance proximo do VisualBasic e,
pior, com produtividade proxima da programacao em assembler.

C++ e' muuuito poderosa e, como toda ferramenta muito poderosa, e' dificil
de dominar e usar bem. Essa e' uma das causas das frustracoes de alguns
com C++ IMHO; eu tenho lido bastante sobre C++, e percebo que ainda
preciso estudar muito para conhecer e saber usar bem a linguagem. Outras
linguagens sacrificam performance e flexibilidade para ter um "custo de
entrada" menor (e parece-me que esse e' um ponto forte de java: esse
sacrificio foi relativamente pequeno). Mas quanto mais leio, mais percebo
que a linguagem e' muito bem projetada e que os problemas que "nao
existem" em outras linguagens sao problemas de programacao, e nao do C++;
portanto, em outras linguagens os problemas ainda estao la', apenas estao
escondidos do programador. Exemplo: como vimos em aula, numa classe assim:

class blah {
public:
	blah (string);
private:
	string lala;
}

Podemos implementar o construtor assim:
blah::blah(string orig) {
	lala = orig;
}

Ou assim:

blah::blah (string orig) : lala (orig) { };

Essa segunda opcao e' mais rapida. No primeiro caso o compilador cria uma
"string", aloca uma quantidade de memoria "padrao" para ela e depois
executa a operacao de copia, que possivelmente envolve um "realloc()" na
memoria interna da string. No segundo caso, a string ja' "nasce" com o
tamanho e os dados corretos.

Mais: a classe poderia ser declarada assim:

class blah {
public:
	blah (string&);
private:
	string lala;
}

E isso faz o compilador evitar chamar o contrutor de copia da string antes
de inicializar a nova "string". Se voce nao soubesse nada disso, poderia
programar despreocupadamente no estilo "mais lento" e tudo funcionaria
corretamente, mas C++ expoe essas sutilezas para o programador. Por outro
lado, aposto que a JVM implementaria essa classe de forma equivalente `a
primeira forma que mostrei, que e' a mais lenta de todas. Moral da
historia: grande parte da complexidade "extra" de C++ vem do fato de ela
nao assumir nada e deixar as decisoes relativas `a performance por conta
do programador, mas se voce tomar as decisoes "erradas" provavelmente nao
vai se dar pior que com Java.

Outra fonte de problemas do C++ e' o parentesco com o C: isso e' otimo,
porque permite que se reutilize codigo e bibliotecas C prontos com um
minimo de esforco, mas por outro lado leva os programadores a escrever
codigo misturando o "estilo" de programacao do C com o "estilo" de
programacao do C++. Isso e' simplesmente medonho, porque voce acaba
programando com "C melhorado" ao inves de C++; ou seja, o paradigma de
objetos vai para o espaco. Pior: em C++, voce pode automatizar o "grosso"
do gerenciamento de memoria e so' se preocupar com "delete" muito
esporadicamente. Mas se voce comeca a misturar o "modo de pensar" do C na
historia, voce acaba tendo um codigo onde voce tem que fazer manualmente
todo o gerenciamento de memoria, e isso com certeza e' bem dificil; o
gerenciamento de memoria automatico e' certamente um dos atrativos do
java, muito embora haja coletores de lixo para C++. Curiosamente, os
programadores C++ nao costumam usa-los por motivos de performance, mas os
programadores java nem pensam no fato de o coletor de lixo existir.

Um exemplo de problema por causa da mistura entre C e C++: o tipo "string"
do CORBA e' mapeado em C++ para "char*". Isso foi feito para garantir uma
maior compatibilidade com o C e, talvez, para ganhar um pouco de
performance. Pelamor! O resultado disso e' a garantia de vazamentos de
memoria no programa. Esse problema e' tao serio que o CORBA tambem define
as variaveis do tipo "String_var" para oferecer um gerenciamento
automatico de memoria. Ugh! De forma similar, sequencias de strings sao
mapeadas para ponteiros para um "container". Caramba! Com um pouco de boa
vontade, daria para usar um container que funcionasse corretamente com
copias "rasas" (shallow copy) e retornar o container e nao um apontador. O
custo e' uma chamada ao construtor de copia, mas essa chamada poderia ser
bastante leve; certamente o tempo para a execucao da copia e' ordens de
magnitude menor que o tempo para a transmissao da mensagem corba via rede.

Entao, por conta dessas "chatices" que nascem da vontade de fazer as
coisas rapidamente, o programador migra para java, que realiza essas
operacoes muuito mais lentamente ainda.

Enfim, acho que e' interessante que exista uma linguagem de uso geral como
java, que oferece um "meio-termo" entre linguagens "faceis e lentas"
(visual basic, python) e a linguagem "dificil e rapida" (C++). Mas o
status do java hoje, controlado pela Sun, e o fato de ela nao estar tao
distante assim nem de C++ (pois C++ bem escrito nao precisa ser tao
complicado) nem de python (pois a velocidade muitas vezes nao importa) me
faz crer que quase sempre da' para usar uma dessas outras linguagens no
lugar do java (nao que seja "crime" usar java, mas me parece que cada vez
mais as pessoas optam por java sem pensar no assunto nem questionar se e'
a melhor solucao para o problema, simplesmente porque e' moda ou porque
ouviram falar que "e' mais facil" ou que C++ "e' muito complicada").

Agora de volta ao EP, que eu estou atrasado :-)

Desculpem o "off-topic" total
Ate' +
Nelson