Planilha "programação" é um tipo de programação de fluxo de dados.
Temos um problema linguístico, não devemos chamá-lo de "programação", porque é muito menos do que chamamos de programação, mas é definitivamente mais do que inserir dados em um programa.
A programação de fluxo de dados é uma arquitetura e disciplina, onde o aplicativo é uma rede de módulos independentes, eles enviam mensagens (dados) um ao outro. Esse modelo não é aplicável a todos os problemas, apenas aos que têm dados ou fluxo de origem (ou mais), que passam pela rede de processamento e produzem dados / fluxos de saída. Veja a lista abaixo.
A programação de fluxo de dados tem vários tipos, vamos ver alguns:
- Planilha: os números de entrada são processados por fórmulas e, em seguida, resultam em números e gráficos. Características especiais: o tempo de execução é "one-shot", quando o valor de entrada (componente) é alterado, a parte apropriada do gráfico de processamento é reexecutada e produz saída.
- Pipe Unix: o shell lança vários programas e vincula stdout-> stdin. Características especiais: somente a vinculação no estilo de tubo é permitida, o gráfico é uma única fila.
- Execução sincronizada: existe um relógio que aciona o processamento de um quadro ou amostra em uma frequência especificada. Cada componente é executado uma vez por ciclo do relógio. Sistemas de processamento de vídeo e áudio os exemplos, eles trabalham em uma taxa de quadros / amostra especificada.
- Execução assíncrona: o gráfico está ocioso, até que um evento externo ocorra. Em seguida, processa o evento, gera alguma saída (ou não) e entra no estado ocioso.
Voltando à sua pergunta: acho que sim, é uma boa ideia publicar um aplicativo de fluxo de dados como um aplicativo independente. Eu já fiz isso. Duas vezes .
Eu e um amigo meu criamos um protótipo de sistema DF para automação residencial. Não temos editor de gráfico; portanto, o aplicativo não é editável pelo usuário, alguns parâmetros são armazenados em um arquivo de configuração, mas nada mais. Temos uma linguagem de script DF, "compilada" no código C ++ (uma lista de criação de componentes e definições de mensagens), que é compilada em um executável nativo. Os módulos são classes C ++ (outras classes, apenas para obter algumas informações sobre nosso sistema: Mensagem, Dispathcer, Componente (resumo), Porta (resumo), ConsumerPort, ProducerPort).
Além disso, ficamos impressionados com as vantagens de um sistema DF: criamos um aplicativo sniffer serial em 2 minutos ou criamos um programa de teste no local , que pisca as lâmpadas um por um (não havia documentação em IDs de hardware). Criamos componentes MIDI e joypad apenas por diversão, também criei um órgão leve (consulte http://homeaut.com/under_construction/ ).
Só vejo uma dificuldade no caso de planilhas: como todo número e fórmula (potencialmente: toda célula) é um componente, seu gráfico não é final. Quando você adiciona uma linha ao seu aplicativo sum () simples, isso significa que o gráfico do fluxo de dados é alterado. Portanto, você deve "reprogramar" o gráfico em tempo de execução, ou devemos chamá-lo de "metaprogramação". No Excel, uma macro faria o trabalho, mas perdemos a pureza do fluxo de dados.
Eu tenho uma solução não muito ruim, mas não perfeita. Eu fiz uma planilha, um aplicativo AJAX com backend PHP. O eixo vertical é o tempo (dias), as linhas são componentes. Existem componentes, como entrada (a linha pode ser editada pelo usuário), média vertical, média / soma horizontal e alguns cálculos estatísticos específicos do domínio. Há apenas um problema: é "unidimensional". Desde que eu queira apenas somar, avg e tudo o mais, posso adicionar novas linhas e criar o componente, que calcula o material. Mas há uma forte restrição: as colunas são sempre dias (criei "visualizações" semana e mês, que exibem dados diários como soma / média, mas ainda são unidimensionais. Não posso mostrar, é colaborativo e requer que a tarefa de back-end do PHP seja executada em 24/7, não é suportada pelo meu provedor de hospedagem.
Portanto, meu modelo (que pode ser melhor descrito como: "dias na horizontal") não é capaz de lidar com outros tipos de problemas.
Eu tenho uma idéia, como resolver este problema: abas .
Quando você fica preso no Excel e precisa criar outra tabela, pode usar uma área distinta na mesma guia ou abrir outra guia. Além disso, a referência entre guias é desconfortável, eu prefiro o primeiro método. Eu acho que as guias devem ser exibidas na mesma tela, como janelas sem sobreposição.
Toda tabela deve ter seu eixo crescente: vertical, horizontal ou fixo. As tabelas verticais crescentes têm componentes de linha (como minha planilha diária), onde todas as colunas têm a mesma fórmula, os componentes horizontais têm componentes de colunas, as tabelas de tamanho fixo são como qualquer planilha.
Portanto, quando o usuário adiciona uma nova linha / coluna, a nova linha / coluna terá a mesma fórmula.
Além disso, nas planilhas, eu odeio o fato de precisar copiar as mesmas fórmulas 1000 vezes, se tiver 1000 linhas. É uma fonte de bugs (mantendo a versão antiga da fórmula em algumas linhas), desperdício de memória (armazenando a mesma fórmula 1000x).
Talvez eu esteja errado, e há erros de conceito nesse modelo, mas espero que tenha sido uma boa idéia.