Um sistema pode ser 100% orientado a dados?

Meu novo chefe trabalha neste projeto há muitos anos. Estou aqui há apenas algumas semanas, mas não sei se é possível. Ele gostaria de projetar um sistema "100% orientado a dados".

Portanto, se colocarmos dados suficientes, podemos definir e gerar qualquer aplicativo. Eu consegui pelo menos fazê-lo admitir algumas coisas, como usuários, ou aplicativos devem ter valores predefinidos, mas ele gosta do conceito de estrutura do sistema, interface do usuário e lógica, todos armazenados como dados.

Existem algumas demonstrações de coisas simples e ele basicamente redescobriu algumas idéias simples de programação orientada a objetos e seus sistemas de modelos básicos, mas acho que, em geral, esse objetivo pode ser realmente impossível.

Não sei como é possível definir lógica usando dados sem que o sistema se torne tão complexo que você esteja fazendo a programação real de qualquer maneira.

Eu acho que teoricamente não é porque a coisa que interpreta os dados acaba precisando se tornar completa para descrever o aplicativo, para que você tenha mudado o problema um nível mais alto para nenhum benefício líquido.

É possível um aplicativo orientado a dados 100%?

Seu chefe deve ler este artigo: Bad Carma: O projeto "Vision", um conto de advertência sobre o efeito da plataforma interna ou o segundo efeito do sistema.

Abstrato

Todos nós que trabalhamos em Tecnologia da Informação (TI) participamos de um projeto em que algo importante simplesmente não está certo. Sabemos disso, quase todo mundo sabe, mas ninguém é capaz de apontar o problema de uma maneira convincente.

Esta história é sobre um projeto de TI, a falha mais espetacular que já experimentei. Isso resultou na demissão completa de um departamento de TI de médio porte e, eventualmente, levou à destruição de uma empresa em crescimento em um setor em crescimento. A empresa, que chamaremos de "Upstart", era uma empresa de televisão por assinatura bem-sucedida e lucrativa.

O projeto ocorreu no início dos anos 90, e era um aplicativo personalizado de entrada de pedidos e atendimento ao cliente, semelhante ao que agora é chamado de CRM ou CRM. A funcionalidade principal do sistema incluía:

• Entrada e estoque de pedidos
• Atendimento ao cliente, suporte técnico
• Contabilidade, contas a receber, cobrança e contas a pagar

O aplicativo foi chamado de "Vision" e o nome era tanto a promessa oficialmente declarada para o Upstart quanto um aceno auto-engrandecedor para o arquiteto. O aplicativo foi inovador, pois foi desenvolvido para ser flexível o suficiente para acomodar quaisquer alterações futuras nos negócios. Não apenas quaisquer mudanças futuras previsíveis nos negócios, mas absolutamente quaisquer mudanças nos negócios, sob qualquer forma. Foi uma afirmação bastante notável, mas o Vision pretendia ser o último aplicativo já construído. Ele alcançou essa flexibilidade total por ser completamente orientado a dados, fornecendo abstração ilimitada e usando técnicas de programação orientada a objetos que eram de ponta na época.

Como muitos desses projetos que se propuseram a criar um aplicativo de missão crítica, o esforço de desenvolvimento durou dois anos, cerca de um ano a mais do que o originalmente projetado. Mas isso era aceitável, porque esse era o aplicativo que duraria para sempre, adaptando-se a quaisquer requisitos futuros, fornecendo um Retorno sobre o Investimento (ROI) ilimitado. Quando o aplicativo finalmente entrou em operação, quase todo mundo na empresa havia investido tanto nele que, literalmente, o destino da empresa dependia de seu sucesso.

No entanto, no caso de mau funcionamento total do projeto, não é permitido aos aplicativos de missão crítica que executam o core business das empresas multinacionais o luxo do tipo de explosão rápida demonstrada por milhares de empresas "pontocom" na era da bolha da Internet. Dentro de um mês depois que o Vision entrou em operação, ficou claro para todos, exceto para os que estavam mais fortemente envolvidos em sua construção, que foi um fracasso.

Veja também

http://en.wikipedia.org/wiki/Inner-platform_effect

A resposta é sim, é possível criar um sistema totalmente orientado a dados e sim, geralmente é uma péssima ideia.

Um programa totalmente orientado a dados é aquele em que toda lógica e configuração é tratada por valores armazenados de tal maneira que, em outro contexto, eles seriam considerados dados. Havia muitos produtos 4GL produzidos na década de 1980 que forneciam a capacidade de gerar relatórios, formulários, tabelas e lógica usando itens de dados inseridos em uma multiplicidade de formulários, armazenados em tabelas e acessíveis através de relatórios. Eu costumava me referir a esses sistemas como "pintar por números", mas vejo que agora passou a ser conhecido como efeito "sistema interno". Bom nome.

As pessoas que criam esses sistemas estão tentando (saber ou não) criar uma nova linguagem de programação. Como eles não têm as habilidades, eles o fazem mal. Do ponto de vista da JVM / CLR, um programa Java / C # compilado é simplesmente dados. Nesse caso, foi feito bem. Nos dois casos, é necessário que os programadores usem a linguagem, seja ela qual for.

Existe uma maneira específica de fazer isso funcionar, que eu conheço. Você constrói o esqueleto de cada um dos componentes necessários: formulário, relatório, tabela etc. Você fornece um mecanismo para configurar várias partes desses componentes definindo itens de dados. Para um conjunto escolhido de recursos, você toma as decisões e as congela no sistema e nega especificamente a capacidade de configurá-los.

Você também implementa uma linguagem capaz de codificar operações lógicas. Minha recomendação é usar uma linguagem existente, como lua ou talvez Python. Você incorpora partes desse código sempre que forem necessárias operações lógicas.

Ao fazer isso, você reduz substancialmente a quantidade de escrita necessária para implementar cada formulário, relatório, tabela e assim por diante. O sistema parece ser orientado por dados, mas apenas até certo ponto.

Neste ponto, você acabou de implementar um novo 4GL. Se você fizer isso com sucesso, entre em contato. A maioria das pessoas falha tristemente. Serei o primeiro a parabenizá-lo por sua conquista.

Eu acho que você está basicamente correto. Um tempo de execução de idioma já é um sistema orientado a dados totalmente flexível. Ele pega um dado (o programa) e o utiliza para determinar como deve agir em outros dados. Pode até ter um esquema multiusuário para armazenar código para reutilização por outros programas (desde um caminho de inclusão até o gerenciamento adequado da instalação).

Uma "linguagem de script", grosso modo, é um tempo de execução de idioma em que essa entrada de código é legível por humanos. Um compilador coloca uma etapa extra entre o usuário e o tempo de execução. Linguagens de "piadas" como Malbolge e APL não precisam ser legíveis por humanos de nenhuma forma. Mas é tudo a mesma coisa em um nível e, de qualquer maneira, legível por humanos não significa que todos os usuários em potencial tenham as habilidades necessárias para ler ou escrever, ou é esperado que eles os desenvolvam.

Existem boas razões pelas quais você normalmente não expõe um tempo de execução do idioma diretamente aos usuários finais. O principal é que a remoção da flexibilidade aumenta a conveniência.

Se eu quiser digitar uma postagem SO, eu apenas quero digitá-la. Sou perfeitamente capaz de escrever um programa C ++ para produzi-lo, mas não usaria um navegador da Web que expusesse um editor de programa C ++ em vez de uma caixa de texto comum. Pessoas que não conhecem C ++ não apenas não usariam o navegador, como também não.

Se eu quiser configurar certos parâmetros de negócios, não necessariamente o desejo usando uma linguagem de especificação completa de Turing, e mesmo que eu tenha feito isso provavelmente não é distinguível de "codificar" esses mesmos parâmetros de negócios em qualquer outra programação língua. Você ainda precisa considerar se o que está escrevendo significa o que deseja que ele signifique. Você ainda precisa testar se as alterações estão corretas. Ou seja, você ainda precisa de habilidades de programação para todas as tarefas que são não-trivial e não antecipado por alguém que não tem habilidades de programação que prepararam um sub-sistema especializado ( "aplicação") para que você configure ( "utilização").

Portanto, se você está prestes a embarcar em um sistema 100% orientado a dados, que pode fazer qualquer coisa com os dados corretos, faça duas perguntas:

1. Estamos no negócio de inventar linguagens de programação ou deveríamos estar?
2. Nossa nova linguagem de programação será melhor (para nossos propósitos) do que as que já temos e iremos apoiá-la e desenvolvê-la conforme necessário?

Às vezes, as respostas são afirmativas e você escreve algum tipo de idioma específico do domínio. Ou até mesmo uma linguagem de programação de uso geral, se você é Sun / Microsoft / Stroustrup / van Rossum / muitas outras. Às vezes, as respostas são não e você tem o efeito "plataforma interna" - depois de muito esforço, tentativa e erro, você acaba com alguma coisa. Se você tiver sorte, é apenas ligeiramente inferior à linguagem de programação em que você a escreveu e não é mais fácil de usar.

Alguns idiomas são mais difíceis ou fáceis de usar do que outros, especialmente se forem especializados para um propósito como o R, alguns usuários os acharão muito mais fáceis. O que você provavelmente não fará é tornar a programação geral de aplicativos fundamentalmente mais fácil. A qualquer momento, provavelmente existem várias pessoas / organizações no mundo com potencial para fazer isso, mas seu chefe / empresa deve considerar honestamente se isso inclui ele ou você.

Existe um truque frequentemente usado para jogos, que é expor as ligações Lua ao mecanismo do jogo. Isso permite que os designers programem em uma linguagem relativamente fácil, mas ainda envolvam um programador "real" quando necessário para obter desempenho ou acessar funcionalidades específicas do mecanismo ou da plataforma. Os scripts Lua resultantes são "dados" no que diz respeito ao mecanismo. Nem todos eles precisam incluir muito do que você chamaria de "lógica" em oposição aos dados de configuração, e geralmente definem praticamente todo o enredo e ambiente, mas não toda a jogabilidade. Isso não é 100% orientado a dados e certamente não é 100% livre de erros, mas é um compromisso prático interessante.

Eu trabalhei em uma empresa onde esse era o objetivo. Fragmentos de SQL foram armazenados em tabelas de banco de dados, lidos em tempo de execução e executados. O desempenho foi terrível, como você pode imaginar, e os bugs eram frequentes. Também era impossível depurar, sem rastreamentos de pilha ou qualquer outra coisa que facilite a vida.

"Programação orientada a dados" resulta de uma falta fundamental de compreensão do que estamos fazendo, como programadores; quaisquer dados capazes de fazer um algoritmo acontecer são na verdade "programação", mesmo que você tenha conseguido misturar (mangle?) as duas idéias na interface do usuário. Agora, isso não significa que você não pode combinar as duas idéias de outra direção, para que todo o código seja dados; essa é a premissa por trás do lisp, que é habilitado por sua homoiconicidade e explorado por seu macro sistema. Sim, esses conceitos parecem semelhantes, mas suas implicações e aplicações são muito diferentes na prática.

Além disso, isso pode ser editorial, mas os lugares que encontrei que desejam uma programação "completamente orientada a dados" realmente não valorizam seus programadores. Eles pensam no código como um centro de custo, algo a ser terceirizado ou ignorado.

Você quer dizer que seu chefe quer que você escreva isso:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Para gerar isso:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

O primeiro é JSON e o segundo é JavaScript .

Clarificação

Eu acho que teoricamente não é porque a coisa que interpreta os dados acaba precisando se tornar completa para descrever o aplicativo, para que você tenha mudado o problema um nível mais alto para nenhum benefício líquido.

É possível um aplicativo orientado a dados 100%?

Foi aqui que eu comecei. Com a minha resposta, estou tentando concordar com o post original de que: É possível, mas você está correto, isso apenas mudará o problema um nível acima, sem nenhum benefício [óbvio] .

Acho que você poderia argumentar de forma convincente que qualquer aplicativo de navegador da web pode ser considerado 100% orientado a dados ¹ .

Obviamente, isso não torna mais simples ou fácil a criação de aplicativos na Web, na verdade, os torna muito mais difíceis.

Diga ao seu chefe que ele está reinventando o navegador da Web e ele precisará reinventar o JavaScript para criar algo razoavelmente complexo.

¹ Bem, se você ignorar plugins, JavaScript e HTML5 .

Sim. Até onde eu sei, um sistema como o Mathematica , que é a chamada poderosa linguagem de programação, mas essencialmente é um shell, baseia-se na idéia semelhante que o seu chefe esperava. O Wolfram Mathematica agora está se tornando suficientemente complexo, de modo que muitas tarefas computacionais podem ser facilmente executadas por ele.

Dados orientados são um conceito. Se nós, programadores, vamos manipular dados de uma maneira simples, precisamos de um shell que seja fácil para brincarmos com dados. Tente entender que, quando começamos a falar sobre o aprendizado de uma linguagem de programação baseada em sintaxe, estamos realmente aprendendo a interface do aplicativo ou simplesmente seu shell. Se entendermos o shell, podemos dirigir os programas.

Quanto a 100% orientado a dados, se o compilador ou o intérprete puder entender o shell, a computação será direcionada. Se os dados tiverem a mesma estrutura subjacente que o shell ou a interface que possui, os dados também poderão ser conduzidos pelo compilador ou intérprete. Eu acho que o Mathematica é uma boa explicação para por que eu respondo com um sim.