De novo :-D: My 2 cents:

A JVM da Sun é um ponto de referência da comunidade. É importante que o desenvolvimento da VM, assim como das suas core-APIs, esteja sob o domínio do processo JCP.

O que eu considero válido é extender ao código da própria VM a licença de pesquisa (já disponível para as core-APIs), que permite ler o código e escrever o seu baseado no conhecimento adquirido.

Isso porque, por um lado, precisam existir implementações livres inteiramente independentes da original. Por outro, precisa existir uma implementação padrão, não-comercial disponível que seja mais conservadora.

A implementação de uma JVM livre já está em andamento com o projeto Apache Harmony (que usa e abusa da licença de pesquisa, para desenvolver as core-APIs).

Para agilizar o desenvolvimento das VM livres, a Sun poderia simplesmente doar o código existente hoje, para servir de ponto de partida. Mas esse é um processo caro, que envolve patentes "invisíveis" de muita gente que nunca se importou com seus direitos até hoje, mas que ao mero rumor de abertura vai levantar pra reclamar e vender seu código ou padrão a altos preços. A Sun terá que comprar, solicitar a doação ou substituir esses fragmentos (pra ter uma idéia, até a Kodak tem coisa no java).

Com uma equipe distribuída trabalhando direto no Apache Harmony (incluindo gente da própria Sun), duvido que eles venham a fazer isso.

Muito bom.: Eu como estudante da tecnologia Java e suas variantes, JSP, Javascript, J2ME etc vejo com muito bons olhos essa abertura.

Para mim isso ficou bem claro no Sun Teck days ocorrido mês passado, 11 e 12 de Abril.

http://sergiotucano.blogspot.com/2006/04/sun-tech-day-be-free.html
Neste link existe um relato sobre o evento que também saiu aqui no Br-Linux:
http://br-linux.org/linux/node/3367

FALOW !

JavaScript variante do: JavaScript variante do java???

Acho que se enganou =)

"A implementação de uma: "A implementação de uma JVM livre já está em andamento com o projeto Apache Harmony"

não esquecendo de Kaffe, IKVM, e outros. além do compilador nativo da FSF -- GCJ...

eu gostaria que java fosse apenas uma plataforma, ao invés de também ser uma linguagem horrenda...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"A implementação de uma: ;; ((lambda (x) x) "Isto é um post duplo e não será executado nunca")

Diferencial: não esquecendo de Kaffe, IKVM, e outros. além do compilador nativo da FSF -- GCJ...

O diferencial do Harmony em relação aos outros é que será o primeiro a ter acesso ao TCK (Kit oficial para testes de compatibilidade).

Em cima do Harmony, todas as outras implementações livres poderão desenvolver com facilidade seus kits de teste até os mínimos detalhes, pois saberão que ele estará sempre afinado com o Kit oficial. A tendência é que ele se torne uma bússola para as implementações livres.

Se a Sun liberasse a implementação do TCK seria bom... Mas isso iria fazer com que toda essa gente que escreve JVMs proprietárias, IBM, BEA, etc. (e cobra muito caro por elas) usasse a versão livre do TCK para produzir esses produtos.

Isso pq a licença livre não obriga a liberar aquilo que é feito com o produto, apenas o próprio produto.

Melhor desfecho foi esse mesmo: uma única implementação livre tem o TCK, o resto segue o Harmony. Quem quiser escrever JVM proprietária não vai conseguir se aproveitar, pois teria que seguir a licença livre.

Com o advento do Apache Harmony, as outras implementações livres darão um salto gigante.

eu gostaria que java fosse apenas uma plataforma, ao invés de também ser uma linguagem horrenda...

Ai, ai... Detalhes a parte, essa é uma opinião pessoal sua. Eu não gosto do Python que vc. gosta, o Patola odeia o TCL que vc. gosta, etc, etc.

Completamente!: Pessoalmente, fiquei feliz quando resolveram mudar esse marketing irresponsável da Netscape.

Para quem ainda não soube, java script não tem nada a ver com Java, nem a linguagem, nem com a plataforma.

Seu nome original era LiveScript e agora está sendo chamado de ECMA Script.

Why ?: ao invés de também ser uma linguagem horrenda...

Porque você tem tanta aversão à linguagem Java. Por ela ser proprietária? Pela perda de performance? Pela sintaxe? Por ser da SUN? Por não ter sido criada em Taguatinga (:D)? Por todos estes motivos juntos?

ps:[Moderem os flames por favor]

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

:-): Por ela ser proprietária?

A linguagem Java não é proprietária, pois é baseada em uma especificação aberta, com BNF disponível e roda em uma plataforma com especificação igualmente aberta também.

A questão é que a Sun desenvolveu ao longo dos anos, para seu uso, um conjunto de facilidades para manutenção dessa plataforma que outros grupos não têm.

Pela perda de performance? Pela sintaxe? Por ser da SUN? Por não ter sido criada em Taguatinga (:D)? Por todos estes motivos juntos?

Sinceramente, acho que nem ele sabe! :-D Ele diz que é por ser (como é mesmo?)... Ah, verborrágica! Mas ele gosta de C++ que é mais verborrágico ainda.

Talvez seja por ser (como dizem) de interpretação (no caso do Java, pré-compilação) lenta. Mas ele gosta do Python, que é interpretado e mais lento ainda.

Talvez seja a curva de aprendizado de todas as aplicações e APIs... Mas ele gosta de cálculo lambda, tente explicar isso pra alguém que acaba de chegar na faculdade.

Oras, desisto! Pra mim, é pessoal mesmo e não se fala mais nisso. :)

Because: * O software que é preciso ter instalado para se executar um programa em Java (runtime) é enorme.

* O próprio programa (.jar) é enorme em comparação com o tamanho que teria se fosse escrito em outras linguagens.

* Java é complexa demais. Tanto quanto C, só que C é muitas vezes melhor (mais leve, mais rápida, mais portável, mais difundida, etc.) Ou a gente usa C ou usa uma "linguagem de script" (Perl, Python, shell). Java é muito lenta e inchada pra tomar o lugar de C e muito complicada e pentelha pra tomar o lugar dos scripts.

* Java é vendida como uma linguagem multi-plataforma e/ou portável, mas quando se leva o programa para outra plataforma, sempre tem um monte de coisa que não funciona.

* Os widgets em Java são horrorosos. Se for pra trabalhar com aquilo, prefiro Tcl/Tk, que têm todas as qualidades que tem Java, mais algumas outras, e nenhum dos defeitos.

* Java é lenta.

* TODO site que usa Tomcat e/ou termina em .jsp fazem minha banda larga parecer linha discada.

* Quase todos os programas feitos em Java que eu já vi eram absolutamente toscos. E lentos.

* Existem várias versões de Java por aí. Evidentemente, incompatíveis entre si.

* Java é uma grande criadora de empregos. Exige 20 programadores para desenvolver o que em outras linguagens bastaria 4.

http://web.ivy.net/~carton/rant/java_languageoftomorrow.html

Java X Empregos:

* Java é uma grande criadora de empregos. Exige 20 programadores para desenvolver o que em outras linguagens bastaria 4.

Hei, eu tinha inventado essa frase também, quando o pessoal da facu (que ensina Java) me perguntou sobre o mercado para um programador Python.
Na época tinha achada a frase original. :S rs...

Após reponder isso sobre o Java, eu indiquei o texto "Great hackers " do Paul Graham:
http://www.paulgraham.com/gh.html

Até mais,

Luciano Pacheco

gosto não se discute: "Pela perda de performance?"

sim, principalmente do programador...

" Pela sintaxe?"

sim, e a coisa tá piorando e a linguagem está ficando tão barroca e poluída quanto papai C++...

" Por ser da SUN?"

sim, linguagens definidas por corporações não cheiram bem...

" Por não ter sido criada em Taguatinga (:D)?"

sim, se fosse daqui eu poderia mandar uma bomba pra sede e acabar com isso de vez...

" Por todos estes motivos juntos?"

sim, e muitos outros

"Ah, verborrágica!"

como esse.

" Mas ele gosta de C++ que é mais verborrágico ainda."

eu não gosto de C++: eu odeio menos que java. É bastante barroca e verborrágica tmb, mas permite esconder isso em operadores simples e integrados à linguagem. E ainda tem performance bem superior... :)

"Mas ele gosta do Python, que é interpretado e mais lento ainda."

Tanto C++ quanto Python batem Java em performance, seja a da máquina, seja a do programador. :)

"Talvez seja a curva de aprendizado de todas as aplicações e APIs... Mas ele gosta de cálculo lambda, tente explicar isso pra alguém que acaba de chegar na faculdade."

vc realmente acha mais fácil um novato guardar na cabeça as imensas APIs java do que aprender uma noção sobre funções anônimas e como combinar, receber e retornar funções como outro dado qualquer?... além da sintaxe rebuscada e cada vez mais complexa de java?...

é, há gosto pra tudo...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

conexões: Javascript deve muito de suas idéias a Self, uma inovativa linguagem com OO baseada em protótipos, exatamente como javascript. Self era um veículo de pesquisas em linguagens de programação e o pessoal por trás dela eventualmente foi contratado pela Sun devido ao seu projeto com a inovativa VM da linguagem. Lá dentro, puseram eles para trabalhar na VM java e o mundo perdeu uma linguagem inovadora, mas ganhou uma VM de ponta na forma do compilador em runtime Hotspot...

como se vê, há sempre uma conexão da parte com o todo no mundo... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

A questão é que a Sun: A questão é que a Sun desenvolveu ao longo dos anos, para seu uso, um conjunto de facilidades para manutenção dessa plataforma que outros grupos não têm.
A vantagem é domínio sobre o código fonte do aplicativo e a vantagem de sempre poder desenvolver o melhor aplicativo pois ela detém a receita, é que nem tentar copiar a coca-cola mas nunca é igual.
O mercado de Java é bom para quem trabalha com ele, mas tem muito marketing e na verdade o cara nem sabe porque escolheu o java para o desenvolvimento (o empresário), ele só ouviu alguém falar ou leu em algum lugar.
O que falta para o Brasil é consultorias de verdade, que não existem. Não existe auditoria em alguns projetos de grande porte, acho uma vergonha o mercado de desenvolvimento, exclamação.
Concordo que o Python é uma solução mais integrada e robusta do que, o Java que veio com o marketing de "compile once, run everywhere" e todos sabem que não é verdade, que uma ferramenta free como o lazarus roda em mais plataformas do que o Java. Afinal como o Java é mais "Open" do que o Lazarus? Tem empresas apoiando um genérico feito sob marca "Apache", mas na verdade são empresas como IBM e HP que estão desenvolvendo o produto.
Tenho vergonha dessas consultorias de meia tigela que só fala em Java, é uma vergonha.

Não tem um pouco...: "Pela perda de performance?"
sim, principalmente do programador...

Não estou querendo defender o Java (até porque não sei programar nesta linguagem e ainda não tive tempo de dar um look nela...) mas será que não tem neste comentário um pouco daquele negócio do Gimp. Será que se você conhecer as manhas da linguagem você não se torna produtivo?

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Você não acha...: O mercado de Java é bom para quem trabalha com ele, mas tem muito marketing e na verdade o cara nem sabe porque escolheu o java para o desenvolvimento (o empresário), ele só ouviu alguém falar ou leu em algum lugar.

Você não acha que pode estar pesando o fato de haver mão de obra farta para desenvolvimento em Java? Será que a estratégia de marketing da SUN não é exatamente esta?

Não sei se o empresário está muito interessado em que linguagem esta sendo feito o desenvolvimento. Acho que a questão principal é o volume de mão de obra disponível.

Vocês hão de convir comigo, mas não creio que existam programadores Phyton, Ruby, Perl, etc. capazes de atender o mercado. Talvez PHP até já esteja chegando lá em função da sua integração com banco de dados (e-comerce).

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Java the hutt: Java é formal, eu penso de modo formal, está sendo divertido estudar Java...

Java lento para desenvolver: Exemplo de perda de tempo no desenvolvimento.

Lendo dados de um arquivo...
Python

arq = open('dados.txt', 'r')
for linha in arq.readlines():
print linha #essa linha é identada, mas no post não fica correto :(
arq.close()


Java (obviamente não sei de cabeça, busquei no Google) :) http://www.guj.com.br/java.tutorial.artigo.13.1.guj

FileReader reader = new FileReader(new File("dados.txt"));
BufferedReader leitor = new BufferedReader(reader);

String linha = null;
while((linha = leitor.readLine())) {
System.out.println(linha);
}



Sacou !?

Será que se você conhecer as manhas da linguagem você não se torna produtivo?

Sim, e é muito mais fácil você pegar as manhas no Python do que a API Java. ;)

Luciano Pacheco

Lamda é opcional:
vc realmente acha mais fácil um novato guardar na cabeça as imensas APIs java do que aprender uma noção sobre funções anônimas e como combinar, receber e retornar funções como outro dado qualquer?... além da sintaxe rebuscada e cada vez mais complexa de java?...


Cabe lembrar que usar lambda é opcional.

Em Java você é obrigado a:
1 - Usar a "simples" API
2 - Declarar tudo
3 - Usar classes

Luciano Pacheco

hum..: hum..

discordo viu.. para por exemplo ler um arquivo, vc poderia ter uma classe utilitaria que jogaria tudo em um ArrayList

public List readFile(String filename) {}

e seu codigo ficaria:
ArrayList arq = (ArrayList)ClassUteis.readFile("meuarquivo.txt");
for (String linha : linha) {
//faz o q quer com a linha aqui
}

e tem inumeras outras formas de se fazer isso, pra ganhar produtividade...
claro, vc tem uma boa curva de aprendizado pela frente, e tem que desenvolver algumas APis porem, a maioria das que vc precisa, vc tem já disponivel: hibernate (bd), apache commons (api pra uma porrada de coisa)..

e eu so citei api opensource :)

hugs

2 cents: 1) vc esqueceu ( de propósito? ) que precisa declarar toda uma classe e um método static void main em torno de seu código.
2) vai jogar um arquivão todo em memória? falta de consciência com recursos e performance é bem típico de programadores java, tsk, tsk!

bem, aqui vai um pouco de Perl -- imbatível em processamento de textos em lote -- para alegrar a criançada:

open ARQ, "lista_telefonica.txt";
while (<ARQ>) { print if /Torvalds/ };
close ARQ;

simples e claro, como muitas pessoas não podem acreditar que Perl é capaz... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Já que não pude evitar o flame...: sim, principalmente do programador...

Engraçado... Sou conhecido onde trabalho por resolver em um ou dois dias, com Java, problemas que outros programadores levam semanas com outras tecnologias (e faço com elevada manutenibilidade).

Acho minha performance bastante boa, e devo ela à plataforma em que trabalho. Ela me permite fazer qualquer coisa rapidamente simplesmente combinando APIs.

sim, e a coisa tá piorando e a linguagem está ficando tão barroca e poluída quanto papai C++...

Vou pedir a quem ler isso para ler e comparar códigos das duas línguagens. Só isso.

sim, linguagens definidas por corporações não cheiram bem...

É uma linguagem inventada por uma equipe que desfrutou de extrema liberdade dentro de uma corporação (Green Project).

Ela é definida por uma comunidade de desenvolvedores muito maior que qualquer uma das outras tecnologias concorrentes. Acho que é isso, em última instância, que te aborrece, não? É chato pregar sozinho na multidão...

esconder isso em operadores simples e integrados à linguagem

Sobrecarga de operadores, defines, diretivas de compilação e toda essa tralha que torna esotéricos os códigos em C++.

E ainda tem performance bem superior... :)

O ganho de performance (quando há), não compensa a dificuldade no gerenciamento da memória e a portabilidade inferior. Sem falar na produtividade (uma das equipes aqui que leva surra dos javeiros nesse requesito é o pessoal do C++... Sem flames, por favor, estou falando de uma equipe isolada) :)

sim, se fosse daqui eu poderia mandar uma bomba pra sede e acabar com isso de vez...

Eu tenho certeza de que vc. gostaria... :) É o único modo que te sobra pra lidar com a concorrência.

Python bate Java em performance

Mentira muito cabeluda mesmo.

vc realmente acha mais fácil um novato guardar na cabeça as imensas APIs java do que aprender uma noção sobre funções anônimas e como combinar, receber e retornar funções como outro dado qualquer?... além da sintaxe rebuscada e cada vez mais complexa de java?...

Acho. Não precisa guardar na cabeça, as APIs do Java estão claramente documentadas da forma mais inventiva e eficiente que já foi inventada (javadoc). Aprenda a navegar nela e terá Java na palma de sua mão.

Recursos como continuações, lambda e outros exigem do aluno elevado nível de abstração. E, sinceramente, na prática as ocasiões onde esses recursos ajudam são mínimas. O que termina fazendo com que um programador use funções anônimas só pelo prazer de usar o recurso, prejudicando a legibilidade.

Java é feito de classes, seus atributos e métodos. Saiba lidar com isso e conseguirá fazer tudo.

Tem gosto pra tudo mesmo. Mas não use falácias para sustentar os seus. Enquanto eu estiver aqui, sua cruzada contra Java sempre vai dar em água.

Hã...: Lamda é opcional

Hã...

O correto é "lambda".

Em Java você é obrigado a:
1 - Usar a "simples" API
2 - Declarar tudo
3 - Usar classes

1- Simples, pq se constitui de classes, atributos e métodos. Apenas isso e nunca diferente disso.

2- Se vc. quer comunicar uma intenção, não pode usar meias-palavras. Declarar tudo sim, e o bom de tipos estáticos é isso.

3- Exato. Classes. Nada mais, nada menos, nunca diferente. Estruture e modularize, ou não escreva.

[]s

:): Finalmente encontro alguém tão cismado com Java quanto eu.

Mas um ponto temos de reconhecer: A difusão de java de certa forma aumentou muito a cultura de orientação a objetos.

Quam sabe java seja a preparação para o futuro domínio de python :P
[]'s
- Walter

:)): Se ela servir como um exemplo a ser reproduzido, fique à vontade.

Competência, comunidade e padrões abertos são as palavras-chave do sucesso do Java. Trabalhe pela sua tecnologia tanto quanto trabalhamos pela nossa e o futuro será bom para ambos.

[]s

e as comparações terminam por aí!: "A difusão de java de certa forma aumentou muito a cultura de orientação a objetos."

e isso é bom, porque... ???

ok, só sendo chato... ;)

pelo menos, POO forçou programadores a modularizar e encapsular seus códigos...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Dúvida.: Me engano ou tem um pouco de ranso contra programação orientada a objeto neste seu comentário?

O negócio é só o Java ou OO também te incomoda?

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

+ 98 cents: 1) vc esqueceu ( de propósito? ) que precisa declarar toda uma classe e um método static void main em torno de seu código.

Depende de onde ele quer rodar o código. Por isso suponho que ele abstraiu essa parte.

Não precisa declarar uma classe, basta pôr o ponto de entrada da aplicação (main() para console, init() para applets, etc.) na classe da sua escolha. Mas é aconselhavel uma classe separada mesmo, ao invés de se render ao desleixo típico de programadores de scripts.

2) vai jogar um arquivão todo em memória? falta de consciência com recursos e performance é bem típico de programadores java, tsk, tsk!

Não estava sendo discutido tamanho do arquivo ou escalabilidade, mas se é pra ser escalável, creio que um código melhor seria (poderia ser mais compacto, mas assim fica mais claro e didático):


public void printFileToConsole(String filename)throws IOException{
FileChannel fc = new RandomAccessFile(new File(filename), "r").getChannel();
MappedByteBuffer buffer = fc.map(FileChannel.MapMode.READ_ONLY, 0, (int)fc.size());
byte[] content = new byte[1024];
while(buffer.hasRemaining()){
buffer.get(content);
System.out.print(new String(content));
}
fc.close();
}


O exemplo usa a API java.nio (J2SE1.4+), que dá acesso à primitivas dos SO atuais (seja lá qual SO for) para I/O, muito mais rápidas.

O MappedByteBuffer usa a técnica de mapeamento de memória. Parece um Buffer em memória, mas na verdade é um pequeno cursor apontando para o arquivo. Vc. pensa que está lendo da memória, mas está lendo do disco.

Como o FileChannel é não-bloqueante por natureza, eu poderia abrir o arquivo com acesso de leitura e escrita (o que não foi feito) e escrever no buffer a vontade, enquanto leio, sem que uma operação bloqueie a outra.

simples e claro, como muitas pessoas não podem acreditar que Perl é capaz... :)

Perl brilha no acesso simples (não escalável) a arquivos e expressões regulares. Em compensação, só é bom pra isso mesmo... :/

Ta ficando bom.: Python bate Java em performance
Mentira muito cabeluda mesmo.

Agora tá ficando bom. Alguém se habilita a gerar testes de performance. Códigos que fazem a mesma coisa escritos nas duas linguagens.

Acho que assim a gente para de bater boca com aquela estória do Stallman.

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Discussão infrutífera: Eu gostaria de pedir aos colegas que trabalham com Python e que costumam participar da PythonBrasil a não ficar discutindo sobre Java por aqui e não provocar flamewars desnecessárias.

Todos nós, desenvolvedores Python, sabemos das inúmeras vantagens que Python apresenta sobre uma grande quantidade de linguagens e também sabemos (ou deveríamos saber) de seus problemas para que ao invés de desperdiçar tempo tentando mudar o imutável aproveitá-lo para melhorar a nossa ferramenta de trabalho favorita.

A fase de chocar os programadores Java já passou. Muitos deles já estão procurando alternativas melhores em linguagens como Ruby e Python (só pra citar 2 exemplos) e por essa razão eles precisam ficar apelando para o tipo de expediente usado aqui: anunciar pela buzilionézima vez que eles 'vão abrir o código da VM deles'.

Isso parece aquela história onde uma 'celebridade' diz que se separou do marido para voltar com ele 48hs depois só para a imprensa dar atenção para eles.

Vamos deixar os programadores Java programando em Java, os programadores Ruby programando em Ruby e vamos voltar a programar em Python que é o melhor que podemos fazer. Os resultados obtidos é que demonstram a superioridade de uma ferramenta e não blablabla inútil que, em muitos casos, mostra a imensa ignorância dos interlocutores sobre os assuntos tratados.

Ao invés de ficar aqui falando que Java é ruim vamos melhorar o {python,ruby,lisp,scheme,haskell} que todos certamentes ganharemos mais pois, afinal, atualmente não é possível melhorar certas partes da plataforma deles porque simplesmente não existe um código fonte disponível.

--
Osvaldo Santana Neto (aCiDBaSe)

cara: infelizmente, hoje não vou responder a vc. já estou meio cansado de discutir com um cara lá no slashdot. Se quiser dar seu pitaco por lá, blz! ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

RE:: A vantagem é domínio sobre o código fonte do aplicativo e a vantagem de sempre poder desenvolver o melhor aplicativo pois ela detém a receita, é que nem tentar copiar a coca-cola mas nunca é igual

Se vc. está falando do código da JVM:

* A tecnologia de construção de máquinas virtuais é amplamente conhecida, já utilizada antes do Java e é um assunto acadêmico, até. Existem inúmeros projetos de JVM, assim como outras VM comerciais (JRockit) até melhores do que a da Sun, para seu governo. A especificação da JVM é um padrão aberto e disponível publicamente.

A CLR do .NET é que infelizmente ainda é uma adaptação porca da JVM 1.1 com GC incremental que eles ganharam de um antigo licenciamento, pq a M$ tem preguiça de fazer algo melhor.

Se vc. está falando das Core-API:

* A especificação das APIs também é aberta e pública. E graças à licença de pesquisa, vc. pode ler o código oficial e escrever seu código baseado nesse conhecimento.

Vc. pode fazer "coca-cola" igual ou melhor. Se quer fazer pior, problema seu.

e na verdade o cara nem sabe porque escolheu o java para o desenvolvimento (o empresário)

Se esse empresário não tem skill ou consultoria suficientes para não saber pq escolheu o Java, então ele também não vai saber como escolher qualquer outra coisa.

O que falta para o Brasil é consultorias de verdade, que não existem.

Eu mesmo conheço várias consultorias excelentes que poupam muito dinheiro dos seus clientes corporativos todo ano (principalmente de licenças).

o Java que veio com o marketing de "compile once, run everywhere" e todos sabem que não é verdade

Durante mais de 10 anos de experiência no mercado corporativo, nunca cheguei a uma situação onde isso não fosse verdade. "Todos sabem"... De quem vc. está falando?

Tem empresas apoiando um genérico feito sob marca "Apache"

O Apache Software Group é um dos expoentes em produtos livres, não limitado a Java. Ele contribuiu e contribui todos os dias com SL. A IBM é apenas um dos seus investidores. A ASF deu ao Linux o mais usado servidor web no mundo, responsável por dar uma surra na M$ no mercado de servidores já a alguns bons anos.

Existem outros grandes centros de CA e SL em Java. Como a ObjectWeb, que tem o próprio governo francês como principal investidor.

Tenho vergonha dessas consultorias de meia tigela que só fala em Java, é uma vergonha.

Tem um erro de concordância nessa frase... Vc. viu isso, né?

E a sua consultoria, fala em quê? Quais são os números da sua eficiência? Quais são as suas histórias de sucesso? Vc. parece ansioso para nos mostrar, faça isso.

[]s

apenas: não retirem a frase do contexto, ok? eu comparava a performance de python à do programador...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Entrevista com o Troll: * O software que é preciso ter instalado para se executar um programa em Java (runtime) é enorme.

15.99Mb, na última versão (1.5.0, update 6). Enorme?

O próprio programa (.jar) é enorme em comparação com o tamanho que teria se fosse escrito em outras linguagens.

Tamanhos típicos:

O Memoranda É meu scheduler "de cabeceira". Tem funcionalidades de agenda eletrônica, acompanhamento de projetos, edição de HTML, integração com progs externos, etc.

O Jar principal tem 620Kb. As várias dependências (a maioria opcionais), somam 1.40Mb. Se vc. compactar tudo, cabe em um disquete.

O HSQLDB é um gerenciador de banco de dados relacional totalmente ACID, suportando um rico dialeto SQL padrão, stored procedures e inúmeras outras features não encontradas em produtos nativos equivalentes (MySQL).

O jar da atual versão tem cerca de 610Kb, contendo o RDBMS, o driver JDBC e algumas ferramentas básicas de administração. O download completo tem cerca de 3Mb.

Em contrapartida, o MySQL (nativo) tem um download de 62.9Mb, na última versão.

Conclusão: sua afirmação é mentira. E é mentira pq aplicações em Java compartilham as bibliotecas core do Java instalado na máquina.

Java é complexa demais.

Depende do que vc. considera complexo.

só que C é muitas vezes melhor (mais leve, mais rápida, mais portável, mais difundida, etc.)

C é mais portável que Java? Não me faça rir...

C é mais difundido que Java? Eu conheço uns 20 programadores profissionais em C e mais de 500 programadores em Java (muitos dos quais eu mesmo formei) trabalhando nas empresas em que presto serviços.

Java é muito lenta e inchada pra tomar o lugar de C

Então pq Java já está tomando o lugar de C em aplicações de alta performance como bancos de dados e sistemas de billing (já trabalhei com vários deles)?

muito complicada e pentelha pra tomar o lugar dos scripts

Ao contrário, os scripts é que têm se mobilizado para concorrer com Java. Em resposta, a plataforma Java também suporta linguas de script (atualmente Groovy e ECMA-Script, através da API javax.scripting).

Java é vendida como uma linguagem multi-plataforma e/ou portável, mas quando se leva o programa para outra plataforma, sempre tem um monte de coisa que não funciona

Depende dos programas que vc. está analisando. Os programas que eu faço sempre foram 100% portáveis entre plataformas (e isso é uma vantagem estratégica onde trabalho). E a grande maioria das aplicações SL ou CA que utilizo também é.

Em casa, meus programas em Java (quase todos) ficam em uma partição FAT. E eu uso a mesma instalação tanto no Linux quanto no Windows.

Claro, se vc. programa amarrando à dependências (o jeito errado), seu aplicativo vai ser dependente.

Os widgets em Java são horrorosos. Se for pra trabalhar com aquilo, prefiro Tcl/Tk, que têm todas as qualidades que tem Java, mais algumas outras, e nenhum dos defeitos.

Comentário que demonstra falta de conhecimento do que está falando. Aprenda sobre Swing e PLAF antes de conversar com a gente. E Tcl/Tk, tem todas as qualidades de Java? Cite.

Java é lenta.

Um mito sem-vergonha que os inimigos da plataforma já não podem mais explorar.

TODO site que usa Tomcat e/ou termina em .jsp fazem minha banda larga parecer linha discada.

Só se for a sua. A minha vai bem, obrigado.

O consumo de banda está diretamente relacionado com a quantidade e o tipo dos dados trafegados. Em um acesso a uma página jsp, servlet, PHP, asp, perl, etc. Os dados trafegados são texto puro, igualmente.

Por aqui os aplicativos web que fazemos sofrem os mesmos testes de performance a que são submetidos qualquer outra aplicação na empresa, feitas com qualquer tecnologia, com os mesmos critérios. Não temos dificuldade em fazer as aplicações em Java passarem nesses testes.

Quase todos os programas feitos em Java que eu já vi eram absolutamente toscos. E lentos.

Vc. precisa pegar seus programas em fontes melhores... Não é difícil.

Existem várias versões de Java por aí. Evidentemente, incompatíveis entre si.

Hã? É claro que não. Mais desconhecimento e desinformação. Acredito que todo mundo saiba que isso não é verdade, certo? Se alguém tiver alguma dúvida é só falar que eu explico.

Java é uma grande criadora de empregos. Exige 20 programadores para desenvolver o que em outras linguagens bastaria 4.

Não condiz com a realidade. Por aqui, temos apenas 4 programadores Java, a menor e mais eficiente equipe.

A verdade é a melhor defesa contra a desinformação.

Cada um na sua praia: O dia em que os programadores Python se derem conta de que o futuro de sua linguagem está relacionado a seu próprio trabalho, e não ao combate ostensivo (e, por vezes, irresponsável e desinformado) a outras tecnologias como Java será um grande dia para sua tecnologia.

Ao invés de torcer pelo fracasso do Java, comecem a trabalhar pelo sucesso da praia de vocês.

A comunidade Java chegou onde chegou com trabalho árduo, e não escrevendo em todo lugar que C++ era ruim. Sugiro que sigam o exemplo.

atualmente não é possível melhorar certas partes da plataforma deles porque simplesmente não existe um código fonte disponível

Estou participando da lista do projeto de JVM Apache Harmony e é exatamente isso que está sendo feito.

Participo do grupo que está desenvolvendo as core-apis e é a comunidade a responsável por quase todas as inovações disponíveis no J2SE6.0.

Mentira: Não.

Vc. disse "tanto a performance do programador quanto a da máquina".

disse-me-disse: "Tanto C++ quanto Python batem Java em performance, seja a da máquina, seja a do programador."

desculpem se não deixei claro suficiente, mas quis dizer que ambos batem java em performance ao seu modo, na de máquina, no caso de C++, e na do programador, no caso de Python...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Ou seja...: Vc. precisa ser mais "verborrágico" ao falar... Ou se arrisca a não ser compreendido. :)

Ou seja... Novamente Vc. está usando uma linguagem nativa para dizer que Java é mais "lenta" ao executar e uma linguagem de script para dizer que Java é "lenta" para desenvolver.

Vc. parece esquecer (de propósito?) que Java é mais rápida para desenvolver que C++ e mais rápida na execução do que o Python.

Sua comparação é furada. Basta inverter os termos.

Uma vez conversei contigo a respeito disso e vc. deu a entender que Java tinha a "obrigação" de ser mais rápida que o C++ para rodar e mais rápida para desenvolver que o Pyhton ou Ruby.

Lamento, mas vc. já ouviu falar de Lavoisier?

Bem, mesmo reconhecendo essa lei, Java trabalha para tornar-se tão rápida quanto o C++ (utilizando otimizações no JIT) e já conseguimos muitos resultados positivos. Na verdade o C++ não é o alvo, apenas trabalhamos para tornar os nossos programas mais rápidos.

..."e já conseguimos muitos: ..."e já conseguimos muitos resultados positivos"

Uau, você trabalha no time de desenvolvimento da JVM na Sun?

:-) calma...: Uau, você trabalha no time de desenvolvimento da JVM na Sun?

Não exatamente, não é preciso. :)

Quando digo "conseguimos" digo nós: a comunidade.

Ao contrário do que se diz por aí, a comunidade Java, os programadores, têm acesso sim e podem influir no futuro de sua tecnologia.

Estou junto com o pessoal que está desenvolvendo a implementação do Mustang (J2SE6.0), que já tem o beta disponivel e terá versão final em meado desse ano. Qualquer um pode acessar os fóruns e contribuir com código (mediante aprovação do time), ou revisar o código existente (o que é mais freqüente) incluindo você mesmo.

Veja o site do projeto em https://mustang.dev.java.net/

A maior parte do projeto é sobre as core APIs, mas tem um pessoal que faz otimizações que dependem de mudanças na JVM.

Uma contribuição razoavelmente simples de dar é o teste de regressão. Pegar as aplicações Java que vc. já usa hoje e executá-las na nova versão. Se não rodar, reportar os detalhes da quebra de compatibilidade ao time atraves do bugtrack.

Outro caminho para participar do desenvolvimento do Java (dessa vez diretamente nas especificações das tecnologias "periféricas") é se inscrever no JCP. A inscrição de pessoas físicas é gratuita. Se vc. conseguir destaque, pode até ser escolhido para fazer parte de um "Expert Group".

No fundo, é como participar de qualquer projeto livre em um repositório organizado. Se vc. submete código, ele será cuidadosamente avaliado antes de ser incorporado.

Não é à toa...: Não é à toa que as "fábricas de software" tem esse nome.

Afinal, elas são lotadas de programadores Java.

Peão trabalha é em fábrica mesmo.

discordo: Discordo, mais uma vez.

Sim, também já trabalhei e elas existem para todas as tecnologias.

Dificilmente existe a associação de desenvolvedor (java ou não, corporativo ou não) ao termo "peão". Aliás, as empresas estão contratando "desenvolvedores" e não "programadores".

Um pouco sobre o dia-a-dia de uma fábrica de software (do tipo que funciona):

1) O Analista de Requesito analisa o problema e prepara uma Especificação Funcional.

2) Em face da EF, os desenvolvedores avaliam a viabilidade e os detalhes dependentes de tecnologia e preparam uma Especificação Técnica.

3) A Especificação Técnica é aprovada pelo líder de projeto e pelo cliente. Geralmente os mesmos desenvolvedores que prepararam a ET se encarregam da implementação.

4) A implementação é encaminhada para a equipe de teste. As falhas encontradas são submetidas para os desenvolvedores para correção, e o processo se repete até que a qualidade requerida seja alcançada.

Como vc. pode ver, o desenvolvedor é o responsável não apenas por programar, mas fazer todo o levantamento necessário e fornecer soluções para que a implementação se torne possível.

Esse processo todo pode ser um pouco burocrático. Por isso, muitas equipes de fábrica estão adotando processos como o Extreme Programing e a Modelagem Ágil para melhorar seu trabalho.

Vc ainda está na matrix, um: Vc ainda está na matrix, um dia vai acordar.

Só posso pensar que você: Só posso pensar que você menospreza o peão de fábrica (de software ou não). Só posso lamentar seu preconceito.

--
Direito de escolha combina com software livre. (Augusto Campos)
JID: emerson.pardo

Minhas olheiras aumentaram: Minhas olheiras aumentaram uns 5cm de tanta preocupação =(

operários estúpidos!: ei, Copérnico. não sou eu não, viu?

mas ele está certo: o que mais tem por aí hoje são peões utilizando das ferramentas de fácil uso desenvolvidas por programadores de infraestrutura de verdade, ganhando bem nas M$, Adobe e Suns da vida, ou como hobby em projetos livres. Estes sim são desenvolvedores de verdade, com formação em Ciência da Computação.

É deprimente lá no trabalho ter que tolher minha criatividade e ficar em um copiar-e-colar estúpido de templates e padrões ridículos pq o processo de construção de software precisa ser nivelado por baixo para que meus colegas menos capacitados possam acompanhar o raciocínio...

tenho voltado meu talento pra programação na linguagem de descrição de cenas do povray. mero hobby, só no meu tempo livre. mas ali, posso dar asas à imaginação como não posso no frustrante trabalho boçal e braçal... bem, tirando meu projeto de criação de uma AI que me substitua no ambiente de trabalho e faça o trabalho por mim, nem é preciso uma AI tão inteligente assim... :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Nemesis, o modelo de: Nemesis, o modelo de negócios das fábricas de software de hoje em dia é baseado apenas numa coisa:

Mão de obra barata.

Hoje é facílimo ter uma fábrica de software. Todo ano saem centenas de formandos dos cursos superiores de computação, e o que eles viram no curso inteiro? Java! E o que essa garotada precisa DESESPERADAMENTE? Experiência!

Junta essas duas coisas, frameworks totalmente integrados, prazos no limite, salários baixos (profissionais desmotivados, afinal grana é a única motivação que interessa pra gente que tem contas a pagar), e vc tem uma bomba.

O problema maior nao é nem a linguagem, q em si só já é uma merda. É que essa linguagem virou tipo uma doença hereditária da programação, onde a garotada já sai das faculdades totalmente viciada nesta joça, e os contratadores APROVEITAM.

Desenvolver software é um processo eminentemente criativo. Não existe mais criatividade no processo de desenvolvimento de software nessas fábricas, pq virou linha de montagem. Exatamente como o p?oprio nome "fábrica" se propõe.

Resultado: software ruim, depuração MUITO dificultada, performance baixissima (já que é muito dificil saber se o gargalo está no seu código ou nos frameworks Java, que são na grande maioria um monte de lixo), etc.

Vai pintar uma pá de gente dizendo que essa lógica é errada, que existem N processos e metodologias, vão dizer que "só as fábricas que eu conheço são assim, a minha faz o melhor software do mundo" e blábláblá e etcetera. A grande verdade é que a grande maioria dos softwares desenvolvidos nessas fábricas é feito a toque de caixa e de baixíssima qualidade. Acompanho o mercado e estou vendo que o processo de desenvolvimento de software está saindo do ambiente controlado das fábricas e indo direto pro ambiente do cliente, via outsourcing.

No falecido PontoBR eu me envolvi em discussões que chegavam às centenas de comentários sobre como o processo de desenvolvimento das chamadas fábricas de software é maléfico. Mas cansei de dar murro em ponta de faca, nego acredita nisso por uma questão de fé. Hoje em dia não tenho mais paciência para isso. Meu argumento se resume hoje a dizer que quem acredita mesmo que o modelo atual das fábricas de software javistas que aparecem por aí às dúzias por um real funciona DE VERDADE, está totalmente fora da realidade, ou é completamente estúpido. Ou os dois.

Além do mais...: ... qualquer um que ainda não esteja na matrix sabe que Python é a melhor linguagem de programação de propósito geral. :)

Pessoas: ei, Copérnico. não sou eu não, viu?

Mon Dieu, são os pseudo-Neos dando cria! :P

mas ele está certo: o que mais tem por aí hoje são peões utilizando das ferramentas de fácil uso desenvolvidas por programadores de infraestrutura de verdade, ganhando bem nas M$, Adobe e Suns da vida, ou como hobby em projetos livres. Estes sim são desenvolvedores de verdade, com formação em Ciência da Computação

Na comunidade Java, são desenvolvedores usando ferramentas e frameworks livres ou CA, escritos por desenvolvedores iguais a eles em projetos 90% mantidos financeiramente por empresas. Essas ferramentas e frameworks são escritos com o único propósito de não reinventar a roda e, em momento nenhum, substituem o skill dos desenvolvedores. Se vc. não entende o problema abordado, nem a forma como ele é resolvido pelo framework, vc. não consegue usá-lo direito (como seria de se esperar).

Claro, existem sim, "programadores" que usam ferramentas e APIs como muletas e não entendem como elas funcionam. Mas esses são profissionais de segunda classe que cedo ou tarde acabam sendo engolidos e saindo do mercado.

A filosofia OOP "rouba" da filosofia Hacker o seguinte conceito: Temos que resolver problemas novos, ao invés de resolver os mesmos problemas velhos de novo e de novo...

Agora, quanto a "tolher sua criatividade":

No mundo real, vc. lida com pessoas igualmente criativas e capazes (na melhor das hipóteses).

No entanto, é preciso lembrar que elas não pensam com a sua cabeça e suas idéias "brilhantes" podem não ser tão óbvias para elas do que são pra você.

É preciso lembrar também que elas têm um prazo para entender o que vc. faz e reagir de acordo.

Ou são pessoas capazes em suas áreas, mas não necessariamente em seu nicho específico.

Você, usando seu código, precisa se comunicar com essas pessoas. Para isso, são necessários padrões de comunicação. E esses padrões precisam exibir alguma sanidade.

Usar os miolos e penetrar na beleza de algoritmos é maravilhoso, mas ter que fazer isso, sem tempo disponível, para cada funcionalidade em um projeto é irritante. Da mesma forma que exibir sua maestria na linha de comando em algum SO cada vez que tiver que procurar um arquivo é ridículo.

Hoje em dia, desenvolvimento de software é uma tarefa de comunicação, muito mais que de genialidade. Se não vc. cria "Máquinas de Babbage", maravilhosamente inteligentes e criativas, mas que nunca ficam prontas.

Nas equipes que já tive oportunidade de comandar, ensino à galera que ninguém usa muletas ("profissionais" que fizeram cursos de Eclipse :-P ). Ou sabe Java de verdade ou não sabe. Quem não sabe tem a oportunidade de aprender com os colegas. Quem não aprende, cedo ou tarde está fora, ou vai ficar "de castigo" fazendo code-review pelo resto do projeto (de repente, revisando, ele aprende alguma coisa).

Nas equipes que eu não tive a oportunidade de comandar, cedo ou tarde eu estou fora (quando a qualidade da coisa piora muito). E aí, quando me ligam pra resolver aquele problema que ninguém por lá consegue, eu sou sincero e respondo:

"- O seu pessoal não tem skill para trabalhar com isso, não adianta explicar por telefone. Contrate gente melhor".

Caramba!: O que vcs acham do estilo do layout dos replys? Fica um bom exercício de leitura, não?

:): Hah.

Engraçado essa.

Cria-se um mito, associa-se uma idéia a esse mito e se joga para as pessoas mastigarem.

"Python é bom pq é a linguage dos Réquer"...

É totalmente dinâmico e por isso lento pra caramba, não é inteiramente OO, etc.

M41s é 4 língu4 duz ráquer. Python rulezzz!

Eu, sinceramente, esperava melhores argumentos. Já ouvi melhores.

Não é pq é a linguagem: Não é pq é a linguagem dos "ráquer".

É pq tem um conjunto de vantagens que tornam o processo de desenvolvimento de software muito mais prático, sem precisar de burocracia de código.

Ráquer não usa linguagem com estrutura de dados de alto nível prontas, faz as dele.

Programar em Java é o equivalente a requisitar alguma coisa em uma repartição pública: vc tem que ir à repartição (carregar JVM), preencher pilhas de formulários (descritores XML), entregar N certidões (declarar classes e interfaces) para ter de volta algo que com uma empresa privada (Python) só precisaria de um telefonema.

E Python não é totalmente dinâmico. Python tem tipos sim. Vc só nao precisa declará-los se não quiser.

Eu gostaria muito de ver um benchmark confiável entre aplicações idênticas nas duas linguagens, pq a minha experiencia com software Java e Python mostra que as aplicações Python tem desempenho visivelmente melhor, em absolutamente todas as áreas: desde processamento de gráficos a análise de volumes de texto na ordem de quase 1 TB (logs de sistemas de billing de empresas de telefonia), até a programas gráficos para uso comum desses que se encontra no freshmeat.

Não sou o Nêmesis, mas vamos discordar da discordância: Mão de obra barata.

Desenvolvedores Java (ao menos são contratados como tal) ganham no mínimo 25 pratas a hora. Profissionais realmente experientes ou dedicados ganham mais de 40. Levando-se em conta que os menos experientes levam mais horas para resolver seus problemas, essa mão de obra é tudo, menos barata.

Não sou um grande fã do modelo de fábrica (principalmente aquele que não dá certo, ou seja, aquele no qual os implementadores nada sabem do que está realmente sendo construído). Mas, trabalhando de forma correta, é possível fazer até mesmo esse modelo lamentável funcionar.

centenas de formandos dos cursos superiores de computação, e o que eles viram no curso inteiro? Java!

Mesmo que eles só vissem Java, o que eu duvido, esta está longe de ser uma "plataforma muleta". Eles obrigatóriamente tiveram de ser expostos a técnicas e protocolos que vão além de uma palataforma específica, tiveram que lidar com diferentes SO (pq Java é multiplataforma). Quase todo mundo que programa em Java sabe o que é Unix, Linux e MacOS (quem não sabe deveria desistir e fazer cachorro-quente).

É melhor hoje do que antes do Java se tornar popular, quando as faculdades cuspiam centenas de "arrastadores de componentes" VB ou Delphi (e ferramentas semelhantes) para alimentar as fábricas amadoras do mercado. São essas mesmas pessoas que hoje amaldiçoam Java pq tentaram arrastar e soltar componentes no Netbeans e não conseguiram.

Sim, quando vc. mistura mão de obra não qualificada com prazos escorchantes e luta exagerada por lucro vc. tem uma bomba. As bombas estouram. E os pagantes aprendem.

Desenvolver software é um processo eminentemente criativo

Ainda é, mas certamente não é o valor principal. Comunicação é o valor principal. Sem ela, não se faz nada. A época do "talento individual" acabou.

Resultado: software ruim, depuração MUITO dificultada, performance baixissima (já que é muito dificil saber se o gargalo está no seu código ou nos frameworks Java, que são na grande maioria um monte de lixo), etc.

O software com que trabalho é bom (sem estourar na mão do cliente mais tarde), sofre testes de performance na homologação, eu nunca preciso depurar (se eu vejo algum "pupilo" depurando um programa eu pergunto se ele nunca pensou em ter outro emprego), se algum problema é detectado em um framework livre nós corrigimos o código do framework e recompilamos (e dizer que é um monte de lixo o trabalho dos outros é fácil... me mostra um "bom" framework que vc. fez para comparar), etc.

"A minha faz o melhor software do mundo" não, faz software competente e de qualidade, o que é suficiente. E quando vc. trabalha direito e sabe aceitar e recusar prazos, vc. cumpre seu objetivo no tempo.

No fim, não importa se é fábrica, centro de pesquisa, templo budista ou coisa que o valha. Existem amadores e existem profissionais.

E existem aqueles que nunca na vida cumpriram um projeto com a qualidade e o prazo desejado. Eles andam por aí dizendo que é impossível fazer, justificando seu fracasso e dizendo que quem faz está fora da realidade ou é estúpido.

P.S.:

No falecido PontoBR

Espero que vc. não venha a fazer isso aqui também, ninguém aqui quer que o Linux-BR tenha o mesmo destino! :P

ganham no mínimo 25 pratas: ganham no mínimo 25 pratas a hora.

Na boa velho, vc acha isso um bom valor?

Tá brincando né.

Quase todo mundo que programa em Java sabe o que é Unix, Linux e MacOS

Mas a grande sacada do Java não era que os programadores não precisavam se importar com a plataforma? E aí?

eu nunca preciso depurar

Parei de ler seu post aqui.

Está completamente óbvio que você não trabalha com software, nunca liderou absolutamente nenhuma equipe, e nunca participou de projeto de software nenhum, grande ou pequeno.

Com base nesta única frase atesto que o resto do seu post, e por consequência todos os outros, não passam de um monte de estrume.

Software NUNCA deixa de ser depurado. Software SEMPRE tem falhas. NAO EXISTE software sem bugs. Ainda mais aquele feito por mais de uma pessoa. NEM O DONALD KNUTH faz software sem bugs.

Não existe esse software que você entregue como um produto fechado numa caixa, igual sucrilhos, e diga: está aqui, tá pronto, não precisa depurar pq não tem falhas.

Qualquer pessoa com no mínimo dois neurônios funcionando sabe que isso é lenda.

Ráquer vs. Hacker: Ráquer não usa linguagem com estrutura de dados de alto nível prontas, faz as dele.

Acredito que a palavra que vc. quis usar seja "Hacker". Hackers fazem isso. Réquers dizem que fazem.

para ter de volta algo que com uma empresa privada (Python) só precisaria de um telefonema

E, se o dono da empresa for atropelado logo depois, ninguém será capaz de saber o qual foi a idéia inicial, se a pessoa do outro lado da linha não entendeu direito.

Linguagens dinâmicas de script, além de serem lentas (é, você ouviu: lentas), ajudam a proliferar a praga de sistemas escritos "nas coxas", esotéricos, mal estruturados e mal documentados.

E Python não é totalmente dinâmico. Python tem tipos sim. Vc só nao precisa declará-los se não quiser.

Ou seja, na prática ninguém declara quase nunca. É um vício em um tipo de linguagem que aceita vícios.

Eu gostaria muito de ver um benchmark confiável entre aplicações idênticas nas duas linguagens

É fácil achar um benchmark em que vc. confie. É aquele que disser que Python é a mais rápida de todas. :)

Quem é experiente em Python sabe os problemas que a plataforma enfrenta hoje em dia. Deveria estar trabalhando para resolver (como nós fazemos), ao invés de ficar criando fumaça.

Eu, basicamente, nunca vi um benchmark onde Python superasse Java ou C++. Vamos fazer o seguinte, pq quero ser justo. Indique um aplicativo em Python simples, que eu possa reescrever em java sem muito trabalho, mas que possa lidar com grande volume de dados e vamos fazer um benchmark pra publicar aqui no portal, com screenshots.

É um vício em um tipo de: É um vício em um tipo de linguagem que aceita vícios.

Que vício, criatura? Se vc está trabalhando com aquele tipo como retorno de um método, se a variável que recebe aquele retorno é setada pra aquele tipo específico, PRA QUÊ CARALHO eu vou declarar aquele tipo se o contexto dele é óbvio?

Qual a diferença entre eu declarar algo com variavel = int(), ou ter isso daí implícito lá na frente? Se no caso de mais pra frente eu fazer uma operação que só aceita string ou qualquer outro tipo de objeto, eu de qualquer maneira preciso retypear também. A necessidade DO COMPILADOR de eu tipar explicitamente nesse contexto é OBVIAMENTE desnecessária e inócua.

Indique um aplicativo em Python simples

Então tá. Implemente ElementTree em Java e parseie um arquivo XML de uns 20 MB e daqui a uns 100 anos quando o seu programa Java acabar de executar vc retorna.

Ai, ai... É cada um...: Na boa velho, vc acha isso um bom valor?

Sei lá, faz tempo que eu não ganho isso. Mas se eu tivesse que pagar por isso, seria caro sim.

Mas a grande sacada do Java não era que os programadores não precisavam se importar com a plataforma? E aí?

Dãã... Vc. precisa botar seu aplicativo para rodar de alguma forma, certo? Vc. precisa usar o SO onde o sistema roda, né? Vc. precisa usar o shell para criar e apagar arquivos, iniciar aplicações nativas, usar telnet e ftp, certo?

Software NUNCA deixa de ser depurado. Software SEMPRE tem falhas. NAO EXISTE software sem bugs. Ainda mais aquele feito por mais de uma pessoa. NEM O DONALD KNUTH faz software sem bugs.

Ai, ai...

É assim que eu não depuro, olha:

Softwares sempre têm erros, isso está certo. Erros são detectados em testes automatizados. Já ouviu falar? Eu uso um framework chamado JUnit - que na certa é grego pra você - e escrevo os testes antes de escrever a funcionalidade. Isso se chama TDD (Test Driven Development - desenvolvimento orientado a testes), procure no google. Além de testar a funcionalidade da sua classe, o código de teste é um excelente exemplo ou documentação de como ela funciona.

Quando um teste pega um erro, vc. pode exibir o número da linha e até fazer dump da pilha de execução (um simples Thread.dump() expresso na classe de teste resolve), além de exibir o valor das variáveis locais (as quais, em uma classe corretamente modularizada, têm a obrigação de serem bem poucas). Descobrir onde está um erro dessa forma leva menos de 15 minutos. Após consertar vc. testa de novo, percebe novos bugs possíveis, escreve mais testes e roda o teste de novo...

Quando a equipe de testes (ou o usuário, na pior das hipóteses) descobre um bug, vc. escreve um teste que reproduz a situação e roda os testes de novo.

Sempre que vc. termina uma versão que possa considerar estável, vc. roda todos os testes novamente. Isso pode ser automatizado, se necessário, por uma ferramenta de integração contínua como o Cruise Control ou o Maven.

Passar horas em um depurador executando passo a passo dando watch em todas as variaveis locais é trabalho de minotauro e um sinal patente de amadorismo.

Agora sei o motivo das coisas que vc. disse antes. Vá depurar seus scripts em Python e não me aborreça.

cuidado: Ei, moderei seu coment pq aqui não é o "falecido PontoBR". Não se usam palavrões por aqui, ao menos eu nunca vi nenhum.

Se vc está trabalhando com aquele tipo como retorno de um método, se a variável que recebe aquele retorno é setada pra aquele tipo específico

Para que eu não tenha que consultar o código do método para descobrir o tipo da variável.

Então tá. Implemente ElementTree em Java e parseie um arquivo XML de uns 20 MB e daqui a uns 100 anos quando o seu programa Java acabar de executar vc retorna.

Vc. não entendeu. Passa o endereço de um soft livre (ou seja: código disponível) simples em Python, para que eu possa fazer o download e reescrever em Java.

Falar não adianta. Faça isso.

Perae, primeiro vc falou que: Perae, primeiro vc falou que nao depura, agora fala que escreve testes especificamente pra validar código pra não precisar depurar? E que testes de unidade são substitutos pra depuração? QUE PORRA É ISSO VELHO, VC TÁ CHAPADO???

Testes de unidade não tem absolutamente NENHUMA condição de testar todas as possíveis situações de entrada que um software não-trivial possa sofrer durante seu uso. Isso é completamente inviável. Os testes de unidade não podem provar que um software está correto, apenas que as saídas mais óbvias sejam capturadas pelo teste. Nao existe como um teste de unidade atestar a ausência de bugs. Testes de unidade também não tem condições de detectar problemas de performance. A unica coisa que um teste de unidade pode fazer é validar um conjunto predeterminado de inputs para determinado bloco de código.

Vc já parou pra pensar que seus testes também são código? E que pode haver erro nos testes também?

Porra, com certeza isso nao está no seu livro de XP.

Cara, a cada post fica mais óbvio que vc nunca trampou com software.

%-/: Hã? Estilo de layout???

%-/

Ei, moderei seu coment pq: Ei, moderei seu coment pq aqui não é o "falecido PontoBR". Não se usam palavrões por aqui, ao menos eu nunca vi nenhum.

Ah velho, eu tô pouco me fudendo se aqui se usa palavrão ou não. Escrevi meu post e vc leu, quem se interessar lê também. Quem não se interessar não lê, e acabou. Não escrevo pra entrar num ranking de comentários, escrevo pra passar minhas idéias.

Pode moderar o quanto quiser, não ligo a mínima.

Para que eu não tenha que consultar o código do método para descobrir o tipo da variável.

MAS BICHO, VC NAO TEM QUE LER O CODIGO DE TODA MANEIRA??? Vc nao vai escrever algo que acessa aquele método? CUSTA alguma coisa ler a doc daquele método? E será que vc acha mesmo produtivo escrever DOIS métodos iguais para retornar DOIS tipos de dados diferentes dependendo do input?

Vc. não entendeu.

O que eu entendi é que se vc digitar "ElementTree" no Google e clicar em "Estou com sorte" vai cair direto numa página onde vc pode baixar a implementação Python do container ElementTree.

Nao pode ficar mais fácil que isso.

De novo?: Tsc! Termos de baixo calão de novo. Vou moderar outra vez. Pare com isso, ok?

Testes de unidade não tem absolutamente NENHUMA condição de testar todas as possíveis situações de entrada que um software não-trivial possa sofrer durante seu uso

O objetivo dos testes é pegar isso. Se vc. recebe report de um bug, conserta e não escreve o teste, o bug volta depois de roupa nova. Já aconteceu comigo.

Se os testes de unidade não têm condições imediatas de pegar todos os erros possíveis, tampouco depurar até fica cego vai fazer isso. Se vc. precisa depurar, suponho que haja um erro a ser encontrado, certo? É porque uma funcionalidade não fez o esperado, né? Então vc. sabe a entrada correta e a saída insatisfatória. Escreva o teste.

Testes de unidade também não tem condições de detectar problemas de performance

Sandice. É óbvio que têm. Existe um framework chamado JUnit-Perf, mas eu posso fazer isso facilmente sem ele. Ponha um delta de tempo no início e no final de um teste. Faça o teste falhar se o delta for maior que x. Vc. pode pôr delta de memória também. É trivial.

Vc já parou pra pensar que seus testes também são código? E que pode haver erro nos testes também

(arre...)

Testes são por natureza bem mais simples do que a funcionalidade. Quanto mais simples ("burro", até) um código é, mais confiável. Se seu teste está complicado e vc. acha que precisa escrever um teste para o teste, alguma coisa está errada com o projeto da classe sendo testada. Refatore-a.

Um método de teste típico, em Java, tem umas 6 a 7 linhas, no máximo. Mais que isso é sinal de projeto deficiente.

Cara, a cada post fica mais óbvio que vc nunca trampou com software.

Pra mim, cada post mostra que vc. trabalha errado.

com certeza isso nao está no seu livro de XP.

Para informação de quem lê, vc. não precisa estar usando XP para desenvolver com testes.

Adianta pedir?: Pode moderar o quanto quiser, não ligo a mínima.

Então, talvez dê certo se eu simplesmente pedir pra você não fazer isso? O nível aqui é alto, mantenha assim. Por favor.

CUSTA alguma coisa ler a doc daquele método

Sim. Custa. Mais ainda se no método tiver referência a uma outra variável não-tipada, que vai me levar a outro método, etc.

Nao pode ficar mais fácil que isso.

Escreva... o... link... Pra todo mundo saber que essa foi a implementação que vc. indicou.

Ponha um delta de tempo no: Ponha um delta de tempo no início e no final de um teste. Faça o teste falhar se o delta for maior que x.

Tá certo cara, o seu software é diferente de todos aqueles que existem no mundo real: é um elevador, que só carrega até 700 KG e se carregar muito mais que isso não funciona.

Aqui no mundo real onde existem leis óbvias tipo a gravidade e a existência de bugs em software, entradas em software podem ser completamente arbitrárias. Ou podem ser 5, ou 50, ou 5000, ou 5 milhões. Vc NAO PODE usar testes de unidade para prever quanto tempo leva um teste com entradas completamente arbitrárias. Seu software pode hoje tratar 5 mil registros, amanhã 5 bilhões, e é inviável tratar a performance numa aplicação que escale muito com testes de unidade senão a execução dos testes vai acabar levando mais tempo que a execução do software.

Imagina só: vc tem uma classe que itera num set de dados de, sei lá, 10 mil objetos hoje. Daqui a um ano ou dois ou dez ele vai iterar em 10 bilhões e vc vai ter um PUTA gargalo pq o cálculto do delta do seu teste de unidade que vc fez láááá atrás quando desenvolveu só previu a possibilidade de uso de até 50 mil objetos.

Fala sério, vc desenvolve sistema de padaria né?

Está cansando, isso...: Caramba, vc. não consegue escrever um parágrafo sem palavrões, cara?

Eu estou sendo educado ao me dignar a te responder, não pode retribuir o favor?

Aqui no mundo real onde existem leis óbvias tipo...

...vai acabar levando mais tempo que a execução do software


(arre de novo...)

Vc. faz seus testes de unidade incluindo performance dentro de limites nominais. Para reais testes de stress, existe uma fase diferente pra fazer isso, e outras ferramentas também (loadrunner, Apache JMeter, etc).

Já percebeu que isso nada tem a ver com a depuração que vc. citou? Vc. faz teste de stress depurando?

Fala sério, vc desenvolve sistema de padaria né?

Vc. está lendo direito as informações que estou passando?

Então, talvez dê certo se: Então, talvez dê certo se eu simplesmente pedir pra você não fazer isso?

Claro que não, me expresso da maneira que desejo e quero mais é que o diabo carregue quem tiver algo contra isso.

Sim. Custa.

Porra bicho então vc tem problemas, pq eu entrei na documentação do Python e cliquei no primeiro módulo que vi pela frente, e olha só:

http://docs.python.org/lib/module-calendar.html

Aí tem a documentação desse módulo, especificando exatamente o que é que cada método recebe como entrada e o quê retorna como saída.

Como é que vc sabe o que as APIs de Java fazem sem ler a documentação? Por bruxaria?? Que mandinga é essa q vc faz pra saber de antemão todos os parâmetros e retornos de todas as funções do mundo sem ler doc??

Escreva... o... link...

http://effbot.org/downloads/elementtree-1.2.6-20050316.tar.gz

Olha só, vc clica com o botão direito, escolhe "Salvar link como...". Depois vc escolhe o diretório onde vai salvar o arquivo, e clica nele. Clica em OK tá! Cuidado pra não se perder!

Se tiver dúvidas de como se descompacta procura no Google que vc acha, ok?

Eu tentei...: Claro que não, me expresso da maneira que desejo e quero mais é que o diabo carregue quem tiver algo contra isso.

Agora eu sei pq vc. não se deu bem no PontoBR. Vc. é um troll, não respondo mais você.

Como é que vc sabe o que as APIs de Java fazem sem ler a documentação? Por bruxaria?? Que mandinga é essa q vc faz pra saber de antemão todos os parâmetros e retornos de todas as funções do mundo sem ler doc??

Eu não preciso ler doc para cada retorno de método. Minhas variáveis são tipadas.

http://effbot.org/downloads/elementtree-1.2.6-20050316.tar.gz

Obrigado. :) Eu vou levar pra casa e dar uma olhada. Retorno o código Java digamos, na segunda, ou terça? Até o final da semana informo o resultado do benchmark.

até lá.

Por hora, já chega.

Vc. está lendo direito as: Vc. está lendo direito as informações que estou passando?

Estou sim! Primeiro vc disse que não debuga. Depois disse que escreve testes de unidade para detectar os bugs. Antes disse que os testes de performance são feitos na homologação, depois disse que faz os testes de performance dentro dos testes de unidade.

E sabe o que eu concluí? Que ou vc não está falando a verdade, ou vc trabalha em alguma fábrica de software na Jamaica, escrevendo software pra controlar a venda de discos do Bob Marley, e q a unica metodologia que vc usa é POC (Programação Orientada a Cannabis).

Desculpe,: Sei que é off-topic, mas é o modo como a formatação comprime as respostas em uma palavra por linha ;)

Eu não preciso ler doc para: Eu não preciso ler doc para cada retorno de método. Minhas variáveis são tipadas.

NOSSA CARA, AGORA SIM sei que estou conversando com um verdadeiro GÊNIO da computação!

Vc sabe EXATAMENTE o que é que cada método retorna sem SEQUER LER A DOCUMENTAÇÃO, apenas pq a linguagem que vc usa é tipada!!

Mano vc acabou de inventar a maior revolução da programação de todos os tempos: a POT: Programação Orientada a Telepatia! Basta vc mentalizar os tipos das variáveis e automaticamente o compilador te passa por transmissão astral o que é que cada método faz!

Vc é um gênio, velho! Orgulho dos brasileiros! Escreve um livro, por favor!

C ?: Cada coisa no seu devido lugar...as necessidades do mundo comercial não são as mesmas do mundo do software de base, de alicerce...pelo que já li, o Gnome é feito em C, o KDE em C++...os kernels de SOs em geral são feitos em C...esse não é o lugar para se usar Java ou uma linguagem interpretada, ninguém é maluco...
No mundo dos negócios é construir bancos de dados, criar o sistema de acesso e interação, fazer a contabilidade, ambientes web...acredito que aí está o nicho para java e as linguagens interpretadas
No momento estudo para poder escrever programas que rodem em máquinas clientes (acessando via browser) e controlem leitoras, a que melhor satisfaz as minhas necessidades é Java.
É isso aí...me esforçando para deixar de ser o livro das trevas e me tornar um bom mininu...hehehe

Java... hmmm....: Java é lento dependendo do que você for fazer... trabalhar (excessivamente com arrays por exemplo).

Swing é feia, isso é fato, mas pode-se usar JavaQt pro exemplo :)

Java come MUITA memória, não há como negar, como vi um dia desses em uma discussão sobre Garbage Collector, "Programas com Garbage Collector não evitam memory leak, eles ficam eternamente com memory leak", um ponto de vista interessante... devido ao fato de que em grande parte do tempo seu programa vai ter memória alocada não utilizada (esperando o GC).

A JRE são 15MB's (o arquivo de instalação), mas depois que você instala ela infla que é uma beleza.

Java assim como todas as linguagens tem coisas boas e ruins e não serve para tudo é só saber usar.

Ah! C e C++ é 100% portável, quem fala o contrário é por que não saca absolutamente nada de C e C++. Acho que a única linguagem não portável que conheço é ASM e Java (ver adiante).

Como diz o mestre Bjarne Stroustrup, você compila um programa em Java para a plataforma Java, não para i386, ARM, etc, logo Java ao contrário de C/C++ é absolutamente não portável.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

CUpérnico Prepúcio: Truques manjados: chamar o outro debatedor de troll e encerrar com pose de superioridade, "A verdade é a melhor defesa contra a desinformação."

15,99Mb é o tamanho do _instalador_ do runtime Java. Depois que se instala, fica bem maior. No Windows, Java ocupa 55 Mb. No Linux ele se espalha, não sei bem qual é o tamanho. Mas é grande. Em comparação, o super ultra completo ActiveTcl ocupa 25Mb. Mas quase qualquer programa em Tcl pode ser executado com um simples starkit de 2Mb. Se você enfiar TODAS (por volta de 40) as extensões possíveis nele, não chega a 5Mb.

Existe Tcl rodando em telefone celular. E Java também! Não sei por quê Java no desktop tem que ser tão enorme.

O HSQLDB é peso pena, tem um limite de 8Gb. É desleal compará-lo com o MySQL. Na categoria peso pena, prefiro SQLite (C++) ou Metakit (Tcl).

Você conhece muito mais programadores Java porque:

* É uma linguagem "da moda" alimentada por uma campanha de marketing brutal e incessante desde que surgiu. Em marketing, Java é insuperável.

* Você deve morar no Brasil, onde grandes pentelhices como Flash e Javascript em Web sites são usadas pelo menos 7 vezes mais que no exterior. Brasileiro tem o cacoete de querer pegar e fazer, do jeito que der. Isso é bom. Iniciativa. Mas quase não pensa em qualidade. Nem tem noção de qualidade. Isso é péssimo.

* Você anda em más companhias. :-) Falando sério, se você adora Java, é natural que se relacione com usuários da mesma droga. Eu conheço muito mais gente que mexe com C ou script do que com Java.

* Se popularidade é marca de qualidade para você, você deve ouvir muito Britney Spears, Tati Quebra Barraco, Backstreet Boys, usar Windows etc.

Por que Java já está tomando o lugar de C em aplicações de alta performance como bancos de dados e sistemas de billing (já trabalhei com vários deles)? Várias pessoas já responderam abaixo. Fábrica de software, toque de caixa, redução de custos, nivelamento por baixo. As faculdades não querem ensinar C. Elas querem oferecer o que está na moda e vender matrículas. Pelo mesmo motivo as rádios FM tocam tanta porcaria. E se você trabalha com Java, é natural que seja chamado para trabalhar com sistemas feitos em Java. Daí tem essa impressão de que o mundo está sendo dominado por Java. Existem muitos outros sistemas no mundo. Você não vê porque só transa Java.

Quem vai pular fora agora sou eu. Não estou ganhando nada para discutir com você. Você é muito arrogante e obstinado, entrou num bate-boca sem fim como se sua vida dependesse disso. Sinal claro de imaturidade. Não é só Java que é ruim, quem mexe com Java quase sempre também é um grande chato de galochas. Por isso mesmo conheço tão poucos, graças a deus.

Já sei, você vai me moderar porque eu disse "pentelhices", não vai? Arre! Com a breca! Sossega, leão! Calma que o petróleo é nosso.

Programadores x desenvolvedores: O dono da razão Copernico Vespucio disse:
Aliás, as empresas estão contratando "desenvolvedores" e não "programadores".

Também estão contratando "auxiliares de higienização" e "oficiais de movimentação interna". http://tinyurl.com/7xwnd

não é preciso ser gênio: Acho que o Copérnico quis dizer que ele não precisa de documentação, tudo que precisa é olhar a declaração do método ou coisa parecida, por ex:

private Foo obtemFoo( Bar bar );

Isso lhe dá a entender que é um método que obtem um Foo de um Bar.

é claro, em python -- sem declarações de tipos -- seria completamente impossível entender o propósito de um método sem ter a documentação, por ex:

def __obtemFoo( bar );

completamente obscuro! Com linguagens sem declarações, sim, é que é preciso ser gênio para se decifrar os propósitos, como se pode observar...

;; ((lambda (x) x) "Isto foi sarcasmo e não será compreendido nunca")

huhuhu: "Mon Dieu, são os pseudo-Neos dando cria! :P"

eu não tenho nada com isso! deve ser filho bastardo do Morpheus! :P

"Essas ferramentas e frameworks são escritos com o único propósito de não reinventar a roda"

ah, bem! bom saber que a comunidade java *COUGHEclipse/NetbeansCOUGH* não gosta *COUGHAWT/Swing/SWTCOUGH* de reinventar *COUGHHybernate/JDOCOUGH* a roda...

"em momento nenhum, substituem o skill dos desenvolvedores."

certo, certo. vamos por um momento acreditar que a massa de programadores java por aí seria capaz de fazer qualquer coisa não houvessem todos esses frameworks já prontinhos pra consumo...

"Mas esses são profissionais de segunda classe que cedo ou tarde acabam sendo engolidos e saindo do mercado... No mundo real, vc. lida com pessoas igualmente criativas e capazes (na melhor das hipóteses)."

Parece que seu mundo real é melhor que o meu! :)

No meu, tenho que criar código que meus compadres programadores -- alguns dos quais vieram da área de humanas, a maioria dos quais nunca passou por uma faculdade de informática e não fazem a menor idéia do que seja um autômato e têm dificuldade em entender coisas básicas como escopos léxicos -- consigam entender. Preciso nivelar por baixo, entende? E não posso modularizar através de funções: ou usa as funções que aparecem no documento de padrões da empresa, ou usa copiar-e-colar pra deixar mais explícito. Senão, neguinho fica confuso...

"No entanto, é preciso lembrar que elas não pensam com a sua cabeça e suas idéias 'brilhantes' podem não ser tão óbvias para elas do que são pra você."

Pois, é. Aliás, além das funções, estou pensando também em desistir de loops for. Explicitamente copiando e colando a mesma sequência de comandos de um número desejado deve tornar as coisas mais claras pros meus cumpadis. Acho que suporte da linguagem e ferramenta não são coisas desejáveis, já que os padrões especificam funções que precisam ser copiadas para cada form individualmente e aparentemente implicaram com a idéia de se usar herança ou mesmo templates Delphi para isso...

"É preciso lembrar também que elas têm um prazo para entender o que vc. faz e reagir de acordo."

bem, não mais. Desisti de pensar e hoje sou apenas um autômato estúpido. É mais fácil e não tenho mais preocupações exceto copiar-e-colar e ligar controles data-aware a seus data sources...

"Hoje em dia, desenvolvimento de software é uma tarefa de comunicação, muito mais que de genialidade."

Desenvolvimento de software comercial de aplicação. Pro usuário final. Pq programadores de infraestrutura, que vendem novas tecnologias ao invés de consumí-las, são bem pagos por sua genialidade. E duvido que seu código interno seja uma "tarefa de comunicação", nenhum software de infraestrutura o é...

"- O seu pessoal não tem skill para trabalhar com isso, não adianta explicar por telefone. Contrate gente melhor."

mas vc sabe que não dá, Copérnico: gente melhor custa caro e o que o mercado quer é essa merda que está aí hoje. Code-monkeys...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

sim: claramente tmb não vou muito com a cara de OO em geral. Gosto de python pq tmb permite programação procedural e até um pouco de funcional. Ruby de certa forma tmb, ao deixar implicito que quando vc declara uma função fora do escopo de qualquer classe, na verdade está declarando um método do módulo atual... :)

Não sou totalmente contra POO, pq ao menos popularizou modularização e encapsulamento.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

1 real: "O MappedByteBuffer usa a técnica de mapeamento de memória."

bem, o que há em um nome? :P

eu sei o que é mapeamento de memória.

"Em compensação, só é bom pra isso mesmo... :/"

a CPAN discorda. se bobear, tem até implementção de VM java por lá... :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Com Python essa necessidade: Com Python essa necessidade forçada de saber o tipo de retorno do método é absolutamente desnecessária.

E se ele REALMENTE precisa saber qual é o tipo do retorno, basta fazer:

>>> a = "aaa"
>>> type(a)
type 'str'
>>> b = 1
>>> type(b)
type 'int'
>>> f = open("/tmp/bla.txt","w+")
>>> type(f)
type 'file'

Esse tipo de argumento tentando transformar uma desvantagem de Java em vantagem é nulo.

Ôo...peraí.: Ráquer não usa linguagem com estrutura de dados de alto nível prontas, faz as dele.

Programar em Java é o equivalente a requisitar alguma coisa em uma repartição pública: vc tem que ir à repartição (carregar JVM), preencher pilhas de formulários (descritores XML), entregar N certidões (declarar classes e interfaces) para ter de volta algo que com uma empresa privada (Python) só precisaria de um telefonema.

Ôo...peraí. Aí quem parece que nunca desenvolveu software é você...

Cara... software de qualidade tem que ter formalismo sim, senão parece coisa escrita por estudante com espinha no nariz.

Ou você acha que as empresas querem que apenas o cara que codificou saiba o que se passa com o software. Outro dia ele morre e o software vai com ele pro caixão.

O pré-projeto (programador odeia isso) é muito importante, do contrário você começa a codificar a la louca e ali na frente você da com a cabeça na parede porque você não preveu escalabilidade. E isso tem que estar tudo documentado.

E se o seu software necessitar integração com outro projeto. Não tem declaração? Não tem estrutura? Não tem formalismo? PÔ QUE ZONA!

O que mais se vê por aí é pouca documentação porque realmente é um saco documentar. Mas é muito importante.

Ser criativo é fantástico, mas não adianta você codificar como um gênio se ninguem entende o que você faz. Outro dia você vai trabalhar em outras paragens e o pessoal fica com o rojão na mão. Tem que encontrar outro gênio que entenda o que você fez... É justamente isso que quem contrata não quer.

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Não te cansa mesmo.: Para por aqui Copernico.
Tu na vê que o cara é daquele tipinho que só quer detonar os outros.
Só ele escreve software...
Só ele não faz software de padaria e de loja de vender discos na Jamaica.
Só ele é o bom do pedaço.

Tremendo mané que não consegue sustentar um debate em alto nível e parte pra gozação, palavreado shulo e isinuações grotescas.

Porque ao invés de ficar detonando os teus comentários ele não mostra uma forma mais produtiva de testar e depurar o software.

Quem sabe ele para de soltar palavrão e começa a postar algo produtivo...

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Que diabo?: No meu, tenho que criar código que meus compadres programadores -- alguns dos quais vieram da área de humanas...

Pô... mas que diabo de empresa é esta que você trabalha? Quem contrata gente assim?

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Já dá pra um chocolate...: eu sei o que é mapeamento de memória.

Mas tem quem não saiba, ué...

O comentário em relação ao Perl é intensamente pessoal e parcial de minha parte. Existem bons aplicativos feitos em Perl. O meu preferido é o Webmin, que permite administração remota do Linux.

Se bem que ele pede uma ajuda pro Java no módulo do gerenciador de arquivos... :)

é o skin: Acontecia comigo no skin padrão... Tenta trocar o skin que eu acho q conserta ;-)

Tu na vê que o cara é: Tu na vê que o cara é daquele tipinho que só quer detonar os outros.

Falar mal dos outros é muito mais gratificante do que falar bem. Eu, se pudesse, só falaria mal.

(e esta frase nem é minha)

Tremendo mané que não consegue sustentar um debate em alto nível

Que alto nível, cumpadi? Cadê o alto nível aqui? Eu só vi um inútil entrando em contradição a todo momento, dizendo que não depura software num momento e depois quando viu que falou merda diz que faz todo um conjunto de testes de unidade. Falou até que sabe exatamente o que cada método faz sem ler a doc. O cara é tão sem noção que acha q testes de unidade servem pra detectar todas as condições de entrada e gargalos que possam aparecer.

Dá pra dizer q um sujeito desses escreve software?

Debate de alto nível é quando as idéias são de alto nível. De que adianta o cara florear o palavreado se só fala bobagem?

Vc prefere o quê, estilo ou substância?

Comigo é no popular.

Me bata no argumento, na idéia. Se não bate, então fica PIANINHO, blz?

Pra vc ver que até as: Pra vc ver que até as buzzwords tem sua utilidade:

O ato de pronunciá-las aumenta a auto-estima, faz gente medíocre parecer importante.

Caricaturas: CUpérnico Prepúcio

Caricatura interessante do meu nick...

Mas só pessoas importantes e famosas são dignas de caricaturas feitas por um artista de tal calibre. Não precisa gastar sua criatividade comigo, eu não sou ninguém.

Truques manjados: chamar o outro debatedor de troll

Fazer conscientemente comentários destrutivos sem embasamento, com o único propósito de incitar polêmica e propagar inverdades. Isso não tem outro nome: é Troll.

encerrar com pose de superioridade, "A verdade é a melhor defesa contra a desinformação."

Superioridade na sua cabeça. A frase diz exatamente o que pretendeu: significa que informações incorretas foram veiculadas e que a única forma de reparar o ocorrido é mostrando os fatos.

15,99Mb é o tamanho do _instalador_ do runtime Java. Depois que se instala, fica bem maior

No meu entender, estava sendo avaliado o tamanho do download. Se o critério é o tamanho instalado, a JRE fica em torno de 50 a uns 65Mb, dependendo da plataforma. Nada de absurdo e nem pode ser chamado de "enorme". Se o tcl/tk, ou "aquela outra plataforma X que eu gosto" ocupa menos disco é pq tem um conteúdo menor. Não dá pra enfiar toda rica API do J2SE5 em uma dezena de Mb.

Na verdade, até dá sim: converta os .jar do JRE para o novo formato pack200 e o tamanho deles cai absurdamente - chega a 8x menor, em alguns casos. Isso pq é um formato de compactação otimizado para arquivos de bytecode da JVM. Mas aí vc. perde a flexibilidade de abrir os arquivos em seu zip-client preferido...

Então fica a dica: Se para vc., leitor, o espaço em disco for importante e vc. usa JRE5.0+, vc. pode fazer a conversão e ganhar (chute) uns 30Mb de espaço.

Existe Tcl rodando em telefone celular. E Java também!

Respeitadas as devidas proporções em número de usuários.

Não sei por quê Java no desktop tem que ser tão enorme.

Talvez pq a API seja bem maior e tenha mais recursos? J2Me (e Java Card) são distribuições minimalistas, próprias para o ambiente na qual executam. Achei que isso era óbvio, tem certeza de que nunca pensou nisso?

O HSQLDB é peso pena, tem um limite de 8Gb. É desleal compará-lo com o MySQL

Tá legal, então posso comparar o MySQL com o Apache Derby, ou o Cloudscape, que são "pesos-pesados" (como se o MySQL não desse crash quando o banco cresce e fragmenta) e ainda são muito menores.

É uma linguagem "da moda" alimentada por uma campanha de marketing brutal e incessante desde que surgiu. Em marketing, Java é insuperável.

Quando vc. tem um bom produto, é fácil falar bem dele. A M$ é muito melhor em Marketing e não consegue o mesmo resultado com .NET.

Você deve morar no Brasil, onde grandes pentelhices como Flash e Javascript

Hããã... O que exatamente isso tem a ver com Java e o assunto? Esqueceu o Java e resolveu desclassificar os brasileiros também? Por que? Fazemos software de qualidade sim.

Falando sério, se você adora Java, é natural que se relacione com usuários da mesma droga. Eu conheço muito mais gente que mexe com C ou script do que com Java

Desculpe. Mas não sou eu quem escolhe as equipes com as quais minhas empresas clientes trabalham. Elas mesmas escolhem.

Se popularidade é marca de qualidade para você, você deve ouvir muito Britney Spears, Tati Quebra Barraco, Backstreet Boys, usar Windows etc

Acredito que a comunidade da informação seja formada por gente com mais de 100 pontos de QI e esteja em outro nível. Interessante que vc. os trate como idiotas, mas eu não estou disponto a fazer o mesmo.

Fábrica de software, toque de caixa, redução de custos, nivelamento por baixo

Fábrica de software, toque de caixa e custo baixo para desenvolver um sistema de billing? Não me faça rir, de novo. Não, não funciona... Esse tipo de projeto é pesquisa pura e muito caro.

Diga-se de passagem, Java já desponta tb. como líder em projetos de pesquisa acadêmica, pq é popular e gera códigos fáceis de entender.

As faculdades não querem ensinar C. Elas querem oferecer o que está na moda e vender matrículas

Elas querem ensinar aquilo que vai fazer diferença para a vida dos alunos. Aqui fora, no mundo real, quase ninguém consegue ganhar a vida escrevendo device drivers.

Daí tem essa impressão de que o mundo está sendo dominado por Java

O sourceforge e o freshmeat também... ;-)

entrou num bate-boca sem fim como se sua vida dependesse disso

Não depende. Meu primeiro comment não tinha nada a ver com bate-boca e flame, mas sempre aparece algum mal intencionado por aqui para aproveitar notícias com "Java" no título e vir trollar a plataforma (isso não acontece em notícias de outras tecnologias, será pq?).

Seria fácil não entrar no flame. Bastaria aceitar na boa a mentirada que foi escrita. Mas chega, estou realmente declarando guerra pra essa galera que, em vez de trabalhar pela sua praia, quer sujar a que é mais popular do que a dele.

E em relação a moderar, quase não faço isso pq respeito a liberdade de expressão. Mas o cara extrapolou o limite dele. Aceitar esse tipo de coisa aqui seria falta de respeito com o brain. Aqui é um lugar de cultura e não pra descer barraco.

Quer argumentar, faça isso com superioridade técnica.

Ou, ao menos, tente.

Vc. está certo,: Vc. está certo, escovador.

Por mais que a tentação apareça, vou manter a minha promessa de ignorar o cara. Já deu.

Mas vou fazer o benchmark que ele "encomendou" e depois posto o resultado, só como exercício intelectual.

[]s

Aqui é um lugar de: Aqui é um lugar de cultura

EHAHEHAHEHHAHEHAHEHHAHEHAHEHAHEHAHEHAHEHAHEHAHHEHAHEA

vou manter a minha promessa: vou manter a minha promessa de ignorar o cara.

Correu do pau.

Entendi.: Falar mal dos outros é muito mais gratificante do que falar bem. Eu, se pudesse, só falaria mal.
Entendi... aliás eu entendo rápido.
É exatamente deste tipo de gente que o SL está carente.

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

Heheh: ah, bem! bom saber que a comunidade java *COUGHEclipse/NetbeansCOUGH* não gosta *COUGHAWT/Swing/SWTCOUGH* de reinventar *COUGHHybernate/JDOCOUGH* a roda...

Heheh, é disso que o meu povo gosta... Falar com conhecimento de causa! :)

Cara, discordâncias técnicas ocorrem em todo lugar (quando são realmente só técnicas) e a concorrência é produtiva, de certa forma.

Mas o que eu disse sobre não reinventar a roda é se concentrar no problema que vc. quer resolver, e não nos outros problemas inerentes e recorrentes. Frameworks ajudam a endereçar o problema. Eles variam em escopo, abrangência, qualidade (pq não?), curva de aprendizado, etc. mas todos evitam que vc. faça trabalho repetitivo.

Ainda que te tirem a oportunidade de inventar soluções cada vez mais "brilhantes"...

...Para o mesmo bom e velho problema.

Conforme se diz em IA, não precisamos de uma solução perfeita. Precisamos apenas de uma solução eficiente. Se ficamos esperando alcançar a "iluminação" seremos como o "burro de von Newman"...

certo, certo. vamos por um momento acreditar que a massa de programadores java por aí seria capaz de fazer qualquer coisa não houvessem todos esses frameworks já prontinhos pra consumo...

Eu já conheci alguns malandros que não conseguem nem se virar com os frameworks... Mas sério, tem muita gente que sabe trabalhar direito e é até fácil reconhecer os caras.

Eu estava trabalhando uma vez em Curitiba e tinha um colega meu que teve uma demanda de um scheduler multi-tarefa e concorrente. Ele escreveu o código na unha (por não conhecer os produtos que fazem isso, ou por não existirem na época). O resultado é que a coisa funcionava e, ainda que com mais tempo o código pudesse melhorar bastante, ficou um produto quase tão bom quanto o Quartz.

Java não é uma "plataforma dragInDrop". Ela obriga as pessoas a pensarem um pouco e destaca a ignorância de quem não pensa.

Senão, neguinho fica confuso...

Se isso acontece, encapsule a complexidade em componentes que exponham interfaces bem simples. E, por favor, esqueça o copy-paste! :)

Pois, é. Aliás, além das funções, estou pensando também em desistir de loops for.

Prrrffffbbbbbkuakuakuakuakuakuakua!

Cara, tu tá infeliz, né? Faz um método que receba um objeto que realiza o processo uma vez e o número de vezes que deve ser feito. :-D Será que assim os caras conseguem usar?

Não, Nêmesis, não é minha postura no trabalho não... Faço do jeito que tem de ser feito e quando vem um chorar e dizer "Não conheço RMI, não sei trabalhar com taglibs, não sei fazer parse de XML", eu digo que ele precisa aprender e mando os links pra ele.

Um colega instrutor uma vez inventou o termo TVM (Te Vira, Malandro), que tem sido bastante útil, devo até estar devendo royalties pra ele.

Desisti de pensar e hoje sou apenas um autômato estúpido

Não deveria. Essas pessoas precisam de alguém que pense para elas e lhes dê tudo mastigado em interfaces simples e claras. Não ser bizarro ao programar também não significa ser tacanho ou desinteressado.

Pq programadores de infraestrutura, que vendem novas tecnologias ao invés de consumí-las, são bem pagos por sua genialidade

Se o seu software tem tamanho suficiente para precisar ser escrito por várias pessoas, se ele têm de atender requesitos pré-estabelecidos, a comunicação ainda é a mais importante. As proporções cresceram. Hoje vc. não programa mais para as máquinas. Programa para as pessoas.

mas vc sabe que não dá, Copérnico: gente melhor custa caro e o que o mercado quer é essa merda que está aí hoje. Code-monkeys...

Enquanto não fizerem isso por lá, vão é perder dinheiro e a confiança do cliente. Pq eu aqui não vou mover uma palha a mais... No fim, funciona. Acredite.

Dono da Razão? Eu não.:
O dono da razão Copernico Vespucio

Não é necessário, basta não ser estúpido.

[]s

É exatamente deste tipo de: É exatamente deste tipo de gente que o SL está carente.

Vc parece ser um cara inteligente. Um oráculo, talvez.

Poderia fazer um IMENSO favor para nós, e nos dizer aonde é que eu posso ler essa cartilha que diz de qual tipo de gente o SL está carente e de qual não está.

Pq do jeito q vc fala, parece até q vc é autoridade no assunto.

Java X C++: "Sobrecarga de operadores, defines, diretivas de compilação e toda essa tralha que torna esotéricos os códigos em C++."

Bom amigo, me lembro da Java World Tour (atual Java One) em 1997 aqui no Brasil, onde o pessoal da SUN falava que Java jamais teria as características de C++ que eles achavam sem sentido e que eram contra a OO, tipo Sobrecarga de operadores e função, Templates (Java implementou templates através de Generics) e a famigerada herança multipla, que recentemente está ganhando força na comunidade java que define as JSR's (Java Stardard Requests se não me engano), portanto Java Versus C++ está cada vez mais ficando Java = C++. Só falta o sacrilégio do da geração de binário nativo.

Leidson Campos
PlanetaMessenger.org

Java X C++: "Sobrecarga de operadores, defines, diretivas de compilação e toda essa tralha que torna esotéricos os códigos em C++."

Bom amigo, me lembro da Java World Tour (atual Java One) em 1997 aqui no Brasil, onde o pessoal da SUN falava que Java jamais teria as características de C++ que eles achavam sem sentido e que eram contra a OO, tipo Sobrecarga de operadores e função, Templates (Java implementou templates através de Generics) e a famigerada herança multipla, que recentemente está ganhando força na comunidade java que define as JSR's (Java Stardard Requests se não me engano), portanto Java Versus C++ está cada vez mais ficando Java = C++. Só falta o sacrilégio do da geração de binário nativo.

Leidson Campos
PlanetaMessenger.org

Oi, Leidson: Oi Leidson. Teu post saiu duplicado, cara. Conserta aí se não fica confuso :)


Sobrecarga de operadores

Essa é ponto pacífico que não vai rolar com Java. Mas para acalmar os anseios, ela é premitida em Groovy, uma lingua dinâmica a ser suportada pela plataforma Java. É uma estratégia para jogar para o groovy tudo que não combina com a filosofia de Java.

e função

Ué, que eu saiba Java sempre suportou sobrecarga de métodos.

Templates

É uma história longa. Desde o início, Gosling não gostava de Templates, tal como existem em C++. Dentre os inúmeros modelos apresentados, muitos foram recusados, até que apareceu o modelo atual.

Se vc. analisar bem de perto, ele é diferente do que C++ implementa, inclusive com o esquema do "apagamento". Generics não viola os princípios OOP.

e a famigerada herança multipla, que recentemente está ganhando força na comunidade java que define as JSR's

Acompanho de perto o JCP e não sei disso não... Pode me dizer o número da JSR?

Acho que essa idéia (beeem ruim) tem ganho um pouco de força em um ou outro grupo de usuários por aí (inclusive no portaljava brasileiro). Mas essa feature em nada acrescenta a linguagem. Não é pq está na moda fazer alterações na línguagem Java que qualquer coisa vai passar.

portanto Java Versus C++ está cada vez mais ficando Java = C++

Não acho não. Java deve muito ao C++, assim como ao Smalltalk (não vamos cometer o pecado da M$ com o .NET aqui, certo?). Mas já passou adiante.

Só falta o sacrilégio do da geração de binário nativo.

Já ouviu falar do GJC? Eu não uso, mas tem quem ache legal...

[]s

Resolveu,: Mas pensando bem, prefiro esse skin mesmo!

Autoridade.: Poderia fazer um IMENSO favor para nós, e nos dizer aonde é que eu posso ler essa cartilha que diz de qual tipo de gente o SL está carente e de qual não está.

Não... não tem cartilha nenhuma não. É só bom senso mesmo. Tipo: Não detone os outros e os outros não te detonam.

Falta de diálogo e entendimento não são produtivos e não atraem gente para os projetos .


Você, que deve assinar alista do kernel, deveria saber disso. O reiser está cada vez mais se distanciando do resto dos desenvolvedores.
Parece que o HURD também não decola porque não consegue atrair gente pro projeto. Você ja parou pra pensar porquê?

Pq do jeito q vc fala, parece até q vc é autoridade no assunto.

Não. Você é que deveria ser autoridade neste assunto. Afinal de contas na música também costuma ser assim. Os grupos permanecem juntos e produzem, enquanto tem entendimento. Enquanto um respeita a individualidade e o modo de pensar do outro. Quando os caras discutem até a marca da guitarra que vão usar... é um pra cada lado.

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

pano rápido!: "Quem contrata gente assim?"

o governo. :P

Tudo bem, não é tão mal assim, apenas um sujeito que veio do RH e saca razoável de PHP, mas está sofrendo com a onda java atual. Os outros têm algum background *profissional* em Informática, mas o nível varia bastante já que poucos têm real *formação* na área e só sabem mesmo usar ferramentas sem entender a teoria por trás, seguindo o pragmático, mas estúpido, lema "atire primeiro, pergunte depois".

Alguns não perguntam nunca, desde que as ferramentas funcionem fácil e o nível seja baixo... :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Saquei.: o governo. :P

Conheço o problema... Tenho uma amiga que é ótima profissional e entrou nessa de emprego público em função da estabilidade. Hoje vejo que ela só reclama e vive frustrada, pois em geral (não sei como pois tem concurso público?????) só tem gente incompetente na volta (segundo ela...).

As vezes no trabalho aparecem tarefas que não me dão prazer, mas que ainda assim devem ser feitas. Mas se passa a ter mais coisa ruim do que boa vou pra outra. Não quero virar Garfield...

Quem tem bala na agulha não se mixa!

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

hah!: "tinha um colega meu que teve uma demanda de um scheduler multi-tarefa e concorrente."

ah! mas se era colega seu, devia ser um gênio tmb! estou falando da grande massa lá fora...

"Se isso acontece, encapsule a complexidade em componentes que exponham interfaces bem simples."

é pra isso que serve o padrão, oras!

"E, por favor, esqueça o copy-paste!"

mas o padrão é basicamente copy-paste: pegue Formulários como modelo e copie os métodos padrão lá desenvolvidos! "Pq não criar um Form desses e herdar dele ou mesmo usar como template?" -- vc pergunta, já que ambos são suportados naturalmente pela linguagem e ferramenta. Pq não faz parte do padrão adotado para o processo de desenvolvimento!

estúpido, obviamente. mas não dou mais meus pitacos, pois um dos idiotas do comitê de padrões é um javali doente e é inútil tentar argumentar com ele...

"Cara, tu tá infeliz, né?"

dá pra perceber?!

"Um colega instrutor uma vez inventou o termo TVM (Te Vira, Malandro),"

muito bom! Gostaria que fizesse parte do padrão! huhahuhauha

"Não ser bizarro ao programar também não significa ser tacanho ou desinteressado."

bizarro... eu não sou bizarro, apenas me puseram em uma camisa-de-força. Só se pode usar funções que estejam definidas no padrão e acabou! Criar funções locais para resolver problemas específicos, nem pensar. Daí o cut-and-paste insano. Mas não ligo mais não. Estou pensando pelo lado positivo, que é que sempre vão precisar do pessoal da Informática para dar manutenção nos sistemas de legado...

"Hoje vc. não programa mais para as máquinas. Programa para as pessoas."

Pessoas não executam software.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Fala sério!: Só se pode usar funções que estejam definidas no padrão e acabou!

Fala sério! Mas o que é isso! Só falta começarem a colocar viseiras em vocês. Isso é caso para o ministério público.

Ja pensou em fazer um protesto silencioso tipo aquele do Stallman. Acho que ia ser hilário... :D

Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."

+-: "ela só reclama e vive frustrada, pois em geral (não sei como pois tem concurso público?????) só tem gente incompetente na volta (segundo ela...)."

Tem muita gente incompetente, realmente. Com certeza deve haver um "peixe" ou outro e esses dá pra sacar de cara, pois não sabem absolutamente nada, mesmo tendo passado para Informática em particular. Mas tmb tem muita gente que passa nos concursos pq fica 1 ano inteiro fazendo cursinho e decorando questões de concursos anteriores... rapaz, eu não estudei computação minha vida inteira pra perder tempo com isso! Chutei as questões de Regimento Interno pra não zerar, pontuei bem em Informática e isso bastou.

"Mas se passa a ter mais coisa ruim do que boa vou pra outra"

mencionei que são apenas 6 horas de coisa ruim? :)

de certo modo, não tenho muito do que reclamar... o trabalho é fácil, apesar de imbecil e fora do meu controle, mas posso empregar minha criatividade em outras atividades externas...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

é o que estou fazendo!: "Ja pensou em fazer um protesto silencioso tipo aquele do Stallman"

Meu protesto é exatamente ser tão burro e estúpido quanto o resto de meus colegas e me ater apenas às funções padrão e ao copy-paste. Silenciei aquela parte irrequieta do meu cérebro... bem, na verdade, ela dá as caras por aqui!... :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

ah! mas se era colega seu,: ah! mas se era colega seu, devia ser um gênio tmb! estou falando da grande massa lá fora...

Esse cara aprendeu Java na faculdade... :) E, diga-se de passagem, com só 6 anos na área anunciou aposentadoria (como ele conseguiu isso, eu me pergunto todo dia). Ele disse: "Programar agora, só como hobby".

Agora, é uma pessoa com um QI decente. A distro Linux que ele usa no notebook é o Gentoo e ele sempre fez questão de atualizar o sistema sempre a partir dos fontes :)

Para o pessoal despreparado (sim, tem muitos), dois remédios: empreste livros, bota os caras pra pensar. Geralmente mesmo programadores iniciantes gostam de escrever bons códigos, só não sabem como.

Se não der certo (o pessoal tá "pendurado" no cabide de emprego), então ensina-se os padrões (os bons) e o cara faz assim "pq é assim que se faz".

javali doente e é inútil tentar argumentar com ele

Pela descrição, parece um javali inexperiente para o serviço. Peça a ele uma explicação do porque é assim (e tenha preparo em Java suficiente para continuar na discussão, ou ele vai usar seu redicalismo contra você), na frente de outras pessoas.

Gostaria que fizesse parte do padrão

Faz parte dos meus... kkk!

Pessoas não executam software.

Elas executam sim. Mandam a máquina executar, fornecem os dados e usam as respostas. Máquinas não precisam de software (seu micro não vai ficar triste se vc. não o usa). Pessoas usam software, e é natural que sejam elas que paguem por ele.

Também concordo que Java: Também concordo que Java não precisa de herança multipla, C++ precisa de herança multipla por não ter interfaces... dai você faz o mesmo que se faz em Java com interfaces usando herança multipla.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

As boas restrições do Java: Também concordo que Java não precisa de herança multipla, C++ precisa de herança multipla por não ter interfaces... dai você faz o mesmo que se faz em Java com interfaces usando herança multipla.

C++ pode usar classes abstratas (o que, nessa linguagem, significa uma classe qualquer com métodos abstratos) para realizar o papel de interface. Mas o problema é que não há como obrigar uma classe dessas a só ter métodos abstratos.

O grande lance da interface Java é a restrição que proíbe métodos concretos em uma interface. É isso o que possibilita a herança múltipla de interfaces, evitando conflitos de implementação nas "classes filhas", fazendo com que o programador não tenha de se preocupar com isso.

Esse é apenas um dos casos em Java onde uma aparente restrição nos fornece recursos extras.

ahem: na verdade, gostaria apenas de lembrar que no caso de herança múltipla, vc herda código já escrito. Com Interfaces, vc *precisa implementar* o código dos métodos de *cada* Interface em *cada* classe que as utilize. Está bem explícito em "implements"...

não consigo entender como o pessoal de java, que odeia reinvenção de roda, pode gostar de implementar os mesmos métodos sucessivamente...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

cat fall: Bom, a coisa mais importante em herança é o relacionamento lógico, não aproveitar código.

Se vc. quer aproveitar código, vc. pode usar composição ao invés de herança para isso. Assim:

  public interface MinhaInterface{


    public void meuMetodoGarantido();


  }





  class MeuCodigo{


    public void meuMetodoReaproveitavel();


  }





  class MinhaSubclasse implements MinhaInterface{


    private MeuCodigo codigo = new MeuCodigo();





    public void meuMetodoGarantido(){


      this.codigo.meuMetodoReaproveitavel();


    }


  }

Com isso, vc. separa a interface de sua implementação, reaproveitando código de forma flexível e sem conflitos de herança.

[]s

rise: "a coisa mais importante em herança é o relacionamento lógico, não aproveitar código...Se vc. quer aproveitar código, vc. pode usar composição ao invés de herança para isso."

nada impede C++ disso. Mas ele não é tão acadêmico quanto Java em suas abstrações e processos analíticos sem fim. Produzir software é uma atividade essencialmente de síntese e integração faz bem pra isso. Mas os javalis estão continuamente tentando separar tudo o máximo possível. Eu acho que eventualmente eles vão pedir para declarar uma classe separada para cada linha de código...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

O J da questão: A questão em evidência aqui é a separação dos interesses. Separar o que é herança verdadeira (vista como relacionamento "lógico" entre os artefatos) do reaproveitamento de código, que é eminentemente "físico".

Dá pra fazer com C++ também, utilizando uma classe abstrata para o papel da interface. O único problema é que nada impede que sejam definidos métodos concretos nela, o que estragaria o padrão e os mesmos velhos problemas de herança múltipla voltariam (assim como um possível "shotgun surgery" entre a classe "abstrata" e a provedora de código).

Ao usar uma interface em Java, vc. está sinalizando claramente que métodos concretos ali não são permitidos.

Essa separação da qual vc. fala chama-se granularidade, e é uma decisão imporante de design, comparável à normalização no modelo relacional.

Quanto mais os interesses são separados uns dos outros, mais fácil a sua manutenção. Com uma ferramenta que gera documentação fácil do que escrevemos (javadoc) e um compilador JIT capaz de fazer inline do código (javac 1.5+) onde for necessário, não temos muitos problemas com design de elevada granularidade.

Para ter bons designs modulares sem ter nas mãos uma "explosão de classes" (quando houver perigo disso acontecer), usamos alguns padrões de projeto bastante úteis, como o Bridge (GoF) por exemplo.

Claro, seu último comentário é um exagero e vc. sabe disso... :)


Ops! ERRATA:

A pressa me fez errar a definição de uma classe:


class MeuCodigo{
public void meuMetodoReaproveitavel();
}


Essa é uma classe concreta, que contem o código a reaproveitar. Então o certo é:


class MeuCodigo{
public void meuMetodoReaproveitavel(){
//Escreva aqui seu código

}
}