Não entendo..: Não entendo porque ficar publicando notas de tais sites, e que não publica o link q interessa.

Tem que ser coisa de Augusto, mesmo..

links: Oi Gerson! Já que aproveitei a íntegra do texto publicado no outro site, acho justo manter o link para ele. Mas sempre vou apreciar se você me enviar notícias na forma como você prefere as ver publicadas.

Acho isso ruim e bom...Me apr: Acho isso ruim e bom...Me aprece que a SUN está querendo tirar o corpo fora e entregar a batata quente pra comunidade...Acho que se for isso, teremos um problema, pois precisamos do apoio de tal empresa...Por enquanto, pelo menos pra mim, a maior novidade do OpenOffice é o módulo para Banco de Dados...O programa para Gráficos piorou, o editor de texto segue na mesma, o tema de ícones padrão continua desbotado...E onde eu esperava uma sincera evolução, era no software editor HTML...Coisa que não ocorreu.Ah, o desempenho ficou ainda pior!

P.S. Brain, Onde está a matéria sobre Software Livre, publicada pela Revista Veja e reproduzida pelo Linux FUD, que eu indiquei?

Sei não..: O módulo de banco de dados depende do Java, e isso é um problema. Se a Sun tá saindo fora, devia deixar a implementação de java dela na LGPL tbm...

A implementação Java do OpenOffice já é LGPL: O OO está tendendo para o Java, mas a implementação é toda livre. Pode conferir:

$ head -13 ContainerFactory.java
/*************************************************************************
*
* $RCSfile: ContainerFactory.java,v $
*
* $Revision: 1.2 $
*
* last change: $Author: misha $ $Date: 2002/05/06 18:23:40 $
*
* The Contents of this file are made available subject to the terms of
* either of the following licenses
*
* - GNU Lesser General Public License Version 2.1
* - Sun Industry Standards Source License Version 1.1


Ou seja, o que está escrito em Java no OO está liberado sob os termos da LGPL juntamente com os da SISSL, o que deve ter produzido uma salada jurídica que a Sun entendeu ser difícil administrar. Agora estão se livrando da SISSL, ficando só com a LGPL.

Motivos para comemorar!

Marcos Alexandre: O Java do OO pode ser compilado com o GCJ, por isso não fica restrito à licença da máquina virtual. A idéia de usar Java é pra facilitar a multi-plataforma e o fato do Java ter uma grande base de usuários.

Gradualmente a Sun está se abrindo mais ao software livre, isso é positivo. Ela tem bons produtos que não vão pra frente por ela ser restritiva nas suas licenças. O .NET está aumentando demais o seu mercado e pode consolidar o domínio da MS sobre os outros sistemas, ficando mais difícil aplicativos multi-plataforma. E o único adversário dele é o Java, que não tem um apoio forte da comunidade de SL.

Haskell developer

__Conordo.Vendo por esse angu: __Conordo.Vendo por esse angulo é díficil imaginar a SUN, numa situação, senão ruim pelo menos crítica, se livrar do OO.

A comunidade deveria amar o Java e a Sun: O .NET está aumentando demais o seu mercado e pode consolidar o domínio da MS sobre os outros sistemas, ficando mais difícil aplicativos multi-plataforma. E o único adversário dele é o Java, que não tem um apoio forte da comunidade de SL.

Esse é um daqueles contra-sensos da comunidade que a gente não consegue entender. A comunidade apoia o Mono que é clone do .NET da Microsoft, que é totalmente contra Linux e Software Livre. Essa mesma comunidade escoiceia o Java, que é livre, que definiu um patamar industrial de produção de software, descaradamente copiado pelo .NET, e a própria Sun, uma empresa que colabora abertamente com a comunidade, tendo liberado o antigo StarOffice, hoje OpenOffice, por exemplo, sem contar inúmeras contribuições para o Linux, sem a qual não seria o SO que é hoje.

Prefiro tentar entender as mulheres. Aliás, eu era mais feliz quando me dedicava a elas.

e isso...: "O .NET ... pode consolidar o domínio da MS sobre os outros sistemas, ficando mais difícil aplicativos multi-plataforma."

...vindo de um "Haskell developer"!

pq será tão mais difícil "aplicativos multi-plataforma"? Pq essa dualidade no mundo da informática? é só Sun ou M$? é só java ou .net? é só software proprietário ou software livre? emacs ou vi? gnome ou kde?

pq o maldito número mágico 2??!!

Que eu saiba, existem N ótimas opções, só para ficar com exemplos em software livre, de ferramentas para se desenvolver "aplicativos multi-plataforma". Haskell mesmo um bom exemplo, assim como Python, Ruby, Perl, Common Lisp, OCaml, C/C++ e várias outras.

As VM java e .net podem afundar, na minha opinião. Com a parrot VM, llvm, vários compiladores nativos e outras opções, qualquer um pode desenvolver bons "aplicativos multi-plataforma" com ferramentas completamente livres e linguagens mais avançadas, expressivas e concisas que java/C#.


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

Marcos Alexandre: Legal você conhecer Haskell.

O .NET não é uma linguagem, mas um Framework. Existe o Haskell.NET, o Delphi.NET, o Cobol.NET e uma penca de linguagens .NET. Assim, nada impede de existir um Python.NET (se já não existe) ou outra dessas linguagens que você falou. O que eu questiono não é a linguagem, mas o fato que o .NET é uma arquitetura feita para rodar em várias platarmas WINDOWS, e a intenção da MS é de que num futuro relativamente próximo, somente aplicativos nativos .NET é que vão funcionar no Windows. A intenção da MS é fazer um porte das APIs Win32 rodando em cima do .NET, mas daí ficariam mais lentas que as aplicações .NET nativas.
E é fato que as aplicações .NET são muito mais difíceis de serem portadas para outras plataformas, então as grandes empresas vão ter dificuldades adicionais para criar uma aplicação para Linux ou Mac, a não ser que fiquem com dois códigos separados. Isso para uma aplicação pequena é fácil, mas imagine um Photoshop da vida, ou um Oracle. As grandes empresas de banco de dados já estão reclamando da dificuldade de portar suas aplicações para .NET e já estão admitindo que o MS SQL Server vai se beneficiar disso, já que ele já está portado na frente dos outros e saiu na frente.
Por último, Haskell, Python, Ruby, etc são ótimas linguagens mas elas estão longe de conseguirem um grande mercado e de ter um grande aporte financeiro para reverter esse cenário. E particularmente não acredito em ver uma aplicação de grande porte feita numa dessas linguagens.
Já C/C++ é outra história, mãe da maioria dos SOs, banco de dados, games, etc. Mas se a MS conseguir sua intenção, um aplicativo C++ será mais lento que um aplicativo .NET nativo na plataforma Windows (que tem mais de 90% do mercado). E um aplicativo em um eventual C++.NET não será tão independente de plataforma.


A idéia do Java é justamente o contrário: um framework independente de plataforma, feito para rodar em qualquer SO e mesmo em dispositivos sem SO. E uma plataforma livre (a única coisa que não é livre é a VM da Sun, mas nada impede outra empresa de fazer outra VM com a licença que ela desejar, contanto que seja equivalente equivalente à VM da Sun, ou seja, os aplicativos que rodam em uma, tem que rodar na outra).


Haskell developer

Matéria da Veja: > Onde está a matéria sobre Software Livre, publicada pela Revista Veja?

Se você mandou no final de semana, deve estar na fila de inclusão, e será lida no procedimento de publicação desta segunda-feira!

O Java da Sun não é livre e: O Java da Sun não é livre e você pode ler sobre os bons motivos de não endossar demais o projeto Java nos artigos de Richard Stallman. Por outro lado ainda que o Mono seja tudo que você ache que é têm o código livre e disponível sob a GPL, existe outro projeto livre que roda aplicações .NET: o dotGNU, também sob a GPL, apesar de que não ele recebe tantas críticas quanto o Mono, o pessoal que desgosta da MS ainda fala mal dele pois implementa uma mera "cópia do Java". O incrível é como essa cópia do Java é mais fácil e rápida de implementar por projetos independentes do que o Java.

O Java é livrérrimo: O que não é livre é a implementação específica da Sun, que você não é obrigado a usar. Não gostou da implementação da Sun? Pegue a da IBM, então. Ah! Da IBM também não é livre? Então escolha uma implementação GNU! Ah! Não gostou do GNU? Faça você mesmo!

Quer mais livre que isso? Não tem! Java é mais livre que o próprio Linux. É tão livre que você pode implementá-lo GPL, ou pode criar uma empresa e implementá-lo como software proprietário. No Linux, nem isso você consegue.

Eu não sou "javeiro", mas fica difícil entender as razões por trás desse asco gratuito ao Java.

Foi exatamente o que eu disse: Foi exatamente o que eu disse: "O Java da Sun não é livre...".
O que eu sou contra é pessoas falando bem do Java da Sun, defendendo ele, (ou o Java implementado pela Sun) e falando mal do Mono por seu uma "mera cópia do Java" apesar de ser livre, apesar de eu não gostar nem de uma nem de outra plataforma. O meu asco com o Java na verdade é um asco com a Sun.

plataformas e mais plataformas: pq não basta ter um SO: tem quer ter uma VM redundante por cima! :))

"O .NET não é uma linguagem, mas um Framework."

sim, eu sei. pelo menos a M$ teve menos cara-de-pau que a Sun e deu nomes diferentes para coisas diferentes. java nomeia simultaneamente uma linguagem, um compilador, uma VM, um fenômeno de massa etc etc...

"Existe o Haskell.NET, o Delphi.NET, o Cobol.NET e uma penca de linguagens .NET. Assim, nada impede de existir um Python.NET (se já não existe) ou outra dessas linguagens que você falou."

Existe o projeto IronPython, iniciado pelo mesmo criador de Jython e que está atualmente empregado na M$, encarregado de ampliar a gama de opções para o .net. Pessoalmente, espero que uma linguagem tão clara e simples como Python possa um dia, quem sabe, até substituir Basic na preferência dos M$ers. mas acho que é pedir muito... gente acostumada com sloppy code geralmente continua assim até o fim da vida...

"O que eu questiono não é a linguagem, mas o fato que o .NET é uma arquitetura feita para rodar em várias platarmas WINDOWS,"

e aí, seu argumento de "aplicações multi-plataforma" perde substância...

"Por último, Haskell, Python, Ruby, etc são ótimas linguagens mas elas estão longe de conseguirem um grande mercado e de ter um grande aporte financeiro para reverter esse cenário."

Mas não deixam de ser opção, pra pessoas com coragem e inteligência usarem.

"E particularmente não acredito em ver uma aplicação de grande porte feita numa dessas linguagens."

pq? pessoas já escreveram aplicações de grande porte em coisas como Cobol, C e Basic. pq não em melhores ferramentas e também de mais fácil manuseio?

"Mas se a MS conseguir sua intenção, um aplicativo C++ será mais lento que um aplicativo .NET nativo na plataforma Windows"

é mais ou menos como o compilador C++ da intel rodando em chips AMD: ele reconhece o chip e gera código mais lento para ele. A AMD está processando a intel depois da descoberta do "truque". Quem se fode sempre: claro, o consumidor, forçado a ficar com as ofertas do monopólio da vez, cujos produtos são "mais rápidos e eficientes"...

managed code é isso aí: gerenciado para servir a propósitos nefastos. e dá-lhe managed code, DRM e outras putarias que estão por vir para os usuários terem cada vez menos controle sobre suas "propriedades digitais"...

"A idéia do Java é justamente o contrário: um framework independente de plataforma, feito para rodar em qualquer SO e mesmo em dispositivos sem SO."

na verdade, o .Net só é exclusivo para Windows por ser da M$ e por causa de algumas dependências fortes da infraestrutura da plataforma ( WinForms ). Fora isso, é uma VM + libs que rodam nessa VM, que é uma máquina abstrata e portanto, portável para outras plataformas. Não é isso exatamente que o mono e dotGnu provêem? tirando eventuais ameaças de patentes...

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

apples and oranges: "Java é mais livre que o próprio Linux. É tão livre que você pode implementá-lo GPL, ou pode criar uma empresa e implementá-lo como software proprietário."

Doh! Se vc vai comparar uma especificação, então compare com a correta: POSIX. Linux implementa a especificação POSIX, da mesma forma que a VM Java da Sun implementa a especificação Java e suas APIs.

POSIX é completamente livre e passível de ser implementada sob outras licensas, como aliás, os BSDs fizeram sob a licensa BSD.

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

Perfeito! Então Java é tão livre quanto POSIX: Sei que me arrisco em cobrar coerência das pessoas, afinal o ser humano é o bicho "racional" mais incoerente que conhecemos, mas não vemos o Stallman criticar a armadilha "Unix", muito pelo contrário, ele baseou seu projeto de vida, o GNU, no Unix. Já o movimento anti-Java, ainda que seja endereçado só ao "Java da Sun", ostraciza o Java como um todo, de modo que pronunciar a palavra Java já produz entortar de bocas, franzir de sobrolhos, ranger de dentes e bufar de ventas.

Xá pralá.

Isto é o mesmo que os pró-j: Isto é o mesmo que os pró-java fazem com o .NET, disputas entre qual é melhor são comuns entre fãs das duas plataformas. Eu não gosto nem de uma nem de outra, só tenho um respeito pela comunidade Mono e dotGNU que saiu a luta para implementar algo do zero. A fundação de software Apache aprovou a entrada do Harmony na incubadora de projetos, o Harmony será uma implementação do Java Serial Edition totalmanete livre sob a Apache License, se eu fosse anti-java estaria falando mal deles e não da Sun.

Armadilha Unix: mas não vemos o Stallman criticar a armadilha "Unix", muito pelo contrário, ele baseou seu projeto de vida, o GNU, no Unix.

Que argumento ridículo. O Stallman escolheu o Unix para ser imitado pelo projeto GNU justamente pra se livrar da "armadilha Unix"! Visto que as especificações eram abertas, não havia problema em implementar uma cópia não-proprietária.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Java Serial Edition????: J2SE é Java 2 Standard Edition.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

posix vs java: POSIX ( Portable Operating System Interface, o X é charme ) é um padrão aberto originalmente comissionado pelo governo norte-americano na época em que via uma crescente dependência de seus sistemas de informação dos Unix comerciais de então, que crescentemente criavam incompatibilidades entre si.

Java é um padrão desenvolvido por uma empresa norte-americana cujas especificações não são totalmente abertas. Pergunte aos implementadores do Classpath GNU ou GCJ o que eles acham de algumas obscuras partes das APIs...

"pronunciar a palavra Java já produz entortar de bocas, franzir de sobrolhos, ranger de dentes e bufar de ventas"

pessoalmente, java só me incomoda por ser extremamente redundante, ainda mais combinado com seu irmão xml, pesado, lento, estúpido e inexpressivo. sei que não são argumentos técnicos, mas pra mim bastam.

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

RMS não menciona armadilha Unix ao escolhê-lo como modelo: O Stallman escolheu o Unix para ser imitado pelo projeto GNU justamente pra se livrar da "armadilha Unix"!


Aparentemente, o que Richard Stallman queria a princípio era escrever o SO do zero. Depois de alguma reflexão, ele escolheu o Unix como modelo por ser portável e modular. Ele não mencionou nenhuma "armadilha Unix".

"Naturalmente, eu tinha de decidir que tipo de sistema operacional deveria ser-- havia algumas decisões técnicas de projeto a serem feitas. Decidi fazer umsistema compatível com UNIX por uma série de razões. Primeiro, eu tinha visto um sistema operacional de que eu realmente gostava [ITS] ficar obsoleto porque ele tinha sido escrito para um tipo específico de computador [PDP-10]. Eu não queria que isso acontecesse de novo. Precisávamos ter um sistema portável. Bem, UNIX era um sistema portável. Então se seguisse as linhas de projeto do UNIX, teria uma boa chance de fazer um sistema que fosse portável e operável. E além disso ser compatível com ele nos detalhes. A razão é que os usuários odeiam mudanças incompatíveis. Se tivesse projetado o sistema do jeito que mais gostasse -- o que teria adorado fazer, com certeza -- teria produzido algo incompatível. Bem, os detalhes seriam diferentes. Assim, se escrevesse o sistema -- os usuários teriam-me dito "olha... é bem legal, mas incompatível. Vai dar muito trabalho migrar. Não compensa usar seu sistema em vez do UNIX, assim ficaremos com o UNIX", eles teriam dito.

Então, se quisesse criar de fato uma comunidade em que houvesse gente--pessoas usando este sistema livre, e usufruindo dos benefícios da livre cooperação--eu teria de fazer um sistema que as pessoas usassem, um sistema que eles achassem fácil de usar, que não apresentasse obstáculo, levando-o ao insucesso logo no início. Ao fazê-lo compatível com UNIX, ficaram definidas todas as decisões de projeto imediatas, porque o UNIX é composto de muitas peças, e elas se comunicam por interfaces que são de alguma forma documentadas. Se quiser ser compatível com UNIX, você precisa substituir cada peça, uma por uma, por outra compatível. As decisões de projeto restantes ficam dentro de cada peça. E poderiam ser escritas mais tarde por quem decidisse escrevê-las; elas não precisavam ser feitas todas desde o início."

Aham: Isso é certo. O nome que o sujeito a quem respondi deu de "armadilha Unix" é um tanto quanto impreciso, mas respondi no contexto dele para clarificar. A "armadilha Unix" seria tão-somente, em analogia com a "armadilha java", construir em cima de uma plataforma proprietária e acabar trancafiado a código proprietário.

O que eu disse não entra em contradição com o que você escreveu.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

java é aberto sim...: Você pode chamar o processo de padronização e definição do java - o famoso JCP, Java Community Process - de pesado, burocratico, lento, mercadológico demais e elitista. Mas não pode negar que ele é aberto e bem documentado.

Ou pode?

A propósito, estou curioso. Que especificações do java não são totalmente abertas? Pode clarificar esse papo de obscuras partes das APIs do java?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Valeu pela correção. Tirei: Valeu pela correção. Tirei o "Serial" da caixinha do Doom 3 aqui do lado.

A Armadilha Java: Bem. Para enlevo da comunidade, resolvi traduzir brevemente o texto original de RMS que se encontra em http://www.gnu.org/philosophy/java-trap.html. Não sei se já foi traduzido em outro lugar, mas ao tentar traduzi-lo, pude refletir com maior profundidade sobre a questão. Obs.: As maiúsculas são minhas.

Se seu programa é software livre, ele é basicamente ético--mas há uma armadilha da qual você precisa se proteger. Seu programa, apesar de livre, pode estar sendo restrito por software não livre do qual dependa. Já que este problema é mais proeminente hoje nos programas escritos em Java, chamamos isso de armadilha Java.

Um programa é software livre se seus usuários têm certas liberdades cruciais. Grosso modo, são elas: a liberdade de executar o programa, a liberdade de estudar e modificar o código-fonte, a liberdade de redistribuir o código-fonte e os binários e a liberdade de publicar versões melhoradas (vide http://www.gnu.org/philosophy/free-sw.html). Um dado programa ser ou não software livre depende unicamente do que diz sua licença.

Saber se o programa poderá ser usado ou não no Mundo Livre, por pessoas que pretendem viver em liberdade, já é uma questão mais complexa. Isto não pode ser definido só pela licença do programa, porque nenhum programa funciona isolado. Todo programa depende de outros programas. Por exemplo, para compilar e interpretar um programa, é necessário um compilador ou um interpretador. Todos esses programas são dependências. Dependências podem ser indispensáveis para que um programa rode, ou apenas acrescentam recursos. De qualquer forma, o programa todo, ou parte dele, não pode operar sem as dependências.

Se algumas das dependências não forem livres, isso significa que parte do programa não poderá rodar em um sistema totalmente livre--ele não será usável no Mundo Livre. Claro, poderíamos redistribuir o programa e ter cópias dele em nossas máquinas, mas não adiantará nada se não puder rodá-lo. O programa será software livre, mas ficará de fato acorrentado às suas dependências não livres.

ESTE PROBLEMA PODE ACONTECER COM QUALQUER TIPO DE SOFTWARE, EM QUALQUER LINGUAGEM. Por exemplo, um programa que só rode no Microsoft Windows é claramente inútil no Mundo Livre. Mas software que rode em GNU/Linux pode também ficar inutilizável se depender de outro software não livre. No passado, o Motif (antes de termos o LessTif) e o Qt( antes de seus desenvolvedores o tornarem software livre) eram as maiores causas desse problema. A maioria das placas de vídeo 3D funcionam plenamente só com drivers não livres, o que causa o problema. Mas a maior fonte dele hoje é o Java, porque as pessoas que escrevem software livre muitas vezes acham Java atraente. Cegos pela atração da linguagem, ignoram o problema das dependências, e caem na Armadilha Java.

A implementação Java da Sun não é livre. O Blackdown também não é; é uma adaptação do código proprietário da Sun. As bibliotecas padrão do Java também não são livres. Temos sim implementações livres de Java, tais como o GCJ (GNU Compiler for Java) e o GNU Classpath, mas elas não suportam todas as funcionalidades ainda. Estamos correndo para chegar lá.

Se você desenvolve programas na plataforma Java, provavelmente usará funcionalidades exclusivas da Sun, mesmo sem notar. Quando finalmente descobrir, você as terá usado por meses; mas ter de refazer o trabalho só por causa disso talvez tome ainda mais outros meses. Aí vai dizer: "ah, vai dar muito trabalho começar de novo". Daí seu programa terá caído na armadilha Java; e será inútil para o Mundo Livre.

Um jeito seguro de evitar a Armadilha Java é ter somente implementações livres do Java no seu sistema. Se usar um recurso ou biblioteca Java ainda não suportada por software livre, você ficará sabendo na hora e poderá rescrever o código imediatamente.

A Sun continua a desenvolver bibliotecas Java "padrão" adicionais e quase todas elas não são livres; em muitos casos, até mesmo a especificação das bibliotecas é um segredo industrial e a última licença da Sun para estas especificações proíbe o lançamanto de qualquer coisa aquém da implementação completa (Vide exemplos em http://jcp.org/aboutJava/communityprocess/JSPA2.pdf e http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html)


Felizmente, a especificação permite sim lançar implementações em software livre; os que receberem as bibliotecas poderão têm permissão de modificá-las e não são obrigados a aderir à especificação. Mas as exigências têm o efeito de impedir o uso de um modelo de desenvolvimento colaborativo para produzir uma implementação livre. O uso do modelo implicaria na publicação de versões incompletas, o que é proibido aos que lerem a especificação.

No início do Movimento de Software Livre, era impossível evitar a dependência de programas não livres. Antes de termos o gcc (Gnu C Compiler), todo programa em C (livre ou não) dependia de um compilador C não livre. Antes de termos a glibc (bibliotecas C GNU), todo programa dependia de uma biblioteca não livre C. Antes de termos Linux, o primeiro kernel livre, todo programa dependia de um kernel não livre. Antes de termos Bash, todo script de shell tinha de ser interpretado por um shell não livre. Era inevitável que nossos primeiros programas fossem limitados por essas dependências, mas aceitávamos isso porque nosso plano incluía resgatá-los subseqüentemente. Nosso objetivo final, um sistema operacional GNU independente, incluía a substituição livre para todas aquelas dependências; se alcançássemos nosso objetivo, todos os nossos programas seriam resgatados das armadilhas. E isso aconteceu: com o sistema GNU/Linux, nós podemos rodar esses programas em plataformas livres.

A situação é diferente hoje. Agora temos sistemas livres poderosos e muitas ferramentas de programação livres. Qualquer trabalho que queira fazer, você pode fazê-lo numa plataforma livre; não há necessidade de se conformar a uma dependência não livre, nem mesmo temporariamente. A razão principal pela qual as pessoas caem na armadilha hoje é porque elas não têm consciência dela. A solução mais fácil para o problema da Armadilha Java é alertar as pessoas para não cair nela.

Para deixar seus códigos Java a salvo da Armadilha Java, instale um ambiente de desenvolvimento Java livre e use-o. Mas de forma geral, para qualquer linguagem que usar, fique de olhos abertos, e verifique a liberdade dos programas do qual dependa seu código. A melhor maneira de verificar se um programa é livre é consultar a Lista de Software Livre (http://www.fsf.org/directory). Se o programa não estiver na lista, você poderá comparar sua licença com as licenças de software livre (http://www.gnu.org/licenses/license-list.html).

Estamos tentando libertar os programas Javas da armadilha, assim se você gosta da linguagem Java, convidamos você a ajudar no desenvolvimento do GNU Classpath. Teste seus programas usando também o Compilador GCJ e o GNU Classpath e relate qualquer problema que encontrar nas classes já implementadas, o que será útil. No entanto, vai levar tempo até completar o GNU Classpath; como a cada dia são acrescentadas novas bibliotecas não livres, nem sempre é possível ter as mais recentes. Assim, não acorrente seu software livre. Quando escrever uma aplicação hoje, escreva-a para rodar num ambiente livre já de início.

Começando pelo java... : Começando pelo java...
Redundante, quanto a isso acho que posso concordar um pouco com você. Vejo as coisas na API feitas de um modo muito "acadêmico" (SWING? e sim, citei academico num mal sentido, nada pratico), mas eles fizeram um ótimo trabalho de modelagem mesmo assim, e de documentação nem se fala (tem alguma api por aí tao bem documentada? desconheço).

Agora, quanto ás criticas ao xml, por favor dê algum argumento pra criticar uma coisa que revolucionou a troca de dados de uma maneira absurda, e chamar ele de lento/pesado/estúpido/inexpressivo.

1. Lento e Pesado são casos. Codigo assembly mal feito pode ser lento, se tá lento dá pra otimizar.
2. Quanto ao estúpido, sem comentários que adicionem nada de bom ao meu post.
3. inexpressivo? em que mundo?! Já ouviu falar na facilidade em integração de sistemas com xml? Já ouviu sobre o novo padrao de formato de arquivo do OpenOffice? WebServices? Ou seja, QUISERA um projeto meu ser inexpressivo a este ponto ;)

Sinto muito, mas depois de ler esse trecho: "sei que não são argumentos técnicos", sendo que você está comentando sobre uma coisa técnica, desqualifica qualquer opinião técnica expressada no seu post.

Sem flame wars, mas acho que assunto técnico se discute com argumentos técnicos, e não com visões superficiais de uma tecnologia simplesmente para atacá-la.

Java x .NET: Não vou me estender pra não gerar flames, ainda mais que diferença de opinião não adianta discutir, por isso só vou citar alguns pontos.

"pq não basta ter um SO: tem quer ter uma VM redundante por cima! :))"

Aí é que está. A intenção da MS é que o SO rode por cima da VM e não o contrario. Essa é a questão! Com isso as aplicações que antes eram nativas é que ficarão lentas, e as aplicações que rodam na VM é que serão as nativas. Por isso o Mono não vai representar perigo, muito pelo contrário. Um aplicativo .NET rodando no Mono será muito mais lento que rodando no Windows.

"e aí, seu argumento de "aplicações multi-plataforma" perde substância..."
Bom, não considero "multi-plataformas WINDOWS" como sendo opções multi-plataforma. Se você considera, tudo bem, realmente o Windows roda em 24 plataformas e nessas com certeza o .NET vai rodar, desde que o SO seja Windows.



"E particularmente não acredito em ver uma aplicação de grande porte feita numa dessas linguagens."
pq? pessoas já escreveram aplicações de grande porte em coisas como Cobol, C e Basic. pq não em melhores ferramentas e também de mais fácil manuseio?
Não consigo imaginar um port do Photoshop em Cobol ou uma versão do Oracle escrita em Basic.

"Mas se a MS conseguir sua intenção, um aplicativo C++ será mais lento que um aplicativo .NET nativo na plataforma Windows"
é mais ou menos como o compilador C++ da intel rodando em chips AMD: ele reconhece o chip e gera código mais lento para ele.
O problema é pior, o C++ vai ter uma "camada" a mais que um aplicativo .NET nativo. Por melhor que seja o compilador, ele vai estar em desvantagem. Imagine então a VM do Java rodando em cima da VM do .NET. O Java morreria!

"A idéia do Java é justamente o contrário: um framework independente de plataforma, feito para rodar em qualquer SO e mesmo em dispositivos sem SO."
na verdade, o .Net só é exclusivo para Windows por ser da M$ e por causa de algumas dependências fortes da infraestrutura da plataforma ( WinForms ). Fora isso, é uma VM + libs que rodam nessa VM, que é uma máquina abstrata e portanto, portável para outras plataformas. Não é isso exatamente que o mono e dotGnu provêem? tirando eventuais ameaças de patentes...
O mono está para o .NET assim como o Wine está para o Win32. Alguma coisa pode até rodar legal, mas nunca vai conseguir 100% e sempre vai ter paus que ele não vai conseguir, já que a MS não tem intenção nenhuma em ajudar os concorrentes. Aliás, nenhuma empresa tem. O .NET tem muita, mas muita coisa que é fortemente ligada à arquitetura do Windows e a MS não pretende mudar isso tão cedo. A intenção deles é matar a concorrência e o .NET é sua arma. A única coisa que o Mono consegue é ajudar a atrair desenvolvedores pra plataforma.

Haskell developer

Redundante?: Redundante?

Na verdade você está confun: Na verdade você está confundindo as coisas um pouco, evitei comentários porque o post é sobre a SUN e OpenOffice e não vi motivo para gerar uma discussão sobre o Mono e o .NET.

A Microsoft não tem intenção de fazer seu sistema operacional rodar abaixo da sua máquina virtual, por várias razões, entre elas:

1. O Windows ficaria ainda mais lento, a velocidade das aplicações rodando apenas em código gerênciado é muito menor que das aplicações nativas.

2. A API do Windows continuará existindo ou será quebrada a compatibilidade com versões anteriores do Windows e depois do Windows ME eu creio que a Microsoft já tenha aprendido.

3. Sistema Operacional é o software básico de um computador e tudo (tudo mesmo) é rodado sobre ele e mesmo que fosse possível deixar todo o Windows sob uma máquina virtual aí seria muito mais fácil implementar essa máquina virtual e rodar as aplicações em outras plataformas, isso com certeza eles não querem.

Com certeza a próxima versão do Windows virá um pouco mais integrada ao .NET e muitas das aplicações serão reescritas para .NET mas note que mesmo hoje a Microsoft faz mais uso de código "não gerenciado" em seu Framework do que o Mono, como exemplo temos o compilador que a microsoft implementa (ou implementava) em código nativo (ou não gerenciado) e no caso do Mono até mesmo o compilador roda sob a VM.

Quanto a rodar aplicações .NET no Mono, bem eu tenho conseguido grande sucesso e posso dizer que a única área em que ainda deixa (um pouco) a desejar é a de aplicações que utilizam a biblioteca "WinForms", de qualquer forma o Mono avançou muito na implementação dessa biblioteca e eu apenas não a uso por preferir o visual do GTK# para aplicações Linux.

Se quiser um exemplo de aplicação "Mono ou .NET" usando GTK# e rodando em multiplas plataformas aí vai um exemplo de um projeto http://www.simios.org/projetos/ovpnadmin ou http://sourceforge.net/projects/openvpnadmin/.

Pra finalizar aproveito para passar o link do http://www.simios.org/ um site nacional voltado a Mono, lá você encontra muita informações em português contando inclusive com a tradução (total) do FAQ do Mono com muitas respostas a dúvidas que freqüêntemente vejo aparecerem por aqui (http://www.simios.org/faq).


Everaldo Canuto
everaldo@simios.org

" Microsoft não tem intenç: " Microsoft não tem intenção de fazer seu sistema operacional rodar abaixo da sua máquina virtual"
1 Não só tem, como declarou isso publicamente por diversas vezes em diversos congresssos e vem repetindo isso exaustivamente em cada palestra sobre .NET. Esse vai ser o grande diferencial do Windows. E não vai ser tão lento assim, já que a idéia da VM é se integrar fortemente ao hardware Intel/AMD. A Sun já tentou fazer isso com o Java no passado. Aliás, quando criou o Java, a promessa era essa.
Pra saber mais detalhes, consulte a página da MS ou assista alguma apresentação deles. Esse sempre foi o objetivo do .NET.

2 A API Win32 continuará vindo com o Windows por um tempo, até que a maioria dos fornecedores portem suas aplicações para .NET, depois disso, o Windows deixará de oferecer suporte nativo. E as APIs Win32 portadas para .NET são somente para ajudar na migração, mas ficarão bem mais lentas que o .NET nativo. Dessa forma os produtos MS que já estao portados vão ter uma vantagem estratégica em cima das outras empresas, que demorarão bastante para portarem, isso se conseguirem. É a mesma coisa da migraçao DOS pra Win32. Ainda existe muitos programas pra DOS rodando, mas é uma tecnologia morta.


Cara, o Mono ainda está longe, muito, muito longe de rodar bem todas as aplicações .NET. Vai demorar bastante para rodar um Delphi 2005, um Visual Studio ou um SQL Server.NET. Ele está se dando bem de rodar alguns programas básicos que não exploram todos os recursos e alguma coisa intermediária. É a mesma dificuldade do Wine, pode reparar que os programas mais recentes dificilmente rodam no Wine sem problemas.

aqui: no mailing-list do projeto Classpath:

http://lists.gnu.org/archive/html/classpath/2004-06/msg00032.html

perspectiva interessante...

particularmente, os pacotes com.sun.* são propositadalmente não documentados. e, apesar disso, projetos importantes dependem deles. e dá-lhe engenharia reversa para tentar acalmar os ânimos...

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

sim, redundante e repetitivo: "Agora, quanto ás criticas ao xml, por favor dê algum argumento pra criticar uma coisa que revolucionou a troca de dados de uma maneira absurda, e chamar ele de lento/pesado/estúpido/inexpressivo."

Desculpe, botei xml no meio da sentença e acabou que aquelas "qualidades", que deveriam descrever java, aparentemente se aplicaram a xml. Não que não mereça, à propósito. Ambos são tecnologias redundantes, repetitivas e pesadas.

Revolucionou?! A internet e a web revolucionaram as telecomunicações globais, mas xml?? Só pq html mostrou como um formato textual aberto e padronizado é uma boa coisa para troca de informações, não significa que xml deve levar o crédito.

"1. Lento e Pesado são casos. Codigo assembly mal feito pode ser lento, se tá lento dá pra otimizar."

Não dá para otimizar xml: é texto encapsulado em toneladas de redundantes e verbosas "tags". s-expressions estúpidas e redundantes. É texto, não formato binário. Nada tenho contra texto. Mas poderiam ter mantido a sintaxe original de Lisp baseada em parênteses.

Por ex:

estúpido e verboso ( necessário parsers complicados e pesados )

<grupo>
  <pessoa id="1">Foobar da Silva</pessoa>
  <pessoa id="2">Bozbar dos Santos</pessoa>
  <pessoa id="3">Frobnicia Faria</pessoa>
</grupo>


simples e conciso ( necessário parsers simples e rápidos )

(grupo ()
  (pessoa ((id "1")) Foobar da Silva)
  (pessoa ((id "2")) Bozbar dos Santos)
  (pessoa ((id "3")) Frobnicia Faria))


"3. inexpressivo? em que mundo?! Já ouviu falar na facilidade em integração de sistemas com xml? Já ouviu sobre o novo padrao de formato de arquivo do OpenOffice? WebServices? Ou seja, QUISERA um projeto meu ser inexpressivo a este ponto ;)"

Inexpressivo, sim. xml não é uma linguagem mágica, está mais para um alfabeto padrão que todas as linguagens devem se basear. Mas da mesma forma que o alfabeto ocidental é usado pelas linguagens ocidentais, nada nos diz a respeito do significado das frases formadas nesse alfabeto nas diferentes línguas.

Webservices! Não há nada que se faça de forma pesada e redundante com xml e webservices ( particularmente aqueles servidos por VM lerdas como a de Java ) que não se faça mesmo com um script CGI e parâmetros de URL. Nada.

Formas padronizadas para trocas de informações não dependem de xml. Basta quem requisita as informações se adequarem ao protocolo sobre formatos de parâmetros e formato de saída. xml deu uma mãozinha aqui: hoje todos usam o formato único, verboso e estúpido.

Quanto a java, é uma linguagem boçal e antiga, um sub-C++ com algumas influências de Lisp e Smalltalk para dar um ar moderno. E uma implementação ineficiente baseada em VM. Mas acima de tudo, toneladas de bibliotecas absolutamente necessárias para se fazer qualquer coisa útil. Quando digo que java é redundante, me refiro principalmente, além da natureza repetitiva da sintaxe da linguagem, ao fato de que essa biblioteca imensa e rodando numa lenta e aparvalhada VM simplesmente reproduz bibliotecas já existentes no SO subjacente, como acesso a BDs, parsers xml, compactadores, GUIs e coisa e tal.

ah, claro! se java está rodando em um pc de usuário com Windows, então java o provê com toda a funcionalidade que deveria existir no SO. :)


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

sub: "Esse vai ser o grande diferencial do Windows."

acho que vc está atrasado. Imaginava-se que o novo sistema, antigo LongHorn, novo Windows Vista, seria todo baseado em .Net. Eles, como sempre, decepcionaram a todos.

"E não vai ser tão lento assim, já que a idéia da VM é se integrar fortemente ao hardware Intel/AMD."

Pode ser. A M$ tem relações fortes com a Intel. AMD não sei.

De qualquer modo, e só pra encerrar essa discussão, gostaria de lembrar aos dois que um kernel de um SO faz basicamente o papel de uma VM, gerenciando o uso de memória, de fluxo de execução de processos e blablabla. Mas, .Net CLI e Java VM são VMs de alto nível, portáveis e que não pressupõem a necessidade de comunicação de baixo nível direta com um processador real de máquina. Pelo menos java, que desde o começo foi imaginado para se rodar em servidores Sun e clientes Windows.

Realmente, dada a aliança extrema da M$ com a Intel, ela poderia amarrar sua VM exclusivamente a processadores dessa plataforma. E fazer a Intel dar suporte a instruções da VM.

"E as APIs Win32 portadas para .NET são somente para ajudar na migração, mas ficarão bem mais lentas que o .NET nativo."

não enquanto esse suposto suporte da Intel à VM .Net não vingar. Embora claramente a M$ poderia complicar as coisas por conta própria, por exemplo, fazer chamadas à Win32 propositadalmente mais lentas, para forçar desenvolvedores a migrarem para seu último produto...

"Ainda existe muitos programas pra DOS rodando, mas é uma tecnologia morta."

a não ser que rodem em FreeDOS! :)

"Cara, o Mono ainda está longe, muito, muito longe de rodar bem todas as aplicações .NET... Ele está se dando bem de rodar alguns programas básicos que não exploram todos os recursos e alguma coisa intermediária."

conversa fiada. No mínimo, ASP.Net roda muito bem a maioria das aplicações, sem problemas. O problema são WinForms. Quem se amarra a uma tecnologia específica a uma plataforma sempre tem problemas...

"Vai demorar bastante para rodar um Delphi 2005, um Visual Studio ou um SQL Server.NET."

A propósito: Visual Studio e SQL Server são escritos em C++. VB, C# e outros são usados apenas pelos clientes da M$, não por seus desenvolvedores. ;)

Imagino que o mesmo seja verdade para Delphi. Ah! não! Esse é em ObjectPascal, compilada para código de máquina também. :)

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

Vamos fazer uma análise crítica deste texto: Saber se o programa poderá ser usado ou não no Mundo Livre

O texto vinha muito bem até aqui. Reconhecemos que o conhecimento fica muito melhor no domínio público. Um exemplo histórico disso está na escrita. No Egito antigo, a escrita era privilégio dos escribas e sacerdotes. Contrariando a determinação da exclusividade da escrita, outros povos não só simplificaram a escrita, como a popularizaram, permitindo e, mais tarde incentivando, a todos os cidadãos a fazer uso dela.

Porém a criação de algo chamado "Mundo Livre" me parece uma utopia, um lugar nenhum, uma condição imaginária, algo completamente longe do ímpeto que levou tanto os antigos quantos os modernos a compartilhar conhecimento.

Se você desenvolve programas na plataforma Java, provavelmente usará funcionalidades exclusivas da Sun, mesmo sem notar. Quando finalmente descobrir, você as terá usado por meses; mas ter de refazer o trabalho só por causa disso talvez tome ainda mais outros meses. Aí vai dizer: "ah, vai dar muito trabalho começar de novo". Daí seu programa terá caído na armadilha Java; e será inútil para o Mundo Livre.

Este trecho do texto me lembrou a "Falácia da Derrapagem": "Você nunca deveria jogar. Uma vez que você comece a jogar, você vai ver que é difícil parar. Logo você vai se ver apostando todo o seu dinheiro em apostas e finalmente você vai ter que recorrer ao crime para apoiar suas perdas."

No início do Movimento de Software Livre, era impossível evitar a dependência de programas não livres. Antes de termos o gcc (Gnu C Compiler), todo programa em C (livre ou não) dependia de um compilador C não livre. Antes de termos a glibc (bibliotecas C GNU), todo programa dependia de uma biblioteca não livre C. Antes de termos Linux, o primeiro kernel livre, todo programa dependia de um kernel não livre. Antes de termos Bash, todo script de shell tinha de ser interpretado por um shell não livre. Era inevitável que nossos primeiros programas fossem limitados por essas dependências, mas aceitávamos isso porque nosso plano incluía resgatá-los subseqüentemente. Nosso objetivo final, um sistema operacional GNU independente, incluía a substituição livre para todas aquelas dependências; se alcançássemos nosso objetivo, todos os nossos programas seriam resgatados das armadilhas. E isso aconteceu: com o sistema GNU/Linux, nós podemos rodar esses programas em plataformas livres.

A situação é diferente hoje. Agora temos sistemas livres poderosos e muitas ferramentas de programação livres. Qualquer trabalho que queira fazer, você pode fazê-lo numa plataforma livre; não há necessidade de se conformar a uma dependência não livre, nem mesmo temporariamente. A razão principal pela qual as pessoas caem na armadilha hoje é porque elas não têm consciência dela. A solução mais fácil para o problema da Armadilha Java é alertar as pessoas para não cair nela.

Esta é uma pérola do casuísmo. Enquanto o software proprietário foi de valia para desenvolvimento do software livre, não se podia condenar os que dele faziam uso. Mesmo que intenção tenha sido "resgatá-los" depois, o fato é que software proprietário foi usado para desenvolver software livre, bem ali no seu nascedouro. E ainda não podemos garantir que todo mundo que produziu software livre até hoje tenha feito com essa intenção. Como podemos esperar que a simples intenção redima os atos de RMS, pela ética que pretende agora nos promulgar?

RMS tem uma visão antiquada de software. Hoje em dia até mesmo o hardware é projetado em software. Você programa um código e manda uma aplicação desenhar o diagrama e o circuito impresso, gerar a lista de compras, e controlar todo o maquinário que fará a soldagem dos componentes na placa, etc.

O que é um processador, tipo Intel? É software! É isso mesmo. Software. Os projetistas de processadores são na realidade programadores. Um processador não passa de um programa armazenado no hardware. Sendo assim, nosso Linux querido, mesmo que esteja totalmente livre de software proprietário, fará uso do conjunto de instruções do processador que nada mais é uma implementação de software, proprietário e, ainda por cima, patenteado. O GNU/Linux, por mais que esteja livre, sempre será DEPENDENTE, para usar um termo do Stallman, da tecnologia do processador sobre o qual rodar.

A JVM é na realidade um processador, que tanto pode ser emulado em software, como implementado em hardware. Se a JVM fosse só um processador, o que Stallman diria?

O que conceitualmente define hoje um processador emulado em software de um realmente implementado em hardware? E porque se deva condenar um software que faz uso dos recursos de uma emulação proprietária em software de outro que faz uso da mesma implementação em hardware?

Penso que RMS, ainda que líder incontestável e peça fundamental para desenvolvimento do software livre, extrapola seu dever social ao tentar definir software sob a ética. Ética, cada povo tem a sua. Ainda que seja interessante ouvir a argumentação de RMS, esta precisa de mais polimento.

O que posso dizer é que ganh: O que posso dizer é que ganho meu pão com o Mono e as aplicações com que trabalho rodam sem nenhum problema em Windows e Linux. Quanto ao Visual Studio, como já dito pelo nemesis, é escrito em C++.

Faço um convite para que instalem e testem o Mono antes de tecer comentários sobre ele :)

Everaldo Canuto
everaldo@simios.org

vamos fazer uma análise crítica deste texto tmb: "Enquanto o software proprietário foi de valia para desenvolvimento do software livre, não se podia condenar os que dele faziam uso."

e daí? o que vc preferia? ficar de braços cruzados, assistindo enquanto muros são construídos à sua volta?

"Mesmo que intenção tenha sido 'resgatá-los' depois, o fato é que software proprietário foi usado para desenvolver software livre, bem ali no seu nascedouro."

novamente, e daí? o reverso também é verdadeiro: inicialmente, todo software era livre, lá pelos idos de 1950, 1960 e boa parte dos 70. Sabia que o interpretador Basic original que Bill Gates "escreveu" para o Altair era livremente baseado em interpretadores disponíveis na época? Pode-se dizer que Bill Gates começou sua fortuna com código livre e depois com um sistema que não era seu ( DOS )...

"Como podemos esperar que a simples intenção redima os atos de RMS, pela ética que pretende agora nos promulgar?"

ah, meu chapa, vá se f*der.

"RMS tem uma visão antiquada de software. Hoje em dia até mesmo o hardware é projetado em software...O que é um processador, tipo Intel? É software! É isso mesmo. Software. Os projetistas de processadores são na realidade programadores. Um processador não passa de um programa armazenado no hardware."

Nada como esticar um pouco os conceitos para caber em nossos argumentos. De qualquer forma, é necessário uma máquina física, lá embaixo, para rodar as abstrações de mais alto nível que normalmente chamamos de software.

"O GNU/Linux, por mais que esteja livre, sempre será DEPENDENTE, para usar um termo do Stallman, da tecnologia do processador sobre o qual rodar."

Tudo tem um limite. Felizmente, Stallman confinou o seu à criação de software, não hardware livre. Poderia-se arguir que mesmo que rodassem sobre hardware livre, a instituição para a qual aquelas máquinas rodam não é livre. Ou seu governo. Ou o mundo...

Se a gente não limitar nosso escopo de ação, nunca chegamos a lugar nenhum e ficamos apenas especulando: "e se..."

"A JVM é na realidade um processador, que tanto pode ser emulado em software, como implementado em hardware. Se a JVM fosse só um processador, o que Stallman diria?"

Não diria nada. Mas a JVM é bem mais que um processador ( está mais para um SO ) e de qualquer forma sua argumentação contra a Java Trap não é dirigida a VM exatamente, mas aos bilhões de bibliotecas não livres que formam a plataforma Java.

"Penso que RMS, ainda que líder incontestável e peça fundamental para desenvolvimento do software livre, extrapola seu dever social ao tentar definir software sob a ética."

melhor alguma ética do que nenhuma, eu acho.

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

Vamos fazer a crítica da crítica da crítica: ah, meu chapa, vá se f*der.

Usar de falácias não vai ajudar a provar seu argumento.

O problema é que RMS condena quem usa Java por fazer uso de software proprietário para rodar. Ora, isso não era pecado na época que software livre precisava dele para sair do limbo.

Quer dizer então que são dois pesos e duas medidas?

E mais: as pessoas não são julgadas pelas intenções. Mas sim pelos atos. RMS lançou mão de SP para produzir SL. Isso é fato. Eu não tenho nada contra. Mas que moral ele tem para condenar agora quem faz uso da mesma prática?

Se basta mencionar uma intenção para que alguém fique isento de um ato então, neste caso, encha o mundo de Java e diga que sua intenção é resgatá-lo depois. Quem poderá condenar você? Stallman?

melhor alguma ética do que nenhuma, eu acho.

Verdade.

RMS é programador, não legislador. Quando tenta ser legislador, destrói a ética que ele mesmo constriui, ficando sem nenhuma. Eu gosto do Stallman, portanto preferiria que ele usasse outro argumento para justificar a escrita de uma alternativa ao Java, porque este argumento está fraco demais para a mente minimamente inteligente.

Nossa, realmente... você est: Nossa, realmente... você está no mercado?

XML não tem credito nenhum relacionado ao sucesso do seu "irmão" HTML. Apesar da sintaxe parecida, os objetivos de ambos são quase sempre diferentes.

1. E você acha que XML foi modelado do jeito que foi por graça? Compare a legibilidade dos códigos que você mesmo postou, e veja a diferença. Isto que vc postou é simplesmente um gosto seu, nada mais.

3. Primeiro procure o significado de Expressivo.
Web Services foi/é/e vai continuar sendo a maior tendencia na troca de dados, até hoje nao se estabeleceu NENHUM padrão melhor (padrao = padronizado? essa palavra deve ter algum sentido pra vc) na integração de sistemas, independente de linguagem/plataforma. O dia que você tiver que trabalhar com esse tipo de integração aí sim você pode vir aqui criticar e dizer os defeitos e que existe algo melhor a se fazer, não ficar na teoria aí. Se o seu ideal de troca de dados é CGI/URL, meu amigo... não acredito que você tenha trabalhado em algum sistema mais complexo.


"Basta quem requisita as informações se adequarem ao protocolo sobre formatos de parâmetros e formato de saída"


Isto não é realidade, não neste mundo. Isto sim é estúpido, e não XML.

XML não está aí pra ser a solução única das coisas, mas está MUITO longe de ser redundante e estúpido como você mesmo está falando (atacando). Estúpido é generalizar e não saber estudar caso a caso pra saber qual solução é melhor, qual tecnologia se adequa melhor à necessidade.


"Quanto a java, é uma linguagem boçal e antiga, um sub-C++ com algumas influências de Lisp e Smalltalk para dar um ar moderno. E uma implementação ineficiente baseada em VM. Mas acima de tudo, toneladas de bibliotecas absolutamente necessárias para se fazer qualquer coisa útil. Quando digo que java é redundante, me refiro principalmente, além da natureza repetitiva da sintaxe da linguagem, ao fato de que essa biblioteca imensa"


Quanto à redundancia de SINTAXE, não entendi. Poderia explicar, dar referencias/exemplos?

Já em relação à API, acho sim que em diversas partes há redundancia (quando me referi ao modo "acadêmico" em que são feitas as coisas), mas isso não a torna uma linguagem boçal e antiga. Então por que cargas d'agua é tão usada? Será que porque a empresa que a representa tem um marketing agressivo com o da Microsoft, que gasta milhoes em publicidade e milhares em desenvolvimento? Ou foi por mérito? Se Java é tão ruim assim, porque domina os sistemas de grande porte críticos, evolui a cada dia, tem mais frameworks que qualquer linguagem que eu já vi nessa vida, tem uma comunidade MUITO ativa, tem suporte (VM) para DIVERSOS SO's. Boçal e antigo... sinto muito, mas não cabe isso aqui.

Quanto à API ser ou não do seu gosto, conhece a filosofia OSS? "Não gostou, faça melhor!". Ah sim, você é programador e não quer perder tempo fazendo isso... Procure no Google alguem que tenha feito algo que você precisa, há grandes chances de você encontrar algo que te ajude. Você não está preso a API do java, de jeito algum.

O tamanho da API do java e ela estar BEM documentada só dá méritos a java, prova que alguem fez e documentou algum recurso que você pode utilizar. Vá fazer qualquer codigo em C++ ou smalltalk que você precise fazer algo mais complicado e você vai depender de bibliotecas feitas por você ou alguma coisa jogada na WEB que nem sempre está documentada.


" e rodando numa lenta e aparvalhada VM simplesmente reproduz bibliotecas já existentes no SO subjacente, como acesso a BDs, parsers xml, compactadores, GUIs e coisa e tal."

Já ouviu falar em MULTIPLATAFORMA? É o que divulgam aí como uma das qualidades do JAVA, acho que já ouvi falar a respeito.

Desculpe os comentários mal criados, mas você continua NÃO dando argumentos técnicos e mesmo assim criticando pesado algumas coisas que você demonstra não ter conhecimento (posso estar errado, mas vários conceitos aí são falhos/faltosos).


Algumas referências pra leitura geral:
http://www.linhadecodigo.com.br/artigos.asp?id_ac=30&sub=12
http://www.fabriciorogerio.hpg.ig.com.br/XML-in-10-points-Portugues.htm

Posix aberto? Talvez no eMule: Desde quando o padrão POSIX é aberto? Tal qual o padrão Java, ele só pode ser alterado por um comitê restrito, do IEEE. Antes que você dê uma das suas respostas sem nenhum respaldo em fatos - na esperança que ninguém confirme os fatos - eu esclareço: o IEEE não é subordinado ao governo americano.

Diferentemente do Java, o padrão POSIX não está disponível gratuitamente, nem pode ser re-distribuído. Se você quiser uma cópia, só pagando.

Tecnicamente falando, o padrão implementado pelo kernel do Linux (POSIX) é mais fechado do que o padrão implementado pelas máquinas virtuais Java livres (padrão Java), ou do que o padrão implementado pelo projeto Mono (.NET). Portanto, se seu medo são os padrões fechados, utilize o Mono, utilize o Java, mas corra do Linux, e dos BSDs.

As classes sun.*, que você cita em outros comentários, não fazem parte do padrão. São extensões. O core do padrão Java está disponível gratuitamente, embora o padrão em si não possa ser alterado por quem quiser. (aliás, como qualquer outro padrão. Se qualquer um pudesse mudar, não seria uma padrão. Padrões, não por acaso, dependem de padronização)

XML for dummies: XML é redundante? Compacte. Use o gzip, e ele retira a redundância. Do outro lado, descompacte, e leia o XML normalmente. Essa tecnologia revolucionária é utilizada pelo Apache a alguns anos.

Webservices! Não há nada que se faça de forma pesada e redundante com xml e webservices ( particularmente aqueles servidos por VM lerdas como a de Java ) que não se faça mesmo com um script CGI e parâmetros de URL. Nada.

Você está brincando, né? Imagina implementar um Google Maps, com CGI. Cada vez que você quiser andar um pouco pra cima no mapa será necessário criar uma nova conexão http, enviar quanto você quer subir, receber o novo mapa... interatividade zero. Já com o uso de webservices, foi possível implementar drag-n-drop via web. Onde se faz isso com cgi?

Nemesis, deixe o saudosismo para outras áreas... A informática muda, evolui... Eu imagino que se você tivesse sido consultado quando a IBM lançou um computador pessoal, você teria sido uma das pessoas a dizer: "computador na mesa de cada pessoa? pra que? bota um mainframe, e um terminal burro, que já é mais do que suficiente. utilizar um processador por pessoa é muito disperdício". Evolua.

É pesado demais, simples!: É pesado demais, simples!Dá aquela travadinha até em pc's novos.

Eu que não entendo esse amor por Java usando-se Java em tudo até coisas para usuários domésticos que mal vêem a chícara ficam com raiva.

Rafael Kafka

s/,/./: Então tem que trocar vírgula por ponto.

não.: "Nossa, realmente... você está no mercado?"

Não, eu estou em casa, mas fiz compras ontem. :)

Agora, sério, se eu estivesse no mercado, iria à falência. Cobro caro pelas minhas preciosas pérolas de conhecimento. :))

XML não tem credito nenhum relacionado ao sucesso do seu "irmão" HTML. Apesar da sintaxe parecida, os objetivos de ambos são quase sempre diferentes.

"Compare a legibilidade dos códigos que você mesmo postou, e veja a diferença."

Eu já disse uma vez e vou dizer de novo: depois que o cara se acostuma com aberrações como notação húngara, nomes kilométricos para variáveis, chamadas de métodos em sequência tudo na mesma linha, java e xml... simplicidade e clareza parecem tão sem graça quanto um deserto...

"Primeiro procure o significado de Expressivo."

Expressivo é dizer muito com poucas palavras. Como, por exemplo, quando vc consegue fazer algo em Haskell, ou Perl, em algumas poucas linhas que levariam várias dezenas de linhas em Java. e alguns imports.

"Web Services foi/é/e vai continuar sendo a maior tendencia na troca de dados, "

Ah, é uma tendencia, é? Que legal! Olha, quando a tendencia for as pessoas se jogarem de cima de prédios me avisa pra eu entrar na onda também...

"até hoje nao se estabeleceu NENHUM padrão melhor (padrao = padronizado? essa palavra deve ter algum sentido pra vc) na integração de sistemas, independente de linguagem/plataforma."

Não tenho nada com resultados de uma requisição que sejam dados estruturados e precisem de uma notação padronizada. Mas requerer que os parâmetros sejam verbosamente encapsulados em um doc xml ao invés da simplicidade de simples duplas var=valor de parâmetros GET ( um padrão também, aliás )... sei não, é estupidez demais pra mim.

"Se o seu ideal de troca de dados é CGI/URL, meu amigo... não acredito que você tenha trabalhado em algum sistema mais complexo."

Obviamente não é meu ideal, mas dei apenas como um exemplo de que é possível ser simples e funcional, sem apelar para a estupidez sempre associada à argumentação quantitativa. A argumentação do "mais é melhor".

"'Basta quem requisita as informações se adequarem ao protocolo sobre formatos de parâmetros e formato de saída'

Isto não é realidade, não neste mundo. Isto sim é estúpido, e não XML."

Tem certeza? Vc não pensa assim quando faz chamadas de funções em sua linguagem estaticamente tipada favorita, pensa? Não. Vc adequa os parâmetro de chamada da função aos tipos que eles exigem. E melhor estar preparado para receber um tipo de dado tal como a função especifica que vai retornar.

Pq deveria ser diferente com a web?

"Quanto à redundancia de SINTAXE, não entendi. Poderia explicar, dar referencias/exemplos?"

Java:


public class Pessoa {
  private String nome;
  Pessoa( String nome ) {
    this.nome = nome;
  }
  public String get_nome() {
    return this.nome;
  }
  public void set_nome( String nome ) {
    this.nome = nome;
  }
  public String toString() {
    return "Oi, " + this.nome + ", aqui.";
  }
}
public class PessoaFisica extends Pessoa {
  private int idade;
  private char sexo;
  PessoaFisica( String nome, int idade, char sexo ) {
    super( nome );
    this.idade = idade;
    this.sexo = sexo;
  }
  PessoaFisica( String nome ) {
    this( nome, 33, 'm' );
  }
  PessoaFisica( String nome, int idade ) {
    this( nome, idade, 'm' );
  }
  public int get_idade() {
    return this.idade;
  }
  public void set_idade( int idade ) {
    this.idade = idade;
  }
  public char get_sexo() {
    return this.sexo;
  }
  public void set_sexo( char sexo ) {
    this.sexo = sexo;
  }
  public String toString() {
    return super.toString() + this.idade + " anos.";
  }
}



Condensado em Ruby:


class Pessoa
  attr_reader :nome
  attr_writer :nome
  def initialize( nome )
    @nome = nome
  end
  def toString()
    "Oi, #{@nome}, aqui."
  end
end
class PessoaFisica < Pessoa
  attr_reader :idade, :sexo
  attr_writer :idade, :sexo
  def initialize( nome, idade = 33, sexo = 'm' )
    super nome
    @idade = idade
    @sexo = sexo
  end
  def toString()
    super + " #{@idade} anos."
  end
end


Entendeu agora a redundância, verbosidade e repetitividade de java quando comparada com uma linguagem realmente poderosa, expressiva e moderna? Alguém que não estou lembrado agora disse que uma linguagem de programação de baixo nível é aquela em que se atenta muito à irrelevância. Linguagens de alto nível permitem a vc se expressar no nível do problema ao invés de ter de ficar lidando com as limitações da linguagem.

Veja, tirando todos os incômodos ; finalizadores de linha, todos aqueles overloads redundantes para a passagem de parâmetros padrão e as declarações de acessores de atributos ( attr_reader e attr_writer criam os métodos correspondentes em ruby ) e temos o modelo simples, a regra de negócio em si. Que é no que deveríamos estar nos concentrando.

Linguagens _expressivas_ nos permitem nos concentrar nas regra de negócio ao invés de ficar lutando contra limitações da ferramenta. Além de que o código fica muito mais claro, objetivo e conciso, importantes durante manutenção.


"não a torna uma linguagem boçal e antiga. Então por que cargas d'agua é tão usada? Será que porque a empresa que a representa tem um marketing agressivo...? Ou foi por mérito? Se Java é tão ruim assim, porque domina os sistemas de grande porte críticos, evolui a cada dia, tem mais frameworks que qualquer linguagem que eu já vi nessa vida, tem uma comunidade MUITO ativa, tem suporte (VM) para DIVERSOS SO's."

COBOL também apresenta essas exatas mesmas características. Apenas é ainda mais boçal e antiga.

Algumas dessas questões são como aquela do ovo e da galinha: é a mais usada pq tem mérito ou tem mérito por ser a mais usada?

"Vá fazer qualquer codigo em C++ ou smalltalk que você precise fazer algo mais complicado e você vai depender de bibliotecas feitas por você ou alguma coisa jogada na WEB que nem sempre está documentada."

"Aqui está seu sistema" -- disse o analista de sistemas ao cliente, entregando-lhe um calhamaço de umas trezentas bem documentadas páginas com diagramas e use-cases, pouco antes de levar um pé-na-bunda...


"Já ouviu falar em MULTIPLATAFORMA? É o que divulgam aí como uma das qualidades do JAVA, acho que já ouvi falar a respeito."

Não deixa de ser redundante, e pagar por isso em performance. Aliás, Qt, em C++, também é um framework plenamente MULTIPLATAFORMA e nem por isso lerdo e pesado como Java. E bem documentado também, se lhe interessa.


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

revolução vs evolução vs involução: "Compacte. Use o gzip, e ele retira a redundância."

Se não me engano, praticamente toda informação textual enviada via http é compactada com gzip por padrão pelo servidor ( ou será só o Apache que oferece isso? ). então, não é necessário.

Mas compactar não esconde o fato de que xml, html e sgml são reinvenções estúpidas e verborrágicas das s-expressions Lisp. Não adianta tapar o sol com a peneira.

"Essa tecnologia revolucionária"

De revolucionária nada tem, já que é apenas uma reinvenção das s-expressions Lisp, mais verbosa para talvez agradar mentecaptos e para ajudar a vender hardware mais potente.

Talvez vc diga que é revolucionária por ter ajudado a integrar sistemas distintos a partir da padronização da forma como trocam dados entre si. Mas, como eu disse, isso é mérito de html e da web.

Bom, se a sintaxe não é tão concisa e eficiente como a de Lisp e a popularização de troca de informações não é mérito seu, eu diria que xml é mais um involução do que evolução ou, pior, revolução.

"é utilizada pelo Apache a alguns anos."

é claro! Faz tempo que o Apache deixou de ser um bom, compacto e livre httpd para se tornar um comitê político partidário de soluções Java, com forte influência da IBM. E o que vem com Java? claro, nosso bom xml. Frente à uma plataforma tão pesada, repetitiva e redundante, escrever arquivos de configuração xml é uma benção...

"Imagina implementar um Google Maps, com CGI. Cada vez que você quiser andar um pouco pra cima no mapa será necessário criar uma nova conexão http, enviar quanto você quer subir, receber o novo mapa..."

pq vc acha que é diferente hoje? http é um protocolo stateless. e a web usa http e ponto.

É perfeitamente possível criar apps AJAX usando CGI no servidor, sim. A maioria dos apps AJAX usa um frame escondido que envia as requisições http e recebe o resultado da requisição, que pode ser html, xml, imagens ou qualquer dado. Quem disse que vc vai ter que dar reload na página que é apresentada atualmente? Basta modificar, com javascript e DOM, o que é necessário na página atual dado a resposta. Transparente para o usuário...

Então, esse é a receita para um app AJAX com CGI: um frame escondido que faz as requisições com parâmetros de URL, recebe o resultado e chama a função javascript adequada para modificar a tela de apresentação para o usuário.

O que menos importa em AJAX é xml. Xml não é uma solução mágica.

Se a web dependesse das tecnologias utilizadas seja no lado servidor ou cliente, não seria a web.

"Já com o uso de webservices, foi possível implementar drag-n-drop via web. Onde se faz isso com cgi?"

Pq não poderia ser feito? Uma requisição webservice simplesmente seria um documento xml descrevendo os parâmetros e o procedimento a ser chamado. Nada que não se possa fazer com parâmetros URL de forma muito mais prática.

Não foi feito pq não se usa mais CGI na prática. É chato, sim, ter que emular sessões com um mecanismo de execução que inicia um novo processo a cada requisição. Além do fato de que as pesadas soluções Java ou .Net seduziram a grande massa de desenvolvedores com suas promessas de facilidade de uso, escalabilidade, performance e integração. Promessas de vendedor...

Ademais, eu dei o exemplo em CGI apenas como exemplo. Eu estava mais interessado nos parâmetros GET OU POST, que também são perfeitamente acessíveis em qualquer framework Java ou no ASP.NET.

Com esse parâmetros, uma chamada à webservice poderia se reduzir a algo como:


http://server/app/service.cgi?param1=foo¶m2=bar


Trivial, ao passo que com webservice vc precisa gerar todo um documento xml só para passar os parâmetros. bobagem...

"Nemesis, deixe o saudosismo para outras áreas..."

não é saudosismo. é apenas deprimente ver que o que é apresentado com o "solução" é apenas mais problema...

"imagino que se você tivesse sido consultado quando a IBM lançou um computador pessoal, você teria sido uma das pessoas a dizer: 'computador na mesa de cada pessoa? pra que? bota um mainframe, e um terminal burro, que já é mais do que suficiente. utilizar um processador por pessoa é muito disperdício'"

não, eu provavelmente diria: "IBM é o c*ralho. Eu quero meu Apple ][". ;)

mas, cá entre nós, o que é a web hoje senão um imenso mainframe com nós nos conectando com nossos terminaizinhos burros ( browsers ), hein? :)

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

Padrões são padrões, imple: Padrões são padrões, implementações são implementações. O cara aí em cima começou a misturar os dois e tive que responder. Mas entre ficar com um padrão um pouco mais fechado, mas com várias boas implementações livres e plenamente funcionais; e um padrão gratuitamente acessível mas com várias implementações livres mais-ou-menos funcionais por conta, dentre outras razões, de dependências de algumas interfaces obscuras e não-documentadas; prefiro ficar com o primeiro, obrigado.

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

Legal, Ruby é moderna e talz...: Agora, onde eu acho uma empresa que queira pagar bem a um programador Ruby para trabalhar num projeto importante?

onde?: Que tal olhar no próprio quintal? Empresas em geral não gostam de soluções que não tenham uma empresa por trás. Elas se sentem mais seguras se tiverem alguém pago a quem pedir socorro ou a quem culpar.

Faça sua parte: mostre o poder de ferramentas como ruby. Faça seu marketing pessoal para essas ferramentas, que realmente só contam com bom boca-a-boca ao invés de milhões em propaganda ( enganosa ).

Não adianta falar, claro. Faça e mostre como a ferramenta te ajudou em determinada tarefa com um mínimo de esforço. Obviamente vc não vai chegar no típico projeto java em que vc está trabalhando e de sopetão declarar que daqui pra frente só escreve em Ruby. Comece menos ambicioso: faça uso da ferramenta para automatizar pequenas tarefas rotineiras, mas essenciais no processo de produção, e que ainda não tenham uma solução em java. Declare que a ferramenta te ajudou a se livrar de cansativas e demoradas intervenções manuais e te ajudou na produtividade.

É assim que se faz. É claro que há sempre a chance de algum bozo na empresa querer reescrever seu script em java, para ficar mais "padrão" e menos alien...

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

Resumo: Ruby é uma linguagem para a qual não há mercado.

exatamente...: ...pois o mercado é regido e consumido por boçais e suas ferramentas primitivas.

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

Então fica assim: Ruby é divino, Java é diabólico.: Ruby representa o ideal de perfeição (acadêmica). Java representa os cuidados da vida (comercial).

Como o homem é feito das duas coisas: espírito + carne, então fiquemos com as duas: Ruby e Java.

Ruby enleva meu espírito. Java paga minhas contas.

bobagem: Acho que deveria ser objetivo na vida de todo desenvolvedor sempre estar em busca de melhores ferramentas. Se acomodar com as ferramentas atuais que pagam as contas e deixar a escolha de tais ferramentas nas mãos de gerentes que não põem efetivamente a mão na massa à anos, é péssimo negócio.

Se Ruby enleva o espírito, pq não fazer dela também a ferramenta que paga as contas? seu raciocínio é meio contraditório e masoquista...

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

O começo do Fim:
Ah, é uma tendencia, é? Que legal! Olha, quando a tendencia for as pessoas se jogarem de cima de prédios me avisa pra eu entrar na onda também...


Legal, eu vou avisar você tambem quando suas ideias tiverem mercado de trabalho como as coisas "estúpidas" com as quais eu e meio mundo trabalham. Se não tem o que comentar, o silêncio é uma ótima opção :)

Antigamente quando eu tinha uma cabeça pouco voltada ao mercado de trabalho, achava tudo que fosse diferente LINDO. "Noooossa, ruby faz isso e aquilo e ninguem usa? panacas!". Aí você começa a ver que certas coisas são usadas por algum motivo e outras nao sao tao usadas por n outros motivos. As vezes por campanhas muito bem feitas (geralmente MS) e as vezes por mérito proprio, como java e padrao xml são. Gostaria MESMO de ver alguns dos sistemas feitos e J2EE em CGI/Perl, e nisto, considerar TODAS as variaveis de um projeto, de modelagem, passando por desenvolvimento e chegando em manutenção.


Não tenho nada com resultados de uma requisição que sejam dados estruturados e precisem de uma notação padronizada. Mas requerer que os parâmetros sejam verbosamente encapsulados em um doc xml ao invés da simplicidade de simples duplas var=valor de parâmetros GET ( um padrão também, aliás )... sei não, é estupidez demais pra mim.


Não, vc nao tem nada do tipo? Nada de estrutura? Você prefere passar tudo isso por um GET? Ainda se fosse um POST... Você tem noção da LIMITAÇÃO que é usar GET com CGI? Não vou procurar dados precisos, mas te garanto que é ridiculo a limitação, nao pode ser usado em nada mais complexo. Em sisteminhas de cadastro de maillist talvez, mas fica por aí. Agora, se considerar usar CGI com POST, aí você pode ter uns formulariozinhos de cadastros mais complexos, e até um ótimo chat do UOL!

Quanto ao codigo em Ruby, realmente, muito conciso! Meio estranho pra mim que não estou habituado com a sintaxe (acho realmente que a sintaxe do java, mesmo pra quem não conhece muito, é de primeira mais legivel). Agora, se você mudar um pouquinho a classe e quiser colocar algo alem nas ações de get e set da variavel (isso no ruby), como você faria? qualquer ação a mais, como incrementar uma variavel a cada get/set feito (exemplo bobo, quero ver a sintaxe apenas). Acho que não vai ficar muito diferente do exemplo em java. sintaticamente não acho o java muito redundante, mas isso é uma visão pessoal e é perda de tempo ficar discutindo mais disso. Acho que provei meu ponto.

Quanto a comparação com COBOL, nao dedico mais do que essa linha para comentar, não seria certo...



"Aqui está seu sistema" -- disse o analista de sistemas ao cliente, entregando-lhe um calhamaço de umas trezentas bem documentadas páginas com diagramas e use-cases, pouco antes de levar um pé-na-bunda...


Em primeiro lugar, estamos falando de desenvolvimento. Ninguem entrega um sistema em java com a API da SUN impressa pro cliente e fala "olha, tá aqui tudo que eu usei, viu!". Novamente você está distorcendo as coisas.

Tomando um pouco a sua visao: "Realmente, a API do java é só um peso, é algo que foi investido um grande trabalho apenas para 'ficar bonito'". Tenha dó rapaz, que distorção você fez aqui! Se você realmente acha as coisas equivalentes, meus pêsames, não há pé de cabra que abra essa mente fechada e generalista que você tem.

>sarcasmo< Eu, como desenvolvedor, acho que é bem melhor pegar um código mal redigido e com NENHUM comentário sequer, quanto mais documentação, e bote nesse cenário que eu preciso usar esse código num sistema cujo deadline é daqui a 2 dias. >/sarcasmo<... cof cof cof


Não deixa de ser redundante, e pagar por isso em performance. Aliás, Qt, em C++, também é um framework plenamente MULTIPLATAFORMA e nem por isso lerdo e pesado como Java. E bem documentado também, se lhe interessa.


Se é redundante, pelo menos só o codigo da VM (que pouco me interessa) que me é fornecida pela SUN nas plataformas em que minha aplicação irá rodar) o é. Eu faço uma vez, e rodo em mil lugares. Quer vantagem maior do que essa? Se eu tenho uma base unica para N sistemas operacionais, o que é mais facil? Portar uma framework para cada plataforma ou apenas codificar um em uma linguagem multiplataforma, e como você mesmo sabiamente diz, FOCAR em logicas de negócio em vez de limitações de linguagem.

Gozado você falar bem de QT (que é um senhor de um toolkit)/C++ sendo que o redundante java pode ser considerado um filho do C++, sintaticamente. Só que é uma pena QT estar fora desse escopo, fale de linguagens e plataformas que confrontem java, e não casos de "frameworks" que você acha que atende as necessidades do MERCADO DE TRABALHO (pronto, agora acho que defini certo pra nao confundir com o mercadinho da esquina).

O que mais me revolta não é que você tenha sua opinião e faça valer aqui neste espaço, e sim a ignorância de chamar de estúpido tudo que é contrário ao seu conceito. A vida ensina, meu caro. Quem tem visão fechada desse jeito pode levar uma pancada de lado por não ver o panorama geral. Continue idolatrando tudo que não é usado em massa pelas empresas e seja feliz, mas quando quiser brincar de gente grande e entender que nem tudo é o que você considera ideal é realmente o ideal para todos os casos que existem por aí.

Pra não dizer que sou puxa-saco de java, um pouco da minha experiencia com tecnologias de desenvolvimento(em ordem cronologica):

* Iniciei com Clipper
* Passei pra Pascal
* Delphi
* CGI/Perl
* PHP (não é bem uma linguagem, mas é uma alternativa ótima ao CGI/Perl)
* Java
* Python (bem pouco)
* C#/.NET (com o qual tenho trabalhado mais ultimamente)

Eu poderia até dizer de VB (incluso VB.NET aí) o que você fala de java: redundante, sintaxe horrivel, enfim, estúpido. Mas não o faço, pois se eu achar algum caso em VB.NET que não seja melhor coberto por C#/.NET, com certeza farei em VB.NET, sem hesitar (apesar de achar deveras complicado de isso acontecer).

Se com essa redação toda eu não convencer você a parar de chamar de estúpido estas tecnologias, me dou por vencido e deixo você ser feliz (mas nao te respeitarei por isso).

Porém, se você parar com essa mania irritante, e passar a considerar que outras linguagens cobrem melhor todos os casos que vc viu até hoje , melhor que java, mas que não tira todo o mérito das outras alternativas, ai sim terei um feedback positivo desse falatório todo.

:
...pois o mercado é regido e consumido por boçais e suas ferramentas primitivas.


ser um bando de terráqueos estúpidos, que não sabe o que você está fazendo na Terra ainde? Todo mundo mora aqui, devem m que morar na lua eh muito mais facil, tudo fica mais leve lá!

O dia em que você conseguir provar pra 51% dos que usam outra tecnologia que ruby é viável, que a MIGRAÇÃO pra ruby é viavel, que o aprendizado de Ruby pra quem tem todo esse know-how de outras tecnologias é viavel, aí sim você pode começar a se vanglorizar de que Ruby não é mais uma ótima ideia que vai ser considerada um ET e que teoricamente poderia substituir todas a "estupidez" das outras ferramentas.

Depois dessa discussão toda, até eu vou dar uma olhada em ruby com mais atenção, juro que vou aprender alguma coisinha, nem que seja algo pouco mais complexo que um hello world. Mas juro de pé junto que mesmo que ache a linguagem maravilhosa, nao vou sair gritando aos quatro ventos que o mundo - ruby é estupidez.

Sugiro que você comece por provar pro seu chefe (se tiver) dos seus conceitos, e se ele nao estiver de acordo você o chame de Estúpido, peça as contas (depois da conversa com o chefe acho que nem precisa pedir), e monte uma empresinha modesta que bata as medias empresas, já que as outras soluções, perto da sua, são ESTÚPIDAS. E lógico, que dure mais de 5 anos, e que saia do negativo. E mais, que volte aqui nesta mesma página (sim, ela vai durar um bom tempo ainda, se deus quiser) e me mande um convite pra conhecê-la. Eu mordo minha lingua em publico, e ainda tiro fotos!

[]s!

Nem tanto: Se Ruby enleva o espírito, pq não fazer dela também a ferramenta que paga as contas?

Só se estiver ameaçado pela concorrência. Como o Ruby não ameaça o Java, que está estabelecido, fico com o Java. Quando Ruby ameaçar o Java, vou para o Ruby.

seu raciocínio é meio contraditório e masoquista...

Masoquismo é dar murro em ponta de faca. Veja que estou em paz com o Ruby e com o Java. A massa de vantagens aparentes do Ruby não compensa seus riscos, pelo menos não hoje, mas vale como ideal a ser alcançado algum dia. Por outro lado os benefícios colhidos pelo Java em muito compensam suas dificuldades aparentes.

Não vejo porque não possa tirar proveito das duas coisas. Admirar a superioridade do Ruby em relação ao Java quanto a sua verbosidade não me faz rejeitar Java. Nem me ater aos benefícios hodiernos do Java me faz rejeitar o futuro para qual Ruby aponta.

Ruby e Java: gosto dos dois, cada qual por seu mérito.

"O dia em que você conseguir: "O dia em que você conseguir provar pra 51% dos que usam outra tecnologia que ruby é viável, que a MIGRAÇÃO pra ruby é viavel, que o aprendizado de Ruby pra quem tem todo esse know-how de outras tecnologias é viavel..."

E como vou provar se não tiver a chance de mostrar? Não foi isso que recomendei? Mostrar que funciona, que traz benefícios? Agora, se o cara quer meter à força, realmente não dá... é mais ou menos como a migração para Linux, há muita resistência, muitos preconceitos, muita gente com medo de perder empregos ( embora ruby possa ser rapidamente absorvida por qualquer programador C++ em um fim-de-tarde )...

"Depois dessa discussão toda, até eu vou dar uma olhada em ruby com mais atenção"

É uma boa forma de se arejar um pouco a mente e ver coisas sob uma perspectiva diferente. Eu uso Delphi no trabalho ( sem chance de mudar ), mas faço bom uso de várias técnicas que aprendi com as ferramentas de scripting e linguagens funcionais.

"Mas juro de pé junto que mesmo que ache a linguagem maravilhosa, nao vou sair gritando aos quatro ventos que o mundo - ruby é estupidez."

Claro que não. Se eu saísse gritando assim, seria por Scheme. :)

"Sugiro que você comece por provar pro seu chefe (se tiver) dos seus conceitos, e se ele nao estiver de acordo você o chame de Estúpido, peça as contas (depois da conversa com o chefe acho que nem precisa pedir), e monte uma empresinha modesta que bata as medias empresas, já que as outras soluções, perto da sua, são ESTÚPIDAS."

Sem dúvidas gostaria de ter meu próprio negócio e escolher a própria tecnologia com que trabalho. Mas, embora me considere um programador razoavelmente habilidoso, como empreendedor ou gerente sou um belo centro-avante. Quem sabe um dia...

Enquanto isso, vou comendo o proverbial pão que o diabo amassou. Mas, apesar disso, não tenho que gostar. E ao invés de me acomodar, posso sempre sonhar com ferramentas melhores que meu martelinho atual...

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

a esposa e a amante: seu argumento parece idêntico e igualmente cretino. vc gosta das duas por razões diferentes: a esposa por representar a segurança, a família e por poder chamá-la de mãe; e a amante para saciar suas taras e te punhetar...

Eu quero uma esposa que seja boa amante. Será que é pedir demais?

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

mais: "Legal, eu vou avisar você tambem quando suas ideias tiverem mercado de trabalho como as coisas "estúpidas" com as quais eu e meio mundo trabalham."

Blz. Eu estou incluído aí nesse meio mundo também, mas estou fazendo minha pequena parte para mudar o quadro. Quem sabe um dia meu pequeno esforço te beneficie também e vc me agradeça por te ajudar a encontrar melhores ferramentas?

"Aí você começa a ver que certas coisas são usadas por algum motivo e outras nao sao tao usadas por n outros motivos.

"Gostaria MESMO de ver alguns dos sistemas feitos e J2EE em CGI/Perl, e nisto, considerar TODAS as variaveis de um projeto, de modelagem, passando por desenvolvimento e chegando em manutenção."

Está pedindo muito, mas, de qualquer maneira, saiba que Perl está por trás de pelo menos 2 sites norte-americanos de tráfego intenso:

http://www.amazon.com ( rodando mod_fastcgi! )
http://slashdot.org

Enquanto isso, nossa intranet abastecida a JSP não é tão rápida quantos os mesmos, apesar da boa infraestrutura de hardware ( servidores Sun ) e de bem menos usuários.

"Não, vc nao tem nada do tipo? Nada de estrutura? Você prefere passar tudo isso por um GET?"

Estamos falando de parâmetros para webservices, não dados cadastrais de formulários. Qual é o problema de um GET? Já ouviu falar em KISS?

"Quanto ao codigo em Ruby, realmente, muito conciso! Meio estranho pra mim que não estou habituado com a sintaxe (acho realmente que a sintaxe do java, mesmo pra quem não conhece muito, é de primeira mais legivel)."

Então, só pra deixar um pouco mais claro: Ruby usa uma convenção chamada "princípio da menor surpresa" como regra de design da linguagem. Ela usa alguns sinais especiais para diferenciar entre diferente tipos de variáveis. Globais são hediondos, e caso queira usá-las, use um $ antes dela. @ marca uma variável como de instância, @@ de classe e uma variável sem nenhum sig antes dela é local ao método em que está sendo referenciada.

Aquelas expressões "#{}" permitem interpolação de _expressões_ dentro de strings. Seriam equivalentes ao printf( "nome: %s", nome ) de C. apenas bem mais fácil e flexível. Vc pode fazer "o resultado de #{a} + #{b} = #{ a + b }".

Não é necessário escrever return foo: a última expressão avaliada em um método é retornado.

Mais: chamadas de métodos não necessitam de parênteses, mas vc pode colocá-los se quiser tirar desambiguidades eventuais. Um método especial chamado initialize é o construtor de uma classe, ali vc especifica variáveis de instância. super faz referência não à classe pai, mas ao método atual na classe pai, portanto vc não precisa dizer super.toString, mas apenas super.

NÃO EXISTE referências a variáveis de instância ou de classe fora de uma classe: tudo são chamadas à métodos. Por isso não precisam de parênteses. Isso pq Ruby é completamente OO, semelhante a Smalltalk: tudo é objeto e com comportamento encapsulado em métodos e só através deles vc é capaz de mudar o estado dos objetos.

Até mesmo por isso, foram criados aqueles métodos construtores de métodos acessores padrão, muito convenientes. Do qual falamos agora...

"Agora, se você mudar um pouquinho a classe e quiser colocar algo alem nas ações de get e set da variavel (isso no ruby), como você faria? qualquer ação a mais, como incrementar uma variavel a cada get/set feito (exemplo bobo, quero ver a sintaxe apenas). Acho que não vai ficar muito diferente do exemplo em java."

Precisamente, vc vai ter que declarar explicitamente. Ainda assim, perceba que Ruby é uma linguagem dinamicamente tipada, o que significa, entre outras coisas, que vc não precisa declarar os tipos das variáveis: variáveis não tem tipo associado, os valores que elas contém a dado momento é que têm. Isso significa código mais conciso.

"Acho que provei meu ponto."

engraçado, todos nós sempre temos essa sensação, não?... ;)

"Quanto a comparação com COBOL, nao dedico mais do que essa linha para comentar, não seria certo..."

hehe, sabe que é a verdade. que Java se tornou o COBOL moderno...

"Ninguem entrega um sistema em java com a API da SUN impressa pro cliente e fala 'olha, tá aqui tudo que eu usei, viu!'."

A comparação não foi essa: quis mostrar como a importância demasiada da documentação às vezes atrapalha. Era só uma piadinha com um analista dando a entender que as especificações e documentação SÃO o sistema...

"Eu, como desenvolvedor, acho que é bem melhor pegar um código mal redigido e com NENHUM comentário sequer, quanto mais documentação, e bote nesse cenário que eu preciso usar esse código num sistema cujo deadline é daqui a 2 dias."

Eu entendi seu sarcasmo, mas acho mais importante me guiar por uma API bem definida e objetiva do que ter que ler toneladas de documentação antes de começar a botar a mão na massa para um deadline de 2 dias. Ter boa documentação, mas uma interface péssima, não vai te ajudar muito. Há aqueles que dizem que funções bem nomeadas e com parâmetros bem definidos, dispensam documentação extensa...

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

O furo básico da sua lógica é: Ruby é bom. Logo, Java é rui: Enquanto você não perceber que isso é uma falácia, qualquer outro argumento vai parecer cretino para você.

Por outro lado, qualquer argumentação sua será instantaneamente arrasada, como de fato vem sendo feito sistematicamente desde sua primeira mensagem lá em cima.

É um erro de lógica bem básico, por isso acredito que você, até por um dever de ofício, não terá dificuldades em corrigir.

na verdade...: ... java é ruim independente de ruby ser ou não bom. ;)

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

Excelente!: Dá até para pseudocodar isso:

if ( Ruby == bom || Ruby == ruim )
Java = ruim;


Esse código dá pra ser reduzido para

Java = ruim;

admitindo que as únicas possibilidades para as variáveis Ruby e Java sejam "bom" ou "ruim".

Bastava você ter dito, Java é ruim, e pronto. A comparação que você fez com Ruby, usando a boa, velha e absolutamente confiável lógica booleana, que é uma das mais básicas que existe, dispensaria todo o blablablá que você usou para "provar" algo que para você, no fim das contas, não passa de uma premissa. Uma premissa é um postulado, ou seja, uma "verdade" que deve ser aceita sem provas.

o propósito da comparação: Não foi mostrar que java é ruim: isso é óbvio. E o que acho mais engraçado é que algumas pessoas gostam tanto de seu martelinho surrado que levam críticas a uma _ferramenta_ como ofensas para o lado pessoal...

O propósito foi fazer um marketing rasteiro para uma linguagem poderosa e moderna, que poderia aliás, ser qualquer outra como Haskell, OCaml, Python...

Tenho certeza que após verem o rei nu, algumas pessoas ficaram com a pulga atrás da orelha e vão se entusiasmar para aprender alguma coisa nova que tenha passado completamente despercebida ante seus narizes simplesmente por falta de divulgação adequada. Não tem mercado pra ela?? Crie, oras...

Como dizia meu tio, vendedor esperto: "Mostrar não custa nada e pode render bastante."

Somos engenheiros e devíamos usar as ferramentas certas para a ocasião e sempre procurar por melhores. Essa é a essência do meu rant...

vc anda muito filosófico, Patola ( ou Ananias )... :)

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

Curso básico de vendas: O propósito foi fazer um marketing rasteiro para uma linguagem poderosa e moderna, que poderia aliás, ser qualquer outra como Haskell, OCaml, Python...

Isso ficou claro. Mas até aí tudo bem. Venda seu peixe, queremos ouvir.

Tenho certeza que após verem o rei nu,

Essa é uma técnica arriscada, porque Haskell, Ocaml, Python e Ruby também têm sua nudez, que pode ser igualmente exposta.

Não tem mercado pra ela?? Crie, oras...

Isso é verdade. Foi exatamente assim que o Java e o Linux se estabeleceram.

Como dizia meu tio, vendedor esperto: "Mostrar não custa nada e pode render bastante."

Verdade. Só que Ruby não ganhou nada quando você sentou a pua no Java. Se Java é sempre ruim, independente de Ruby ser boa ou não, então a ruindade do Java não ajuda a demonstrar que Ruby é boa, já que a qualidade do Ruby não é uma função da qualidade do Java.

Somos engenheiros e devíamos usar as ferramentas certas para a ocasião e sempre procurar por melhores. Essa é a essência do meu rant...

O problema é que sua análise é estreita.Qualquer engenheiro faria uma série de outras considerações que não só a verbosidade da língua para escolhê-la como padrão de projeto. Rantear também não ajuda a vender uma linguagem, qualquer vendedor sabe disso.

vc anda muito filosófico, Patola ( ou Ananias )... :)

Não estamos nos Jardim de Epicuro, isso eu posso garantir a você.

Eu?????: vc anda muito filosófico, Patola ( ou Ananias )... :)

Colé, nemesis? Tá me estranhando? Fui eu que escrevi isso não.

--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

isso está ficando ridículo...: ... nem temos mais espaço!

"Essa é uma técnica arriscada, porque Haskell, Ocaml, Python e Ruby também têm sua nudez..."

a diferença é que sua nudez parece a da Juliana Paes, enquanto Java é cheio de pelancas, rugas e pêlos... eca!! :)

"a ruindade do Java não ajuda a demonstrar que Ruby é boa, já que a qualidade do Ruby não é uma função da qualidade do Java."

Tive que por lado a lado pq o cara estava pedindo comparações, explicitamente. Tá bom, foi meio que uma surra gratuita, mas foi bom. :)

"Qualquer engenheiro faria uma série de outras considerações que não só a verbosidade da língua para escolhê-la como padrão de projeto."

Mas já é um bom começo: me desculpem as feias, mas beleza é fundamental, como diria o Vinícius. :)

"Não estamos nos Jardim de Epicuro, isso eu posso garantir a você."

ok, pra quem não entendeu, assim como eu:
Jardim de Epicuro



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

E qual é o problema de ter sido você?: Está com receio de expor as falácias por trás dos arghumentos nemesis? Logo você, Patola, meu grande inspirador no combate à trollagem sem noção?

:D:D:D:D: a diferença é que sua nudez parece a da Juliana Paes, enquanto Java é cheio de pelancas, rugas e pêlos... eca!! :)

Cuidado para não melecar seu código!

:D:D:D:D

a-há!: Ananias, vulgo Eu, sem dúvida. a bat-dupla... :))

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

Falácias?: Está com receio de expor as falácias por trás dos arghumentos nemesis?

Que falácias?

Gosto de muitos dos argumentos do nemesis, discordo de alguns. Acho que ele pega pesado quando fala do java e a "verbosidade" da linguagem tem seus motivos. Gosto de java e uso muita coisa feita nessa linguagem. Não tenho receio de Ruby, Python ou qualquer dessas linguagens que têm defensores agressivos (na verdade estou interessado em aprender OcaML).

Tenho muitas opiniões fortes sobre linguagens de programação também, o que não tenho é tempo pra expressá-las com suficiente clareza em um fórum como esse. Se já sou verboso normalmente, em um assunto como esse eu excederia o limite.

Logo você, Patola, meu grande inspirador no combate à trollagem sem noção?

É uma pena que me veja assim, mas de minha parte garanto que sou sincero ao expressar minhas opiniões, e o que é visto como inflamatório é decorrente de as pessoas não gostarem de ver suas convicções serem discutidas. Para um suposto "troll", acho que ofendo as pessoas menos do que muitos outros aqui. Por outro lado, acho que ofendo bastante as opiniões delas...
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Eu é que pergunto: que falácias?: Estamos testando os argumentos do nemesis exatamente para saber se contêm ou não falácias, se se sustentam ou não, e se contém falhas, onde elas estão e como corrigi-las.

É uma pena que me veja assim,

E como deveria vê-lo?

o que é visto como inflamatório é decorrente de as pessoas não gostarem de ver suas convicções serem discutidas.

Como você aparenta ter bastante senso crítico, imaginei que estivesse apreciando a discussão.

Claro que estou apreciando: Só não estou participando porque me tiraria muito tempo do meu já curto dia.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Agora que consegui parar de rir, deixa eu responder o resto: Tive que por lado a lado pq o cara estava pedindo comparações, explicitamente. Tá bom, foi meio que uma surra gratuita, mas foi bom. :)

Bom para quê? Você não vendeu Ruby nem Java. Como diria o Roberto Justus: você está demitido!

me desculpem as feias, mas beleza é fundamental, como diria o Vinícius. :)

É verdade. Mas como dizia Millôr: as feias sempre se casam.

obrigado: "Gosto de muitos dos argumentos do nemesis"

valeu pelo apoio! :)

São poucos os que discutem de forma razoável por aqui e claro que um anti-fudêncio como vc é um deles. :)

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

open-source nemesis: "Estamos testando os argumentos do nemesis exatamente para saber se contêm ou não falácias, se se sustentam ou não, e se contém falhas, onde elas estão e como corrigi-las."

Mandem bugzilla reports para namekuseijin at yahoo_com :)

fazendo um nemesis melhor...

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

bem...: "Você não vendeu Ruby nem Java"

claro que certamente consegui chamar atenção para um opção melhor.

as feias se casam e têm filhinhos feinhos. :P

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

Como não vencer o Java: claro que certamente consegui chamar atenção

Isso, sim.

para um opção melhor.

Na sua opinião.

Pode ser até que Ruby seja mesmo boa, e que valha a pena testá-la. Mas se você queria mostrar que vale a pena abandonar o Java, você falhou. Pelo contrário, até incitou defesas em favor dele. Você pode apelar em útlima instância dizendo que quem defende Java é boçal, mas isso é uma falácia e não dá em lugar nenhum.

Existem maneiras vencer o Java, mas certamente não é usando essa estratégia.

nemezilla: fazendo um nemesis melhor..

A idéia é essa.

como vencer: "Existem maneiras vencer o Java..."

como, por exemplo, _mostrando_ que existem ferramentas melhores? comparando código java com o de uma linguagem mais moderna e flexível?

ou que tal comparar a performance de uma solução java com a de uma outra?

não tenho como cobrir todas as opções em um fórum...

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

Veja de novo...: não tenho como cobrir todas as opções em um fórum...

E mesmo que cobrisse, a amostra que você deu aqui se verificou ineficaz.

Para cada tentativa de mostrar que existe algo superior ao Java, você provoca a reação de alguém defendendo-o. Como não existe saída desse beco, você invariavelmente vai desqualificar o argumento do denfensor, ou o próprio defensor, conferindo ainda mais pontos para o Java.

Bill Gates nos ensina que no mundo da tecnologia nem sempre é o melhor que vence. E quando o assunto é fazer vingar porcarias, Bill Gates é autoridade, por isso dou crédito total a ele. E o porquê você está vendo agora. Os defensores das tecnologias "superiores" usam a estratégia errada para vencer, e o que conseguem é só mais oposição à sua causa.

Minha missão aqui, que era ver se objeção que você levantou tinha consistência, e infelizmente não tem, está acabada.

Abraços e boa sorte da próxima vez.

exatamente: "Bill Gates nos ensina que no mundo da tecnologia nem sempre é o melhor que vence."

pois é, exatamente por isso java vai continuar com seu status quo em detrimento de melhores tecnologias, como ruby...

"Minha missão aqui, que era ver se objeção que você levantou tinha consistência, e infelizmente não tem, está acabada."

obrigado pelo esforço. vou aplicar os patches...

"Abraços e boa sorte da próxima vez."

sorte não existe...

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