Um sistema pode ser 100% baseado em dados?

Seu chefe deve ler este artigo: Bad Carma: O projeto "Vision", um aviso história sobre efeito de plataforma interna ou segundo efeito de sistema.

Resumo

Those of us who work in Information Technology (IT) have all been on a project where something important is just not right. We know it, most everyone knows it, but nobody is quite able to put his or her finger on the problem in a convincing way.

This story is about such an IT project, the most spectacular failure I have ever experienced. It resulted in the complete dismissal of a medium-sized IT department, and eventually led to the destruction of a growing company in a growing industry. The company, which we'll call "Upstart," was a successful and profitable subscription television business.

The project occurred in the early 1990s, and it was a custom-built order-entry and customer-service application, closely resembling what is now referred to as Customer-Relationship Management or CRM. The core functionality of the system included:

• Order entry and inventory
• Customer service, help desk
• General ledger, accounts receivable, billing, and accounts payable

The application was called "Vision" and the name was both its officially stated promise for Upstart as well as a self-aggrandizing nod to its architect. The application was innovative, in that it was built to be flexible enough to accommodate any future changes to the business. Not just any foreseeable future changes to the business, but absolutely any changes to the business, in any form. It was quite a remarkable claim, but Vision was intended to be the last application ever built. It achieved this utter flexibility by being completely data-driven, providing limitless abstraction, and using object-oriented programming techniques that were cutting-edge at the time.

Like many such projects that set out to create a mission-critical application, the development effort spanned two years, about a year longer than originally projected. But that was acceptable, because this was the application that would last forever, adapting to any future requirements, providing unlimited Return On Investment (ROI). When the application finally went "live," almost everybody in the company had invested so much in it that literally the fate of the company hinged on its success.

However, in the event of total project malfunction, mission-critical applications running the core business of multinational corporations are not permitted the luxury of the type of fast flameout demonstrated by thousands of "dot-com" companies in the era of the Internet bubble. Within a month of Vision going "live," it was apparent to all but those most heavily vested in its construction that it was a failure.

Veja também

link

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 a lógica e configuração é manipulada por valores armazenados de tal maneira que em outro contexto eles seriam considerados como dados. Havia muitos produtos 4GL produzidos nos anos 80 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 por meio de relatórios. Eu costumava me referir a sistemas como "pintar por números", mas vejo que agora passou a ser conhecido como o efeito "sistema interno". Bom nome.

As pessoas que criam esses sistemas estão tentando (sabendo ou não) criar uma nova linguagem de programação. Como eles não têm as habilidades, eles fazem mal. Do ponto de vista da JVM / CLR, um programa Java / C # compilado é simplesmente dados. Neste caso, foi bem feito. Em ambos os casos, os programadores são necessários para usar 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 de recursos escolhido, você toma as decisões e as congela no sistema e, especificamente, nega a capacidade de configurar esses recursos.

Você também implementa um idioma que tem a capacidade de codificar operações lógicas. Minha recomendação é usar uma linguagem existente como lua ou talvez Python. Você incorpora partes deste código onde quer que sejam 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, por favor me avise. A maioria das pessoas falha miseravelmente. Eu serei o primeiro a parabenizá-lo pela sua conquista.

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

Uma "linguagem de script", grosso modo, é um tempo de execução de linguagem 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 "Joke" 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 forma, legível por humanos não significa que todos os usuários em potencial tenham as habilidades para ler ou escrever, ou que possam desenvolvê-los.

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

Se eu quiser digitar uma postagem do SO, quero apenas digitá-la. Eu sou perfeitamente capaz de escrever um programa em C ++ para produzi-lo, mas eu não usaria um navegador da Web que expusesse um editor de programa C ++ em vez de uma caixa de texto normal. As pessoas que não conhecem o C ++ não apenas não usariam o navegador, elas não poderiam.

Se eu quiser configurar certos parâmetros de negócio, então eu não necessariamente quero fazer isso usando uma linguagem de especificação Turing-completa, e mesmo se eu fiz isso provavelmente não é distinguível de "hard- codificação "os mesmos parâmetros de negócios em qualquer outra linguagem de programação. Você ainda precisa considerar se o que você está escrevendo significa o que você quer dizer. Você ainda precisa testar se as alterações estão corretas. Ou seja, você ainda precisa de habilidades de programação para quaisquer tarefas não triviais e não previstas por alguém que tenha habilidades de programação que preparou um subsistema especializado ("aplicativo") para você configurar ( "use").

Então, se você está prestes a embarcar em um sistema 100% baseado em dados, que pode fazer qualquer coisa com os dados certos, você tem duas perguntas a fazer:

1. Estamos no negócio de inventar linguagens de programação ou deveríamos estar?
2. A nossa nova linguagem de programação será melhor (para os 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 sim e você escreve uma linguagem específica de domínio de algum tipo. Ou até mesmo uma verdadeira linguagem de programação de propósito geral se você for Sun / Microsoft / Stroustrup / van Rossum / muitos outros. Às vezes as respostas são não e você tem o efeito de "plataforma interna" - depois de muito esforço e tentativa e erro você acaba com algo. Se tiver sorte, é apenas um pouco inferior à linguagem de programação na qual você a escreveu e não é mais fácil de usar.

Alguns idiomas são mais difíceis ou mais fáceis de usar do que outros, especialmente se forem especializados para um propósito como o R, então 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 há provavelmente várias pessoas / organizações no mundo com potencial para fazer isso, mas seu chefe / empresa tem que considerar honestamente se isso inclui ou não você.

Há um truque frequentemente usado para jogos, que é expor as ligações de Lua ao mecanismo do jogo. Isso permite que os projetistas programem em uma linguagem relativamente fácil, mas ainda envolvam um programador "real" quando necessário para o desempenho ou para acessar uma funcionalidade específica do mecanismo ou da plataforma. Os scripts Lua resultantes são "dados" no que diz respeito ao mecanismo. Eles nem todos precisam incluir muito do que você chamaria de "lógica", ao contrário de dados de configuração, e muitas vezes eles praticamente definem todo o enredo e ambiente, mas não o jogo todo. 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. Snippets de SQL foram armazenados em tabelas de banco de dados, lidos em tempo de execução e executados. O desempenho era 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 facilitasse a vida.

"Programação orientada por dados" resulta de uma falta fundamental de compreensão do que estamos fazendo, como programadores; qualquer dado que é capaz de fazer um algoritmo acontecer 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 possa combinar as duas ideias da outra direção, de modo que todo código seja dado; essa é a premissa por trás do lisp, que é possibilitada pela sua homoiconicidade e explorada pelo seu sistema macro. 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 editorialização, mas os lugares que eu encontrei que querem 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 .

Eliminação

I think theoretically it isn't because the thing that interprets the data ends up needing to become turing complete to describe the application so you've just shifted the problem one level higher to no net benefit.

Is such a 100% Data Driven Application possible?

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

Você poderia argumentar de forma convincente, acredito, que qualquer aplicativo de navegador da Web poderia ser considerado 100% orientado por dados ¹ .

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

Diga ao seu chefe que ele está reinventando o navegador da Web, e ele eventualmente terá que reinventar o JavaScript para construir algo razoavelmente complexo.

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

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

Data driven é um conceito. Se nós, programadores, manipularmos os dados de uma maneira simples, precisamos de um shell que seja fácil para nós brincarmos com os dados. Tente entender que, uma vez que começamos a falar sobre o aprendizado de uma linguagem de programação baseada na sintaxe, estamos realmente aprendendo a interface do aplicativo ou simplesmente seu shell. Se entendermos o shell, podemos conduzir os programas.

Quanto aos dados 100% gerados, se o compilador ou o interpretador puderem entender o shell, o cálculo será conduzido. Se os dados tiverem a mesma estrutura subjacente do shell ou da interface, os dados também poderão ser controlados pelo compilador ou pelo interpretador. Eu acho que Mathematica é uma boa explicação para por que eu respondo com um sim.