Progettazione di sistemi estensibili e interattivi

Un linguaggio specifico del dominio è solitamente la migliore risposta a questo tipo di problema.

Alcune lingue, come Ruby o Boo , sono ben progettati per consentirti di creare DSL. Ma questo è un argomento vasto, molto più di quanto possa essere trattato in una sola risposta qui, ma ci sono un paio di buoni libri sull'argomento:

• Lingue specifiche del dominio di Martin Fowler
• I DSL in Boo di Ayende Rahien

La maggior parte delle persone non sa quello che vuole, e quelli che sanno quello che vogliono non sanno come descriverlo in un modo che

• un computer può capire,
• è abbastanza user-friendly per un semplice mortale,
• è abbastanza robusto da non bloccarsi ogni 5 minuti e
• è abbastanza flessibile da resistere a futuri cambiamenti aziendali.

Ecco perché esistono i programmatori.

Poiché gli utenti non sono veramente interessati a scrivere i propri programmi, ciò che si finisce è scrivere un sistema che è configurabile , cioè, ha impostazioni che sono già comprese dal sistema che possono essere manipolato da un utente. Se sei fortunato, il numero di tali impostazioni è abbastanza piccolo che la flessibilità che forniscono è sufficiente per il dominio del problema senza aggiungere troppa complessità.

Come sottolinea pdr nella sua risposta , le lingue specifiche del dominio sono un buon ponte per quelle persone che hanno bisogno più potenza e flessibilità di quanto la configurazione possa fornire.

È un argomento studiato, anche se sfortunatamente non è un ben studiato. Tali sistemi sono solitamente chiamati Sistemi di auto-mantenimento , Sistemi auto-supportanti o (specialmente nella comunità Smalltalk) Sistemi vivaci .

Non sorprendentemente, Smalltalk stesso è un tale sistema, e la comunità di Smalltalk (in particolare lo stesso Dr. Alan Kay) è costantemente impegnata a costruire sistemi sempre più potenti e allo stesso tempo sempre più semplici. Il gruppo di ricerca del Dr. Alan Kay sta attualmente lavorando alla progettazione di un nuovo linguaggio e di un nuovo sistema che fornirà un completo Personal Computing System (es. Sistema operativo, Linguaggio di programmazione, Compiler, VM, IDE, Editor, Office Suite, Browser Web, Realtime Collaboration ecc. .) in meno di 20000 SLOC totali.

Questo suona sospettosamente come il "modello interno" (anti).

L'idea di base è scrivere un software che incorpori in sé un mezzo a forma libera di configurazione e / o specifiche di comando. Questo metodo è solitamente, come altri hanno correttamente sottolineato, un "linguaggio specifico per il dominio" o DSL, interpretato dal tuo software in parti di codice più statiche che hai scritto. Ci sono molte di queste lingue già là fuori; VBA, SQL, lo scripting dietro i motori Quake e Source, ecc.

Tuttavia, il difetto in tale modello diventa evidente quando si guardano i DSL di esempio. Dubito che sul pianeta ci sia un DBA che si fiderebbe con chiunque in Contabilità abbastanza da dare loro una copia di SQL Management Studio e lasciare che eseguano le proprie query di segnalazione. D'altro canto, dubito che ci sia un ragioniere sul pianeta che pensa che sia una soluzione valida per il loro bisogno di rapporti personalizzati. Il 99% degli utenti non sa come scrivere uno script per automatizzare qualcosa in un gioco di Quake o Source-engine; quelli che continuano a trovare buchi in ciò che quei motori non ti permettono di fare, di fare qualcosa che dia un vantaggio ingiusto.

Mentre potremmo implementare la nostra DSL (grafica o basata su testo) che semplifica la creazione di query personalizzate e che non consente all'utente di rovinare nulla oltre la propria query, c'è una linea molto sottile da seguire durante la progettazione un DSL che consente all'utente di fare ciò di cui ha bisogno, in un modo che capiscono, senza impedire quindi di fare qualcosa di cui hanno legittimamente bisogno o di permettere loro di fare qualcosa di dannoso. Spesso, non esiste una tale soluzione, e anche se esiste, fornire una DSL che permetta loro di fare qualsiasi cosa che dovrebbe essere in grado di non proteggerti dal dover cambiare la DSL per permettere qualcosa di nuovo a cui nessuno ha mai pensato prima, questo è perfettamente accettabile e non dannoso. In quanto tale, la piattaforma interna non risolve realmente il problema a cui era destinata; permettendo agli utenti di fare la propria "programmazione", così i veri sviluppatori possono fare cose più interessanti della personalizzazione dell'interfaccia utente o del layout di report / contenuti. Gli sviluppatori saranno sempre chiamati a "spiegare" (cioè a tenere la mano dell'utente) il DSL che hanno dato all'utente ea rispondere al "bene perché non posso farlo solo in questo modo" domande che sono inevitabili.

Anche i programmatori si occupano di tutto questo tempo, nel trattare con le DSL progettate per l'interazione con software di terze parti. "Ehi, perché non posso fare X, sembra abbastanza semplice e ho davvero bisogno di fare questa cosa che il mio utente vuole" ... "Beh, se ti lasciamo fare questo allora un utente malintenzionato potrebbe fare qualcosa di simile e ti farà davvero impazzire su, e anche noi ". Come programmatori ci aspettiamo una certa quantità di ciò; gli utenti finali si aspettano un po 'più di facilità d'uso. Ecco perché siamo qui.

Uno dei miei concetti preferiti nell'ingegneria del software è convenzione sulla configurazione e mi è venuta in mente di leggere la tua domanda. Quello che mi piace fare è estrarre la maggior parte della definizione della logica app in una qualche forma di rappresentazione dei dati, sia che si tratti di file di configurazione XML / json o tabelle di database. Cerco di evitare la logica hard-coding nel livello dell'app e solo di interpretare le istruzioni che sono definite (inizialmente dallo sviluppatore, modificabile in seguito dall'utente) nel livello dati. È quasi come un 4GL che il controller dell'app capisce. L'utente non tecnico ha quindi un'interfaccia amichevole per manipolare quella logica. Questo approccio viene fornito con un elevato livello di responsabilità, dato che si fornisce all'utente un socket per modificare il funzionamento dell'applicazione al suo interno. Quindi cose come autorizzare le esecuzioni di test prima che le modifiche siano confermate, ACL, autorizzazioni ecc. Sono tutte critiche in questo approccio.

In futuro vedremo sempre più separazioni tra la definizione logica e il codice compilabile.

".... la pienezza del tempo, credo che la fluidità nella programmazione diventerà onnipresente come l'alfabetizzazione, quindi non avrà importanza ....."

Crede che tutti siano destinati a diventare programmatori, non sono d'accordo. Nel mondo reale, le persone sono diventate meno consapevoli delle cose che fanno ogni giorno con il passare del tempo. Hai usato per ruotare un dial per sintonizzare un canale TV e capito "Frequency", e sapevo dove si trovava ogni canale, ora premi il pulsante "Auto Program". Hai usato per cambiare il tuo petrolio e aggiustarti la tua foratura quando possedevi un'auto, dovevi sapere come risolvere un guasto, ora raramente devi fare nulla di tutto ciò, e portarlo al garage o chiamare AAA. Sei solito coltivare le tue stesse verdure e cucinare il tuo cibo, ora sono le cene di McD e TV .....

Personalmente penso che alla fine i programmatori programmeranno e useranno gli utenti. Lo strano entusiasta diventerà un programmatore dilettante, ma proprio come nel mondo reale, gli strumenti che usano saranno sostanzialmente simili a quello che usano i professionisti. Immagina di provare a costruire la tua auto con "Strumenti specifici del dominio" che potrebbero fare solo alcuni dei dadi e bulloni, o cucinare la cena con una cucina "sicura e facile da usare" che non ha coltelli o superfici calde, come possono fare un sacco di danni se usato in modo errato.

La risposta alla tua domanda è bootstrap. Per prima cosa progettate un linguaggio molto semplice, flessibile ed estensibile. (I linguaggi dinamici funzionano bene). Lo implementa. Quindi in quella lingua scrivi estensioni della lingua finché non hai la lingua che desideri. Quindi scrivi l'applicazione stessa in quella lingua. Quando hai finito, esponi la lingua con cui hai iniziato.

Poiché tutto è scritto in quella lingua e le estensioni sono disponibili in fase di runtime, puoi fare tutto ciò che vuoi sull'applicazione (comprese le cose poco sagge).

Per esempio vedi come emacs è scritto in eLisp. Oppure guarda Smalltalk. O Schema.

Questo è il principio. I dettagli tendono ad essere molto, molto complicati. Pertanto raccomando vivamente di studiare codice che sembra farlo bene. E leggi libri come On Lisp che dimostrano come un linguaggio può essere esteso da se stesso. Se hai il giusto tipo di mente ricorsivamente contorta, alla fine sarai in grado di costruire il tuo sistema su questo principio. (Ma buona fortuna a spiegare a qualcun altro cosa lo rende figo ...)