^{Ho trovato alcune informazioni parziali, quindi inizierò a compilare le mie conclusioni nella mia risposta. Per favore, non lasciare che questo ti impedisca di contribuire con le tue risposte (o modificando questa).}

Letteratura esistente:

• Un confronto empirico di 7 lingue di programmazione - Prechelt (2000) [ PDF ]

  Un po 'datato, ma copre parte del materiale a cui sono interessato e fornisce una visione sull'uso e l'espressività della memoria di runtime. I risultati possono essere molto diversi ora, ma è un inizio interessante.

• Velocità, dimensioni e affidabilità dei linguaggi di programmazione - Marceau (2009) [ blog ]

• Codice usato, forme utilizzate nel tempo dal gioco Benchmarks [ u32 , u32q , u64 , u64q ]

  Anche se non copre il consumo di memoria in fase di esecuzione, il lavoro di Marceau è più o meno il tipo di riferimento o di studio empirico che sarei disposto a trovare per quella critica, in termini di contenuto e qualità. Un buon esempio di ciò che cerco, solo per metriche diverse. Il secondo articolo è un seguito trovato sul sito Benchmarks Game e che è stato pubblicato poco dopo (e quali riferimenti) lavoro di Marceau, con schermate più recenti e più lingue, anche se ancora senza dettagli di memoria di runtime. Ogni grafico su queste pagine porta quindi a un confronto linguistico che fa fornisce comunque informazioni di memoria di alto livello.

Questo non risponde alla domanda per dire, ma forse cambia un po 'la prospettiva. Sto tenendo presente la trascrizione della chat, per impostare il tono di questa risposta, un commento che sarà sicuramente soggetto a molti voti negativi.

Ci sono persone, fornitori di hardware, fornitori di strumenti e programmatori preoccupati per l'efficienza. Per il momento, sarà una preoccupazione crescente per loro e per tutti noi. Queste preoccupazioni sono radicate nei dispositivi mobili, in particolare nei mostri divoratori di batterie ad alta potenza con gli schermi più grandi e le radio più potenti.

Per fare un altro passo indietro, parte della ragione per cui ci troviamo nella situazione in cui ci troviamo oggi, con quadri comparativamente massicci e qualche lieve disprezzo per l'efficienza generale, oltre ai miglioramenti dell'hardware è legacy. La compatibilità con i sistemi legacy ci rende compatibili con la compatibilità. Non è tanto la colpa di un run-time di alto livello, in quanto essenzialmente lo stesso runtime si comporta in modo abbastanza efficiente e performante quando viene utilizzato in un ambiente operativo diverso (es. Xbox, windows mobile pre 7/8 / surface, java micro framework , ecc.)

Confronta l'estensione della compatibilità che un desktop possiede con il suo software legacy per quanto riguarda la compatibilità con un dispositivo mobile.

Con i dispositivi mobili, i produttori di dispositivi compiono alcuni sforzi per garantire una certa compatibilità, ma non hanno reso la compatibilità un nucleo fondamentale. Quando la scelta è tra continuare a fornire compatibilità e spostare il design del sistema mobile in avanti, il sistema mobile avanza.

Per i desktop, il contrario sembra vero. Se un significativo cambiamento improvviso colpisce erroneamente i marketers o gli early adopters, spinge le funzionalità necessarie e la necessità di ridisegnare di nuovo la stanza sul retro. Ad un certo punto ricordo voci secondo le quali noi come utenti Windows troveremmo un file system completamente nuovo e con Windows XP, poi in Vista, poi lo stesso per Seven, e infine ancora in Eight, ma no, solo migliorato in modo incrementale dal l'abbiamo visto per la prima volta su Windows2000? Il nuovo sistema di file è rimasto in circolazione per molto tempo, è stato demolito, e comunque le voci decidono la storia dopo di ciò, non posso dire. Questo è probabilmente il caso più noto, ma io sono sicuro che non è l'unico grande caso.

Anche con i tablet e i sistemi operativi mobili più recenti, Microsoft, che un tempo ha plasmato il mercato, è ora intrecciata in un match mortale non solo con i consumatori, ma con l'ombra di se stesso dal reparto desktop. Il tablet doveva avere un'interoperabilità significativa con la controparte desktop. No, non poteva giocare perfettamente con esso, a causa delle differenze di architettura, ma anche a causa della natura arcaica delle puntellature del desktop ha fatto sacrifici significativi.

Ora, certamente, Windows è l'obiettivo facile per qualsiasi tipo di critica per questa situazione, ma altre piattaforme sono lontane dal "peccato libero". Ci sono molte reliquie in agguato nell'ecosistema Linux che sono sicuramente causa di grande costernazione per un miglioramento sistematico.

L'economia gioca un ruolo importante in questa equazione; il modo in cui finanziamo il nostro calcolo e le nostre applicazioni da un lato, e il modo in cui sono finanziati dall'altro seguono modelli sorprendentemente differenti. Laddove Wintel ha strongmente influenzato l'obsolescenza, Apple e Google lo hanno trasformato in un programma quasi rigoroso. Questo è più fuori rotta di quanto intendessi, quindi me ne andrò così com'è e lascerò che i lettori lo prendano da lì.

Se e quando i grandi fornitori cambiano i loro modelli di obsolescenza e di prezzo, allora possono iniziare ad andare avanti con cambiamenti su scala più ampia a un tasso più uniforme. Quelle strutture di alto livello che sono guidate dai linguaggi di ordine più alto si ridurranno in un modo, in quanto saranno in grado di raggiungere il loro compito di alto livello con un livello più basso come l'efficienza perché l'inefficiente compatibilità intermedia e i livelli di basso livello essere drasticamente ridotto, se non eliminato.