Meio Bit - Rapid Application Development - ser ou não ser rápido ? - Comentários

Re: Re: Re: Oi, Cafuin ! Quote: Pois

ironman_br — Sun, 13 Jul 2008 15:23:44 +0000

Que necessidade criar um curso de formação para operadores de RAD?

Cara isso já existe, com cursinhos por ai.

Um profissional deve ter uma formação boa, aprender bem os conceitos e conhecer as camadas baixas, ir subindo na abstração e depois decide em que vai se especializar.

Jabá http://beernotfoundexception.blogspot.com/

Vou reformular um pouco seu

garoa — Thu, 10 Jul 2008 19:56:54 +0000

Vou reformular um pouco seu comentário para ver se vc se toca, ok?

Quote:

pra que ver o que o compilador está fazendo por baixo dos panos??!!!...
Dennes, os compiladores e editores visuais da vida tornam um leigo em um bosta de profissional.

Você soa exatamente como alguém saído da prehistória da Informática, acostumado a programar assembly em batch ao lidar com os novos e sensacionais Unix da década de 70 e seus compiladores de linguagens de alto nível (C e Pascal, quero dizer) e editores visuais como vi, ex e ed. "A perda de performance! O consumo de memória! O terror por não saber o que está sendo gerado!!"

Ah, nada como uma boa dose de perspectiva...

Fora isso, concordo que deve-se aprender a dirigir sem direção hidráulica.

Fala Dennes, Sem problemas,

davidkwast — Thu, 10 Jul 2008 14:01:25 +0000

Fala Dennes,

Sem problemas, as vezes esqueço da palavra debate, discutir é forte demais mesmo.

No baixo nível, não sei até onde é OO e passa a ser bytes de dados e instruções. Só quis deixar claro esse tipo de OO no nível alto não gera problemas de desempenho no Python. O que deixa o Python mais lento que Java e C# é a tipagem dinâmica.

Bom, se quiser debater mais alguma coisa, estou a disposição.

[]s

Oi, David ! Quote: em vez de

Dennes — Thu, 10 Jul 2008 13:47:58 +0000

Oi, David !

Quote:

em vez de tentar usar minhas palavras contra eu mesmo

Pensei que estivessemos debatendo e não discutindo. Minha intenção não chega nem perto disso.

Purismo OO em alto nível todas as linguagens mais sérias já possuem. Então quando citou o purismo no tratamento de objetos, pensei estar se referindo ao purismo em baixo nível, do qual a maioria das linguagens fugiu devido a considerável perda de performance, como citei.

Mas ao falar da separação entre o alto nível e o bytecode, você novamente está falando de purismo de alto nível e isso á é lugar comum entre as linguagens. Por isso simplemente não entendi as afirmações.

[]'s

Dennes

---------------------
CidadaoCarioca
BufaloInfo

Prezado, Se deseja realmente

Dennes — Thu, 10 Jul 2008 13:33:29 +0000

Prezado,

Se deseja realmente algum tipo de debate construtivo, releia os comentários. 10 vezes se necessário.

Tenho certeza que ao final conseguirá - enfim - entender o que escrevi e então sim, escrever algo construtivo a respeito.

Dennes

---------------------
CidadaoCarioca
BufaloInfo

Concordo 100%! O que o

MaRKauM — Thu, 10 Jul 2008 12:55:53 +0000

Concordo 100%!

O que o Dennes tem que entender é que aprender apenas sobre ferramentas é suicício! Como eu já falei em outro post, temos que conhecer primeiro os métodos, depois as técnicas, só então que podemos conhecer as ferramentas!
Se não for dessa forma, criaremos profissionais medíocres e com pouco conhecimento. É necessário partir dos princípios de algorítmos, ensinar a desenvolver em alguma linguagem de nível mais baixo, nem que seja uma pseudo-linguagem igual ao Portugol.
Somente quando essas bases estiverem sólidas é que podemos seguir em frente. Se todos aprenderem apenas com uma ferramenta, imagina o dia em que a ferramenta mudar, não vão nem conseguir encontrar os registros do DNS.

Antes de fazer uma pergunta idiota, pesquise!

Fala Dennes, Bom, não sei o

davidkwast — Thu, 10 Jul 2008 12:52:57 +0000

Fala Dennes,

Bom, não sei o que você entendeu sobre o modo que o Python faz programação OO. Mas com certeza o que eu faço programando vai ser diferente da estrutura do byte-code e com certeza muito diferente quando chegar no processador.

Acho melhor você constatar esse tipo de coisa estudando mais sobre outras linguagens, em vez de tentar usar minhas palavras contra eu mesmo. Com certeza não vou ser capaz de falar as coisas no modo que você quer ouvir, e nem o que você quer ouvir. Não quero colocar na sua cabeça que Python é melhor que tudo que você conhece, mas estou aproveitando essa discussão para mostrar que é outra forma de fazer algumas coisas, com suas vantagens e desvantagens.

Dennes disse:

Oi, David !

Não é birra, é só uma constatação em relação a algo que você havia citado antes :

Quote:

Porque não deixamos os objetos falarem se podem fazer alguma operação com outro objeto, seu valor booleano, sua capacidade de iterar sobre seus dados e outras coisas que vão muito além de getters e setters?

Essa coisa de um objeto dizer tudo que ele pode fazer já existe no Python, e não prejudica o desempenho a ponto de invibilizar aplicações comuns de mercado como Web, Desktop e Servidores.

Se quiser aprender mais sobre esse tipo de coisa:
Objeto que sabe:

se converter para String: http://docs.python.org/dev/reference/datamodel.htm...
se converter para Bool (util quando usando em IF e WHILE): http://docs.python.org/dev/reference/datamodel.htm...
se comportar como uma função: http://docs.python.org/dev/reference/datamodel.htm...
se comportar como número: http://docs.python.org/dev/reference/datamodel.htm...

mais em: http://docs.python.org/dev/reference/datamodel.htm...

Bom, por hoje chega...

[]s

Com certeza vale! Eu já

v1d4l0k4 — Thu, 10 Jul 2008 02:57:50 +0000

Com certeza vale! Eu já conhecia o import this, mas veio bem a calhar... É essa filosofia pythônica que me mantém cada vez mais interessado na linguagem.

Tem um pequeno adendo no Python Culture (http://www.python.org/dev/culture/):

Don't take these 19 aphorisms too seriously -- tattooing them on your body is probably a bad idea, for example -- but it's instructive to contemplate them. Some parallels can be drawn to the guiding principles of extreme programming, most notably the emphasis on "Do the simplest thing that can possibly work".

Another principle is "Correctness and clarity before speed." Most of the code in the Python interpreter and standard library is written in a very straightforward style. The developers aren't interested in making the interpreter run faster at the expense of unreadable or hard-to-follow tricky code. In the past working patches have been rejected because they would have made the code too difficult to maintain.

[sarcasmo=ON]E olha que o Guido não é MVP. É só um BDFL.[/sarcasmo]

----------
Não sou elefante mas encomodo muita gente...

Dennes disse: Bem,

xzerorj — Thu, 10 Jul 2008 02:37:24 +0000

Dennes disse:

Bem, primeiramente eu suponho o ensino de RAD com uma ferramenta boa. Nesse caso, em termos educacionais, pode significar simplesmente uma ferramente em que o professor acredite

Bem eu estava me referindo ao Visual Studio 2005, por quê? Ele não é uma boa ferramenta RAD para você não?

Dennes disse:

Depois, o ensino com RAD não seria abrir código auto-gerado para explica-lo. Isso seria o ensino dos conceitos mais básicos, não o ensino com RAD.

Tem razão... pra que ver o que o RAD está fazendo por baixo dos panos??!!! É bem melhor clicar em vários botões, abas e links, digitar meia dúzia de palavras e no final de tudo submeter o programa ao Suporte Microsoft para eles dizerem que o programa está correto mas não funciona porque eu tenho que aplicar um patch-sei-lá-qual-versão para funcionar corretamente.

Dennes, os RAD's e Wizard's da vida tornam um leigo em um bosta de profissional. Aqui na minha empresa por exemplo, tem um funcionário que há mais de 15 anos trabalha com windows, sempre soube criar um DNS, um DHCP, etc... Mas no dia que fui falar para ele documentar os registros dos DNS ele me olhou como se eu fosse um alienígena, porque não tinha essa opção no wizard do windows... Ferramentas são boas pra uso, não pra ensino. "Para ensino, gafanhoto-san, você deve carregar as pedras antes de poder quebrá-las"

Denes disse:

O ensino de algorítimo com RAD seria usar a ferramenta da forma como seria usada comercialmente, mas criar situações de negócio que obriguem o aluno a criar algorítimos sobre o RAD da ferramenta, situações próximas da realidade.

Novamente você está dizendo que temos que ensinar a usar um produto e não uma tecnologia. O profissional deve aprender a lógica pra poder utilizar qualquer ferramenta, e não aprender a ferramenta e ficar dependente dela eternamente...

Eu por exemplo, quando fiz o curso preparatório para o MCAD, aprendi sobre .NET na linha de comando, com compilar os programas direto na telinha preta. Depois que nós (a turma) entendemos como funciona é que passamos a aprender "A FERRAMENTA", porque a funcionalidade da "TECNOLOGIA" nós já tínhamos aprendido.

Legal você querer fazer merchan da Micro$oft aqui, mas seja coerente com a realidade... Faça posts que nos dêem informação independente, afinal isso aqui não é o MSDN certo?

Re: Re: Re: Re: Não é acusação, é

xzerorj — Thu, 10 Jul 2008 02:15:59 +0000

Concordo com vocês... mas acho sinceramente que os posts do Dennes devem servir de moeda de troca para Microsoft manter um patrocínio no MeioBit.
Taí! Que tal alguns posts comentando como é a infra do POP, qual a solução de backup deles, seus maravilhosos serviços gratuitos??? Já que é pra puxar sardinha, vamos puxar de quem paga ora essas!!!!

Mas falando sério, até pagaria os tais R$ 29,99 só pra não ter que ler mais posts do Dennes.
Há tanta informação sobre tecnologia e ele ainda só consegue enxergar Bill & Cia Foundation...
Fala sério...

Oi, David ! Não é birra,

Dennes — Thu, 10 Jul 2008 02:01:20 +0000

Oi, David !

Não é birra, é só uma constatação em relação a algo que você havia citado antes :

Quote:

[]'s

Dennes

---------------------
CidadaoCarioca
BufaloInfo

Fala Dennes, Não entendi a

davidkwast — Wed, 09 Jul 2008 22:54:35 +0000

Fala Dennes,

Não entendi a sua birra. Se eu tenho toda a liberdade que a linguagem/framework/VM me dá, o que me importa o tratamento interno desses tipos? Sempre entendi que o conceito de VM nasceu para fazer isso mesmo, esquecer que processador meu programa vai rodar.

E não sei se há tratamento diferenciado no Python, talvez sim, porque quando um Float se soma com Int ou vice-versa, a VM analisa ambos e faz a operação certa.

A questão de performance não me preocupa. Já tentei mostrar pelo SPOJ que em alguns casos o Python consegue ser até mais rápido que Java e C#, e muitas vezes consome menos memória e dificilmente é muito mais lento a ponto de invibializar alguma solução. Se isso acontencer, há diversas saídas que aproveitam 99% do código escrito em Python.

[]s

Re: [...] eu brinco dizendo que

davidkwast — Wed, 09 Jul 2008 22:03:09 +0000

Um import vale mais do que mil palavras!!!!!

>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

[]s

duplicado

garoa — Wed, 09 Jul 2008 21:28:43 +0000

*duplicado*

[...] eu brinco dizendo que

v1d4l0k4 — Wed, 09 Jul 2008 21:07:35 +0000

[...] eu brinco dizendo que é melhor esquecer tudo que já sabe e aprender a programar de novo.

Eu tirei esse ano pra aprender Python. Isso que tu disse é a mais pura verdade. E o lado bom disso é que tu "reaprende a programar" brincando - não há como não passar horas no interpretador interativo testando as coisas que você lê por aí.

----------
Não sou elefante mas encomodo muita gente...

Rapid Application Development - ser ou não ser rápido ?

Dennes — Sun, 06 Jul 2008 18:52:35 +0000

O RAD, como ficou conhecido, começou a surgir junto com o Visual Basic. A idéia era permitir o desenvolvimento rápido com um mínimo de código. Tornar possível que o desenvolvedor se concentrasse nas regras de negócio da aplicação que estava desenvolvendo e não em códigos acessórios era o objetivo - mais parecendo uma utopia.

O que antes era lógica e algorítimo se tornou configuração, junção de peças e organização de componentes. A lógica e algorítimo se acomodaram sobre o funcionamento das pecinhas, funcionando como uma cola a fazer toda a junção de componentes para chegar ao resultado final, o sistema.

Toda a evolução pode ser resumida em uma palavra : Abstração. Tanto da roda para o carro, como do Assembly para o Pascal, da interface de texto para a interface gráfica e do Clipper para o Visual Basic/Delphi com RAD a evolução caminhou sempre no sentido da abstração - o individuo ganha a possibilidade de se despreocupar a respeito da forma de funcionamento de elementos mais simples e passa a utilizar estes elementos mais simples para construir elementos mais complexos, tendo a certeza de que os mais simples já funcionam.

Claro que existem momentos em que o individuo precisa voltar a suas origens. Um grande exemplo disso foi a cena de "Naufrago" onde Tom Hanks precisou aprender a acender fogo com os pauzinhos. Nem ele, nem 99.9% da plateia lembravam que para acender fogo com pauzinhos era necessário um fluxo de ar. Fez falta para o Tom Hanks ? Fez alguma falta quando ele ficou perdido em uma ilha deserta depois de um desastre aéreo no meio do oceano. Mas se você não for nenhum paranóico que passou a ir ao dentista sempre antes de pegar um vôo após ver aquele filme, então a abstração de conhecimentos passados não será problema para você.

Existem momentos em que a abstração funciona perfeitamente. Responda rápido : Quantas linhas de assembly você consegue escrever ? Ainda assim consegue programar, certo ? Isso é a abstração.

Mas existem momentos em que a abstração não funciona tão bem. Alguém lembra do Kit 5 ? Foi muito famoso na época do Clipper, mas hoje praticamente não é lembrado. O que deu errado na abstração oferecida pelo Kit 5 ?

A resposta pode não ser tão óbvia, mas ela está lá : Quando a abstração limita o resultado final e a aplicação da criatividade para as necessidades de quem está usando a ferramenta, a abstração é rejeitada e as pessoas preferem utilizar a tecnologia base devido a versatilidade que esta fornece.

Portanto, no avanço tecnológico existem tentativas de abstração que funcionam e tentativas de abstração que fracassam, o Kit 5 é um exemplo de uma tentativa de abstração que não foi para a frente, outro exemplo foram os recursos específicos criados pelo Interdev (e porque não dizer FrontPage), recursos tão específicos que ficavam extremamente presos com a ferramenta.

Por outro lado o avanço tecnológico sempre continua. Na continuidade do avanço tecnológico mesmo as abstrações que eram vistas como boas podem passar a ser vistas como algo ruim. Esse fenômeno aconteceu com o Visual Basic, mais ou menos de sua versão 4 até sua versão 6.

Inicialmente excelente para aumentar a produtividade, aos poucos as tecnologias que forneciam o RAD do Visual Basic começaram a ser discriminadas como sendo técnicas pouco profissionais, funcionando como a assinatura de um sistema amador.

Mas por que isso aconteceu ?

Porque neste período entre a versão 4 e versão 6 do visual basic coincide com o período em que se começou a utilizar bancos de dados client/server. Era uma metodologia nova para a época e os desenvolvedores ficavam confusos com relação a sua utilização.

Ok, tudo bem. Mas o que tem uma coisa a ver com outra ?

Para o R.A.D. funcionar adequadamente com o client/server eram necessárias diversas configurações específicas que muitos desenvolvedores não sabiam realizar. Com isso as aplicações feitas por meio de RAD acabavam com uma performance sofrível e inúmeros problemas.

Quando o desenvolvedor resolvia fazer a aplicação "na mão" (aqui um parentesis : "fazer na mão" se tornou um termo classico do meio da abstração tecnológica, significando burlar a abstração atual, mas podendo referir-se a inúmeros níveis de abstração diferentes. O que hoje é abstrair amanhã será "fazer na mão") acabava como consequencia estudando em detalhes as melhores formas de fazer, ou pelo menos fazendo copy/past de outros sistemas prontos e com isso chegando a um resultado melhor do que o R.A.D.

As técnicas de RAD, porém, se tornavam pobres vítimas do desconhecimento do desenvolvedor. Elas podiam fazer muito melhor, mas eram discriminadas. A grande maioria dos desenvolvedores que dizia que os objetos RAD eram ruins diziam isso por terem ouvido falar ou por alguma experiência não muito técnica com os mesmos.

Não estou de forma alguma inocentando o RAD da época e dizendo que era uma maravilha tecnológica. Não era. Tinha os seus problemas, bugs nos componentes visuais, até muitos bugs nos componentes visuais, porém o RAD não era em definitivo a porcaria que os desenvolvedores faziam parecer, sem nem saber porque o chamavam de porcaria.

Eis então que surge o .NET. Anders Hejlsberg, que já tinha dado uma amostra de seu trabalho com o Delphi, mostrou do que sua criatividade é capaz. Ninguém lembrou de dizer para o sujeito que era impossível, então ele foi lá e fez : Mudou por completo a forma de se fazer RAD, sem porém mudar o seu resultado (os bons resultados, quero dizer)

O conceito de RAD mudou completamente. A sigla e seu objetivo final continuaram sendo os mesmos : Uma forma rápida de realizar desenvolvimento de software, desenvolvendo de forma visual. Mas o meio de chegar a esse resultado mudou. No ambiente não gerenciado, para chegar a este resultado eram utilizados componentes "fechados", que faziam tudo por si só dependendo apenas de pequenas configurações. No ambiente do .NET o RAD passou a ser feito com geração de código. Tudo, cada detalhe do que se arrasta para dentro de um formulário gera código fonte acessível para o programador.

Com o novo RAD, por que fazer tudo na mão ? Na pior das hipóteses utilizavamos o RAD e depois alterávamos o código para ficar da forma como desejávamos, ainda assim ganhando em produtividade. Quantos, porém, realmente criaram o hábito de personalizar o código gerado por um simples windows forms, por exemplo ?

Desta forma a radical mudança no significado do RAD durante surgimento do .NET gerou uma maior confiança por parte dos desenvolvedores, mas nem por isso fez com que os desenvolvedores tivessem que usar o recurso de personalizar o desenvolvimento "manualmente", especialmente porque a Microsoft teve a oportunidade de, criando uma ferramenta nova, corrigir erros de configuração e performance das antigas ferramentas - afinal, tudo começou novamente do zero.

Falamos muito de windows forms até agora, mas e o ambiente web, como se encaixa em tudo isso ?

No principio, era o substantivo. HTML, Javascript, CSS, ASP e nos tempos mais atuais até um pouco de XML. Todos esses substantivos eram necessários para o desenvolvimento de uma aplicação web. O desenvolvedor precisava dominar todos os detalhes destas tecnologias, saber como integrar essas tecnologias e entender como utiliza-las para manipular os protocolos da web e chegar ao resultado desejado.

Várias tentativas foram feitas para se chegar a um nível de abstração ideal. Primeiramente FrontPage e Interdev começaram a fazer uma abstração de forma equivalente a abstração existente no ambiente windows. Porém com toda a complexidade do ambiente web, não agradou. O desenvolvedor ainda estava tentando entender as tecnologias do desenvolvimento web e já lhe era oferecido um nível de abstração mais alto para estudar, mas preso a estas ferramentas. Pouco versátil, o desenvolvedor dispensou.

Então surgiu o DreamWeaver Ultradev. Ao invés de tentar componentes amplos, o DreamWeaver investiu na montagem de código através de wizards, deixando o código a disposição do desenvolvedor (semelhança com .NET alguns anos antes, não ?). Foi um grande sucesso entre os desenvolvedores.

A etapa seguinte foi o surgimento do ASP.NET. O ASP.NET foi uma grande evolução no desenvolvimento web, pois conseguiu dar um enorme salto no nível de abstração do desenvolvimento, aproximando o desenvolvimento web do desenvolvimento windows e sem sofrer rejeição do público por causa disso.

A abstração no ASP.NET divide-se em duas partes que utilizam metodologias distintas : Primeiramente o ASP.NET em si, que se apresenta ao programador como uma nova forma de programar baseada em tags e código e abstraindo muito, muito mesmo do trabalho anterior com técnicas semelhantes a do Frontpage e Interdev.

Mas se o Frontpage e o Interdev deram errado, por que o ASP.NET funcionou ?

Simples : Porque conseguiu fazer uma abstração mais versátil, mais flexivel e aberta a criatividade do desenvolvedor. Enquanto os dois anteriores se baseavam em uma coleção enorme de bibliotecas de código difíceis de organizar, o ASP.NET trazia uma escrita simples de tags que apenas se transformavam em código client em momento da compilação, longe dos olhos do programador. Todo o trabalho do programador poderia ser feito com as tags em alto nível mesmo desenvolvendo no notepad se desejasse.

Mas o ASP.NET trouxe também um 2o nível de abstração : Wizards no Visual Studio para a geração das tags ASP.NET. Wizards e recursos configuráveis de forma altamente flexivel e mantendo o padrão de deixar o código fonte visivel ao programador - só que desta vez um código fonte ASP.NET seguindo a abstração anterior.

A produtividade do desenvolvimento web com o uso do ASP.NET foi as alturas e se tornou um marco na evolução tecnológica para a web. Porém conforme a evolução dava saltos cada vez maiores (em 2005 o salto do framework 1.1 para o framework 2.0 foi muito considerável) se tornava cada vez mais complexo o aprendizado da tecnologia.

Para aqueles que acompanharam a evolução desde o inicio, a tecnologia é um verdadeiro livro aberto. Porém, para quem entra no estudo da tecnologia nos dias de hoje, ver o que o ASP.NET 2.0 é capaz de fazer parecer pura magia e exige um grande esforço para analisar toda a arquitetura do ambiente e compreender como aquilo que inicialmente parece mágica na verdade se encaixa perfeitamente com os conceitos técnicos da web.

Iniciar o trabalho com ASP.NET nas versões atuais, porém, tem um efeito muito diferente de quem acompanhou a sua evolução desde o principio. Iniciando nas versões atuais, o desenvolvedor fica dividido entre dois ambientes : as linguagens base da web e o ASP.NET. É claro que o ASP.NET é muito mais produtivo, mas essa divisão e a dificuldade em compreender os "efeitos de magia" do ASP.NET acabam por gerar efeitos semelhantes ao que outros processos de abstração geraram no passado : Rejeição.

Por isso hoje é muito comum vermos algumas pessoas dizendo "prefiro produzir o HTML na mão", "Não gosto da geração automática de HTML", "fica muito lixo no resultado gerado pela renderização", só que na grande maioria das vezes essas pessoas não tem um profundo conhecimento do ASP.NET para poderem se justificar, se tornando um efeito muito semelhante ao que aconteceu com o R.A.D. entre as versões 4 e 6 do VB.

Não quero dizer com isso que o ASP.NET não tem problemas, que o ASP.NET não possa melhorar em muitas coisas. É claro que pode ! A tecnologia sempre pode melhorar ! Mas comparando-se os problemas que o RAD no ASP.NET (e porque não no framework como um todo ?) tem hoje com os problemas que o RAD do VB 6 possuia, passamos por um processo de evolução inigualável.

Quer um exemplo ? Veja o webcast de criação de uma camada de acesso a dados para web, onde uso o RAD ao extremo demonstrando que ele não apenas é eficiente mas também não gera perdas para a capacidade de manutenção da aplicação.

Assim sendo, quando vejo jovens advogando que preferem fazer "tudo manualmente" ao invés de usar as tecnologias para abstração que temos hoje, isso muito me decepciona. Desde a roda até o carro o caminho do avanço tecnológico sempre foi direcionado a abstração.

O ASP.NET tem problemas com design gráfico ? Eu diria que o Visual Studio até a versão 2005 teve problemas com design gráfico. Mas por que chutar o balde e querer fazer tudo na mão apenas por causa do design gráfico ? Não seria preferível corrigir os problemas existentes para mantermos o alto nível de abstração e produtividade, ao invés de chutar o balde e regridirmos em termos de produtividade ? Que tal assistir a um vídeo sobre como o Visual Studio 2008 lida com design e ver se realmente continua sendo preferível jogar fora toda a abstração obtida e regridir tanto ?

Uma outra clara distorção (campo de distorção da realidade ?) quando desenvolvedores dizem que preferem fazer tudo "na mão" ocorre com a criação de aplicações distribuidas. Eu posso dizer que fiz e ensinei a fazer aplicações distribuidas "na mão". Utilizávamos DCOM em alguns casos e transmissão de XML em outros, montando o XML com o DOM (Document Object Model de XML da Microsoft) e transmitindo com XMLHTTP. E olha que ainda dá para dizer que isso era muito luxo, pois pouco tempo antes tinha que ser concatenação de strings e abertura "manual" de conexões HTTP.

Tá. E dai ? Dai que surgiu o W3C e criou : SOAP, WSDL, WS-SECURITY, WS-TRANSACTIONS, WS-ADDRESSING, isso só para citar alguns dos WS* . Imagine-se tendo que seguir todos esses padrões da forma como faziamos, montando o XML "manualmente". Viável ?

Absurdo. Confesso que eu próprio, no inicio de toda essa padronização, fiquei me perguntando o quanto seria realmente vantajoso seguir os padrões se o volume de trabalho que teríamos para isso seria simplesmente triplicado.

A padronização que o W3C criou nos ensinou uma grande lição : A padronização não tem como objetivo apenas a interoperabilidade, mas também a abstração. A partir do momento em que algo é padrão, então não precisa mais ser feito por uma pessoa, pode ser feito por uma máquina.

Foi exatamente isso que aconteceu com os padrões W3C : A partir da criação dos padrões, seu uso passou a ser automatizado. Passamos do Soap Toolkit para os webServices do .NET e agora o WCF, o conceito de criação de proxys para acesso a serviços se intensificou e tais elementos passaram a ser gerados dinamicamente. Que atire o primeiro webService com suporte a ws-security, ws-transactions e com WSDL aquele que disser que prefere fazer tudo "manualmente".

O ASP.NET pode melhorar mais ? Claro que pode, assim como toda tecnologia. Mas quanto mais os desenvolvedores investirem em sugestões e formas de melhorar a tecnologia, ao invés de chutar o balde diretamente, mais e mais a tecnologia evoluirá. Chutar o balde, querer ter o controle de tudo e fazer tudo manualmente é um retrocesso, ir contra a todo o avanço tecnológico que temos desde a roda. Aqueles que assim fazem podem até estar temporariamente corretos (o que particularmente não acredito), mas cedo ou tarde a abstração, presente na evolução desde a roda, irá atropela-los.

Neste momento temos um novo dilema no mercado de desenvolvimento web : Devemos seguir adiante com o modelo de desenvolvimento que temos ou devemos mudar o caminho para a metodologia alternativa que está sendo proposta, o ASP.NET MVC ? Para entrar mais tecnicamente neste assunto escrevi os artigo Analisando o ASP.NET MVC Framework, Criando uma Cesta de Compras com o ASP.NET MVC Framework e Analisando uma Aplicação ASP.NET MVC. Só espero que não tenha acendido o pavio de um barril de pólvora.