Viva a diversidade!

September 27, 2007

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).

tags:
posted in Uncategorized by Miguel Galves

Follow comments via the RSS Feed | Leave a comment | Trackback URL

View Comments to "Viva a diversidade!"

  1. Raphael Lullis wrote:

    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.

  2. Miguel via Rec6 wrote:

    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…

  3. O legal de um blog como o log4dev… « Log4Dev wrote:

    [...] 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, ó. [...]

  4. Miguel Galves wrote:

    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”.

  5. Bruno wrote:

    Responder o Raphael me tomará um tempo que eu não terei nesta agitada sexta-feira. Amanhã eu respondo :)

  6. Bruno wrote:

    Minha resposta:

    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.
    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.
    A força de JaL é que é uma linguagem segura,
    Você deve estar se referindo ao falta de aritmética de ponteiros, a presença de um Garbage Collector, Null pointer exceptions, Array index out of bounds exceptions… 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).
    mas isso resultou em perda de poder.
    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?
    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.
    Acredite, em Java o seu ponteiro para void é simplesmente uma variável do tipo Object (claro, sem artimética de ponteiros ou tipos primitivos e outras restrições).
    No espectro de capacidade de expressão, até C é mais poderosa do que JAL.
    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).
    Se olhar, muitas “técnicas” de engenharia de software acabam sendo criadas para compensar essa falta de capacidade de expressão.
    Exemplos…?
    JaL tem uma série de problemas por ser estritamente OO e não permitir certas construções lógicas e sintáticas?
    Quais problemas? Quais construções lógicas e sintáticas??
    Design Patterns neles.
    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?
    JaL tem dificuldade para fazer programação bottom-up? Refactoring, Refactoring, Refactoring.
    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.
    JaL é muito verbosa e precisa de 20 linhas para um programa básico? IDE’s com geração de código a caminho…
    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 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,
    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.
    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.
    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.
    Para o pessoal enterprise-y, isso está ótimo.
    Java se destaca e muito no mundo científico, vai até em sondas para Marte :)
    É uma linguagem segura, onde se tem confiança que o programador não é capaz de fazer grandes estragos num codebase
    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)
    e, mais importante, o desenvolvedor passa a ser uma peça intercambiável.
    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).
    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).
    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.
    No mercado enterprise, não cabe muito ao programador a parte de bolar a solução.
    Não cabe aos desenvolvedores de software, os programadores que terminem seus cursos de graduaçã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.
    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?
    No mercado enterprise é preferível um programa “medíocre” e “confiável” a um programa “genial” mas “imprevisível”.
    Well, software imprevisível só os geradores de números aleatórios devem ser mesmo.
    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.
    Definitivamente você não provou nada disto aqui.
    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.
    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.
    JaL, como é, vai morrer (como C++) ou ter que se adaptar continuamente (como C#).
    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.
    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
    Quando performance 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.
    Que outra plataforma seria esta? .Net? (só para saber, é que no final você acabou não dizendo qual)
    Viva a diversidade? Ok. Mas temos que saber que a natureza elimina os menos aptos.
    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 :)

  7. Raphael Lullis wrote:

    Bruno, I’ll bite.

    Particularmente com o Eclipse eu uso Java até para scripting, ainda tenho o melhor dos dois mundos

    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.

    Java sim tem um ótimo poder de expressão para escrever código OO. (…) 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?

    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.

    Quais construções lógicas e sintáticas??

    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.

    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 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?

    Se você não considera o James Gosling um hacker na época em que escreveu Java então… (…) A linguagem foi concebida para sistemas embarcados, para rodar em aparelhos de TV.</
    “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”.

    Java se destaca e muito no mundo científico, vai até em sondas para Marte.

    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.

    Permitir a programação Orientada a Objetos com a sintaxe mais expressiva e 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.

    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.

    Hoje é possível dizer seguramente que Java não apresenta nenhum sinal de ter seus vastos domínios tomados por um concorrente.(…)

    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?

    Que outra plataforma seria esta?

    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.

  8. Raphael Lullis wrote:

    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.

  9. Miguel Galves wrote:

    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á.

  10. Bruno wrote:

    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.

  11. Bruno wrote:

    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 ;)

  12. Miguel Galves wrote:

    É 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

  13. Raphael Lullis wrote:

    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.

    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.

  14. Raphael Lullis wrote:

    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.

  15. Bruno wrote:

    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.

    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.

    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.

    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.

    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.

    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 new faz com que ela se referencie ao objeto do escopo de sua execução. Se você usar o operador new é 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.

    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.

    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.

    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.

    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.

  16. Raphael Lullis wrote:

    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?

  17. Bruno wrote:

    O wordpress não está exibindo minha última resposta…

  18. Bruno wrote:

    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.

    Eu só quero passar uma função. Aplicar um “map” em um vetor. Filtrar por alguma condição determinada.

    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.

  19. Raphael Lullis wrote:

    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?

  20. Raphael Lullis wrote:

    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?

  21. Bruno wrote:

    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).

  22. Alexandre Barbosa wrote:

    Raphael,

    não vou acrescentar nada interessante à discussão, apenas fiquei curioso … para você, qual é a menlhor linguagem em seu ponto de vista?

    Sorô

  23. Raphael Lullis wrote:

    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.

  24. Rafael Naufal wrote:

    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 :-)

  25. Bruno da Silva wrote:

    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

  26. Bruno wrote:

    - First-Class functions: Javascript, Python, Ruby, Lisp, Ocaml, Haskell, Erlang

    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.

    - 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

    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.

    - 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

    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.

    - 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…

    Sobre o qualquer uma que vá em .NET 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.

    - 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.

    Novamente faltou Java ai, o projeto Beanshell existe pelo menos desde o ano 2000.

    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).

    De LISP eu sabia, agora eu desconheço o fato de Python e Ruby também permitirem isto.

    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.

    Bom, pelos últimos benchmarks que eu vi Python ainda é bem mais lento que Java.

    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}.

    Açúcar sintático por si só nunca vai vencer toda uma plataforma madura e estável como Java é hoje.

    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?

    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.

    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#)

    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 um for(;;) tradicional com 1 tecla de atalho (no Eclipse digite for e então Ctrl+space).

    - “Ah, se eu tivesse usando uma linguagem que não me OBRIGASSE a declarar tudo em objetos, essa construção seria mais enxuta”.

    O overhead por tudo em Java ser sintaticamente uma classe é tão, mas tão pequeno.

    - “Ah, se eu pudesse fazer operator overloading desse método, o código ficaria mais limpo para quem fosse ler”.

    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.

    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,

    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!

    é um arquivo de configuração que você usa XML para processar (para compensar a falta de data-is-code) depois de amanhã…

    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.

    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;} ),

    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, 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.

    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)

    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 pagaento 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.

    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.

    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.

    Colocado desta maneira apenas as startups tem uma necessidade urgente de produzir valor, nas demais empresas apenas classes e objetos, interfaces…

    Qualquer overhead é um obstáculo perigoso. Qualquer sobrecarga que não te ajude a oferecer algo mais valioso para o cliente deve ser eliminada.

    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 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.

    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.

  27. Miguel Galves wrote:

    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.

  28. Bruno wrote:

    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/arche1000610.html#e610

  29. Miguel Galves wrote:

    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

  30. Raphael Lullis wrote:

    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.

  31. Bruno wrote:

    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.

    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.

    Calma lá, eu não falei que é um programador bom ou ruim. Eu disse que usar Java não te faz usar OO corretamente.

    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).

    Certíssimo.

    qual a vantagem de usar Java para programação procedimental?

    É 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 :-)

  32. Bruno wrote:

    Enquanto eu acabo de ler o artigo da IBM enviado pelo Raphael:

    The fate of reduce() in Python 3000

    Guido van Rossum comments on the elimination of map(), filter(), reduce() and lambda from Python 3000: So now reduce(). This is actually the one I’ve always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what’s actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it’s better to write out the accumulation loop explicitly. And then, with these functions gone, there is no use for lambdas, he argues.
    Well, eu posso estar errado mas dito isto e sem lambdas me 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).

  33. Bruno wrote:

    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.

  34. wrote:

    Faltou o link para o texto do Guido falando do reduce(): http://lambda-the-ultimate.org/node/587

  35. Raphael Lullis wrote:

    Nã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.

  36. laggarcia wrote:

    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 :) )

  37. Raphael Lullis wrote:

    Léo, obrigado, obrigado, muito obrigado… :)

  38. Bruno wrote:

    Primeiro entenda o lance de first-class functions. Depois, a opinião. Já basta um opinionated motherfucker solto por aí: moi.

    Como eu já havia respondido ao Miguel, realmente Python tem realmente First-class functions. Bom em discussões como é esta é realmente sair aprendendo algo ;)

    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.

    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.

    - 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”.

    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.

    - 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.

    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.

    - 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)”.

    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.

    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.

    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.

    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.

    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.

  39. Bruno wrote:

    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 :-)

  40. Raphael Lullis wrote:

    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.

  41. Bruno wrote:

    [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.

    Discordo em gênero, número e grau. Não dá para fazer qualquer coisa em qualquer linguagem, mas nem vou tentar provar isto (tirando o papo de Turing complete por favor…).

    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.

    Bom, eu já discordo que dê para fazer QQ coisa com QQ linguagem entao nem vou continuar aqui.

    Mas mudo, pela filosofia e pela “comunidade”. E não gosto de nenhum dos princípios que servem como base do design de JaL.

    Não gostar é uma coisa, fazer críticas erradas é outra. Eu acho que você se equivocou muito em suas colocações sobre Java (e me desculpe mas eu não vejo sentido em falar de Java apenas a linguagem).

    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.”

    Cara, nem vou responder isto…

    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.

    Oks, a sintaxe OO de java não é elegante… Vamos ver a declaração de uma interface (um elemento utilíssimo em modelos OO) escrita em C++:

    class AB { public:   virtual void f() = 0; };

    Agora em Java:

    interface AB { void f(); }

    Não só temos menos código, portanto java neste caso é menos verboso como também é mais elegante. Eis os motivos: ->Você usa a palavra chave interface que não deixa espaço para dúvidas do que está sendo criado;

    ->nela todos os métodos são públicos então é irrelevante (porém tolerado) usar a palavra public para os mesmos; ->Nada de virtual ou terminar a declaração com >= 0;

    Agora uma declaração de classe em Python?

    class AB:     def f(self):

            …

    A declaração do self é bem redundante já que você está criando uma classe não?

    Agora em Java:

    class AB {     void f() {     } }

    E não estou falando de verbosidade, mas sim de sintaxe OO elegante mostrando que java não tem elementos OO redundantes e é sim mais clara como foi mostrado no exemplo em C++.

    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”.

    Eu abordei estes assuntos quando você deu usos errados para Design Patters, Refactoring, etc.

    Com relação a falar de Java sem falar da plataforma é a mesma coisa de falar o quando um pneu corre sem falar do carro, falar da parte não faz sentido se ela não vive sem o todo.

    Vamos por partes agora:

    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”.
    Se você realmente usa muiiito isto, OKs concordo contigo que é bom procurar uma linguagem que tenha isto.
    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.
    Nunca vi ninguém gostar tanto de uma feature que mascara ou obfusca o código fonte, mas… idem ao item acima.

    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.

    Disto eu discordo veementemente, o overread de java para você programar com funções apenas é desprezível (nem vou por novamente o link para um post em meu blog aqui).

    falar que a IDE compensa a verbosidade NÃO RESOLVE o problema da verbosidade.

    Resolve sim, como não??? Só não vou fazer um screencast aqui :-)

    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.

    Não sei se eu entendi bem, mas o interpretador de python tb não tem code completion (pelo menos quando usei não tinha). Aliás é dificil fazer code completion em python justamente pela sua inferência de tipos. Você vê? O fato de java não ter inferência de tipos permite que as ferramentas voltadas para ele tenham avançadas features de navegação, refactorings, verificação de código, etc. Perde-se de um lado mas se ganha muito mais do outro, fora que com IDEs nem se sente a verbosidade de java (tem code completion até…).

    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.

    Sua predileção por first class functions eu não discuto, agora o “tacar tudo num class” é bobagem, o overread é desprezível.

    Uma linguagem dinâmica RESOLVE boa parte das questões de polimorfismo e operator overloading.

    Dois equívocos: ->Por linguagem dinâmica entende-se (entre outras coisas) inferência de tipos através de dynamic typing, nenhuma relação com o polimorfismo de OO (uma linguagem pode ser dinâmica sem ser OO). ->Tampouco uma linguagem dinâmica tem algo a ver com operator overloading, (C++ já tinha isto…).

    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).

    Colocar VB ai ofende hein ;)

    Mas, contanto que eu tenha o poder de escolha, Java é carta fora do baralho.

    Sua preferência por Python eu não discuto, só discuto quando você levanta pontos errados sobre Java. Aliás eu gosto muito de ler sobre Python e eventualmente brincar um pouco com ele, assim como com Ruby (que eu prefiro por ter nascido já OO diferentemente de Python), com AWK, Groovy, Nice, Javascript, etc.

    Toda a sua primeira resposta dada ao Miguel está equivocadíssima, de cabo a rabo. Você não acertou em um só ponto naquela primeira resposta, eu diria até que falou vários absurdos, creio eu que baseados em desconhecimento e preconceito contra Java

    E eu ainda nem respondi sua terceira resposta, que pode ser refutada em sua maior parte, mas ai você deu a entender que Python permitia programação funcional… (talvez por causa das high order functions) ai perdemos o foco um pouco.

    E não venha me dizer que você ficou surpreso com a minha resposta, você ofendeu muita gente nas entrelinhas alí, falou que java foi feito para code-monkeys!!! Fala isto para os desenvolvedores do Tomcat ou qualquer projeto da Apache/Jarkarta (e estes são alguns que eu poderia citar).

  42. Rafael Naufal wrote:

    Sobre inferência de tipos, dificuldade de refactoring e verificações de tipos em linguagens dinâmicas segue um interessante artigo.

  43. Raphael Lullis wrote:

    Bruno, já que você tá lendo o que quer, eu proponho um exercício para você: tente você atacar o JaL e defender outras linguagens (que não C/C++. Você ataca olhando pra C/C++, e as outras linguagens para você são “brinquedos”).

    Exemplo: em Java, tem que declarar “classes” e “interfaces”. Em liguagens dinâmicas, não: basta fazer a classe e implementar o método.

    Um outro exercício: tente elaborar uma justificativa (dica: tente entender a dinâmica econômica, oferta e demanda de pessoas e produtos) para o fato que uma linguagem como Java (ou .NET, ou Oracle, ou Delphi) precisa ter bons hackers desenvolvendo frameworks, ao passo que linguagens mais “poderosas” tem hackers acostumados a usar e fazer suas próprias pequenas libs, mais ajustadas ao seus interesses.

  44. Bruno wrote:

    Como lendo o que quer? Eu comentei sua resposta inteira…

  45. Paulo Silveira wrote:

    Raphael,

    o fato que uma linguagem como Java (ou .NET, ou Oracle, ou Delphi) precisa ter bons hackers desenvolvendo frameworks, ao passo que linguagens mais “poderosas” tem hackers acostumados a usar e fazer suas próprias pequenas libs, mais ajustadas ao seus interesses.

    Fiquei curioso para saber onde você baseou esse seu “fato”. Você deve se considerar um bom hacker por isso não utiliza Java, correto? Com esse comentário e um outro sobre code-monkeys você está fechando os olhos para muita gente realmente boa que desenvolve em Java.

    A dinâmica econômica que vejo é que se usa a plataforma java justamente para não se preocupar com problemas resolvidos e utilizar o tempo no desenvolvimento do business, não leve o business apenas para o lado de aplicação empresárial (no próximo parágrafo irei dar um exemplo). Notei que em vários comentários você defende que se quiser fazer algo realmente fun (pesquisa, testes de algoritmos, uma nova idéia, etc) não use java. Acho que você está enganado. Hoje trabalho em uma empresa que pesquisa e que vende o seu resultado no mercado, cujo principal produto é um software para monitorar tráfico de redes em tempo real, o software é feito 95% em java e as novas funcionalidades são feitas em Java.

    Ainda no campo da pesquisa leio vários artigos publicados por revistas ciêntificas de ciências da computação com exemplos e implementações em Java.

  46. Raphael Lullis wrote:

    Bruno, você não respondeu:

    • Você não me mostrou onde e como JaL possui maior capacidade de expressão do que outras linguagens mais modernas (First-class functions, closures… essas coisas que você diz, no seu próprio blog, que são desnecessárias e que devem ficar fora da linguagem). O maior ponto da minha crítica, a capacidade de expressão da linguagem, você trata como algo supérfluo.

      • Onde em sua “resposta de cabo a rabo” você me mostra features que só JaL tem? Se você me der isso, aí você teria uma prova razoável de poder de expressão. E, catzo, não venha usar a JVM como argumento: se vale para JVM, isso quer dizer que eu posso programar em, sei lá, Scala, e aí eu teria o poder da JVM E os recursos de Scala.

      • Design Patterns. Seja realmente “coerente” e “lógico”:

    1) Faça uma compilação de todos os design patterns e implemente-os em C, C++, Java, Python, Ruby e Lisp.

    2) Faça uma análise e veja o quanto alguns desses patterns são diretos nas linguagens dinâmicas, ou nas linguagens que tem os tais do “carboidratos sintáticos”.

    3) Perceba o quanto esses Patterns acabaram sendo catalogados para suprir as deficiências de linguagens OO estáticas.

    4) Pare pra pensar que ninguém da GoF iria ganhar dinheiro se vivessem de livros sobre Design Patterns em linguagens dinâmicas.

    O que enche o saco dessa nossa briga é o seguinte: se você reconhecesse que JaL tem sim limitações, mas que essas limitações não são relevantes para você, não teríamos discussão. Foi unicamente por isso que eu propus o exercício: inverta os papéis e ataque você a linguagem. Se você não conseguir, fica clara a sua visão de JaL como perfeita, livre de defeitos, e aí caímos justamente no tipo de discussão que o Miguel falou no post. Inútil e infantil. Se for pra ficar nesse tipo de discussão tola, prefiro falar de futebol.

    Paulo,

    Você inverteu a lógica. Não é o fato de programar em Python que implica em ser um bom hacker. É o fato de só ser capaz de aprender e lidar com linguagens menos expressivas que indica um sujeito fraquinho.

    Eu disse que a linguagem Java foi projetada com o intuito de ser uma linguagem mais segura que as alternativas da época E que pudesse ser facilmente aprendida, para que a Sun pudesse vender certificações para massas de code-monkeys.

    Traduzindo: não quero dizer que “toda pessoa que programa em JaL é um code-monkey”. Quero dizer, entretanto, que uma pessoa que só programa em Java (ou só programa em C#, ou VB, ou Delphi) e não consegue assimilar conceitos presentes em outras linguagens com certeza não poderá ser chamada de “bom hacker”. E não estou fechando os olhos para quem programa em Java. O próprio Miguel (assim como o Léo e o Sorô) mexem com Java em seu trabalho atualmente, e são pessoas que eu adoraria poder trazer para o meu projeto. Certamente, a proposta que eu faria para eles (trabalhar de graça por um período, em troca de uma minúscula chance de ficar milionário) não é muito melhor do que as propostas que eles já receberam.

    Sobra ainda o conjunto “péssimos programadores que tentam trabalhar com linguagens mais poderosas e complexas”. Esse conjunto, quase certamente, eu me incluo.

    E você tem razão: quem usa Java não quer se preocupar com problemas resolvidos e só quer gastar seu tempo no desenvolvimento do business. Isso em economês seria traduzido para “agregar valor à empresa através da implementação de um conhecimento específico, ao invés de criar um novo conhecimento e um novo mercado”.

    Mas, olha só: pelo que você tá falando, a empresa que você trabalha faz tanta pesquisa quanto o lugar que eu trabalhava antes. Não é apenas pesquisa. É pesquisa orientada a uma solução já conhecida. O seu produto é novo, mas ele veio para solucionar um problema que já foi identificado por outra empresa. Na prática, ainda faz parte do “mundo enterprise”.

    E os que não estão nesse mundo, nem tem esse tipo de prioridade? E os que querem criar um negócio novo mas não tem a menor idéia de qual vai ser o produto final? Exemplo: o pessoal do YouTube começou a trabalhar com a idéia de fazer uma agência de encontros! Qual era o “conhecimento específico” que eles tinham a respeito do produto? Nenhum!

    Você acha que esses caras tem que trabalhar pensando em fazer um plano no MS Project e começar a fazer uma modelagem OO das possíveis entidades que vão fazer parte do sistema deles? Preocupar-se com “boas práticas de programação”? Preocupar-se com escalabilidade? Performance? Claro que não! Tudo isso é secundário quando a pessoa está tentando apenas criar algo que possa chamar a atenção dos consumidores ou de um investidor. Para esses caras, escalabilidade é um “bom problema”, pq é um sinal que o cara já tem seu número de usuários crescendo. Resolver problemas de performance é um “bom problema”, pq é sinal que seu sistema já está sendo minimamente utilizado.

    O difícil é o primeiro usuário. Arrumar alguém de fora que veja valor no seu produto. E para conseguir esse primeiro usuário, muito vai ter que ser alterado, re-escrito, re-projetado, jogado fora, reciclado, muita coisa vai ter que ser adicionada… O que é melhor para eles? Ferramentas que permitam que eles trabalhem de forma mais abstrata possível (poder de expressão) e tenham flexibilidade para mudarem o design rapidamente, ou o fato de contar com “tecnologia há mais de 10 anos no mercado”?

  47. Bruno wrote:

    Raphael, cuidado, você fala como quem conhecesse a fundo como funciona uma startup de sucesso, quando na verdade você nunca participou de verdade deste processo.

    Com relação a Design Patterns em linguagens dinâmicas eu citei logo nas primeiras respostas alguns patterns são utilizados em qualquer linguagem. Você é quem não citou um único exemplo de Design Pattern que já está “embutido” em linguagens Dinâmicas.

    Aparentemente você cada vez mais mostra que não conhece a definição do que faz uma linguagem ser considerada dinâmica, e isto não tem nenhuma relação com o paradigma OO, Funcional, Procedimental, (muito menos com operator overloading) etc. Você ainda não percebeu o tamanho do seu equívoco?!?

    3) Perceba o quanto esses Patterns acabaram sendo catalogados para suprir as deficiências de linguagens OO estáticas.

    Modelos OO não são alterados porque uma linguagem tem checagem de tipos em tempo de compilação ou em tempo de execução! Você mais uma vez prova que não entende muito o que é uma modelagem Orientada a Objetos.

    Mas fique tranquilo que eu vou responder mais tarde todos os seus pontos desta sua última resposta, estou ansioso por isto. (ainda mais quando falar de desenvolvedores “fraquinhos” ou “code-monkeys”)

    Ps. Eu não chamei nenhuma linguagem de brinquedo, eu disse que brinco com linguagens que quero aprender, não é possível que você tenha entendido errado a expressão.

  48. Bruno wrote:

    Muito bem colocados seus pontos Paulo, ver alguém que trabalha no mercado e ainda faz parte do mundo acadêmico (Mestrando) mostrando que Java não é só usado em aplicações de pesquisa por sua segurança, é bem elucidativo para aqueles que não estão vendo a figura toda.

    Será que no mundo acadêmico temos então apenas desenvolvedores “code-monkeys” ou “fraquinhos”?

  49. Fabrício wrote:

    Apenas reforçando o que o Paulo falou:

    “…dinâmica econômica que vejo é que se usa a plataforma java justamente para não se preocupar com problemas resolvidos e utilizar o tempo no desenvolvimento do business, não leve o business apenas para o lado de aplicação empresárial…”

    O meu trabalho de doutorado utiliza conceitos das áreas de Mineração de Textos, Mineração de Dados, Recuperação de Informação e Computação Sensível ao Contexto. Para implementar os meus experimentos eu uso Java. Eu uso Java porque existem inúmeras ferramentas que já implementam diversos algoritmos e funcionalidades que eu preciso. Estas ferramentas são:

    • Weka: biblioteca com diversos algoritmos de aprendizado implementados. Implementada em Java. Free e Open Source.
    • YALE(RapidMiner): uma outra biblioteca com diversos algoritmos de aprendizado, incluindo os próprios algoritmos da biblioteca Weka e algoritmos para manipulação de textos e som. Implementada em Java. Free e Open Source.
    • GATE: plataforma com algoritmos para o Processamento de Linguagem Natural. Implementada em Java. Free e Open Source.
    • LingPipe: biblioteca para o Processamento de Linguagem Natural. Implementada em Java. Free e Open Source.
    • Protégé: editor de ontologias.
    • JEOPS: the Java Embedded Object Production System.
    • Joone: Java Object Oriented Neural Engine.

    Eu não vou reinventar a roda só porque eu quero usar outra Linguagem de Programação (LP).

    A LP é apenas um “martelo”. Alguns martelos servem para pregar alguns tipos de pregos e outros martelos outros tipos de pregos. (Ponto final).

  50. Raphael Lullis wrote:

    Puta merda, Bruno! Lê direito! Pára de ficar se prendendo ao seu conceito de uma idéia, e tenta sair dessa bitola. Pense de forma um só pouco mais abstrata, will you?

    “Design Patterns” => Padrões de Projeto.

    Padrões de Projeto. Pense direitinho: o que significa isso?

    Respondo: são soluções catalogadas para problemas que eram comuns aos desenvolvedores de software. Não importando o domínio de trabalho, desenvolvedores passavam por alguns problemas na hora de implementação. Aí, o pessoal da GoF, espertinhos que só eles, compilaram soluções que eram adotadas e consideradas aceitáveis e chamaram de “Padrões de Projeto”.

    Tudo bem até aqui? Espero que sim.

    Agora eu faço a pergunta filosófica: Se uma árvore caiu no meio da floresta onde ninguém escutou, podemos dizer que ela fez barulho? Ou então: se uma linguagem de programação X oferece recursos built-in para fazer uma construção lógica que em outra linguagem é necessário catalogar a porra da solução, não seria razoável dizer que essa linguagem X elimina a necessidade do pattern?

    Por exemplo: se o Peter Seibel demonstra que em Lisp não precisa de patterns que são usados em JaL, o que é que eu faço? Falo pra ele que ele não “entende OO”? Que ele está equivocado? Ou aceito o fato que alguém que vai usar JaL precisa contornar a limitação da linguagem e aprender como implementar um pattern (ou dois, ou vários) a mais do que um programador de Lisp/Python/Ruby)?

    Posso voltar a tentar tocar a minha startup, essa coisa que eu não sei nada a respeito, ou você precisa me converter para a grande religião do Javaísmo antes?

    Fabrício, se bibliotecas implementadas em Java resolvem os seus problemas, ótimo. Ponto final.

  51. Bruno wrote:

    O pessoal do GoF deixa bem claro no inicio do livro que eles apenas catalogaram os padrões, não entendi porque você os chama de espertinhos. Embora isto não seja um ‘apenas’ e ainda sim muitos destes padrões foram os autores mesmo que desenvolveram.

    Árvores caindo em florestas à parte eu vou ter que ler mesmo o Peter Seibel, porque você até agora só falou em recursos builtin mas não deu nenhum exemplo concreto, ao passo que eu nomei pelo menos 3 patterns que qualquer linguagem pode implementar pois não vem builtin.

    E reitero, os padrões de desenho de modelos OO independem da linguagem destino do modelo, o próprio GoF tem exemplos em Smalltalk e C++, quer linguagens mais diferentes entre si? A única coisa em comum é serem OO mesmo. Inclusive uma é dinâmica e outra não, como é que você me diz:

    2) Faça uma análise e veja o quanto alguns desses patterns são diretos nas linguagens dinâmicas, ou nas linguagens que tem os tais do “carboidratos sintáticos”.
    Smalltalk não tem nada de “carboidratos sintáticos”. Novamente mostrando que você mostrou um entendimento bem falho do que define uma linguagem dinâmica.

    Bom, vou me dar ao trabalho de ler que você me mandou do Seibel para comentar. Agora uma curiosidade o GoF fala de patterns para modelos OO, esta comparação se aplicaria a algum sabor de LISP que suporta o paradigma OO? Porquê senão fica dificil comparar… Como implementar padrões de desenho OO em uma linguagem que não suporta OO?

    Deve ser mais uma comparação de paradigma funcional vs. OO. E eu em nenhum momento disse que um paradigma é melhor que o outro. Pessoalmente acho e já escrevi em meu blog que ambos tem seu lugar ao sol (posso mandar o link para provar). Então eu não sei o que este artigo traria a nossa discussão.

    PS. Ainda vou responder seu primeiro comentário de hoje

  52. Raphael Lullis wrote:

    Se você ver o vídeo que eu te passei, você vai ver que ele fala que (1) Java só faz “single dispatch”, que (2) que Lisp faz multiple dispatch, que (3) fala de como é muito mais direto fazer Visitor Pattern em Lisp, que (4) o fato de ser linguagem estática dificulta a implementação do “generic dispatch” (que é built-in no Lisp graças ao sistema de generic functions), a não ser que use contorcionismos usando Reflection e que (5) Lisp tem CLOS (Common Lisp Object System) há decênios.

    Agora, por favor, vamos dar um reset nessa discussão, que já estamos bifurcando há muito tempo. A trilha que eu segui na primeira resposta foi “Não gosto de Java porque ela limita as escolhas do programador e porque é uma linguagem que quer impor uma disciplina. Eu prefiro uma linguagem que dê ao programador a capacidade de se expressar como bem entender, e ele que sofra as consequências disso”.

    Daí desandamos a falar de plataforma, paradigmas e trocentas outras coisas que não tinham a ver com a minha queixa original. Coisas as quais eu nem me preocupei em falar. Coisas que eu nem ataquei, mas que você se apressou em trazer uma argumentação.

  53. Bruno wrote:

    Eu sei que isto está se arrastando mas eu preciso exercer meu direito de resposta.

    - Você não me mostrou onde e como JaL possui maior capacidade de expressão do que outras linguagens mais modernas (First-class functions, closures… essas coisas que você diz, no seu próprio blog, que são desnecessárias e que devem ficar fora da linguagem). O maior ponto da minha crítica, a capacidade de expressão da linguagem, você trata como algo supérfluo.

    Vamos chegar nisto.

    – Onde em sua “resposta de cabo a rabo” você me mostra features que só JaL tem? Se você me der isso, aí você teria uma prova razoável de poder de expressão. E, catzo, não venha usar a JVM como argumento: se vale para JVM, isso quer dizer que eu posso programar em, sei lá, Scala, e aí eu teria o poder da JVM E os recursos de Scala.

    Você é quem fez um alarde dizendo que Java era uma linguagem para code-monkeys por ter sido concebida com uma sintaxe simples (eu diria elegante). Eu digo que a sintaxe de Java não atrapalha em absolutamente nada a plataforma como um todo. O que Java tem como plataforma excede de longe o que python tem em termos de expressividade. E falando de sintaxe java é muito mais conciso e expressivo do que C++ e até do que python no momento de declarar métodos de uma classe, já que em python temos que repetir a declaração do ponteiro self sempre na assinatura dos métodos.

    - Design Patterns. Seja realmente “coerente” e “lógico”: 1) Faça uma compilação de todos os design patterns e implemente-os em C, C++, Java, Python, Ruby e Lisp. 2) Faça uma análise e veja o quanto alguns desses patterns são diretos nas linguagens dinâmicas, ou nas linguagens que tem os tais do “carboidratos sintáticos”. 3) Perceba o quanto esses Patterns acabaram sendo catalogados para suprir as deficiências de linguagens OO estáticas. 4) Pare pra pensar que ninguém da GoF iria ganhar dinheiro se vivessem de livros sobre Design Patterns em linguagens dinâmicas.

    Já falei sobre isto em meu último post que foi uma resposta parcial e rápida a este. Sua concepção de linguagens dinâmicas é totalmente errônea. Você citou depois o Visitor em LISP utilizando o mecanismo double-dispatch, ainda quero mesmo ver o video que você mandou, mas estou curioso, é só este pattern que você encontrou automaticamente embutido em LISP? (digo LISP apenas porque não faz sentido dizer linguagens dinâmicas aqui)

    Se for só 1 pattern contra os muitos catalogados desde 1994 então acho que tem mesmo é muito pattern por ai que pode ser utilizado em outras linguagens, correto?

    O que enche o saco dessa nossa briga é o seguinte: se você reconhecesse que JaL tem sim limitações, mas que essas limitações não são relevantes para você, não teríamos discussão.

    Não tem generator expressions, fato. Isto faz java uma linguagem inferior? Como plataforma ainda? De maneira alguma! Pois insisto não faz sentido falar de Java como ferramenta para uso real sem considerar sua plataforma.

    Eu ainda estou para ver um argumento que me faça usar Python ao invés de Java para por exemplo sistemas web/corporativos ou mesmo aplicações gráficas stand alone. Mas pode ser que tenha alguma API super útil só implementada em python, que eu precise muito, ai sim teríamos alguma coisa…

    Foi unicamente por isso que eu propus o exercício: inverta os papéis e ataque você a linguagem. Se você não conseguir, fica clara a sua visão de JaL como perfeita, livre de defeitos, e aí caímos justamente no tipo de discussão que o Miguel falou no post. Inútil e infantil. Se for pra ficar nesse tipo de discussão tola, prefiro falar de futebol.

    Eu simplesmente refutei seus argumentos fortíssimos contra Java, baseados unicamente na sintaxe da linguagem. Você levantou grandes equívocos sobre uma ferramenta que eu conheço e Miguel pediu minha opinião a respeito, aqui estamos.

    Paulo, Você inverteu a lógica. Não é o fato de programar em Python que implica em ser um bom hacker. É o fato de só ser capaz de aprender e lidar com linguagens menos expressivas que indica um sujeito fraquinho.

    Me recuso a comentar isto… Ou melhor, vou comentar, que mágica tem em usar as ultra sofisticadas e complexas funções map, filter e reduce? Nada! É simples, e generator expressions? Também não tem nenhuma mágica ai! Garanto que entender o paradigma de modelos orientados a objetos e funcional sim, estes são dificeis de entender, requerem muito estudo e mais dificeis ainda de se dominar! A sintaxe expressiva de python? Mamão com açucar, sinceramente.

    Eu disse que a linguagem Java foi projetada com o intuito de ser uma linguagem mais segura que as alternativas da época E que pudesse ser facilmente aprendida, para que a Sun pudesse vender certificações para massas de code-monkeys.

    Concordo que a indústria de certificações existe e que a Sun explora mesmo este nicho. Culpa dos empregadores que veêm algum valor nisto, hehe.

    Traduzindo: não quero dizer que “toda pessoa que programa em JaL é um code-monkey”. Quero dizer, entretanto, que uma pessoa que só programa em Java (ou só programa em C#, ou VB, ou Delphi) e não consegue assimilar conceitos presentes em outras linguagens com certeza não poderá ser chamada de “bom hacker”.

    Só um comentário aqui, Python não adiciona NENHUM conceito em cima de Java!

    É uma linguagem com inferência de tipos, algo que eu espero que Java nunca tenha, e acredito, não tendo isto Java ganha inúmeras vantagens. Fora isto tem um interpretador mais lento, provavelmente gerenciador de memória menos sofisticado/eficiente e um menor número de Aplicações, frameworks e APIs.

    Nem por isto tenho pouco interesse em python, pelo contrário, sei que existe uma comunidade vibrante por trás desta ferramenta e admiro muitas de suas facetas, mas… para muitos casos acho Java ainda uma ferramenta mais aplicável, para outros acredito que python possa servir melhor.

    Sobra ainda o conjunto “péssimos programadores que tentam trabalhar com linguagens mais poderosas e complexas”. Esse conjunto, quase certamente, eu me incluo.

    Não vi esta complexidade toda em python, não estou conseguindo ver.

    E você tem razão: quem usa Java não quer se preocupar com problemas resolvidos

    Mas quem quer se preocupar com problemas já resolvidos?! Para quê? Reiventar a roda? Você tem todo este tempo sobrando para isto?

    e só quer gastar seu tempo no desenvolvimento do business.

    Não é resolvendo os problemas de negócio que se ganha dinheiro??

    Isso em economês seria traduzido para “agregar valor à empresa através da implementação de um conhecimento específico, ao invés de criar um novo conhecimento e um novo mercado”.

    Mas o que usar java (sem inferência de tipos, generator expressions, map, reduce, filter e lambda) pode impedir a criação de um novo conhecimento e um novo mercado? Percebe como sua lógica tem um exagero tremendo?

    Mas, olha só: pelo que você tá falando, a empresa que você trabalha faz tanta pesquisa quanto o lugar que eu trabalhava antes. Não é apenas pesquisa. É pesquisa orientada a uma solução já conhecida. O seu produto é novo, mas ele veio para solucionar um problema que já foi identificado por outra empresa. Na prática, ainda faz parte do “mundo enterprise”. E os que não estão nesse mundo, nem tem esse tipo de prioridade? E os que querem criar um negócio novo mas não tem a menor idéia de qual vai ser o produto final? Exemplo: o pessoal do YouTube começou a trabalhar com a idéia de fazer uma agência de encontros! Qual era o “conhecimento específico” que eles tinham a respeito do produto? Nenhum!

    Mas Raphael, os problemas existem independente da linguagem de programação usada para a construção de sua solução! Que isto tem com Java ou Python?

    Você acha que esses caras tem que trabalhar pensando em fazer um plano no MS Project e começar a fazer uma modelagem OO das possíveis entidades que vão fazer parte do sistema deles? Preocupar-se com “boas práticas de programação”? Preocupar-se com escalabilidade? Performance? Claro que não! Tudo isso é secundário

    Cara, eu realmente acho que os caras do YouTube começaram tudo pensando sério em performance pelo simples fato do serviço deles só ser útil se atender a milhares de usuários o tempo todo.

    quando a pessoa está tentando apenas criar algo que possa chamar a atenção dos consumidores ou de um investidor. Para esses caras, escalabilidade é um “bom problema”, pq é um sinal que o cara já tem seu número de usuários crescendo. Resolver problemas de performance é um “bom problema”, pq é sinal que seu sistema já está sendo minimamente utilizado.

    Bom, ai quando chegamos neste ponto você vai reinventar a roda? Resolver problemas já solucionados? Ou vai usar algo que já está pronto, funciona, etc e tratar de preocupar-se com os problemas dos seus usuários? O problema deles não é ter um servidor web que rode em cluster, o problema destes é colocar seus videos on line. Servidor web que rode em cluster tem o Tomcat ai, feito por colaboradoes que só se dedicam a isto o ano inteiro, neste caso você faria uma solução in house enquanto seus usários migram para o concorrente?

    O difícil é o primeiro usuário. Arrumar alguém de fora que veja valor no seu produto. E para conseguir esse primeiro usuário, muito vai ter que ser alterado, re-escrito, re-projetado, jogado fora, reciclado, muita coisa vai ter que ser adicionada… O que é melhor para eles? Ferramentas que permitam que eles trabalhem de forma mais abstrata possível (poder de expressão) e tenham flexibilidade para mudarem o design rapidamente, ou o fato de contar com “tecnologia há mais de 10 anos no mercado”?

    Problemas de negócio a parte como como conseguir o 1o. usuário fogem do escopo da discussão e nada tem a ver com ela, mas certamente tecnologias estáveis sem dúvida alguma estarão na minha lista! Acima dos tais expression generators. Agora não vejo como inferência de tipos pode ajudar uma pessoa a mudar seu design rapidamente, se é isto mesmo que você quis dizer.

    Se você mudar as operações que uma classe possui com inferência de tipos ou não seu código não vai mais funcionar, a diferença é que em uma linguagem estaticamente tipada como Java estes erros são todos muito bem enumerados pelo seu compilador, e com qualquer ferramentinha com um mínimo de dignidade é só um click do mouse para ir direto ao erro. Ao passo que com linguagens como python este erro só se daria em tempo de execução, é bom você ter Testes Unitários em Python também, uma técnica que nasceu na cultura Java.

    PS. Eu acho os expression generators de python bem legais, só não são nenhuma bala de prata.

  54. Raphael Lullis wrote:

    Bruno, só vou responder todas as suas asneiras depois que você assistir o vídeo. Você quer racionalizar a sua escolha por Java, tudo bem. Não me importo. Trabalhe com o que quiser.

    Mas antes de sair vomitando respostas quilométricas, faça o dever de casa. Todas as coisas que você está falando aí, já foram ditas:

    1) Esqueça a plataforma. Você não precisa de Java-a-Linguagem para ter os recursos de Java-a-Plataforma. Não queira usar a Plataforma como muleta para sua escolha. Escolha, aliás, que nem deve ter sido sua. Sou capaz de apostar que você acabou aprendendo Java por necessidade do mercado, pensando na grana. Não, não estou te julgando por isso. Só estou querendo dizer que são poucas as pessoas que escolhem programar em Java por ver nela uma linguagem com features interessantes. Só escolhe Java quem compara com linguagens “piores” como C, VB, C++, etc.

    2) Pergunta: se você acha que é, no início, tão priotário ter um ambiente estável e com performance quanto uma linguagem mais flexível e que der poder ao desenvolvedor, pq são são tão poucas as startups de sucesso que usam Java? Se a escolha de linguagem é algo irrelevante, não seria de se esperar que não houvesse correlação entre linguagem de desenvolvimento/habilidade do desenvolvedor/nível de risco do projeto/sucesso da empresa?

    3) Tarefa extra: lê isso aí e pára de me encher o saco.

    http://www.ginstrom.com/scribbles/2007/10/08/design-patterns-python-style/

  55. Bruno wrote:

    Raphael, uma resposta parcial e rápida: No link que você passou sobre desing patterns em python, o primeiro que o autor descreve, o Iterator, está totalmente errado!!!. Não quero nem ver o resto… Mas faço questão de passar por todos eles mais tarde.

    Motivação para o pattern Iterator [GoF]:

    An aggregate object such as a list should give you a way to access its elements without exposing its internal structure.
    Aplicação [GoF]:
    Use the Iterator pattern:   * to access an aggregate object’s contents without exposing its internal representation.   * to support multiple traversals of aggregate objects.   * to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

    Olha a explicação simplória do cara:

    Iterators are built into the Python language. Anything that is iterable can be iterated, including dictionaries, lists, tuples, strings, streams, generators, and classes for which you implement iterator syntax.

    Dizer isto aliás não faz o menor sentido! Java em sua API tem a interface Itarable em todas suas coleções, nem por isto Java tem o pattern Iterator embutido em si, e

    Dizer que python tem estruturas built in que implementam algum pattern não quer dizer que usando python ele já vai implementar em suas classes/estruturas estes mesmos patterns, ou ainda dizer que não haverá nunca necessidade de você implementar manualmente tal padrão de desenho.

    Cara, que equívoco gigantesco este artigo que você mandou!!!

  56. Raphael Lullis wrote:

    nem por isto Java tem o pattern Iterator embutido em si

    The joke is on you, dude.

    for thing in L: try: thing.aMethod() except NotImplemented: pass

    É tudo que eu preciso para fazer tudo que se dá na sua definição do GoF, inclusive support polymorphic iteration. Então, se eu consigo fazer de forma razoavelmente natural usando o idioma acima, para quê, catzo, eu preciso me preocupar com Iterator pattern?

    Não dá pra sacar que tudo isso que você tá colocando – a sua preocupação em me mostrar como é o jeitinho certo de se fazer Patterns, chamar de “equívoco” a definição do cara, etc – é um reflexo do fato de você estar acostumado a pensar as coisas no “Java way of life”?

    Voltando ao ponto inicial, do primeiro comentário: não gosto de Java justamente por querer me impor essa disciplina. O código em Python acima funciona, é direto, limpo e logicamente claro. E, mais importante, ninguém vai falar “você tá sendo burro e não tá usando OO direito”. Ninguém vai querer me acusar de erro conceitual.

    Agora, se eu quisesse fazer isso na sua linguagem favorita? (contribuição do Miguel)

    for(Object o: L){ try{ Method m = o.getClass().getMethod("aMethod"); m.invoke(o); }catch(NoSuchMethodException e){ }

    Com certeza, não é algo que possa ser chamado de “bom código OO”. Para cada ação que eu quisesse adicionar no loop, eu teria que adicionar duas linhas de código.

    Com certeza, em Java (ou C++)você vai querer criar uma interface. Aliás, você é praticamente obrigado. Qualquer pessoa que fizesse isso em código de produção ia tomar um chute no traseiro depois de qualquer code review. Com certeza, você vai querer me dar um sermão sobre o fato de já existir um design pattern que já demonstra a forma “correta” de se fazer um Iterator.

    Olha só: eu não quero aprender isso. Eu não quero ter que me submeter a uma disciplina para começar a expressar uma idéia. Eu só quero demonstrar pro computador rapidamente “cada objeto da sua lista tem que fazer tal coisa, se o objeto for capaz de fazer tal ação”. Isso é o que eu chamo de “poder de expressão”.

    Francamente, me diga: pq é tão difícil você me responder mais ou menos desse jeito:

    • “Pô, Lullis, Java-a-Linguagem tem sim uma série de limitações. Mas se eu pesar os prós (faço aqui uma lista de coisas boas: X, Y e Z) e contras da linguagem e comparar com as linguagens que estavam disponíveis na época, JaL era uma excelente opção. Eu acho que compensou fazer o investimento em aprender e trabalhar com Java”.

    Se sua resposta tivesse seguido esse caminho, não teríamos nenhuma discussão. Mas você tá sendo o language troll, ao querer racionalizar e justificar os problemas da linguagem. Parece coisa de torcedor de time de futebol: olha as virtudes do time quando ganha; quando perde, fica arrumando desculpa ou tentando racionalizar a derrota.

  57. Miguel Galves wrote:

    Caros…depois de quase 60 respostas, considero que esgotamos este assunto, certo?

    Raphael e Bruno: o primeiro que postar mais alguma resposta neste tópico sofrerá as consequencias da maldição do editor do blog que vos fala: 7 anos sem….

    Sem mais, despeço me

  58. Raphael Lullis wrote:

    Miguel, nunca satisfeito… quando posta e ninguém comenta, reclama. Quando posta e comentam, reclamam também. People are so hard to please.

  59. Miguel Galves wrote:

    Comentou e ainda por cima criticou o autor do post. 21 anos sem…

  60. Bruno wrote:

    Raphael, gostaria muito de te responder mas infelizmente o Miguel me proibiu de continuar esta discussão aqui… :)

  61. Raphael Lullis wrote:

    Bruno, vou ser o cara que desautoriza o dono. Responda o quanto quiser.

    Só peço que você veja – com atenção – os links que eu passei, ok?

  62. Turing completeness (Pra que linguagens de programação?) « Log4Dev wrote:

    [...] mais lidos AJAX em 20 minutosGPS + Google MapsViva a diversidade!Otimização de código javascriptMyFaces e Spring Web FlowConcatenação eficiente de Strings em [...]

Leave Your Comment

blog comments powered by Disqus

Switch to our mobile site

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org