Viva a diversidade!
Emacs vs Vi, Mac vs Windows vs Linux, Intel vs AMD, OO vs Funcional. Vários temas na Computação são capazes de gerar discussões intermináveis, exaltadas, quase religiosas. Mas atualmente, a que mais me irrita é a interminável discussão sobre qual a melhor linguagem de programação.
Defensores de Java dizem que linguagens de script não aguentam sistemas grandes, estruturados. Defensores de Ruby ou Python dizem que Java é um lixo feito para quem não sabe programar. Amantes de Ocaml, Haskell e Erlang acham o resto do mundo é inferior. Quem não programa em Ocaml, Haskell e Erlang acha que são linguagens exóticas e acadêmicas. Todos acham que .NET é um lixo. Cada um quer mostrar quão melhor é a sua linguagem, como pode fazer tudo o que as outras fazem e muito mais.
É inevitável que uma pessoa acabe ficando mais a vontade com uma ou duas linguagens, aquelas que ela usa no dia a dia. Eu por exemplo considero que minha primeira linguagem hoje em dia é Java. Foi a primeira linguagem séria que eu aprendi, e venho trabalhando com ela comercialmente há vários anos. Mas sinceramente não gosto de ser marcado como Programador Java. Aliás, não gostaria de ser marcado como Programador X, onde X é uma linguagem qualquer. Acho que isso reduz. Me considero um desenvolvedor de tecnologia, de produtos, e assim sendo gosto de sempre procurar uma linguagem que se adeque melhor ao tipo de programa que tenho que escrever.
Tirando Pascal, que aprendi na universidade por motivos didáticos (curso básico de programação), todas as linguagens que eu programei minimamente foram motivadas por motivos práticos. Aprendi Perl quando eu quis escrever um etiquetador de palavras em português: dada uma lista de palavras, ele determinava se era oxítonas, paroxítonas ou proparoxítonas, e se eram mono, bi, tri ou polisilábicas (comecei escrevendo em C, mas rapidamente percebi que seria muito mais rápido e eficiente aprender Perl do que ficar fazendo regexp na unha). Aprendi Python quando precisava de uma linguagem de script clean e bem estruturada para processar arquivos com dados de biologia molecular. Aprendi de fato C quando precisei escrever um captador e analisador de imagens via firewire em tempo real para um sistema embarcado. Descobri o poder de Javascript quando comecei a querer implementar aplicações Web com interfaces ricas, AJAX. Aprendi Java quando quis começar a desenvolver sistemas OO multiplataformas e mais tarde, sistemas web.
Não existem nenhuma tecnologia perfeita. Um bom desenvolvedor tem que saber definir quais características são importantes pro projeto dele, e determinar qual tecnologia é a mais adequada. Temos a tendência a sempre querer usar aquelas que conhecemos melhor. É inevitável. Mas as vezes é saudável analisar outras opções e ver se existem coisas melhores. Sim, coisas melhores podem existir! É importante portanto que sejamos capazes de reconhecermos as fraquezas de cada linguagem, e eventualmente abrirmos mão daquela que sempre usamos.
Dois pontos tem que ficar bem claros para pessoas ligadas ao mundo do desenvolvimento.
O primeiro ponto é entender que o que diferencia bons desenvolvedores de péssimos desenvolvedores é a capacidade de entender e manipular as tecnologias existentes, ter uma visão crítica do que existe, saber se adaptar. O mundo da computação evolui de forma muito rápida. As necessidades mudam constantemente. Ficar obcecado por uma linguagem e tentar provar a todos que é capaz de fazer tudo com ela não leva a lugar nenhum. Bons desenvolvedores são pessoas curiosas, que gostam e são capazes de aprender coisas novas, querendo sempre aprimorar seus conhecimentos. Bons desenvolvedores são aqueles que entendem (ou procuram entender) os conceitos por trás das ferramentas que utilizamos.
O segundo ponto é que em última instância, o que paga nossos salários e o que nos torna úteis para a sociedade não é o fato de saber escrever if-then-else em uma determinada linguagem. O que nos torna úteis é a nossa capacidade de desenvolver produtos que facilitem de alguma forma o dia a dia das pessoas. Esse é o grande poder da tecnologia. Assim sendo, o nosso objetivo é criar estes produtos da melhor forma possível, utilizando os melhores recursos disponíveis. Usuário não vê o que está por baixo dos panos, e tampouco está interessado nisso. Usuário vê apenas se aquilo que desenvolvemos ajuda ou não. Nesse ponto, o que interessa portanto não é a tecnologia, mas sim o design da solução (aconselho a leitura do texto do Raphael sobre este tema).
Miguel,
sabes muito bem que sou um crítico severo de Java-a-linguagem. Sou menos crítico de Java-a-plataforma. Acho que Java-a-linguagem (JaL, pra encurtar) deixa muito a desejar no quesito “capacidade de expressão”. É praticamente impossível fazer construções lógicas curtas e diretas em JaL. Tudo é muito sandboxed. É muito difícil querer usar JaL para testar algum algoritmo de forma rápida, ou montar um protótipo para validar algum conceito (explorar alguma idéia). Throwaway code, então, nem pensar.
A força de JaL é que é uma linguagem segura, mas isso resultou em perda de poder. C, por exemplo, não tem nada de segurança mas ao menos permite que você passe um (void *) de um lado pro outro. Isso pode ser perigoso, mas pode ser muito útil em um ou outro caso. No espectro de capacidade de expressão, até C é mais poderosa do que JAL.
Se olhar, muitas “técnicas” de engenharia de software acabam sendo criadas para compensar essa falta de capacidade de expressão. JaL tem uma série de problemas por ser estritamente OO e não permitir certas construções lógicas e sintáticas? Design Patterns neles. JaL tem dificuldade para fazer programação bottom-up? Refactoring, Refactoring, Refactoring. JaL é muito verbosa e precisa de 20 linhas para um programa básico? IDE’s com geração de código a caminho…
Se for ver, isso foi intencional por parte da Sun. JaL não foi desenvolvida por um grupo de hackers que se sentiram descontentes com a capacidade de expressão com as linguagens da época, mas foi desenvolvida com o intuito de ser uma linguagem que pudesse ser aprendida por hordas e hordas de code-monkeys, através de toneladas de cursos e certificações by Sun.
Para o pessoal enterprise-y, isso está ótimo. É uma linguagem segura, onde se tem confiança que o programador não é capaz de fazer grandes estragos num codebase e, mais importante, o desenvolvedor passa a ser uma peça intercambiável. Na cabeça do empregador, basta tirar um code-monkey e colocar outro, contanto que ele tenha uma certificação by Sun (ou by IBM, ou by Impacta, wherever).
No mercado enterprise, não cabe muito ao programador a parte de bolar a solução. Formatos de armazenamento de informações de bilhetagem não são feitos por programadores, são pré-determinados por gente com experiência em OOS e BOS em telecom. Sistemas de gerenciamento de tráfego aéreo não são projetados por programadores, mas são analisados e especificados por profissionais da área. Sistemas de armazenamento de informações de pacientes em hospitais, a mesma coisa. O trabalho do desenvolvedor é um trabalho de implementação, puro e simples.
No mercado enterprise é preferível um programa “medíocre” e “confiável” a um programa “genial” mas “imprevisível”.
Você fica bravinho comigo porque acha que eu estou desmerecendo você, ou comparando você a um code-monkey. Não é verdade. Como você mesmo disse, você não é um “programador Java”. Você, quando precisou, buscou linguagens onde precisava de mais poder de expressão.
Entretanto, eu acho sim que há uma resposta para “qual é a melhor linguagem” e definitivamente Java está longe de ser a resposta. Pergunte-se: “se você pudesse iniciar um projeto, seu, sem pensar no dinheiro ou emprego, qual linguagem você escolheria?”. Eu sou capaz de apostar que os que vão escolher Java são os que têm experiência apenas em Java. Qualquer um que tenha mexido com linguagens que permitem maior capacidade de expressão vão utilizar desse poder.
JaL, como é, vai morrer (como C++) ou ter que se adaptar continuamente (como C#). Ela nunca chegou a ser a solução perfeita em termos de WORA, performance só se tornou aceitável depois que isso deixou de ser relevante e, mais importante, os desenvolvedores top agora possuem linguagens que oferecem as benesses da plataforma Java (gerenciamento de memória, interface com código-objeto escrito em outra linguagem, orientação a objeto onde interessante, etc) AO MESMO TEMPO que oferece mais flexibilidade, dinamismo e capacidade de expressão.
Viva a diversidade? Ok. Mas temos que saber que a natureza elimina os menos aptos.
Viva a diversidade! « Log4Dev
Você é daqueles que ficam discutindo qual a melhor linguagem, e quem é melhor programador? Quer minha opinião? Esta discussão é inútil. Existem coisas muito mais importantes…
[…] Então, lendo o último post do Miguel, eu fiquei com vontade de falar “Java is TeH SuXXXXXoR”. Mas como precisamos fazer as coisas aqui com estilo, acabei escrevendo isso aqui, ó. […]
Raphael, vou transpor para este espaço os nosso diálogo no gtalk.
Você me pergunta o que eu acho do teu comentário.
Eu digo que as coisas que vc falou de java, concordo em partes. Discordo quando vc diz que é sim possivel determinar qual a melhor linguagem de programação. Não me parece que isto seja algo absoluto. Talvez determinar um bom set de linguagens de programação seja possível.
O ponto principal, como eu disse, é que é importante ter visão crítica. Neste ponto, teu comentário tem uma visão crítica interessante sobre a linguagem Java (tô curioso pra ver os comentários do Bruno em breve)
o que me irrita, e vc sabe, é a famosa associação “você programa linguagem X” => “você é um loser”. A associação correta pra mim seria “você acha que X resolve tudo e que o resto é uma merda?” => “você é um loser”.
Responder o Raphael me tomará um tempo que eu não terei nesta agitada sexta-feira.
Amanhã eu respondo
Minha resposta:
Particularmente com o Eclipse eu uso Java até para scripting, ainda tenho o melhor dos dois mundos, todo meu conhecimento de Java, seu SDK, debuging no IDE e a agilidade de quem está escrevendo scripts mesmo.
Você deve estar se referindo ao falta de aritmética de ponteiros, a presença de um Garbage Collector,
Null pointerexceptions,Array index out of boundsexceptions… Ou outros aspectos?Detalhe, segura não é Java a linguagem, pois quem carrega o fardo as tarefas acima é sim a Máquina Virtual e não a sintaxe da linguagem (com excessão da aritmética de ponteiros).Poder para acessar regiões de memória não seguras? Poder para esquecer-se de desalocar memória para por exemplo toda e qualquer string?
Acredite, em Java o seu ponteiro para
voidé simplesmente uma variável do tipoObject(claro, sem artimética de ponteiros ou tipos primitivos e outras restrições).Não imagino como! Java sim tem um ótimo poder de expressão para escrever código OO, humilhando C++ neste caso, basta comparar qualquer simples código OO em ambas as linguagens. (sim, eu vi que você estava falando de C, mas o coitado do C nem OO é, mas é claro, tem seu lugar no mundo atual bem seguro em determinados nichos).
Exemplos…?
Quais problemas? Quais construções lógicas e sintáticas??
Design Patterns são apenas nomes para soluções de desenho de modelos OO para aumentar o reuso e melhorar a manutenção de seu código. Não tem absolutamente nada a ver com as limitações sintáticas de uma linguagem.Quem não busca reuso e código mais manutenível em seu trabalho?
Refactoring é simplesmente um conjunto de técnicas para alterar o seu código sem alterar seu comportamento, novamente buscando melhor reuso e manutenibilidade. Não tem nada a ver com permitir programação bottom-up em nenhuma linguagem.
Ai eu faço minhas as palavras de Kevin King. A dita verbosidade de Java é facilmente suplantada por ferramentas extremamente sofisticadas e gratuitas como o Eclipse, e se você programa em Java e diz que não usa uma ferramenta como o Eclipse então…
Se você não considera o James Gosling um hacker na época em que escreveu Java então… (o cara escreveu uma versão do emacs) Vale lembrar que Java não foi feito de maneira alguma para o mundo Enterprise. A linguagem foi concebida para sistemas embarcados, para rodar em aparelhos de TV.
Bom, já disse que Java não foi concebida para tanto, basta checar sua história em qualquer fonte, e por favor, o verdadeiro mundo dos code-monkeys é o mundo M$ Visual Basic e ASP.
Java se destaca e muito no mundo científico, vai até em sondas para Marte
Como não?? O que uma coitada de uma linguagem pode contra um verdadeiro code-monkey??? (Claro, o mundo Java não está livre desta espécie)
Nossa… intercambiável por causa da sintaxe pouco expressiva de Java ou por causa de toda a segurança que você citou? (Claro que estou sendo irônico).
Já encontrei muita gente certificada que não sabia absolutamente nada de Java ou de programação em geral. Inclusive eu tenho uma das certificações que fiz por ter conseguido de graça e estar em casa esperando uma semana para começar a trabalhar em um novo emprego. Posso dizer, responder a prova para programador Java não te qualifica como desenvolvedor de nada.
Não cabe aos desenvolvedores de software, os programadores que terminem seus cursos de graduação.
Wow… Você fala como se tudo viesse especificadinho, mastigado 50x e sem erros. Como se o fruto da análise fossem diagramas UML executáveis. Na boa, onde você já viu isto funcionar assim??? Isto que você falou é tão descabido, já encontrou outra pessoa que concorde com isto?
Well, software imprevisível só os geradores de números aleatórios devem ser mesmo.
Definitivamente você não provou nada disto aqui.
O poder de expressão de uma linguagem é apenas um de tantos fatores…Escolho Java por: Permitir a programação Orientada a Objetos com a sintaxe mais expressiva em elegante para tal; O melhor SDK da indústria; O melhor ecossistema de soluções free e open source (Apache, Jakarta, Codehaus, etc); Madura: 10 anos além da versão 1.0; Altamente escalável: Basta ver o que os servidores de aplicações aguentam por ai em grandes corporações; As maiores empresas do mercado investem pesado nela: IBM, Oracle, Redhat, Sun; Uma Virtual Machine extremamente sofisticada: Alocação de memória em Java pode ser mais rápida do que em C!; Os IDEs mais sofisticados e poderosos são escritos para desenvolvimento na plataforma Java, menção honrosa para o Eclipse por ser free; Ótimas tecnologias de distribuição: Java Web Start com um dos melhores exemplos; Excelente retro compatibilidade das versões novas com as anteriores; et cetera.
Vale lembrar que C# é um dos maiores tributos a plataforma Java, se inspirou em tudo que deu certo e corrigiu ainda o que podia, pois diferentemente de Java não tinha código legado para respeitar.O dia em que Java morrer é porque teremos uma plataforma melhor em seu lugar, neste caso eu estarei na linha de frente para migrar para esta nova tecnologia.
…
Quando performance deixou de ser relevante?
Que outra plataforma seria esta? .Net? (só para saber, é que no final você acabou não dizendo qual)
Hoje é possível dizer seguramente que Java não apresenta nenhum sinal de ter seus vastos domínios tomados por um concorrente. Pelo contrário, cada ano a plataforma aumenta de tamanho, mais ferramentas surgem, novas especificações (”espec o que???” diriam os microsofteers), mais ótimos projetos de código aberto, mais milhões de dólares em investimentos das grandes empresas, etc.Bom, acho que é isto, tréplicas são bem vindas
Bruno, I’ll bite.
Com o Eclipse! Com a plataforma! Foco toda a minha crítica na linguagem, e você vem usar a plataforma como suporte de argumento.
Adiante.
Você está comparando apenas com C, meu caro.
Você fala em poder de expressão para escrever código OO. E se eu quiser escrever código funcional? E se eu quiser encarar um programa como uma série de manipulações em listas? Python faz isso. Lisp faz isso. Javascript faz isso.
Até em C eu consigo fazer programas onde eu passo funções como argumentos (function pointers). JaL, não. Isso é falta de poder.
Pegue uma lista de objetos S e remova os que possuem o campo “ExpireDate > Today()” e ordene por FabricationDate. Faça isso em uma linha (ou duas) em Java.
Em Perl, é possível fazer isso de 18 maneiras diferentes. Você vai falar que é feio. E é mesmo. Mas em Python (ou Lisp) é possível fazer isso de forma simples e elegante.
Não exatamente. Design Patterns são necessários para ter reuso de código em problemas comuns aos desenvolvedores. Acontece que os tais problemas não são problemas em algumas outras linguagens. Lê isso aqui, por exemplo
E outra: você tá fundamentando todos os seus argumentos em desenvolvimento OO, como se desenvolvimento OO fosse o Santo Graal da Computação. Não é. Bebeu do Kool-aid?
“We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.” - Guy Steele, co-author of the Java spec.
Esse papo de “concebida para o mercado embarcado” pode ser puro papo de Relações Públicas. A Sun pode até ter tentado, inicialmente, focar a estratégia nessa área. Mas não deu certo. As primeiras versões da JVM eram lentas, e os chips e processadores nem tinham direito memória para rodar a JVM, quiçá as aplicações que iam em cima.
Para não perder o trabalho, continuaram apostando no que tinham, dessa vez usando o mantra da portabilidade e do “É um C++ melhorado”.
Justamente pelo aspecto segurança, não pelo aspecto “poder de expressão”.
Eu jamais faria software de controle de usinas nucleares em Ruby, ou software de controle de transações bancárias em Perl. Isso não quer dizer que Ruby ou Perl deixem de ser mais expressivas do que Java.
No mundo científico, a linguagem mais usada ainda é FORTRAN. Isso torna FORTRAN uma linguagem tão nobre, que merece essa defesa tão religiosa? Eu acho que não.
E, olha só, eu não trabalho com nada disso, graças ao bom Pai. Já tive a minha cota de trabalhar com sistemas operacionais real-time e requisito de “five nines” de disponibilidade, onde nem Java é uma opção.
Lá vem você de novo falando em OO. Tudo bem. De resto, todos os quesitos que você listou também são válidos para Lisp, ou Erlang. Com a diferença que as duas são mais expressivas do que Java.
Isso é argumentum ad populum. Podemos também “dizer seguramente que Windows não apresenta nenhum sinal de ter seus vastos domínios tomados por um concorrente”. Isso faz com que o Windows seja um melhor S.O?
Eu não critiquei a plataforma, critiquei?
Eu falei do poder de expressão das linguagens. No caso, acho que Javascript é muito boa. Python, também. Queria ter mais tempo para aprender Common Lisp, porque Common Lisp já tem (há mais de 35 anos) todas as features que são badaladas nas linguagens “modernas”.
De qualquer jeito, se você realmente quiser uma resposta: não estou tendo surpresas ruins com uma stack LLPP (Linux, Lighttpd, Python e PostgreSQL). É uma combinação que me deixa livre para pensar aplicações sem me obrigar a usar um único “mindset”.
E, se você é tão fanático por Java-a-plataforma, bem que poderia dar uma olhada em JRuby ou Jython. O poder da JVM, sem o fardo de JaL.
Desculpa, passei o link errado na parte de Design Patterns.
Era esse que eu tava procurando.
De qualquer forma, peguei esse link está no blog de um cara que escreve o seguinte, grifos meus:
Why am I learning Scheme? Well, there are a few reasons. (…) I also came across an essay describing design patterns supported by LISP. Many of the patterns I use regularly in Java programs, such as the Visitor pattern, Command pattern, and Iterator pattern, are not needed in LISP: they are built in at the language level. Because of this, I wanted to learn more and, although I have just started, I am sure this is going to make me a better programmer.
Eu escrevo todo um texto sobre o fato que linguagem não é nada, resultado final e design é tudo, e o que eu ganho? uma discussão sobre Java
Confesso que já esperava.
O fato é que esta discussão acaba corroborando um pouco a minha opinião sobre o fato que definir qual a melhor linguagem é algo extremamente complexo. Tem quem prefira concisão e eventualmente usar caracteristicas funcionais para expressar varias idéias em uma linha só (concisão é algo que precisa ser usado com cuidado. Um programa totalmente conciso pode ser facilmente um programa ilegivel). Outros preferem uma linguagem OO mais segura, bem tipada, organizada usando isso como base para uma programação mais estruturada. Acho que isto pode ser aceito sem que se discuta a qualidade dos indivíduos.
Pessoalmente gosto da sintaxe OO do Java (mesmo sendo verbosa), gosto da ideia de JVM com uma API bastante completa. Gosto bem menos do ecossistema que se criou em torno, com J2EE, specs e mais specs, quantidades enormes de XML, frameworks enterprise que querem salvar o mundo…(inclusive a questão do uso de frameworks vs soluções home made ainda vai virar um post). Era mais feliz quando usava só Tomcat e eventualmente servlets, antes de conhecer Hibernate, Spring e EJBs.
A questão é que, tirando certos domínios muito específicos, todas as linguagens citadas pelo Raphael e java são capazes de resolver problemas e de gerarem sw de qualidade. Depende da qualidade do design e do desenvolvedor. Repetindo a máxima deste texto: viva a diversidade! De resto, quem viver verá.
Raphael, vou responder, com calma, mas não hoje
Por hora:
-Acho sem sentido discutir a escolha de Java para um determinado problema sem falar da Plataforma.
-Que Ruby é mais expressivo que java eu nunca discuti, inclusive publiquei em meu blog um script em Ruby que eu fiz. A questão é, esta toda poderosa expressividade de Ruby não o faz competir com Java a plataforma em inúmeros casos, exemplia gratia: sistemas corporativos.
-Agora fanatismo, religiosidade, etc. De minha parte? Sobre Java? Well, eu acho que eu apresentei fatos para corroborar todos meus argumentos, e é assim que eu costumo discutir sempre. Se você discorda de qualquer ponto de algo que eu disse basta apresentá-lo e mostrar-me suas idéias a respeito, agora não me acuse de uma coisa tão baixa quanto um ser fanático ou até mesmo religioso sobre uma determinada ferramenta. A questão não é “eu gosto de Java”, a questão é “eu digo que a plataforma java é boa por X, Y e Z, sendo XYZ não argumentos subjetivos, mas fatos concretos, todos.”. Pode até ser que no calor da discussão eu não tenha argumentado alguma coisa, mas certamente é a menor parte de meu texto.
Mas me permita parar por aqui, mais tarde vou publicar uma resposta completa sobre cada um de seus pontos.
PS: Eu não resisto, você disse não conseguir passar ponteiros para função em Java, cara, ouvir isto me dá arrepios! O que é passar um objeto com um único método público? Algo melhor que um ponteiro para função! Pois este objeto tem estado próprio, são seus atributos, que são inclusive persistentes as invocações do método, melhor ainda, este estado não é global!!! Então o conceito de passar ponteiros de função em java não só possível como tem pelo menos duas grandes vantagens! (sem religiosidade, pois acabei de listar as duas). Estou falando até apenas de Java como linguagem. E antes que ofendam minha inteligência, eu sei que Java não é uma linguagem funcional, assim como não é Python ou Javascript.
Miguel, acabei não publicando aqui, mas achei seu post ótimo e concordo plenamente com seus pontos.
Quanto aos frameworks, specs e specs, servidores de aplicação que querem dominar o mundo. Tente fazer por conta própria o que um JBoss ou Websphere fazem ao receber centenas de invocações por segundo: criar e gerenciar pool de objetos, tratar de invocação remota, persistir objetos válidos em disco e trazer de volta quando necessário, operar em cluster!
É isto que a tão malhada spec JEE faz, seus componentes ganham isto tudo e muito mais por um preço que fica barato quando você de fato precisa fazer uso destes serviços (e é ai que fica o pulo do gato, saber quando isto tudo é necessário). Claro, muitas coisas são especificas de um Servidor de Aplicação ou outro, afinal é assim que eles ganham seus mercados.
O erro foi um bando de (lideres técnicos e gerentes)-monkeys quererem tranformar toda e qualquer classe java em um EJB.
Ai muita gente entrou no barco de que era assim que se programa em JEE, quando na verdade apenas a menor parte das operações de uma aplicação precisam fazer uso de todos os serviços do seu servidos de aplicações.
Eu me lembro em 2003 quando um colega colocou uma aplicação que rodava em um JBoss em cluster! Não precisou escrever uma linha de código, foi só configurar o servidor de acordo, e de acordo com ele foi bem fácil. Imagine colocar uma aplicação em cluster apenas reconfigurando a mesma sem um servidor de aplicações?!? (Observação: esta feature do JBoss não é coberta pela spec, eu sei
É isto que a tão malhada spec JEE faz, seus componentes ganham isto tudo e muito mais por um preço que fica barato quando você de fato precisa fazer uso destes serviços (e é ai que fica o pulo do gato, saber quando isto tudo é necessário).
Talvez seja isso que mais me incomode no ecossistema J2EE: tem se uma tendência de sempre se achar que precisamos de todos os serviços supracitados. Mata-se pulga com bomba atomica. Você dirá que é culpa das pessoas, não da ferramenta. Verdade. Em geral é. Eu te direi que meu problema é justamente com as pessoas.
Era feliz com o Tomcat, justamente porque ele me oferecia exatamente o que eu precisava: servidor web. O resto, fazíamos nós mesmos sob medida, com ótimos resultados. Desenvolvemos varios sistemas de processamento de dados genomicos, processando muito dados (tanto em quantidade quanto em tamanho de arquio) submetidos por muita gente. Talvez seja romantismo da minha parte, mas muitas vezes prefiro ter maior controle sobre o que eu faço em detrimento de uma certa comodidade. Mas ja estou saindo do assunto. Esta questão ainda vai virar um post.
Ps: Eu ja montei um cluster em JBoss. Muito bom de fato.
M
Bruno,
desculpe, mas a sua forma de argumentação é de alguém que trabalhou muito tempo com uma tecnologia, domina-a e depois acha que tudo ficou óbvio. Não é bem assim.
Por exemplo:
você disse não conseguir passar ponteiros para função em Java, cara, ouvir isto me dá arrepios! O que é passar um objeto com um único método público?
Eu não disse isso em lugar nenhum. Eu disse que não tem suporte direto da linguagem para passar funções como argumentos*. Em C, isso é possível, e o esquema para tanto chama “function pointers”. Se você tiver interesse, tem descrição online.
E “passar um objeto com um único método público” NÃO é a mesma coisa, sinto muito. Em Python, Lisp, Javascript, é só passar o nome da função, ou definir a função anonimamente. É teoricamente a mesma coisa, mas no caso de Java, eu tenho que definir o objeto fora para depois passar como argumento.
* Tirado de algum canto do mundo.
Q:How should I pass a function as an argument (in Java)?
A:It depends on what you’re trying to do. The basic answer is “you can’t”. However, there are a couple of ways to get functionality that’s similar to passing in a method in other languages.
1) You can pass a java.lang.reflect.Method. This is pretty close to passing a function pointer, but probably a bit slower and you’re likely to end up doing contortions to get everything to work the way you want.
2) You can define an interface that has a method with the appropriate signature, and pass an instance of a class which implements that interface. java.lang.Runnable is a good example: there are a lot of APIs which take a Runnable, and call run() on it. They’re used by doing something like: SwingUtilities.invokeLater(new Runnable() {
public void run() {
// do something here.
// you CAN reference member variables (being careful with threading)
// and final local variables in this inner class).
}
});
Which instantiates an anonymous class that implements Runnable, and passes it into invokeLater, which queues it up and later the event thread calls run() on this object. This idiom is common in some parts of the API (Swing, threading), and gets you pretty close to most uses of function pointers.
Desculpe se você entendeu que eu estou falando que você é fanático. Só atente para o ponto do quanto a sua argumentação só faz sentido para alguém que JÁ escolheu Java (linguagem ou plataforma). Para alguém que chega sem opinião nenhuma, isento e buscando superar alguma deficiência que sinta em outras linguagens, há muito a ser considerado.
E cuidado com a idéia de achar que você está apoiando toda a sua defesa em fatos. Procure por “Get the Facts” no Google e você vai entender.
Ah! Eu sei que você falou de piadinha, mas a parte de “software imprevisível” não se resume a gerador de números aleatórios. Vamos definir assim: imprevisível é qualquer software que ainda não tenha atingido confiança e robustez suficiente para eu fornecer o número do meu cartão de crédito.
O orkut (C# + ASP.NET) é um software “genial” mas “imprevisível”. Possui muito valor, apesar dos bugs malucos (contagem de mensagens no scrapbook), erros diversos (geralmente causado por excesso de tráfego e algum bottleneck na rede) e até mesmo falhas de segurança.
O Youtube (Python) também. O Reddit (Lisp, depois Python) também passou por isso.
Raphael, eu argumentei meus pontos, se descorda de algum basta colocar seu ponto de vista, não fique puxando para o lado subjetivo dizendo que acho óbvio isto ou aquilo. Vamos conversar em torno de fatos.
Eu usava ponteiros para função em C em 1998 em trabalhos para faculdade.
Realmente, não são a mesma coisa, passar um objeto em Java é muito melhor pelos pontos que eu já levantei anteriormente. Aliás polimorfismo em OO é em grande parte uma automatização da manipulação de ponteiros para função suportado pelo compilador ou VM. Ou seja, para obter um bom reuso de código antes do paradigma OO, muito se fazia manualmente a manipulação de ponteiros de função.
Justamente, não é a mesma coisa, e quando você precisar realmente de só uma função, a sintaxe de Java permite isto com facilidade, basta fazer o método ser estático, e ainda com static imports (desde Setembro de 2004) você pode usar este método (em termos de sintaxe) como uma função escrita em C, Python, Ruby, etc.
Detalhe, em Javascript toda função manipula um objeto ou cria um novo. Por exemplo:
function foo() {
this.x = 10;
this.y = 20;
this.addToX = new function (value) { this.x += value; };
}
someObject = new foo();
Invocar uma função sem usar o operador
newfaz com que ela se referencie ao objeto do escopo de sua execução. Se você usar o operadornewé a mesma coisa só que com um objeto novo que o interpretador de JS irá criar.Javascript é uma linguagem muito bem Orientada a Objetos com uma sintaxe bem elegante, porém não baseada em classes como Java, C++, Ruby e Python mas sim em protótipos, conceito também utilizado no ambiente Self que foi largamente inspirado em Smalltalk.
Isto foi mais para dizer que em JS uma função é mais que uma mera função em C, ela sempre tem um objeto ao qual se refere e pode inclusive fazer coisas como adicionar atributos ao mesmo.
Mais uma coisa, em Java você poderia ter o seguinte:
Runnable doIt = new Runnable() { //Obviamente a interface deve ser escrita antes, estou usando Runnable apenas como um exemplo
public void run()
{
}
};
Tá ai o seu ponteiro para uma função. Convenhamos, não é um código absurdamente mais verboso, é?
E ainda dá informações suficientes para o seu IDE fazer navegação de código (ir para classe base, encontrar usos da função, etc) e Refactorings. Bom, java falei tudo que eu queria sobre este tema aqui.
Nós não nos conhecemos, então você não tem a obrigação de saber o que eu penso sobre muitas coisas em termos de desenvolvimento de software mas eu posso dizer que em 14 de
Abril de 2005 eu já publiquei meu interesse (que já era anterior a esta data) em outras linguagens e/ou plataformas de desenvolvimento, provando que eu não “já escolhi java” e não tenho a mente fanaticamente fechada para outras tecnologias. Aja vista também o que eu já escrevi sobre Ruby e Python em diversos outros posts.
Bom, a porta está aberta para você contestar qualquer ponto de vista meu, desço até em detalhes se você quiser, mas por favor, critique alguma coisa concreta que eu disse ao invés fazer estes comentários tão abrangentes que se tornam em nada construtivos para a discussão.
Ai, Dio…
Percebeu que a discussão está caminhando justamente para o ponto que deveríamos evitar?
Em última análise, TODAS as linguagens são possíveis de se fazer QUALQUER tipo de construção lógica. Se não fosse assim, elas não seriam Turing-Complete, tampouco mereceriam o nome “Linguagem de Programação”.
Mas o que para você uma construção lógica que “convenhamos, não é algo muito mais verboso”, para mim é uma limitação que eu não quero (ou melhor, não sou obrigado a) aguentar.
No fim das contas, é uma escolha subjetiva. E minha escolha defnitivamente não é uma linguagem onde para passar uma função como argumento eu tenho que saber que “basta fazer o método ser estático, e ainda com static imports você pode usar este método”. Eu não quero ter que aprender o método daquela linguagem para poder usar um conceito muito mais abstrato (no caso, lambda calculus). Eu só quero passar uma função. Aplicar um “map” em um vetor. Filtrar por alguma condição determinada.
É o tipo de coisa que, se você realmente quiser precisar fazer para o seu programa, sempre vai ter alguém que vai falar “é só fazer isso”, “é só fazer aquilo”, “é só editar o arquivo blahblahblah.xml e usar a interface XYZ-Scrabble”. Eu não quero isso. Eu quero evitar isso.
Frameworks, então, nem me fale. O Miguel sabe o quanto eu ODEIO frameworks, justamente pelo fato das tais frameworks serem uma compilação de “é só fazer isso, desse e desse jeito.” Eu não quero uma ferramenta que me obrigue a entrar no mindset dela para que eu possa desenvolver qualquer coisa banal. Eu quero uma ferramenta auxiliar. Por exemplo, eu não quero um framework para fazer mapeamento O-R. O que eu quero é uma lib que eu possa jogar uma consulta SQL e obter uma lista de registros. Só! Acho que isso me dá mais controle sobre o design.
Você bate em C(++). Pode bater. Não tenho dúvida de que JaL é tem mais construções auxiliares do que C ou C++.
Entretanto, até 2 meses atrás, se alguém falasse “C é uma porcaria.”, eu responderia: “Como linguagem, é uma porcaria. Tem muito a desejar mesmo. Mas é o que paga o meu salário. E enquanto eu estiver aqui e não for pago para portar o produto para Erlang, é com essa porcaria que eu tenho que lidar.”
Por que é tão difícil falar o mesmo para JaL?
O wordpress não está exibindo minha última resposta…
Eu não disse que Java era melhor linguagem, apenas discordei de todos os pontos que você escolheu criticar na linguagem, basta ler minha primeira resposta.
Eu acho que a escolha de uma ferramenta está muito, mas muito longe de ser subjetiva, não é como escolher a cor de um carro, tem ferramentas com características mais adequadas para um problema ou outro, e sim, isto leva em consideração a plataforma, do contrario vira um exercicio mental sem aplicação prática alguma.
O import estático de java que te assustou tanto é require do Ruby, o include do C, import do Python, etc. Não tem nada de: “é só fazer isso”, “é só fazer aquilo”.
Agora não gostar de frameworks… Já ouvi falar da síndrome do “Not made home”? Aquele lance de reinventar a roda. Well… Ainda nesta linha anti-frameworks, vc faria um sistema web em Ruby sem usar o Rails? Mesmo usando o Rails tem muita receitinha de bolo para seguir, como era de se esperar eu eu acho bem normal.
E não dá para discutir Java a linguagem, java é uma plataforma, só se desenvolve em java usando a plataforma, não faz sentido este exercicio teórico que diz “Vamos imaginar que java seja apenas um compilador e uma VM, esqueça todo o resto…” Para que serviria isto?
Resumindo, eu apenas discordei de suas criticas à Java como plataforma E linguagem, não vi nenhuma argumentação forte para nenhum dos pontos apresentados.
Na boa, isto tudo se faz em Java e muito bem e desde que você não use um notepad, o problema de verbosidade deixa de existir.
Eu deveria só ter desbloqueado o seu comentário, e não respondido mais nada. Se Java é a sua blub, more power to you.
Mas como eu não aguento “também”, olha só:
- Eu falei do lance da necessidade de design patterns que existem em linguagens como C++ e Java por falta de features, by design, e você deu o contra-argumento padrão de quem já se acostumou a ter que lidar com isso.
- Eu falo da necessidade de IDE’s complexas para qualquer coisa em Java, devido a verbosidade, e você fala “mas se você não usa Notepad, isso não é um problema.” Viu a lógica circular de argumentação?
Python, Perl, C, Lisp; todas essas linguagens eu consigo programar usando Emacs. Java, não. O problema é meu, do Emacs, ou da linguagem?
- Aí você fala:
tem ferramentas com características mais adequadas para um problema ou outro, e sim, isto leva em consideração a plataforma, do contrario vira um exercicio mental sem aplicação prática alguma.
Eu não disse justamente que Java é interessante pro pessoal de mercado enterprise, onde nenhum dos fatores que eu critico são relevantes?
Exercício que poderia servir de Dojo que o Sorô tinha proposto.
Isso é um programa completo em C# 3.0:
static void Main(){
var numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };
var sum = numbers.Where(x => (x % 2) == 0).Select(x => x * x).Aggregate(0, (x, y) => x + y);
Console.WriteLine(”Sum: {0}”, sum);
}
Qual o equivalente em Java?
Cara, programas de 5 linhas não entram em produção, não vão lhe dar $$$.
O equivalente em java disto eu faço em minutos, sem falsa modéstia, é factível de ser feito muito rapidamente.
Detalhe, poucas linhas de código não significam que o código pode ser escrito rapidamente, o Quicksort é um algoritmo extremamente enxuto que levou anos para ser confeccionado. (Mas é claro que o código que você colocou de exemplo ai é mega simples)
Não usar IDEs hoje em dia só é sensato por falta de opção, quando existe opção é como andar de carroça do lado de um porsche.
BTW, eu já usei Emacs como ambiente de desenvolvimento em 2002, para java inclusive, não se compara com qualquer IDE moderno. O sistema checava o status dos clientes em Bureaus de crédito, usava apenas o SDK, servidores com Sockets, etc. Usando apenas emacs e Ant. E olha que eu vinha de um projeto para a Bolsa de Valores usando Visual Age. (Minha mente não estava tão fechada na bolha me parece).
Design Patterns você queria acreditar ou não são sim independentes de linguagem, vc vai escrever um compilador em Ruby, Python? Certamente vai usar um Visitor. Outros mais populares como Observer/Observable você vai usar em programação de eventos, Template method? Muitas vezes, independente da expressividade da linguagem. I could go on and on… usando exemplos dentro do próprio Rails ou projetos grandes em Python…
Sobre o seu código ainda, eu já publiquei em meu blog sobre LINQ em Outubro e Novembro de 2005, já publiquei sobre Ruby, Python, Nice, C#, Lisp, Orientação por Objetos, Design Patterns, LISP, AWK, etc. Me parece uma bolha de interesses um tanto quanto volumosa, não?
Entendi que você disse que Java é interessante (eu diria bem mais que isto) para o mercado de aplicações Corporativas (eu diria bem mais que isto). Legal, estamos de acordo.
Eu também não falei mal de nenhuma linguagem o tempo todo (pelo menos não que eu me lembre hehe). Apenas discordei de seus pontos negativos em relação a Java e citei vantagens de Java sobre outras plataformas. Meu discurso não foi “Python/Ruby/Earlang/Oz/Mozart são ruins”.
Mas eu sei que compartilhamos o interesse e admiração por diversas linguagens de programação (exceto Java talvez na parte de ‘admiração’ hehe).
Raphael,
não vou acrescentar nada interessante à discussão, apenas fiquei curioso … para você, qual é a menlhor linguagem em seu ponto de vista?
Sorô
Acredito que cada uma das plataformas citadas tem sua devida contribuição no mundo de desenvolvimento de software e resolvem bem os problemas para os quais são aplicadas, no seu nicho. É importante ter sempre em mente (como já foi citado), que nós desenvolvedores de software, devemos sempre buscar as tecnologias que resolvem os problemas do dia-a-dia de uma forma mais clara e legível, não deixando nossas tendências por uma ou outra plataforma de desenvolvimento falar mais alto.
Particularmente, posso dizer que tenho uma certa tendência pela plataforma Java, principalmente pelos argumentos já utilizados pelo Bruno (ótima capacidade materializar modelos OO, bibliotecas e componentes open source disponíveis, IDE’s, ferramentas, frameworks) que, a meu ver, cumpre com um dos objetivos da plataforma, que é cada dia mais facilitar o desenvolvimento de sistemas, além de ser simples, clara, legível.
Sobre os constructos previamente citados, como list comprehensions, closures, C# delegates, lambda expressions, encontrados em Python, Ruby, Erlang, acho muito interessantes e permitem criar abstrações com poucas linhas de código, mas acho que nada agregariam na plataforma
Java neste momento (comenta-se muito a introdução de closures no Java 1.7 Dolphin), por exemplo, pelo fato de trazer aumento de complexidade à plataforma (o que acredito que já ocorreu com a introdução de Generics, eu já falei sobre isto anteriormente).
Como devem saber, muitos querem a reificação de tipos genéricos, ou seja, determinar os tipos parametrizados de um objeto em runtime. Pensa-se até em quebrar a compatibilidade binária do Java. Acho tudo isto desnecessário neste momento, os problemas surgidos com tais modificações superariam os benefícios, na minha opinião.
Com relação ao paradigma funcional, mais precisamente Erlang, não posso opinar a fundo, pois não sou muito conhecedor, mas até mesmo quem trabalha no google tem dificuldade de fazer a leitura do código, justamente pelo fato da não-existência do conceito de classes
Pô, Sorô…
Não tenho uma opinião de “melhor” linguagem. O que eu tenho, entretanto, é uma listinha de features que eu gosto de ver em linguagens de programação:
- First-Class functions: Javascript, Python, Ruby, Lisp, Ocaml, Haskell, Erlang
- Não me restrinja a um úm único paradigma (eu uso OO quando e se isso for útil): Javascript, Python, Ruby, Lisp, Ocaml, Haskell, Perl
- Inferência de tipos (facilita para seu código ser copiado e chupado livremente de um lugar para outro, sem a obrigação de refactoring): Python, Ruby, C# (3.0), Lisp, Perl, Erlang
- Garbage Collection, pq ninguém mais precisa ficar manipulando memória (essa é obrigatória para qualquer linguagem moderna): Java, JS, qualquer uma que vá em .NET, Lisp, Ocaml, Haskell, Python, Perl, Ruby, Erlang…
- Interpretador disponível para eu ir jogando “snippets” de código e ir moldando uma função, ou testando alguma coisa: JS (+ Firebug), Python, Ruby, Lisp, Ocaml, Perl, Erlang.
E existe uma coisa que, pelo que eu sei, só Python, Ruby e Lisp fazem: permitir que você possa manipular a Abstract Syntax Tree (metaprogramming em Python, Macro System em Lisp). Essa é uma coisa que eu não coloco na minha lista porque eu ainda não senti necessidade de usar - embora exemplos de coisas úteis a ser feitas com isso não faltem.
Escolhi trabalhar com Python pq, como você pode ver, ela passa em todos os meus pontos da minha listinha. Junte isso à filosofia do “batteries included” (a falta de bibliotecas maduras e bem documentadas é o maior impedimento para Lisp) e ao fato de ter uma performance aceitável (ao contrário de Ruby, que ainda está muito lenta) e eu tenho uma linguagem em que eu não me sinto limitado.
Bruno,
eu sei que você é capaz de fazer o programa em Java. Não duvido disso. Mas o que eu sou capaz de apostar é que o seu programa vai (a) usar mais linhas de código e (b) precisar usar outras construções lógicas no lugar do {WHERE, SELECT, AGGREGATE}.
O meu ponto é o seguinte: se com um programa simples assim já encontramos coisas que JaL precisaria usar mais linhas e demonstrou a falta de certas “capacidades”, imagina num programa grande?
Eu não sei você, mas o pouco que eu mexi com Java foi suficiente para eu passar com situações onde eu pensava coisas como:
- “Ah, se eu tivesse um foreach, isso ficaria mais fácil.” (a última versão de JaL já faz esse, mas levou muito tempo, e só fez depois do C#)
- “Ah, se eu tivesse usando uma linguagem que não me OBRIGASSE a declarar tudo em objetos, essa construção seria mais enxuta”.
- “Ah, se eu pudesse fazer operator overloading desse método, o código ficaria mais limpo para quem fosse ler”.
São coisas pequenas, aparentemente banais. Eu sei. Sei também que você tem a resposta para contornar cada um desses problemas.
Mas esse tipo de coisa vai acumulando. São 5 linhas a mais que você escreve hoje, uma interface que você tem que adicionar amanhã, algum método que você tem que encapsular depois, é um arquivo de configuração que você usa XML para processar (para compensar a falta de data-is-code) depois de amanhã…
Quando você vai ver, o programa - que poderia ser conceitualmente mais simples - acaba virando uma monstruosidade de getters e setters (que não fazem nada além de getFoo(){return this.foo;} ), classes, interfaces, arquivos XML de configuração… até chegar no ponto em que passamos mais tempo lidando com o overhead do que realmente adicionando features e valor ao produto.
Para quem vive de salário, tudo bem. Para quem vive de vender problema (grandes empresas de consultoria e auditoria), tudo bem. Não importa o quão veloz ele seja capaz para conseguir uma solução, o pagamento dele vai ser o mesmo. Contanto que o sujeito não seja incompetente a ponto de colocar o emprego dele em risco, o dinheiro pro leitinho das crianças está garantido.
Para quem vive de vender solução (startups, pesquisadores, empresas de produto), não pode ser assim. O tempo que o cara tem para desenvolver tem que ser unicamente voltado para produzir valor. Qualquer overhead é um obstáculo perigoso. Qualquer sobrecarga que não te ajude a oferecer algo mais valioso para o cliente deve ser eliminada.
Falando nisso, deixa eu encerrar esse post, que eu ainda tenho que voltar para o batente.
Ao Raphael Lullis e Bruno
li por alto oq vcs veem comentando aki … achei umas coisa muito legais outra naum..
acho que tudo comeca bem depois tudo se mistura e se perde a linha do pensamento…
linguagens sao ferramentas para cada caso teremos uma linguagem mais adequada..
vcs falaram basicamente de c , c++ , java .. . ferramentas de script etc..
eu naum sou um profundo conhecedor de c nem c++ mais gostaria de lembrar que c++ foi criado pra suprir a deficiencias de c..
c eh uma otima linguagem mais pra pequenos sistemas / solucoes ..
ferramentas de script sao otimos pra executar pequenas tarefas satelites..
quanto a programadores java serem rotulados de code-monkeys eu sinceramente
acho que todos somos… no ponto que naum criamos tecnologia soh usamos…
acho interessante o ponto de expressividade… c eh mais expressivo que java ? depende do ponto de vista… depende do uso… na maioria dos casos naum… e sistemas… pra quem tah fazendo um driver pra uma placa de video c eh muito bom… mais assembly eh mais expressivo…
Bruno da Silva
Javascript, Python e Ruby não são linguagens funcionais. E pelo que eu já discuti com Miguel (que estudou mais Python do que eu) Python teria apenas uma maneira estática de manipular funções.
Como eu disse Javascript, Python e Ruby não são linguagens funcionais. Veja se as mesmas tem as caracteristicas presentes em Haskell ou Erlang.
Isto prova que você nunca usou alguma ferramenta para automação de refactorings como Eclipse ou IntelliJ IDEA (o melhores IDEs para Java). Ter ou não inferência de tipos em nada afeta sua necessidade ou não de fazer refactorings. Vide a definição de refactoring que eu citei em minha primeira resposta.
Sobre o faltou dizer o mesmo para Java já que existem muito mais projetos que geram código para a JVM do que para a plataforma .NET.
Novamente faltou Java ai, o projeto Beanshell existe pelo menos desde o ano 2000.
De LISP eu sabia, agora eu desconheço o fato de Python e Ruby também permitirem isto.
Bom, pelos últimos benchmarks que eu vi Python ainda é bem mais lento que Java.
Açúcar sintático por si só nunca vai vencer toda uma plataforma madura e estável como Java é hoje.
Cara, temos sistemas gigantescos surgindo escritos em Java a cada mês que passa. É muito mais do que possível fazer grandes sistemas com uma linguagem OO estaticamente tipada e com as sofisticadas ferramentas como temos hoje, mais do que possível, é uma realidade.
Cara, o
foreaché só um açúcar sintático! Você não pode estar falando sério. Ainda mais qualquer IDE gera o código para umfor(;;)tradicional com 1 tecla de atalho (no Eclipse digite for e entãoCtrl+space).O overhead por tudo em Java ser sintaticamente uma classe é tão, mas tão pequeno.
Não foi a toa que operator overloading foi elegida como uma característica do C++ a não ser inclusa na linguagem. Pessoalmente usar métodos tradicionais deixa o código muito mais claro.
Cara, uma interface, um método encapsulado, primeiro que você só faz isto em Java se quiser.
E eu não vejo como usar interfaces possa ser um impedimento para produtividade, elas estão exatamente entres o pilares para o uso de Polimorfismo em um modelo Orientado a Objetos!
O que tem um arquivo de configuração a ver com Java como simples linguagem ou plataforma? Pois ambos não precisam de XML nenhum para funcionar.
Não cometa o erro de criticar a ferramenta por algo construído com ela.
Cara, o Eclipse ou qualquer outro IDE fazem e refazem isto em segundos. E na boa, não adiciona complexidade alguma no código, melhor ainda lhe fornecem uma camada de indireção para o acesso ao seus dados. Mas eu até entendo que este seja um ponto polêmico, mas nunca ao ponto de acabar com a produtividade de alguém.
Classes, interfaces, overhead??? Realmente você ainda esta preso no arcaico paradigma procedimental que todos sabemos, desde a década de 80, não escala para sistemas com centenas de milhares de linhas (que é um número bem razoável para qualquer sistema corporativo por exemplo, hoje em dia)
Não entendi, você fala como se a vida de qualquer um que não esteja em uma Startup possa
comportar os horríveis overheads de usar classes e interfaces, getters e setters.
Colocado desta maneira apenas as startups tem uma necessidade urgente de produzir valor,
nas demais empresas apenas classes e objetos, interfaces…
Startups são apenas empresas novas, em termos de desenvolvimento de software tem as mesmas necessidades de qualquer grande empresa.
Numa Startup ou vivendo de salário os desafios de se fazer software bem feito são os mesmos.
Bom Raphael, pelo que você falou é possivel notar que não lhe agrada muito o paradigma de modelos Orientados a Objetos, e é apenas mais um entre milhares que por não entender muito bem OO acha que usar Java te obriga a programar em OO, confunde completamente sintaxe com semântica. Pude ver isto quando você disse .
Usar uma sintaxe OO não te faz criar um bom modelo polimórfico, com alto grau de reuso logo uma boa manutenção.
Assim como poder em termos de sintaxe criar funções não faz o seu código seguir corretamente as diretivas da decomposição funcional.
Java só te obriga usar a sintaxe OO e como eu já publiquei em meu blog, com um overhead muito pequeno.
Bruno, nos conversamos sobre Python e eu afirmei que Python tem todos os aspectos de linguagens funcionais. Podem ser consideradas portanto como multiparadigmas.
Python is a multi-paradigm programming language (functional, object oriented and imperative) which has a fully dynamic type system and uses automatic memory management; it is thus similar to Perl, Ruby, Scheme, and Tcl.
Em particular, as funções são first-class objects SIM, assim como em Javascript. Não sei Ruby.
So relembrando a definição:
In computing, a first-class object (also value, entity, and citizen), in the context of a particular programming language, is an entity which can be used in programs without restriction (when compared to other kinds of objects in the same language).
In computer science, a programming language is said to support first-class functions if it treats functions as first-class objects. Specifically, this means that the language supports constructing new functions during the execution of a program, storing them in data structures, passing them as arguments to other functions, and returning them as the values of other functions. This concept doesn’t cover any means external to the language and program (metaprogramming), such as invoking a compiler or an eval function to create a new function.
Realmente Miguel, pesquisando melhor constatei o que você disse, em Python é de fato possivel manipular funções desta maneira. Um explo interessante aqui http://zephyrfalcon.org/weblog2/arch_e10_00610.html#e610
Bruno, eu estava lendo a tua resposta, e confesso que fiquei encafifado com a parte final.
Bom Raphael, pelo que você falou é possivel notar que não lhe agrada muito o paradigma de modelos Orientados a Objetos, e é apenas mais um entre milhares que por não entender muito bem OO acha que usar Java te obriga a programar em OO, confunde completamente sintaxe com semântica. Pude ver isto quando você disse Não me restrinja a um úm único paradigma.Usar uma sintaxe OO não te faz criar um bom modelo polimórfico, com alto grau de reuso logo uma boa manutenção. Assim como poder em termos de sintaxe criar funções não faz o seu código seguir corretamente as diretivas da decomposição funcional. Java só te obriga usar a sintaxe OO e como eu já publiquei em meu blog, com um overhead muito pequeno.
Primeiro que, sem querer tomar as dores do Raphael, inferir que ele não entende bem de OO baseado na troca de mensagens aqui me parece algo meio sem nexo. Não existe nenhum elemento que permita chegar à esta conclusão.
Mas tem algo que me incomoda mais.
Usar uma sintaxe OO não te faz criar um bom modelo polimórfico, com alto grau de reuso logo uma boa manutenção.
Obviamente, estamos todos de acordo: usar C, ou Java, ou qualquer outra coisa não faz automaticamente de você um bom programador. Usar Java não faz de você um bom programador OO. Mas pelo o que eu entendi, você está dizendo que Java apenas te força a usar a sintaxe OO, mas não forçosamente o paradigma OO. Estou certo? (Java só te obriga usar a sintaxe OO e como eu já publiquei em meu blog, com um overhead muito pequeno).
Muito bem: isso implicaria que Java pode ser utilizado para outros paradigmas. Certo? Bom, o único possível seria o paradigma procedimental. Funcional nem por decreto. E daí eu te pergunto: qual a vantagem de usar Java para programação procedimental? Afinal como você mesmo disse, seria um paradigma atrasado e que não escala.
Outro ponto em relação à não escalar. Tenho minhas dúvidas se esta regra pode ser utilizada sem restrições. Talvez OO escale mais facilmente. Mas como você mesmo disse, usar Java ou OO não quer dizer forçosamente usar um bom modelo OO. Entao usar Java não quer dizer forçosamente criar sistemas que escalem facilmente. Qual o elemento que falta aí? Bons arquitetos e bons desenvolvedores. E aí voltamos ao ponto: na mão de gente boa, qualquer coisa fica boa.
Um exemplo bem claro pra mim de bom sistema procedimental é o kernel do linux. Sem falar na quantidade gigantesca de código escrito em Cobol que roda em bancos e Mainframes há anos e anos. Não estou advogando a volta a estas tecnologias, longe de mim, mas acho que o argumento “roda a muito tempo de forma estavel” vale pra muitos sistemas e linguagens diferentes.
Em relação a dizer que funcional é um paradigma que não escala, etc…eu nunca desenvolvi sistemas grandes usando linguagens funcionais. Mas gostaria de apontar que existem vários artigos por aí de gente interessante discutindo a questão do paradigma funcional ser extremamente apropriado para as novas arquiteturas multicores e paralelas hoje em dia, pelo fato de programas funcionais não terem efeito colateral, estado global e todas estas maravilhas que são fontes de dor de cabeça de desenvolvedores.
É importante ressaltar também que um dos principais artificios utilizados pelo Google para processar a sua enorme quantidade de dados de forma rapida é usar a estratégia Map Reduce, que é uma estratégia classicamente funcional. Portanto, este papo de escalabilidade precisa ser revisto
Bruno, posso deixar o pessoal da IBM falar por mim?
Eu entendo OO. E já trabalhei com análise e modelagem OO mesmo desenvolvendo em C. Mas, olha só: a linguagem não ajuda! Como ela não possui construções lógicas/sintáticas que te permitem definir objetos, encapsular comportamento, etc, etc, é muito mais árduo fazer isso em C. Não quer dizer que é impossível, apenas quer dizer que é mais árduo.
Em Java, a mesma coisa. O que pra você é açúcar sintático, eu chamo de recurso que aumenta a capacidade de expressão. Você defende uma linguagem que te obriga a sintaxe OO, e usa a defesa que o overhead é pequeno. Dane-se. Eu quero uma linguagem que me dê sintaxe OO e sintaxe funcional e closures e qualquer outra coisa que eu sentir que pode me ajudar em capacidade de expressão.
O que parece é que você se recusa a compreender que eu (1) fiz uma crítica às escolhas feitas para a linguagem, (2) às consequências derivadas dessas escolhas e (3) entendo que essas escolhas não foram à toa, que elas servem a algum propósito, mas que não são os meus propósitos.
O que JaL tem a oferecer, eu não quero. Agora, o que JaL NÃO oferece, eu quero. Capisce?
Performance? Dane-se! Python é mais lento que Java? Sem dúvida. Mas performance pura não importa hoje em dia. Hardware hoje já é tão barato que pouco importa se eu tenho que ter 1, 2 ou 3 máquinas para rodar o sistema. O que não pode é ter uma plataforma tão lenta que me obrigue a comprar 20 ou 30, que seria o caso do Ruby. Questão de ordem de grandeza.
Mais importante: depois que eu tenho um sistema geral, projetado, eu posso arquitetar a coisa para otimizar. Se eu tiver uma função muito lenta rodando no servidor de aplicação, posso transformar em uma procedure no banco de dados, por exemplo. Mas isso é uma otimização. Enquanto eu estou na fase de design, isso não é importante. Na fase de design, eu quero passar o mais rápido possível do conceito para código executável.
Miguel, rapidamente vamos aos pontos:
-Realmente dizer que está preso ao paradigma OO por usar uma linguagem que tem sintaxe OO eu considero um erro crasso, ao ponto de dizer que realmente a pessoa está equivocada *demais*.
Fazer um bom modelo OO *mesmo quando você está querendo* já é complicado e requer muito estudo e dedicação.
Imagine alguém te dizer que usar python te obriga a usar expressões lambda? Bom, no caso de OO e sintaxe o engano é maior ainda. Mas ninguém te a obrigação de estudar e/ou gostar de OO, outros paradigmas estão ai para nos servir.
Calma lá, eu não falei que é um programador bom ou ruim. Eu disse que *usar Java não te faz usar OO corretamente*.
Certíssimo.
É toda vantagem que você leva usando o paradigma procedimental, muita gente só usa ele mesmo. Eu pessoalmente acho ele extremamente inferior ao paradigma OO (e poderia falar horas sobre isto), o problema é que OO adiciona uma complexidade muito maior ao seu código, exige muito mais do desenvolvedor, mas isto é contrabalanceado com um código mais reutilizável, que por consequência será mais fácil de manter e terá uma vida mais longa.
Levando isto em consideração, somente sistemas de uma certa complexidade valem a pena ter o esforço para um modelo OO empregado. Eu particularmente uso OO para tudo que não sejam scripts. E mesmo aplicações pequenas ficam bem elegantes quando este paradigma é utilizado.
Mas entendo que para certos problemas talvez seja um tiro de canhão para uma mosca.
Aliás, o paradigma procedimental é o que eu mais vi aplicado na minha experiência com sistemas web corporativos.
–
if intanceof’s a torto e a direito;–Tomadas de decisão em cima do estado interno de objetos;
–Classes gigantescas;
–Nenhum uso de polimorfismo;
–Variáveis com um escopo enorme;
–etc;
Tudo apesar da sintaxe OO de Java.
-Eu disse que OO permitiu com que os sistemas pudessem ter mais de centenas de milhares de linhas (de forma manutenível), escalabilidade com relação a *complexidade* e *quantidade de código* e não performance. (“centenas de milhares de linhas“)
-”“roda a muito tempo de forma estavel” vale pra muitos sistemas e linguagens diferentes.”
Claro que vale, se eu dei a entender o contrário em algum momento errei ao me expressar.
Sobre COBOL ter milhões de linhas escritas por ai, well, isto por si só não diz muita coisa, ao passo que as qualidades de Java que eu já citei aqui são numerosas. (Fora que COBOL não é uma linguagem de propósito geral, não é nada expressivo e muito verboso).
Mas é isto, acho que a confusão maior ai foi a questão da escalabilidade.
Sei que minhas opiniões são deveras fortes para algumas questões, mas eu seria falso de outra maneira. Eu mesmo prefiro aqueles que me criticam aos que me adulem (como diz tanto o político G.Alckmin). Prefiro que gritam, discordam de mim na minha cara e me mostrem seu ponto de vista do que os que ficam calados me julgando em silêncio.
Só espero não me tornar tão cedo persona non grata aqui
Enquanto eu acabo de ler o artigo da IBM enviado pelo Raphael:
The fate of reduce() in Python 3000
Well, eu posso estar errado mas dito isto e sem
lambdasme parece que o criador de Python não pensa muito em usá-lo como uma linguagem funcional. (lembrando que este paradigma está longe de ser meu forte).Este artigo da IBM http://www.ibm.com/developerworks/library/l-prog.html prova definitivamente que Python não foi feito para programação com todas as características do paradigma funcional.
Vou postar nos próximos dias em meu blog o porquê desta minha opinião em detalhes.
Faltou o link para o texto do Guido falando do
reduce(): http://lambda-the-ultimate.org/node/587Não, Bruno, por favor.
Primeiro entenda o lance de first-class functions. Depois, a opinião. Já basta um opinionated motherfucker solto por aí: moi.
Enquanto alguém puder escrever
for number in [x*x for x in range(1000) if x.isPrime()]: print number, " é um número primo elevado ao quadrado."Você vai estar lidando com funções anônimas, map e filter. Não é só pq ele quer tirar a palavra-chave que a funcionalidade foi perdida.
Que mais…
- Como você mesmo disse, não é a linguagem que vai fazer com que o cara aprenda a modelar direito o seu sistema em OO. Nunca isso foi posto em disputa. O que é posto em disputa é que há outras linguagens que fazem tudo que você faz em Jal E oferecem outros recursos, outras niceties. Ou seja, do mesmo jeito que você diz que COBOL não é nada expressivo, há de se olhar JaL não é a linguagem mais poderosa nesse quesito. Você, experiente em Java vai achar bizarro um cara que diga “com o COBOL.NET eu tenho uma plataforma madura e estável e posso fazer tudo isso que vocês fazem usando blah, blah, blah”. Eu, experiente em porra nenhuma (um tico de C, vai) mas curioso por linguagens de mais alto nível, acho bizarro você defendendo “com o Java eu tenho uma plataforma madura e estável e posso fazer tudo isso que vocês fazem usando blah, blah, blah”.
- Procure pelo caso da empresa que desenvolvia jogos para Playstation, em Lisp!!, e fazia isso tão bem que foi comprada pela Sony (ou uma empresa de games maior, não lembro). Veja o relato do cara contando o que aconteceu com a qualidade da equipe depois que eles foram obrigados a portar todo o código deles para C++, para que o “código deles pudesse ser reaproveitado pelos outros membros da empresa”. Resumo para você: ao abrir mão de uma ferramenta mais poderosa, jogaram fora TODA a vantagem competitiva que tinham.
- Startups e empresas consolidadas tem desafios diferentes na questão de software. Empresas consolidadas já tem o seu negócio definido e estabelecido. Startups, por contraste, estão tentando criar um novo negócio. O cara assalariado (ou o consultor) recebe para implementar algo que já se tem uma idéia definida - “Eu quero um software que faça controle de temperatura de um açougue e me gere relatórios em Excel”, “Eu quero uma stack de protocolo de comunicação SIP que atenda 100 mil usuários simultâneos”.
Uma startup, quase sempre, não sabe como vai resolver um problema muito mais geral: “Minha idéia é desenvolver um sistema que permita vídeos online facilmente acessíveis”, “minha idéia é um software que rode no celular para indicar onde os seus amigos estão localizados”, “eu quero um site que permita micro-crédito entre pessoas dispensando o sistema financeiro (bancos e financeiras)”.
Para esses caras, pouco importa se há sistemas todo mês com centenas de milhares de linha surgindo. Para esses caras, esses sistemas monstruosos são as aberrações que eles não querem e não podem ser. Eles têm que ser o Davi para o proverbial Golias.
E a melhor forma de vencer os gigantes é sendo mais rápido do que eles, adicionando recursos mais rápidos do que eles, ou redefinindo o mercado onde você e seus concorrentes estão atuando.
Bruno, Lullis,
Apenas um comentário menos importante e paralelo à discussão de vocês, vindo de alguém que trabalha na IBM.
O artigo do developerWorks que vocês comentaram não é da IBM e nem mesmo foi escrito por alguém da IBM.
O site do developerWorks sim é mantido pela IBM, mas é um espaço aberto para qualquer pessoa postar idéias e artigos. É claro que eles passam por um processo de aprovação antes de serem publicados, mas existe uma quantidade enorme de artigos lá que não foram escritos por gente da IBM.
Aliás, está aí um espaço legal para vocês postarem idéias estruturadas em artigos sobre questões técnicas que vocês enfrentam. O developerWorks em geral é bem quotado em buscas no Google e os artigos costumam ser muito bons (e não falo isso por trabalhar na IBM; já conhecia o developerWorks bem antes).
Em relação à discussão de vocês, confesso que estava enfadado com ela, especialmente até lá pelo décimo quinto post… Estava parecendo mais uma discussão “religiosa” do que propriamente uma argumentação técnica. Acho que a folga que me dei de alguns dias antes de voltar a ler os seus comentários me fez apreciar mais o assunto sendo discutido e acho que o nível melhorou nos últimos comentários.
Mas, meu humor a parte, sinceramente, eu acho que os dois pontos de vista são válidos e, pelo que eu consigo ver, ambos transparecem dificuldade de enxergar a realidade vivida pelo outro. O Lullis está focado em uma visão baseada em startups, que lidam com projetos menores, menos controlados e mais audaciosos no seu conceito; enquanto o Bruno está mais ligado com aquilo que é necessário em grandes empresas, que lidam com projetos mais complexos, com muito mais controle e, em geral, não tão inovadores assim. Dificuldade que não significa incapacidade: acho que os dois tem boa noção dos dois mundos, só estão defendendo o ponto de vista pelo qual vocês mesmos vêem o mundo. Eu, particularmente, acho ambas as visões válidas, só depende do contexto sendo focado. E, ainda mais: acho que existe uma falta de entendimento generalizada no mercado (não de vocês) sobre as duas realidades, que sempre vão coexistir.
Quanto à discussão das linguagens em si, sinceramente, isso pouco me importa. Particularmente eu não tenho linguagem preferida e nunca trabalhei por um longo período de tempo só com uma linguagem. No fundo, acho que todas tem boas vantages e todas tem grandes problemas (pelo menos nisso acho que todos nós concordamos
)
Léo, obrigado, obrigado, muito obrigado…
Como eu já havia respondido ao Miguel, realmente Python tem realmente First-class functions. Bom em discussões como é esta é realmente sair aprendendo algo
Correto, mas você há de convir que o pai do Python condenando estas funções é um sinal forte de que Python está longe de ter sido concebido como uma linguagem funcional. Ademais isto também ficou claro como água com o artigo que você mesmo mandou publicado na Alphaworks.
Eu também sei que os expression generators vieram justamente para melhorar a legibilidade para este tipo de declaração de funções anônimas, logo as mesmas não são condenadas por Guido.
Raphael, preciso insitir veementemente, o que uma linguagem/plataforma pode fazer ou não, se é general purpose ou não, não é questão de gosto! Mas é sim algo passível de ser constatado. Vamos pegar apenas o Cobol que eu citei como exemplo(não uma versão .NET), ele não é general purpose, não dá para fazer qualquer tipo de aplicação no COBOL clássico que tanto roda nos Mainframes mundo a fora.
Você não tem que achar bizarro o que eu falo sobre Java, não confie na minha opinião, basta checar os argumentos sobre os quais eu sustentei isto. Falar dos pontos bons ou ruins de qualquer ferramenta é uma discussão objetiva e não religiosa ou pessoal.
Entendi a história mas não sei o que isto tem haver com o que eu tenho defendido aqui. Eu tenho defendido Java de suas acusações a partir de sua primeira resposta. Que LISP pode ser usado com sucesso em soluções inovadoras você sabe melhor do que eu que Paul Grahan defende isto com unhas e dentes há muitos anos, mas eu mesmo nunca falei o contrário.
Você enveredou por defender algumas linguagens como se eu as tivesse criticado, como Python e LISP, mas eu mesmo já postei em meu blog meu uso pessoal de Python (e mais) e mesmo LISP me interessou e interessa ainda demais.
O desafio da inovação que uma startup enfrenta por definição está presente em qualquer outra empresa, quer ela entenda isto ou não, pois qualquer empresa corre o perigo constante de ser desbancada por uma grande idéia, seja esta idéia implementada por uma startup ou qualquer outra empresa.
Eu sinceramente acho que nenhum bom desenvolvedor de software queira fazer sistemas aberrações como você mesmo disse, o meu ponto é estando em uma startup ou não eu quero sempre produzir software da melhor maneira possivel, seja procurando novas ferramentas/paradigmas/etc.
Ai você está assumindo como premissa que o Java é menos produtivo, o que sinceramente você não conseguiu mostrar, o fato de Java como Plataforma não ter inferência de tipos ou expression generators não o faz menos produtivo do que Java.
Eu já citei inúmeras vantagens da plafatorma java: (listando novamente abaixo)
->Permitir a programação Orientada a Objetos com a sintaxe mais expressiva em elegante para tal;
->Excelente SDK da indústria;
->Excelente ecossistema de soluções free e open source (Apache, Jakarta, Codehaus, etc);
->Madura: 10 anos além da versão 1.0;
->Altamente escalável: Basta ver o que os servidores de aplicações aguentam por ai em grandes corporações;
->As maiores empresas do mercado investem pesado nela: IBM, Oracle, Redhat, Sun;
->Uma Virtual Machine extremamente sofisticada: Alocação de memória em Java pode ser mais rápida do que em C!;
->Os IDEs mais sofisticados e poderosos são escritos para desenvolvimento na plataforma Java, menção honrosa para o Eclipse por ser free;
->Ótimo mecanismo de distribuição: Java Web Start com um dos melhores exemplos;
->Ótima mecanismo de para garantir a segurança de aplicações distribuidas pela rede;
->Excelente retro compatibilidade das versões novas com as anteriores;
->et cetera.
Estas são todas características fáceis de serem compravadas, não são minha opinião, não são argumentos subjetivos ou religiosos ou até mesmo de um fanático por java, são caraterísticas que simplesmente existem. Eu adicionei adjetivos a elas como “Excelente” sim, mas é fácil descer em detalhes em todas elas para que eu lhe mostre o porque do “Excelente”.
E para resumir minha opinião: Eu estudo novas tecnologias, paradigmas e ferramentas esteja eu em um empreendimento como uma startup ou sendo um assalariado. Meu interesse e dedicação para evoluir como desenvolvedor de software é o mesmo em qualquer um dos casos.
laggarcia,
Concordo com a última frase de seu último parágrafo mas eu creio que uma uma boa idéia possa ser implementada em Java em um esquema startup sem perder em nada para qualquer linguagem dinâmica que existe atualmente, basta saber como
Poderia ser implementada em Python com igual produtividade? Creio que seja possível (embora, em certo casos, eu não veja isto claramente).
O meu ponto nunca foi diminuir outras linguagens, mas diante do que foi apresentado eu creio que Java não perde em nada para as alternativas citadas. O meu ponto foi simplesmente refutar as ditas desvantagens de Java levantadas aqui.
PS. No meio do caminho também quis deixar claro que:
-Python não é uma linguagem funcional, nem a definição encontrada no site oficial diz isto “Python is a dynamic object-oriented programming language that can be used for many kinds of software development”.
-Usar uma sintaxe OO não lhe faz programar em OO;
-O dito overhead da sintaxe OO de java é desprezível;
-A niceties sintáticas de python não o tornam uma plataforma mais produtiva do que Java;
-Não me lembro mais
Bruno, sinto muito. Você tá respondendo com a medula. Pensa no que o Léo acabou de falar, com calma.
[C]reio que uma boa idéia possa ser implementada em Java em um esquema startup sem perder em nada para qualquer linguagem dinâmica que existe atualmente, basta saber como.
Eu posso falar isso de Visual Basic. Eu posso falar isso de Clipper. Eu posso falar isso de Lisp. Eu posso falar isso de Assembler. Aliás, eu posso falar isso de QUALQUER linguagem.
Não sei você, mas justamente pelo fato de QUALQUER linguagem ser possível de se fazer QUALQUER coisa quando “se sabe como”, eu acabo procurando uma filosofia, um propósito que justifique o investimento de se aprender uma linguagem de programação. Se são todas iguais, para que mudar? Eu continuaria com C, ou Pascal. Seria mais fácil.
Mas mudo, pela filosofia e pela “comunidade”. E não gosto de nenhum dos princípios que servem como base do design de JaL.
Perl tem como filosofia “making easy things trivial, hard things easy, and impossible things possible”. Ou seja: dê poder ao programador, e ele que se vire para utilizar esse poder com responsabilidade.
JaL não foi projetada para ser uma linguagem que desse poder absoluto ao programador, é só ver pelas motivações para justificar a remoção de Operator Overloading. Qual a filosofia dos seguidores de Java? “O pessoal de Perl é tudo um bando de cheira-cola que escreve código que eu não consigo ler depois. Precisamos de uma linguagem que limite o poder desses caras de fazer código incompreensível.”
Você vai dizer que não é. Vai dizer que é ter uma linguagem com sintaxe OO elegante. Isso também é uma questão subjetiva. Eu vou dizer “elegante o escambau.”
Não há argumentação aqui que vá fazer com que cheguemos em um acordo.
Você está tão preocupado em fazer uma defesa de Java que começou a racionalizar tudo: tacou questões de plataforma (as quais nem falei nada), performance, paradigma de desenvolvimento, código “manutenível”.
O que você NÃO entendeu é que a sua “defesa” de JaL não resolve os problemas que eu senti quando trabalhei com Java. E propor uma forma de contornar um problema identificado NÃO é o mesmo que RESOLVER o problema.
Falar que “um objeto com um único método é o mesmo que passar uma função (ou até melhor” NÃO RESOLVE o problema que eu não tenho first-class functions”. Falar que Operator Overloading foi banida da spec de Java pq era vista como elemento de confusão NÃO RESOLVE o problema que eu posso precisar/querer usar operator overloading. Falar que a sintaxe OO não te obriga a desenvolver em OO NÃO RESOLVE o problema quando eu quiser adicionar uma função auxiliar, fora de um objeto. Falar que a IDE compensa a verbosidade NÃO RESOLVE o problema da verbosidade. Falar que tem um projeto para fazer um interpretador de JaL NÃO RESOLVE o problema, pq o bendito interpretador não tem autocomplete ou whatever, então tudo que eu vou ter é um interpretador de uma linguagem verbosa.
Eu não estou procurando uma linguagem puramente de paradigma XYZ ou que seja sancionada por alguém como a coisa mais linda e perfeita em termos de teoria de computação. Eu quero uma linguagem que resolva os problemas que eu falei. Uma linguagem que permite passar funções como argumentos RESOLVE um problema: ela possui first-class functions, e eu posso usar isso quando é útil. Uma linguagem que não me obrigue a tacar tudo dentro de um “class” RESOLVE o problema de me deixar ter uma função fora do objeto e usá-lo, quando isso for interessante. Uma linguagem dinâmica RESOLVE boa parte das questões de polimorfismo e operator overloading.
Então, se o GvR disse uma coisa ou não, se o site oficial diz que é funcional ou não, isso pouco me importa. O que importa é que a linguagem resolveu problemas. Como linguagem, acho ela melhor projetada do que Java (e PHP, Perl, Visual Basic e muitas outras).
Mas eu não quero ficar num pissing contest. Se você é feliz com Java-a-linguagem, more power to you. Eu não era, nunca fui. Sinto-me preso e limitado. Pode até ser que eu venha a trabalhar em algum lugar onde eu tenha que lidar com código Java, e vou trabalhar e tentar aprender a contornar os problemas que eu identifico. Mas, contanto que eu tenha o poder de escolha, Java é carta fora do baralho.