Perché Objective-C non è ampiamente utilizzato oltre gli ambienti Cocoa?

Objective-C offre un buon orientamento agli oggetti, semplicità, eleganza e (come un superset di C), abilità di basso livello. Potrebbe sembrare l'alternativa semplice e moderna al C ++ che molte persone cercano e cercano in Go. Ma è solo usato negli ambienti Cocoa e Post-NextSTEP, e anche in questo caso è visto più come un peso per ragioni storiche che come una scelta ottimale.

Perché non è più ampiamente utilizzato allora? Quali sono i suoi problemi?

IMO, il problema con Objective-C non è tanto un'enorme carenza, quanto una carenza minore (soprattutto all'inizio) e mancanza di vantaggi percepiti.

Objective-C era un puro superset di C, quindi il codice C poteva passare facilmente a Objective-C. La mentalità di utilizzare Objective-C, tuttavia, differiva dalla C mentalità un sacco . Il passaggio da C a Objective-C è facile per il codice ma non è affatto facile per molti programmatori. Il programmatore AC non può semplicemente scegliere alcune nuove funzionalità di convenienza in Objective-C e ottenere una migliore produttività quasi immediatamente - deve imparare molte nuove "cose" prima di poter arrivare ovunque.

Il C ++ ha reso la transizione per alcuni codici un po 'più difficile, ma la transizione per la maggior parte dei programmatori è molto più semplice. I programmatori C che sono abituati a gestire ogni dettaglio del loro codice potrebbero ancora farlo in C ++ esattamente nella misura in cui volevano. Il C ++ ha anche reso facile l'uso di alcune nuove funzionalità (ad esempio l'aggiunta di un ctor per inizializzare automaticamente i membri della tua struttura) senza cambiare davvero il tuo modo di pensare. Molti puristi di OO hanno spinto cambiamenti radicali nel pensiero, ma molti programmatori C sono passati al C ++ senza fare nulla del genere (almeno subito - e spesso mai, dall'aspetto delle cose).

Il C ++ sembrava anche molto più familiare alla maggior parte dei programmatori C. Ha aggiunto alcune nuove parole chiave, ma (soprattutto all'inizio) il codice sembrava ancora abbastanza familiare. Nonostante il suo stato di "superset puro", la maggior parte del codice Objective-C sembra abbastanza estraneo alla maggior parte dei programmatori C. Un sacco di C ++ è anche abbastanza facile da spiegare e capire in termini di come funzionano le cose in C. Passare a Objective-C ha molti più posti che tutto ciò che puoi dire è "fidati di me e dimentica tutto ciò che pensi di sapere. "

Molte delle decisioni di progettazione in Objective-C lo hanno anche reso (un po ') più lento del C ++, specialmente su macchine relativamente vecchie con processori lenti, memoria limitata, ecc. Giustamente o erroneamente, è stato visto in gran parte come un prodotto per singola azienda, dove Il C ++ era liberamente disponibile per chiunque e tutti da implementare.

Tutto ciò ha portato all'adozione del C ++ abbastanza rapidamente in anticipo che ha raggiunto la "massa critica" abbastanza rapidamente, quindi (tra le altre cose) è diventata la scelta ovvia per molti progetti solo perché era già ampiamente usato, noto quantità.

Objective-C non ha mai raggiunto quel punto. In effetti, era sulla buona strada per svanire nell'oscurità quando Apple lo ha rianimato costringendolo quasi a chiunque volesse sviluppare per i loro sistemi. Tuttavia, la quota di mercato di Apple non è abbastanza grande da consentirle di ottenere davvero una massa critica - solo una nicchia più ampia. È una scelta "predefinita" solo dove / perché Apple lo rende tale.

Aggiungo anche che, almeno secondo me, il modello a oggetti come Smalltalk di Objective-C significa che in effetti è molto più un diretto concorrente di Java che C ++. Sì, ha ancora le basi C, e sì puoi ancora scrivere codice di basso livello senza usare un linguaggio separato - ma il C puro e il vero Objective-C sono abbastanza diversi che è meno simile a una singola lingua rispetto a due lingue completamente diverse che capita che entrambi siano gestiti da un singolo compilatore (anche se è utile che i due possano parlare tra loro senza che JNI si unisca a loro).

Bene, fondamentalmente, Apple è la forza trainante di Objective-C da qualche tempo:

• Mentre l'ultima versione è praticamente abbandonata, Objective-C 2.0 sta effettivamente iniziando a diventare sempre più legato ad alcune delle classi / protocolli di base, il che significa che esiste un legame intrinseco tra le funzionalità del linguaggio e il framework, NSFastEnumeration mi viene in mente , necessario affinché gli oggetti rispondano correttamente ai cicli in. Ciò significa che esiste un legame crescente tra la lingua e la piattaforma.
• Non c'è praticamente alcuna vera alternativa al cacao. E Cocoa a sua volta sta iniziando a dipendere da sempre più funzionalità OSX. Sebbene tecnicamente, puoi avere un'implementazione di Objective-C in esecuzione su qualsiasi sistema operativo con qualsiasi framework di base, non ci sono cose molto recenti là fuori per qualsiasi altra piattaforma.

Come è ora, Apple ha il pieno controllo su Objective-C e guida il linguaggio in base alle sue esigenze, mentre non esiste un'organizzazione su questo pianeta interessata a far funzionare Objective-C su un dispositivo non Apple, che sarebbe sufficientemente grande da fornire un libreria e toolkit standard per cominciare, che potrebbero persino competere a distanza con gli ecosistemi presentati da .NET / Mono, C ++ o Java.