Sobre Frameworks…

December 21, 2007

Eu odeio frameworks. Não um ódio assim que faz pensar em mandar emails ameaçadores ao criador do ASP.NET, nem um ódio que me faça pensar colocar um vírus no computador de algum líder do projeto Jakarta que só permita que ele edite seu código usando Notepad (ou edlin) para o resto da vida. É um ódio de quem tem a sensação de que algo está fundamentalmente errado na forma como os desenvolvedores produzem e consomem frameworks de software.

Quando eu digo isso, a reação tradicional é: “Lullis, você quer o quê? Que todo mundo reinvente a roda? O que você sugere?”

Só posso responder com uma outra pergunta: você conhece o Método Socrático? Maiêutica?

Se você sabe, ótimo. Como eu não tenho como conferir sua resposta, vou tentar dar a minha explicação: o método socrático é um modo de tentar produzir novas idéias (complexas) a partir de um jogo de perguntas e respostas para conceitos mais simples que pertencem ao mesmo contexto.

Por exemplo, suponha que você esteja querendo ensinar cálculo de potências para uma criança. Como um matemático “formal” tentaria transmitir esse conhecimento? Apresentando uma série de colorários, princípios gerais e tentando mostrar todas as definições para a criança, até que ela consiga repetir todos os métodos utilizados pelo seu professor na obtenção de respostas para os problemas pré-estabelecidos.

Um professor que estivesse usando o método socrático certamente começaria fazendo perguntas para as quais os alunos já soubessem. “Usando notação matemática, como vocês fariam para escrever ‘quatro vezes quatro vezes quatro’”? “E se eu quisesse repetir a multiplicação 10 vezes?”. “E se eu quisesse multiplicar infinitamente?”. “E se eu quiser dividir repetidas vezes, ao invés de multiplicar?”. “Quanto é 1 multiplicado por 1?” “Quanto é 1 multiplicado por 1 multiplicado por 1… 100 vezes? E 1000 vezes? E 10?”. Ao deixar as crianças responder essas perguntas, elas mesmas passam a observar os princípios gerais por trás das fórmulas matemáticas. Através da intuição, elas desenvolvem quase que por conta própria uma nova “unidade de conhecimento”, ao invés de tê-la transmitida através de um mestre. Um professor socrático atua muito mais como um guia, do que como uma bússola.

Qual sistema é melhor? Muito depende do seu objetivo. Alunos das duas escolas conseguirão responder que A^(-x) é igual (1/A^x). Um o fará quase que por instinto, condicionamento mental. O outro pode até não ter isso cravado em sua cabeça, mas chegará à resposta se tiver desenvolvido a habilidade de saber fazer as perguntas certas. “Se ao incrementar o expoente eu multiplico a base, o que aconteceria se eu diminuísse?”

Computadores são inúteis. Eles só sabem dar respostas.

No espiríto do Método Socrático, eu pergunto: o que acontece numa situação em que as perguntas não possuem uma resposta catalogada?

Provavelmente, o aluno de métodos mais tradicionais (digamos, alguém que passou tempo demais estudando Kumon) vai travar, ou voltar para o seu mestre, na esperança de obter as respostas que faltam. Ainda que ele seja capaz de responder por reflexo a equações derivadas de segundo grau, ele não saberá por onde começar caso tenha que jogar Petals around the Rose.

Certo. E o que isso tem a ver com frameworks?

Escreva “define: framework” no Google. Um dos termos que você encontrará é “sistema de regras, idéias ou princípios que é usado para planejar ou decidir algo.”

Olha só que interessante: ao tentar explicar para você sobre o Método Socrático, eu acabei achando uma das melhores formas de explicar o meu desgosto por frameworks de desenvolvimento.

Frameworks, em sua essência, acabam sendo um “pacote fechado” de soluções prontas para alguém que tem um problema a ser resolvido. “Se você está desenvolvendo um aplicativo e precisa de uma integração Web, use o framework XYZ que te dá autenticação de usuários, geração de código HTML a partir dos seus dados, servidor HTTPS e no fim do dia ainda te faz uma massagem nas costas”. “Se você quer desenvolver software para sistemas embarcados, use o nosso DevKit e você terá um emulador em seu computador, configuração de diversos setups em software, cross-compiler e no fim do dia ainda te daz uma massagem nas costas.”

Se ao menos as promessas de massagem fossem verdade…

O problema, ao meu ver, é que alguém (indivíduo ou grupo associado) que decide implementar um framework se coloca na posição de detentor de um pilha de conhecimento como se fosse “a única verdadeira solução”, quando na verdade esse alguém possui apenas uma compilação de regras e receitas usadas na resolução dos problemas dele. Ou, pior, é uma empresa que está tentando criar a solução definitiva. E, devemos saber, isso não existe.

Outra coisa a se pensar – ao menos para os desenvolvedores web – é que a velocidade do surgimento de tecnologias é muito rápida. Mais rápida até do que a capacidade do grupo de assimilar e sedimentar qualquer forma de conhecimento que possa se transformar em um “pacote fechado.” Aí, logo depois que qualquer sistema começa a se consolidar, já haverá parte do grupo tentando forçar a adoção das novas tecnologias e paradigmas, levando ou a um sistema que é abandonado e preterido em favor da Próxima Grande Tecnologia, ou haverá um produto torto, sem identidade. Jack of all trades, Master of none.

E os desenvolvedores que são usuários desses frameworks, meu Deus? Passam tanto tempo aprendendo a lidar com os problemas, aprendem todas as formas de contornar as falhas de design, decoram tantos lotes de informação que, no fundo, acabam tendo que reaprender sistemas inteiros. Tornar-se verdadeiramente produtivo com o tal framework é quase tão trabalhoso quanto implementar você mesmo as funcionalidades prometidas. Que vantagem há nesse processo?

Qual a alternativa?

Seguindo a analogia, o nosso Software Socrático não é desenvolvido em cima de uma plataforma ou de um framework, mas utilizando pequenos componentes mais simples e que já são conhecidos suficientemente. Esses elementos menores seriam as unidades de conhecimento necessárias para que, através da intuição, possamos chegar a uma solução que produza o resultado esperado.

Um guia, não uma bússola.

posted in Desenvolvimento, Design, Teoria by Raphael Lullis

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

  • http://log4dev.com Miguel

    Raphael, prevejo discussões tenebrosas e longas em relação a este tema. Apesar de não odiar frameworks, eu sou adepto a implementação de soluções caseiras quando me parece que o framework me trará mais problemas do que vantagens. Já fiz isso em relação a gerenciamento de componentes (não usei Spring) e em relação a acesso à base de dados (não usei Hibernate). E te garanto que fui mais feliz.

    O problema é que, sobretudo no mercado business dominado por Java, existe uma crença de que os frameworks mantidos e testados pela comunidade e por ultramastergeeks da computação são infinitamente melhores do que qualquer coisa que eu, pobre desenvolvedor, posso fazer durante minha vida toda. E aí começa a discussão. Espero nosso amigo, cujo nome não vou citar mas que todos que conhecem o blog sabem quem é, vir dar sua opinião.

    Vai pegar fogo. Eu sei, ja passei por isso :-)

  • Tiago Granato

    Bem caracteristico da sua mentalidade de trabalho Mr. Lullis, R.

    Outro dia eu li em um blog a seguinte frase: “Good hackers search for an environment with no rules, in other words, which can answer anything without pre-defined behaviors.” Acho que isto resume de maneira sucinta o seu texto.

    Eu concordo com seu ponto de vista! Mas nao tem como deixar de salientar a extrema utilidade que frameworks podem ter em projetos pontuais! O objetivo é atingido mais rapidamente e o desgaste com a procura da resposta certa é consideravelmente menor, maximizando lucros e otimizando o tempo de projeto

    []s

    Granato.

  • http://www.via6.com/topico.php?tid=139776 Miguel via Rec6

    Log4Dev » Sobre Frameworks…

    Eu odeio frameworks. É um ódio de quem tem a sensação de que algo está fundamentalmente errado na forma como os desenvolvedores produzem e consomem frameworks de software….

  • http://log4dev.com Leonardo Garcia

    Raphael,

    Eu até concordo com muitas das coisas que você disse. Mas quando seu chefe fala que você precisa fazer um sistema de “autenticação de usuários, geração de código HTML a partir dos seus dados, servidor HTTPS” porque no final do dia ele tem uma massagem marcada para se desestressar do atraso no projeto causado por você, o que você faz? Começa a se fazer perguntas básicas tentando achar um guia para tudo isso ou vai para o Google e acha o “framework XYZ” que resolve tudo isso pra você até o outro dia de manhã?

    Talvez eu esteja sendo um pouco pragmático, é verdade. Mas com o tempo talvez os meus trabalhos tenham me tornado mais pragmático do que eu já era naturalmente.

    Mas ai vem uma outra pergunta minha: é claro que os frameworks limitam a sua imaginação como programador. Mas porque eles não podem ser bons? Em geral, as pessoas que constrõem frameworks realmente precisam resolver determinados problemas. E, em geral, elas gastam boas horas pensando e desenhando este framework para que ele seja minimamente utilizável. E, portanto, pode ser útil sim para muita gente.

    É claro que sou contra a idéia de que frameworks são a solução para todos os problemas. Mas eu também diria que sem um bom framework certas tecnologias nunca seriam adotadas. Mesmo que elas fossem ótimas.

    Um abraço,

    Leonardo Garcia

  • Miguel Galves

    Leo, respondendo pelo Raphael, depois ele ve se me desautoriza ou não. Acho qu eé importante salientar que NÃO GOSTAR DE FRAMEWORKS não quer dizer ter aversão por códigos externos, escritos por outras pessoas. Quer dizer preferir usar libs pontuais, que resolvem o problema do HTTPS, da geração de HTML e de autenticação e que você tenha a liberdade de montar como quiser.

    Frameworks, como seu nome indica, oferecem um quadro de trabalho, no qual você tem que se inserir, e é este o problema que o raphael vê, certo?

    Resumindo: o problema não é o uso de código alheio. O problema é quando você tem que se adpatar ao código alheio, e não o código alheio se adaptar a você.

  • http://log4dev.com Leonardo Garcia

    Miguel,

    Eu até entendo o que você esta dizendo e acho que o Raphael deva pensar assim também pelo que conheço dele.

    Mas talvez a questão mais importante para mim seja uma que você também levantou: “frameworks mantidos e testados pela comunidade e por ultramastergeeks da computação são infinitamente melhores do que qualquer coisa que eu, pobre desenvolvedor, posso fazer durante minha vida toda.”.

    Como disse, não acho que a solução para tudo seja frameworks grandes e complexos, mas acho que simplesmente dizer que eles te limitam e por isso você não os usa, sem nenhum tipo de avaliação mais detalhada, é pouco produtivo.

  • Miguel Galves

    Leo, eu não disse que eu acho isso. Disse que esta é a crença geral da comunidade. Eu não acredito piamente nisso. Ou melhor: acredito que uma equipe que trabalhe fulltime num projeto consiga produzir coisas mais elaboradas do que eu eventualmente faria em algumas horas ou dias. Mas isto não quer dizer que este código ultra elaborado seja mais adequado em TODOS os casos para meu projeto do que um que eu mesmo fiz.

  • http://log4dev.com Raphael

    Léo, a resposta do Miguel resumiu perfeitamente.

    Só adicionando mais uma coisa, servindo de resposta para o Tiago, também: se o software que você está adicionando resolve apenas um problema secundário ao core business da sua empresa, então o problema do “Fator Framework” se reduz.

    Exemplo: se você trabalha no mercado financeiro e você trabalha com internet banking, ter um website moderno, que permita autenticação com OpenId ou outro sistema distribuído de autenticação é algo totalmente supérfluo. O valor agregado do seu produto não está em oferecer uma experiência de internet nova. Pelo contrário, até. Pessoas querem um produto “quadrado” em que elas sintam confiança. Nesse caso, usar um framework testado, consolidado e que foi feito pensando nisso é o caminho óbvio.

    Por que isso? Porque seu objetivo, no caso, é apenas oferecer um produto robusto. Pode ser uma caixa cinza e quadrada, monótona. Mas você está sendo pago não pra oferecer uma caixa moderna e high-tech. Você está sendo pago para construir uma caixa sólida, cinza e quadrada. O core business do mercado financeiro não é o “high-tech”. É o “sólido, quadrado, robusto”.

  • http://log4dev.com Leonardo Garcia

    Raphael,

    Você usa frameworks? Ou seu ódio é tão grande que você sempre dispensa eles?

  • http://bpfurtado.livejournal.com Bruno

    Não seria Maiêutica a grafia correta? :)

  • Sérgio JardimN

    Frameworks são apenas ferramentais úteis. É como aquela velha frase: “Aprenda a calcular para depois usar a calculadora”.

    Não se pode negar que tarefas repetitivas como validação de formulários são perda de tempo para o desenvolvedor experiente.

    É recomendável, creio eu, o uso de frameworks (de qualidade), para aumentar a produtividade da empresa e deixa-lá tratar da parte inteligente do processo, de resolver os verdadeiros pepinos e criar as soluções bacanas.

    Os problemas maiores dos frameworks não são suas convenções e objetivos primários, mas sim quem os usa de forma imbecilizante. É impressionante a quantidade de gente que sai mais burra do que entrou numa faculdade, sem capacidade para pensar além do que está escrito na IDE…

  • Raphael

    Bruno, meus dedos disléxicos pedem desculpas.

    Erro corrigido.

  • Henrique

    até que enfim alguém que tenha a mesma opinião que eu !!!

  • http://rnaufal.livejournal.com Rafael Naufal

    Raphael,

    não entendi o teu texto quando vc menciona que odeia frameworks de uma maneira tão veemente e te explico o motivo. Batendo um papo uma vez com o Miguel sobre o Job4dev (que acredito que teve um resultado final mto bom, com um excelente UI design e um look and feel clean), ele mencionou que vcs o construíram com o suporte que o Django provê em termos de aplicação Web. Acessando o site do Django, me deparo com a seguinte definição:

    Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

    Python ainda é um dos meus ramos de interesse e pelo que vi do Job4Dev a utilização do Django pareceu-me mto produtiva para sua construção, permitindo a liberação do Job4Dev em tão pouco tempo. Agora não entendo sua crítica tão forte aos frameworks, pelo simples fato de vcs terem utilizado um para construir o Job4Dev. Será que a construção do Job4Dev teria sido tão produtiva assim sem o apoio de um framework?

  • Raphael

    Rafael,

    Leia o post do Miguel sobre “Construindo o Job4Dev”. Lá ele conta uma versão bem sucinta e correta do que aconteceu. O Miguel já estava com algumas versões preliminares, algumas idéias sobre como funcionaria o fluxo do Job4Dev. Eu peguei um feriado do mês de novembro – dois dias – e fiz a “minha versão, com os meus pitacos” usando web.py. O Miguel gostou, pegou o front-end: css e templates, e jogou no código dele, em Django. Ficamos mais um dia ou dois brincando de “o meu é melhor que o seu”, onde um implementava uma funcionalidade, e o outro replicava. Exemplo: ele “acertou” primeiro a parte de RSS, então eu puxei a template dele. Eu “acertei” o formulário, ele portava pro código dele…

    Depois desses dois dias, quando chegou a hora de lançar pro público, os dois sistemas estavam sistematicamente similares. Mas eu jamais teria a intenção de seguir adiante com o meu projeto. Usei a minha implementação apenas como uma forma de testar idéias. No instante que essas idéias estavam criando vida, passei a ajudar o Miguel só a parte de deploy do aplicativo dele, além de testes e bug-fixing.

    O engraçado: as coisas que você elogiou a respeito do site (obrigado, obrigado) não são características que foram viabilizadas pelo Django. É CSS e (perdão a falta de modéstia) bom senso de design e usabilidade. E isso, não há framework que consiga ensinar a ninguém.

  • http://bpfurtado.livejournal.com Bruno

    Raphael, já que você deu esta deixa toda filosófica, comecemos como os conselhos do sábio doctor Lecter:

    First principles, Clarice. Read Marcus Aurelius. Of each particular thing, ask: What is it in itself? What is its nature? What does he do, this creature you seek?
    1 – Conceito: Um framework lhe propõe uma série de vantagens ou serviços para que auxiliar o seu work, mas para tanto ele precisa que você siga um determinado protocolo, ferramental, é a parte frame.

    2 – Contexto: Peguemos como exemplo a roupa e equipamento de um mergulhador de altas profundidades. Seu equipamento lhe proporciona oxigênio, temperatura adequada, medidores de pressão, luz para melhor visibilidade, etc.

    Imagine uma pessoa utilizando todo este ferramental em um mergulho à digamos 30 metros de profundidade, faz todo sentido não?

    Agora imagine todo o mesmo equipamento agora num mergulho de 5 à 10 metros em um mar calmo, quente e tranquilo. Parece meio exagero não? Um simples snorkel faria muito mais sentido né, o mergulhador não precisa de tudo aquilo…

    Agora imagine todo este equipamento em uma pessoa brincando em uma piscina olímpica… hmmm agora já passamos a barreira do ridículo. Um óculos de natação e uma simples sunga seriam mais do que suficientes.

    Agora imagine tal mergulhador usando todo este equipamento para andar no seco!! Para digamos alugar um vídeo na locadora do seu bairro. Well, ultrapassamos os limites do bom senso.

    Pois é, em todas estas diversas situações que muitas pessoas usam frameworks complexos com equipamentos profissionais de mergulho e até mesmo o famigerado JEE.

    Este é meio primeiro ponto: O uso descabido de certos frameworks fora de um contexto adequado gera um ódio totalmente infundado por estes.

    3 – Conceito vs Implementação: Muita gente confunde totalmente as bolas porque usou um framework tem determinada faceta sua muito mal implementada e acha que frameworks em geral são ruins. Vamos pegar o exemplo clássico da configuração necessária para os componentes dentro do esquema EJB na era pré Annotations. Era ruim e trabalhosa, era, de fato. Mas nem por isto eu vou criar meu próprio ferramental para politicas simples como transações distribuídas, clustering, etc.

    E pior ainda, não dizer que frameworks são ruins simplesmente porque você usou um que seja ruim, ora, você acha que o conceito do automóvel é ruim porquê você comprou carro ruim? Exitem fuscas e existem mercedes, o conceito de veículo é o mesmo! Com frameworks é a mesma coisa, pois um framework é um conceito apenas.

    4 – Restrição de Criatividade…: Eu não poderia discordar mais de você neste ponto. Pegue um exemplo clássico de um dos frameworks mais utilizados no mundo java nos últimos tempos, Servlets. Faz parte do meu negócio (digamos uma loja qualquer na web) entender todos os pormenores (e não são poucos) do protocolo HTTP, métodos GET/POST, HEADERs de requisições, etc? Eu preciso saber o básico, certamente! Agora eu preciso escrever software para resolver estes problemas todos só para fazer minha loja web!?! A resposta é: precisaria! Se não fosse o utilíssimo framework Java Servlets. Com ele eu só preciso escrever um método (e.g. doGet) e programaticamente obter os parâmetros da requisição HTTP e responder também facilmente simplesmente executando prints na saída padrão.

    Onde está o corte da minha criatividade? Da mesma forma os serviços dos quais os meus EJBs se valem não são parte do meu negócio a ser resolvido, de maneira alguma. O mesmo se aplica ao Spring e a tantos outros milhares de frameworks presentes no mundo Java.

    A natureza dos frameworks é prestar serviços de infra-estrutura e não se meter na lógica do negócio a ser resolvido, eu queria muito ver pontos que ilustrassem que o conceito de framework representa o contrário.

    Nunca o uso de frameworks web (ou de qualquer outra natureza) vão tolher minhas opções para experimentar as mais criativas soluções para resolver problemas. Por pior implementado que seja um framework, ele sempre trata de serviços de base, scaffold e não suas regras de negócio.

    E francamente, você sempre pode ignorar um framework e escrever seu código a sua maneira quando necessário, é como as pessoas pensarem que o Hibernate vai surgir como um poltergeist da tela do seu PC para lhe jogar itens da sua escrivaninha caso você ouse pensar em usar JDBC, hehehe, um erro crasso e pior, uma interpretação errônea bem comum.

    5 – Conceito (mais detalhado): Frameworks são soluções inteligentes para aumentar o grau de reuso de determinados pedaços de código. Em geral você codifica apenas o que não diz respeito a responsabilidade do framework e seu código fica então muito menos poluído e portanto manutenível, com maiores chances de escalar (estou falando de quantidade de código).

    Diversos padrões de desenho são recorrentes nos modelos de tais ferramentas. Seu uso é mais do que amplo no mundo do desenvolvimento de software, não por comodismo e ignorância de gerações inteiras de profissionais e acadêmicos, mas sim por promover o reuso de software de maneira efetiva, por existirem ótimas implementações utilizadas já a exaustão e nas quais inclusive outros frameworks puderam ser construídos.

    6 – Complexidade: Podem ser ferramentas (assim como aparelhos profissionais de mergulho) complexas pois oferecem serviços complexos, mas nem por isto devemos aceitar que sejam complicadas de operar, e em muitos casos realmente são, sem que isto fira o seu conceito (vide o exemplo acima do automóvel).

    A adição de complexidade é sempre bem vinda quando o seu preço é facilitar as operações mais críticas, necessárias ou numerosas do seu sistema. É sempre uma questão de qui pro quo, você adiciona complexidade aqui para ter facilidade logo ali, e que a facilidade venha num ponto interessante para suas necessidades.

    Eu não tenho esperanças que o uso de soluções complexas como diversos frameworks (e o próprio conceito exige certo raciocínio abstrato) seja algo popular entre as massas. Imaginem D. Knuth ou mesmo A. Kay me ouvindo dizer que frameworks são complexos…

    7 – Considerações finais: Raphael, você critica um conceito fundamental da nossa caixa de ferramentas como desenvolvedores de software, mas uma caixa mais sofisticada, a caixa de ferramentas do raciocínio abstrato.

    Não concordo com a analogia com a Maiêutica pois já não concordo com a sua visão sobre frameworks.

    PS. Decidir numerar as seções do meu texto, pois daria muito mais trabalho fazer algo fluído.

  • Raphael

    Bruno…

    WTF?

    O conceito do automóvel é ruim ou bom, tendo eu comprado ou não. O conceito do automóvel pode ser visto como ruim por ser ineficiente na relação eficiência de transporte, consumo de combustível, espaço físico que consome, recursos naturais que são necessários, etc, etc.

    Por outro lado, podemos dizer que um automóvel é bom por dar a capacidade a um único indivíduo de se transportar por longas distâncias.

    No fim das contas, cada um vai dizer “eu acho que é bom” ou “eu acho que é ruim”. Mas não podemos negar certos aspectos da natureza do veículo.

    Precisa que eu faça a analogia para a questão do framework, ou quer que eu desenhe?

  • http://bpfurtado.livejournal.com Bruno

    Raphael,

    Se você realmente acha que o conceito de framework é ruim, você deveria se atentar a quantas e quantas vezes você utilizou algum. E garanto que por mais que você reclame você já se valeu das funcionalidades providas por eles em muitas situações.

    Fora que é algo mais ou menos intuitivo, procurando o reuso seja em uma linguagem OO ou funcional, arquiteturas baseadas em frameworks vão sempre existir.

    Eu só queria entender de vez uma coisa, sua crítica mesmo é em relação ao conceito de frameworks? Ou a má implementações ou uso fora de contexto (como eu tentei explicar acima)?

  • http://log4dev.com Raphael

    Bruno,

    Relax. Estou no fim do mundo, a.k.a Vale do Paraíba, e estou lutando com internet discada. Vou tentar acabar o post de hoje. A discussão fica pra depois.

    Bom Natal.

  • http://log4dev.com Raphael

    Só pra pensar…

    Se você realmente acha que o conceito de framework é ruim, você deveria se atentar a quantas e quantas vezes você utilizou algum. E garanto que por mais que você reclame você já se valeu das funcionalidades providas por eles em muitas situações.

    Vou manter a sua analogia de “conceito de framework” e “conceito de automóvel” para reescrever o primeiro parágrafo do meu texto.

    Eu odeio automóveis. Não um ódio assim que faz pensar em mandar cartas-bomba ao netos do Henry Ford, nem um ódio que me faça pensar em colocar um cano de escapamento de motor diesel no quarto de cada operário que trabalhe na Volkswagen. É um ódio de quem tem a sensação de que algo está fundamentalmente errado como as pessoas pensam em sistemas de transporte, quer pessoal quer de carga.

    Deu pra sacar? Eu uso automóvel? Uso. Isso quer dizer que eu gosto? Não! Isso quer dizer que eu defendo o automóvel como a solução única e definitiva? Não!

    O que eu defendo é o seguinte: “Porra, vamos buscar uma outra alternativa? Tudo bem que antigamente essa era uma solução adequada, talvez a melhor possível. Mas quando você fica sabendo que uma cidade como New York tem 1/6 do seu trânsito causado por pessoas que – ao invés de estarem em locomoção – estão procurando um lugar pra estacionar o seu carro, fica claro que há alguma coisa errada no design do sistema de transporte baseado em automóvel e rodovias.

    Quando você vem falando “ah, mas você usou muitas funcionalidades, logo isso é bom e não pode reclamar.”, eu digo que é bobagem. Se eu ficasse apenas reclamando e não estivesse buscando uma alternativa, até te daria razão. Mas estou buscando uma alternativa, estou formulando uma proposta.

    Sacou?

  • http://bpfurtado.livejournal.com Bruno

    Raphael,

    Depois das festas continuamos então.

    Feliz natal para você e todos ai do log4dev, leitores e blogueiros!! :D

  • http://www.useinet.com.br Carlos Daniel de Mattos Mercer

    Isso me lembra a velha história do software, compro, modifico ou faço do zero?

    Acredito que cada caso seja um caso, mas convém testar as 3 opções antes de decidir.

    O problema é quando a decisão vem de cima, vamos comprar, vamos modificar ou vamos fazer do zero, sem análise das demais alternativas.

    Framework por ser peça de software me parece se encaixar também neste mesmo dilema.

  • http://bpfurtado.livejournal.com Bruno

    Raphael,

    Se você vai realmente continuar com a loucura de criticar o conceito de frameworks eu realmente acharia interessante ouvir seus contra argumentos sobre os pontos que eu enumerei em minha primeira resposta.

    E ainda dizer está procurando uma alternativa tendo antes dito que usa o web.py?!?

    web.py is a web framework for python that is as simple as it is powerful.
    Este framework que você tanto elogia me está parecendo nada mais do que uma versão de Java Servlets para Python, correto?

  • Marcos Douglas

    E aí gente, acabou a discussão? Ah, que pena… bom, cheguei muito atrasado também.

    Raphael,

    Sei que este post já tem um tempo razoável e eu nem sei se vc vai ler isso, mas vou escrever assim mesmo.

    A muito tempo eu tenho o mesmo pensamento que vc, de que algo está muito errado. Em todas as empresas que eu trabalhei, utilizávamos frameworks, caseiros ou não, não importa… O fato é que sempre havia alguma coisa para implementar que fugia totalmente à filosofia do framework aí, então, a criatividade tomava conta da situação e o problema era resolvido, mas essa parte ficava totalmente fora da filosofia e estrutura do framework; ficava desconexo.

    Vou dar um exemplo simples: Numa das empresas na qual trabalhei, utilizávamos Delphi. Tinha um framework “caseiro”. Para se fazer um formulário de cadastro, herdávamos de uma classe que já tinha todos os botões de inclusão, alteração, exclusão, pesquisa, funcionalidades para Mestre/Detalhe etc… Bem, se o seu cadastro fosse utilizar tudo aquilo, na mesma filosofia, com DBWare, era fantástico. Mas e quando o cadastro tinha alguns requisitos bem diferentes do usual, o que fazíamos? Simples, “Visible = False” em todos os componentes que não fossemos utilizar, ignorando todos os DataSets (pois este cadastro deveria utilizar uma Stored Procedure, por exemplo), ignorando todos os eventos “maravilhosos” que alguém pensou que cobriria todas as situações, etc. Não quero me estender muito. Mas deu pra ter uma idéia? Espero que sim…

    Hoje eu tento trabalhar utilizando bibliotecas em detrimento aos frameworks, pois sempre haverá situações que o framework não previu, e é aí que as coisas não vão ficar mais homogêneas… o projeto não seguirá mais a mesma filosofia, em todo ele.

    Que bom encontrar pessoas, como vc, que tem o mesmo pensamento que eu. Pensei que eu fosse o único! E como sempre acabo perdendo nesse tipo de discussão, já estava perdendo as esperanças…

    Forte abraço Marcos Douglas

  • http://books4dev.com Raphael

    Marcos,

    Obrigado pelas suas palavras. Fique tranquilo, eu e você não somos os únicos que partilham dessa opinião.

    E, ainda que você fosse o único, não teria por que considerar que “perdeu a discussão”. O simples ato de ponderar sobre o que você observa e defender sua opinião já te faz melhor do que aqueles que apenas seguem o consenso geral.

    Abraços

  • Marcos Douglas

    Raphael,

    Quando disse que perdia as discussões, era pelo fato de não representar a maioria dos desenvolvedores na hora de escolher a tecnologia/linguagem/framework… O framework da “moda” sempre “ganhava”.

    Li o seu post por causa do web.py. Entrei no mundo Python a pouco tempo e estava procurando algo que fosse produtivo mas que tivesse de acordo com minhas convicções. Espero ter encontrado.

    abraços

  • http://bpfurtado.livejournal.com Bruno

    Eu não canso de me impressionar… Quer dizer que se um framework não cobre todas as situações possíveis do universo então a conclusão lógica de alguns é pensar que o próprio conceito de frameworks é inválido… assustador…

    PS: Não me perguntem como eu achei esta thread novamente, a google sidebar do meu google desktop é que ‘popou’ um alerta com este link, mistérios… hehehe.

    PS2: Eu realmente não queria voltar nesta discussão sem fim, mas não resisti, fico cada vez mais impressionado.

  • http://bpfurtado.livejournal.com Bruno

    Todo framework, API ou qualquer pedaço de software que queira alavancar o reuso de código procura endereçar um certo problema recorrente. É sempre uma troca, você injeta complexidade em um lado do seu modelo para permitir que a criação de uma série de outros componentes se dê de maneira mais simples, pois o que todos eles fazem em comum está escrito uma única vez em um ponto isolado do sistema [pausa...] de forma ainda que uma única alteração nesta ‘parte’ comum aos componentes seja propagada de maneira ‘transparente’ e/ou simples.

    SE você não possui de forma recorrente o problema que o seu framework procura endereçar e talvez até possua pouquíssimos casos para os quais ele foi projetado para ajudar, bom… ai a culpa é sua por usar a ferramenta errada no lugar errado.

    Não há como fugir da complexidade, se ela existe de fato no seu problema. Se o seu problema se resolve bem com 2000 linhas de código, então realmente você talvez não precise de uma pilha de frameworks e/ou APIs de terceiros. Que sejam 10.000 linhas ou 20.000, etc.

    Agora se o seu sistema está escalando para 100.000 linhas ou mais, a complexidade provavelmente existe em algum lugar, não adianta você fingir que ela não existe e usar apenas um web.py para todo o ERP, CMS, XYZ da sua empresa. A complexidade existe e é extremamente comum no desenvolvimento de uma classe numerosa de tipos de software hoje em dia, alguém duvida?

    Agora se a complexidade existe cabe ao desenvolvedor de software saber onde injetar mais complexidade (e.g. um modelo OO por exemplo) para aliviar a complexidade de se escrever o que quer que seja mais recorrente dentro do seu sistema. [pausa...]. A questão toda é saber onde injetar esta complexidade para resolver o problema certo.

    A culpa é sua se escreveu metade do sistema para facilitar a escrita de 14% dos casos de uso (a não ser é claro que sejam os 14% mais importantes e difíceis de escrever, hehe). A culpa é sua se escolheu um framework que resolve um problema que você não tem, o que não seja de longe seu principal problema.

    A culpa é sempre do desenvolvedor e suas escolhas, nunca da tecnologia.

  • Marcos Douglas

    Bruno,

    Você está referindo-se ao meu post? Vou considerar que sim…

    O problema não é porque um framework não cobre todas as possibilidades, pois isto é impossível mesmo… O problema é o framework querer cobrir todas as possibilidades! Aí, quando alguma coisa foge do contexto imposto pelo framework, este engessa o código de uma tal forma que, as vezes, é necessário fazer gambiarras para implementar o que se deseja, fugindo totalmente da “filosofia” do framework usado.

  • http://bpfurtado.livejournal.com/ Bruno

    Marcos, se você leu pelo menos minha primeira resposta e ainda sim concorda com o argumentos do Raphael eu desisto.

    PS: O que você disse agora eu comentei em detalhes na minha última resposta.

  • Maurício Kataoka

    Depois de ler todas essas mensagens de uma só vez (nem sei mais dizer como o Google me trouxe aqui), fiquei impressionado e elogio a Rafael, pelo tópico, e a todos os outros, pela elegância e refinamento das argumentações posteriores.

    Acho que tudo que foi dito aqui tem logica e está correto, não vejo como alguns acham que estão discordando de outros.

    Depois de tantas teses e antíteses vou, sem pretenção de concluir nada, tentar iniciar uma síntese. Desconhecendo o furum e a pesonalidade dos presentes, devo salientar que ao contrário de querer ter a “última palavra”, quero apenas descarregar alguns pensamentos que esta leitura me criou, e pô-los a prova aqui, esperando que alguém se manifeste, concordando ou discordando.

    Acho que até mesmo Rafael, o autor, se esqueceu do foco em meio ao debate, que a meu ver era a Maiêutica, ou “parto de idéias”, de onde vem o termo. A EDUCAÇÃO.

    Defendendo Rafael (que me corrija se estiver errado) de forma que nem ele lembrou de fazer, a “raiva” dele está no ensino de frameworks e não no uso delas. Isto faz com que surjam profissionais aptos, mas dependentes de uma ferramenta, ao contrario de profissionais que sejam TÃO capazes de usar uma ferramenta por conhecer sua excência, QUANTO capazes de forjar uma nova e mais adequada ferramenta para um uso diferenciado.

    Acrescentando à analogia do Bruno, se você trabalha na Aqualug (fabricante de equipamentos de mergulho), seu trabalho é “reinventar a roda” a todo momento. Você aperfeiçoa às vezes, também tem que jogar tudo fora e começar do zero para quebrar paradigmas e criar conceitos inovadores, ou uma nova empresa o fará, com certeza.

    Se você trabalha com manutenção de pier, não vai inventar um novo equipamento de mergulho, seu trabalho é fazer a manutenção do pier, e só.

    Mas na formação do mergulhador, ele tem que durante sua formação, aprender a fisiologia do mergulho e a engenharia do pier, se quiser ser um profissional capaz de ver que “algo está fundamentalmente errado na forma como os desenvolvedores produzem e consomem equipamentos de mergulho e ferramentas de manutenção de pier” e, propor, ou ele mesmo inventar, soluções para realizar melhor suas tarefas ou possibilitar novas tarefas que ninguém pensara antes.

    Até aqui foi uma tentativa de sintetizar tudo que foi dito e concordo plenamente.

    Tenho algo a acrescentar a este tópico, e, para tal, vou me basear no própria crença de Sócrates, que se julgava superior a grande maioria dos homens por “saber que nada sabe”. Aviso, de ante-mão, não ter nada a ver com tecnologia, mesmo assim não acho off-topic.

    Ele tinha a consciência de que seu conhecimento jamais seria entendido pela massa e apenas alguns “privilegiados” poderiam ensiná-lo como Anaxágoras de Clazômenas ou aprender com ele, como Platão. Seu indiferença era evidente de tal forma que preferiu a pobreza por toda a vida, a se render ao sufismo, pratica de cobrar para transmitir conhecimento em público.

    É verdade que nem todos que pretendem ser mergulhadores tem capacidade intelectual para desenvolver novos equipamentos de mergulho e mesmo assim podem executar muito bem sua tarefa de consertar o pier.

    Da mesma forma, nem todos terão a capacidade de aprender a programar sem usar frameworks, mas poderão ser bons profissionais e executar bons trabalhos. E ainda deixar sua marca no mundo, embora não revolucionem. Serão “heróis” no sentido arquétipo da palavra, sustentando suas famílias, gerando soluções a empresas e serão felizes.

    Dentro do “saber que nada sei”, alguns, talvez, nunca tenham parado pra pensar que estamos sempre usando frameworks. Mesmo C ou assembler, são linguagens para chegarmos ao microcódigo de um processador, ao qual nunca teremos acesso direto e a maioria simplesmente desconhece.

    Assim como Sócrates, um projetista de processadores poderia ter desprezo ou indiferença, pelos programadores de assembler? C? E quanto aos “utilizadores de frameworks”? Esses então, não mereciam nem terem nascido?

    Este hipotético “projetista socrático”, deveria lembrar que para que ele pudesse desenvolver seu chip, utilizou um computador, com um sistema operacional, provavelmente desenvolvido em C e um software CAD feito em Python, por um “utilizador de framework”.

    Termino, chegando a minha conclusão pessoal, que julgo ser mais “libertadora”, ao estilo filosófico de Foucault:

    Existe uma interdependencia entre todos os seres humanos, assim como entre os programadores e temos que usar o traje certo para mergulhar, brincar na piscina ou ir a locadora. Quando se levanta uma bandeira de que algo deveria ser assim ou assado, como Rafael, embora seja um pensamento logicamente certo, não liberta o ser humano, muito menos é justo com a capacidade individual deste, que pode estar simplesmente aprendendo de uma forma facilitada uma cadeira que pode não lhe ser natural ou adequada, mas que lhe foi conveniente pela situação do mercado de trabalho. Acredito que a maioria das pessoas que trabalham com tecnologia, não estariam, se quase a totalidade das boas oportunidades de carreira não fossem nesta área e se a profissão de, por exemplo, motorista de ônibus fosse respeitada e bem remunerada por, desta, depender o progresso de todas as outras. Mas este mundo só existe na cabeça de Foucault e em poucos e pequenos paízes sociais-democratas.

    Rafael, sei que você, como Sócrates, tem a consciência do “Sei que nada sei”. E como já disse não discordo de nada que tenha sido dito aqui. Só não tenha essa “raiva” dos framework, de seus desenvolvedores ou seus utilizadores. Sócrates, acho que não parou pra pensar que, mesmo as formiguinhas, em sua minúscula capacidade e imperceptível utilidade, podem construir enormes formigueiros e têm grande responsabilidade na manutenção do ecosistema.

    Um abraço a todos e obrigado pelo deleite tecno-filosófico proporcionado.

  • http://books4dev.com Raphael

    Taí, gostei.

blog comments powered by Disqus

Switch to our mobile site

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