linguaggi di programmazione dinamica moderni come Python, Ruby e Javascript prendono tutti l'approccio di trattare tutto come un oggetto, qual è il vantaggio di questo approccio e qual è la maledizione di esso?
Beneficio a cui posso pensare: funzioni di prima classe, digitazione anatra.
Svantaggi: problema di prestazioni, in particolare prestazioni di tipi primitivi come interi ecc.
Non è del tutto chiaro se stai parlando della semantica o della pragmatica qui. La tua domanda legge di più sulla semantica, ma nei commenti dici che stai chiedendo della pragmatica. Ho intenzione di rispondere su entrambi.
Il modo in cui questo viene usato nel mondo reale è che si hanno linguaggi puramente orientati agli oggetti le cui implementazioni usano le primitive senza mai esporle al programmatore. Quindi, le uniche persone che hanno bisogno di affrontare le complessità di avere due "cose" differenti (oggetti e primitive non-object) sono gli implementatori di compilatori / interpreti. Gli utenti di lingue usano semplicemente gli oggetti.
Quindi, in altre parole, usa la semantica senza primitive, ma implementale con i primitivi. YARV, Rubinius, MRuby, MacRuby, praticamente tutte le implementazioni Lisp e Smalltalk (e derivate come Self e Newspeak), alcune implementazioni ECMAScript e probabilmente molte altre lo fanno.
Le tecniche per fare questo sono state conosciute dal (almeno) anni '80. Come molte altre cose utili, i progettisti della piattaforma Java sembrano averli dimenticati quando hanno progettato la piattaforma Java, e ora stanno combattendo una dura battaglia decennale contro i vincoli di compatibilità all'indietro per rimuovere nuovamente le primitive. (Si dice che siano passati da Java 10, ma poi di nuovo, questa voce è in circolazione da 15 anni.)
Le prestazioni non contano. O meglio: rispetto a fornire agli sviluppatori lo strumento migliore con cui possono esprimere e modellare ciò che vogliono il computer, le prestazioni sono il problema più facile da risolvere.
Tipi, classi, oggetti, funzioni, lambda - tutti questi concetti aiutano ad organizzare i tuoi pensieri e il tuo codice. A questo punto, non sono affatto collegati al modo in cui il processore eseguirà il codice. La "maledizione", se ce n'è una, è quando il tuo linguaggio di scelta ti costringe a un particolare modello (classi contro oggetto, di oggetto vs funzionale) quando ti piacerebbe usarne un altro per un particolare problema.
Riguardo all'attuazione effettiva, non ne so abbastanza per commentare al riguardo. Tuttavia la coerenza è preziosa: avere tutto come un oggetto per lo sviluppatore potrebbe rendere l'implementazione della lingua leggermente più difficile, ma rende molto più facile l'utilizzo. Non importa (nella maggior parte dei casi) se internamente ha un trattamento speciale perché è int o non.
Leggi altre domande sui tag object-oriented programming-languages dynamic-typing dynamic-languages