Não fiquei muito feliz não...: Será que a RedHat de maneira similar vai criar o Enterprise Jboss?
Não gostei muito disso não!
Mas se ela começar a fazer isso certamente um novo branch do projeto será criado...

abs

Parabéns a RedHat, mostrando: Parabéns a RedHat, mostrando novamente que é uma empresa séria e que o Código Livre é uma mercado que dá certo!

não acredito: O AS JBoss, como produto, nunca foi realmente grande coisa no aspecto comercial.

Ele é sim, um AS J2EE construído com boa arquitetura, maleável, etc. Mas também é, comparável a seus concorrentes proprietários (ao menos da visão de cliente), complexo e dificil de configurar e usar.

O maior valor agregado que o JBoss oferece a grandes corporações é precisamente o suporte, a venda de soluções como serviço e o treinamento além do básico. Era como a empresa ganhava seus cobres.

Empacotar o JBoss em uma distribuição open-source comercial não deve dar bons resultados, principalmente com os seus concorrentes de código aberto (ObjectWeb Jonas e Apache Gerônimo e Sun Glassfish) alcançando tanta popularidade.

É mais provável que a Red Hat mantenha o modelo de negócio original do JBoss, porém usando-o para ampliar sua oferta de soluções corporativas. Seria a linha de ação mais correta, na minha opinião.

?: Empacotar o JBoss em uma distribuição open-source comercial não deve dar bons resultados, principalmente com os seus concorrentes de código aberto (ObjectWeb Jonas e Apache Gerônimo e Sun Glassfish) alcançando tanta popularidade.

Por que não deve dar bons resultados? Não acompanhei seu raciocínio. Se não houvesse os concorrentes de código aberto, deveria dar bons resultados ou eles são só mais um fator contra?

Java: Isso pode significar que a Red Hat vai investir mais ainda em Java?

Não, com esse investimento e: Não, com esse investimento ela mostrou que vai investir firmemente no Mono.

Cássio R. Es_kelsen

explicando...: O que eu quis dizer é que não dá bons resultados explorar o JBoss como produto (empacotando como produto de caixa, integrando com outras soluções e "vendendo" o serviço de distribuição), visto que há produtos de código aberto de qualidade semelhante.

A vantagem do JBoss é em relação ao suporte técnico e treinamento, que tem realmente qualidade acima da média e tem sido a principal linha de negócio do grupo JBoss. Disse que acreditava que essa linha deveria ser mantida.

Aparentemente, essa é a ideia da Red Hat também... O grupo JBoss continuará com certa independência dentro da empresa, na qualidade de sub-divisão, continuando as atividades que tem hoje e o CEO do pessoal continuará sendo o Marc Fleury (que responderá diretamente ao Matthew Szulik).

Então, nada muda para os usuários e clientes do grupo JBoss (ao menos por enquanto).

J2EE e Red Hat: No cenário atual ("black propaganda" microsoftiana à parte), a maior parte do investimento corporativo ainda aponta para o J2EE.

A Red Hat apenas está seguindo o mercado, mais nada.

"Tolerância Zero!" :-DDD : "Tolerância Zero!" :-DDD

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

Olha gente não se iludam. Ne: Olha gente não se iludam. Nenhuma empresa compra outra sem ter um potencial, sem ter um retorno. É ilusão pensar que o JBox não irá crescer bastante. Agora quanto ao comentário sobre o Java realmente é uma linguagem forte, no entanto apostaria para linguagens como Python, Zope e TCL/TK para o futuro promissor. Estas sim apostaria no futuro e não tanto o Java. Hoje é bem usado, mas até 1 ano atrás estas duas linguagens eram pouco usadas, hoje estão sendo mutio aprendidas por várias pessoas. Isso não é uma tendência de mercado boa?

O JBox tem uma fatia boa do mercado Norte-americano e não do brasileiro, por isso não a conhecemos muito. Se a Red Hat está comprando não é a toa, é porque está tendo um bom crescimento. Nunca uma empresa joga para perder, mesmo qeu aparente isso.





Filipe

técnico em eletrônica
Administrador júnior de sistemas Linux

Obrigado por deixar mais expl: Obrigado por deixar mais explícito o que eu queria dizer. ;)

O JBoss não está crescendo,: O JBoss não está crescendo, pois já é grande. O JBoss é muito usado no Brasil, e no mundo, por quem usa EJB, principalmente quando não se quer pagar algumas centenas de milhares de dólares pelo Weblogic.

Eu só apostaria em qualquer outra linguagem de programação que tivesse inovação suficiente, viesse acompanhada de uma IDE mais poderosa que as existentes hoje e com uma gama de bibliotecas, para todos os usos, como existe no Java hoje. Pode ser qualquer uma, Python, Ruby ou Lua, mas deve ter o que eu disse.
--
Alan Kelon Oliveira de Moraes - kelon.org

Só não sei pq você jogou L: Só não sei pq você jogou Lua no meio de Python, Ruby e Java...

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

Python, Zope e... TCL/TK?: no entanto apostaria para linguagens como Python, Zope e TCL/TK para o futuro promissor.

Tá maluco? Pra começar Zope não é uma linguagem, é um framework pra Python. E TCL/TK??? TCL/TK mesmo? Aquela que usa Motif/Lesstif? Cara, se liga, enquanto Ruby e Python são linguagens belas e cheias de recursos, TCL/TK - palavra de quem já programou muito nela - é MUITO ruim, moderadamente difícil de aprender, com sintaxe complicada e ainda bastante propensa a erros. Pra piorar, é lenta e limitada em recursos. é um milagre existirem softwares como o amsn, escritos nela. O futuro do tcl/tk é desaparecer, tanto que o próprio amsn está sendo reescrito em outra linguagem.

Esta merece entrar na história da BR-Linux: apostaria para linguagens como Python, Zope e TCL/TK para o futuro promissor

Afff, tem muita (mais muita mesmo) besteiras escritas aqui nos cometários da BR-Linux, mas esta merece entrar para a história.

T+

Concordo plenamente!: Realmente, Python é uma linguagem interessante, poderosa como Perl e elegante como Java e que possui uma possibilidade real de crescimento e adoção pelo mercado. Porém hoje, se você quer programação enterprise, ou vai para J2EE, ou vai para .NET. Goste ou não, a realidade é essa.
Infelizmente ainda existem pessoas que torcem para que java fracasse única e exclusivamente por não ser a sua linguagem de escolha. E ainda mais, a maioria que fala mal de java sequer foi além de um applet, nunca chegou a realizar nada real. Nem em Java e nem em outras linguagens.

Lua e Groovy: Não se deixe iludir pela simplicidade da linguagem Lua.

Como linguagem de script, ela é bastante poderosa, direta e conta com uma estrutura que permite fácil integração com linguagens mais estáticas.

Embora não seja tão difundida como seus pares, ela merece sim lugar no grupo.

A propósito: quem gosta de línguas de script com suporte a OO, continuações, closures e outros recursos, deveria dar uma olhada em Groovy. Ela tem vantagens concretas na integração com a plataforma Java.

Se inveja matasse, teria gent: Se inveja matasse, teria gente já em decomposição hahahah

Python e Java: Para quem gosta de Python e quer se envolver em programação Enterprise, pode saber que não precisa torcer que o Java fracasse para isso.

A JSR 223 introduz a API java.script, que permite a integração de línguas de scripting à plataforma Java, através de "motores" que processam os mesmos. A implementação da Sun do J2SE6.0 "Mustang" já introduz o conceito fornecendo a integração com Javascript (ECMA Script, pra quem quer um nome decente e não marketeiro), utilizando o Mozilla Rhino como motor.

Como se trata de uma API desacoplada em relação ao motor utilizado, ela pode servir para integrar virtualmente qualquer linguagem de script (beanshell, Lua, Python, Ruby, Groovy, Perl, etc.). Existe uma aposta na comunidade Java que confia que a implementação da IBM vai dar suporte nativo ao Python.

Mesmo que isso não aconteça, iniciativas paralelas podem fazer isso facilmente, como a equipe do Jython.

Em futuro próximo, vc. poderá ver páginas dinâmicas escritas com Python ou Groovy rodando em cima da plataforma J2EE, por exemplo (contando com as ricas bibliotecas do Java, compiladores JIT, etc).

E (ao menos eu espero) que seja o fim dessas briguinhas bobas.

não, obrigado: "Embora não seja tão difundida como seus pares"

Não é questão de difusão: Lua é apenas uma linguagem de script, feita para ser leve e um linguagem de extensão para aplicativos. Ela não está no mesmo nível de Perl/Python/Ruby, que se tornaram ambientes autônomos e autosuficientes, até pesadões... não que haja algo de errado com uma ou outra categoria...

"quem gosta de línguas de script com suporte a OO, continuações, closures e outros recursos ...Groovy. Ela tem vantagens concretas na integração com a plataforma Java."

Groovy usa a mesma sintaxe deprimente de java, é feita sob medida para programadores acomo, digo, habituados àquela linguagem. Há sempre jython, kawa (scheme) e, breve, jruby... embora eu não entenda pq uma pessoa gostaria de rodar programas nessas linguagens -- que rodam em *qualquer* plataforma -- em cima de ainda outra plataforma rodando sobre a plataforma nativa...

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

seja benvindo: Já está em decomposição, Nêmesis.

Lua é apenas uma linguagem de script, feita para ser leve e um linguagem de extensão para aplicativos.

É nisso que reside seu poder. Ser "apenas" uma linguagem de script, que serve de camada de controle e deixa o "trabalho pesado" ser feito por plataformas que têm esse escopo.

Groovy usa a mesma sintaxe deprimente de java, é feita sob medida para programadores acomo, digo, habituados àquela linguagem

Vá aprender Groovy antes de prestar declarações como essa. Groovy não tem a mesma sintaxe do Java (embora não se assemelhe à garatuja de algumas outras línguas cheias de sinais mnemônicos desnecessários) e implementa recursos que eu detestaria ver em Java, como a sobrecarga de operadores.

que rodam em *qualquer* plataforma -- em cima de ainda outra plataforma rodando sobre a plataforma nativa...

Sem outro flame por aqui. Só digo que, por razões "estranhas e misteriosas", conseguimos desempenho e produtividade superiores usando essas "redundâncias" multiplataforma: as plataformas com "mais desempenho" são menos produtivas e as plataformas "mais produtivas" têm desempenho sofrível. As que escapam dessa ciranda estão presas a uma única plataforma ou usam gambiarras não padronizadas para serem portadas.

Vc. usa linguagens nativas de baixo nível para dizer que Java é lento. Mas pra dizer que Java tem produtividade menor, compara-o à linguagens de script *interpretadas*... Faça-me o favor, Nemesis... Já tô cheio disso.

Enquanto vc. resmunga, Java está ganhando espaço. Continue resmungando, por favor.

em defesa...: "TCL/TK mesmo?"

qual é o problema?

"Aquela que usa Motif/Lesstif?"

Só no Linux: Tk precede a popularização dos toolkits GTK e QT. Na época, só tinha Motif e este acabou sendo a cara de Tcl/Tk nos *nix. No Windows e Mac, Tcl/Tk roda com a cara dos toolkits nativos. E ainda há projetos para se implementar temas...

"Ruby e Python são linguagens belas e cheias de recursos,"

ei, Tcl também tem lá sua beleza e recursos: é um cruzamento meio que bastardo de Lisp e shell scripting, com resultados bastante interessantes. :)

"TCL/TK é MUITO ruim,"

vindo de um programador Java, não me diz muita coisa, exceto que gosto é que nem c*: cada um tem o seu...

"moderadamente difícil de aprender,"

isso vindo de um programador java!...

não é não: a linguagem é tão simples que vc aprende em 11 passos em menos de meia hora! É realmente tudo o que vc precisa saber sobre a sintaxe, e a biblioteca padrão também é relativamente pequena, mas poderosa!

"com sintaxe complicada e ainda bastante propensa a erros."

só um programador java pra encontrar complexidade na simplicidade... :P

"Pra piorar, é lenta e limitada em recursos."

Tcl/Tk continua firme aos princípios de uma linguagem de script, bem mais que seus pares atuais: uma ferramenta de automação de recursos nativos. Para o que se presta, é uma excelente pedida e os recursos providos, como event loops para IO, são coisa de outro mundo em termos de simplicidade e elegância!

"é um milagre existirem softwares como o amsn, escritos nela."

não é tão milagre quanto a quantidade de software escrito em linguagens medonhas e de baixo nível como assembly, C ou Java... :P

"palavra de quem já programou muito nela "

é, como disse, *programou*. Seus conceitos estão bem defasados...

Eu sugiro que dê um download na excelente distribuição Tcl/Tk da ActiveState e brinque um pouco.

"O futuro do tcl/tk é desaparecer"

Isso me lembra do futuro de COBOL. Ou Lisp. Ou Perl. e eventualmente, de Java... que não é desaparecer, mas apenas se tornar o horror dos manutenedores futuros, acostumados com as últimas bobagens "fáceis de usar" da M$...

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

heh: "Ser 'apenas' uma linguagem de script, que serve de camada de controle e deixa o 'trabalho pesado' ser feito por plataformas que têm esse escopo."

Essa é a típica resposta de um programador de linguagens estaticamente tipadas, que se convence que a importância da performance da máquina é maior que a performance do programador e que tempo de execução é mais importante que prazos de entrega. É um argumento tão antigo quanto Lisp e Fortran e frequentemente debatidos por proponentes dos descendentes de ambos desde então. Não vou nem me prestar a tanto...

Se te alegra, no entanto, saiba que a maioria das bibliotecas para python e similares são thin-wrappers para bibliotecas nativas. Ou seja, no fim das contas, essas linguagens continuam se prestando a scripting, apenas que para uma plataforma portável na forma de coleções de bibliotecas escritas em C...

"Groovy não tem a mesma sintaxe do Java"

hmm, ok. Critiquei tanto o Patola que acabei incorrendo no mesmo erro. Não me lembro se era groovy ou outra linguagem, mas me lembro de uma que eu poderia descrever apenas como java sem declarações de tipo.

Parece um cruzamento de ruby com haskell. Nesse caso, é interessante, ao menos para quem quer rodar em java...

"implementa recursos que eu detestaria ver em Java, como a sobrecarga de operadores."

programadores java são notoriamente anti-criatividade e flexibilidade...

"Vc. usa linguagens nativas de baixo nível para dizer que Java é lento. Mas pra dizer que Java tem produtividade menor, compara-o à linguagens de script *interpretadas*"

vide o primeiro parágrafo...

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

Encontrando o baixo nível de Java...: linguagens medonhas e de baixo nível como assembly, C ou Java... :P

Java é linguagem de baixo nível (mais próxima da máquina do que do programador)? Nêmesis, toma seu remédio e vai dormir um pouco.

Se não resolver, atenda aos conselhos da galera e dá um pulo no Mobral.

não é não: a linguagem é tão simples que vc aprende em 11 passos em menos de meia hora!

Vc. aprende COBOL em menos tempo ainda, afinal os conceitos são simples e os comandos são poucos. Mas depois, vai escrever um programa com ele...

Quanto mais tacanha uma linguagem, mais complicado é escrever programas com ela.

e eventualmente, de Java

Perca suas esperanças, meu caro :)

Inveja do que, guri? : Inveja do que, guri?

Estou falando que é OBVIO que a RH vai investir em Java. Meu, nada a contra nem a favor. Só tirei um sarrinho da pergunta com resposta óbvia do colega acima.

Cássio R. Es_kelsen

Re: Heh: que se convence que a importância da performance da máquina é maior que a performance do programador e que tempo de execução é mais importante que prazos de entrega

Meio termo, rapaz... O conceito é tão difícil assim? Um sistema rápido que é um pesadelo de manutenção ou um sistema feito de forma tacanha, mas que não atende aos requesitos de performance: ambos estão errados.

Vc. é meio difífil de entender. Gosta do C++ pq é rápido. Gosta do Python pq é "fácil". Não gosta do Java, que é mais rápido do que Python e mais fácil do que C++. Ah, Nêmesis == "Do Contra", certo? Entendi...

Se te alegra, no entanto, saiba que a maioria das bibliotecas para python e similares são thin-wrappers para bibliotecas nativas

E, com isso, presas a plataformas nativas ou dependentes de portes específicos, não-padronizados e de qualidade variável, para cada plataforma. O cobertor é curto: descobriu os pés para cobrir a cabeça.

mas me lembro de uma que eu poderia descrever apenas como java sem declarações de tipo

Vc. está falando de Beanshell, que *não é uma outra linguagem*, nem é propagada como tal. É o mesmo bom e velho java, só que escrito como script. Antes de dizer seu "não, obrigado" característico, pesquise... :P

ao menos para quem quer rodar em java

Nada impediria de usar o Groovy em outras plataformas... Mas o atual interpretador do Groovy tem a vantagem de fazer interface transparente com classes java (do seu projeto ou da API) e usar outros recursos da plataforma (como a compilação Just in Time, por exemplo).

programadores java são notoriamente anti-criatividade e flexibilidade...

Programadores java são notóriamente avessos à pesadelos de manutenção e insanidades em geral. É por isso que temos sucesso no mundo corporativo, onde a "criatividade" (que pode se provar uma boa idéia de jerico mais tarde) usada sem critério pode custar muito dinheiro.

vide o primeiro parágrafo...

Vide a primeira resposta.

acho que não foi com você: Tenho a impressão de que ele não estava se referindo à você, diretamente...

Como era mesmo a campanha?: "programadores java são notoriamente anti-criatividade e flexibilidade..."

ah! Não alimente os trolls!
E esse aí é bem grandão!

pelo contrário: "Um sistema rápido que é um pesadelo de manutenção ou um sistema feito de forma tacanha, mas que não atende aos requesitos de performance"

Quem disse que uma aplicação python, ruby ou empregando linguagens de mais alto nível são "pesadelo de manutenção" ou "sistema feito de forma tacanha"? Muito pelo contrário, a simplicidade, expressividade e clareza que essas linguagens oferecem provavelmente vai tornar a tarefa de manutenção bem mais tranquila, contanto que vc conheça a linguagem, claro, e alguns dos idiomas comuns mais empregados...

"Gosta do C++ pq é rápido. Gosta do Python pq é 'fácil'."

Eu não gosto de C++, eu gosto de C, que é mais simples e ligeiramente mais rápida que C++.

"Não gosta do Java, que é mais rápido do que Python e mais fácil do que C++."

Mas deveria ser mais rápido do que C++ e mais fácil do que Python! Vc está comparando com as fraquezas, ora bolas!...

"E, com isso, presas a plataformas nativas ou dependentes de portes específicos, não-padronizados e de qualidade variável, para cada plataforma."

Não, por nativa, eu quis dizer que rodam nativamente, não que sejam desta ou daquela plataforma em particular. Essas bibliotecas são completamente self-contained: foram criadas para a biblioteca da linguagem mesmo. Apenas eventualmente uma ou outra biblioteca externa ao projeto, se pequena ou útil o suficiente, é "embrulhada" para a linguagem...

"É por isso que temos sucesso no mundo corporativo..."

Sucesso em um ambiente ascéptico, rígido e padronizado. Mais uma vez comparando à Matrix: vcs são os Smiths, repetitivos, sistemáticos e redundantes, causando uma infecção viral ampla e problemática. Aqueles que os combatem são esfarrapados, mas corajosos, lutando contra a hegemonia controladora e precisam contar com soluções criativas contra a pura força-bruta de suas soluções... :)

Java não encontra muito espaço em pesquisa avançada em vários campos, como I.A., computação gráfica, simulações físicas e coisa e tal. Nessas áreas, criatividade e flexibilidade são mais importantes do que agradar à gerentes de software ou estar de acordo com regras e padrões de mercado...

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

em defesa...: "linguagens medonhas e de baixo nível como assembly, C ou Java... :P"

Excelente piada.

PuccA

Defendendo o TCL?: É, às vezes eu fico achando que você gosta mesmo é de provocar briga. =P

Só no Linux: Tk precede a popularização dos toolkits GTK e QT. Na época, só tinha Motif e este acabou sendo a cara de Tcl/Tk nos *nix. No Windows e Mac, Tcl/Tk roda com a cara dos toolkits nativos. E ainda há projetos para se implementar temas...

Não importa, a decisão de amarrá-la ao motif/lesstif no Unix e no GNU/Linux ficou. Agora ou esperamos o porte pra GTK ou QT, ou nos contentamos com essa relíquia.

ei, Tcl também tem lá sua beleza e recursos: é um cruzamento meio que bastardo de Lisp e shell scripting, com resultados bastante interessantes. :)

LISP? Só por causa do lappend e das listas? Tá viajando? tcl não tem nada de paradigma funcional, é procedural pura.

"moderadamente difícil de aprender,"

isso vindo de um programador java!...

não é não: a linguagem é tão simples que vc aprende em 11 passos em menos de meia hora! É realmente tudo o que vc precisa saber sobre a sintaxe, e a biblioteca padrão também é relativamente pequena, mas poderosa!

Releia de novo os 11 passos! Compare com os passos das suas linguagens prediletas - ruby, python ou até C. A sintaxe do TCL é insana! Na prática, o excesso de regras dela, aliado ao jeito com que ela trata strings, fazer você nunca saber de verdade se precisa usar aspas ou não, se precisa "quotar" um texto ou não, se na hora de executar um comando com a dada string, partes com [] ou $ serão executadas ou não.

Acrescente agora a "sintaxe extra" do TK, com os malditos pontos começando as coisas. Embola mais ainda, na prática, ao programar. Isso causa erros. Já li uma introdução a ruby que falava algo como "o legal do ruby é que voce faz a coisa e simplesmente funciona da primeira vez". Sabe o "legal" do tcl? Ë que você faz um programa, revista ele e põe pra rodar e mesmo quando tem apenas 60 linhas, SEMPRE tem um errinho. Seja algo na sintaxe, seja algo cujo índice era 1 e você trocou por zero, seja um comando que deixa um espaço a mais na string, seja um outro comando que interpretou algo que você colocou dentro de uma string.

Me chame de incompetente, mas programo em tcl/tk desde que a aprendi na faculdade em 1995 e ainda uso tcl de vez em quando pra fazer scripts pros meus bots. Diferente de outras linguagens que uso, como C++, Java, perl e shell, TCL SEMPRE me decepciona. Como eu gostaria que eggdrops tivessem bindings pra outra linguagem script... Mas estou preso pelo legado, exatamente como o tcl/tk com o motif/lesstif.

Talvez você devesse ver mais os defeitos da linguagem tcl, nemesis, nessa histórica discussão entre o Richard Stallman e John Ousterhoust, o inventor da linguagem. É tão divertida quanto a discussão Linus x Tanenbaum.

Isso me lembra do futuro de COBOL. Ou Lisp. Ou Perl. e eventualmente, de Java... que não é desaparecer, mas apenas se tornar o horror dos manutenedores futuros, acostumados com as últimas bobagens "fáceis de usar" da M$...

Curiosidade, COBOL você admite que é ruim? Admite PELO MENOS que é pior que Java?
--
Dicionário rápido para o br-linux:

• É exceção e não excessão.
• É licença e não licensa.

ponha seus pêlos na direção certa...:
Um sistema rápido que é um pesadelo de manutenção...


"Quem disse que uma aplicação python, ruby ou empregando linguagens de mais alto nível são "pesadelo de manutenção"

Eu estava me referindo ao C++ mal empregado... Python e Ruby estão no grupo de linguagens de "alta produtividade, baixa performance". :)

Eu não gosto de C++, eu gosto de C, que é mais simples e ligeiramente mais rápida que C++.

Concordo que é simples e mais rápido, mas a produtividade do C (até mesmo comparado ao C++) para a maior parte das aplicações que não sejam drivers de dispositivo ou similares, é ínfima. E não é você o cara que adora produtividade?

Mas deveria ser mais rápido do que C++ e mais fácil do que Python! Vc está comparando com as fraquezas, ora bolas!...

E vc. também está comparando as fraquezas, sempre esteve. Isso significa que pra você parar de trollar o Java, ele precisa ser mais produtivo que a mais fácil linguagem de script e mais rápido que a mais rápida linguagem nativa compilável? Faça-me o favor!

Java representa "o caminho do meio". Não é tão purista quanto Smalltalk, mas é comprometido com as práticas corretas de OO. Não é tão rápido quanto C++, mas é mais produtivo. Pode não ser tão produtivo quanto um "Ruby on Rails" da vida, mas é mais rápido.

Não, por nativa, eu quis dizer que rodam nativamente, não que sejam desta ou daquela plataforma em particular.

Se aproveitar um recurso sequer do processador ou alguma chamada específica do sistema operacional, já não é automaticamente portável. Com a vivência de quem já trabalhou com C++, é quase impossível uma biblioteca C que não dependa de algum arquivo de cabeçalho específico para um SO. Então, não acredito nessa coisa de "100% self-contained". Só acredito vendo.

Sucesso em um ambiente ascéptico, rígido e padronizado. Mais uma vez comparando à Matrix: vcs são os Smiths, repetitivos, sistemáticos e redundantes, causando uma infecção viral ampla e problemática. Aqueles que os combatem são esfarrapados, mas corajosos, lutando contra a hegemonia controladora e precisam contar com soluções criativas contra a pura força-bruta de suas soluções... :)

Essa merece citação. É a garantia de que vc. precisa tomar seu remédio, rapaz. Vc. tá fora do mundo real hoje. Repita comigo: Eu *não sou* o Smith, vc. *não é* o Neo e, acima de tudo, vc. *não deve* metralhar as pessoas no cinema, elas *não são* programas desgarrados.

Java não encontra muito espaço em pesquisa avançada em vários campos, como I.A., computação gráfica, simulações físicas e coisa e tal.

É mesmo?

Só alguns pequenos exemplos, todos de código aberto:

I.A. (gosto muito dessa área e estou sempre pesquisando):

Algoritmos Genéticos: http://jgap.sourceforge.net/

Sistemas Especialistas: http://drools.codehaus.org/
(melhor do que o JESS, que trabalha com CLIPS).

Redes Neurais: http://www.jooneworld.com/

Computação Gráfica:

Muitos projetos no www.java.net, onde vc. pode encontrar comunidades inteiras. Mas para ter uma base vc. deve começar por:

http://java.sun.com/products/java-media/3D/

http://java.sun.com/products/java-media/2D/index.jsp

Depois, encontre seu brinquedo preferido em:

https://media.dev.java.net/

Simulações Físicas:

É um campo amplo, mas acho que o JSci pode representá-lo bem:

http://jsci.sourceforge.net/

Tenho acompanhado os estudos do pessoal da Unidev, dá uma olhada:

http://www.unidev.com.br/forum/topic.asp?TOPIC_ID=5848

Nessas áreas, criatividade e flexibilidade são mais importantes do que agradar à gerentes de software ou estar de acordo com regras e padrões de mercado...

Sim, e Java está nelas também... :)

chefe: "que seja o fim dessas briguinhas bobas"

Não vai ser o fim. Não é pq vc pode rodar python na *plataforma java* que vc vai poder escrever seu aplicativo em python, pela mesma razão pela qual vc não pode escrevê-lo em python para a *plataforma nativa*: pq seu chefe quer que vc use uma linguagem *mainstream*, propositadamente limitada para seguir padrões e facilitar interações entre os operá, digo, desenvolvedores...

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

baixo: "Java é linguagem de baixo nível (mais próxima da máquina do que do programador)?"

Sim, evolução direta de C++. Removeu os ponteiros e trouxe gerência automática de memória, mas como linguagem fortemente imperativa que é, com todas as amarras para botar programadores nos trilhos e toda a tralha de declarações e minúcias para satisfazer o compilador, é definitivamente baixo nível.

Linguagens de alto nível permitem ao programador focar no que deve ser feito, não em como fazê-lo ou em ficar lutando com o compilador...

"aprende COBOL em menos tempo ainda, afinal os conceitos são simples e os comandos são poucos."

essa é boa!... só falta a flexibilidade ao COBOL...

"Quanto mais tacanha uma linguagem, mais complicado é escrever programas com ela."

por isso sou contra java... :P

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

Chute na cara sem dó nem piedade: Essa merece citação. É a garantia de que vc. precisa tomar seu remédio, rapaz. Vc. tá fora do mundo real hoje. Repita comigo: Eu *não sou* o Smith, vc. *não é* o Neo e, acima de tudo, vc. *não deve* metralhar as pessoas no cinema, elas *não são* programas desgarrados.

Desculpa, mas quando eu li essa passagem eu tive que parar pra rir sozinho por mais de um minuto. Essa fica pra história.
--
Dicionário rápido para o br-linux:

• É exceção e não excessão.
• É licença e não licensa.

sim, pq não?: "É, às vezes eu fico achando que você gosta mesmo é de provocar briga."

será por causa do meu login? ;)

"Não importa, a decisão de amarrá-la ao motif/lesstif no Unix e no GNU/Linux ficou."

amarrar Tk a GTK ou QT é piada, né? Pra que uma dependência desse tamanho em uma solução GUI que foi feita para ser simples, leve e scriptável?... Ademais, vc mesmo pode com pouco esforço dar um tweak nos widgets tk para ficarem com o visual que vc quiser.

"Só por causa do lappend e das listas? Tá viajando? tcl não tem nada de paradigma funcional, é procedural pura."

o fato de ambas adotarem a sintaxe prefixada? O fato de que há um foco definitivo em avaliação de expressões? Não completamente procedural...

"Compare com os passos das suas linguagens prediletas - ruby, python ou até C. A sintaxe do TCL é insana!"

Vc está delirando. Python, simples como parecia ser está cheia de centenas de regras loucas ultimamente descritas em vários PEPs, os quais preciso de um pepsamar para digerir, como descritores, geradores, decoradores e coisa e tal. Cada qual, quase sempre, requerindo sua própria sintaxe. Daqui a pouco python vai chegar no nível de Perl em termos de variedade de sintaxe. Fora as dezenas de atributos especiais denotados por __foobar__...

Ruby diferencia de forma sutil e não muito coerente entre blocos begin/end e {/}. Cada objeto básico de ruby tem dezenas de métodos, bem mais do que python, o que torna o aprendizado confuso...

As regras em tcl são simples: tudo são comandos, como comandos de shell. Vc avalia comandos e passa seus argumentos dentro de [], o que invoca recursivamente o interpretador. Vc acessa o valor de variáveis com $, como $foo, inclusive dentro de strings. E, por fim, vc previne a avaliação de argumentos ou comandos, "quotando-os", seja com aspas ou {}. Eis as regras de tcl, em suma. O que tem de complicado ou excessivo?

O problema aqui é muito comum em linguagens imperativas e afeta menos linguagens com um certo caráter funcional: para vc ter mais recursos na linguagem, vc cria nova sintaxe! O que significa que eventualmente sua linguagem vai ser tão barroca quanto C++, Perl ou Java... ao menos perl usa disso para permitir flexibilidade incomparável...

Já em linguagens funcionais, tudo são funções! Praticamente não há sintaxe ou problemas na interpretação e entendimento da sintaxe. Basta conhecer as funções que vc vai usar e cair de pau...

"jeito com que ela trata strings, fazer você nunca saber de verdade se precisa usar aspas ou não, se precisa 'quotar' um texto ou não, se na hora de executar um comando..."

o seu problema com Tcl, ao que parece, é que vc não pegou o espírito da coisa: *tudo* em Tcl são strings, grosso modo. Sabendo disso, tudo se torna mais claro e previsível. Por padrão, as strings são "unquoted" e, portanto, avaliadas e interpoladas. Se quer prevenir isso, passe entre {}...

"Acrescente agora a 'sintaxe extra' do TK, com os malditos pontos começando as coisas."

A única sintaxe extra. E bastante útil, pois indica a hierarquia de widgets tk: .frmTop.edtNome etc...

"Isso causa erros."

deixa eu adivinhar: vc ficou tão fulo com tcl por não entender o espírito da coisa, que passou a desprezar linguagens de script e se voltou para java, uma camisa-de-força que torna absolutamente impossível causar erros de compilação, certo?

"você faz um programa, revista ele e põe pra rodar e mesmo quando tem apenas 60 linhas, SEMPRE tem um errinho."

Mas 60 linhas em tcl deve ser o equivalente a umas 300 em java sem as toneladas de declarações pro compilador. Então, há bastante coisa sendo feita ali. Do que vc está reclamando?...

"Seja algo na sintaxe, seja algo cujo índice era 1 e você trocou por zero, seja um comando que deixa um espaço a mais na string, seja um outro comando que interpretou algo que você colocou dentro de uma string."

erros de sintaxe ocorrem em qualquer linguagem. Em linguagens compiladas o compilador avisa. Em linguagens interpretadas, o interpretador avisa. Se vc testa seu código incessantemente, não deveria haver problemas.

"Me chame de incompetente, mas programo em tcl/tk desde que a aprendi na faculdade em 1995"

não é incompetência, é apenas programar com uma mentalidade diferente... sabe quando seus professores de inglês te ensinam a "pensar" na linguagem, ao invés de pensar em português para então traduzir?...

"perl e shell, TCL SEMPRE me decepciona."

isso é estranho, já que o shell tem sintaxe bem mais bisonha que TCL, um bocado mais clean e bem pensada...

"nessa histórica discussão entre o Richard Stallman e John Ousterhoust, o inventor da linguagem."

E pq vc acha que eu nunca li? O Stallman é pró-Lisp e, se dependesse dele, o sistema GNU seria todo scriptado em Lisp, sem sombra de perl ou python.

"COBOL você admite que é ruim? Admite PELO MENOS que é pior que Java?"

dizem as más linguas que java é o COBOL moderno. :)

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

Frustrações: Não.

Vc. não pode escrever seu programa para sua plataforma predileta, no seu SO predileto, na sua linguagem predileta, sem integrar com nada e nem pensar em mais ninguém.

Pq existem mais pessoas no mundo além de você. Elas têem opiniões diferentes das suas e fazem outros sistemas além do seu.

Isso te frustra, não é? Sinto muito.

Saiba também que o maior sinal da incompetência de alguém é quando essa pessoa começa a falar que todo mundo é incompetente. Eu confio na sua capacidade, vc. é um cara inteligente (a maioria das vezes). Não incorra nesse tipo de erro, por favor.

Creio que vc. quis dizer "Eu não vou parar de brigar". Tudo bem,
se você prefere seu mundo "perfeito" (perfeito só pra você), tem o direito de sonhar que está vivendo nele.

Afinal, alguns soldados japoneses continuaram brigando muito tempo depois que a segunda guerra acabou. Mas isso não afetou muito a cara do nosso século. Graças a Deus...

Toma logo o remédio, vai?: é definitivamente baixo nível

Tão de baixo nível que vc. não tem acesso a nenhum recurso da máquina física... Arre! Vc. está piorando com o tempo.

ou em ficar lutando com o compilador

Ei, essa briga é só sua. Toda língua tem regras. Se vc. não conhece ou obedece as regras, o compilador briga com você. Ou deixa seus erros vazarem e estourarem em execução.

por isso sou contra java... :P

Vc. me confunde... Tacanho == Simplório. O que é "complexo" não pode ser "tacanho", certo?

pílula vermelha: "É a garantia de que vc. precisa tomar seu remédio, rapaz."

Eu já tomei minha pílula vermelha. ;)

"vc. *não deve* metralhar as pessoas no cinema, elas *não são* programas desgarrados."

essa foi ótima!! :P

"Um sistema rápido que é um pesadelo de manutenção...

Eu estava me referindo ao C++ mal empregado..."

agora vc diz isso! mas passou a impressão que sistema rápido é sistema desenvolvido rapidamente com uma linguagem de script rápida e suja...

"E não é você o cara que adora produtividade?"

não, esse deve ser outro. eu sou o cara que adora simplicidade, flexibilidade e expressividade...

"E vc. também está comparando as fraquezas, sempre esteve."

fair enough... :)

"Se aproveitar um recurso sequer do processador ou alguma chamada específica do sistema operacional, já não é automaticamente portável."

Claro! Por isso a maioria dessas bibliotecas lidam com IO de/para arquivos. O mínimo e faz o trabalho necessário.

"Sim, e Java está nelas também... :)"

não poderia deixar de estar, já que está em tudo quanto é parte. Não que as soluções em java se equiparem às soluções mais avançadas nessas áreas...

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

cruzes: Nem vou tecer muitos comentários técnicos para algumas sandices ditas aqui, o Patola pode fazer isso se tiver paciência com você.

Mas...

dizem as más linguas que java é o COBOL moderno. :)

De todas as bobagens que vc. já disse por aqui, essa foi a pior delas. *Que* más linguas? Posta o link...

rs*** Ok, "Neo": Eu já tomei minha pílula vermelha. ;)

Cuidado. Pode ser veneno. :-O

Vou avisar pra sua mãe que ela tem trancar o armário do banheiro... Toma um copo de leite e procura o médico mais próximo.

mas passou a impressão que sistema rápido é sistema desenvolvido rapidamente com uma linguagem de script rápida e suja...

Rápido em tempo de exexução, criatura (coisa que um script interpretado nunca é)... Quer que eu desenhe?

não, esse deve ser outro. eu sou o cara que adora simplicidade, flexibilidade e expressividade...

Há quem diga que essas coisas são sinônimos de produtividade, e eu acredito neles...

Claro! Por isso a maioria dessas bibliotecas lidam com IO de/para arquivos. O mínimo e faz o trabalho necessário.

O que significa: Não é portável. O "cobertor curto" continua curto.

não poderia deixar de estar, já que está em tudo quanto é parte.

Dá pra notar um certo desespero de sua parte nessas bem escritas linhas?

Não que as soluções em java se equiparem às soluções mais avançadas nessas áreas...

Sai da frente do DVD-Player passando Matrix, acorda pra realidade, estuda mais, e vai aprender que é justamente o contrário... ;-)

Memórias Póstumas: por isso sou contra java... :P

Deus te livre de uma idéia fixa; antes um argueiro, antes uma trave no olho. Vê o Cavour; foi a idéia fixa da unidade italiana que o matou. Viva pois a história, a volúvel história que dá para tudo.

Java is the new Cobol: Uma busca no Google com a frase do título revela 7.440.000 links.

Java é um grande mercado. E obviamente há muita gente interessada em tomar conta dele, especialmente a Microsoft. Por isso propalam aos quatro ventos tais afirmações para as quais eles dão uma conotação negativa.

A verdade é que, enquanto Java dominar o mercado de linguagens de programação, os incompetententes vão ficar chiando. Estão no papel deles. É só o que saberão fazer.

nossa!: Nossa, como tem trolls no mundo!

Mas eu cheguei a dar uma olhada nos resultados (obrigado pelos links, Urso).

Me pareceu que as comparações são principalmente filosóficas (comparando a extensão e adoção da plataforma Java em comparação com a base COBOL no passado). Não é realmente uma comparação técnica entre as duas linguagens.

A comparação dos AS com mainframes também achei meio forçada.

A verdade é que, enquanto Java dominar o mercado de linguagens de programação, os incompetententes vão ficar chiando. Estão no papel deles. É só o que saberão fazer.

É... Infelizmente :,-(

Bem...: Isso está uns 30% certo...

A linguagem Assembly é realmente de baixo nível, está o mais perto possível do hardware.

O C está no meio termo entre baixo e alto nível.

Agora: Nenhuma dessas linguagens é "medonha". E Java é obviamente uma linguagem de alto nível de abstração.

Ou seja: 30% certo e 70% errado. Como eu não sou um otimista (que consideraria cheio um copo com um resto de água), concordo:

Excelente piada.

funny guy!: "Vou avisar pra sua mãe que ela tem trancar o armário do banheiro..."

lições de Sun Tzu: desestabilizar o oponente, insultando-o e desmerecendo sua pessoa... :)

"Rápido em tempo de exexução, criatura ... Quer que eu desenhe?"

sim, nunca ouvi falar em exexução...

"coisa que um script interpretado nunca é"

Nenhuma ferramenta de scripting moderna é puramente interpretada, como os velhos interpretadores Basic linha-a-linha. Todas elas são convertidas para algum formato binário pelo parser -- sejam ASTs ou bytecode -- e aí são executadas. Esse formato interno pode ser salvo em disco e na próxima são carregados diretamente, ao invés do fonte.

A partir desse momento, a execução é similar a java, exceto pela falta de um compilador JIT em tempo de execução e pelo sistema de tipos dinâmico -- a real causa da flexibilidade e performance menor...

"não, esse deve ser outro. eu sou o cara que adora simplicidade, flexibilidade e expressividade...

Há quem diga que essas coisas são sinônimos de produtividade, e eu acredito neles..."

então, pq usa java?

"O que significa: Não é portável."

vc cheirou alguma coisa? IO puro com arquivos é a coisa mais portável que existe!

"Dá pra notar um certo desespero de sua parte nessas bem escritas linhas?"

é claro que estou desesperado e sufocado, tendo que usar essas ferramentas medíocres no trabalho e vendo elas serem adotadas por legiões sem conta como se fosse a melhor coisa desde pão francês!

"Não que as soluções em java se equiparem às soluções mais avançadas nessas áreas...

Sai da frente do DVD-Player passando Matrix, acorda pra realidade, estuda mais, e vai aprender que é justamente o contrário... ;-)"

é? eu não acho que o Renderman da Pixar, o renderizador 3D padrão na indústria cinematográfica, seja escrito em Java. Pensando bem, também estou certo de que Oracle, Windows e mesmo IDEs como Delphi ou VisualStudio não são programados em linguagens dependentes de runtime, como java.

Minha rinha com java é que é uma linguagem de baixo nível, verbosa e inflexível que tenta passar a idéia de que é mais alto-nível que C++ e com performance melhor que Python. Problema é: qualquer coisa é mais alto-nível que C++ e qualquer coisa tem performance melhor que Python!

As pessoas não usam essas linguagens por causa de seus pontos fracos, mas o pessoal de java se orgulha de sua ferramenta cujo propósito é ser medíocre ao se limitar a ser melhor que os concorrentes em seus pontos fracos...

além de que tem gente usando o marretão java pra tudo, fazendo de tudo , prego...

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

do jeito que vc fala...: "enquanto Java dominar o mercado de linguagens de programação, os incompetententes vão ficar chiando"

...dá a impressão de que ser competente é suportar numa boa a insanidade de escrever umas 10 linhas de declarações para cada linha efetivo algoritmo... fora integração com configurações em xml...

é, faz sentido, o cara tem que ralar pra ter mérito, né? Nesse caso, que tal voltarmos pra assembly, hein?

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

simples: Pq não são sandices e vc ou não conhece para argumentar ou simplesmente não tem como contra-argumentar...

As más linguas, na verdade, são boas línguas. E não são uma legião de trolls incompetentes, mas, assim como eu, frustrados com uma ferramenta genuinamente limitada e medíocre que é padrão na indústria...

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

incompetência: "Vc. não pode escrever seu programa para sua plataforma predileta, no seu SO predileto, na sua linguagem predileta"

é? então, pq sugeriu isso com:

"Em futuro próximo, vc. poderá ver páginas dinâmicas escritas com Python ou Groovy rodando em cima da plataforma J2EE, por exemplo (contando com as ricas bibliotecas do Java, compiladores JIT"

querendo vender o peixe de que java como plataforma é uma boa, quando na realidade o cara vai ter é que programar em java, mesmo, né? :P

"o maior sinal da incompetência de alguém é quando essa pessoa começa a falar que todo mundo é incompetente"

eu não acho que todo mundo é incompetente, só programadores M$. :)

programadores java obviamente não são incompetentes: são muito esforçados e ignorantes de que existe coisa melhor lá fora... :)

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

Learn to live with it!: frustrados com uma ferramenta genuinamente limitada e medíocre

Na opinião deles.

que é padrão na indústria...

Isso é uma verdade.

O segredo para não se frustrar é entender que para qualquer indústria, qualquer mesmo, sua opinião individual vale precisa e absolutamente shit, nada, niente, nihil, nichts, zenzen, xuá, zero, null. A não ser que você seja capitalista de uma delas.

Agora vai dormir. Amanhã acorde disposto, abra um editor de textos, digite import e sorria.

porém: "sua opinião individual"

como vc deve ter percebido pela pesquisa do Google, minha opinião individual é partilhada por muitos outros indivíduos...

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

Não estou pra ser engraçado hoje: lições de Sun Tzu: desestabilizar o oponente, insultando-o e desmerecendo sua pessoa... :)

Sério? Onde vc. viu isso? Eu tenho "The Art of War" (é um dos meus livros de cabeceira) e não encontrei esse conselho em particular em lugar nenhum... Tem certeza de isso é Sun-Tzu?

Sério, eu tenho uma preocupação legítima com você. Esse tipo de declaração que vc. faz, e sua insistência em agir como troll as vezes, não faz bem pra sua imagem.

Finalmente, vc. não é um "oponente". É só um colega de portal resmungando...

Nenhuma ferramenta de scripting moderna é puramente interpretada, como os velhos interpretadores Basic linha-a-linha. Todas elas são convertidas para algum formato binário pelo parser -- sejam ASTs ...

O processo de parsing e construção de árvore sintática, com ou sem autômatos finitos (determinísticos ou não), e sua posterior interpretação não é de forma alguma novo, já existe a bastante tempo e não é "moderno". E esse processo continua sendo mais lento do que a execução de bytecode em VM e ainda mais lento que a execução de código nativo.

São poucas as linguagens de script dinâmicas que conheço que pré-compilam para alguma forma de bytecode. A maioria não faz isso.

então, pq usa java?

Por que a plataforma Java alcança o equilíbrio certo entre produtividade, portabilidade e performance.

vc cheirou alguma coisa?

Não preciso dessas coisas, gosto de viver no mundo real.

IO puro com arquivos é a coisa mais portável que existe!

Agora fui eu que não entendi. Para fazer IO com cada sistema operacional, vc. precisa chamar primitivas de kernel, certo? Elas não são iguais em todos os SO e vc. precisa isolar as diferenças em arquivos de cabeçalho (no C), ok? Então a sua "portabilidade" depende de um baralho de arquivos de header com instruções específicas para cada SO. Graaaande portabilidade!

é claro que estou desesperado e sufocado, tendo que usar essas ferramentas medíocres no trabalho e vendo elas serem adotadas por legiões sem conta como se fosse a melhor coisa desde pão francês!

Já passou pela sua cabeça que as "legiões sem conta" são formadas de pessoas inteligentes (algumas, até mais que você mesmo...) e que elas vêem vantagens que vc. pode estar se recusando a enxergar, por uma pura questão de "religião"? Não venha com essa sua conversa niilista de "toda unanimidade é burra!" quem interpreta essa frase de forma errada é mais idiota ainda.

Agora, se vc. quer que eu seja realmente sincero, acho que o seu desespero se deve mais ao fato de que está se popularizando uma tecnologia que vc. não domina.

o renderizador 3D padrão na indústria cinematográfica, seja escrito em Java

Assim como milhares de softwares importantes pelo mundo não são escritos em Java, assim como o mesmo número não é escrito em .NET, e um número igual não é escrito em Python, o que equivale a um mesmo número que não é escrito em C, etc. Isso não diz absolutamente nada.

A HBO nos deixou (Brasil, nós somos conceituados por lá) em segundo lugar por dois anos seguidos no Java ONE, por sua representatividade ao produzir software Java.

Pensando bem, também estou certo de que Oracle, Windows e mesmo IDEs como Delphi ou VisualStudio não são programados em linguagens dependentes de runtime, como java

E isso diz o que? E daí?

uma linguagem de baixo nível

Mentira.

tenta passar a idéia de que é mais alto-nível que C++

É realmente de mais alto nível que C++, por não ser híbrida.

e com performance melhor que Python

Realmente tem performance superior ao Python.

Problema é: qualquer coisa é mais alto-nível que C++ e qualquer coisa tem performance melhor que Python!

Essa ganhou todas! Pensei que vc. só estivesse trollando o Java. Não, existem muitas linguagens de mais baixo nível que C++ ou mais lentas que o Python, garoto.

mas o pessoal de java se orgulha de sua ferramenta cujo propósito é ser medíocre ao se limitar a ser melhor que os concorrentes em seus pontos fracos...

Sofisma. Olhando por outro ângulo, nós enxergamos uma plataforma cujo o propósito é minimizar ou eliminar pontos fracos.

além de que tem gente usando o marretão java pra tudo, fazendo de tudo , prego...

A plataforma Java é uma caixa inteira com inúmeras ferramentas para inúmeras utilizações. Problemas diferentes são resolvidos com ferramentas diferentes (até chegando ao caso de várias soluções possíveis para o mesmo problema), todas padronizadas (de preferência padrões abertos), dentro do nosso leque de opções.

Não é uma marreta, por mais que vc. se esforce para se fazer acreditar.

Java, Pyhton e competência: é? então, pq sugeriu isso com:

Vc. esqueceu de fazer um pouco da boa lógica booleana.

Programar com Python em plataforma Java, sendo que seu sistema pode ser portado para Windows ou Mac...

Vc. estará programando com a sua linguagem predileta, mas não em sua plataforma "predileta", nem para seu SO "predileto"... E isso ocorre porque há mais gente no mundo além de você.

Java pode melhorar sua vida permitindo que vc. use ao menos sua linguagem predileta em sua plataforma. Mas eliminar a plataforma Java em troca da sua ou eliminar todos os SO do mundo para que só sobre o seu, não dá pra fazer...

eu não acho que todo mundo é incompetente, só programadores M$. :)

Não generalize. Embora raros, existem os que são competentes. A plataforma deles tem vários problemas de diversos tipos, mas isso não dá a eles certificados de incompetência.

O maior indicador da competência de um profissional de TI é quando ele sabe ouvir...

são muito esforçados e ignorantes de que existe coisa melhor lá fora

Sério? Eu nao tenho certeza, mas acho que eu conheço outras tecnologias mais do que vc. conhece Java... :)

escrita competente de código: ...dá a impressão de que ser competente é suportar numa boa a insanidade de escrever umas 10 linhas de declarações para cada linha efetivo algoritmo... fora integração com configurações em xml...

Ser competente é lembrar que vc. escreve código não só para máquinas, mas também para outros seres humanos. Que podem não ter tido a mesma iluminação "genial" que vc. teve ao bater com a cabeça na privada de hoje de manhã. Essas pessoas precisam de declarações explícitas para acompanhar seu raciocínio.

Se a língua que vc. usa não te dá isso, suponho que ao menos vc. vá escrever bons comentários para compensar.

Ser competente é lembrar que existem mais qualidades em um software do que dizem seus requesitos funcionais. Portabilidade, Escalabilidade, capacidade de integração, manutenibilidade, reuso, etc. Não se trata de escrever meia dúzia de linhas às pressas e dizer pro chefe: "tá pronto!"

Ser competente é, acima de tudo, ter ciência de que um sistema no mundo real é muito mais e envolve muito mais do que simplesmente saber fazer algoritmos.

Ser competente é ser julgado pelo seu resultado final, ao longo do tempo de vida do seu sistema (e não ser elogiado agora e ouvir o pessoal de manutenção te xingando depois).

Se vc. conseguir isso com Assembly (ou com qualquer outra língua), então ok. Vc. é competente.

Patola, responde a esse menino...: Pq não são sandices e vc ou não conhece para argumentar ou simplesmente não tem como contra-argumentar...

Seu "comentário" foi direcionado ao Patola. Se ele não tiver saco de te responder (e por acaso eu tiver), posso pensar com carinho no seu caso...

As más linguas, na verdade, são boas línguas. E não são uma legião de trolls incompetentes, mas, assim como eu, frustrados com uma ferramenta genuinamente limitada e medíocre que é padrão na indústria...

Eu poderia dizer pra você se juntar a eles no mesmo saco, mas realmente acredito que vc. é mais do que isso.

caravana: Tem sempre cães latindo enquanto uma caravana passa...

Mas a caravana passa, mesmo assim...

[]s

Pra vc v q sua PRÓPRIA opinião individual vale menos ainda: ..uma vez que você e muitos outros vociferam em coro e o efeito é nulo.

O "sua" opinião individual era um "sua" genérico: a sua, a minha e de quem quer que seja.

Aprenda. Indústria é indústria. É movida pela necessidade, não pela volúpia. Pela obrigação, não pelo prazer. Não se industria (do verbo industriar que, se não existir, acabei de inventar) porque é bonito, mas porque é imperativo.

O que significa que, se alguém faz críticas ao Java fora de seu contexto, é porque não entendeu ainda este conceito tãããão básico e antigo.

?: Hã?

Não concordo.: Não concordo. Pessoas, sejam elas clientes ou desenvolvedores, podem e devem influenciar muito àquilo que faz diferença em suas vidas.

Em última instância, são as empresas e corporações (ao menos todas, menos a M$ e até mesmo ela está aprendendo) que "correm atrás" da opinião pública da comunidade de informação e não o contrário.

Faço parte da comunidade Java, que me permite participar de todo processo. No JCP, no java.net, etc. A próxima versão de produção do Java (JSE6.0 - Mustang) foi desenvolvida com total participação da comunidade. Foi o esforço da comunidade que levou a uma revisão da especificação EJB. São os frameworks de código aberto desenvolvidos pela comunidade que fazem o futuro da plataforma.

Qualquer opinião pessoal *construtiva* e de *bom senso* que leve em consideração as necessidades de toda a comunidade é muito importante para nosso futuro.

Então isso tudo é falácia. Eu não consinto que minha opinião (ou mesmo a do Nemesis) não vale nada. E mesmo assim eu não sou um frustrado.

[]s

the daily wtf: "Ser competente é lembrar que vc. escreve código não só para máquinas, mas também para outros seres humanos."

...ou melhor, que código de alto nível é escrito para seres humanos, não máquinas.

"Essas pessoas precisam de declarações explícitas para acompanhar seu raciocínio."

pra que vc acha que nomes de parâmetros ou atributos servem, ou as regras de escopo léxico?

"Portabilidade,"

check!

"Escalabilidade,"

check!

"capacidade de integração,"

check! ponto ainda mais favorável às linguagens de script, que foram feitas para se integrar e "colar" ferramentas nativas. E seu sistema de tipos dinâmicos facilita imensamente comunicação com APIs externas...

"manutenibilidade,"

check!

"reuso,"

check! diria até que os módulos mixins de ruby são particularmente notáveis para isso...

"Não se trata de escrever meia dúzia de linhas às pressas e dizer pro chefe: 'tá pronto!'"

meia dúzia de linhas em python ou ruby equivalem às 200 que vc levaria a manhã toda pra escrever em java... é claro, se vc preferir, é possível escrever as mesmas 6 portáveis, claras e objetivas linhas de python lentamente, não às pressas... :)

"um sistema no mundo real é muito mais e envolve muito mais do que simplesmente saber fazer algoritmos."

sim, envolve também interfacear com outros algoritmos, seja através de chamadas de funções diretamente, seja através de IPC...

"(e não ser elogiado agora e ouvir o pessoal de manutenção te xingando depois)."

vc está com uma visão errada sobre as ferramentas de script modernas. Se está lembrado da antiga maneira Perl ou Tcl, esqueça. É bem provável que vc seja elogiado agora e depois pelo pessoal da manutenção por seu econômico, modular e claro código python/ruby...

Outra coisa, relacionada. Talvez seja interessante notar que a maioria do código inepto que aparece lá no Daily WTF é código java/C#/VB... Poderia-se dizer que é consequência pura da popularidade dessas ferramentas, que igualmente atrai mais programadores ineptos.

Mas acho que há mais coisa envolvida aí e a cultura de complexidade -- ou "sloppiness", no caso de VB -- que essas ferramentas fomentam, têm algo a ver com a história...

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

marreta: "Tem certeza de isso é Sun-Tzu?"

desestabilizar o inimigo:
Capítulo um -- Se eles ( os inimigos ) estão enfurecidos, perturbe-os.

ainda:
Capítulo 6 -- Provoque o inimigo, para saber seus padrões de movimento.

Insultar o oponente é uma forma de provocá-lo, irritá-lo e desestabilizá-lo e fazê-lo perder o foco.

"Sério, eu tenho uma preocupação legítima com você."

essa é boa!...

"É só um colega de portal resmungando..."

isso veremos, smith... ;)

"O processo de parsing e construção de árvore sintática, com ou sem autômatos finitos (determinísticos ou não), e sua posterior interpretação não é de forma alguma novo, já existe a bastante tempo e não é 'moderno'."

ninguém disse que é. Se não houvessem, não haveriam compiladores...

É que vc parecia entender que os interpretadores modernos seriam lentos como os antigos Basic, que reinterpretam linha-a-linha as mesmas instruções, como em loops por exemplo...

"E esse processo continua sendo mais lento do que a execução de bytecode em VM"

não é a real causa da lerdeza: python usa bytecodes, ruby e perl, ASTs. A real causa é o sistema de tipos dinâmicos, com verificações em runtime. Mas é exatamente isso que traz tanta flexibilidade.

Claro, um jit ajudaria tmb...

"Por que a plataforma Java alcança o equilíbrio certo entre produtividade, portabilidade e performance."

Eu não diria certo, apenas suficiente. Mas vou concordar com vc nessa. exceto no quesito produtividade...

"Para fazer IO com cada sistema operacional, vc. precisa chamar primitivas de kernel, certo?"

Não. Só preciso chamar as primitivas oferecidas pela stdio do C. Ela pode ser implementada diferente para cada plataforma, mas não preciso me preocupar com isso, da mesma maneira que vc não precisa se preocupar como as primitivas de IO do java são implementadas sob a plataforma subjacente...

"elas vêem vantagens que vc. pode estar se recusando a enxergar, por uma pura questão de 'religião'?"

Eu sei as vantagens que elas vêem: um grande contingente de código disponível e um grande exército que sabe lidar com esse código. São pessoas práticas, que preferem usar o que há disponível para produzir do que ousar algo possívelmente melhor mas sem utilização ampla na indústria. É o mesmo tipo de gente que só vai usar Linux quando todos os outros estiverem usando. Costumavam chamar-se "maria-vai-com-as-outras"...

"acho que o seu desespero se deve mais ao fato de que está se popularizando uma tecnologia que vc. não domina."

Não domino pq não tenho saco, mas possivelmente terei que usar dentro em breve no trabalho e estão empurrando cursos e coisa e tal. No momento, por exemplo, estamos vendo JSP -- cujo ASP.NET da M$, com o qual já tinha experincia, é cópia lavada. Então, prepare-se, pois dentro em breve poderei reclamar com conhecimento de causa... :))

"Isso não diz absolutamente nada."

isso me diz que sistemas que precisam de performance não usam ferramentas dependentes de um runtime, como java ou python...

"Mentira."

é tão baixo nível que apenas algum tempo atrás o único controle para loops com coleções era o sofrível for(;;)... já ouviu falar em list comprehension? generators? iterators, felizmente, já chegaram...

"existem muitas linguagens de mais baixo nível que C++ ou mais lentas que o Python, garoto."

é figura de linguagem, filho...

"Não é uma marreta, por mais que vc. se esforce para se fazer acreditar."

Todas as diferentes tarefas a que vcs se propõem são escritas na exata mesma linguagem, mesmo que ela não seja a mais adequada à tarefa. Já ouviu falar de DSLs? Embora todas as linguagens Turing-compatíveis sejam capazes de fazer o mesmo que outras façam, a facilidade com que o fazem ou pertinência ao domínio do problema variam bastante.

Por isso, considero java a linguagem um marretão. Não que Python ou Scheme não sejam: um sistema grande tipicamente vai conter vários subdomínios e linguagens mais adequadas para este ou aquele podem facilitar bastante a escrita do sistema e o pessoal acostumado a essas linguagens têm uma visão boa disto.

Minha rinha é o pessoal que faz tudo com uma só ferramenta, como o marretão java, transformando todo problema em pregos ao invés de usar a ferramenta mais adequada...

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

Enfim, lucidez. Seja benvindo.: Se eles ( os inimigos ) estão enfurecidos, perturbe-os.

Não sabia que vc. estava enfurecido, parecia estar em delírio, mas enfurecido não. Estava?

Capítulo 6 -- Provoque o inimigo, para saber seus padrões de movimento.

Insultar o oponente é uma forma de provocá-lo, irritá-lo e desestabilizá-lo e fazê-lo perder o foco.

Insultar você foi uma forma de obrigá-lo a pôr os pés no chão, deixar a trollagem de lado e se armar de discernimento, se quisesse continuar naquilo que queria discutir. Aparentemente deu certo, lendo seus textos agora vejo que recobrou a lucidez. Só agora conversar com você voltou a ser uma atividade decente.

"Sério, eu tenho uma preocupação legítima com você."

essa é boa!...

Não preciso que vc. acredite, mas é verdade. Vc. pra mim é como um dos meus colegas ou alunos. É uma pessoa inteligente, mas que tem algo a aprender para conviver com outras pessoas e trabalhar melhor em equipe.

isso veremos, smith... ;)

Isso foi uma brincadeira, certo? Vc. não acredita mesmo nesse negócio de "Smiths", né? Espero que não.

ninguém disse que é. Se não houvessem, não haveriam compiladores...

Não, criatura. A utilização dessas técnicas em *interpretadores* também não é nova.

É que vc parecia entender que os interpretadores modernos seriam lentos como os antigos Basic, que reinterpretam linha-a-linha as mesmas instruções, como em loops por exemplo...

Interpretadores são lentos, seja qual for a técnica que utilizem. Interpretadores tipo (o antigo) Basic eu nem considero na discussão, pois se baseia na mesma técnica de interpretadores simples de expressões.

não é a real causa da lerdeza: python usa bytecodes, ruby e perl, ASTs. A real causa é o sistema de tipos dinâmicos, com verificações em runtime. Mas é exatamente isso que traz tanta flexibilidade.

Interpretar árvores sintáticas ainda é bem mais lento que executar ("interpretar") bytecodes.

Claro, um jit ajudaria tmb...

Nisso eu concordo. Mas o excesso de dinamismo em uma língua pode tornar grande parte do trabalho do JIT inútil.

Eu não diria certo, apenas suficiente. Mas vou concordar com vc nessa. exceto no quesito produtividade...

Do jeito que você fala, parece que eu levo horas para escrever uma aplicação em Java. Não é assim. Não se iluda com o fato de que escrever um HelloWorld em Java leva 1 minuto e em Python leva 40 segundos. Em uma aplicação "no mundo real", escrever mais não reduz a produtividade, pois aumenta a segurança com a qual você escreve.

É fácil perceber porque as linguagens dinâmicas seduzem as pessoas. Outro dia eu estava brincando com o suporte Jython/Groovy no meu Netbeans e realmente são gastas muito poucas linhas para escrever um servlet simples em Jython.

Mas seguindo adiante, a medida em que o código aumenta, logo vc. vai sentir falta de coisas importantes como tipos estáticos, blocos de declaração e coisas do tipo.

E, se eu estiver fazendo manutenção no código de outras pessoas, posso ficar muito chateado tentando decifrar algum trecho especialmente bizarro de código por um tempão até perceber que algum filho de uma vaca escomungada redefiniu algum operador em algum lugar do script.

Seguir em frente de modo seguro, sem receios, é uma peça importante da produtividade. Pelo menos da minha...

já ouviu falar em list comprehension? generators? iterators, felizmente, já chegaram...

Isso era implementado com objetos, como todo o resto. E confesso que isso não me incomodava muito não... Tampouco me ofendo com o novo for, é um açúcar sintático interessante. Mas ele não serve pra tudo.

Só preciso chamar as primitivas oferecidas pela stdio do C

Se só o stdio.h te atende, então suas bibliotecas são muito triviais... Nunca vi nada "sério" em C que não tivesse dependências de headers específicos e uma boa quantidade de instruções de pré-compilação. E em C geralmente tenho que me preocupar com isso sim, pois muitos recursos contam com versões para um SO e não contam para o outro, ou são implementadas por pessoas diferentes, exibindo interfaces diferentes.

é figura de linguagem, filho...

Usada impropriamente. Esconde o fato de que Java é mais rápida que muitas outras plataformas e mais produtiva que muitas outras também.

Todas as diferentes tarefas a que vcs se propõem são escritas na exata mesma linguagem, mesmo que ela não seja a mais adequada à tarefa.

É como se alguém dissesse que a língua portuguesa não é a mais adequada para falar disso ou daquilo. Não aprovo a multiplicidade de linguagens não. Quem "domina" várias línguas pode parecer "inteligente", mas na verdade o uso delas pode aumentar a confusão.

Sou contra sistemas "colcha de retalhos" ou "torres de Babel" onde um pouco da lógica está no banco, em PL/SQL, outra parte está em SQL padrão, outra ainda em Java, que roda alguns scripts Python e Lua, declarações em XML terminando com Groovy Server Pages.

Pra mim um programador deve conhecer uma língua de programação, algumas de manipulação de dados/fatos (SQL, OQL, CLIPS) e umas poucas de marcação, para usar em configurações ou na descrição de dados. E deve conhecer essas poucas ferramentas muito bem, de forma não superficial.

Prefiro bibliotecas para resolver problemas específicos do que linguagens para problemas específicos. Mais ou menos como acontece na língua falada.

Conclusão:

a facilidade com que o fazem ou pertinência ao domínio do problema variam bastante.

Não acho que a "facilidade" conseguida valha a pena. A menos que vc. queira passar a impressão de "hacker".

Pode me chamar de conservador o quanto quiser. Mas enquanto os "gênios" explodem quarteirões, são os conservadores que controem pontes e tornam a sua vida confortável.

português, *a* linguagem: "Não sabia que vc. estava enfurecido, parecia estar em delírio, mas enfurecido não. Estava?"

não estava nem enfurecido, nem delirando. Mas isso não muda o fato de que vc usou a tática do Sun-Tzu...

"É uma pessoa inteligente, mas que tem algo a aprender para conviver com outras pessoas e trabalhar melhor em equipe."

blablabla...

"A utilização dessas técnicas em *interpretadores* também não é nova."

eu devia ter dito "tradutores"...

"Interpretadores são lentos, seja qual for a técnica que utilizem."

É a velha discussão entre flexibilidade vs rigidez: interpretadores são lentos porque permitem ao programa se adequar à condições existentes em tempo de execução, ao passo que um programa compilado não pode prever tudo o que vai acontecer e deixa o código amarrado ao que o programador sabia até a compilação.

Sempre vai haver gente pendendo para um lado ou para o outro, dependendo da ocasião. Mas talvez seja bom lembrar: "A árvore que não se curva em temporais, quebra"... flexibilidade é bom. :)

"Interpretar árvores sintáticas ainda é bem mais lento que executar ('interpretar') bytecodes."

python é tão ou mais lento quanto ruby ou perl, prova de que teoria é uma coisa e prática é outra...

"o excesso de dinamismo em uma língua pode tornar grande parte do trabalho do JIT inútil."

exatamente. vê pq não há muito esforço no sentido de se implementar JIT para essas linguagens? ou pq não há muitos benefícios em rodá-las na JVM?

"escrever um HelloWorld em Java leva 1 minuto e em Python leva 40 segundos."

haha, boa! mas na verdade, o hello world do python sai em uns 4 segundos, consistindo apenas em:
print "Hello World"

ao passo que em java:
public class HelloWorld {
   public static void Main() {
     System.out.println( "Hello World" );
   }
}

tenho que declarar um porrilhão de coisas antes de fazer o que quero -- coisa pejorativamente chamada no círculo das linguagens de script como "boilerplate code" ou "scaffolding"...

É verdade que as IDEs dão uma boa ajuda durante a *escrita*, seja com autocomplete, seja com templates. Elas só não ajudam posteriormente durante a *leitura* e manutenção: vc tem que distinguir os poucos trechos de código útil embrulhados em meio a uma enxurrada de "boilerplate code"...

"Em uma aplicação 'no mundo real', escrever mais não reduz a produtividade, pois aumenta a segurança com a qual você escreve."

Escrever
System.out.println( "foo" );

não me dá nenhuma sensação de segurança a mais que:
print "foo"

nem tampouco declarar
private TipoRet metodoFoo( TipoArg argumento )

não me deixa muito mais seguro quanto a
def metodoFoo( argumento )

exceto que programadores insanos não poderão passar qualquer tralha para o métodoFoo em tempo de compilação. A checagem de tipos durante a compilação vai impedir isso, mas não vai impedir comportamentos estranhos de ocorrerem em tempo de execução decorrentes de algoritmos mal pensados...

Unit tests cobrem todas essas possibilidades e são a meu ver bem mais úteis em termos de segurança do que um sistema de tipos estático e bem menos limitante...

Além disso, na prática, vendo código de programadores que pensam como vc, sou forçado a lidar com código que, visualmente, parece uma muralha de letrinhas: para distinguir os parcos trechos de código relevante dentre todo o boilerplate entremeado, é preciso apertar a vista e dar scroll pro lado... como isso pode ser possivelmente melhor que código enxuto, econômico e visualmente claro está além de minha compreensão...

"Outro dia eu estava brincando com o suporte Jython/Groovy no meu Netbeans e realmente são gastas muito poucas linhas para escrever um servlet simples em Jython."

ok, já é um começo. Mas da próxima vez, ao invés de brincar, tente algo sério...

"a medida em que o código aumenta, logo vc. vai sentir falta de coisas importantes como tipos estáticos, blocos de declaração e coisas do tipo."

Vc tentou algo sério para efetivamente falar isso? É um mundo diferente e pode ser difícil largar velhos hábitos e partir para uma forma diferente de pensar, admito. Imagino que seja uma sensação semelhante ao passarinho engaiolado por tanto tempo que depois tem medo de voar livremente, sentindo falta da falsa sensação de segurança da clausura...

"se eu estiver fazendo manutenção no código de outras pessoas, posso ficar muito chateado tentando decifrar algum trecho especialmente bizarro de código por um tempão..."

código bizarro se escreve em qualquer linguagem e são particulamente "nasty" quando escritos em linguagens verbosas como java por programadores entusiasmados por toda aquela redundãncia, como fica evidente em muito do código no The Daily WTF...

"até perceber que algum filho de uma vaca escomungada redefiniu algum operador em algum lugar do script."

redefinição de operadores ou definição de novos são essenciais para linguagens que se adaptem facilmente a seu domínio de aplicação. Linguagens de script, C++, Haskell, Lisp e outras são linguagens bastante fortes nesse quesito.

Mas vc está enganado! Não é em qualquer lugar, senão é bagunça! Pelo menos, regras de escopo léxico estão sendo seguidas, o que significa que a alteração é sempre local a uma região de código e facilmente identificável e isolada. Logo vc, que deve gostar de ler todas as declarações no código! :))

"Seguir em frente de modo seguro, sem receios, é uma peça importante da produtividade."

sapato velho sempre é mais confortável, sem dúvidas...

"Mas ele não serve pra tudo."

não, serve apenas para tornar escrita de processamento de coleções muito mais conveniente, algo que deve responder por cerca de 80% em loops de aplicações do "mundo real"...

"Se só o stdio.h te atende, então suas bibliotecas são muito triviais"

um bocado de código que precisa realizar IO pode tranquilamente ser reduzido a sequências de puts, gets e getchar em arquivos ordinários. Particularmente, bibliotecas com tarefas específicas, tipo em lote.

"É como se alguém dissesse que a língua portuguesa não é a mais adequada para falar disso ou daquilo."

Tem razão! Aliás, pq não escrevemos em bom português nossos programas de computador, ao invés de perdermos nosso tempo com java e outras bobagens, hein? Pq não descrevemos modelos de dados em português ao invés da linguagem gráfica de diagramas UML? Pq não descrevemos fórmulas matemáticas em alto e bom português, ao invés de todos aqueles símbolos malucos?! H2O?! Não me faça rir: claramente, "água" é muito mais claro e objetivo!!

Português é claramente adequado para todas as nossas necessidades e muito mais conveniente para a expressão de idéias em quaisquer domínios de aplicação...

"Quem 'domina' várias línguas pode parecer 'inteligente', mas na verdade o uso delas pode aumentar a confusão."

eu diria que aumenta o entendimento nos diferentes domínios com o quais o sistema vai interfacear...

"E deve conhecer essas poucas ferramentas muito bem, de forma não superficial."

vejo que webdesigners -- que conhecem bem seu domínio de aplicação, com html e CSS -- não têm vez em seus sistemas, que só falam java...

"Prefiro bibliotecas para resolver problemas específicos do que linguagens para problemas específicos. Mais ou menos como acontece na língua falada."

a lingua falada não conta com bibliotecas para problemas específicos. Ela forma sublinguagens ou idiomas para lidar com idéias e expressões específicas a um domínio...

"Não *acho* que a 'facilidade' conseguida valha a pena."

eu *acho* que vale...

"Mas enquanto os 'gênios' explodem quarteirões, são os conservadores que controem pontes e tornam a sua vida confortável."

muitos conservadores são capazes de atrocidades contra a humanidade em prol de uma vida confortável para seus pares. e nem todo gênio é do mal...

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

É uma delas...: Mas isso não muda o fato de que vc usou a tática do Sun-Tzu...

Se não estava delirando antes, está agora. Larga dessa, vc. não é meu oponente, mesmo que queira ser.

blablabla...

Ok, é inútil falar sobre suas atitudes com você. Esqueça.

interpretadores são lentos porque permitem ao programa se adequar à condições existentes em tempo de execução, ao passo que um programa compilado não pode prever tudo o que vai acontecer e deixa o código amarrado ao que o programador sabia até a compilação.

A compilação "intermediária" (pré-compilação) ajuda a endereçar esse problema.

"A árvore que não se curva em temporais, quebra"... flexibilidade é bom. :)

Essa frase é de Jigoro Kano e está 100% certa. Que bom que vc. aprendeu.

python é tão ou mais lento quanto ruby ou perl, prova de que teoria é uma coisa e prática é outra...

. . .

exatamente. vê pq não há muito esforço no sentido de se implementar JIT para essas linguagens? ou pq não há muitos benefícios em rodá-las na JVM?



É por causa do (ab)uso das invocações dinâmicas na linguagem. Sob plataforma Java, parece que haverá uma novidade no J2SE7.0 (Dolphin), que seria a adição de uma instrução adicional de bytecode (invokedinamic) que permitirá algumas otimizações sobre invocações dinâmicas e deve beneficiar tanto o Jython quanto o Groovy. É esperar pra ver.

haha, boa! mas na verdade, o hello world do python sai em uns 4 segundos...

Pô, tampouco em Java leva realmente 1 minuto. Foi só figura de linguagem.

A diferença entre a escrita em Python e Java é que em Java eu não escrevo apenas um "HelloWorld". Eu escrevo uma classe, que tem seu lugar no "mundo" (namespace) e todas as propriedades que uma classe tem. Ela está inevitavelmente inserida no contexto de OOP. Pode ser utilizada por outras classes como tal.

Então não é "boilerplate code" como vc. afirma. O código "extra" tem a sua função.

Por outro lado, em línguas de script eu tenho um "print" solto no espaço e no tempo, sem outra propriedade a não ser o que é.

Se vc. quiser apenas um HelloWorld, escreva print "Hello World" no beanshell.

Escrever
System.out.println( "foo" );

não me dá nenhuma sensação de segurança a mais que:
print "foo"

Mas escrever:

class Foo{
public void print(String foo){
System.out.println(foo);
}
}

ME dá mais segurança sim. Tem acessibilidade definida, um método que pode ser sobrescrito ou sobrecarregado (ou não, com os modificadores corretos), uma classe que pode ser derivada (ou não), o tipo de parâmetro que pode ser passado é estaticamente definido (tal como eu queria no meu projeto), etc.

nem tampouco declarar
private TipoRet metodoFoo( TipoArg argumento )

não me deixa muito mais seguro quanto a
def metodoFoo( argumento )

... exceto que programadores insanos não poderão passar qualquer tralha para o métodoFoo em tempo de compilação...


Programadores "insanos" são aqueles que querem confiar no compilador para ajudá-los a não cometer erros no uso de uma API de terceiros que não se conhece bem?

Deixa seguro sim. A intenção do programador fica clara em tempo de projeto, e a API não pode ser usada fora dos propósitos para os quais foi projetada.

Unit tests cobrem todas essas possibilidades e são a meu ver bem mais úteis em termos de segurança do que um sistema de tipos estático e bem menos limitante...

Testes de Unidade ajudam bastante o seu trabalho, mas vc. não pode fazer com que seu sistema dependa dos testes unitários para fazer sentido. Senão isso vira uma muleta. E um aleijado e sua muleta pode ser facilmente separados.

Além disso, na prática, vendo código de programadores que pensam como vc, sou forçado a lidar com código que, visualmente, parece uma muralha de letrinhas: para distinguir os parcos trechos de código relevante dentre todo o boilerplate entremeado, é preciso apertar a vista e dar scroll pro lado... como isso pode ser possivelmente melhor que código enxuto, econômico e visualmente claro está além de minha compreensão...

Acho que é coisa pessoal. Em código Java eu consigo chegar no trecho relevante em poucos segundos. O que é ruído para você, para mim são sinais que me levam ao meu objetivo.

Enquanto isso, em línguas de script eu fico olhando para uma variável misteriosa (sem tipo definido) solta no espaço tentando imaginar que tipo de informação vai ter ali dentro quando a birosca executar. E sou obrigado a caçar todas as malditas atribuições feitas à miserável.

Java fala bastante explicando tudo. Scripts falam um provérbio e esperam que eu adivinhe o resto.

Sobre sobrecarga de operadores:
a alteração é sempre local a uma região de código e facilmente identificável e isolada

Um bloco de código bastante longo que tem sobrecargas de operadores em seu escopo continua tornando as coisas difíceis. Ah, blocos não deveriam ser tão longos? Bem, uma linguagem não pode depender da boa vontade dos programadores para ser simples de manutenir.

pq não escrevemos em bom português

A comparação foi mal interpretada. Fiz uma analogia entre linguagem humana e a de computador. O que quis dizer foi que línguas humanas têm a obrigação de poder expressar idéias humanas. Vc. não pode ser obrigado a dizer algo em alemão porque o Português não atende. Da mesma forma, vc. não pode ser obrigado a escrever um monte de partes do sistema em C só porque Python é muito lerdo.

vejo que webdesigners -- que conhecem bem seu domínio de aplicação, com html e CSS -- não têm vez em seus sistemas, que só falam java...

Eles que escrevam seu trabalho da forma melhor que puderem, do jeito que quiserem. Quando terminarem cada página eu faço pequenas marcações em seu design (velocity ou Tapestry) e integro ao sistema J2EE. Em momento nenhum preciso estar a par das novidades do CSS ou até de Javascript.

Agora, se sou incumbido de fazer o trabalho todo (sem designer), faço o trabalho em JSF, integrado ou não com Ajax ou Laszlo. Novamente, não preciso estar a par das novidades do CSS ou até de Javascript.

No dia em que todos os navegadores suportarem XUL, minha vida ficará bem melhor. Deixo HTML, CSS, Javascript nos livros de história e faço aplicações mais facilmente, deixando que os designers desenvolvam em volta da minha aplicação.

Como pode ver, eu e os designers daqui estamos em bom acordo! :)

eu diria que aumenta o entendimento nos diferentes domínios com o quais o sistema vai interfacear...

Não. Obriga os profissionais a pulverizarem seu conhecimento de forma a que saibam muitas coisas com profundidade nenhuma.

a lingua falada não conta com bibliotecas para problemas específicos. Ela forma sublinguagens ou idiomas para lidar com idéias e expressões específicas a um domínio...

Já ouviu falar de analogia e metáforas? Elas comunicam conjuntos inteiros de idéias sem precisar recorrer a um idioma específico.

eu *acho* que vale...

Seja feliz com isso então. O futuro dirá, assim como o presente está dizendo.

muitos conservadores são capazes de atrocidades contra a humanidade em prol de uma vida confortável para seus pares. e nem todo gênio é do mal...

Essa não foi uma comparação moral. Vou ter que explicar melhor.

Conservadores são práticos o suficiente para construírem coisas confiáveis, enquanto "gênios" explodem coisas por acidente até acertar.

Cara, por mais "estimulante" que seja "flamear" com você, temo que isso se tornará cada vez mais raro. Eu estou realmente ficando de saco cheio disso e questionando sua utilidade. Por outro lado, tenho aquele projeto que concebemos aqui no BR-Linux (o JIX, lembra?) e vou direcionar meus esforços para ele.

[]s

bye for now: Pra ser honesto, já estou de saco cheio de fóruns web: é discussão em cima de discussão sem nunca chegar a lugar algum. Argumentar com seres humanos é impossível pq o apelo emocional sempre ganha da razão...

É irracional continuar e, portanto, este será meu último post aqui. Tenho uma A.I. para reconstruir e um cyberspace para conquistar... :)

"Essa frase é de Jigoro Kano e está 100% certa. Que bom que vc. aprendeu."

sim, espero que vc chegue lá... ;)

"É por causa do (ab)uso das invocações dinâmicas na linguagem."

que é precisamente o que as tornam tão flexíveis, produtivas e interessantes...

"(invokedinamic) que permitirá algumas otimizações sobre invocações dinâmicas e deve beneficiar tanto o Jython quanto o Groovy."

Isso é resultado de um Summit realizado em 2005 ou 2004 na Sun, na qual eles convidaram várias personalidades das linguagens de script mais populares -- incluindo Larry Wall e Guido van Rossum -- para ouvirem quais recursos seriam interessantes para linguagens desse tipo na forma de operadores primitivos na VM. invokedynamic foi uma prioridade...

"A diferença entre a escrita em Python e Java é que em Java eu não escrevo apenas um 'HelloWorld'. Eu escrevo uma classe, que tem seu lugar no 'mundo' (namespace) e todas as propriedades que uma classe tem."

se eu quiser modularizar, em python, basta gravar um arquivo hello.py:

def hello( foo = "World" ):
&npsp;&npsp;print "Hello, %s!" % foo

isso é um módulo completo ( controle de namespace ) e se quiser redundância extra, ainda pode prefixar o acima com:

class Hello:

e ter seu código encapsulado em uma classe pertencente a um namespace.

para invocar o código, vc importa:
import hello.Hello
ou
from hello import Hello

Enfim, *quando* vc precisa, basta fácil e incrementalmente adicionar encapsulamentos...

"Por outro lado, em línguas de script eu tenho um 'print' solto no espaço e no tempo, sem outra propriedade a não ser o que é."

perfeito para um helloworld. simplicidade, Copérnico, simplicidade! não preciso de um canhão para matar moscas e posso incrementalmente ter mais recursos disponíveis se necessário...

"Se vc. quiser apenas um HelloWorld, escreva print 'Hello World' no beanshell."

que é uma linguagem de script...

"Tem acessibilidade definida, um método que pode ser sobrescrito ou sobrecarregado (ou não, com os modificadores corretos), uma classe que pode ser derivada (ou não),"

na realidade, python e similares provêm tudo isso. exceto "ou não", pois não faz parte da filosofia por trás dessas linguagens limitar...

"o tipo de parâmetro que pode ser passado é estaticamente definido (tal como eu queria no meu projeto)"

Interessante vc ter definido um parâmetro string. Strings são o "kitchen-sink" dos tipos de dados comuns: o cara passa qualquer porra lá dentro. String vazia, dígitos ao invés de esperados caracteres alfabéticos, código HTML misturados com texto normal etc...

Uma linguagem realmente segura te deixaria definir alguns tipos comuns para serem usado ao invés de strings. Tipo, NomeType para strings com algumas particularidades no formato ou IdadeType representando ranges de inteiros entre 0 e 130 ( usualmente )...

"Programadores 'insanos' são aqueles que querem confiar no compilador para ajudá-los a não cometer erros no uso de uma API de terceiros que não se conhece bem?"

na verdade, pensei em sujeito insanos mesmo, que não seguem a razão e o bom-senso. :)

Mas o que te leva a acreditar que o interpretador não faria um trabalho tão bom quanto um compilador em avisar o programador sobre erros? Um interpretador nada mais é que um compilador realmente JIT... claro, não compila nada, apenas chama código já compilado na forma das primitivas, mas no sentido de traçar o código...

"A intenção do programador fica clara em tempo de projeto, e a API não pode ser usada fora dos propósitos para os quais foi projetada."

as APIs dessas linguagens são geralmente bem claras e sensatas, mas elas podem ser usadas de maneiras que o programador original não previu, para o bem ou para o mal...

"vc. não pode fazer com que seu sistema dependa dos testes unitários para fazer sentido. Senão isso vira uma muleta."

no que isso difere de um compilador, seu aleijado? :)

"O que é ruído para você, para mim são sinais que me levam ao meu objetivo."

mas talvez vc chegasse lá mais rápido sem tanta tralha na frente... :P

"Enquanto isso, em línguas de script eu fico olhando para uma variável misteriosa (sem tipo definido) solta no espaço tentando imaginar que tipo de informação vai ter ali dentro quando a birosca executar."

vc parece estar falando de bash, ou tcl ou perl nos bons tempos... :)

ruby e python não são assim -- prezando, ao invés, modularidade e encapsulamento -- embora vc certamente possa usá-las para scripts rápidos e rasteiros...

de qualquer maneira, se se incomoda variáveis e mudanças de estado, sugiro que se livre delas e dê uma olhada em linguagens funcionais como Haskell, nas quais tudo é resultado da avaliação de expressões...

"Java fala bastante explicando tudo. Scripts falam um provérbio e esperam que eu adivinhe o resto."

boa! huhuhu...

mas eu diria que a comparação está mais para um cansativo monólogo em 3 atos vs uma comédia standup em 15 minutos... :)

"blocos não deveriam ser tão longos? Bem, uma linguagem não pode depender da boa vontade dos programadores para ser simples de manutenir."

é verdade, ela pode ao invés lhes tomar liberdades em prol do bem-comum e padronizações e pô-los em camisas-de-força para que não atirem no próprio pé...

"Novamente, não preciso estar a par das novidades do CSS ou até de Javascript."

*alguém* precisa estar, seja programadores da Sun ou M$ vendendo seus últimos revolucionários produtos, seja programadores open-source de infraestrutura...

"Javascript nos livros de história e faço aplicações mais facilmente"

na realidade, XUL usa javascript para resposta a eventos...

"Obriga os profissionais a pulverizarem seu conhecimento de forma a que saibam muitas coisas com profundidade nenhuma."

a idéia de DSLs é de que vários profissionais de áreas diferentes se integrassem em um projeto para a criação de sistemas. Mas concordo com vc: na prática, vai ser um só maluco pra criar a interface, conectar com o banco, ter as regras de negócio na cabeça, e por aí vai... nada é perfeito...

"Conservadores são práticos o suficiente para construírem coisas confiáveis, enquanto 'gênios' explodem coisas por acidente até acertar."

ei, alguém precisa tentar novas maneiras de se fazer as coisas. Se fosse pelos conservadores, ainda estaríamos no Neolítico...

"tenho aquele projeto que concebemos aqui no BR-Linux (o JIX, lembra?) e vou direcionar meus esforços para ele."

ok, boa sorte. se as coisas complicarem, tente reimplementar em python... huahauhauhuhauh....

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

Conclusão e Câmbio Final: Argumentar com seres humanos

Hehe... Essa piada de "sou um bot" já rendeu bons momentos.

que é precisamente o que as tornam tão flexíveis, produtivas e interessantes...

. . .

etc, etc, etecétara...

Acho que aprendemos (ou ao menos precisamos aprender) uma coisa muito importante aqui, chamada convivência.

Resumindo essa coisa toda, representamos dois tipos de programador:

Conservador (Copérnico): Confia em padrões, mas do que em genialidade. Nenhuma solução brilhante é útil se não for padronizada e se integrar de forma previsível com o que já existe. Muitos gênios fazendo coisas brilhantes, mas cada qual do seu próprio jeito, não é produtivo.

Confia em uma única linguagem para cada tarefa macro. Para cada problema, uma solução. Uma única linguagem de programação, uma única linguagem de marcação... Quanto menos linguagens ele puder trabalhar, e quanto mais nelas ele puder se aprofundar, melhor. Se tem um problema que ele não pode resolver com seus recursos atuais, ele desenvolve novos recursos, na mesma plataforma em que ele confia.

Procura a concórdia e evita a polêmica. Seu ideal é padronizar o mundo.

Para ele, padrões e restrições não são para prender quem está dentro, mas manter as coisas ruins do lado de fora.

Tem de se cuidar para não se tornar centralizador em excesso.

Liberal (Nêmesis): Confia em soluções novas para cada problema específico. Para ele, padrões são uma prisão que impede o florescimento de novas idéias. Nenhuma tecnologia é boa quando se pode encontrar alguma outra melhor, para cada objetivo. Se há um problema que ele não consegue resolver com seus recursos atuais, ele procura uma abordagem completamente diferente.

Adora a polêmica e evita a unanimidade. Se alguém decide aprovar o que ele diz, ele logo muda de discurso. Seu ideal é o debate constante.

Para ele, padrões e restrições não são feitas para protegê-lo, mas sim para impedir que ele alcance seus objetivos.

Tem de se cuidar para não se tornar dispersivo demais.

Os dois tipos de pessoa sempre vão ter opiniões divergentes sobre esse tipo de assunto. A conclusão aqui é que temos que aprender à conviver e a integrar.

perfeito para um helloworld. simplicidade, Copérnico, simplicidade!

Padronização, Nêmesis, padronização! Fazer as coisas de um jeito uniforme, previsível, escalável e menutenível!

na realidade, python e similares provêm tudo isso. exceto "ou não", pois não faz parte da filosofia por trás dessas linguagens limitar...

Já isso, pra mim, é um problema enorme!

mas elas podem ser usadas de maneiras que o programador original não previu, para o bem ou para o mal...

Geralmente nem para o bem nem para o mal: usadas erradas por engano.

Conclusão: é um debate infinito... :)

Últimos esclarecimentos:
na realidade, XUL usa javascript para resposta a eventos...

Não exatamente. XUL pode usar [substitua pelo seu script preferido, que seu motor suportar] para interpretar eventos. Dando uma olhada no Bizantyne, vc. vai ver que ele usa Java puro para isso.

Uma linguagem realmente segura te deixaria definir alguns tipos comuns para serem usado ao invés de strings

As type-safe enumerations do Java endereçam parte desse problema. A próxima parada são tipos range (que vc. pode simular hoje, encapsulando com objetos).

o interpretador não faria um trabalho tão bom quanto um compilador em avisar o programador sobre erros?

Oras, simplesmente pelo fato de que o compilador valida obrigatóriamente todo o código, enquanto o interpretador só valida um trecho quando o fluxo de execução passa por ele. Um bug pode se esconder por meses em alguma opção condicional obscura (e não coberta pelos teste, se existirem) antes de estourar na sua mão em tempo de execução!

JIX:

ok, boa sorte. se as coisas complicarem, tente reimplementar em python...

Nem pensar! :) Preciso de uma API de sistema coesa e bem definida. E o Python não tem a quantidade de recursos de API e projetos open source de que preciso (nem aquelas outras coisas que sabemos bem). Mas alegre-se, estou pensando em você também. Além do beanshell padrão e emulação do bash, já consegui material para incluir suporte shell a ECMA-Script (javascript), Jython, tcl, Groovy e JRuby (rodando sobre a JVM).

Câmbio, desligo.