Vedete un uso per "Programmazione di fogli di calcolo"? [chiuso]

Qualche tempo fa mi sono imbattuto nel concetto di usare fogli di calcolo (intendo celle e formule non codice Macro) come un modo per specificare la logica di programmazione. L'idea è:

• creare un foglio di calcolo con un flusso di calcoli chiaramente definito (che a volte sono più adatti al paradigma del "flusso di dati" di fogli di calcolo invece che a stili di programmazione procedurali o orientati agli oggetti)

• definire le celle di input

• definire le celle di output

• compilare il tutto in una classe eseguibile autonoma (o funzione, procedura, ...)

• usalo nel normale codice all'interno di un progetto software più ampio

• usa il foglio di calcolo come codice sorgente da mantenere nel tempo

L'idea è di usare questa tecnica per problemi che si adattano davvero al modello e che ciò porterebbe a un codice naturalmente ben documentato e facilmente gestibile. Sono interessato a sapere se hai sperimentato l'uso della tecnica e per cosa. Un'applicazione di esempio che mi è venuta in mente sono i calcolatori delle tariffe assicurative, che sono in genere elaborati, creati e convalidati da attuari su fogli Excel e solo successivamente codificati (è un processo doloroso) in una logica di programmazione difficile da mantenere.

Sebbene non sia esattamente lo stile di "costruire un foglio di calcolo, compilarlo in codice" di cui ti stavi chiedendo, l' estensione del flusso di dati di Cells a CLOS utilizza un modello simile: che le formule che esprimono flussi di dati e trasformazioni siano la rappresentazione del "materiale di origine" / " del record "per la progettazione di oggetti / classi. Consideralo un modo alternativo per costruire ciò di cui stavi chiedendo.

E solo per divertimento: macro foglio di calcolo

che a volte si adattano meglio al paradigma del "flusso di dati" dei fogli di calcolo anziché agli stili di programmazione orientati agli oggetti o procedurali

Onestamente, riesco a malapena a pensare a calcoli del mondo reale in cui questo si applica. La programmazione "Dataflow" può essere facilmente eseguita con molti linguaggi di programmazione moderni (si veda LINQ nel mondo .NET, o gli operatori di elaborazione di elenchi di Perl e Python) e, per la mia esperienza, risulta un codice molto più gestibile di un gruppo di "formule di fogli di calcolo" con riferimenti di cella difficili da mantenere.

D'altra parte, io e i miei colleghi abbiamo creato molte applicazioni basate su fogli di calcolo (MS-Excel, per essere precisi), in cui Excel è stato utilizzato come strumento intuitivo per l'immissione di dati di input / la creazione di maschere di input molto rapidamente, oppure per la creazione di output formattato o entrambi. In tutti questi casi, il calcolo o l'elaborazione di tali dati non è stato eseguito (o solo parzialmente) dalle formule di Excel, ma dal codice del programma, poiché le formule di Excel non erano abbastanza potenti o lo strumento completamente sbagliato (e credetemi, abbiamo un molta conoscenza di ciò che è possibile con le formule di Excel e di cosa non lo è).

Da quando ho letto questo articolo, ho pensato e ripensato al concetto. Penso che ci sia sicuramente un uso.

Una cosa sull'ottimizzazione di una cosa del genere, un foglio elettronico è molto simile allo spazio di memoria. È anche molto simile allo spazio di visualizzazione e stampa (come in x, y). Molti vantaggi anche lì.

Quando hai notato la manutenibilità, ciò mi ha aperto molte idee. Non so che cosa c'è là fuori da compilare con funzionalità davvero e linguistiche, librerie, ecc. Potrebbe essere abbastanza doloroso. Tuttavia, potrebbe esserci un futuro da qualche parte.

Ho davvero scritto solo script VB per fogli di calcolo, libri di testo e "software" di contabilità. Non ho mai creato app eseguibili da qualsiasi foglio di calcolo basato su Excel, eccetto l'interfaccia di file da un'app C ++.

Sì, tuttavia lo considero più come un "test di foglio di calcolo" piuttosto che come "programmazione di un foglio di calcolo". Ad esempio, recentemente ho lavorato su una funzione per il nostro progetto che prevede l'esecuzione di un calcolo su un gran numero di record di database. Il calcolo era relativamente semplice ma importante e quindi necessitava di un'attenzione particolare ai test. Inoltre, la formula che stavamo usando richiedeva una piccola quantità di adattamento per essere applicabile alla nostra situazione.

Ho eseguito manualmente alcuni calcoli per scrivere i miei test unitari, mentre il tester con cui stavo lavorando ha creato un foglio di calcolo come hai descritto per l'uso nei suoi test end-to-end. A causa dell'adattamento della formula di origine non avevamo dati di test indipendenti con cui confrontare, quindi il foglio di calcolo ha fornito una sorta di controllo di stile "contabilità a doppia entrata" che ci ha dato la certezza che il codice era corretto.

Quindi sì, vedo questa tecnica come molto utile come fonte di dati di test per i casi in cui i calcoli coinvolti sono facili da implementare in un foglio di calcolo, ma per il resto devono essere implementati nel codice. Tuttavia, tale foglio di calcolo non dovrebbe essere utilizzato per "specificare la logica di programmazione" di per sé, ma semplicemente i risultati finali richiesti.

Il foglio di calcolo "programmazione" è un tipo di programmazione del flusso di dati.

Abbiamo un problema linguistico con esso, non dovremmo chiamarlo "programmazione", perché è molto meno di quanto chiamiamo programmazione, ma è decisamente più che inserire dati in un programma.

La programmazione del flusso di dati è un'architettura e una disciplina, in cui l'applicazione è una rete di moduli indipendenti, che si scambiano messaggi (dati). Questo modello non è applicabile a tutti i problemi, solo per quelli in cui vi sono dati o flussi di origine (o ce ne sono altri), che attraversano la rete di elaborazione e producono flussi / dati di output. Vedi la lista qui sotto.

La programmazione del flusso di dati ha diversi tipi, vediamo alcuni:

• Foglio di calcolo: i numeri di input vengono elaborati da formule, quindi numeri di risultati e grafici. Caratteristiche speciali: il tempo di visualizzazione è "one-shot", quando il valore di input (componente) cambia, la parte appropriata del grafico di elaborazione viene eseguita nuovamente e produce output.
• Unix pipe: la shell avvia diversi programmi e collega stdout-> stdin. Caratteristiche speciali: è consentito solo il collegamento in stile pipe, il grafico è una singola coda.
• Esecuzione sincronizzata: esiste un orologio che attiva l'elaborazione di un frame o di un campione in una frequenza specificata. Ogni componente viene eseguito una volta al ciclo di clock. I sistemi di elaborazione audio e video, ad esempio, funzionano a un frame / frequenza di campionamento specificati.
• Esecuzione asincrona: il grafico è inattivo, fino a quando si verifica un evento esterno. Quindi elabora l'evento, genera un output (o no) e passa allo stato inattivo.

Torna alla tua domanda: penso di si, è una buona idea pubblicare un'applicazione di flusso di dati come app autonoma. L'ho già fatto. Due volte .

Io e un mio amico abbiamo creato un prototipo di sistema DF per l'automazione domestica. Non abbiamo un editor grafico, quindi l'app non è modificabile dall'utente, alcuni parametri sono memorizzati in un file di configurazione, ma nient'altro. Abbiamo un linguaggio di script DF, che viene "compilato" in codice C ++ (un elenco di definizioni di componenti e creazione di componenti), che viene compilato in un eseguibile nativo. I moduli sono classi C ++ (altre classi, solo per ottenere alcune informazioni sul nostro sistema: Message, Dispathcer, Component (abstract), Port (abstract), ConsumerPort, ProducerPort).

Inoltre, siamo rimasti sorpresi dei vantaggi di un sistema DF: abbiamo realizzato un'app sniffer seriale in 2 minuti o abbiamo creato un programma di test in loco , che fa lampeggiare le lampade una a una (non c'era documentazione su ID hardware). Abbiamo creato componenti MIDI e joypad solo per divertimento, ho anche creato un organo leggero con esso (vedi http://homeaut.com/under_construction/ ).

Riesco a vedere solo una difficoltà in caso di fogli di calcolo: poiché ogni numero e formula (potenzialmente: ogni cella) è un componente, il tuo grafico non è definitivo. Quando aggiungi una linea alla tua semplice app sum (), significa che il grafico del flusso di dati viene modificato. Quindi, devi "riprogrammare" il grafico in fase di esecuzione, o dovremmo chiamarlo "metaprogrammazione". In Excel, una macro farebbe il lavoro, ma perderemo la purezza del flusso di dati.

Ho una soluzione non troppo male, ma non perfetta. Ho realizzato un foglio di calcolo, un'app AJAX con back-end PHP. L'asse verticale è il tempo (giorni), le linee sono componenti. Ci sono componenti, come input (la linea può essere modificata dall'utente), media verticale, media / somma orizzontale e alcuni calcoli statistici specifici del dominio. C'è solo un problema: questo è "monodimensionale". Finché voglio solo somma, avg e qualsiasi altra cosa, posso aggiungere nuove righe e creare il componente, che calcola il materiale. Ma c'è un forte vincolo: le colonne sono sempre giorni (ho creato "viste" settimanali e mensili, che mostrano i dati giornalieri come somma / media, ma è ancora unidimensionale). Non riesco a mostrarlo, è collaborativo e richiede l'esecuzione del back-end PHP per essere eseguito 7/24, non è supportato dal mio provider host.

Quindi, il mio modello (che può essere meglio descritto come: "giorni in orizzontale") non è in grado di gestire altri tipi di problemi.

Ho un'idea, come risolvere questo problema: le schede .

Quando rimani bloccato in Excel e devi creare un'altra tabella, puoi utilizzare un'area distinta nella stessa scheda o aprire un'altra scheda. Inoltre, fare riferimento tra le schede è scomodo, preferisco il primo metodo. Penso che le schede dovrebbero essere visualizzate sullo stesso schermo, come le finestre non sovrapposte.

Ogni tavolo dovrebbe avere il suo asse crescente: verticale, orizzontale o fisso. Le tabelle in crescita verticale hanno componenti di linea (come il mio foglio di calcolo basato sul giorno), in cui tutte le colonne hanno la "stessa" formula, i componenti orizzontali hanno componenti di colonna, le tabelle di dimensioni fisse sono proprio come qualsiasi foglio di calcolo.

Pertanto, quando l'utente aggiunge una nuova riga / colonna, la nuova riga / colonna avrà la stessa formula.

Inoltre, nei fogli di calcolo, odio la cosa, che devo copiare le stesse formule 1000 volte, se ho 1000 righe. È una fonte di bug (mantenendo la vecchia versione della formula in alcune righe), spreco di memoria (memorizzazione della stessa formula 1000x).

Forse mi sbaglio, e ci sono bug concettuali in questo modello, ma spero sia stato un buon stimolo.

Il mio pensiero sarebbe quello di utilizzare il foglio di calcolo per definire la logica per i calcoli e, nel frattempo, provare a impostare il foglio di calcolo in modo tale da renderlo compatibile con il linguaggio di programmazione. Con amichevole intendo -> usare intervalli di nomi / riferimenti invece di coordinate cellXY e scomporre le formule in pezzi più piccoli.