Re: [QD-Filosof ia] Excelência vs liberdade

On Feb  2, 2005, Leandro Guimaraens Faria Corsetti Dutra <[email protected]> wrote:

> Em Wed, 02 Feb 2005 16:06:03 -0200, Ricardo Andere de Mello escreveu:

>> se você leu a resposta do klaus no link que você mesmo deu
>> (http://www.dbdebunk.com/page/page/806810.htm) saberia que o klaus
>> mexe com smalltalk e bancos de dados há muitos anos.

> 	E...?  Conheço muita gente enganada sobre muita coisa há
> muitos anos.

Você percebe que esse argumento funciona pros dois lados?

> 	Eu já trabalhei com bilhetagem e faturamento, devo dizer que
> não conheço nenhum sistema de bilhetagem e faturamento
> decente... todos que vi até agora funcionam com base no sangue, suor e
> lágrimas, não porque sejam bem feitos.

Talvez porque não usem os progressos da engenharia de software
alcançados nos últimos 20+ anos (desde o surgimento dos conceitos de
orientação a objetos)?

> Há questões muitso sérias sobre OO e dados.

Certamente.

> Devo avisar que o juízo da comunidade de dados sobre o Prevayler é
> *muito* severo.

Assim como o juízo da comunidade de programação estruturada sobre OO é
*muito* severo.  Assim como o juízo da comunidade de engenharia de
software tradicional sobre extreme programming é *muito* severo.  Ou
eram, e a aceitação foi aumentando com o tempo, à medida em que os
benefícios se comprovavam mais.  São todos exemplos de quebras de
paradigma.  Significam que talvez os tantos anos de investimento e
pesquisa numa área tenham sido em vão, em face da descoberta de uma
forma muito melhor de alcançar resultados similares.

> Vai quebrar a cara também.  Aliás paradigma é o tipo da palavra que
> ofusca em vez de esclarecer.

Argumento ad-hominem (ou, no caso, ad-palavrorum :-)

> Olha, há 35 anos de pesquisa sobre o modelo relacional, e mais
> ainda sobre sistemas de gestão de bases de dados em geral.  Coisas
> muito básicas como os requerimentos ACID, controles de transações e
> segurança, independência de dados, a teoria dos conjuntos e a lógica
> dos predicados, os modelos gerais de dados...

Exatamente.  Estão fundamentados sobre conceitos que são
essencialmente distintos do modelo de programação concorrente na
maioria das linguagens em uso na atualidade.  Essa diferença de modelo
exige camadas de adaptação, e essas camadas causam dificuldades e, às
vezes, problemas.

O que o Prevayler faz é acabar com a necessidade dessa camada de
adaptação, e aplicar um único modelo aos dados.  Em vez de considerar
a cópia em disco dos dados a cópia primária, considera-se a cópia em
memória a cópia primária, e se aplica a ela o modelo de concorrência
vigente na linguagem de programação Java.  Que esse modelo tem lá suas
dificuldades de implementação, tem.  Mas é o modelo da linguagem.
Adicionando-se a ele a teoria de snapshots, que é essencialmente o que
o Prevayler tira do estado do repositório de dados da aplicação de
tempos em tempos, obtém-se não um banco de dados tradicional em
memória, mas a capacidade de preservar um estado bem definido de um
repositório de dados em memória num meio persistente.

Não há os recursos transacionais, não há múltiplas versões de objetos,
não há logs, não há consultas otimizadas dinamicamente, procedimentos
armazenados, etc, além daqueles codificados na própria aplicação.
Dispensa-se a camada de adaptação para banco de dados porque ela é
desnecessária e até prejudicial nos casos em que o modelo de dados é,
efetivamente, parte de um modelo orientado a objetos, e não apenas um
modelo relacional encapsulado por uma camada orientada a objetos.

> é preciso muita fundamentação para 'quebrar este paradigma', e isso
> nem o Klaus nem ninguém mais nem sequer chegou perto de conseguir.

A fundamentação de modelos de programação concorrente, snapshots e
orientação a objetos está aí pra quem mais se dispuser a estudar.
Quem se fechou no mundo de SGBD provavelmente não viu quando a
engenharia de software e os outros modelos teóricos acima passaram
zunindo.

> Só para introduzir: me aponte para uma descrição do modelo de
> dados de prevalência.

Que tal a descrição do modelo de concorrência de Java?  Tudo bem, há
artigos que apontam erros na descrição do modelo, mas, que eu me
lembre, não no modelo propriamente dito.

> Renato, administração de dados não é arte, é ciência.

Mas felizmente não é a única ciência.

> O fato, no frigir dos ovos, é que não há nenhuma
> incompatibilidade de OO com o modelo relacional,

Essa é a opinião típica que eu vi em todo cara fechado em SGBD que
tenta ver OO.  O cara deixa pra lá herança, especialização de métodos
e outras coisas mais que são o grande diferencial de OO, e modelam o
que sobrou como tabelas relacionais.  Aí, é claro que não vê
incompatibilidade nenhuma, porque está comparando o modelo relacional
com ele mesmo, e não com OO.

> mas sim com o SQL; e que os BDOO, incluído aí o Prevayler, são um
> retrocesso de 35 anos aos tempos pré-relacionais.

A falácia aqui é a afirmação implícita de que a teoria relacional é um
progresso.  Foi certamente um progresso sobre o que havia 35 anos
atrás.  Houve outros progressos, e infelizmente alguns deles, como OO,
entram em conflito com o modelo relacional, porque o modelo relacional
foca primária e essencialmente nos dados, enquanto o modelo de objetos
foca (surpresa!) em objetos, como entidades que compreendem não apenas
dados, mas também modelos de comportamento e encapsulamento.

A meu ver, encapsulamento é uma idéia fundamentalmente incompatível
com modelo relacional e, no entanto, é um dos pilares do modelo de
orientação a objetos.  Modelos de comportamento (métodos) não são
apenas procedimentos pré-otimizados ou restrições a modificações para
fim de preservação de consistência: são a única forma de interagir com
um objeto, num modelo OO puro.

> Se o Klaus ou qualquer outra pessoa tivesse conseguido fazer
> isso, não precisava usar mumbo-jumbo de prevalência ou ficar
> comparando com Oracle.  Bastava se colocar.

Ele não conseguiu um SGBD.  Ele desenvolveu um sistema que tira
snapshots do estado relevante de uma aplicação para posterior
recuperação em caso de falha.  Só isso.  Não carrega toda a semântica
adicional de um SGBD porque ela não só é desnecessária para algumas
aplicações, ela é incompatível com o modelo de programação em que
essas aplicações são desenvolvidas.

> 	Tirando isso, há as famosas camadas de persistência... o
> Prevayler é na verdade isso, uma camada de persistência que tenta
> fazer o trabalho de um SGBD, mas sendo apenas arquivo...

Não tenta fazer o trabalho de um SGBD.  É *apenas* uma camada de
persistência.  E muitas vezes isso é exatamente o que você precisa.

> Eu sei que pode parecer incrível a um programador, mas dados
> não é uma área que dependa somente da experiência.  Há um corpo
> teórico, um conjunto de requisitos conceituais.

Uau!  Sabia que os bancos de dados são desenvolvidos por programadores
que, supostamente, se apóiam não só na teoria de BD, mas também nos
modelos teóricos das linguagens de programação utilizadas para
garantir o bom comportamento das aplicações que desenvolvem (no caso,
o BD)? :-)

Sinto em informá-lo que BD não é a única frente de pesquisa em
computação que se apóia fortemente em teoria.  Não é a primeira, e
nem vai ser a última.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

_______________________________________________
Quilombodigital-filosofia mailing list
Quilombodigital-filosofia-lWjjnNBg0S7cOli+L/M/[email protected]
http://listas.quilombodigital.org/mailman/listinfo/quilombodigital-filosofia