Pourquoi Objective-C n'est-il pas largement utilisé au-delà des environnements Cocoa?

Objective-C présente une orientation, une simplicité, une élégance et (en tant que surensemble de C) une capacité de bas niveau. Cela pourrait ressembler à l'alternative simple et moderne au C ++ que beaucoup de gens recherchent et essaient de trouver dans Go. Mais il n'est utilisé que dans les environnements Cocoa et post-NextSTEP, et même dans ce cas, il est davantage considéré comme un fardeau pour des raisons historiques que comme un choix optimal.

Pourquoi n'est-il pas alors plus largement utilisé? Quels sont ses problèmes?

OMI, le problème avec Objective-C n'est pas tant des lacunes massives, que des lacunes mineures (surtout au début) et le manque d'avantages perçus.

Objective-C était un pur surensemble de C, donc le code C pouvait facilement passer à Objective-C. L'état d' esprit d' utiliser Objective-C, cependant, diffère de la C état d' esprit d' un grand nombre . La transition de C à Objective-C est facile pour le code mais pas facile du tout pour de nombreux programmeurs. Le programmeur AC ne peut pas simplement choisir quelques nouvelles fonctionnalités pratiques dans Objective-C et obtenir une meilleure productivité presque immédiatement - il doit apprendre beaucoup de nouveaux "trucs" avant de pouvoir aller n'importe où.

C ++ a rendu la transition pour certains codes un peu plus difficile, mais la transition pour la plupart des programmeurs beaucoup plus facile. Les programmeurs C qui sont habitués à traiter tous les détails de leur code pourraient toujours le faire en C ++ exactement comme ils le voulaient. C ++ a également facilité l'utilisation de nouvelles fonctionnalités (par exemple, l'ajout d'un ctor pour initialiser automatiquement les membres de votre structure) sans vraiment changer votre façon de penser. Beaucoup de puristes OO ont poussé des changements radicaux dans la pensée, mais beaucoup de programmeurs C sont passés au C ++ sans rien faire de ce genre (au moins tout de suite - et souvent toujours, à en juger par les choses).

C ++ semblait également beaucoup plus familier à la plupart des programmeurs C. Il a ajouté quelques nouveaux mots clés, mais (surtout au début), le code semblait toujours assez familier. Malgré son statut de "surensemble complet", la plupart du code Objective-C semble assez étranger à la plupart des programmeurs C. Beaucoup de C ++ est également assez facile à expliquer et à comprendre en termes de fonctionnement des choses en C. Passer à Objective-C a beaucoup plus d'endroits que tout ce que vous pouvez dire est "faites-moi confiance et oubliez tout ce que vous pensez savoir." "

De nombreuses décisions de conception dans Objective-C l'ont également rendu (un peu) plus lent que C ++, en particulier sur les machines relativement anciennes avec des processeurs lents, une mémoire limitée, etc. À tort ou à raison, il était également considéré en grande partie comme un produit à entreprise unique, où C ++ était disponible gratuitement pour tout le monde et tout le monde à mettre en œuvre.

Tout cela a conduit à l'adoption du C ++ assez rapidement pour qu'il atteigne assez rapidement la «masse critique», donc (entre autres choses), il est devenu le choix évident pour de nombreux projets simplement parce qu'il était déjà largement utilisé et bien connu. quantité.

Objective-C n'a jamais atteint ce point. En fait, il était sur le point de sombrer dans l'obscurité quand Apple l'a relancé en le forçant presque à quiconque souhaitait développer pour ses systèmes. La part de marché d'Apple n'est pas assez importante pour que cela lui donne vraiment une masse critique - juste une niche plus grande. C'est un choix "par défaut" seulement où / parce qu'Apple le fait.

J'ajouterais également qu'au moins à mon avis, le modèle d'objet de type Smalltalk d'Objective-C signifie qu'en fait, il est beaucoup plus un concurrent direct de Java que C ++. Oui, il a toujours les fondements C, et oui, vous pouvez toujours écrire du code de bas niveau sans utiliser un langage séparé - mais le C pur et le vrai Objective-C sont suffisamment différents pour que cela ressemble moins à un seul langage qu'à deux langages complètement différents qui arrive à la fois être géré par un seul compilateur (bien qu'il soit pratique que les deux puissent se parler sans quelque chose comme JNI pour les rejoindre).

Eh bien, fondamentalement, Apple est la force motrice derrière Objective-C depuis un certain temps maintenant:

• Alors que la dernière version est pratiquement abandonnée, Objective-C 2.0 commence en fait à devenir de plus en plus lié à certaines des classes / protocoles de base, ce qui signifie qu'il existe un lien inhérent entre les fonctionnalités du langage et le cadre, NSFastEnumeration me venant à l'esprit. , qui est nécessaire pour que les objets répondent correctement aux boucles for in. Cela signifie qu'il existe un lien croissant entre la langue et la plateforme.
• Il n'y a pratiquement pas d'alternative réelle au cacao. Et Cocoa à son tour commence à dépendre de plus en plus de fonctionnalités OSX. Bien que techniquement, vous pouvez avoir une implémentation d'Objective-C exécutée sur n'importe quel système d'exploitation avec n'importe quel framework de base, il n'y a pas vraiment beaucoup de choses récentes là-bas pour toute autre plate-forme.

Dans l'état actuel des choses, Apple a le contrôle total sur Objective-C et pilote le langage en fonction de ses besoins, alors qu'aucune organisation sur cette planète n'est intéressée à exécuter Objective-C sur un appareil non Apple, qui serait suffisamment grand pour fournir un bibliothèque standard et boîte à outils pour commencer, qui pourraient même rivaliser à distance avec les écosystèmes présentés par .NET / Mono, C ++ ou Java.