¿Por qué Objective-C no se usa ampliamente más allá de los ambientes de cacao?

Objective-C presenta una buena orientación a los objetos, simplicidad, elegancia y (como un superconjunto de C), habilidad de bajo nivel. Podría parecer la alternativa simple y moderna a C ++ que muchas personas buscan e intentan encontrar en Go. Pero solo se usa en los entornos Cocoa y post-NextSTEP, e incluso en este caso se considera más una carga por razones históricas que una opción óptima.

¿Por qué no se usa más ampliamente entonces? Cuales son sus problemas?

En mi opinión, el problema con Objective-C no son tanto las deficiencias masivas, como las deficiencias menores (especialmente al principio) y la falta de ventajas percibidas.

Objective-C era un superconjunto puro de C, por lo que el código C podía pasar fácilmente a Objective-C. La forma de pensar para utilizar Objective-C, sin embargo, difiere de la C mentalidad un montón . La transición de C a Objective-C es fácil para el código, pero no es fácil para muchos programadores. El programador de CA no puede elegir fácilmente algunas características nuevas y convenientes en Objective-C y obtener una mejor productividad casi de inmediato; necesita aprender muchas "cosas" nuevas antes de poder llegar a cualquier parte.

C ++ hizo la transición de algunos códigos un poco más difícil, pero la transición para la mayoría de los programadores fue mucho más fácil. Los programadores de C que están acostumbrados a lidiar con cada detalle de su código aún pueden hacerlo en C ++ exactamente en la medida que lo deseen. C ++ también facilitó el uso de algunas características nuevas (por ejemplo, agregar un ctor para inicializar automáticamente los miembros de su estructura) sin cambiar realmente su forma de pensar. Muchos puristas de OO impulsaron cambios radicales en el pensamiento, pero muchos programadores de C cambiaron a C ++ sin hacer nada por el estilo (al menos de inmediato, y a menudo siempre, por el aspecto de las cosas).

C ++ también parecía mucho más familiar para la mayoría de los programadores de C. Agregó algunas palabras clave nuevas, pero (especialmente al principio) el código aún parecía bastante familiar. A pesar de su estado de "superconjunto puro", la mayoría del código de Objective-C parece bastante extraño para la mayoría de los programadores de C. Una gran cantidad de C ++ también es bastante fácil de explicar y entender en términos de cómo funcionan las cosas en C. Cambiar a Objective-C tiene muchos más lugares en los que todo lo que puedes decir es "solo confía en mí y olvida todo lo que crees que sabes. "

Muchas de las decisiones de diseño en Objective-C también lo hicieron (algo) más lento que C ++, especialmente en máquinas relativamente antiguas con procesadores lentos, memoria limitada, etc. C ++ estaba disponible gratuitamente para que cualquiera y todos lo implementaran.

Todo esto llevó a que C ++ se adoptara lo suficientemente pronto como para lograr una "masa crítica" con bastante rapidez, por lo que (entre otras cosas) se convirtió en la opción obvia para muchos proyectos solo porque ya era una aplicación ampliamente conocida cantidad.

Objective-C nunca ha llegado a ese punto. De hecho, estaba en camino de desvanecerse en la oscuridad cuando Apple lo revivió casi forzándolo a cualquiera que quisiera desarrollarse para sus sistemas. Sin embargo, la cuota de mercado de Apple no es lo suficientemente grande como para que eso realmente le dé masa crítica, solo un nicho más grande. Es una opción "predeterminada" solo donde / porque Apple lo hace así.

También agregaría que, al menos en mi opinión, el modelo de objetos tipo Smalltalk de Objective-C significa que, en efecto, es mucho más un competidor directo de Java que C ++. Sí, todavía tiene los fundamentos de C, y sí, todavía puede escribir código de bajo nivel sin usar un lenguaje separado, pero C puro y Objective-C real son lo suficientemente diferentes como para que sea menos un solo lenguaje que dos lenguajes completamente diferentes que los dos pueden ser manejados por un solo compilador (aunque es útil que los dos puedan hablar entre sí sin que JNI se una a ellos).

Bueno, básicamente, Apple es la fuerza impulsora detrás de Objective-C desde hace algún tiempo:

• Si bien la última versión está prácticamente abandonada, Objective-C 2.0 en realidad está comenzando a estar cada vez más vinculado a algunas de las clases / protocolos básicos, lo que significa que existe un vínculo inherente entre las características del lenguaje y el marco, NSFastEnumeration que me viene a la mente , que es necesario para que los objetos respondan adecuadamente en bucles. Esto significa que hay un vínculo creciente entre el lenguaje y la plataforma.
• Prácticamente no hay una alternativa real al cacao. Y Cocoa a su vez está comenzando a depender de más y más características de OSX. Aunque técnicamente, puede tener una implementación de Objective-C ejecutándose en cualquier sistema operativo con cualquier marco central, en realidad no hay muchas cosas recientes para ninguna otra plataforma.

Tal como está ahora, Apple tiene control total sobre Objective-C y maneja el lenguaje de acuerdo con sus necesidades, mientras que no hay ninguna organización en este planeta interesada en ejecutar Objective-C en un dispositivo que no sea Apple, eso sería lo suficientemente grande como para proporcionar un biblioteca estándar y kit de herramientas para comenzar, que incluso podrían competir remotamente con los ecosistemas presentados por .NET / Mono, C ++ o Java.