Emacs vs Vi, Mac vs Windows vs Linux, Intel vs AMD, OO vs Funcional. Vários temas na Computação são capazes de gerar discussões intermináveis, exaltadas, quase religiosas. Mas atualmente, a que mais me irrita é a interminável discussão sobre qual a melhor linguagem de programação.
Defensores de Java dizem que linguagens de script não aguentam sistemas grandes, estruturados. Defensores de Ruby ou Python dizem que Java é um lixo feito para quem não sabe programar. Amantes de Ocaml, Haskell e Erlang acham o resto do mundo é inferior. Quem não programa em Ocaml, Haskell e Erlang acha que são linguagens exóticas e acadêmicas. Todos acham que .NET é um lixo. Cada um quer mostrar quão melhor é a sua linguagem, como pode fazer tudo o que as outras fazem e muito mais.
É inevitável que uma pessoa acabe ficando mais a vontade com uma ou duas linguagens, aquelas que ela usa no dia a dia. Eu por exemplo considero que minha primeira linguagem hoje em dia é Java. Foi a primeira linguagem séria que eu aprendi, e venho trabalhando com ela comercialmente há vários anos. Mas sinceramente não gosto de ser marcado como Programador Java. Aliás, não gostaria de ser marcado como Programador X, onde X é uma linguagem qualquer. Acho que isso reduz. Me considero um desenvolvedor de tecnologia, de produtos, e assim sendo gosto de sempre procurar uma linguagem que se adeque melhor ao tipo de programa que tenho que escrever.
Tirando Pascal, que aprendi na universidade por motivos didáticos (curso básico de programação), todas as linguagens que eu programei minimamente foram motivadas por motivos práticos. Aprendi Perl quando eu quis escrever um etiquetador de palavras em português: dada uma lista de palavras, ele determinava se era oxítonas, paroxítonas ou proparoxítonas, e se eram mono, bi, tri ou polisilábicas (comecei escrevendo em C, mas rapidamente percebi que seria muito mais rápido e eficiente aprender Perl do que ficar fazendo regexp na unha). Aprendi Python quando precisava de uma linguagem de script clean e bem estruturada para processar arquivos com dados de biologia molecular. Aprendi de fato C quando precisei escrever um captador e analisador de imagens via firewire em tempo real para um sistema embarcado. Descobri o poder de Javascript quando comecei a querer implementar aplicações Web com interfaces ricas, AJAX. Aprendi Java quando quis começar a desenvolver sistemas OO multiplataformas e mais tarde, sistemas web.
Não existem nenhuma tecnologia perfeita. Um bom desenvolvedor tem que saber definir quais características são importantes pro projeto dele, e determinar qual tecnologia é a mais adequada. Temos a tendência a sempre querer usar aquelas que conhecemos melhor. É inevitável. Mas as vezes é saudável analisar outras opções e ver se existem coisas melhores. Sim, coisas melhores podem existir! É importante portanto que sejamos capazes de reconhecermos as fraquezas de cada linguagem, e eventualmente abrirmos mão daquela que sempre usamos.
Dois pontos tem que ficar bem claros para pessoas ligadas ao mundo do desenvolvimento.
O primeiro ponto é entender que o que diferencia bons desenvolvedores de péssimos desenvolvedores é a capacidade de entender e manipular as tecnologias existentes, ter uma visão crítica do que existe, saber se adaptar. O mundo da computação evolui de forma muito rápida. As necessidades mudam constantemente. Ficar obcecado por uma linguagem e tentar provar a todos que é capaz de fazer tudo com ela não leva a lugar nenhum. Bons desenvolvedores são pessoas curiosas, que gostam e são capazes de aprender coisas novas, querendo sempre aprimorar seus conhecimentos. Bons desenvolvedores são aqueles que entendem (ou procuram entender) os conceitos por trás das ferramentas que utilizamos.
O segundo ponto é que em última instância, o que paga nossos salários e o que nos torna úteis para a sociedade não é o fato de saber escrever if-then-else em uma determinada linguagem. O que nos torna úteis é a nossa capacidade de desenvolver produtos que facilitem de alguma forma o dia a dia das pessoas. Esse é o grande poder da tecnologia. Assim sendo, o nosso objetivo é criar estes produtos da melhor forma possível, utilizando os melhores recursos disponíveis. Usuário não vê o que está por baixo dos panos, e tampouco está interessado nisso. Usuário vê apenas se aquilo que desenvolvemos ajuda ou não. Nesse ponto, o que interessa portanto não é a tecnologia, mas sim o design da solução (aconselho a leitura do texto do Raphael sobre este tema).
Miguel,
sabes muito bem que sou um crítico severo de Java-a-linguagem. Sou menos crítico de Java-a-plataforma. Acho que Java-a-linguagem (JaL, pra encurtar) deixa muito a desejar no quesito “capacidade de expressão”. É praticamente impossível fazer construções lógicas curtas e diretas em JaL. Tudo é muito sandboxed. É muito difícil querer usar JaL para testar algum algoritmo de forma rápida, ou montar um protótipo para validar algum conceito (explorar alguma idéia). Throwaway code, então, nem pensar.
A força de JaL é que é uma linguagem segura, mas isso resultou em perda de poder. C, por exemplo, não tem nada de segurança mas ao menos permite que você passe um (void *) de um lado pro outro. Isso pode ser perigoso, mas pode ser muito útil em um ou outro caso. No espectro de capacidade de expressão, até C é mais poderosa do que JAL.
Se olhar, muitas “técnicas” de engenharia de software acabam sendo criadas para compensar essa falta de capacidade de expressão. JaL tem uma série de problemas por ser estritamente OO e não permitir certas construções lógicas e sintáticas? Design Patterns neles. JaL tem dificuldade para fazer programação bottom-up? Refactoring, Refactoring, Refactoring. JaL é muito verbosa e precisa de 20 linhas para um programa básico? IDE’s com geração de código a caminho…
Se for ver, isso foi intencional por parte da Sun. JaL não foi desenvolvida por um grupo de hackers que se sentiram descontentes com a capacidade de expressão com as linguagens da época, mas foi desenvolvida com o intuito de ser uma linguagem que pudesse ser aprendida por hordas e hordas de code-monkeys, através de toneladas de cursos e certificações by Sun.
Para o pessoal enterprise-y, isso está ótimo. É uma linguagem segura, onde se tem confiança que o programador não é capaz de fazer grandes estragos num codebase e, mais importante, o desenvolvedor passa a ser uma peça intercambiável. Na cabeça do empregador, basta tirar um code-monkey e colocar outro, contanto que ele tenha uma certificação by Sun (ou by IBM, ou by Impacta, wherever).
No mercado enterprise, não cabe muito ao programador a parte de bolar a solução. Formatos de armazenamento de informações de bilhetagem não são feitos por programadores, são pré-determinados por gente com experiência em OOS e BOS em telecom. Sistemas de gerenciamento de tráfego aéreo não são projetados por programadores, mas são analisados e especificados por profissionais da área. Sistemas de armazenamento de informações de pacientes em hospitais, a mesma coisa. O trabalho do desenvolvedor é um trabalho de implementação, puro e simples.
No mercado enterprise é preferível um programa “medíocre” e “confiável” a um programa “genial” mas “imprevisível”.
Você fica bravinho comigo porque acha que eu estou desmerecendo você, ou comparando você a um code-monkey. Não é verdade. Como você mesmo disse, você não é um “programador Java”. Você, quando precisou, buscou linguagens onde precisava de mais poder de expressão.
Entretanto, eu acho sim que há uma resposta para “qual é a melhor linguagem” e definitivamente Java está longe de ser a resposta. Pergunte-se: “se você pudesse iniciar um projeto, seu, sem pensar no dinheiro ou emprego, qual linguagem você escolheria?”. Eu sou capaz de apostar que os que vão escolher Java são os que têm experiência apenas em Java. Qualquer um que tenha mexido com linguagens que permitem maior capacidade de expressão vão utilizar desse poder.
JaL, como é, vai morrer (como C++) ou ter que se adaptar continuamente (como C#). Ela nunca chegou a ser a solução perfeita em termos de WORA, performance só se tornou aceitável depois que isso deixou de ser relevante e, mais importante, os desenvolvedores top agora possuem linguagens que oferecem as benesses da plataforma Java (gerenciamento de memória, interface com código-objeto escrito em outra linguagem, orientação a objeto onde interessante, etc) AO MESMO TEMPO que oferece mais flexibilidade, dinamismo e capacidade de expressão.
Viva a diversidade? Ok. Mas temos que saber que a natureza elimina os menos aptos.
Link | September 28th, 2007 at 00:25
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…
Link | September 28th, 2007 at 11:16
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, ó. [...]
Link | September 28th, 2007 at 11:42
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”.
Link | September 28th, 2007 at 11:54
Responder o Raphael me tomará um tempo que eu não terei nesta agitada sexta-feira. Amanhã eu respondo
Link | September 28th, 2007 at 13:33
Minha resposta:
Particularmente com o Eclipse eu uso Java até para scripting, ainda tenho o melhor dos dois mundos, todo meu conhecimento de Java, seu SDK, debuging no IDE e a agilidade de quem está escrevendo scripts mesmo.Você deve estar se referindo ao falta de aritmética de ponteiros, a presença de um Garbage Collector,Null pointerexceptions,Array index out of boundsexceptions… Ou outros aspectos?Detalhe, segura não é Java a linguagem, pois quem carrega o fardo as tarefas acima é sim a Máquina Virtual e não a sintaxe da linguagem (com excessão da aritmética de ponteiros).Poder para acessar regiões de memória não seguras? Poder para esquecer-se de desalocar memória para por exemplo toda e qualquer string? Acredite, em Java o seu ponteiro paravoidé simplesmente uma variável do tipoObject(claro, sem artimética de ponteiros ou tipos primitivos e outras restrições).Não imagino como! Java sim tem um ótimo poder de expressão para escrever código OO, humilhando C++ neste caso, basta comparar qualquer simples código OO em ambas as linguagens. (sim, eu vi que você estava falando de C, mas o coitado do C nem OO é, mas é claro, tem seu lugar no mundo atual bem seguro em determinados nichos). Exemplos…?Quais problemas? Quais construções lógicas e sintáticas??Design Patterns são apenas nomes para soluções de desenho de modelos OO para aumentar o reuso e melhorar a manutenção de seu código. Não tem absolutamente nada a ver com as limitações sintáticas de uma linguagem.Quem não busca reuso e código mais manutenível em seu trabalho?Refactoring é simplesmente um conjunto de técnicas para alterar o seu código sem alterar seu comportamento, novamente buscando melhor reuso e manutenibilidade. Não tem nada a ver com permitir programação bottom-up em nenhuma linguagem.Ai eu faço minhas as palavras de Kevin King. A dita verbosidade de Java é facilmente suplantada por ferramentas extremamente sofisticadas e gratuitas como o Eclipse, e se você programa em Java e diz que não usa uma ferramenta como o Eclipse então…Se você não considera o James Gosling um hacker na época em que escreveu Java então… (o cara escreveu uma versão do emacs) Vale lembrar que Java não foi feito de maneira alguma para o mundo Enterprise. A linguagem foi concebida para sistemas embarcados, para rodar em aparelhos de TV. Bom, já disse que Java não foi concebida para tanto, basta checar sua história em qualquer fonte, e por favor, o verdadeiro mundo dos code-monkeys é o mundo M$ Visual Basic e ASP. Java se destaca e muito no mundo científico, vai até em sondas para MarteLink | September 28th, 2007 at 22:58
Bruno, I’ll bite.
Com o Eclipse! Com a plataforma! Foco toda a minha crítica na linguagem, e você vem usar a plataforma como suporte de argumento.
Adiante.
Você está comparando apenas com C, meu caro.
Você fala em poder de expressão para escrever código OO. E se eu quiser escrever código funcional? E se eu quiser encarar um programa como uma série de manipulações em listas? Python faz isso. Lisp faz isso. Javascript faz isso.
Até em C eu consigo fazer programas onde eu passo funções como argumentos (function pointers). JaL, não. Isso é falta de poder.
Pegue uma lista de objetos S e remova os que possuem o campo “ExpireDate > Today()” e ordene por FabricationDate. Faça isso em uma linha (ou duas) em Java.
Em Perl, é possível fazer isso de 18 maneiras diferentes. Você vai falar que é feio. E é mesmo. Mas em Python (ou Lisp) é possível fazer isso de forma simples e elegante.
Não exatamente. Design Patterns são necessários para ter reuso de código em problemas comuns aos desenvolvedores. Acontece que os tais problemas não são problemas em algumas outras linguagens. Lê isso aqui, por exemplo
E outra: você tá fundamentando todos os seus argumentos em desenvolvimento OO, como se desenvolvimento OO fosse o Santo Graal da Computação. Não é. Bebeu do Kool-aid?
“We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.” – Guy Steele, co-author of the Java spec.Esse papo de “concebida para o mercado embarcado” pode ser puro papo de Relações Públicas. A Sun pode até ter tentado, inicialmente, focar a estratégia nessa área. Mas não deu certo. As primeiras versões da JVM eram lentas, e os chips e processadores nem tinham direito memória para rodar a JVM, quiçá as aplicações que iam em cima.
Para não perder o trabalho, continuaram apostando no que tinham, dessa vez usando o mantra da portabilidade e do “É um C++ melhorado”.
Justamente pelo aspecto segurança, não pelo aspecto “poder de expressão”.
Eu jamais faria software de controle de usinas nucleares em Ruby, ou software de controle de transações bancárias em Perl. Isso não quer dizer que Ruby ou Perl deixem de ser mais expressivas do que Java.
No mundo científico, a linguagem mais usada ainda é FORTRAN. Isso torna FORTRAN uma linguagem tão nobre, que merece essa defesa tão religiosa? Eu acho que não.
E, olha só, eu não trabalho com nada disso, graças ao bom Pai. Já tive a minha cota de trabalhar com sistemas operacionais real-time e requisito de “five nines” de disponibilidade, onde nem Java é uma opção.
Lá vem você de novo falando em OO. Tudo bem. De resto, todos os quesitos que você listou também são válidos para Lisp, ou Erlang. Com a diferença que as duas são mais expressivas do que Java.
Isso é argumentum ad populum. Podemos também “dizer seguramente que Windows não apresenta nenhum sinal de ter seus vastos domínios tomados por um concorrente”. Isso faz com que o Windows seja um melhor S.O?
Eu não critiquei a plataforma, critiquei?
Eu falei do poder de expressão das linguagens. No caso, acho que Javascript é muito boa. Python, também. Queria ter mais tempo para aprender Common Lisp, porque Common Lisp já tem (há mais de 35 anos) todas as features que são badaladas nas linguagens “modernas”.
De qualquer jeito, se você realmente quiser uma resposta: não estou tendo surpresas ruins com uma stack LLPP (Linux, Lighttpd, Python e PostgreSQL). É uma combinação que me deixa livre para pensar aplicações sem me obrigar a usar um único “mindset”.
E, se você é tão fanático por Java-a-plataforma, bem que poderia dar uma olhada em JRuby ou Jython. O poder da JVM, sem o fardo de JaL.
Link | September 29th, 2007 at 19:25
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.
Link | September 29th, 2007 at 19:40
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á.
Link | September 29th, 2007 at 23:59
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.
Link | September 30th, 2007 at 20:27
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
Link | September 30th, 2007 at 20:52
É 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
Link | September 30th, 2007 at 21:41
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.
Link | September 30th, 2007 at 23:07
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.
Link | September 30th, 2007 at 23:54
Raphael, eu argumentei meus pontos, se descorda de algum basta colocar seu ponto de vista, não fique puxando para o lado subjetivo dizendo que acho óbvio isto ou aquilo. Vamos conversar em torno de fatos.
Eu usava ponteiros para função em C em 1998 em trabalhos para faculdade. Realmente, não são a mesma coisa, passar um objeto em Java é muito melhor pelos pontos que eu já levantei anteriormente. Aliás polimorfismo em OO é em grande parte uma automatização da manipulação de ponteiros para função suportado pelo compilador ou VM. Ou seja, para obter um bom reuso de código antes do paradigma OO, muito se fazia manualmente a manipulação de ponteiros de função.
Justamente, não é a mesma coisa, e quando você precisar realmente de só uma função, a sintaxe de Java permite isto com facilidade, basta fazer o método ser estático, e ainda com static imports (desde Setembro de 2004) você pode usar este método (em termos de sintaxe) como uma função escrita em C, Python, Ruby, etc. Detalhe, em Javascript toda função manipula um objeto ou cria um novo. Por exemplo:
function foo() { this.x = 10; this.y = 20; this.addToX = new function (value) { this.x += value; }; } someObject = new foo();
Invocar uma função sem usar o operador
newfaz com que ela se referencie ao objeto do escopo de sua execução. Se você usar o operadornewé a mesma coisa só que com um objeto novo que o interpretador de JS irá criar. Javascript é uma linguagem muito bem Orientada a Objetos com uma sintaxe bem elegante, porém não baseada em classes como Java, C++, Ruby e Python mas sim em protótipos, conceito também utilizado no ambiente Self que foi largamente inspirado em Smalltalk.Isto foi mais para dizer que em JS uma função é mais que uma mera função em C, ela sempre tem um objeto ao qual se refere e pode inclusive fazer coisas como adicionar atributos ao mesmo.
Mais uma coisa, em Java você poderia ter o seguinte:
Runnable doIt = new Runnable() { //Obviamente a interface deve ser escrita antes, estou usando Runnable apenas como um exemplo public void run() { } };
Tá ai o seu ponteiro para uma função. Convenhamos, não é um código absurdamente mais verboso, é? E ainda dá informações suficientes para o seu IDE fazer navegação de código (ir para classe base, encontrar usos da função, etc) e Refactorings. Bom, java falei tudo que eu queria sobre este tema aqui.
Nós não nos conhecemos, então você não tem a obrigação de saber o que eu penso sobre muitas coisas em termos de desenvolvimento de software mas eu posso dizer que em 14 de Abril de 2005 eu já publiquei meu interesse (que já era anterior a esta data) em outras linguagens e/ou plataformas de desenvolvimento, provando que eu não “já escolhi java” e não tenho a mente fanaticamente fechada para outras tecnologias. Aja vista também o que eu já escrevi sobre Ruby e Python em diversos outros posts.
Bom, a porta está aberta para você contestar qualquer ponto de vista meu, desço até em detalhes se você quiser, mas por favor, critique alguma coisa concreta que eu disse ao invés fazer estes comentários tão abrangentes que se tornam em nada construtivos para a discussão.
Link | October 1st, 2007 at 10:54
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?
Link | October 1st, 2007 at 12:51
O wordpress não está exibindo minha última resposta…
Link | October 1st, 2007 at 20:12
Eu não disse que Java era melhor linguagem, apenas discordei de todos os pontos que você escolheu criticar na linguagem, basta ler minha primeira resposta.
Eu acho que a escolha de uma ferramenta está muito, mas muito longe de ser subjetiva, não é como escolher a cor de um carro, tem ferramentas com características mais adequadas para um problema ou outro, e sim, isto leva em consideração a plataforma, do contrario vira um exercicio mental sem aplicação prática alguma.
O import estático de java que te assustou tanto é require do Ruby, o include do C, import do Python, etc. Não tem nada de: “é só fazer isso”, “é só fazer aquilo”.
Agora não gostar de frameworks… Já ouvi falar da síndrome do “Not made home”? Aquele lance de reinventar a roda. Well… Ainda nesta linha anti-frameworks, vc faria um sistema web em Ruby sem usar o Rails? Mesmo usando o Rails tem muita receitinha de bolo para seguir, como era de se esperar eu eu acho bem normal.
E não dá para discutir Java a linguagem, java é uma plataforma, só se desenvolve em java usando a plataforma, não faz sentido este exercicio teórico que diz “Vamos imaginar que java seja apenas um compilador e uma VM, esqueça todo o resto…” Para que serviria isto?
Resumindo, eu apenas discordei de suas criticas à Java como plataforma E linguagem, não vi nenhuma argumentação forte para nenhum dos pontos apresentados.
Na boa, isto tudo se faz em Java e muito bem e desde que você não use um notepad, o problema de verbosidade deixa de existir.
Link | October 1st, 2007 at 20:14
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?
Eu não disse justamente que Java é interessante pro pessoal de mercado enterprise, onde nenhum dos fatores que eu critico são relevantes?
Link | October 2nd, 2007 at 04:17
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?
Link | October 2nd, 2007 at 04:29
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).
Link | October 2nd, 2007 at 09:16
Raphael,
não vou acrescentar nada interessante à discussão, apenas fiquei curioso … para você, qual é a menlhor linguagem em seu ponto de vista?
Sorô
Link | October 2nd, 2007 at 16:56
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:
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:
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.
Link | October 2nd, 2007 at 23:44
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
Link | October 2nd, 2007 at 23:15
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
Link | October 3rd, 2007 at 14:08
Javascript, Python e Ruby não são linguagens funcionais. E pelo que eu já discuti com Miguel (que estudou mais Python do que eu) Python teria apenas uma maneira estática de manipular funções.
Como eu disse Javascript, Python e Ruby não são linguagens funcionais. Veja se as mesmas tem as caracteristicas presentes em Haskell ou Erlang.
Isto prova que você nunca usou alguma ferramenta para automação de refactorings como Eclipse ou IntelliJ IDEA (o melhores IDEs para Java). Ter ou não inferência de tipos em nada afeta sua necessidade ou não de fazer refactorings. Vide a definição de refactoring que eu citei em minha primeira resposta.
Sobre o faltou dizer o mesmo para Java já que existem muito mais projetos que geram código para a JVM do que para a plataforma .NET.
Novamente faltou Java ai, o projeto Beanshell existe pelo menos desde o ano 2000.
De LISP eu sabia, agora eu desconheço o fato de Python e Ruby também permitirem isto.
Bom, pelos últimos benchmarks que eu vi Python ainda é bem mais lento que Java.
Açúcar sintático por si só nunca vai vencer toda uma plataforma madura e estável como Java é hoje.
Cara, temos sistemas gigantescos surgindo escritos em Java a cada mês que passa. É muito mais do que possível fazer grandes sistemas com uma linguagem OO estaticamente tipada e com as sofisticadas ferramentas como temos hoje, mais do que possível, é uma realidade.
Cara, o
foreaché só um açúcar sintático! Você não pode estar falando sério. Ainda mais qualquer IDE gera o código para umfor(;;)tradicional com 1 tecla de atalho (no Eclipse digite for e entãoCtrl+space).O overhead por tudo em Java ser sintaticamente uma classe é tão, mas tão pequeno.
Não foi a toa que operator overloading foi elegida como uma característica do C++ a não ser inclusa na linguagem. Pessoalmente usar métodos tradicionais deixa o código muito mais claro.
Cara, uma interface, um método encapsulado, primeiro que você só faz isto em Java se quiser. E eu não vejo como usar interfaces possa ser um impedimento para produtividade, elas estão exatamente entres o pilares para o uso de Polimorfismo em um modelo Orientado a Objetos!
O que tem um arquivo de configuração a ver com Java como simples linguagem ou plataforma? Pois ambos não precisam de XML nenhum para funcionar. Não cometa o erro de criticar a ferramenta por algo construído com ela.
Cara, o Eclipse ou qualquer outro IDE fazem e refazem isto em segundos. E na boa, não adiciona complexidade alguma no código, melhor ainda lhe fornecem uma camada de indireção para o acesso ao seus dados. Mas eu até entendo que este seja um ponto polêmico, mas nunca ao ponto de acabar com a produtividade de alguém.
Classes, interfaces, overhead??? Realmente você ainda esta preso no arcaico paradigma procedimental que todos sabemos, desde a década de 80, não escala para sistemas com centenas de milhares de linhas (que é um número bem razoável para qualquer sistema corporativo por exemplo, hoje em dia)
Não entendi, você fala como se a vida de qualquer um que não esteja em uma Startup possa comportar os horríveis overheads de usar classes e interfaces, getters e setters.
Colocado desta maneira apenas as startups tem uma necessidade urgente de produzir valor, nas demais empresas apenas classes e objetos, interfaces…
Startups são apenas empresas novas, em termos de desenvolvimento de software tem as mesmas necessidades de qualquer grande empresa.
Numa Startup ou vivendo de salário os desafios de se fazer software bem feito são os mesmos.
Bom Raphael, pelo que você falou é possivel notar que não lhe agrada muito o paradigma de modelos Orientados a Objetos, e é apenas mais um entre milhares que por não entender muito bem OO acha que usar Java te obriga a programar em OO, confunde completamente sintaxe com semântica. Pude ver isto quando você disse .
Usar uma sintaxe OO não te faz criar um bom modelo polimórfico, com alto grau de reuso logo uma boa manutenção.
Assim como poder em termos de sintaxe criar funções não faz o seu código seguir corretamente as diretivas da decomposição funcional.
Java só te obriga usar a sintaxe OO e como eu já publiquei em meu blog, com um overhead muito pequeno.
Link | October 4th, 2007 at 17:40
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.
Link | October 4th, 2007 at 17:57
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
Link | October 4th, 2007 at 18:18
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
Link | October 4th, 2007 at 18:33
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.
Link | October 4th, 2007 at 18:35
Miguel, rapidamente vamos aos pontos:
-Realmente dizer que está preso ao paradigma OO por usar uma linguagem que tem sintaxe OO eu considero um erro crasso, ao ponto de dizer que realmente a pessoa está equivocada demais. Fazer um bom modelo OO mesmo quando você está querendo já é complicado e requer muito estudo e dedicação. Imagine alguém te dizer que usar python te obriga a usar expressões lambda? Bom, no caso de OO e sintaxe o engano é maior ainda. Mas ninguém te a obrigação de estudar e/ou gostar de OO, outros paradigmas estão ai para nos servir.
Calma lá, eu não falei que é um programador bom ou ruim. Eu disse que usar Java não te faz usar OO corretamente.
Certíssimo.
É toda vantagem que você leva usando o paradigma procedimental, muita gente só usa ele mesmo. Eu pessoalmente acho ele extremamente inferior ao paradigma OO (e poderia falar horas sobre isto), o problema é que OO adiciona uma complexidade muito maior ao seu código, exige muito mais do desenvolvedor, mas isto é contrabalanceado com um código mais reutilizável, que por consequência será mais fácil de manter e terá uma vida mais longa. Levando isto em consideração, somente sistemas de uma certa complexidade valem a pena ter o esforço para um modelo OO empregado. Eu particularmente uso OO para tudo que não sejam scripts. E mesmo aplicações pequenas ficam bem elegantes quando este paradigma é utilizado. Mas entendo que para certos problemas talvez seja um tiro de canhão para uma mosca.
Aliás, o paradigma procedimental é o que eu mais vi aplicado na minha experiência com sistemas web corporativos. –
if intanceof‘s a torto e a direito; –Tomadas de decisão em cima do estado interno de objetos; –Classes gigantescas; –Nenhum uso de polimorfismo; –Variáveis com um escopo enorme; –etc; Tudo apesar da sintaxe OO de Java.-Eu disse que OO permitiu com que os sistemas pudessem ter mais de centenas de milhares de linhas (de forma manutenível), escalabilidade com relação a complexidade e quantidade de código e não performance. (“centenas de milhares de linhas“)
-”“roda a muito tempo de forma estavel” vale pra muitos sistemas e linguagens diferentes.” Claro que vale, se eu dei a entender o contrário em algum momento errei ao me expressar.
Sobre COBOL ter milhões de linhas escritas por ai, well, isto por si só não diz muita coisa, ao passo que as qualidades de Java que eu já citei aqui são numerosas. (Fora que COBOL não é uma linguagem de propósito geral, não é nada expressivo e muito verboso).
Mas é isto, acho que a confusão maior ai foi a questão da escalabilidade.
Sei que minhas opiniões são deveras fortes para algumas questões, mas eu seria falso de outra maneira. Eu mesmo prefiro aqueles que me criticam aos que me adulem (como diz tanto o político G.Alckmin). Prefiro que gritam, discordam de mim na minha cara e me mostrem seu ponto de vista do que os que ficam calados me julgando em silêncio.
Só espero não me tornar tão cedo persona non grata aqui
Link | October 4th, 2007 at 21:50
Enquanto eu acabo de ler o artigo da IBM enviado pelo Raphael:
The fate of reduce() in Python 3000
Well, eu posso estar errado mas dito isto e semlambdasme 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).Link | October 4th, 2007 at 22:16
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.
Link | October 4th, 2007 at 22:42
Faltou o link para o texto do Guido falando do
reduce(): http://lambda-the-ultimate.org/node/587Link | October 4th, 2007 at 22:47
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.
Link | October 5th, 2007 at 00:00
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
)
Link | October 5th, 2007 at 09:56
Léo, obrigado, obrigado, muito obrigado…
Link | October 5th, 2007 at 12:26
Como eu já havia respondido ao Miguel, realmente Python tem realmente First-class functions. Bom em discussões como é esta é realmente sair aprendendo algo
Correto, mas você há de convir que o pai do Python condenando estas funções é um sinal forte de que Python está longe de ter sido concebido como uma linguagem funcional. Ademais isto também ficou claro como água com o artigo que você mesmo mandou publicado na Alphaworks. Eu também sei que os expression generators vieram justamente para melhorar a legibilidade para este tipo de declaração de funções anônimas, logo as mesmas não são condenadas por Guido.
Raphael, preciso insitir veementemente, o que uma linguagem/plataforma pode fazer ou não, se é general purpose ou não, não é questão de gosto! Mas é sim algo passível de ser constatado. Vamos pegar apenas o Cobol que eu citei como exemplo(não uma versão .NET), ele não é general purpose, não dá para fazer qualquer tipo de aplicação no COBOL clássico que tanto roda nos Mainframes mundo a fora.
Você não tem que achar bizarro o que eu falo sobre Java, não confie na minha opinião, basta checar os argumentos sobre os quais eu sustentei isto. Falar dos pontos bons ou ruins de qualquer ferramenta é uma discussão objetiva e não religiosa ou pessoal.
Entendi a história mas não sei o que isto tem haver com o que eu tenho defendido aqui. Eu tenho defendido Java de suas acusações a partir de sua primeira resposta. Que LISP pode ser usado com sucesso em soluções inovadoras você sabe melhor do que eu que Paul Grahan defende isto com unhas e dentes há muitos anos, mas eu mesmo nunca falei o contrário.
Você enveredou por defender algumas linguagens como se eu as tivesse criticado, como Python e LISP, mas eu mesmo já postei em meu blog meu uso pessoal de Python (e mais) e mesmo LISP me interessou e interessa ainda demais.
O desafio da inovação que uma startup enfrenta por definição está presente em qualquer outra empresa, quer ela entenda isto ou não, pois qualquer empresa corre o perigo constante de ser desbancada por uma grande idéia, seja esta idéia implementada por uma startup ou qualquer outra empresa.
Eu sinceramente acho que nenhum bom desenvolvedor de software queira fazer sistemas aberrações como você mesmo disse, o meu ponto é estando em uma startup ou não eu quero sempre produzir software da melhor maneira possivel, seja procurando novas ferramentas/paradigmas/etc.
Ai você está assumindo como premissa que o Java é menos produtivo, o que sinceramente você não conseguiu mostrar, o fato de Java como Plataforma não ter inferência de tipos ou expression generators não o faz menos produtivo do que Java.
Eu já citei inúmeras vantagens da plafatorma java: (listando novamente abaixo) ->Permitir a programação Orientada a Objetos com a sintaxe mais expressiva em elegante para tal; ->Excelente SDK da indústria; ->Excelente ecossistema de soluções free e open source (Apache, Jakarta, Codehaus, etc); ->Madura: 10 anos além da versão 1.0; ->Altamente escalável: Basta ver o que os servidores de aplicações aguentam por ai em grandes corporações; ->As maiores empresas do mercado investem pesado nela: IBM, Oracle, Redhat, Sun; ->Uma Virtual Machine extremamente sofisticada: Alocação de memória em Java pode ser mais rápida do que em C!; ->Os IDEs mais sofisticados e poderosos são escritos para desenvolvimento na plataforma Java, menção honrosa para o Eclipse por ser free; ->Ótimo mecanismo de distribuição: Java Web Start com um dos melhores exemplos; ->Ótima mecanismo de para garantir a segurança de aplicações distribuidas pela rede; ->Excelente retro compatibilidade das versões novas com as anteriores; ->et cetera.
Estas são todas características fáceis de serem compravadas, não são minha opinião, não são argumentos subjetivos ou religiosos ou até mesmo de um fanático por java, são caraterísticas que simplesmente existem. Eu adicionei adjetivos a elas como “Excelente” sim, mas é fácil descer em detalhes em todas elas para que eu lhe mostre o porque do “Excelente”.
E para resumir minha opinião: Eu estudo novas tecnologias, paradigmas e ferramentas esteja eu em um empreendimento como uma startup ou sendo um assalariado. Meu interesse e dedicação para evoluir como desenvolvedor de software é o mesmo em qualquer um dos casos.
Link | October 7th, 2007 at 22:00
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
Link | October 7th, 2007 at 22:19
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.
Link | October 8th, 2007 at 01:48
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…).
Bom, eu já discordo que dê para fazer QQ coisa com QQ linguagem entao nem vou continuar aqui.
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).
Cara, nem vou responder isto…
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
interfaceque 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
virtualou 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++.
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:
Se você realmente usa muiiito isto, OKs concordo contigo que é bom procurar uma linguagem que tenha isto. Nunca vi ninguém gostar tanto de uma feature que mascara ou obfusca o código fonte, mas… idem ao item acima.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).
Resolve sim, como não??? Só não vou fazer um screencast aqui
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é…).
Sua predileção por first class functions eu não discuto, agora o “tacar tudo num class” é bobagem, o overread é desprezível.
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…).
Colocar VB ai ofende hein
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).
Link | October 8th, 2007 at 20:51
Sobre inferência de tipos, dificuldade de refactoring e verificações de tipos em linguagens dinâmicas segue um interessante artigo.
Link | October 9th, 2007 at 13:24
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.
Link | October 9th, 2007 at 20:51
Como lendo o que quer? Eu comentei sua resposta inteira…
Link | October 9th, 2007 at 21:12
Raphael,
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.
Link | October 9th, 2007 at 22:45
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”?
Link | October 10th, 2007 at 05:26
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?!?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.
Link | October 10th, 2007 at 07:30
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”?
Link | October 10th, 2007 at 07:36
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:
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).
Link | October 10th, 2007 at 10:08
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.
Link | October 10th, 2007 at 12:35
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:
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
Link | October 10th, 2007 at 15:28
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.
Link | October 10th, 2007 at 16:29
Eu sei que isto está se arrastando mas eu preciso exercer meu direito de resposta.
Vamos chegar nisto.
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
selfsempre na assinatura dos métodos.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?
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…
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.
Me recuso a comentar isto… Ou melhor, vou comentar, que mágica tem em usar as ultra sofisticadas e complexas funções
map,filterereduce? Nada! É simples, egenerator 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.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.
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.
Não vi esta complexidade toda em python, não estou conseguindo ver.
Mas quem quer se preocupar com problemas já resolvidos?! Para quê? Reiventar a roda? Você tem todo este tempo sobrando para isto?
Não é resolvendo os problemas de negócio que se ganha dinheiro??
Mas o que usar java (sem inferência de tipos, generator expressions, map, reduce, filter e lambda) pode impedir a criação de ? Percebe como sua lógica tem um exagero tremendo?
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?
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.
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?
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 generatorsde python bem legais, só não são nenhuma bala de prata.Link | October 16th, 2007 at 20:41
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/
Link | October 17th, 2007 at 01:58
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]:
Aplicação [GoF]:Olha a explicação simplória do cara:
Dizer isto aliás não faz o menor sentido! Java em sua API tem a interface
Itarableem todas suas coleções, nem por isto Java tem o pattern Iterator embutido em si, eDizer 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!!!
Link | October 17th, 2007 at 13:00
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:
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.
Link | October 17th, 2007 at 14:29
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
Link | October 17th, 2007 at 14:35
Miguel, nunca satisfeito… quando posta e ninguém comenta, reclama. Quando posta e comentam, reclamam também. People are so hard to please.
Link | October 17th, 2007 at 14:38
Comentou e ainda por cima criticou o autor do post. 21 anos sem…
Link | October 17th, 2007 at 14:50
Raphael, gostaria muito de te responder mas infelizmente o Miguel me proibiu de continuar esta discussão aqui…
Link | October 18th, 2007 at 16:52
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?
Link | October 18th, 2007 at 16:59
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 [...]
Link | October 18th, 2007 at 23:49