Less is More
“Occam’s Razor” (Navalha de Occam) é uma dessas coisas que a gente escuta por aí, cada um dando uma definição um tanto vaga, que costumam girar em torno de “idéias muito complexas costumam ser erradas” e “entre duas explicações para uma idéia, a mais simples é a correta”.
Pois bem. Se você procurar uma definição, vai ver que (William) Occam é um nome de um filósofo inglês do século XIV, e que “Occam’s Razor” é definido como uma expressão da “Lei da Parcimônia”, ou seja: “Entidades não devem ser adicionadas além do necessário”. Traduzindo: quanto menos conceitos você precisar para explicar e testar uma idéia, melhor.
Penso cá com meus botões - apesar de só ter usado camisetas ultimamente - que essa é uma idéia que não é totalmente assimilada pelos computeiros em geral. Para o nerd tradicional, é divertido quebrar a cabeça resolvendo problemas. Logo, pensa ele, quanto mais complexa a idéia, maior será a recompensa em resolvê-la.
Isso me veio a cabeça lendo o último texto do Steve Yegge, que trata do problema de lidar com grandes bases de código. Alguns trechos abaixo:
People in the industry are very excited about various ideas that nominally help you deal with large code bases, such as IDEs that can manipulate code as “algebraic structures”, and search indexes, and so on. These people tend to view code bases much the way construction workers view dirt: they want great big machines that can move the dirt this way and that. There’s conservation of dirt at work: you can’t compress dirt, not much, so their solution set consists of various ways of shoveling the dirt around. There are even programming interview questions, surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck at a time.
Industry programmers are excited about solutions to a big non-problem. It’s just a mountain of dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.Ah, você é daqueles que acredita que há a solução para todos os problemas da humanidade, se todo mundo aprendesse a seguir o manual? Dê uma olhada no que se diz a respeito de Design Patterns:
Interestingly, sales people didn’t get excited about Design Patterns. Nor did PMs, nor marketing folks, nor even engineering managers. The only people who routinely get excited about Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns. However, Java programmers misattributed this; they concluded that Perl programmers must be slovenly, no good bachelors who pile laundry in their closests up to the ceiling.E você acha que basta ter ferramentas para resolver esse problema? Diga-me, espertinho, como é que as suas ferramentas vão me ajudar a aprender e assimilar os conceitos desnecessariamente complexos empilhados em seu projeto/código?It’s obvious now, though, isn’t it? A design pattern isn’t a feature. A Factory isn’t a feature, nor is a Delegate nor a Proxy nor a Bridge. They “enable” features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the “Gang of Four” book – make code bases get bigger. Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.
Dependency Injection is an example of a popular new Java design pattern that programmers using Ruby, Python, Perl and JavaScript have probably never heard of. And if they’ve heard of it, they’ve probably (correctly) concluded that they don’t need it. Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger.
Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.
In the other compartment, they think their IDE makes the code size a non-issue. (…) There are several problems with this perspective. One is simple arithmetic again: given enough code, you eventually run out of machine resources for managing the code. Imagine a project with a billion lines of code, and then imagine trying to use Eclipse or IntelliJ on that project. The machines – CPU, memory, disk, network – would simply give up. We know this because twenty-million line code bases are already moving beyond the grasp of modern IDEs on modern machines.
Raphael,
Realmente interessante este ponto de vista. Aliás, este é um ponto de vista que se encaixa muito bem em projetos de código-aberto onde, na maior parte deles, só se inclui no código aquilo que se prova ser realmente necessário. É fácil encontrar exemplos de pessoas que chegam em uma determinada comunidade com algo que é até legal e bem feito mas que, por não ser realmente necessário naquele momento para os membros daquela comunidade, é simplesmente ignorado.
Um abraço,
Leonardo Garcia
Log4Dev » Less is More…
Occam é um nome de um filósofo inglês do século XIV, e “Occam’s Razor” é definido como “Entidades não devem ser adicionadas além do necessário”. Ou: quanto menos conceitos você precisar para explicar e testar uma idéia, melhor….
Design Patters dizem respeito a melhores técnicas para reuso de código, assim como OO. E que viagem confundir o Spring que é um container de componentes (que btw são apenas POJOs) com design patterns. Como confundir o tal do Observer/Observable com o Spring? Ou com o Pico, Nano, whatever?!? Percebe o nível da falta de compreensão entre as entidades comparadas aqui?
Quanto aos 2 primeiros blockquotes que você copiou neste post, discordo diametralmente, que embasamento o sr. Yegge tem para fazer uma generalização deste porte? Dito isto, com as premissas erradas você pode provar qualquer coisa
Raphael, eu sei que você é usário do Django, que deve ser um misto de API, Framework e Container.
Você já teve a curiosidade de baixar o código fonte dele e procurar os famigerados design patterns por lá? Já pensou em fuçar na lista dos desenvolvedores (deve existir uma) e ver quais são os tópicos relativos ao design da coisa?
Uma última porém importante pergunta, nestes seus projetos novos o jobs4dev, o news4dev, você tem programado usando algum IDE? Digo IDE mesmo e não editores de texto turbinados.
PS. (Só para não haver mal entendidos, eu tenho Editores de texto para programadores como um dos melhores canivetes suiços do meu dia a dia, uso e recomendo o jEdit).
Bruno,
job4dev, log4dev e news estão sendo desenvolvidos em Emacs. E não entendi de onde você tirou a referência ao Spring neste texto..fiz uma busca pela palavra e ela só aparece no seu comentário. Ou será que você está se referindo ao IoC?
Miguel,
Sim, falei do Spring baseado no trecho abaixo:
Achei meio óbvio pois o Spring framework é o maior expoente ao se faler de Dependency Injection, foi A ferramenta que popularizou este padrão arquitetural.Sobre o uso de emacs no lugar de um IDE, você já pensou em baixar o pydev? Acha que realmente ele seria ou é ou ainda, representa um overhead tão grande ao ponto de suas vantagens não compensarem o trabalho para utilizá-lo? (trabalho este que sequer existe…)
E DI nao e pattern?
Quanto ao pydev, eu baixei, cheguei a utilizar. Mas sinceramente o problema nao foi o overhead. O problema foi que eu nao vi nenhuma vantangem extra do pydev em relacao ao python mode do emacs. E eu queria variar um pouquinho, ja mexo com Eclipse todo santo dia,e eu queria recuperar um pouco de pratica no emacs.
E eu considero o Emacs um IDE. Integrated Development Environment. Instalei ambiente de SVN, python (que me permite executar trechos de codigo, verificar estilo do codigo, etc), javascript, html, shell, SQL…e sem contar que o esquema de macros do editor eh animal.
Voce deveria tentar.
Querer experimentar o emacs eu entendo como motivação. É um editor de texto poderoso mas para IDE está longe, me surpreende um usuário de Eclipse confundir o emacs com todas as centenas de funcionalidade que o Eclipse oferece.
Editores de texto poderosos eu fico com o jEdit, possui mil plugins instaláveis pela própria GUI, é todo feito em Java inclusive obviamente sua arquitetura extensível de plugins.
Sua linguagem de macro inclusive tem um modo “Record” e é toda gravada em comandos java a lá beanshell, super fácil de entender e alterar, é código java!
E quanto ao emacs já inclusive trabalhei vários meses unicamente com ele na construção de um sistema em java (sem frameworks na época) que representava um servidor de consultas ao Serasa, para máquinas de validação de cheques. Btw, thanks god o Ant já quebrava um bom galho naquela época.
Fora que eu já estudei muito tempo o Xemacs (emacs modo texto já é demais) e o personalizei na época. Isto vindo depois de trabalhar 1 ano e meio com um IDE bem parrudo como era o Visual Age.
Mas fiz isto pois também queria saber como era realmente trabalhar 5 dias por semana o dia inteiro com o famoso emacs e por também ser cultura da empresa e mais, um grande desenvolvedor amigo meu que lá trabalhava conhecia muito o editor.
Acontece que posteriormente eu tive oportunidade de trabalhar com o IntelliJ IDEA e isto é com certeza um caminho sem volta, não fosse o Eclipse eu teria ponderado a compra do IntelliJ há muito tempo.
Trabalhando com IDEs como Eclipse e IntelliJ IDEA a diferença para com editores de texto por mais poderosos que sejam fica mais do que clara.
Ps: Não vivo sem o recurso de macros e é comum eu manipular trechos de texto no jEdit e copiá-los de volta ao IDE. Mas um IDE tem features incomparáveis e imprescindíveis hoje em dia.
Miguel,
Eu acho DI muito mais que um pattern no formato definido pelo GoF, é na verdade uma solução, um software completo que por sua vez é concebido muito provavelmente com o uso de outros patterns em seu modelo OO.Talvez possa ser considerado como um padrão de arquitetura.
Bruno,
Quanto ao lance de IDE, dá uma lida em http://osteele.com/archives/2004/11/ides .
Bruno,
pergunta básica: que tipo de “solução” é fornecida pelo DI? Algum usuário do software pagaria mais pelo fato do desenvolvedor ter usado DI?
Raphael,
Não vou ler um link só porquê você colou ele aqui, na boa, tenho bilhões de links na minha própria lista para ler já, o mínimo que você faz é tentar me mostrar o que tem de interessante no texto apontado, me dê PELO MENOS sua opinião sobre o texto.
Raphael,
Eu tenho certeza que o usuário paga por código entregue com mais qualidade, facilidade de manutenção, tempo de resposta para correção de erros, etc. Isto reflete DIRETAMENTE no produto final que ele está comprando.
E é exatamente nestes pontos em que padrões de modelos OO e/ou padrões arquiteturais influem.
Você discorda disto?
Bruno,
1) Lê o texto. É melhor para mim e para você que você gaste o seu tempo lendo os textos do que discutindo usando argumentos batidos.
2) Discordo. Usuário paga por features. Mesmo a mais brilhante peça de engenharia não vale nada se as funcionalidades não servirem ao usuário.
Argumentos batidos?!? Quais, contra IDEs? Eu estou tão por fora assim que existe uma corrente tão forte de desenvolvedores contra IDEs (em termos quantitativos e qualitativos)?
E outra, você só me dá o link então eu posso assumir que você concorda com 100% das palavras do cara, que a sua opinião é tão igual a dele que você nem se dignifica a escrever uma palavra de próprio cunho?!? O cara é tão dono da verdade assim?
E nenhum argumento fica “batido” por causa de um único post num blog, qualquer que seja.
Amigo, features são escritas em cima de modelos e arquiteturas, elas não existem ou funcionam bem ou sequer evoluem se os modelos que as suportam não forem bem feitos!!! Como você não pode ter isto claro?!?!??
Pra que te dar minha opinião? Pra quê? Pra você ficar exercitando sua vaidade intelectual? Chega… só caio nisso uma vez. Já basta o fato de você estar devendo até agora algum comentário a respeito do video do Peter Seibel sobre o lance de Patterns e os problemas de uma linguagem como Java.
O texto nem é “contra” IDE’s. Se você ao menos abrisse a porcaria da página e desse uma lida por cima, ia ver qual era o ponto que o cara trata no texto. O tempo que você ia gastar dando uma lida rápida ia ser menor que o tempo que você ia gastar trollando.
Não, não vou mastigar pra você e colocar aqui a minha síntese da idéia, justamente pra ver se você sossega o facho ao ler de “cabeça aberta”.
Mas não… o que você quer é ganhar a briga. Discutir só pela graça de fazer valer a sua opinião.
E quanto a parte de “features serem escritas em cima de modelos e arquiteturas”. Quantas vezes você já viu o Linus Torvalds falando que o sucesso do Linux é devido a uma uniformidade e padronização de idéias e modelos? Nenhuma! Já parou pra pensar que muitas coisas (especialmente no mundo open source) surgem por crescimento orgânico, ao invés de excessivo pré-planejamento e over-engineering?
Eu disse:
E você me diz e que isto é “excessivo pré-planejamento e over-engineering”?!? De onde você tirou isto??? E ainda, o Linus Torvalds pode falar o que quiser mas eu repito “features são escritas em cima de modelos e arquiteturas” e a raiz do sucesso do kernel está não só no trabalho colaborativo como em software muitíssimo bem escrito, be sure of that!Para escrever software bem feito, com bons modelos e arquitetura não é necessário “excessivo pré-planejamento e over-engineering”, isto com a mais absoluta certeza. Ou você acha que modelos e arquitetura só vêm com trabalho burrocrático?
E cara, cuspir um link qualquer e me mandar ler, ahh, se tá de brincadeira mesmo! Se eu não tivesse mais nada para fazer neste mundo eu veria com vontade, agora se o interesse é seu que eu leia o texto o mínimo que você me faz é dizer o porquê, hehehe.
Imagine eu mandar um cara que eu respeito muito como desenvolvedor: “tó, lê isto ai porque você não conhece nem os argumentos mais batidos desta discussão”. Piada, né não Raphael?
Sempre que eu quis mostrar alguma idéia para um colega eu tento mostrar minha opinião antes e torná-la atrativa para ele como é para mim. Depois então se surgiu interesse eu passo textos e referências para a pessoa.
Chutar um texto e achar que eu vou me sentir obrigado a ler e ainda ficar P da vida com isto é brincadeira.
E pode ter certeza Raphael, não preciso que ninguém mastigue nenhuma informação para mim, não foi um movimento maquiavélico de minha limitada mente querendo que outras pessoas façam o trabalho sujo de pensar por mim, hehe.
E que tal agora a gente focar na discussão e você comentar alguns pontos do meu primeiro post? Como o que eu disse sobre criatividade e frameworks por exemplo?
Agora o tal video ao qual você se refere é aquele no qual o cara fala de double dispatch e como isto já traz o pattern Visitor naturalmente para LISP, é este? Eu tenho quase certeza que não só vi o video que você me mandou, como tenho uma opinião bem formulada a respeito dele. SE não respondi lá foi por respeito ao Miguel que quis encerrar as respostas aquele post.
Bruno, diz uma coisa… você ao menos tenta compreender o ponto que está sendo feito por alguém, ao entrar nessas discussões? Ou você só quer mostrar o quanto você é capaz de permanecer refratário a qualquer coisa que seja contra o seu worldview?
Você defendeu que:
1) A premissa do Yegge está errada. Diz você, os desenvolvedores não querem IDE’s que tratem suas codebases como ferramentas que ajudem a manipular e mover grandes bases de código de um canto para outro.
2) A visão do cara está errada em relação ao Design Patterns. Design Patterns, diz você, é a forma correta de fazer com que seu código seja legível e melhor reutilizável.
3) Logo depois, você entra em discussão com o Miguel sobre o DI, um pattern que só se aplica a linguagens que não são dinâmicas.
4) Você coloca a idéia que o uso do DI ajuda a construir software com maior qualidade, e que isso é importante para o usuário.
5) Você também sugere ao Miguel que use o PyDev ao invés do Emacs para desenvolvimento em Python, achando que ele só teria a ganhar com isso.
Pois bem… para esses pontos, eu pergunto:
1) Se a premissa está errada, qual é o ponto de ferramentas como IDE’s? Antes de disparar no teclado dando a resposta “do livro-texto”, tenha em mente que não é todo mundo que trabalha da mesma forma que você, i.e, há gente por aí que usa linguagens mais dinâmicas, mais “densas”, que são capazes de produzir a mesma funcionalidade em menos linhas de código.
2) O texto critica a) o fato das pessoas não se preocuparem com o tamanho da base de código, já que creditam às IDEs o trabalho de manipular os blocos de código, e b) o fato de usarem toda a sorte de Design Patterns, o que leva a um aumento ainda maior do código, em linhas. A pergunta: qual é a sua proposta, então, para que possamos ter código mais enxuto?
3) Você mesmo diz que o DI foi popularizado pelo Spring. Também diz que o DI é uma “solução arquitetural”. Pergunta: não lhe parece meio estranho o surgimento de uma solução que só é popularizada entre pessoas que estão trabalhando em uma classe específica de ferramentas? Ou melhor: se tem gente usando outras ferramentas onde não existe esse “problema”, qual a necessidade desse tipo de solução?
4) Você mesmo falou que o Linux tem código de qualidade, não foi? Pergunta: quantas vezes você encontrou algum texto de algum desenvolvedor do Linux reclamando algo do tipo “até gostaria de adicionar as funcionalidades implementadas por Fulano, mas o código dele não usa DI e isso é uma afronta aos nossos guidelines de desenvolvimento.”?
5) Você seria capaz de listar alguma funcionalidade que eu estou deixando de utilizar por ter escolhido o Emacs ao invés do PyDev+Eclipse?
Ps.:
Eu diria que isso é uma forma de catequização. Vejo que seria melhor para você e para seu colega que você desse o máximo possível de idéias e opções de escolha (isento de opinião) e deixasse o seu colega atingir por meios próprios suas conclusões.
Eu realmente achei o post do Yegge uma viagem, mas prefiro e vou escrever sobre isto em detalhes em outra oportunidade.
Um bom modelo OO sem dúvida permite a construção de código legivel e reutilizável. É impressionante outros pensarem diferente. Não coloque “a forma correta” quando esta expressão não foi utilizada.
Eu acho que foge demais ao foco, desta discussão, dizer em que tipo de linguagens DI se aplica, mas eu não vejo impedimento algum em implementar um container para DI em linguagens que tenham mecanismos de reflexão e introspecção.
Não só DI amigo, como bons modelos OO, etc. Mas enfim, agora você me diz que software com qualidade não é importante para o usuário?!?
Eu acho que ele teria a ganhar mesmo.
Cara…. você ainda está preso no tempo, e caso você não saiba tem muita gente, inclusive tech leaders da ThoughtWorks que usa IDEs para programar em… Pasme! Ruby!!! Isto, usando o IntelliJ IDEA, usando Netbeans, e outros tantos já despontando por ai. Verdade, eu não sei o quão bons eles são, perto de outros tantos já consagrados.
Design Patterns aumentando linhas de código?!? Sendo responsável por sua code base atingir níveis ingerenciáveis?!? Wow…!!! I’m shocked…
Eu quero crer que você nunca leu o estudo de caso no inicio do Design Patterns [GoF], tão pouco tenha lido o livro Refactoring [Fowler]. Este último ainda sendo aqui completamente idolatrado por Yegge. Aliás, o Steve Yegge não deixa de viajar nem neste post, embora diga coisas muito boas com as quais concordo sobre o livro do Fowler.
Isto eu acho que é meio que fato, não? Mas enfim…
Yep..
O fato de não existirem, se é que não existem mesmo, containeres de DI para o mundo python ou ruby não quer dizer nada, pode ser apenas uma questão de tempo. E outra, quanto em termos de ferramentas já python ou ruby não herdou de outras plataformas? Frameworks/API de ORM é só um dos exemplos. O web.py tem cara de ser bem inspirado em Java Servlets. Quantas template engines não surgiram para a plataforma Java antes de projetos semelhantes serem criados para outras linguagens?
Dizer-me que os mundos Python ou Ruby não precisam de DI, baseado na simples afirmativa de ainda não existirem soluções deste tipo para tais linguagens, é um argumento muito fraco. Isto se já não existirem iniciativas para tanto.
Este seu argumento está tão sem sentido e tão fora de contexto que não merece atenção.
Já listei, quase 2 meses atrás, veja em meu blog.
Eu acho que é a opção mais natural ao trabalhar com uma determinada tecnologia buscar a melhores ferramentas para lhe auxiliar. Você pelo visto acha tudo muiiito complicado e muiiito overhead. Eu com certeza acho que o PyDev tem um potencial muito maior para me ajudar do que um editor de textos, por mais que seja o emacs.
Eu acho que faz parte da nossa profissão buscar as melhores ferramentas, é algo até natural. E ainda mais ferramentas tão simples de usar como e o Eclipse JDT ou imagino que seja Eclipse PyDev (eu mesmo que sou o programador python mais casual que existe configurei e rodei um projeto em minutos, projeto não Hello World).
Entende o ponto? IDEs hoje em dia são ferramentas simplérrimas de serem utilizadas! E ainda muito poderosas, aumentam nossa produtividade anos luz a frente da era [editor de texto] [Ant] (E no caso de Ant ainda seu potencial é multiplicado dentro do Eclipse)
Por que você tem uma posição tão refratária com relação a IDEs então???
Com relação a bons modelos OO eu até entendo, não é algo necessariamente simples de digerir, requer estudo mesmo, agora usar uma IDE? Hoje me dia? …
O que você chama de catequese eu chamo de diálogo, troca de experiências e informações.Bruno, estou começando a duvidar da sua capacidade de leitura e compreensão de texto…
Tente de novo:
1) Onde eu falei que um bom modelo OO é incapaz de produzir código legível e reutilizável? Onde o Yegge em sua “viagem” afirmou isso?
O ponto é o tamanho das bases de código, e a forma que os industry programmers lidam com isso. O texto fala justamente coisas como “programadores Java estão acostumados a usar toda sorte de Design Patterns com o intuito de ter um código mais gerenciável, entretanto isso em nada resolve, até piora, o problema do tamanho da code base”.
2) Onde eu falei que a qualidade não é importante para o usuário, filho de Deus? Eu apenas coloquei a sua afirmação que diz que o uso do DI é praticamente fundamental para a obtenção de qualidade no software.
3) É impressionante como você tem tempo para me acusar de estar preso no tempo, mas não tem tempo para ler um texto que fala justamente sobre a questão de desenvolvedores que focam seus esforços em aprender linguagens e seus recursos e outros que focam seus esforços em dominar ferramentas para linguagens mais limitadas. Nem sei se mando você ler o texto de novo… acho que você não vai conseguir entender. Ou, pior, você vai se identificar com um dos “lados” e vai ficar aí, debatendo ad infinitum.
4) Nunca te ocorre a possibilidade que as features de linguagens dinâmicas eliminam a necessidade de um pattern? Você tem certeza que viu o vídeo que eu te passei?
5) Você acha que eu devo ficar impressionado com o fato de ter rodado o jogo “em minutos”? Você por acaso chegou a tentar colocar o jogo pra rodar sem a sua tão preciosa IDE? Já parou pra pensar que poderia conseguir rodar o jogo “out of the box”?
6) Olha o seu “diálogo”: qualquer um que critica o modus de pensar dos industry programmers é chamado por você de “viagem” ou de “cara que não entende/incapaz de ingerir OO/preso no tempo”? Que diálogo é esse?
Tenta de novo, por favor.
Minha capacidade de interpretação de texto? Eu disse:
Você inferiu: Hmmm… um pouco diferente não?Você deu a entender que o usuário não paga por bons modelos ou arquitetura mas sim por features, o que na minha opinião é uma viagem, já que features só sobrevivem em cima de bons modelos e arquitetura, não são coisas que podem ser separadas, não faz o menor sentido dizer que o usuário não paga por um software bem modelado.
Li o texto sim viu, e é bem simples de enteder, nenhuma mágica, hehehe. Discordo de vários pontos e concordo com alguns.
Mas só pode ser uma piada mesmo né Raphael!!! Eu vi bem o video e nele eu vi que o ÚNICO pattern citado é o Visitor, em função do mecanismo de double dispatch, etc. SÓ um pattern amigo!!! UM!!!
Como você é teimoso, já discuti isto amplamente com você no outro post, você não é capaz de me citar mais nenhum pattern que uma linguagem dinâmica traz consigo embutido! E olha que nem na definição de linguagem dinâmica você acertava!
Qualquer um vírgula Raphael, não é qualquer um que eu critico não, hehe. Minha opinião é que o cara viajou mesmo, e??? E outra, com prazer pretendo comentar este post no meu blog, assim que o tempo permitir.
Sobre estar “preso no tempo”, sim, aqueles que criticam o conceito de IDE estão bem perdidos mesmo, ainda se fossem ferramentas dificeis de operar.. mas nem isto.
Agora criticar um IDE específico, normal, mas o conceito em si… wow… não sei o que é pior, criticar o conceito de IDEs ou de framworks, ou ainda Design Patterns, wow^2.
Diálogo para você é “Tó ai este link”. Falar comigo no modo imperativo não é o melhor caminho para me fazer ler um texto, hehehe.
O meu precioso IDE me dá features que o seu precioso editor de textos não dá…. Então o tom perjorativo por você empregado fica meio sem sentido, não?
Agora respondendo sua pergunta, porque eu martelaria um prego com um martelo se eu posso usar uma pedra mesmo? Martelo não é coisa que um merceneiro de verdade deveria usar… tem que ser um ferramental mais rústico mesmo, pedras ou quiçá os próprios punhos. Afinal, onde já se viu um marceneiro querer usar as melhores ferramentas disponíveis?!? Não há tempo para isto, é um absurdo…
Ok, Bruno…
Suas últimas respostas deixaram claro que o que você quer mesmo é brincar de Narciso intelectual. Você só vai achar bonito o que for espelho.
Nem se você lesse três vezes o que correu dos comentários, você entenderia o ponto que eu, o Miguel e o Steve Yegge queríamos mostrar.
Retiro-me em vergonha, ofuscado por tua sapiência. Aproveitarei e mandarei um email para Linus Torvalds, Paul Graham, Steve Yegge, Peter Seibel e todos os outros pobres coitados presos no tempo que me recordar. Avisarei cada um deles dos erros que eles cometem. Os dois primeiros usam vi, tadinhos. Os dois últimos, Emacs. E todos eles, burros que são e incapazes de ler o livro do GoF, produzem código sem se perguntarem antes qual é o pattern adequado a ser aplicado.
Que lástima. Que vergonha.
Faça o favor: quando Google ou a Amazon ou a Microsoft ou a Sun te chamar para uma entrevista, deixe-me como referência. Sou um convertido a todo o seu conjunto de valores, e farei questão de mostrar a eles que qualquer coisa que eles falarem em contrário, estarão errados.
É mais fácil responder assim mesmo do que rebater o argumentos que eu levantei…
Talvez possamos parar com respostas passive-agressive quando você entender que eu não estou preocupado em debater os seus argumentos, mas em mostrar que há gente produzindo coisas de valor sem se valer de idéias que, embora sejam senso comum, não sejam leis universais para pessoas que trabalham com tecnologia.
Você se agarrou a um conjunto de valores que funciona - em alguns casos. Eu estou falando de outras coisas, outras necessidades, outros objetivos. Entretanto, você continua tentando fazer valer a sua visão nesses outros aspectos.
Vou te dar um exemplo da sua defesa “religiosa” (religiosa no sentido de ser dogmática) dos seus conjuntos de valores: o próprio texto do Steve Yegge, ele fala que ele produziu um jogo online, e que esse jogo chegou a ter 250 mil usuários. Todo o texto dele parte da experiência dele por ter desenvolvido, sozinho, um jogo em Java com 500 mil linhas de código. Sua reação? Falar que o cara “viaja”, ou “de onde ele tirou embasamento para isso?”…
Ao invés de tapar os olhos e ouvidos, que tal tentar aprender um pouco com a experiência dos outros?
Está dizendo que eu tenho dogmas em relação ao desenvolvimento de software??? Cara, eu cansei de dar argumentos paupáveis e de lhe fazer questionamentos, os quais você, na maioria, sequer responde.
E se não me engano o próprio Steve Yegge não escreveu recentemente que o jogo dele está fora do ar e que o código fonte está totalmente impossível de dar manutenção??? É isto mesmo? Digo porque eu corri só os olhos neste post e não li inteiro, mas se for, é este o exemplo que você usa para fundamentar seu raciocínio?
Na boa, aprender com a experiência de outros é ótimo, mas os outros que eu escolho tem muito mais, mas muito mais reputação que o mr. Yegge.
Tá bravo? Calma, cara. Como eu já disse antes, faça um favor a nós dois e reflita um pouco sobre o que se lê, antes de pular no teclado e despejar sua fúria.
Pensa um pouco… o que faz você pensar que o código dele não faz uso dos princípios que você defende? Se você ler o texto todo (ao invés de só correr os olhos procurando por trechos isolados que possam ser atacados), em nenhum momento você pode inferir que ele negou os princípios que são tidos como best-practices no desenvolvimento em Java (ou C++, ou linguagens/plataformas consideradas padrão entre os industry programmers).
Justamente o contrário. O texto dele mostra um ponto muito maior: “ao longo de todos os anos, e mesmo conhecendo as técnicas consideradas como corretas no desenvolvimento de grandes sistemas, ainda assim o sistema que eu desenvolvi é excessivamente complexo e carece de muito tempo e esforço para manipulação e manutenção.”
Outra: o que faz você pensar que as pessoas que você tem em mais alta conta seriam capazes de manter online um sistema com milhares de usuários, trabalhando sozinhas e apenas nas horas vagas?
Se eu perdi a calma contigo? Certamente, e faz teeeempo.
Faça você um favor para nós dois e não me chame de dogmático/religioso em relação ao meu trabalho.
Raphael, não vou perder mais tempo com esta discussão, eu tenho certeza que ela não vai me ensinar nada.
Até a próxima.
Qual parte te deixou nervoso?
O que eu tô tentando te mostrar é que tudo que você coloca (opinião sobre OO, linguagens de programação, experiência, objetivos de programação, etc, etc, etc) você o faz como se fosse algo definitivo, sólido e imutável, quando não é. Parece que, para você, as regras aprendidas em algum lugar (seja em livros ou com experiência própria) se tornam condições necessárias e suficientes para fazer com que as coisas dêem certo.
O lance da IDE serve de exemplo: você, ao escrever como escreve, se posiciona com uma idéia que pode ser mais-ou-menos lida como “qualquer pessoa que não faz desse jeito é um imbecil, um idiota que não consegue entender as ferramentas”. Eu coloco alguns exemplos de pessoas que estão longe de ser idiotas, e que certamente são capazes de entender as ferramentas, e você acha que isso não é suficiente para derrubar o seu argumento. É ou não é dogmático?
Eu passo um link com o intuito de trazer um ponto de informação para você, de forma isenta… e você acha que eu estou “sendo imperativo”, como se eu estivesse te passando um cala-boca. Ao invés de usar sua inteligência para ler o texto e tentar compreender o “meu lado do debate”, você parte pra desqualificação. É ou não é vaidade da sua parte?
Francamente, esta conversa já perdeu o sentido faz tempo, quando você quiser voltar a discutir o tema do seu post eu posso voltar a te responder.
BTW, eu li neste final de semana o texto do Yegge, é simplesmente o pior rant a Java, IDEs, Design Patterns, etc que eu já li na minha vida.
Não se preocupe que agora eu posso falar muito mais do que “o cara viaja”. Vou postar em breve meu comentários sobre o texto em meu blog.