Anche se posso vedere i benefici, non sono un grande fan di questi linguaggi astratti. Tendono a fornire in genere una buona soluzione generica a un problema molto specifico, affittano quelli che ho visto. Credo che non possano diventare una realtà tanto quanto io credo che gli Architetti possano creare architetture complesse e complesse usando nient'altro che un word processor.
Detto questo, credo che sarà possibile comporre sistemi complessi da blocchi già realizzati. In un certo senso questo giorno è già qui, alcuni hanno inventato il loro linguaggio specifico e funziona ... in qualche modo, purché l'applicazione di destinazione rimanga nel dominio della prima applicazione da cui il framework è stato derivato.
I problemi che possono essere risolti con la programmazione sono vasti e, in quanto tali, per creare un singolo linguaggio che invariabilmente diventerà invariabilmente tutto. L'idea di avere un linguaggio di integrazione per aiutare i diversi sistemi a comunicare tra loro è piacevole e le definizioni dei protocolli come SOAP, Rest, * RPC cercano di ottenere proprio questo. Alcuni sono forti per le interazioni dinamiche ma forniscono poco per gestire la modellazione dei dati, altri gestiscono i dati molto bene, ma sono deboli per gestire le interconnessioni degli altri, tuttavia descriveranno in modo molto preciso il comportamento previsto di un sistema dando poco o nessun intuito su come dovrebbe essere fatto. Immagino che il mio punto qui sia che c'è sempre un compromesso da fare da qualche parte che sposterà il framework un po 'più in là lungo la strada della specializzazione. Accoppiandolo con la vasta diversità di domini e applicazioni diventa impossibile anticiparli tutti per creare una visione unificata di come un'architettura dovrebbe essere espressa. Un'architettura software è molto più di una definizione statica di componenti interagenti e questo è il punto in cui la maggior parte degli ACL fino ad oggi fallisce miseramente.
Un approccio migliore IMHO sarebbe quello di creare un modello liberamente definito e aperto per esprimere la capacità di un componente in modo programmabile. Un buon esempio di questo sarebbe un moderno editor GUI. La maggior parte consentirà la creazione di nuovi componenti che includono una sorta di funzionalità dichiarativa che l'editor può utilizzare per esporre automaticamente il nuovo componente per le composizioni future. La maggior parte degli editor di GUI attuali eccellono nel comporre widget, ma offrono pochissimo per esprimere le interazioni dinamiche di questi componenti.
L'architettura basata su agenti ha tentato di affrontare questo problema ma con scarso successo. Penso che fossero in anticipo sui tempi in quanto la comunicazione era un componente centrale delle community di agenti, ma i protocolli e gli strumenti per supportare tale ricchezza di comunicazione non erano ancora stati progettati.
Per quanto ne so, il miglior tentativo attuale di questo sarebbe Spring Roo . Sebbene sia specifico per la lingua (Java), tenta di riunire componenti di alto livello separati in un singolo modello di architettura.
L'espressione dell'architettura di un sistema software è relativa al tuo punto di vista; esprimere questo punto di vista porterà inevitabilmente a una riduzione delle informazioni. L'espressione di tutte le dimensioni di un'architettura software si trova in definitiva nel codice sorgente ma per "vederle" è necessario un grande sforzo.
Come argomento conclusivo, suppongo che la creazione di tale linguaggio sia soggetta al principio di incertezza di Heisenberg applicato al software, più precisamente rappresenti un aspetto del sistema più ti perdi di vista gli altri aspetti.
il mio 2 centesimo ... per quello che vale con i tassi di cambio in questi giorni ...