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

Verdade.

Me expressei um pouco mal. Me me referia aos que aprendem des do início a "programar" utilizando RADs.. sou totalmente contra isso.

Mas que criar interfaces gráficas na mão é chato, isso é hein!

//Pelo que eu entendi, ele não disse que transforma programadores, //mas sim forma "programadores burros", desses que não //programariam de outra forma.
oops

Daniel.

Ambientes RAD não transforma ninguém em um programador ruim.

Na verdade é um ambiente onde um programador ruim se sente confortável.

Excelente.

Oi !

Apenas completando :

Não é só a questão de não comparar, mas a questão de aceitar e ir em direção a evolução tecnológica.

Dependente de ferramenta... hoje dependemos de um fogão, prato, talheres e panelas para conseguir almoçar. Portanto nosso dia-a-dia tem uma total dependência de ferramentas.

[]'s

Dennes

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

Olá!

Sim, é totalmente relativo. Oque eu quis dizer é que não é nada legal ensinar uma pessoal a programar usando RADs, mesmo que seja mais fácil! Acho que a parte "chata" de algorítimos e lógica de programação não são bem aplicadas utilizando estas ferramentas(quero dizer os conceitos). Acho que todo mundo deveria aprender utilizando um editor de texto simples, um compilador(ou interpretador) e linha de comando. É chato(na verdade não =D ), mas, para mim, funciona!

Bom, era isso ai.

Exemplo? Porque eu considero um "simples site web", tanto o meu site, quanto um "msdn.microsoft.com", por exemplo. Ambos estão disponibilizados via browser, e são de acesso público. Como eu disse posteriormente, esta lógica não se aplica a desenvolvimento das tais "lógicas de negócio complexas" cujos detalhes desconheço.

Não se trata de "possível perda no design gráfico". É bem mais do que isso. Perde-se semântica para posterior indexação do conteúdo por sites de busca, por exemplo. Perdem os padrões web. Perdem a compatibilidade segura entre os browsers (o fato de uma página não seguir os padrões pode causar tal efeito). Antes fosse uma "pequena perda no design gráfico". Isso é o de menos, acerta-se.

Exemplo? O próprio tratamento de conteúdo de exemplo dos CssAdapters:

E o que deveria ser o resultado se fosse semântico:

Aí, neste caso, o que faço? Programo usando as ferramentas de RAD, introduzo o adapter e trabalho usando o adapter pra ele limpar as monstruosidades que o asp.net faz por default, e ainda trocando as bizarrices que o adapter cria? Dois trabalhos?

Pode ser o projeto que for, simplezinho ou extremamente complexo, esta abordagem não me parece vantajosa. E isso porque eu nem fui encucar com a metodologia de trabalho do negócio: No caso do exemplo do menu, há javascript demais aonde poderia ser feito de outros modos, bem divulgados na web aliás, que evitariam uns 5kb de informação pro usuário baixar. É pouco? É. Agora junta tudo num site de grande porte e veja a banda jogada fora, em prol de um desenvolvimento mais rápido. O asp.net acha que javascript é a melhor coisa do mundo, e sai criando menus, eventos, hovers, tudo usando js. Cai em um browser que não usa JS pra você ver: O cara não navega. E são coisas que poderiam ser solucionadas de outro modo.

Você até poderá dizer algo do tipo "isso só faz diferença em 'lógicas de negócio complexas', soluções e sitezinhos não fazem mesmo diferença. Mas, não falo sem nenhum conhecimento de causa: Já trabalhei em projetos bem complexos usando webServices, zilhões de requisições ajax em tempo real, e sei bem o que certos atalhos que frameworks e RADS oferecem provocam quando o bicho pega.

E, principalmente, fato que é bom deixar claro: O design nem é a minha principal preocupação, o buraco é bem mais embaixo.

Hoje? Sim, se preocupa. Mas, não era assim fazem alguns (poucos) anos atrás não. Aliás, estamos em 2008, e, como você bem disse, os CCA SERÃO incorporados ao framework como default (espero).

Tá certo que tem um pouco de "propaganda" Microsoft, mas o que o artigo está enfocando a meu ver, é o papel que Microsoft teve nas ferramentas RADs

Não foi isso que eu entendí não.

Oi !

Se eu pudesse falar de RAD sem falar do papel da Microsoft nele, com certeza falaria, pois sabia que iam levantar o dedo para dizer que é propaganda.

Mas a conclusão que espero colocar em debate é o fato de que o RAD não é um emburrecimento, mas uma evolução e outros fabricantes deveriam se dedicar mais a ele.

[]'s

Dennes

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

Concordo.

Ainda citando QT, que é multiplataforma. Existem varias preocupações sobre a renderização do texto, idiomas e capacidade de tradução, tema, etc.. varias coisas sobre a QT que quando se cria um codigo para varias plataformas precisa de "braço" para ficar bom em varias plataformas.

Em java com swing já tive vários problemas no construtor que gerava botoes em diferentes locais, também.

E principalmente a parte do "código de verdade" que tem que ser feito para rodar nas diferentes plataformas, seria bem mais fácil criar uma aplicação só para Windows em QT ou só para Linux em QT.

Ainda no Desktop também existe vários desses problemas que você citou. E com certeza para Web o buraco é bem mais em baixo, talves até por isso alguns apostam tanto no Flex, esquecendo é claro dos diversos problemas do player para Linux.

Em fim, é realmente complicado achar um cenário perfeito. Qualquer técnica de automação é maravilhosa quando é possível determinar toda a amplitude do cenário. E nem sempre isso é possível.

Citando novamente a Web, hoje boa parte das ferramentas de RAD focam nesse quesito, ainda geram muito "lixo", porém acredito que algumas(como o DreamWeaver) ajudam muito principalmente nesse problema, gerando códigos que são capazes de rodar em diferentes navegadores e suas diferentes versões, não talves muito eficiente com relação aos problemas que afetam a plataforma, mais ainda assim acredito que seja um grande passo.

Porém é claro, concordo plenamente quanto a parte do "lixo" gerado, que em aplicações mais "criticas" aumentam e muito a curva assintótica da aplicação. Esse problema como você comentou é bem menos prejudicial em desktop, porém (lembrando do caso do twitter) pode ser fatal na web.

Oi, Fabião !

Por isso que demorou tanto para existir um RAD para ambiente web e, em minha opinião, ainda não existe.

Quanto a geração de código em excesso, etc, e tal, já indiquei vários links em uma resposta anterior para você.

Neste parágrafo existem vários "porém"s. Você não está falando deste artigo, está ? Acho que você pode estar falando sobre os artigos a respeito do ASP.NET MVC e não sobre este aqu. Como não estão publicados aqui e sim no BufaloInfo, o ideal seria debater esse tópico na lista de discussão do devaspnet.

Além disso a afirmação "cuja Microsoft endossa", caso você esteja se referindo ao MVC, está errada, porque não existe endosso ou falta de endosso. A Microsoft criou um ambiente alternativo aos webforms e smplesmente nos indica para escolher aquele que preferirmos.

[]'s

Dennes

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

"Pois eu tenho medo que estejamos criando somente operadores de RAD. Engenheiros com medo de ponteiros."

Conheço muitos engenheiros que têm medo de ter de trabalhar com arquivos de texto no programa (sim, reset, WriteLn, readln e closefile). E você ainda quer que aprendam ponteiros?

Programadores sim tem que saber lidar com ponteiros, garbage collector, problemas de little endian e big endian, etc. Engenheiros recém-formados têm que saber usar SDKs, APIs, algoritmos matemáticos e fazer especificações. E não a fazer gambiarras em DOS para aprender for, if, while, case e until e esquecer seis meses depois.

Note que eu estou falando "Engenheiro" e não "Engenheiro de Computação".

Oi, Cafuin !

O problema da educação é algo totalente adicional a isso.

Um desenvolvedor .NET pode ser um excelente desenvolvedor e nunca na vida desenvolver um driver de dispositivo em C.

Da mesma forma, o contrário, um desenvolvedor de drivers e API's para dispositivos pode nunca se interessar em desenvolver uma aplicação comercial com .NET

Estamos falando de profissões diferentes que precisam começar a serem tratadas como tal dizer que desenvolver aplicações comerciais sem nunca desenvolver em baixo nível é um emburrecimento, é desrespeitar um ramo profissional.

Um exemplo cinéfilo : No filme Jurassic Park, examine a relação entre os 3 especialistas convidados para o parque e os cientistas que criaram o parque.

[]'s

Dennes

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

Concordo com Cafuin. Conhecer como funciona não deveria ser considerado "dinossauro", e nem quem programa com o notepad bombado. Aplicações embarcadas normalmente necessitam de otimizações absurdas no código, e simplesmente arrastar e colar não soluciona isso.
________
http://nodoadouniverso.wordpress.com
http://cybergalo.wordpress.com

Oi, Oceanos !

Sem necessariamente discordar de nada, mas apenas acrescentando mais variáveis na equação : Será que o profissional que sai da faculdade, da forma como citou, realmente está preparado para o mercado ?

Será que temos cursos profissionalizantes que realmente preencham o buraco restante ?

[]'s

Dennes

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

Eu já fui a um seminário de realidade virtual onde a gente passou mais tempo corrigindo nome de variável escrito errado (no Kate) que de fato usando as ferramentas desenvolvidas pela faculdade. No fim a pegou a ferramenta na internet para rodar em casa no Visual Studio. Rápido, eficiente e sem ter que ouvir um cara ensinar a 20 pessoas como corrigir duas dúzias de linhas de código.

Eu gosto de programação por causa do potencial dela como ferramenta. Alguns profissionais não se podem dar ao trabalho de reinventar a roda e fazer as coisas na mão, quando se pode dispor de uma ferramenta rápida para fazer o que deve ser feito.

Já vi problemas que levam 8 horas serem resolvidos em duas horas programando (e daí pra nunca mais). Um problema que levaria dias programando ser resolvido em 30 minutos fazendo uma planilha inteligente no Excel e deixando um "manual de instruções" nas colunas do lado.

Eu sei usar a tabela Price mas usar PGTO(payment) no Excel dá menos trabalho. Solver ou Atingir Meta pode ser mais fácil de implementar que Newton–Raphson.

Para quem está mais preocupado com a resistência do ar ou com a composição do cimento, a programação deve ser encarada mais como um meio que como o objetivo. Se a ferramenta ajudar, tanto melhor.

Oi, Wallacy !

O ponto que mais destaco ai é o fato da IDE nem sempre ser capaz de suprir todas as necessidades. Isso é uma total verdade, mas apenas indica que ainda não chegamos ao nível de RAD adequado.

Posso falar do ambiente em que trabalho : A IDE não supre todas as necessidades, mas o trabalho com webcontrols fornecido pelo ambiente já é por si só um trabalho RAD, me afastando por completo do trabalho não RAD.

Fato. É a realidade de hoje. Mas essa realidade já começa a mudar. Veja o desafio que propus no 3o parágrafo, de baixo para cima. Consegue executar esse desafio sem nenhuma ferramenta RAD, apenas o Kwriter ?

Isso é um sinal da evolução do RAD e de como ele veio para ficar.

[]'s

Dennes

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

Oi, rod !

Pode depender da ferramenta RAD.

O desenvolvimento de webServices utilizando todas as especificações do W3C hoje é uma aventura que, sem RAD, acho impraticável (alguém aqui já experimentou ?)

O conceito é fundamental, mas quando o RAD chega em seu nível adequado de abstração, acho que poderia ser incorporado em geral ao ensino.

Outro problema a parte é a preparação para o mercado de trabalho.

Não estou dizendo que sua afirmação está errada, mas talvez fosse o caso de criar cursos superiores diferentes, com enfoques diferentes. Apenas talvez.

[]'s

Dennes

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

Existiam ferramentas, por exemplo no LINC II você definia uma tela texto em um "modo gráfico" e dava atributos aos campos (texto, número, moeda, tamanho, apresentação, validação, etc) a partir dai o LINC já gerava os programas para manipular sua tela e a base de dados para suporta-la, no caso de modificações o sistema já modificava e reorganizava seu DB. Quando você acabava de "desenhar" a tela ela já funcionava. Ainda existia a possibilidade de definir procedimentos para serem executados na carga, exibição ou quando fosse salvar a tela. Isso permitia que você sentasse com um usuário em frente ao terminal e fosse desenvolvendo o sistema interativamente, a cada geração do sistema o usuário já podia utiliza-lo e só era necessário fazer refinamentos. Por isso o nome inicial do RAD era prototipação contínua, e os protótipos gerados já eram parte do sistema definitivo, eram mais versões novas do sistema que protótipos.

A ferramenta era tão fácil de usar que acarretava dois problemas, um analista pouco experiente poderia trazer o sistema todo abaixo (imagine mandar reorganizar o DB em um mainframe a cada 5 minutos) e do lado funcional o desenvolvimento do sistema tendia a ser eterno, sempre havia uma coisinha a mais para fazer. Daí que entrava a metodologia para tentar dar um pouco de ordem nessa bagunça.

Isso rodava em mainframes UNISYS, no mundo IBM existiam equivalentes, mas nenhum tão desenvolvido quanto o LINC II.

Se você quiser fazer um pouco de arqueologia em RAD e IDE recomendo que você baixe o Squeak é um ambiente SmallTalk opensource bastante poderoso, lógico que está bastante modificado em relação ao original da década de 70, mas os conceitos básicos são os mesmos. Para ver o que é capaz de fazer com o Squeak baixe o Scratch, é uma VM Squeak desenvolvida para ensinar conceitos de programação para crianças, é simplesmente espetacular o que dá para ser feito com ela.

Ao invés de RAD e IDE estou pensando em escrever um artigo sobre esses ambientes de programação para crianças, Scratch, eToys e Alice. São projetos que a maioria das pessoas da área não conhece e são fascinantes.

Oi, Dennes!

Cara, desculpa, mas acho essa metáfora da panela meio furada... Panela é uma coisa estática e cuja essência/princípio é aberta para todos, qualquer um entende facilmente e tal qual em alguns "Reality Show" de sobrevivência é possível reproduzí-la com materiais encontrados na própria natureza. O RAD pago estaria mais para uma espécie de intérprete que você paga caro para traduzir a comunicação entre você e uma certa cultura/língua. Você não precisa aprender nada, só pagar. Mas não compre ainda! O melhor é que com o tempo você pode continuar sem aprender nada e parar no tempo, pois seu intérprete abstrai pra você as mudanças recentes naquela cultura e língua. E você vai ficando pra trás, só precisa pagar a atualização dele... Ah, talvez mais pra frente seja necessário pagar um curso para você aprender a se comunicar com ele usando algumas novas expressões (que não são na língua alvo)... Na verdade, esse intermediário pode ser um malandro que pode ganhar muito de você nesse esquema... Ainda mais quando o intérprete na verdade já se encontrar desatualizado porque a cultura/língua do momento já é outra e você não percebeu porque ele filtrava os problemas para você... Enfim, se exagero é só pra deixar o alerta. Não gosto de radicalismos e dependendo do contexto as coisas mudam. Afinal, melhor que usar Software livre é procurar ser um Pensador livre. Maelhor que usar Open Source é manter a mente aberta.

Cara, vendido eu não sei, mas que o Dennes adora fazer propaganda da Microsoft em todos os post dele, isso é verdade...

Antes de fazer uma pergunta idiota, pesquise!

Não é acusação, é constatação.
Basta ver o conteudo dos posts...é totalmente diferente dos posts da Patricia, Dori, Cardoso, Leonardo, Ricardo, Marcellus etc...
Estes falam de tecnologia como um todo, as vezes da Apple, as vezes do Linux, do Gmail..enfim....noticias e artigos sobre tecnologias e novidades do mundo da tecnologia...alguns com enfase em determinados assuntos, o Gilson por exemplo so fala sobre fotografias e afins, mas não fala somente sobre uma marca, fala sobre todas.

Essa é a diferença.

Fala Dennes,

Se pode herdar o tipo Int e sobrescrever seu métodos. Se posso também fazer isso:

>>> int(5).__add__(int(1))
6
>>> int(5).__add__(int(1)) == 5+1
True
>>> 5 .__add__(1)
6
>>> float(4).__mul__(int(-2))
-8.0

Porque tudo não é objeto?

Até funções, métodos, definição de classes são objetos que eu posso acessar, mudar e criar novos atributos.

>>> def funcao(a, b):
... return a+b
...
>>> dir(funcao)
['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__getattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name']
>>> funcao(1,2)
3
>>> funcao.__call__(1,2)
3
>>> funcao.__name__
'funcao'
>>> funcao
<function funcao at 0x6a9f0>
>>> funcao.__name__ = 'novo_nome'
>>> funcao
<function novo_nome at 0x6a9f0>
>>> funcao.__name__
'novo_nome'

Não queria entrar nesses detalhes, mas você disse nenhuma linguagem é. Ruby e SmallTalk são muito mais. Python ainda possui mais 2 paradigmas bem diferentes.

[]s

Obviamente, é tudo na realidade apenas um conjunto de bytes na memória.

As únicas linguagens que conheço que realmente tratam tudo, em nível conceitual, uniformemente como objetos são Smalltalk e Ruby. Ambas são em geral um pouco menos rápidas do que as que usam atalhos para baixo nível.

Não importa muito: se estão lentas, joga mais hardware. Tenta jogar mais programadores em um projeto pra ver se decola mais rápido...

*duplicado*

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