típico!: brasileiros são derrotistas por natureza...

Assembly: É uma pena não valorizarem tanto a linguagem Assembly. Preferem o Java, Python, Ruby, linguagenzinhas da moda. Daqui no máximo 10 anos entra outras no lugar delas.

Java já tem mais de 10 anos.: Java já tem mais de 10 anos...

Compiladores: Na verdade, só existe a linguagem implementada em hardware, no caso o Assembly.
Por que desprezam o Assembly ?
Só quem projeta e implementa compiladores/interpretadores/máquinas virtuais conhece a máquina nesse nível, enquanto que a maioria trabalha sobre enormes camadas de abstração. Além disso, o que impera são aplicações comerciais (principalmente Web): PHP+alguma implementação do SQL+Apache
Basta você prestar atenção nos posts aqui do br-Linux ou de qualquer outro site, não me lembro de ter lido uma única vez sobre algum projeto de programação sobre robótica, controle de sondas, engenharia civil, CAD, nada...é só Web, típico de um país shopping center como o nosso.
Espero que agora você acorde para a realidade.

Tenta fazer uma aplicaç: Tenta fazer uma aplicação comercial em assembly....

Robert.

Porquê não faz sentido em 99% dos casos hoje: Eu já programei (e ainda programo ocasionalmente) bastante em assembly. Não acredito que você se lembre pois este projeto tem uns 15 anos mas existia um grupo de programs gráficos chamados, em conjunto, de Família Ted. Eram compostos por Ted2D, TedChart e TedSlide. Eu fui um dos desenvolvedores em parte do Ted2D e a totalidade do TedSlide. O Ted2D foi todo escrito em assembly. O problema é que trabalhar com gráficos nas máquinas da época era pareo duro e assembly era a melhor opção para conseguir uma boa performance.
Em casos onde performance tem que ser extrema ou ainda tem-se recursos muito limitados, assembly ainda pode ser uma boa opção mas, com a complexidade dos procesadores atuais, o custo baixo de recursos de hardware, o alto custo de mão de obra e a qualidade dos compiladores atuais, simplesmente não faz muito sentido hoje em dia. O tempo gasto para programação e debug de um sistema escrito em uma linguagem de baixo nível, sem contar a maior probabilidade de ocorrência de problemas, é muito maior que simplesmente acrescentar mais recursos de hardware para compensar a perda de performance.
Isso sem contar fatores comerciais e de marketing como tempo-para-mercado, etc.
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca

Comercial: É óbvio que não tem sentido fazer em Assembly...é uma questão de contexto, projetistas de compiladores/interpretadores/máquinas virtuais, esses tem que entender de arquitetura de computadores em geral, pois o alvo do back-end é o hardware (na maioria das vezes).
Mas...isso é para essa elite seleta, a qual tem que existir, caso contrário, quem faria as ferramentas que os outros usam ?

pq...: "Por que desprezam o Assembly ?"

_qual_ Assembly? *86, para processadores PowerPC, Sparc etc? Seja mais específico.

e é essa justamente a razão para se abstrair do nível de máquina: portabilidade. Além, é claro, da maior performance ( do programador, claro )...

Claro: Era o contexto da época, mas há situações em que é preciso saber como é a máquina real, para os projetistas de tradutores em geral é o caso.
Mas preste atenção nas suas frases, estão todas no pretérito, hoje, é uma festa Web, "eu dei um beijo nééla, e levei prá passear, nóis fumo junto prú shóppíng...pra mói da gente lanchá!"
Fazer o que né ?
Não podemos fazer nada é claro. Paciência.

Genérico...: Um conjunto de registradores, e um conjunto de funções elementares para mover dados da memória para os registradores (e vice-versa), somadores, subtratores e jumpers. Hoje em dia só quem faz as ferramentas conhece muito bem essa área da computação.
hummm...chega, não vale a pena discutir, a mentalidade é "como mortadela e arroto peru".
Tchau

tal linguagem assembly genér: tal linguagem assembly genérica não existe, simplesmente.

Mas, se vc gosta de programar em assembly, de forma portátil, um boa opção pode ser programar para máquinas virtuais modernas, como bytecodes para a Java VM ou Parrot ( a VM de Perl6 ).

Pergunta pessoal.: Kid-X, você programa?

Só pra ter uma referência sobre o embasamento de sua opinião.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Os programadores amam, já os usuários...: Programar em Java deve ser muito fácil para tanta paixão!

Em 95 por cento das máquinas no país qualquer programa em Java vai dar aquela clássica travada de 5 segundos quando a famigerada xícara aparece.Até hoje não vi um pc sequer que rodasse aplicativos em java de forma rápida.Pior, os aplicativos são horríveis, vide o Azurreus.

Qual o sentido, pelo amor de DEUS, de se usar máquinas virtuais quando é notório que são verdadeiros tanques?

Infelizmente muitos programam para o vento, não para o usuário real, o pc real.

Links: http://www.cminusminus.org/

http://www.menuetos.org/

Ser feio não é característ: Ser feio não é característica do Java. Vide o Zend. Você pode escolher tema, etc, etc. É que geralmente eles usam a padrão. Basta uma linha de código pra deixar com a cara do sistema.

O carregamento inicial ser lerdo, é um tanto quanto inevitável numa VM. Só se fizessem um esquema dela vir pré-carregada quanto o SO desse boot.

Claro que existe.: E o que você acha que é C?

-- ofranja

VM Livre: Qual é a implementação de VM Livre que os projetos apoiados pelo ITI usam?

A mentalidade de "usar uma peça proprietária no quebra cabeça não tem problema" trouxe um certo transtorno ao desenvolvimento do Linux recentemente (caso BitKeeper).

Eu não sou um programador pr: Eu não sou um programador profissional, mas me interesso por Assembly e C (Estou certo de que não são todos os códigos Assembly que funcionam em todos os Assemblers, cada código difere de Assembler, arquitetura da CPU e às vezes sistema operacional). Eu gosto dessas linguagens de baixo-nivel (C já é médio-nível) porque o meu interesse são sistemas de baixo-nível, integrações com hardware, drivers e coisas do tipo.
As outras linguagens ditas de alto nível, como eu citei, têm as suas vantagens e utilidade, de terem instruções mais rápidas e também são mais fáceis de aprender (será mesmo?). Porém, como eu disse, logo entra outras no lugar delas, pois desde a década de 50 nenhuma substituiu o Assembly e desde 70 nenhuma substituiu o C...

(Pessoal, gostei do tópico, os comentários foram bem racionais; Embora esteja meio offtopic, a conversa esta(va) boa) )

Cobol e Fortran também não.: Pela sua argumentação, se eu entendi corretamente, você quer dizer que linguagens de alto nível são efêmeras, certo? Bem, até hoje, boa parte (talvez até a maior parte) do que roda por aí é Cobol e Fortran. Sistemas legados. Realmente Assembly e C também estão aí firmes e fortes mas evoluiram. Paradoxalmente Basic também :)
O que ocorre é que cada linguagem tem seu nicho. Algumas se sobrepõem, mas isso não quer dizer que são efêmeras. Isso significa que mais e mais aplicações aparecem, mercados são criados, necessidades mudam e devido a vários fatores, linguagens novas são criadas para estes propósitos. Como foi citado aqui mesmo, as aplicações web são um exemplo. Dá pra escrever em C? Claro que dá mas PHP por exemplo é muito mais adequado e produtivo.
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca

Isso mesmo: Explicou tudo, Adilson ;-)

Opiniões.: Engraçado, enquanto as linguagens de programação procuram abstrair cada vez mais o hardware, existe gente que ainda vai em sentido contrário, sem motivo algum.

É claro que Assembly é importante, mas não pra ser programado à mão. Ter controle preciso das instruções é algo interessante, mas vale lembrar nem sequer no mercado de sistemas embutidos as pessoas procuram usar assembly: usa-se basicamente C e C++, com alguns "asm()" onde for estritamente necessário. É muito melhor usar um assembly portável (AKA C/C++) onde for possível.

Entretanto, concordo com você com relação às linguagens de alto-nível "da moda": também não prefiro Python, Ruby, e *muito menos* Java. É Von Neumann demais para a minha cabeça. :^)

E é isso.

-- ofranja

Não é por nada...: É um tanto estranho falar em "substituir assembly". É algo que sempre vai ser usado, mesmo que apenas fazendo parte de uma etapa de compilação. O grande X da questão é que ninguém programa em assembly, a não ser que estritamente necessário. E ponto. É mais um "mal necessário" do que "uma linguagem insubstituível", por assim dizer.

E 'C', a propósito, é apenas um assembly portável. Para que substituir uma linguagem de baixo-nível dessa, que serve muito bem para seus propósitos?

Bem, é isso.

-- ofranja

C é linguagem de nível méd: C é linguagem de nível médio, a distância dela para assembly é considerável.

Máquinas virtuais: Máquinas virtuais são mais úteis quando se tem vários SOs funcionando ao mesmo tempo numa rede. Já em computadores em casa, com um número indeterminado de aplicações rodando com um único SO ou no máximo com dual boot, máquinas virtuais são incomodamente lentas, especialmente quando o usuário espera mais velocidade resultante de uma máquina veloz. Por esta razão, parece que são mais usadas no setor corporativo.

O que eu acho engraçado é gente minimizando a lentidão inevitável de VMs(porque são um passo a mais na execução de um programa), dizendo que com memória e processadores mais acessíveis, este problema é menos importante, numa visão extremamente simplista, como se houvesse uma relação proporcional entre memória+processador e velocidade, ignorando a complexidade dos dados e o volume do processamento.

Assembly!: __Alguém se lembra do POwer DVD, feito em Assembly para usuários do Windows e do WinDVD, programado em C, senão me engano, todo mundo qe tinha um micro mêa-boca malhava o WInDVD que é uma merda de primeira qualidade!Mais o Power DVD tinha um desmpenho fenomenal mesmo em Pentium 300. . .Pois é, isso tudo antes de migrar para Linux e usar Xine e MPlayer, que se fossem feitos em Assembly seriam muito melhores. . .Talvez drivers feitos em Assembly fossem mais fáceis de serem adaptados para Linux. . .Mas o problema é que os computadores estão cada vez mais rápidos de modo que programar em altissimo nível virou mania, mesmo que o desempenho fique uma merda, (gera-se applets java em dois cliques de mouse)! Ou alguém nunca rodou aplicativos .NET em máquinas antigas, ou mesmo JAVA???

Por que usar linguagens de alto-nível?: O maior motivo para o empregador forçar o uso de linguagens de alto-nível é que o custo do hardware é menor que o das horas de um bom programador.

É mais barato investir em uma máquina muito potente e fazer o programador trabalhar com uma linguagem de alto-nível e terminar mais cedo o projeto do que pagar as várias horas que um programador C levaria para levantar um serviço Web do nível do Apache.

O fato de se programar para a Web ser uma febre é por ser amplamente acessível em várias plataformas. Tudo que o usuário precisa para acessar a aplicação é um browser. E o programador não tem que fazer um cliente para cada plataforma, nem mesmo programar a interface gráfica, com bibliotecas mais complexas, é só HTML e, se necessário, JavaScript. Então, o tempo de desenvolvimento é menor e é mais cômodo para o usuário.

Mas o paradigma da Web é dif: Mas o paradigma da Web é diferente daquele do desktop. A Web é essencialmente conteúdo, enquanto que desktop é essencialmente orientado a tarefa. É uma bobagem alguns acharem que o sistema dn destkop vai deixar de ser relevante, como já vi algumas vezes em alguns artigos. Como é que o usuário vai acessar o serviço Web? Por telepatia?

Isto quer dizer que a Web não elimina a necessidade de escrever clientes para cada plataforma, isto é, ser portável. Além do mais, algumas coisas são relativas a tarefas específicas do usuário.

nostradamus vc hein ?: java jah tem 10 anos :) e soh fica mais forte... pare de falar bobagens e comece a fazer algo que realmente valha a pena...

Uau!: Cara, pela primeira vez concordo contigo! :)

...: Nunca vi até hoje um programa feito em Java que seja rápido de verdade. Não entendo também por que tanta gente é apaixonada por Java. Não entendo por que as pessoas são malucas por linguagens orientadas a objeto, como se essa fosse a única maneira decente de programar (o que não é verdade).

Acho que e explicação lógica para tanta gente gostar de java, é porque é a linguagem mais ensinada nas universidades (talvez por ser fácil de entender). E sei que alguns programam em java porque não conseguem entender a "complexidade" de outras linguagens, como C (que de complexo não tem nada).

Alguns dizem que java é portável. Não faz diferença. C, além de ser rápida (o que java não é), também é portável.

...: "É mais barato investir em uma máquina muito potente e fazer o programador trabalhar com uma linguagem de alto-nível e terminar mais cedo o projeto do que pagar as várias horas que um programador C levaria para levantar um serviço Web do nível do Apache."

Eu garanto que um bom programador C levaria o mesmo tempo que um bom programador Java para fazer o mesmo aplicativo. A diferença é que hoje em dia é muito difícil achar um bom programador C. Já viram alguém inicializar um ponteiro com -1? Ou então zerar um array usando "x[0] = 0; x[1] = 0; x[2] = 0; x[3] = 0; x[4] = 0; ... x[100] = 0;"? Eu já vi... Gente que só programa em altíssimo nível aparece com umas dessas quando tenta programar em C.

Velocidade: Cadu,

quando você diz que Java não é rápido você está julgando os toolkits gráficos AWT e Swing. Eles são lentos, e não se integram com o resto do sistema operacional.

Para aplicações em modo texto, ou que utilizem toolkits decentes, como o SWT (do Eclipse), ou o GTK (do Gnome), programas em Java passam a apresentar a mesma velocidade que qualquer outro programa. Nesse caso, o gargalo passa a ser a Entrada/Saída, como em programas escritos em C ou C++. (ou Assembly, para deixar o Kid-X feliz)

Faça, o teste. Escreve um programa Java utilizando o java-gtk, e você verá que ele não será lento. Faça o mesmo com Python, ou com C#, que também são interpretadas, e também não ficará lento. A única lentidão apresentada por programas que rodam em máquinas virtuais é o tempo de carregamento da própria máquina virtual, o que só vai acontecer na hora de carregar o primeiro programa que utilize a máquina virtual. (e se você quiser, utilize o gcj, e compile o código Java para código nativo, e deixe de precisar da máquina virtual)

Quando a OO, são formas diferentes de programar, com propósitos diferentes. Eu entendo que você esteja na fase de achar que a única forma de programação importante é a de baixo nível, kernel ou exploits, mas um dia você vai perceber que para escrever sistemas grandes, para a Web ou não, a programação OO é mais prática.

Uma ressalva importante: muitos dizem que Assembly é mais rápido do que C, ou outras linguagens. Isso é, basicamente, mentira. O GCC é um compilador extremamente otimizado, e é muito difícil gerar um código assembly mais otimizado do que o GCC consegue gerar. Em geral, o que acontece é, em uma parte do programa, onde você consegue ver uma possibilidade de otimização que não seja trivial a ponto de o GCC percebe-la, ser válido incluir um código assembly que otimize aquela parte. Na maior parte dos casos, o código em assembly gerado por humanos é menos otimizado que o gerado pelo GCC (ou gcj, ou máquinas virtuais).

Se Assembly fosse uma coisa mágica, que fizesse os programas ficarem mais rápidos simplesmente por estarem escritos em assembly, bastaria escrever seus programas em C, compilar com "gcc -S programa.c", que o GCC geraria o "main.s", que seria seu programa escrito em Assembly. Aí você compilaria o main.s com o seu assembler favorito, e seu programa ficaria mais rápido, pois estaria escrito em assembly. Isso, obviamente, não faz o menor sentido. Programas feitos em assembly são mais rápidos que os feitos em C se o programador conseguir gerar códigos mais otimizados que aqueles produzidos pelo compilador, o que quase nunca acontece.

Chega de aula por hoje.

Java!!: Já diziam Harold Abelson e Gerald Sussman
"Programs must be written for people to read, and only incidentally for machines to execute."

Acho que o pessoal está se esquecendo de algumas coisas... O valor de um programador (como programador/codificador) não está associado as suas genialidades na geração de código, muito menos em sua intelectualidade em uzar linguagens "de baixo nível" para resolver um problema (desde que tenha escolhas, o que hoje é um caso raríssimo não existir), esse cara não está nem um pouco interessado se seu "programa" vai rodar rápido ou devagar, se vai ser bonito ou apenas usual, mas sim que ele cumpra com os pré-requisitos.

Analizando por esta perspectiva qualquer programador em sã consciência perceberá que Java é muito mais legal do que parece. Sua abrangente API resolve grande parte dos problemas, sem recorrer a pacotes proprietários, simplicidade e clareza do código (desde que não seja feito por um desses programadores "malucos", aqueles que insistem em usar nomes de variáveis do tipo "i", "x", "args") tornam o entendimento de qualquer método uma tarefa trivial. Talvez por isso que muitos projetos "Open Source" não vão pra frente ou param no caminho (de uma olhada na atividade da maioria dos projetos do sourceforge), cada um que "bota a mão" faz uma "salada" e no fim o negócio fica indigerível.

Se o Brasil tem a maior comunidade Java isso me tranquiliza em saber que aqui não existem tantos "malucos" que ainda insistem em brincar com ponteiros, registradores e alocação de memória em um tempo onde o que interessa é funcionalidade e mantenabilidade. Mas depois que vejo alguns comentários defendendo Assembly no século XXI (onde a maioria dos computadores - leia-se X86 - são feitos para compiladores e não programadores, ou algum programador assembly sabe tirar vantagem das instruções MMX, 3DNow, SSE, SSE2...?) isso me deixa com um pé atrás e continua a alimentar a idéia de que ainda vão algumas gerações até que o pessoal mude a cabeça.

API Java: Além da grande API basica que vem com Java, existe muitas extensões livres da API (vide http://www.apache.org/ e muitas outras). Muita coisa pronta pra usar, de qualidade.

E como só na hora de carregar o programa que Java costuma ser menos rápido que C, em muitos casos isso não significa nada... Vide o GMail que é feito em Java (a parte do lado do servidor). Ou grandes aplicações gráficas que usando SWT + Java vai ser tão rápida do que uma feita em C++. Mas será muito mais fácil e rápido desenvolver em Java...
Ou em outra linguagem de auto nível como Python.

Pressupostos: Cadu,

Você está carregando consigo muitos pressupostos pra concluir tudo isso. Não se trata de "minimizar a lentidão inevitável de VMs"; máquinas virtuais nem sempre são mais lentas. Mas, como um fenômeno de massa, são um fenômeno relativamente recente na computação (bem mais recente que compiladores, pelo menos), e têm menos tempo de evolução pra estarem tão boas quanto deveriam. Mas na verdade máquinas virtuais podem ser tão rápidas quanto programas compilados e, em casos específicos, até mais rápidas. Veja, por exemplo, esse benchmark que mostra java em alguns casos sendo mais rápida do que C++. Veja os JIT (Just-In-Time compilers), que fazem otimizações de RUNTIME que não são factíveis de fazer em código-fonte ou compilado.

Isso sem contar que em alguns contextos cada vez mais presentes hoje, uma VM oferece serviços, ligados ao bytecode, que não podem ser devidamente substituídos por nenhum framework já compilado. Explico: as VMs são mais do que apenas executadores passivas de bytecodes. Elas também gerenciam segurança, cache de compilação, coleta de lixo e outros serviços e, quando acopladas ao que se chama de "servidor de aplicações" como o JBoss, muitas outras coisas. Essas coisas todas são amarradas ao código ser portável e gerenciável (como a serialização); logo, não são factíveis (talvez sejam possíveis, mas o grau de complexidade seria proibitivo) de ser implementadas somente com código compilado. Esse tipo de coisa confere uma escalabilidade muito grande ao software rodando nesses frameworks e por conseguinte desempenho quando devidamente gerenciado desse jeito que não seria alcançado por código compilado puro.

Me parece que visão extremamente simplista é a sua, pois você acha que sem otimização uma VM não leva apenas tempo O(1) (diretamente proporcional) em relação ao código compilado? Ela é, em execução bruta contínua, X vezes mais lenta apenas. E isto é contrabalançado facilmente por outros fatores, como a citada compilação JIT e os frameworks de serviços.

Infelizmente, o Swing, toolkit de widgets do Java, contribuiu muito para isso: suas primeiras implementações foram muito pesadas, continham o problema de ocupar muita memória, etc. Mas isso foi porque o Swing foi criado para ser um tollkit "computacionalmente correto", com containers, framework MVC e seguindo as teorias acadêmicas de programação visual. Isso lhe conferiu uma complexidade grande, e as primeiras versões foram, como acontece com qualquer software, ineficientes e bugadas.

Hoje o Swing já melhorou bastante e vem melhorando a passos largos. Do java 1.3 para o 1.4 a diferença é bem visível, mas do 1.4 para o 1.5 é difícil não perceber.


OBS.: Perceba que eu nem entrei no mérito da facilidade/dificuldade de programação (tente programar orientado a objetos em assembly e verá como é um trabalho ingrato, além de uma gambiarra imensa), pois percebo que o que estamos tratando agora é simplesmente da vantagem pura para o usuário.

OBS.2: Hoje em dia muito dinheiro está sendo investido na otimização just-in-time. Alguns produtos hoje já prometem mais velocidade do que C ou C++. Já faz quase 2 anos que eu não trabalho com Java, mas algumas das técnicas usadas eram muito interessantes e me parece que a otimização em tempo de execução oferece mais possibilidades, e portanto mais velocidade, do que a em tempo de compilação. Basta procurar por papers sobre "JIT Java runtime bytecode optimization" no google que você acha...
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Re: API Java: Além da grande API basica que vem com Java, existe muitas extensões livres da API (vide http://www.apache.org/ e muitas outras). Muita coisa pronta pra usar, de qualidade.

Atribuir qualidade de uma linguagem(para ficar mais correta a comparação) à sua API não tem nada a ver. São duas coisas diferentes.

E como só na hora de carregar o programa que Java costuma ser menos rápido que C, em muitos casos isso não significa nada... Vide o GMail que é feito em Java (a parte do lado do servidor). Ou grandes aplicações gráficas que usando SWT + Java vai ser tão rápida do que uma feita em C++.

Não tem como uma aplicação gráfica usando SWT e Java, ou qualquer outro toolkit para Java ser tão rápida quando uma com C++(não sem fazer requerimentos de memória maiores). A razão é que depende de um máquina virtual, que SEMPRE é mais lenta que uma que gera código nativo.
E é mais lento, porque tem que traduzir para instruções físicas de hardware na execução, executando um passo extra que não existe no código nativo.

Por mais que se tente usar otimizar via JIT, nenhum JIT consegue ser mais experto que um ser humano, pois ele não pode saber todas as formas possíveis de organização e estrutura do código, e nem sabe nada a respeito da complexidade dos dados e o volume de processamento.

Além do mais, C++ não tem máquina virtual, de forma que a comparação fica um tanto injusta.

Mas será muito mais fácil e rápido desenvolver em Java...

Facilidade é uma coisa muito relativa, além do mais você não mencionou um contexto. Sem um contexto apropriado, comparações entre linguagens tem tanta utilidade quanto enxugar gelo.

O foco de C++ é diferente daquele do Java, não diga que Java é mais fácil ou produtivo sem levar isto em conta. Além disto, C++ não é nenhum bicho de sete-cabeças. O problema basicamente é a herança do C, e a forma errada com que se ensinam a linguagem. No ensino de C++, deve-se ensinar inicialmente o C++ e deixar de lado momentaneamente o C, usando a STL, que é muito fácil e produtiva.

Quanto ao Python, é uma linguagem de script, nem vale mencioná-la. Não tem nada ver.

Em tempo, C++ É uma linguagem de alto nível, mas permite programação de baixo nível(até por causa do C), como o C#(em um grau mais estrito), mas ninguém diz que C# é de baixo nível, não é engraçado? E o que dizer do Object Pascal, também?

O nível da linguagem é sempre definido em termos das instruções da máquina ou da "forma" de pensar da máquina. Não tem sentido dizer que C++ é de nível baixo ou até médio(nesse caso o C pode, por causa do seu relaxamento exagerado nas regras de sintaxe), há uma diferença enorme para assembly. Assim como existe uma diferença enorme entre uma linguagem de programação funcional como Haskell e C++, Java, VB ou Pascal. Essas linguagens são imperativas; isto é muito mais próximo da máquina do que uma linguagem funcional ou uma de lógica como Prolog.

Re: Pressupostos: Porque me chamou de Cadu? Com que está falando :)?

Estou citando fatos, não pressupostos. Veja o Kdevelop e o Eclipse, por exemplo, uma comparação mais próxima. Dizer quer melhoras na VM ou JIT aumentam o desempenho ao ponto que você diz é tão mito quanto a velocidade de compilação de arquivos de cabeçalho de C++ seria mais rápido com melhoras nos compiladores, mas as razões são diferentes(apesar de que eu não estava falando de Java, especificamente).

Testes de benchmark não são muito úteis. Aplicações de maior porte(digamos, de centenas de milhares de linhas de código, só como referência) usadas no dia a dia permitem uma comparação melhor, desde que seja feita com outras similares. Seria melhor que você usasse JBoss com outra similar feito em outra linguagem, aí as coisas ficam mais justas.

Você mencionou C++ na sua resposta, mas meteu a VM do Java no meio, misturando laranjas e cebolas, que é fora de propósito, pois deveria falar das linguagens, nesta comparação, então, e não de máquina virtual. Mas nem vou entrar nessa discussão de linguagem, porque não acrescenta nada, as linguagens tem focos diferentes. Além do mais, C++ não é uma plataforma de software, não tem máquina virtual.

Um JIT apenas alivia parte da otimização, ela não é capaz, sozinho, de otimizar partes de código com estrutura e organização feita de n formas diferentes possíveis. Nenhuma JIT é mais esperta que o ser humano ou capaz de lidar com todas as situações possíveis de otimização.

Java não É Portável entre plataformas, ele É uma plataforma. A portabilidade está na máquina virtual, e não na plataforma em si.
Dê uma olhada em Portabilidade para ver que tem diferença. Um programa Java sem a máquina virtual não vai fazer nada. Propaganda é dose!

Coleta de lixo não precisa de máquina virtual, veja Smart Pointers.

Tá difícil: Então acho que foi você que não entendeu minha resposta, Léo. Antes, apenas uma resposta ao seu comentário:

Testes de benchmark não são muito úteis. Aplicações de maior porte(digamos, de centenas de milhares de linhas de código, só como referência) usadas no dia a dia permitem uma comparação melhor, desde que seja feita com outras similares.

Testes de benchmarks são úteis (são feitos para sê-lo, caso contrário não haveria sentido em gastar processamento com eles) e, de fato, são o melhor que sempre teremos: se você roda duas aplicações com condições controladas, está fazendo um teste de benchmark. Se tudo o que você tem a dizer sobre um benchmark que mostra Java rodando em alguns contextos mais rápido do que C++ é isso, bom, então o problema é contigo que não aceita fatos.

Agora sobre você não entender, deixe-me ressaltar melhor alguns pontos:

Você mencionou C++ na sua resposta, mas meteu a VM do Java no meio, misturando laranjas e cebolas, que é fora de propósito, pois deveria falar das linguagens, nesta comparação, então, e não de máquina virtual.

Pelo contrário! O foco era a velocidade das linguagens, então a abordagem Máquina Virtual vs. Programa Compilado é essencial para o esclarecimento.

Mas nem vou entrar nessa discussão de linguagem, porque não acrescenta nada, as linguagens tem focos diferentes.

Acrescenta bastante e é, de fato, todo o ponto. Se quisermos discutir linguagens compiladas x linguagens de bytecode, são, talvez, os melhores candidatos. Precisamos de exemplos concretos em que nos basear, oras.

Sobre focos diferentes, isso é mínimo. Ambas são também de propósito geral e, como tal, podem fazer as mesmas tarefas e podem ser comparadas para essas tarefas. Ter um objetivo principal não tira os objetivos secundários das linguagens e se elas fossem específicas demais ("a linguagem X é feita para fazer programas de rede que usam linha de comando em chips 486DX2 fabricados entre 1990 e 1994") não seriam linguagens, seriam toolkits.

Além do mais, C++ não é uma plataforma de software, não tem máquina virtual.

Claro, foi uma linguagem projetada para ser compilada, não ser rodada como bytecode. E é disso que estamos tratando, oras. Comparando a abordagem de VM x programas compilados.

Um JIT apenas alivia parte da otimização, ela não é capaz, sozinho, de otimizar partes de código com estrutura e organização feita de n formas diferentes possíveis. Nenhuma JIT é mais esperta que o ser humano ou capaz de lidar com todas as situações possíveis de otimização.

Então acho que você realmente nunca leu sobre otimização em runtime. Não consiste naquelas técnicas que se usam em compiladores, que é o que você parece estar pressupondo, e realmente não poderiam ser feitas por humanos justamente porque dependem da análise do estado do bytecode na hora em que está rodando. Dá pra fazer otimização de runtime até em executáveis nativos (desde que, claro, eles sejam executados por um processo manipulador de código especial), mas é bem menos flexível e completo do que para bytecode feito com uma VM para cuidar de certos serviços em mente.

Quanto à filosófica questão de "programas serem mais espertos do que seres humanos", só lembro que desde que o conhecimento necessário pra otimizar algo seja finito e algorítmico e a máquina programada com esse conhecimento, ela consegue igualar ou até mesmo superar seres humanos. É com essa base que existem os chamados Sistemas Especialistas. Mas de qualquer jeito não é disso que estamos tratando, só quis espetar sua fé na grandeza humana.

Java não É Portável entre plataformas, ele É uma plataforma. A portabilidade está na máquina virtual, e não na plataforma em si.

Isso é uma questão semântica menor que não muda os fatos: java roda em várias máquinas de arquiteturas diferentes e em vários sistemas operacionais diferentes, desde que haja uma VM implementada para tal.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Java, C e C++: Além da grande API basica que vem com Java, existe muitas extensões livres da API (vide http://www.apache.org/ e muitas outras). Muita coisa pronta pra usar, de qualidade.

Atribuir qualidade de uma linguagem(para ficar mais correta a comparação) à sua API não tem nada a ver. São duas coisas diferentes.

Concordo que, se estivermos comparando linguagens puras em termos abstratos de mérito, as APIs feitas para elas não são muito importantes. Mas, no mundo real, na prática, e na hora de escolher uma linguagem, sinto muito, Léo: isso é essencial saber. A API Java é muito elegante e completa (claro, tem suas falhas - por que não tem métodos eficientes pra mexer com apenas data ou apenas hora?) e bem superior à STL nesse aspecto.

E é mais lento, porque tem que traduzir para instruções físicas de hardware na execução, executando um passo extra que não existe no código nativo.

E isso lá é tudo que existe na execução de um programa? Esse é um problema muito complexo e muito mais do que apenas um fator entra nele. Temos chamadas de API, saltos longos e curtos, relocação de blocos de memória, controle de multithreading e no caso da VM de cache de compilação e execução e diversas outras coisas. E a VM pode, no final, por causa de vários outros recursos agregados que oferece, funcionar como um computador com cache de RAM contra um computador sem cache com clock maior: ser mais rápido.

Por mais que se tente usar otimizar via JIT, nenhum JIT consegue ser mais experto que um ser humano, pois ele não pode saber todas as formas possíveis de organização e estrutura do código, e nem sabe nada a respeito da complexidade dos dados e o volume de processamento.

Léo, você realmente não sabe nada sobre técnicas de otimização de código em runtime, não? Parece que você está assumindo que são as mesmas de otimização de código-fonte ou de código sendo compilado. Por favor, informe-se sobre isso, tem muita leitura agradável sobre o tema na web.

Só pra adiantar, o otimização em runtime junta sim estatísticas sobre os dados e o programa (enquanto está executando!) de modo a saber mais do que o próprio programador a respeito deles, e ajustar a execução do programa para refletir isso (reservar buffers maiores ou menores, reescalonar prioridades, otimizar - dinamicamente! - de um ou outro jeito, etc.).

Facilidade é uma coisa muito relativa

Sim, facilidade é relativa e mais do que isso, é bastante subjetiva. Que tal então fazermos uma pesquisa pra ver quem acha java mais fácil do que C++?

Serei o primeiro a responder: trabalho há 5 anos com C++ (sou desenvolvedor C++ profissional, é meu trabalho de tempo integral) e trabalhei um ano inteiro só com Java/J2EE. Java é para mim mais fácil, produtiva e agradável que C++ para todos os escopos que conheço.

Quanto ao Python, é uma linguagem de script, nem vale mencioná-la. Não tem nada ver.

Qual é a diferença do Python para o Java, nesse sentido, já que o python na verdade compila o código para bytecode e o executa assim? Então java também é uma linguagem script, nesse sentido. Tanto que existe o Jython, que compila para bytecode da JVM.

Faz todo o sentido incluí-la na comparação, sim, senhor.

Em tempo, C++ É uma linguagem de alto nível, mas permite programação de baixo nível(até por causa do C), como o C#(em um grau mais estrito), mas ninguém diz que C# é de baixo nível, não é engraçado? E o que dizer do Object Pascal, também?

C é uma linguagem mais perto do "baixo nível" porque mapeia muito diretamente suas instruções para instruções em assembly. Um programador C em geral pensa "meio em assembly", pois tem a noção com detalhes do que acontece na máquina enquanto seu programa está executando. Um programador mais de alto nível perde essa noção quanto mais diferenças, APIs e complicações existirem no caminho...


--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Só mais uma pergunta, é pos: Só mais uma pergunta, é possível escrever drivers funcionais (de hardware) usando essas linguagens de alto nível, do tipo Java, Python, Ruby, C#? Se possível, a funcionalidade do driver não seria tão otimizado quanto escrito em C ou Assembly?
Estou perguntando porque eu nunca vi drivers escritos em linguagem de alto-nivel como essas.

Dah pra ver que vc nao sabe o que fala.: Meu filho. O assembly x86 que se usa hoje foi criado na metado dos anos noventa, com o pentium pro e o pentium 2.

Ou seja, o assembly que voce tanto fala eh mais novo que java.

Assembly eh o tipo de linguagem mais efemera que existe. Cada arquitetura tem um completamente diferente.

Python compila pra assembly python. Java compila para assembly java.
Voce tah viajando feio, meu filho.

Linguagem de medio nivel?!???!?? Q q vc fumou?

C eh realmente util somente em baixo nivel.
Por exemplo: Este semestre estou mexendo num SO escrito quase completamente em C++, usando o C classico soh para tratar de interrupcoes e gerar assembly.

Claro...: "Se Assembly fosse uma coisa mágica, que fizesse os programas ficarem mais rápidos simplesmente por estarem escritos em assembly, bastaria escrever seus programas em C, compilar com "gcc -S programa.c", que o GCC geraria o "main.s", que seria seu programa escrito em Assembly. Aí você compilaria o main.s com o seu assembler favorito, e seu programa ficaria mais rápido, pois estaria escrito em assembly. Isso, obviamente, não faz o menor sentido."

Isso é óbvio. Eu posso estar errado, mas não sou burro.

Eu acho que você deveria falar para os desenvolvedores do kernel Linux, que todas as funções que eles escrevem em assembly (muitas vezes por serem funções críticas, que devem ser muito rápidas), eles deveriam escrever em C (e por que não em Java, e depois geram um objeto com gcj?), já que o compilador sempre irá gerar um código mais otimizado que qualquer programador.

Claro que sim!: Kid-X, de acordo com o professor Ananias, dá sim. Dá para escrever até em Java, e gerar um objeto para ser linkado com o kernel depois! Quem sabe não trabalhamos juntos num projeto de migração do kernel Linux para Java?

Estacionado: Ananias = Klassik = Eu = John Doe = ...
Você não muda hein ?
Agora é até professor!
Formado pela Wikipedia...huahuahua

PS: se a sequência de igualdades acima é falsa, então há mais exemplares de lunáticos na web do que eu pensava...

Moda Fashion: Olha a evolução:

Pascal ---> C ---> Java

Essa sequência é a evolução temporal (nada de "mudar para melhor" conforme o dicionário - é mudança com o tempo apenas) do ensino de linguagens de programação nas grandes universidades. Eu comecei com Pascal, e até hoje não vi nada melhor para ensinar os fundamentos da computação: recorrência, recursividade, busca, ordenação, listas, pilhas, árvores, autômatos finitos, etc,etc,etc
Pascal ??? Que coisa mais véia né ?
Acontece que a linguagem escolhida não deve sobrecarregar o que interessa, tudo que eu citei não são efemeridades (talvez acabei de cunhar uma palavra nova, sinto muito...), devem ser fundamentais ainda por um bom tempo, a menos que surja uma revolução na computação (algo que eu não acredito)
Há pouco tempo descobri que estão ensinando os exemplos acima usando Java...huahuahua...coitados dos alunos, não aprendem nem estruturas de dados e nem OOP, são apenas vítimas de professores que seguem modas ditadas pelos grandes centros (aka EUA).
Que as grandes corporações imponham seus produtos ao mercado eu até entendo, mas as universidades também serem arrastadas no processo é uma piada sem nenhuma graça.

Deveria ler com mais atenção: Cadu,

o kernel do linux é um dos melhores exemplos para comprovar o que eu falei. Me citando: "Em geral, o que acontece é, em uma parte do programa, onde você consegue ver uma possibilidade de otimização que não seja trivial a ponto de o GCC percebe-la, ser válido incluir um código assembly que otimize aquela parte."

O kernel do Linux é exatamente assim. É escrito, na sua maior parte, em C. O que é específico de cada plataforma, ou onde é possível otimizar mais que o compilador, usa-se Assembly. Se o assembly fosse esse milagre que vocês descrevem, o kernel inteiro seria escrito em Asm, e não só poucas partes.

Calma...: Amigos, pensem sempre em "a ferramenta certa, para o trabalho certo". Escrever um programa que precisa ter acesso direto ao hardware, como um device driver, em uma linguagem de alto nível seria tão improdutivo quanto escrever um browser em assembly.

Eu também nunca vi browsers escritos em assembly. Certamente é possível fazer, mas não sei por que alguém o faria.

Novidade?: Eu sou o "Eu ", e acho que sempre deixei isso bem claro. "Klassik", "John Doe" e "..." eu não sei quem são, e certamente eu não sou.

Será?: Nível médio é forçar a barra. A distância não é considerável: C é assembly portável e ponto. Você só acha que o nível dele é médio por causa das abundantes bibliotecas, mas isso não muda as características da linguagem.

-- ofranja

uma linguagem procedural, est: uma linguagem procedural, estruturada em blocos, com tipos de dados estruturados, derivada de B, derivada de BCPL, derivada de Algol?

definitivamente, não é assembly, embora seja flexível e concisa o suficiente para ter caído no (mal) gosto de programadores de dispositivos de hardware...

não é assembly: permite a c: não é assembly: permite a criação de estruturas de dados complexas, tem intruções de controle estruturadas em bloco e bem mais interessantes que JMPZ, e permite a criação de abstrações de alto nível com funções e as estruturas de dados.

Só pq existe um compilador C de esperando para qual for a plataforma que vc queira programar, não quer dizer que C seja assembly.

"C eh realmente util somente: "C eh realmente util somente em baixo nivel.
Por exemplo: Este semestre estou mexendo num SO escrito quase completamente em C++, usando o C classico soh para tratar de interrupcoes e gerar assembly."

não entendi de onde vc tirou que só por estar aplicando C dessa maneira, implique que seja útil somente em baixo nível. Sabe que plataformas Unix são todas escritas em C, não? Que C é usado para criação de frameworks GUI OO como GTK?

...

E..?: Nao entendi porque estas caracteristicas inviabilizam a linguagem de ser considerada um assembly portavel.

Eh muito simples se programar proceduralmente e em blocos em assembly, e se programar sem procedimentos e sem estrutura nenhuma em C. E tipos de dados voce tem em TAL (typed assembly language) tambem. E aih?

Agora, chamar C de flexivel eh forcar um pouco. Por exemplo, qualquer um que jah programou usando listas, arrays e similares sabe como eh horrivel ter que usar casting em tempo integral para passar por cima do fraquissimo sistema de tipos da linguagem. No fim das contas, linguagem eh simples (simploria ateh), e ponto. E isso soh reforca o que eu disse.

Aproveito pra comentar sobre a linguagem C--, cujo link foi postado abaixo: eh basicamente C reformulado para melhor se encaixar na sua melhor definicao: um assembly portavel. E olha que esta definicao eh praticamente a mesma de C... :^)

E eh isso.

-- ofranja

Alto-nivel?: Abstracoes de alto-nivel, estruturas de dados complexas?

A segunda tudo bem, mesmo que seja apenas uma forma primitiva de agrupar dados. Mas abstracoes de alto-nivel? Gostaria de saber como voce definiria o sistema de tipos de Haskell, por exemplo. Deve ser de alguma coisa do tipo "magnanimo-nivel", para cima. :^)

BTW, assembly tambem permite estruturas de controle de procedimento (bloco) bem mais interessantes que um JMP: muitos processadores suportam instrucoes do tipo CALL/RET, que jah fazem grande parte da trabalho sujo (cuidam do endereco de retorno, abrem espaco na pilha, etc).

Acho que o problema aqui, entretanto, eh que estamos falando de espacos amostrais diferentes; o que inviabiliza a gente de chegar num ponto em comum.

E eh isso.

-- ofranja

Impossível: "compilar com "gcc -S programa.c", que o GCC geraria o "main.s", que seria seu programa escrito em Assembly. Aí você compilaria o main.s com o seu assembler favorito"

Fica impossível para compilar o programa com o meu assembler favorito (no caso o FASM) porque a sintaxe que o GCC geraria seria AT&T, usada no GNU Assembler (GAS) e o FASM usa a sintaxe Intel padrão.

A não ser que tenha um conversor de código assembler (suponhamos um GAS2FASM) muito otimizado. E também, os assemblers mais usados pela maioria dos programadores Assembly de x86, são FASM e o NASM. O GAS, do GNU Binutils só serve mesmo como back-end do GCC.

"Eh muito simples se programa: "Eh muito simples se programar proceduralmente e em blocos em assembly, e se programar sem procedimentos e sem estrutura nenhuma em C. E tipos de dados voce tem em TAL (typed assembly language) tambem. E aih?"

e TAL é usado onde mesmo? algum processador usa ou é apenas um projeto acadêmico sem uso prático?...

"chamar C de flexivel eh forcar um pouco."

é que desconheço uma linguagem outra além de C com a qual se possa programar em baixo nível ou alto nível, com ou sem procedimentos, com ou sem dados estruturados e com implementação para tudo quanto é plataforma. Pode me apontar uma? real?

"Mas abstracoes de alto-nivel: "Mas abstracoes de alto-nivel? Gostaria de saber como voce definiria o sistema de tipos de Haskell, por exemplo."

eu definiria, sublime. Agora, vá em frente e implemente um framework GUI em Haskell. Com Monads para controlar side-effects e IO.

tenho certeza que no fim das contas, vai se revelar uma tarefa tão ingrata quanto fazê-lo em assembly.

C é flexível, suficientemente baixo ou alto nível para qualquer tarefa que se possa imaginar. E, sem dúvida, gera código mais rápido do que qualquer compilador para linguagens funcionais. Só perde para assembly, mas essa não oferece possibilidade de se abstrair do nível de máquina...

curiosidade: Você é profissional C++ ? O que você desenvolve no seu
trabalho ?
Eu gostaria de trabalhar com desenvolvimento também, a resposta de um profissional da área seria interessante.

"Um programa Java sem a máqu: "Um programa Java sem a máquina virtual não vai fazer nada."

a não ser que você use GCJ para compilar direto para assembly nativo, claro... :)

"O GCC é um compilador extre: "O GCC é um compilador extremamente otimizado, e é muito difícil gerar um código assembly mais otimizado do que o GCC consegue gerar."

a não que seja o compilador da Intel ou o compilador C++ da M$. sem julgamentos morais, please...

Kawa e depois...lawa: Meu jesuis cristinho dos desesperados!
É óbvio que trabalhar com linguagem de máquina o tempo todo é um completo absurdo! Mas TODOS os candidatos a nerd/programador precisam saber o minimum minimorum sobre a máquina real, saber a arquitetura básica de um computador toy model, seus registradores e suas instruções e entender como uma abstração é mapeada em instruções de máquina elementares.
Outro detalhe: é um COMPLETO absurdo usar uma "linguagem orientada à bibliotecas" como Java para ensinar as bases da computação (o que fica), OOP é uma abstração (Teoria das categorias e funtores) muito grande para um novato...o(a) infeliz acaba não entendendo nem uma coisa e nem outra

Abstracoes.: Sublime, gostei da definicao. :]

"C [...]. E, sem dúvida, gera código mais rápido do que qualquer compilador para linguagens funcionais."

Esta falando de um compilador C, certo? Bom, vou assumir que voce esta falando do GCC.

Existe um exemplo bem conhecido de um programa em C e um em O'Caml, programados da mesma maneira. Pelas otimizacoes que sao feitas no programa em O'Caml, ele acaba sendo muito mais rapido. E isto, num programa trivial.

Entretanto, as implementacoes atuais que temos de linguagens funcionais nao refletem nem de longe tudo que jah se tem em pesquisa, especialmente em termos de otimizacao. Nao me espantaria de ver um programa escrito em termos muito abstratos ser tao rapido quanto um programa em C com algumas otimizacoes, com o uso destas tecnicas.

"Agora, vá em frente e implemente um framework GUI em Haskell. Com Monads para controlar side-effects e IO."

Jah existe pelo menos uma implementacao, que usa o wxWidgets.

"C é flexível, suficientemente baixo ou alto nível para qualquer tarefa que se possa imaginar."

Nao. Ele nao suporta tipos definidos pelo usuario, nao suporta tipos parametricos, polimorfismo ad hoc, e outras vantagens abtrativas que qualquer linguagem de alto-nivel decente suporta.

Tambem nao eh flexivel o suficiente para o baixo nivel necessario de um assembly, pois na maioria dos casos que se precisa de uma instrucao muito especifica do processador, insere-se um "asm()" no meio do codigo. Neste ponto, nao eh mais em C que esta se programando, e sim em assembly.

Por essas e outras, eu fico com a minha definicao inicial: C eh um assembly portavel, e soh.

E eh isso.

-- ofranja

Linguagens.: "e TAL é usado onde mesmo? algum processador usa ou é apenas um projeto acadêmico sem uso prático?..."

Bom, se eu nao me engano, dah pra botar um sistema de tipos em qualquer variante do assembly, inclusive x86. :^)

"é que desconheço uma linguagem outra além de C com a qual se possa programar em baixo nível ou alto nível, com ou sem procedimentos, com ou sem dados estruturados e com implementação para tudo quanto é plataforma. Pode me apontar uma? real?"

C++

Mas esta continua sendo igualmente ruim para se programar em alto-nivel. :^)

-- ofranja

...: "Mas esta continua sendo igualmente ruim para se programar em alto-nivel. :^)"

ainda assim, definitivamente melhor que assembly, bytecodes java ou parrot pasm.

huh...: "Existe um exemplo bem conhecido de um programa em C e um em O'Caml,"

eu não conheço. link?

"E isto, num programa trivial."

já percebeu que sempre que alguém quer vender seu peixe, ele sempre dá um exemplo trivial? ;)

"Entretanto, as implementacoes atuais que temos de linguagens funcionais nao refletem nem de longe tudo que jah se tem em pesquisa, especialmente em termos de otimizacao."

concordo. Mas ainda duvido que uma linguagem funcional possa um dia ser tão rápida quanto uma imperativa... embora eu seja um proponente do estilo functional.

"Jah existe pelo menos uma implementacao, que usa o wxWidgets."

Que é escrito em C++, aliás. :)


"Ele nao suporta tipos definidos pelo usuario, nao suporta tipos parametricos, polimorfismo ad hoc, e outras vantagens abtrativas que qualquer linguagem de alto-nivel decente suporta."

Eu disse _suficientemente_ alto nível, ou seja, pairando acima do nível de máquina e capaz de definir tipos de dados de usuário e procedimentos, que, francamente, são tudo o que é necessário para se contruir as outras abstrações que você citou. Tudo o que as outras linguagens oferecem são "syntatic sugar" para construção mais fácil dos dito-cujos sem chamadas de funções...

É por essa razão, essa flexibilidade, que torna C e C++ linguagens tão versáteis, capazes de programar dispositivos de hardware com a mesma facilidade com que são capazes de fazer coisas para as quais não foram originalmente projetadas -- como no exemplo do framework OO GTK com C, ou programação funcional com a biblioteca boost::lambda em C++...

Por fim, meu amigo, me espanta que mesmo conhecendo Haskell, linguagens funcionais, tipos paramétricos, polimorfismo e o c* a 4, vc ainda se anime com assembly... :))

huhu...: "Programs must be written for people to read, and only incidentally for machines to execute."

Obviamente, você sabe que Abelson e Sussman tinham Scheme em mente, não Java (que nem existia naquela época feliz de programadores inteligentes).

O que mais me irrita em Java é sua repetitiva redundância, tipo não ter seções public e private (como em C++ ou ObjectPascal), requerendo que cada maldita declaração venha acompanhada do devido ( e longo ) qualificador e tipo. Ah, sim, não vamos esquecer dos métodos get e set para ficarmos completamente OO. Mesmo quando o bom-senso nos diz que pessoa.nome sempre vai ser uma string.

É realmente uma linguagem para os operários do software, pessas com parcos conhecimentos de ciência da computação, peças sobressalentes e sem criatividade que só sabem criar código copiando e colando e dando nomes longos e imbecis segundo as regras vigentes definida por um ex-programador Cobol. Apesar disso, essas medidas e o uso de uma linguagem limitada e inflexível não fazem um bom sistema. E eu regojizo com isso a cada falha estúpida e problemas com prazos no sistema web com servlets da minha empresa. E não, obviamente não sugiro PHP ou ASP como soluções, pois são ainda piores...

"mas sim que ele cumpra com os pré-requisitos."

sem dúvida. E o que vier é bônus, como performance, concisão no código (maior manutenabilidade) e outras qualidades não associadas à linguagem Java.

"Analizando por esta perspectiva qualquer programador em sã consciência perceberá que Java é muito mais legal do que parece."

Lamento, mas não. Sua verborragia mata concisão, torna manutenabilidade um terror e exige IDEs pesadas para se poder fazer qualquer coisa útil, já que do contrário, o programador teria que ficar lutando contra as próprias limitações e excessividade da linguagem, ao invés de focar no problema a ser resolvido...

"Sua abrangente API resolve grande parte dos problemas"

Dos mesmos Abelson e Sussman, no "Revised 5th Report on the Algorithmic language Scheme", na Introdução:

"Linguagens de programação deveria ser projetadas não empilhando-se recursos em cima de recursos, mas sim removendo as fraquezas e restrições que fazem recursos adicionais parecerem necessários."

Realmente, java, a linguagem, é muito restrita, inflexível e limitada. Seu único caminho viável são toneladas de bibliotecas e IDEs pesadas. Muita gente faturando pesado com uma linguagem estúpida através de cursos, ferramentas para lidar com o bicho e prazos longos e lucrativos para projetos por causa da lerdeza na criação de sistemas por conta de uma ferramenta equivocada...

", simplicidade"

tem certeza que está falando de Java? Desse Java?


public class Pessoa {
private String nome;
private int idade;

public String getNome() { return nome; }
public int getIdade() { return idade; }

public static Pessoa( string nome, int idade ){
this.nome = nome;
this.idade = idade;
}
}

joao = new Pessoa( "João Foobar", 33 );
joao.nome // => "João Foobar"
joao.idade // => 33


espero que um equivalente em Scheme (sem qualquer coisa especificamente OO) não seja simples demais:


(define (pessoa nome idade)
(lambda (atrb)
(case atrb
((nome) nome)
((idade) idade)
(else (error "Mensagem inadequada para pessoa")))))

(define joao (pessoa "João Foobar" 33))
(joao 'nome) ;; => "João Foobar"
(joao 'idade) ;; => 33


Obviamente, usando um sistema OO portável em Scheme tornaria as coisas ainda mais simples.

" e clareza do código"

ler 10 declarações "private static foo" seguidas dá dor de cabeça...

ler psJoaoClaudioNogueira.getDeclaracaoImpostoRenda( 2005 ).calculaDividendos() é um grande pé-no-saco. E é o terror da manutenção! Não seria muito melhor:

imp = joao.impostoRenda( 2005 )
imp.calculaDividendos()

(obviamente, não precisamos declarar o tipo de imp pq o exemplo é em Python :)


"(desde que não seja feito por um desses programadores "malucos", aqueles que insistem em usar nomes de variáveis do tipo "i", "x", "args")"

Quem será mais maluco, hein?

Programadores experientes que dão valor ao bom-senso e à manutenabilidade que usam nome curtos e concisos para variáveis locais de loop (famosas inclusive) como i, c (o que seria de c++, hein?) e args (para argumentos), ls (lista) ou p (pessoa, se houver uma classe dessas por perto)?

Ou programadores "enterprise", que seguem padrões rígidos (ainda que contra o bom-senso) e usam variáveis com nomes tão longos e absurdos quanto possível, com notação húngara, como "iContadorLocal" ou "string PessoaFisica.fRetornaNomePessoaFisica()" e frameworks imensos e incomensuráveis para linguagens estúpidas, inflexíveis e limitadas como Java?

"tornam o entendimento de qualquer método uma tarefa trivial"

é realmente notável a capacidade humana de adaptação ao ambiente. Programadores C ou assembly acham incompreensível a falácia do pessoal OO. Programadores funcionais acham o pessoal imperativo uns bárbaros do mau-gosto.

Acho que no fim das contas, o entendimento está nos olhos de quem vê.

Porém, já ouviu a expressão "O silêncio é ouro"? Acho que a concisão de expressão de linguagens como Scheme contrasta beneficamente contra a gritaria de declarações, redundâncias e toneladas de imports de Java.


"Talvez por isso que muitos projetos "Open Source" não vão pra frente ou param no caminho (de uma olhada na atividade da maioria dos projetos do sourceforge), cada um que "bota a mão" faz uma "salada" e no fim o negócio fica indigerível"

Salada se faz em qualquer linguagem, veja os vários projetos web JSP. Juntou java e xml, então, putz! verborragia ao molho pardo...


"Se o Brasil tem a maior comunidade Java isso me tranquiliza em saber que aqui não existem tantos "malucos" que ainda insistem em brincar com ponteiros, registradores e alocação de memória em um tempo onde o que interessa é funcionalidade e mantenabilidade."

e venda de ferramentas e cursos para domar a complexidade inerente a uma solução estúpida, não se esqueça! :)

Lembrando que o Brasil é um ótimo mercado para porcarias tecnológicas importadas, já que não desenvolve suas próprias tecnologias. Nem nunca desenvolverá, se sempre depender de alguém lhe vendendo um framework já pronto, sem saber como alocar memória na mão ou como criar suas próprias abstrações a partir do básico que toda máquina lhe oferece: memória, intruções de máquina e registradores.

não que eu seja programador assembly, mas é importante...

Grande programador!: Kid-x,

você, como grande programador em Assembly, deveria saber melhor do que ninguém que a função do Assembler é simplesmente traduzir o pseudo-código para código binário. Assim, o assembler utilizado é diferente. Um assembler para sintaxe intel vai pegar um "mov byte ptr" e gerar o mesmo código que um assembler para sintaxe at&t geraria para um "movl".

ps.: há muito tempo não uso assembleres com sintaxe intel, então não sei se o código correto para copiar um valor de 4 bytes é "mov byte ptr", mas dá pra entender a mensagem da mesma forma, não dá?

UAU2!!!: Ô teacher Ananias!!!
O post acima é que se pode chamar de uma aula viu ???

Hein?: Primeiro: nao sei de onde voce tirou isso, mas eu nao estou me animando com Assembly; estou dizendo que C nao eh alto-nivel. Desde o comeco. Volte no inicio da thread e de uma olhadinha.

Segundo: C soh consegue construir ALGUMAS abstracoes, de uma maneira muito tosca, e usando ninguem-mais-ninguem-menos que um preprocessador.

Terceiro: C++ eh outra linguagem. A minha critica eh com relacao a C, que nao tem metade das abstracoes e/ou recursos que tem C++. Entretanto, C++ tambem tem seus problemas. De uma olhadinha em alguns comentarios mais pra frente desta noticia, onde o Patola fala da sua experiencia com a linguagem. Eh bem instrutivo.

Quarto: exatamente, voce diz que C eh alto-nivel por causa das bibliotecas! Va usar a API do GTK em outras linguagens que sao *realmente* de alto-nivel para entender a diferenca.

Quinto: eu sei que a wxWidgets foi escrita em C++. E que nao foi escrita em C - que foi a principal razao de ter comentado sobre ela. Ou melhor, sobre um binding existente para Haskell, que usa monadas, e tudo que se tem direito.

A proposito, nao vejo porque seria tao dificil programar desse jeito como eh programar em assembly. Acho que o maior problema de se programar funcionalmente eh a inercia de sair do estilo de Von Neumann. Mas a partir daih, programar de maneira imperativa comeca a ser a tarefa mais macante da face da terra. :^)

E eh isso.

-- ofranja

E?: Eh, talvez soh alguem louco o bastante pra programar em alto-nivel usando C teria a capacidade de usar algum assembly especifico para fazer o mesmo. :^)

-- ofranja

Nao concordo.: Isso nao eh inevitavel. Uma VM modularizada resolveria muito bem esse problema do carregamento lento. Nada que um projeto/implementacao bem feitos nao resolva.

-- ofranja

email: patola arroba gmail.com
ou
patola arroba linuxfud.org

Aí conversamos sobre isso =)
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Discordo.: Muito interessante seu longo post, mas, ao invés de enveredar longamente na discussão, vou só colocar alguns pontos importantes dos quais discordo:

sem dúvida. E o que vier é bônus, como performance, concisão no código (maior manutenabilidade) e outras qualidades não associadas à linguagem Java.

Você associa concisão a maior manutenabilidade (é essa mesma a palavra? eca!), mas nunca vi esse tipo de associação antes. Pelo contrário: todos os programas dos concursos de programas ofuscados, como esse, são incrivelmente compactos e concisos, fazendo muita coisa numa grama de código.

Numa mesma linguagem, só o fato de você ser mais conciso pode dificultar muito a leitura; por exemplo, "if (!strcmp(str1, str2))" é a mesma coisa que if (strcmp(str1, str2) == 0)", mas a segunda forma é bem mais fácil de ler fluidamente do que a primeira. Ao ler a primeira forma, você tem que parar e pensar: peraí, o que isso testa? Se é igual ou diferente? strcmp() retorna zero se forem iguais, zero é falso em C, e a condição nega o resultado... peraí... Já na segunda, vai de cara.

Além disso, a minha experiência em particular mostra o oposto do que você fala. Você parece ter ojeriza aos nomes longos, mas você já teve, no seu trabalho, que pegar código de outras pessoas pra ler e manipular? Já me safei de boas encrencas por pegar código com nomes verbosos e "no estilo java", apesar de serem em C++.

Um pouco de bom-senso é necessário. Em um loop curto em que você não vá usar a variável dentro, mais vale chamar de "i" do que factoryProductsLoopCounter. Mas se seu loop tem 600 linhas e por várias vezes a variável de loop é referenciada e até modificada, mais vale o nome longo da segunda.

Para mim, pelo menos, o que me faz ser lento ao escrever código não são coisas triviais como tamanho dos nomes das variáveis, métodos e funções, e sim a própria complicação do algoritmo. E ao ler código, eu prefiro métodos beeem explicadinhos que me ajudam a manter a abstração deles na cabeça.

Ok, dado esse ponto, que parece ser a totalidade do seu argumento (e que não estou muito interessado realmente em contra-argumentar, apenas em "dar um toque" que o que você chama de facilidade não é igual pra todos), gostaria também de reclamar que sua mensagem não está muito bem-escrita em termos de argumentos. Ela usa de falácias demais pra tentar convencer, desde apelo a preconceitos até conclusões irrelevantes. Não vou passar a limpo onde está cada um deles porque seria confrontativo demais, mas pediria para que melhore como coloca seus argumentos em mensagens vindouras.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

ah, é?: "Segundo: C soh consegue construir ALGUMAS abstracoes, de uma maneira muito tosca, e usando ninguem-mais-ninguem-menos que um preprocessador."

Pode me indicar onde exatamente é usado um preprocessador no código abaixo que define um simples ADT? Não há qualquer macro, apenas dados , procedimentos e information hiding através de variáveis com escopo léxico...



#include "stdio.h"

typedef struct _Pessoa *Pessoa;
struct _Pessoa {
char *nome;
int idade;
void (*se_apresenta)();
};


Pessoa new_Pessoa( char *nome, int idade ){
Pessoa p = ( Pessoa )malloc(sizeof( struct _Pessoa ));

p->nome = nome;
p->idade = idade;

/* definição de um "método" */
void se_apresenta(){
printf( "Olá, meu nome é %s e tenho %d anos.\n", p->nome, p->idade );
}
p->se_apresenta = se_apresenta;

return p;
}


int main( int argc, char **args ){
Pessoa p = new_Pessoa( "nemesis", 30 );
p->se_apresenta();
}


Se isso não for _suficientemente_ alto nível, mas sim do nível de assembly, eu como minhas cuecas...


"Quarto: exatamente, voce diz que C eh alto-nivel por causa das bibliotecas!"

Não. Minha intenção com GTK foi mostrar que C é _suficientemente_ baixo ou alto nível: foi baixo nível o bastante para criar um framework OO completo de criação de widgets gráficos _a partir do nada_ e _suficientemente_ alto nível para permitir se criar aplicativos usando esse mesmo framework na própria linguagem.

Suficiente, essa é a questão. Óbvio que programar GTK com Python é bem mais prazeroso, mas a questão é que é perfeitamente aceitável em C, pois a linguagem oferece abstrações _suficientes_.

"Quinto: eu sei que a wxWidgets foi escrita em C++. Ou melhor, sobre um binding existente para Haskell, que usa monadas, e tudo que se tem direito."

Sim, mas a questão é essa: não é uma implementação em Haskell, apenas uma interface para um sistema escrito numa linguagem que consegue fazê-lo. Com C ou C++, você cria infraestrutura ou aplicativos. Com Python ou Haskell, você não está muito bem equipado para criar a infraestrutura, apenas a utilizar alguma já existente...

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

re:: "Você associa concisão a maior manutenabilidade (é essa mesma a palavra? eca!)"

Não sei se é o termo certo, mas, sim, concisão de expressão é importante para manutenção de código. Por concisão não quero dizer eliminar espaços em branco, dar nomes monosilábicos a toda e qualquer variável ou outras obfuscações. Concisão me remete a clareza e economia de expressão.

Exemplo de como falta de concisão complica as coisas: IDEs tornam incrivelmente fácil se escrever código "spaghetti" através do uso de hierarquias profuuundas em linguagens OO. Isso significa que o cara vai, através de code-completion, pesquisando fundo nas hierarquias até encontrar um método de seu interesse. TUDO na _mesma linha_. Então, por exemplo:


begin
frmFuncionario.dtsFuncionarios.LoadFromDataSet( unFuncionario.fPesquisaPorNome( frmFuncionario.edtNome.Text ) );
end;


Uma leve mostra de estúpido código Delphi com que tenho que lidar todo dia no trabalho. Uau, realmente descritivo, não? Não, sério, concordo que é descritivo, mas excessivo demais, e a falta de concisão na expressão do código acima é temível. O cara que está lendo essa merda tem que ficar constantemente correndo com o scroll pro lado pra ver o que está acontecendo! Isso cansa a vista e mina a paciência...

Perceba como alguns poucos ajustes podem ajudar um bocado:


var DataSet ds, funcs;
string nome;
begin
with frmFuncionario do
begin
ds = dtsFuncionarios;
nome = edtNome.Text;
end;

funcs = unFuncionario.fPesquisaPorNome( nome );
ds.LoadFromDataSet( funcs );
end;


Talvez eu tenha escolhido a palavra errada: concisão. O código acima usa mais caracteres e linhas do que o anterior. No entanto, não acho que estarei sozinho na opinião de que o código acima é bem mais legível e menos "verborrágico", por assim dizer, do que o anterior. Você bate os olhos e rapidamente vê tudo que está acontecendo de uma só vez, sem apelar pra scroll. Me parece muito mais claro e fácil de lidar (e manter).

Obviamente, aficcionados por Delphi notarão que é possível tornar o anterior mais legível simplesmente fazendo-se algo como:


frmFuncionario.dtsFuncionarios.LoadFromDataSet(
unFuncionario.fPesquisaPorNome(
frmFuncionario.edtNome.Text ) );


Bem, agora você também vê tudo de uma só vez, mas você continua tendo que percorrer hierarquias sem fim com os olhos até finalmente encontrar a função chamada e os parâmetros que ela requer.

"mas nunca vi esse tipo de associação antes"

bem, está vendo agora e tenho certeza que vai lembrar disso pelo resto de sua vida profissional. :)


"Um pouco de bom-senso é necessário."

Sem dúvida. Lamentável é que se perca tempo com tantos "padrões" de nomenclatura que o desafiam constantemente...

"Mas se seu loop tem 600 linhas e por várias vezes a variável de loop é referenciada e até modificada, mais vale o nome longo da segunda."

Aí, é que está! Cadê a concisão em um loop com 600 linhas??! Um programador que faz uma porra dessas devia ser metralhado! E ainda aposto que boa parte desse volume seria puro copiar-e-colar demente, prontamente passível de ser parametrizado e devidamente posto numa função. Eu sei que é assim, pois volta e meia tenho que consertar essas monstruosidades no trabalho...

Existe um conceito que diz que uma função (ou procedimento, subrotina, método etc) deveria caber em uma tela, pra você bater o olho e ver tudo o que é feito de uma só vez. Eu concordo, mas obviamente pessoas não vão concordar com o tamanho dessa tela ou da fonte usada... :P


"Para mim, pelo menos, o que me faz ser lento ao escrever código não são coisas triviais como tamanho dos nomes das variáveis, métodos e funções, e sim a própria complicação do algoritmo."

Tudo bem, mas code bloat derivada de copiar-e-colar ou code completion excessivo não prejudica que está _escrevendo_. É só na hora da manutenção que a sujeira aparece...

"E ao ler código, eu prefiro métodos beeem explicadinhos que me ajudam a manter a abstração deles na cabeça."

explicadinho é uma coisa, ruídos, falta de bom senso, excesso de declarações são outra. Prefiro código claro e limpo do que um monte de redundância em nome de supostas "boas práticas". Boa prática pra mim é KISS.

"Ela usa de falácias demais pra tentar convencer, desde apelo a preconceitos até conclusões irrelevantes."

esperei que os exemplos dados falassem por si, mas se uma pessoa já se acostumou com code bloat "enterprise", notação húngara, xml ou mnemônicos assembly, está fora do alcance de qualquer ajuda... :)


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

Correto: Eu deveria ter dito "O GCC é um compilador extremamente otimizado, e é muito difícil, para um humano gerar um código assembly mais otimizado do que o GCC consegue gerar."


Os compiladores da MS, ou da Intel, para C++ realmente são mais otimizados que o gcc (ou g++). Entretanto, para C, eles competem mais ou menos no mesmo nível.

ooops...: ok, gostaria de me desculpar pelo falho exemplo acima: é um exemplo do que ocorre quando você passa tempo demais com abstrações de alto nível em linguagens superiores, quando você se acostuma com garbage-collector, clausuras léxicas, polimorfismo, inferência de tipos etc. Não que o exemplo não rode, mas se se exigir mais dele, dará Segfaults.

O problema é que fazia tempo que não mexia com C e como tenho estado bem animado com Scheme, fui tentar em C o que facilmente consigo com Scheme: encapsulamento e data hiding através de closures com escopo léxico. Eu defini a função se_apresenta internamente à função constructor e retornei seu endereço para o devido campo no struct. Porém, me equivoquei em tratar as abstrações de C no mesmo nível que as de Scheme: a função só existe durante a chamada à new_Pessoa! Ou seja, da primeira vez que é chamado, até ainda pode rodar, mas na segunda chamada, vai dar pau, pois provavelmente o código correspondente já terá sido desalocado da memória...

Mas, não desanimemos: C possui abstrações de alto nível _suficientes_, como eu disse. Embora, eu não seja mais capaz de usar a conveniente notação típica OO como p->metodo(), por não ser capaz de passar implicitamente para a função correspondente o argumento p, isso seria apenas "syntatic sugar". Mas é plenamente possível usar um esquema de notação usando abstrações tradicionais na forma de funções.

Por exemplo: void pessoa_apresenta( Pessoa p ); de forma que escreveríamos pessoa_apresenta( p ) ao invés de p->se_apresenta.

Procedimentos e aplicação de procedimentos são a base de toda a computação, desde a Máquina de Turing, ao cálculo Lambda de Church. Linguagens de alto nível apenas provêem _suficiente_ "syntatic sugar" para tornar expressar tais computações de uma forma mais aprazível. C possui _suficiente_ "syntatic sugar" para dar conta do recado em muitas aplicações de alto nível.

e é isso. :)


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

Abstrações.: Não é por nada, mas.. orientação a objetos? Essa você apelou. :^)

Não é isso que faz uma linguagem de mais alto nível que outra - pelo menos na minha opinião. Assembly, obviamente, não permite estruturas de dados com campos nomeados, mas isso não te impede de abrir um espaço de memória, e colocar lá dentro os dados/métodos. Quando quiser chamar um método, é só deferenciar o espaço de memória onde está o objeto, mais o deslocamento pro método. E executar um call/jmp. Olha que interessante: será possível extender uma "classe" e continuar usando o mesmo código para tratar as "subclasses"! O único problema, como já falei, é que você não pode nomear nada, nem definir permissões de acesso. Mas não deixa de ser orientado a objetos. :^)

O meu ponto continua sendo: C não é alto-nível. Ele tem poucas abstrações, e primitivas demais. Além das que eu comentei, podia citar muitas outras que as linguagens modernas suportam, como pattern matching ou templates. Vale comentar também que, apesar de C ter uma construção 'typedef', ela nada mais é do que um criador de sinônimos, não um construtor de tipos como o de SML, por exemplo.

Entretanto, não estou questionando a capacidade de *baixo-nível* de C, só estou expondo a sua não-capacidade de um alto-nível, digamos, a um nível desejável. Se eu tivesse que fazer uma aplicação que trabalhasse com hardware, por exemplo, faria um pequeno código em C que exportasse os dados ou a memória, e algumas funções primitivas (se necessário) para uma linguagem de alto-nível, e aí sim faria a lógica do programa. O que seria um bom uso das capacidades de C: ser um assembly portável. Mas tentaria minimizar o código em C, assim como se tenta minimizar os códigos em Assembly, atualmente. Vale lembrar, no final das contas, que não é só a "syntatic sugar" que está em jogo. São coisas como a garantia que um programa "safe" nunca gere falha de segmentação (muito importante, inclusive para a segurança), a rapidez em se programar e outros paradigmas de programação (fora o imperativo) que são muito melhores para resolver vários problemas (funcional, para tranformações em árvores, por exemplo).

Mas acho que já falamos o suficiente, e que isto está virando uma questão de opinião. Eu não vou mudar de idéia sobre C e alto-nível, então termino a minha parte da discussão por aqui. :^)

E é isso.

-- ofranja

Claro.: Pra fazer, o programador em C levaria até menos tempo.

O problema, é quanto tempo levaria para debugar.

-- ofranja

não é apelo: é pura mostra do que C é capaz, dada sua flexibilidade. Lamento se vc só usa a linguagem para programar dispositivos, mas também não há aqueles que só usam Haskell para computar fatoriais?

Ficou abismado com OO em C? Alguma vez na vida já deu uma olhada em aplicativos C usando GTK? Tem o gtk-demo que você pode tentar na linha de comando do Linux, vem nas distribuições GTK recentes e é inspirado no tcl-demo, onde você tem um demo com menus, onde cada item é um pequeno aplicativo, e há um botão ao lado de cada um que mostra o código-fonte. Pode lhe ser instrutivo.

O pessoal de GTK usa a sintaxe convencional por meio de funções, com uma nomenclatura rígida que visa emular a hierarquia de classes de um framework OO. Assim, você tem por exemplo: gtk_window_set_title( GTK_WINDOW( jan ), "teste" ); e por aí em diante.

Mas, sim, é possível usar a sintaxe que indiquei acima, se você quiser. Pensando um pouco a respeito, é possível fazer:


Pessoa pessoa( Pessoa p ) {
void se_apresenta() {
prinf( "Olá, meu nome é %s e tenho %d anos.\n", p->nome, p->idade );
}
p->se_apresenta = se_apresenta;
return p;
}



Ou seja, você cria uma função que define os "métodos" da "classe" e os coloca na instância, para ser usado de imediato. Você os chamaria assim:


int main( int argc, char *args ) {
Pessoa joao, paulo;
joao = Pessoa( "João Paulo", 22 );
paulo = Pessoa( "Paulo João", 19 );

pessoa( paulo )->se_apresenta();
pessoa( joao )->se_apresenta();
}


O que sem dúvida é muito mais "clean" e alto-nível do que um esotérico "abrir um espaço de memória, e colocar lá dentro os dados/métodos. Quando quiser chamar um método, é só deferenciar o espaço de memória onde está o objeto, mais o deslocamento pro método. E executar um call/jmp.". Um usuário de Java é capaz de compreender o código acima.

Isso, meu chapa, é coisa que assembly nenhum, TAL ou não, faz. C não é assembly, embora certamente possa ser usado assim, dada sua flexibilidade.

Enfim, pra encerrar nossa discussão vou frisar uma última vez o que tenho dito desde o começo: C é alto-nível o _suficiente_. Está muito distante de Haskell ou OCaml e até de seu par C++. Mas dá conta do recado em qualquer tipo de situação sem nenhum problema, desde que o programador seja habilidoso.

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

Isto está ficando ridículo.: Claro que fiquei abismado com o "OO" em C! É muita apelação! Eu fazia isso quando comecei a programar (5 anos atrás) e não conhecia nada além de C, Delphi e Java. Tentando colocar um eufemismo na frase, eu chamaria isso de 'uma enjambração muito tosca'. É que nem tentar usar um alicate para fixar um prego na parede: dá certo, mas você vai ter muito, *muito* mais trabalho, e o prego vai acabar ficando torto. :^)

Mas então, vamos falar do seu exemplo da orientação a objetos em C. Mostre agora o polimorfismo básico: usar uma sublasse no lugar de uma superclasse. Sem casting, claro. Faça também uma herança simples, quero ver como funciona em C. Não funciona? Isso que é orientação a objetos? Sei.

C foi feito para um simples propósito: escrever sistemas operacionais portáveis, e ponto. Ele não tem sequer tipos paramétricos. Você precisa fazer casting (AKA passar por cima do sistema de tipos) se quiser criar um "container" (lista, array) genérico. Logo, é um procedimento necessário para a programação na dia-a-dia. Isso é alto-nível? Uma linguagem estaticamente tipada com um sistema de tipos tão simplório (e até ridículo) não é alto-nível. Você sabe o que casting acarreta, não? Se não sabe, leia sobre, porque é a pior coisa que um programador pode fazer neste contexto.

Cá entre nós, nem sequer escrever sistemas operacionais é um bom uso de C, porque C++ funciona muito melhor nesse aspecto, especialmente pelos problemas de casting que comentei acima. Isso é fato. Eu programei em C pra sistemas embutidos algumas vezes, mas mais por comodismo: ainda estou aprendendo C++. Poderia muito bem ter feito em C++, e a solução teria ficado muito melhor.

Você também pode lamentar o meu (não-)uso de C, mas eu lamento que você não tenha percebido ainda o quão ultrapassada ela é. O fato de muita gente programar em C para fazer aplicativos não quer dizer nada. É só uma herança, um legado histórico. Pelo visto, nem mesmo você mais programa em C, então não vejo porque a defende tanto.

Sobre GTK: já fiz alguns aplicativos para GTK usando C, Perl e O'Caml, e usando as duas versões da API do gtk. Inclusive, portei o mesmo aplicativo pras estas três. E eu posso te dizer, com certeza, que eu prefiro ficar com a última, sem nem pensar duas vezes. Aconselho você a tentar o mesmo. :^)

Também aproveito pra ressaltar que é óbvio que o código em C é mais simples de entender que o Assembly. Claramente, não era meu objetivo provar o contrário. Mas como falei, *você só deu nomes para as funções*. Todo o resto de orientação a objetos, C também não tem.

Por fim, eu deixo aqui meu desabafo: existem dezenas, e até centenas de linguagens conhecidas para se fazer programação geral. Porque ficar com uma só? Uma ferramenta para todo problema não é algo prático, ainda mais se for uma ferramenta desprovida de tantos recursos que são encontrados nas linguagens mais modernas. Enfim, eu não vejo porque alguém ainda programa em C se C++ faz o mesmo trabalho desta, e de uma maneira muito melhor. Acho que é mais uma questão de comodismo/religião do que de praticidade. :^)

Bem, e é isso.

-- ofranja

ok: "C é alto-nível o _suficiente_. Está muito distante de Haskell ou OCaml e até de seu par C++. Mas dá conta do recado em qualquer tipo de situação sem nenhum problema, desde que o programador seja habilidoso."

o que exatamente aí em cima você não entendeu? o "_suficiente_"? o "está muito distante"? ou o "desde que o programador seja habilidoso"?

por fim: estava apenas bancando o advogado do diabo. Gosto do lema: "a ferramenta certa para a ocasião" e acho saudável a mistura de linguagens e paradigmas. Mas tive que defender C da retórica batida de que é "apenas assembly portável", o que é um desmerecimento de suas capacidades -- que estão além de qualquer assembly.

Pessoalmente, prefiro Scheme e Ocaml no espectro de linguagens dinamicas e estáticas.

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

python vs java e o futuro: bancando o advogado do diabo mais uma vez... :)

"Quanto ao Python, é uma linguagem de script, nem vale mencioná-la."

Claro que vale. Tradicionalmente, linguagens de script são interpretadas ( daí o script, como um ator interpretando-o ) e tem facilidades no acesso a recursos do sistema, como execução de subprocessos e IPC. Python ( e Perl e Ruby ) evoluiu muito como linguagem a partir de suas origens como mera ferramenta de script para automações e hoje não é meramente interpretada ( compilada para bytecodes ) e, por causa de sua grande portabilidade, não é tão fácil de se acessar aqueles recursos ( normalmente vai involver importar algum módulo ) quanto numa genuína linguagem de script, como em linguagens de shell como bash ou command.com.

"Qual é a diferença do Python para o Java, nesse sentido, já que o python na verdade compila o código para bytecode e o executa assim? Então java também é uma linguagem script, nesse sentido. Tanto que existe o Jython, que compila para bytecode da JVM."

Ok, eis o que acontece: já ouviram falar em linguagens estaticamente tipadas ou dinamicamente tipadas? early-binding vs. late-binding? Pois a confusão que está ocorrendo aqui é precisamente essa.

Java é uma linguagem que usa um runtime (JVM) para rodar bytecodes compilados , da mesma maneira que Python. Mas as semelhanças terminam aí.

Esqueçam o conceito estúpido de linguagens de script: o negócio aqui é que Java é uma linguagem estáticamente tipada e Python dinamicamente tipada. Em outras palavras: os tipos de Java são conhecidos em tempo de compilação, os de Python, não. Quando você declara uma variável em Java, digamos:


Pessoa p = new Pessoa( "foobar" );


Essa variável tem um tipo associado, que foi explicitamente declarado. O compilador gera código, em _tempo de compilação_, para lidar com a checagem e corretude dos tipos associados àquela variável daí em diante.

Com Python, simplesmente fazemos:


p = Pessoa( "foobar" )


Até aqui, tudo bem. Mas Python não precisou declarar o tipo da variável. As _variáveis_ em Python não têm tipo associado, mas sim os _valores_ que elas contém, em determinado momento. Esse valor, só é conhecido em _tempo de execução_. Qualquer checagem de tipo deve ser feita explicitamente, em _tempo de execução_, e é isso que torna linguagens dinâmicamente tipadas consideravelmente mais lentas que suas similares estaticamente tipadas.

Além de outros fatores de implementação, por exemplo, obviamente o compilador JIT hotspot do Java 5 é muito mais potente do que a VM do Python.

mas essa é uma longa guerra, que se iniciou com linguagens de alto nível vs. antigas linguagens de alto nível há muito tempo atrás. Por exemplo, Fortran era consideravelmente alto nível quando surgiu, até que Lisp surgiu e introduziu alocação automática de memória, instruções if e um pensamento geralmente voltado à performance do programador e ao problema a ser resolvido do que à performance do programa e de detalhes de implementação.

Mesma coisa em Java vs Python.

"o que dizer do Object Pascal, também?"

é uma linguagem imperativa, estaticamente tipada, com extensivas e cansativas declarações de tipos, estruturada em blocos de escopo léxico, com sintaxe verborrágica diretamente descendente de Algol e um sistema OO implementado pela Borland. respondi a sua pergunta? ;)

Percebam por favor que ser estaticamente tipada não necessariamente causa lerdeza na performance do programador. Linguagens alto-nível realmente modernas, poderosas e flexíveis podem ser estaticamente tipadas, mas concisas e flexíveis como uma linguagem dinamicamente tipada.

Elas oferecem poderosas abstrações como você possivelmente jamais verá em Java: como inferência de tipos ( embora estaticamente tipadas, as variáveis não precisam, normalmente, ter seus tipos explicitamente declarados: eles são deduzidos no seu uso nas expressões ), módulos polimórficos, polimorfismo de tipos, declaração de operadores, declaração de funções por pattern-matching, recursão por tail-call automática ( recursão não causa estouros de pilha, porque é identificada e compilada como um loop goto ).

O melhor exemplo que conheço de tal linguagem moderna é Haskell:

http://www.haskell.org

e

http://www.haskell.org/ghc

Para seu poderoso compilador para código nativo de máquina.

Na minha opinião, Haskell é a culminância de anos de pesquisa em linguagens funcionais como Scheme e OCaml, além de muitas conveniências e uma sintaxe mais concisa em relação às duas. Não vai se arrepender.


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