Un sistema può essere guidato al 100% da dati?

Il mio nuovo capo ha lavorato a questo progetto per molti anni. Sono qui da poche settimane, ma non sono sicuro che sia possibile. Vorrebbe progettare un sistema "guidato al 100% dai dati".

Quindi, se inseriamo dati sufficienti, possiamo definire e generare qualsiasi applicazione. Sono riuscito almeno a fargli concedere alcune cose come gli utenti, o le app dovrebbero avere valori predefiniti, ma gli piace il concetto di struttura del sistema, l'interfaccia utente e la logica che sono tutti archiviati come dati.

Ci sono alcune dimostrazioni di cose semplici e ha sostanzialmente riscoperto alcune semplici idee di programmazione orientata agli oggetti e i tuoi sistemi di template di base, ma penso che nel complesso questo obiettivo potrebbe essere effettivamente impossibile.

Non so come si possa definire la logica usando i dati senza che il sistema diventi così complesso da eseguire comunque la vera programmazione.

Penso che teoricamente non sia perché la cosa che interpreta i dati finisce per diventare turing completa per descrivere l'applicazione, quindi hai appena spostato il problema di un livello superiore a nessun vantaggio netto.

È possibile tale applicazione basata sui dati al 100%?

Il tuo capo dovrebbe leggere questo pezzo: Bad Carma: il progetto "Vision", un ammonimento sull'effetto piattaforma interna o sul secondo effetto di sistema.

Astratto

Quelli di noi che lavorano nell'Information Technology (IT) hanno tutti partecipato a un progetto in cui qualcosa di importante non è giusto. Lo sappiamo, quasi tutti lo sanno, ma nessuno è abbastanza in grado di mettere il dito sul problema in modo convincente.

Questa storia parla di un tale progetto IT, il fallimento più spettacolare che abbia mai visto. Ha portato al licenziamento completo di un dipartimento IT di medie dimensioni e alla fine ha portato alla distruzione di un'azienda in crescita in un settore in crescita. La società, che chiameremo "Upstart", è stata un'attività di televisione in abbonamento di successo e redditizia.

Il progetto si è svolto nei primi anni '90 ed era un'applicazione di inserimento ordini e assistenza clienti su misura, simile a quella che ora viene definita Customer-Relationship Management o CRM. Le funzionalità principali del sistema includevano:

• Inserimento dell'ordine e inventario
• Servizio clienti, help desk
• Contabilità generale, crediti, fatturazione e contabilità fornitori

L'applicazione si chiamava "Vision" e il nome era sia la promessa dichiarata ufficialmente per Upstart che un cenno auto-esaltante al suo architetto. L'applicazione era innovativa, in quanto è stata costruita per essere abbastanza flessibile da accogliere eventuali cambiamenti futuri per l'azienda. Non solo eventuali cambiamenti futuri prevedibili al business, ma assolutamente qualsiasi cambiamento al business, in qualsiasi forma. Era un'affermazione davvero notevole, ma Vision doveva essere l'ultima applicazione mai costruita. Ha raggiunto questa totale flessibilità essendo completamente guidato dai dati, fornendo un'astrazione senza limiti e utilizzando tecniche di programmazione orientate agli oggetti che erano all'avanguardia all'epoca.

Come molti di questi progetti che si prefiggevano di creare un'applicazione mission-critical, lo sforzo di sviluppo è durato due anni, circa un anno in più rispetto a quanto inizialmente previsto. Ma era accettabile, perché questa era l'applicazione che sarebbe durata per sempre, adattandosi a qualsiasi requisito futuro, fornendo un ROI (Return On Investment) illimitato. Quando l'applicazione alla fine è diventata "attiva", quasi tutti gli utenti dell'azienda avevano investito così tanto in essa che il destino dell'azienda è dipeso dal suo successo.

Tuttavia, in caso di malfunzionamento totale del progetto, alle applicazioni mission-critical che gestiscono il core business delle multinazionali non è consentito il lusso del tipo di spegnimento rapido dimostrato da migliaia di società "dot-com" nell'era della bolla di Internet. Nel giro di un mese dalla visione di "vivere", era evidente a tutti, tranne quelli più fortemente investiti nella sua costruzione, che si trattava di un fallimento.

Guarda anche

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

La risposta è sì, è possibile creare un sistema completamente guidato dai dati e sì, di solito è una pessima idea.

Un programma completamente guidato dai dati è uno in cui tutta la logica e la configurazione sono gestite da valori memorizzati in modo tale che in un altro contesto sarebbero considerati dati. Negli anni '80 c'erano molti prodotti 4GL che offrivano la possibilità di generare report, moduli, tabelle e logica usando elementi di dati inseriti in una molteplicità di moduli, archiviati in tabelle e accessibili tramite report. Mi riferivo a sistemi come "dipingi con i numeri", ma vedo che ora è diventato noto come effetto "sistema interno". Bel nome.

Le persone che creano questi sistemi stanno provando (che lo sappiano o meno) a creare un nuovo linguaggio di programmazione. Dal momento che non hanno le competenze, lo fanno male. Dal punto di vista di JVM / CLR, un programma Java / C # compilato è semplicemente un dato. In questo caso è stato fatto bene. In entrambi i casi, i programmatori sono tenuti ad usare la lingua, qualunque essa sia.

C'è un modo specifico per far funzionare questo, che conosco. Costruisci lo scheletro di ciascuno dei componenti di cui hai bisogno: modulo, report, tabella, ecc. Fornisci un meccanismo per configurare varie parti di questi componenti impostando gli elementi di dati. Per un set scelto di funzionalità, prendi le decisioni e le congeli nel sistema e neghi specificamente la possibilità di configurarle.

È inoltre possibile implementare un linguaggio che ha la capacità di codificare le operazioni logiche. La mia raccomandazione è di usare un linguaggio esistente come lua o forse Python. Incorporate parti di questo codice ovunque siano necessarie operazioni logiche.

In questo modo riduci sostanzialmente la quantità di scrittura richiesta per implementare ogni modulo, report, tabella e così via. Il sistema sembra essere basato sui dati, ma solo fino a un certo punto.

A questo punto hai appena implementato un nuovo 4GL. Se succede, fallo con successo, per favore fatemelo sapere. La maggior parte delle persone fallisce in modo disastroso. Sarò il primo a congratularmi con te per il tuo successo.

Penso che tu sia sostanzialmente corretto. Un runtime linguistico è già un sistema basato su dati completamente flessibile. Prende un pezzo di dati (il programma) e lo usa per determinare come dovrebbe agire su altri dati. Potrebbe anche avere uno schema multiutente per archiviare il codice per il riutilizzo da altri programmi (che vanno da un percorso di inclusione alla corretta gestione dell'installazione).

Un "linguaggio di scripting", approssimativamente parlando, è un runtime linguistico in cui questo input di codice è leggibile dall'uomo. Un compilatore posiziona un ulteriore passaggio tra l'utente e il runtime. Le lingue "scherzose" come Malbolge e APL non devono essere leggibili dall'uomo in nessuna forma. Ma è la stessa cosa a un livello, e comunque leggibile dall'uomo non significa che tutti i potenziali utenti abbiano le competenze per leggerlo o scriverlo, o ci si può aspettare che li sviluppino.

Vi sono buoni motivi per cui normalmente non si espone un runtime linguistico direttamente agli utenti finali. Il principale è che rimuovere la flessibilità aumenta la praticità.

Se voglio digitare un post SO, voglio solo digitarlo. Sono perfettamente in grado di scrivere invece un programma C ++ per produrlo, ma non userei un browser web che esponesse un editor di programmi C ++ invece di una normale casella di testo. Le persone che non conoscono il C ++ non solo non usano il browser, ma non potrebbero.

Se voglio configurare determinati parametri di business, non voglio necessariamente farlo usando un linguaggio di specifica completo di Turing, e anche se lo facessi probabilmente non è distinguibile dal "hard-coding" di quegli stessi parametri di business in qualsiasi altra programmazione linguaggio. Devi ancora considerare se ciò che stai scrivendo significa ciò che vuoi che significhi. Devi ancora verificare che le modifiche siano corrette. Che è, è ancora necessario competenze di programmazione per qualsiasi attività che non sono banali e non previsto da qualcuno che non ha competenze di programmazione che hanno preparato una speciale sotto-sistema ( "applicazione") per la configurazione ( "uso").

Quindi, se stai per intraprendere un sistema basato sui dati al 100%, che può fare qualsiasi cosa, dati i dati giusti, hai due domande da porsi:

1. Siamo nel business di inventare linguaggi di programmazione o dovremmo esserlo?
2. Il nostro nuovo linguaggio di programmazione sarà migliore (per i nostri scopi) di quelli che già abbiamo e lo sosterremo e lo svilupperemo di cui ha bisogno?

A volte le risposte sono sì e scrivi una lingua specifica del dominio di qualche tipo. O anche un vero linguaggio di programmazione generico se sei Sun / Microsoft / Stroustrup / van Rossum / molti altri. A volte le risposte sono no e si ottiene l'effetto "piattaforma interna" - dopo molti sforzi, prove ed errori si finisce con qualcosa. Se sei fortunato è solo leggermente inferiore al linguaggio di programmazione in cui lo hai scritto e non è più facile da usare.

Alcune lingue sono più difficili o più facili da usare rispetto ad altre, in particolare se sono specializzate in uno scopo come R, alcuni utenti le troveranno molto più facili. Quello che probabilmente non farai è rendere la programmazione di applicazioni generali sostanzialmente più semplice. In qualsiasi momento ci sono probabilmente diverse persone / organizzazioni al mondo con il potenziale per farlo, ma il tuo capo / azienda deve considerare onestamente se ciò include o meno.

C'è un trucco spesso usato per i giochi, che è quello di esporre i binding di Lua al motore di gioco. Ciò consente ai progettisti di programmare in un linguaggio relativamente semplice, ma di coinvolgere comunque un programmatore "reale" ove necessario per le prestazioni o per accedere a particolari funzionalità del motore o della piattaforma. Gli script Lua risultanti sono "dati" per quanto riguarda il motore. Non tutti devono includere gran parte di ciò che chiamereste "logica" invece di configurare i dati, e spesso definiscono praticamente tutta la trama e l'ambiente, ma non l'intero gameplay. Questo non è basato sui dati al 100% e certamente non è privo di errori al 100%, ma è un compromesso pratico interessante.

Ho lavorato in un'azienda in cui questo era l'obiettivo. I frammenti di SQL sono stati archiviati nelle tabelle del database, letti in fase di esecuzione ed eseguiti. Le prestazioni sono state terribili, come puoi immaginare, e gli errori erano frequenti. Era anche impossibile eseguire il debug, senza tracce dello stack o qualsiasi altra cosa che semplifichi la vita.

La "programmazione basata sui dati" deriva da una fondamentale mancanza di comprensione di ciò che stiamo facendo, come programmatori; qualsiasi dato che sia in grado di far accadere un algoritmo è in realtà "programmazione", anche se in qualche modo sei riuscito a mescolare (manipolare?) le due idee nell'interfaccia utente. Ora, questo non significa che non puoi combinare le due idee dall'altra direzione, in modo che tutto il codice sia dato; questa è la premessa dietro a lisp, che è abilitato dalla sua omoiconicità e sfruttato dal suo sistema macro. Sì, questi concetti sembrano simili, ma le loro implicazioni e applicazioni sono molto diverse nella pratica.

Inoltre, questo può essere editoriale, ma i luoghi che ho incontrato che desiderano una programmazione "completamente basata sui dati" non danno valore ai loro programmatori. Pensano al codice come a un centro di costo, qualcosa da esternalizzare o ignorare.

Vuoi dire che il tuo capo vuole che tu scriva questo:

[
  {
    "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"
          ]
        }
      ]
    }
  }
]

Per generare questo:

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

Il primo è JSON e il secondo è JavaScript .

Clearification

Penso che teoricamente non sia perché la cosa che interpreta i dati finisce per diventare turing completa per descrivere l'applicazione, quindi hai appena spostato il problema di un livello superiore a nessun vantaggio netto.

È possibile tale applicazione basata sui dati al 100%?

Questo è dove ho appena iniziato. Con la mia risposta sto cercando di concordare con il post originale che: è possibile, ma hai ragione, sposterà il problema di un livello superiore senza alcun [ovvio] beneficio .

Potrei sostenere in modo convincente, penso, che qualsiasi applicazione per browser web potrebbe essere considerata al 100% basata sui dati ¹ .

Ovviamente, ciò non semplifica o semplifica la creazione di applicazioni sul Web, anzi le rende molto più difficili.

Di 'al tuo capo che sta reinventando il browser web e alla fine dovrà reinventare JavaScript per costruire qualcosa di ragionevolmente complesso.

¹ Bene, se ignori plugin, JavaScript e HTML5 .

Sì. Per quanto ne so, un sistema come Mathematica , che è un cosiddetto potente linguaggio di programmazione ma essenzialmente è una shell, si basa sull'idea simile che il tuo capo si aspettava. Wolfram Mathematica ora sta diventando abbastanza complesso da consentire di svolgere facilmente molti compiti di calcolo.

Il data driven è un concetto. Se noi programmatori manipoleremo i dati in modo semplice, avremo bisogno di una shell per giocare con i dati. Cerca di capire che una volta che iniziamo a parlare dell'apprendimento di un linguaggio di programmazione basato sulla sintassi, stiamo effettivamente imparando l'interfaccia dell'applicazione o semplicemente la sua shell. Se comprendiamo la shell, possiamo guidare i programmi.

Per quanto riguarda i dati guidati al 100%, se il compilatore o l'interprete sono in grado di comprendere la shell, il calcolo è guidato. Se i dati hanno la stessa struttura sottostante della shell o dell'interfaccia che ha, i dati possono essere guidati anche dal compilatore o dall'interprete. Penso che Mathematica sia una buona spiegazione del perché ti rispondo con un sì.