Perché molti linguaggi di programmazione dinamica tipizzati da anatra utilizzano un approccio basato su classi invece di OOP basati su prototipi?

Question 1) What’s the need for a Class in a dynamic language? Why the language is designed that way to use a class as some kind of “template” instead of do it the prototype-way and just use a object?

Il primo linguaggio OO (anche se non era chiamato "OO"), Simula, non aveva ereditarietà. L'ereditarietà è stata aggiunta in Simula-67 ed era basata sulle classi.

Nello stesso periodo, Alan Kay ha iniziato a lavorare sulla sua idea di un nuovo paradigma di programmazione, che in seguito ha chiamato "Object-Orientation". Gli piaceva davvero l'ereditarietà e voleva averlo nella sua lingua, ma a lui non piacevano molto le lezioni. Tuttavia, non riusciva a trovare un modo per ereditare senza classi, e così decise che non gli piacevano le classi più di quanto gli piacesse l'ereditarietà e progettò la prima versione di Smalltalk, Smalltalk-72 senza classi e quindi senza ereditarietà.

Un paio di mesi dopo, Dan Ingalls ha proposto un design di classi, in cui le classi stesse erano oggetti, vale a dire istanze di metaclassi. Alan Kay ha trovato questo design leggermente meno appagante di quelli più vecchi, quindi Smalltalk-74 è stato progettato con classi e con ereditarietà in base alle classi.

Dopo Smalltalk-74, Alan Kay sentiva che Smalltalk si stava muovendo nella direzione sbagliata e non rappresentava effettivamente ciò che OO era tutto, e propose che la squadra abbandonasse Smalltalk e si fosse messa in moto, ma fu messo in minoranza. Seguirono Smalltalk-76, Smalltalk-80 (la prima versione di Smalltalk da rilasciare ai ricercatori), e infine Smalltalk-80 V2.0 (la prima versione ad essere commercializzata, e la versione che divenne la base per ANSI Smalltalk) .

Poiché Simula-67 e Smalltalk-80 sono considerati i nonni di tutte le lingue OO, quasi tutte le lingue che seguirono, copiarono ciecamente il design delle classi e dell'ereditarietà in base alle classi. Un paio di anni più tardi, quando altre idee come l'ereditarietà basata su mixin anziché classi e la delega basata su oggetti invece dell'ereditarietà basata su classi emerse, l'ereditarietà basata su classi era già diventata troppo radicata.

È interessante notare che l'attuale linguaggio di Alan Kay è basato sulla delega del prototipo.

Molti programmatori preferiscono lavorare con le classi. È un concetto molto facile da comprendere che è un buon modello di processi di pensiero umano sul mondo (cioè, colleghiamo istintivamente oggetti reali al gruppo astratto di elementi a cui pensiamo appartengano, che è ciò che è una classe) . Inoltre, le classi rendono più facile ragionare sui tipi di oggetto: in un linguaggio basato sulla classe, l'applicazione di principi come sostituzione di Liskov è più semplice di è in una lingua in cui abbiamo solo oggetti che possono avere metodi diversi, o il cui tipo può anche cambiare in fase di esecuzione, come nel caso di JavaScript.

Si noti che anche in JavaScript, un sacco di codice utilizza semplicemente la funzione di prototipo per emulare le classi. Ciò è dovuto principalmente al fatto che molti programmatori preferiscono pensare in questo modo.

C'è anche un'altra ragione per cui sono preferiti i linguaggi basati sulle classi: è più facile compilarli in un codice efficiente. Le VM JavaScript più efficienti creano dinamicamente le classi in modo efficace per rappresentare i tipi di oggetti JavaScript man mano che cambiano i loro metodi e prototipi. Vedi questa descrizione dell'implementazione del V8 per una spiegazione del perché questo è stato fatto.

Ho sentito dire che su grandi progetti, in cui team di persone lavorano insieme sullo stesso codice, che i linguaggi flessibili (in cui è possibile modificare le proprietà e i metodi di un oggetto durante l'esecuzione) sono le libertà che gli altri membri del team donano " Voglio che tu abbia.

Vogliono sapere, quando hanno a che fare con un oggetto, che l'oggetto agirà proprio come dice il modello, e non un modo morphed in cui qualche altro ambizioso sviluppatore ha deciso di cambiarlo per completare il suo compito.

Quindi, l'unica ragione per cui posso concepire, che qualcuno non vorrebbe la flessibilità offerta da questi fantastici linguaggi dinamici, è che vogliono semplificare lo sviluppo del team, il debug e la documentazione automatica.

Personalmente, ho sviluppato applicazioni in entrambe le metodologie e ho fatto le cose molto più velocemente con i linguaggi dinamici. Non uso nessuno di questi framework progettati per riportare di nuovo il mio linguaggio dinamico in un linguaggio di classe. Queste cose sono una regressione ai miei gusti.

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things -- Alan Kay

Quindi quello che sta dicendo qui è che OO sta facendo scatole nere che rispondono ai messaggi. In un certo senso REST è l'ultimo sistema OO in quanto utilizza verbi (cioè un messaggio) e risorse (cioè una scatola opaca che contiene alcuni dati).

Quindi la domanda sul perché alcuni sono basati su classi e altri basati su prototipi non si rendono conto che non importa, sono entrambe semplici implementazioni. Un sistema che utilizza esclusivamente la messaggistica al posto delle chiamate ai metodi è identico a OO delle due istanze menzionate.