¿Por qué Apple introduciría nuevos lenguajes de programación (por ejemplo, Swift) en lugar de adoptar uno existente?

Ya teníamos cosas como MacRuby, que tomó Ruby (posiblemente el lenguaje existente más cercano a Objective-C, bajo el capó) y lo hizo usar el tiempo de ejecución de Objective-C debajo, junto con los objetos Foundation que sirven como los tipos incorporados de la plataforma.

Swift fue simplemente un enfoque de pizarra limpia, aparentemente tomando señales de muchos lugares diferentes. También se esforzó por ser fácil de aprender mientras contenía algunas características potentes, todas con una sintaxis bastante mínima.

Sin embargo, no hay mandato de que nadie, dentro o fuera de Apple, use Swift. Objective-C no va a ninguna parte. Basta con mirar cuánto tiempo se han marcado algunas funciones como obsoletas, por ejemplo: doce años después todavía puede usar + [NSString stringWithCString:]. Está en desuso, pero sigue ahí … Objective-C no está en desuso, por lo que debería permanecer al menos la misma cantidad de tiempo, creo.

Desarrollador de bloqueo.

Es el estilo de Apple. Es la razón por la que se quedaron con Objective-C todos estos años también.

Apple estaba buscando un nuevo lenguaje para todo. No se trata solo de pequeñas aplicaciones en iOS que realizan solicitudes a un servidor HTTP y llenan una pantalla de iPhone con algunos tweets o lo que sea. Swift será el futuro del desarrollo de aplicaciones Macintosh. Debes poder escribir iTunes en el nuevo idioma. Debe poder escribir Photoshop en el nuevo idioma, etc.

El desarrollo de Apple siempre ha sido sobre desarrollo nativo. No les importa la plataforma cruzada; son la plataforma que les importa. Ellos controlan el hardware; Las configuraciones heterogéneas de hardware no son un problema. Por lo tanto, nunca se subieron a la locura de las máquinas virtuales de fines de la década de 1990. Cualquier lenguaje que iba a reemplazar a Objective-C tendría que ser un lenguaje que se compilara al nativo.

Dado eso, la única opción real habría sido C ++ 14. Ya tienen un excelente soporte en Xcode / Clang de características modernas de C ++ como lambdas y las últimas incorporaciones a la biblioteca estándar. Podrían haber hecho un esfuerzo para apoyar características de vanguardia como los conceptos. Podrían haber reescrito Cocoa para ser básicamente el primer gran ejemplo del diseño ultra moderno de C ++, utilizando una implementación personalizada de algo como señales de impulso y ranuras para enlazar con la interfaz de usuario y administrar la memoria con shared_ptrs et. al., etc. Pero esto (a) no habría hecho un anuncio llamativo y (b) no habría fomentado el bloqueo del desarrollador.

Así que más o menos tenía que ser un nuevo lenguaje compilado (quiero decir, supongo que podrían haber elegido a Haskell, pero eso es una locura …)

Ninguna de sus sugerencias se ajusta a la factura. No resuelven el problema principal. ¿Cómo podría Apple actualizar Objective-C para que tengamos un lenguaje más rápido, fácil y seguro sin destruir Cocoa?

Java pertenece a otra persona. Necesita una máquina virtual, y la recolección de basura que Apple ha demostrado es menos que óptima en dispositivos móviles.

Apple ya es compatible con C ++, en cierta medida. Incluyendo hacer una conexión entre C ++ y Cocoa. Pero reemplazar un lenguaje basado en C complicado por un lenguaje basado en C aún más complicado no daría lugar a un progreso. Todavía tendríamos encabezados y todo ese equipaje histórico.

Ni Python ni Ruby están compilados, lo que los descarta. Uno de los objetivos era aprovechar los avances que habían logrado con la tecnología de compilación.

Comparación de rendimiento para un ejemplo de clasificación simple:

• C ++ -O3: 0.05 s
• C ++ -O0: 0.4 s
• Java: 0.2 s
• Python con PyPy: 0.5 s
• Python: 12 s
• Rápido – Rápido: 0.05 s

Apple es famosa (o notoria) por ignorar lo que todos los demás están haciendo y por irse en su propia dirección si creen que es la mejor solución.

Swift tiene elementos de estos idiomas, y no es particularmente difícil de aprender.

El idioma está cambiando a medida que intentamos codificar aplicaciones. Lo cual es frustrante, pero también parece que estamos a la vanguardia de algo nuevo y genial.

Objective-C es notablemente terrible para trabajar como desarrollador, por lo que Apple finalmente lo está reemplazando con una versión mejorada. El éxito del ecosistema de Android (que usa Java) probablemente ayudó a impulsarlos hacia esto.

Pero, ¿por qué Apple desarrolló un nuevo lenguaje de lenguaje, Objective-C, en primer lugar? La respuesta de Franck Stauffer toca esto: Apple necesitaba un lenguaje que compilara un código rápido y eficiente en memoria para plataformas móviles, pero que también fuera fácil de usar para los desarrolladores. C ++ era (y sigue siendo) el lenguaje de facto para sistemas embebidos, pero C ++ es una tarea difícil de programar, especialmente para los nuevos programadores. En comparación con C ++, Objective-C es mucho más accesible. Esto permitió que el ecosistema de la App Store de Apple prospere, lo que sin duda fue clave para el éxito masivo del iPhone.

Muchos desarrollos de lenguaje de programación son mejoras a nuevos lenguajes. Pero si eso es todo lo que alguna vez hicimos, nos quedaríamos atrapados en los máximos locales . A veces, para lograr un progreso significativo, tenemos que hacer cosas que son radicalmente diferentes .

Además de eso, los idiomas se acumulan a medida que crecen. A menudo esto no es un gran problema, pero rápidamente se convierte en un lastre omnipresente para la productividad tanto de los usuarios como de los diseñadores del lenguaje. Comenzar de nuevo nos permite restablecer temporalmente el medidor cruft. Nos permite corregir deficiencias evidentes y fallas de diseño que de otro modo se consolidan por la compatibilidad con versiones anteriores.

Entonces, en última instancia, creamos nuevos idiomas como una forma de aumentar el progreso en los idiomas existentes.

Swift es un lenguaje de programación moderno que es rápido, seguro e interactivo. Swift es una herramienta de programación activa que se utiliza para desarrollar aplicaciones para iOS, OS X y watchOS. El uso de Swift One puede crear códigos fácilmente, ya que tiene muchas características divertidas y es interactivo, la sintaxis es corta y expresiva. Con el uso de Swift, se pueden ejecutar aplicaciones a la velocidad de la velocidad del rayo, ya que funciona en paralelo con Objective-C.

caracteristicas:

Modelo de manejo de errores:

Swift proporciona un modelo avanzado de manejo de errores que es una sintaxis clara y expresiva de manejo excepcional. Los desarrolladores pueden crear sus propios nombres de error personalizados para que puedan describir casos de error claros.

Mejoras de sintaxis:
Ahora, utilizando Swift, puede crear códigos más expresivos, ya que ha mejorado mucho en todo el idioma. El SDK ha empleado nuevas características de Objective-C, como genéricos y anotaciones de anulabilidad para mantener los códigos limpios y seguros.

Fuente abierta:
A finales de este año, Swift se denominará de código abierto. Es una combinación única de potencia, elegancia y seguridad que tiene la capacidad de hacer avanzar a toda la industria del software.

Moderno:
Considérelo como la última investigación de lenguaje de programación, combinada con una vasta experiencia en el desarrollo de plataformas Apple. Los parámetros nombrados presentados desde Objective-C se expresan en una sintaxis limpia que hace que las API en Swift sean aún más fáciles de leer y mantener.

Parques interactivos:
Usando parques infantiles uno puede escribir códigos rápidos con increíblemente simple y divertido. Los resultados aparecen inmediatamente a medida que escribe los códigos. La vista de resultados puede mostrar gráficos, listas de resultados o gráficos de un valor a lo largo del tiempo. Puede abrir el Asistente de línea de tiempo para ver cómo una vista compleja evoluciona y se anima, ideal para experimentar con un nuevo código de interfaz de usuario o para reproducir una escena animada de SpriteKit mientras la codifica.

Diseñado para la seguridad:
Elimina toda la clase de código inseguro. Las variables siempre se inicializan antes de su uso, las matrices y los enteros se comprueban en busca de desbordamiento y la memoria se administra automáticamente.

Rápido y poderoso:
Swift es un lenguaje de programación rápido de compilación y ejecución. Utiliza el compilador LLVM de alto rendimiento, el código Swift se transforma en código nativo optimizado que aprovecha al máximo el hardware moderno.

Si bien hay esfuerzos en este momento donde las personas están tratando de reinventar un idioma.

Los riesgos de reescribir un idioma:
Python2 -> Python3 fue radicalmente diferente al menos en el sentido de que rompió la compatibilidad con versiones anteriores para abordar algunos problemas centrales. Esta es una especie de respuesta no oficial de uno de los principales confirmadores de Python. Preguntas y respuestas sobre Python 3: la documentación de Python Notes 1.0 de Nick Coghlan y solo puede buscar en Google y descubrir qué tan frustrados estaban los usuarios de Python con la incompatibilidad de Python.

Mira a Perl. Está atascado con una revisión menor. Con las especificaciones de Perl 6 y varias implementaciones, romperá Perl 5. De hecho, Perl 6 es un lenguaje completamente diferente. [con modo de compatibilidad para Perl6]. Las personas que usan hoy Perl “temen” que la migración a Perl 6 cuando una de las implementaciones de Perl se convierta en la implementación del portador de la antorcha para la especificación Perl 6. [Lea esto para saber más: El discurso del “Estado de la cebolla” de Lary Wall sobre Perl 6 en 2000 Estado de la cebolla 2000]

El punto es que se requiere un gran esfuerzo cuando los idiomas antiguos hacen cambios tan radicales. El esfuerzo no solo proviene de los desarrolladores principales del idioma, sino también de la comunidad. También existe un gran riesgo de incluso perder el interés o la participación de la comunidad debido a “ruptura y falta de confiabilidad”. Los lenguajes tan populares como Java garantizan la compatibilidad con versiones anteriores cuando lanzan nuevos y utilizan el mecanismo de “desaprobación” para pasar a mejores implementaciones. En el otro extremo, los lenguajes como Groovy y Scala [lenguajes JVM] son ​​lenguajes nuevos que son multi-paradigmáticos y están cargados con los enfoques más recientes [en realidad más antiguos] para el diseño del lenguaje, pero que aún funcionan en la JVM antigua.

Escribir un idioma puede no ser fácil, pero obtener la adopción es difícil:

Escribir un nuevo idioma es un esfuerzo, por supuesto, pero la adopción es otro. Los usuarios no son solo la “base de usuarios” sino que también sirven como fuentes de retroalimentación muy efectivas e importantes para mejorar el idioma. Crecer una base de usuarios también es muy difícil. Incluso los idiomas como “Go” y “dart” creados por google donot tienen una gran base de admiradores o esperan ser adoptados por millones de personas en todo el mundo en sus primeros 5 años. Si tiene un idioma con licencia comercial, debe hacer algo más que escribir un idioma y sus bibliotecas.

ColdFusion era un lenguaje promocionado como el próximo lenguaje “web” de Internet que ofrecía una fuerte competencia a .Net [especialmente porque en los días anteriores a 2005 estaba escrito en vc ++ 6.0 y, por lo tanto, solo se ejecutaba en Windows] y Java [luego fue reescrito en Java y finalmente se convirtió en un lenguaje jvm]. No tengo suficientes referencias [solo recuerdos de discusiones con prog-community en los últimos 8 años] sobre por qué ColdFusion falló. El desarrollador principal se mudó a Yahoo, Microsoft, etc., Microsoft se aseguró de que .Net tuviera una biblioteca para hacer cualquier cosa [incrustado, escritorio, web]. Se aseguró de que el mensaje llegue a todos [con su fuerte efectivo y relaciones públicas].

Si no tiene bibliotecas y marcos que faciliten el desarrollo de software, entonces no tiene una solución completa.

Muchos de los idiomas gratuitos y no comerciales comienzan en un aula de profesores donde el profesor enseña a sus alumnos nuevos conceptos de programación utilizando estos mismos idiomas. Los estudiantes terminan usándolos en sus proyectos y se convierten en expertos en ellos. Algunos de ellos terminan escribiendo bibliotecas para estos idiomas [que extienden la base funcional del lenguaje]. Incluso los desarrolladores principales a veces terminan escribiendo bibliotecas / marcos extendidos a su alrededor. Las personas que necesitan / usan estas bibliotecas y marcos terminan siendo los usuarios de primera línea del lenguaje. Así es como comienza la base de usuarios. Para cualquier idioma nuevo es muy importante el tipo de bibliotecas que puede proporcionar. Lograr una comunidad suficiente para construir una biblioteca integral es muy importante en cuanto al alcance y el uso del lenguaje.

Imagine que se da cuenta de que Java como lenguaje no está completo y termina escribiendo un nuevo lenguaje desde cero. El lenguaje es increíble y todos, pero nunca agregaste ninguna biblioteca y las personas que buscan marcos de trabajo tipo “j2ee” y “spring” siempre apreciarán tu idioma pero nunca lo usarán. No tiene dinero para “comprar” desarrolladores para implementar funciones, ni tiene poder y recursos para construir la comunidad a su alrededor.

Ahora, relacionando esto con su pregunta, mi respuesta a su suposición es “No, no es más fácil escribir un nuevo idioma y tener éxito con él”

La gran razón es que necesitaban que el nuevo lenguaje fuera retrocompatible con Objective-C y, por supuesto, compatible con Cocoa, que presenta su API, en general, en Objective-C.

Eso significa cosas como parámetros con nombre, el sistema de delegado, extensiones a clases, cosas así.

Creo que si Apple hubiera elegido un idioma existente, habría sido necesario escribirlo estáticamente, lo que excluye a Python y Ruby.

Apple había establecido que su puesto estaba en contra de Java, por lo que realmente no podían seguir ese camino.

Scala necesita la JVM, así que eso está fuera.

C ++ da un poco de miedo a los principiantes.

C # es un gran lenguaje, pero quizás Apple no quería una tecnología propiedad de Microsoft.

Sin embargo, en última instancia, Apple tiene requisitos que otros idiomas simplemente no tienen, tiene que ser compatible con Obj-C y con Cocoa. Podrían obligar a un sistema existente a jugar bien con él, pero considerando todo, probablemente fue una buena idea seguir su propio camino.

Descargo de responsabilidad: esta es una respuesta cínica.

C es un lenguaje extremadamente inseguro. Esto no es malo ni bueno. Está demasiado cerca del hardware para ser seguro (piense en el ensamblaje del siglo XXI). Si sabes lo que estás haciendo, y será mejor que estés paranoico al respecto, está bien.

Obj-C, siendo un superconjunto de C, es igual de inseguro porque inherentemente le permite hacer todas las cosas estúpidas / irresponsables que puede hacer en C más algunas de las suyas.

Ahora, el loco crecimiento de la App Store ha atraído a un número increíble de desarrolladores, la mayoría de los cuales son / fueron en realidad novatos (nuevamente, no es algo malo). Las historias rápidas de éxito, el marketing sin sentido y la creencia de que en la actualidad cualquier niño de 3 años puede hacer una fortuna en la App Store creó una premisa falsa de que programar para iOS es fácil. Lo malo es que C (y, por extensión, Obj-C) no fue diseñado para ser infalible y, de hecho, requiere una buena cantidad de conocimiento de bajo nivel y pensamiento de bajo nivel. Las personas que, naturalmente, esperaban lanzar una aplicación exitosa por fin de semana, se encontraron con errores malos. Esto es normal. El proceso de aprendizaje solo requiere tiempo, esfuerzo y paciencia.

Sin embargo, la baja calidad de la aplicación y la falta de control de calidad (no se espera un control de calidad serio de una tienda de un solo hombre que vende ¢ 99 aplicaciones, ¿verdad?) Inevitablemente conducen a la frustración. A los clientes no les gusta bloquear aplicaciones y culpar al menos a la plataforma de Apple. Ahora las cabezas inteligentes de Apple tienen un problema que no tiene una solución simple. Para ser precisos, eso no es un problema de ingeniería pura, pero desde iOS, los frameworks, Xcode y LLVM son mantenidos por ingenieros, que de alguna manera se convirtió en un problema de ellos.

Y los ingenieros de Apple, siendo inteligentes, han encontrado una solución. ¡Nuevo idioma! Irónicamente, ningún lenguaje de programación puede reparar miles de radares abiertos durante años. Imagine arreglar la ley y el orden quebrantados, los prejuicios, el calentamiento global y la injusticia general al cambiar a un idioma extranjero. Me parece irónico porque quien inventó Swift debe saber que diseñar un lenguaje de programación es varios órdenes de magnitud más difícil que usarlo. Lo que no entiendo es por qué todo el mundo parece pensar que Swift es de alguna manera más fácil que Obj-C. En mi opinión no tan humilde, no lo es, y puede crear más problemas de los que puede resolver.

En cuanto a por qué eligieron un nuevo idioma en lugar de uno de buena reputación, la respuesta simple es la interoperabilidad con los marcos Obj-C. De hecho, es un gran problema de ingeniería (ABI, espacio de direcciones común y todo) y, aún más irónicamente, eso ha mordido a Swift desde el día cero.

Mi respuesta se basa en ser un usuario a largo plazo (20 años) de C ++ y un experto en idiomas que ha estado estudiando lenguajes de programación durante la mayor parte de los últimos 30 años. He programado en la mayoría de las plataformas, especialmente portando entre Mac y Windows (ambas direcciones).

He pasado por la revolución OO y he estado aprendiendo programación funcional como actividad de fondo durante los últimos 5 años.

Cuando aprendí Python, cambió un poco la forma en que programé.

Cuando aprendí la Programación Funcional, tuvo un profundo efecto en cómo programaba, pero tuve que usar C ++ la mayor parte del tiempo. El C ++ 11 moderno me permitió usar mucho más estilo de FP pero a un costo de legibilidad y aún no tanto como quería.

Apple necesitaba lograr muchas de las cosas que son las fortalezas del C ++ moderno pero sin su sintaxis verdaderamente horrible y muchas muchas trampas.

Necesitaban un lenguaje que pudiera funcionar con los bits buenos de Objective-C, a través de un puente seguro, pero que permitiera a las personas escribir código más rápido con más seguridad.

Nada, literalmente, nada en el planeta tenía esa mezcla de características.

Aplaudo el coraje y la dedicación de Apple al comprometerse con Swift. Nadie más ha hecho algo así: Google y Microsoft tienen sus propios idiomas, pero ninguno ha hecho nada como el movimiento dedicado que Apple ha hecho.

Cuando Apple decidió reemplazar Objective-C, probablemente su objetivo más importante era la interoperación: cualquier reemplazo tendría que funcionar naturalmente con los marcos existentes. Eso significa que no solo tendría que ser técnicamente posible llamar a Objective-C, sino que también es sintácticamente natural.

Eso significa, solo para comenzar, que tiene que admitir parámetros de métodos con nombre, que son tan intrínsecos a Objective-C que eliminarlos cambiaría fundamentalmente el carácter de los marcos de Apple. Eso elimina Java y C ++ desde el principio. Scala y Python tienen “argumentos de palabras clave”, pero funcionan de manera muy diferente a los de Objective-C, y probablemente no serían adecuados.

Ruby 2.1, por otro lado, admite argumentos de palabras clave que funcionarían con Objective-C. De hecho, Apple escribió esto en un momento: se llamaba MacRuby. Sin embargo, Apple abandonó MacRuby, por lo que aparentemente no estaban contentos con eso. Un desarrollador externo más tarde lo recogió para hacer RubyMotion, pero por alguna razón, Apple no parece querer usar Ruby.

(Parte de la razón podría ser que Swift está diseñado para permitirte hacer un trabajo de muy bajo nivel si estás dispuesto a aceptar el riesgo. Apple eventualmente quiere poder escribir cualquier cosa, en cualquier nivel de su sistema operativo, en Swift , todo el camino hasta el núcleo si es necesario. No hay forma de que puedan hacer eso con Ruby).

Hay una gran cantidad de idiomas en el mundo, y probablemente haya algo que Apple podría haber aprendido si hubiera querido. Pero creo que, al final, no quisieron. Apple ha tenido prácticamente el idioma principal de su plataforma durante casi 15 años, y resulta que es una posición realmente cómoda para estar, si desea solucionar un problema de idioma como clases base frágiles, o agregar una función de idioma como bloques, poseer su El lenguaje significa que puede ir y hacerlo sin tener que preocuparse por la compatibilidad con la implementación de otra persona. Microsoft ahora tiene lo mismo en C #, y parece que les gusta tener ese poder igual.

Al crear su propio lenguaje desde cero, Apple está limitado por nada más que sus propios requisitos y recursos. Dado que sus requisitos son bastante específicos y sus recursos incluyen uno de los mejores equipos de compilación del mundo, es un lugar bastante bueno para estar.

Basado en la presentación de Apple, características del lenguaje

• Cierres (similares a bloques en C y Objective-C) unificados con punteros de función
• Tuplas y múltiples valores de retorno
• Genéricos
• Iteración rápida y concisa sobre un rango o colección
• Estructuras que soportan métodos, extensiones, protocolos.
• Patrones de programación funcionales, p. Ej .: mapa y filtro

El compilador está optimizado para el rendimiento y el lenguaje está optimizado para el desarrollo.

Swift es más fácil de aprender que Objective-C. El lenguaje está inspirado en varios lenguajes de programación como Objective-C, C #, Ruby, Rusy, Haskell, Python, etc. Las construcciones de programación funcional ayudan al programador a ser mejor productivo que Objective-C. Para ser más precisos, como dijo Craig Federighi, solo queremos eliminar el equipaje de C del Objetivo C.

El verdadero jugador detrás del rendimiento de Swift es el compilador base LLVM. LLVM tenía como objetivo proporcionar una compilación rápida, un bajo uso de memoria y una arquitectura basada en biblioteca modular. LLVM fue creado originalmente por Chris Lattner cuando era pasante de verano en la investigación de Microsoft. Apple extendió su soporte para desarrollar el compilador basado en LLVM y específicamente querían soportar el compilador basado en LLVM para Objective-C. Más tarde, Lattner propuso integrar LLVM con GCC, lo que ayudó a traer métodos modernos para las optimizaciones y el rendimiento del compilador y más tarde conocido como LLVM-GCC.

LLVM evolucionó y tiene más funciones para agregar fácilmente a Objective-C. Swift es un lenguaje de programación de sistemas que es tan expresivo y agradable como un lenguaje de secuencias de comandos.

Obtiene un lenguaje altamente productivo y un código mejor optimizado con la ayuda de LLVM.

Querían un lenguaje sencillo, intuitivo y conciso como Ruby o Python, que esté tipado y compilado estáticamente como Java, C # o C ++.

A menos que quiera discutir Go by Google, no hay otros. Y Apple quiere liderar la evolución del lenguaje ellos mismos, por lo que necesitan control. Ciertamente, no lo dejarían en manos de Google, su mayor competencia móvil.

C es un lenguaje extremadamente inseguro. Obj-C, ser un superconjunto de C es igual de inseguro. Ahora, el loco crecimiento de la App Store ha atraído a un número increíble de desarrolladores. Apple había establecido que su puesto estaba en contra de Java, por lo que realmente no podían baja por esa ruta.

Apple ya es compatible con C ++, en cierta medida. Incluyendo hacer una conexión entre C ++ y Cocoa. Pero reemplazar un lenguaje basado en C complicado por un lenguaje basado en C aún más complicado no daría lugar a un progreso.

Apple es famoso por ignorar lo que todos los demás están haciendo y salir en su propia dirección si creen que es la mejor solución.

Swift tiene elementos de estos idiomas, y no es particularmente difícil de aprender.

El idioma está cambiando a medida que intentamos codificar aplicaciones.

Diseño y desarrollo web | Marketing digital | Empresa de desarrollo de aplicaciones y juegos móviles Noida, India-Websquare.co

La mayor “característica” de Swift es que es altamente interoperable con Objective-C y particularmente con los marcos existentes para iOS y Mac escritos en ObjectiveC.

Ahora que he pasado unos meses escribiendo código Swift, puedo entender muchas de las elecciones que Apple hizo al diseñar el lenguaje.

El código rápido interopera MUY BIEN con la base de código existente. Los objetos escritos en Swift aún pueden interactuar con los objetos del Objetivo C (por ejemplo: los objetos de Swift pueden heredar y extender los objetos del Objetivo C, y viceversa)

Swift NO requiere conocer ningún marco nuevo.
Puede transferir su código Objective C existente “una clase a la vez” a Swift. Hay un esfuerzo para reorganizar un poco sus encabezados si está haciendo un código mixto Objective-C / Swift, pero permite que tanto Apple como los desarrolladores existentes de iOS y Mac continúen utilizando su inversión en su código Objective C existente, y migrar a Swift de forma incremental.

Pero agrega algunas características necesarias muy agradables que ofrecen los idiomas modernos. Y, en general, mi código Swift se ha sentido más simple, más limpio y más legible que la misma lógica implementada en Objective-C.

En cuanto a Apple usando un lenguaje que nadie más está usando … Bueno, ya nadie más estaba usando Objective-C tampoco. Entonces eso no es nuevo.

Cuando la gente me preguntaba si Objective-C era difícil, les decía que en realidad no era un lenguaje difícil. El verdadero desafío para el desarrollo de iOS es comprender los marcos API de iOS y Mac, y comprender cómo construir buenos productos al “estilo Apple”. Apple no le ofrece ninguna otra opción para crear una aplicación iOS: su aplicación DEBE usar elementos UIKIT para poder compilarse y ejecutarse en dispositivos iOS.

Apple tiene una gran inversión en la construcción y el soporte de esos marcos. Por lo tanto, incluso si Apple quiere comenzar a portar internamente su propio código fuente a Swift, deberán continuar apoyando a los clientes de Objective-C durante mucho tiempo. Swift les permitirá hacer eso.

A veces, las características que no tiene un idioma son tan importantes como las que tiene. Algunas características que parecían una buena idea en ese momento demuestran ser menos deseables que las alternativas que no se pensaban o no se consideraban prácticas en ese momento. Por ejemplo, usar malloc y free o new y delete para administrar la memoria requiere que el programador tenga una comprensión global de dónde se utilizan sus estructuras de datos para que puedan saber cuándo liberarlas. Usar un recolector de basura para administrar la memoria es mucho más fácil y seguro. Podría desarrollar una biblioteca para manejar la recolección de basura que se usará en C o C ++ (de hecho, esto se ha hecho), pero necesariamente habrá nuevas limitaciones sobre cómo usar C o C ++ si desea usar la recolección de basura. Entonces, para admitir mejor la recolección de basura, necesita un nuevo lenguaje, como Java.

El sistema de tipos de Java permite punteros nulos, y esta es una fuente de errores de programador. Algunos lenguajes han introducido el concepto de tipos anulables, y prohíben que los tipos que no pueden anularse contengan un valor nulo. Dicha característica podría agregarse a Java (y se ha agregado a C #, que es similar), pero un enfoque más limpio sería utilizar tipos algebraicos, que otorgan el mismo poder y permiten una precisión mucho mayor en el diseño de tipos. Sin embargo, ese cambio no se puede adaptar a un idioma existente.

La programación de orden superior (lambda y cierres) es una característica del lenguaje con creciente popularidad. Puede agregar lambda y cierres a Java (y esto finalmente se ha hecho), pero la actualización destructiva limita la utilidad de
código de orden superior, ya que un cierre que cree manteniendo un valor puede terminar manteniendo un valor diferente para el momento en que se aplica el cierre. De hecho, la actualización destructiva de los datos compartidos es un problema en muchos contextos, que requiere que el programador tenga una comprensión global del programa y donde los valores se modifican para comprender el comportamiento de una sola llamada. Pero cualquier intento de eliminar la actualización destructiva de datos compartidos de Java dejaría un lenguaje irreconocible. Tendría mucho más sentido crear un nuevo lenguaje (o simplemente usar uno existente) que no tenga una actualización destructiva.

Apple modernizó gradualmente Objective-C (propiedades, ARC, …) y ahora ha llegado a un punto en el que el siguiente paso era crear un nuevo lenguaje al que los desarrolladores experimentados de Objective-C pudieran hacer la transición. Claramente, elegir un lenguaje existente desde ese punto de vista habría hecho poca diferencia desde esa perspectiva.

Los lenguajes basados ​​en JVM (Scala, Java) o los lenguajes de script (Python) no eran una opción (mantenerse a la par con el uso / rendimiento de la memoria es extremadamente importante). C ++ habría sido una pesadilla para la gran mayoría de los desarrolladores (pocas personas tienen las habilidades para escribir un buen C ++). No quedaban muchas opciones …

El desarrollo rápido comenzó en 2010 dentro de Apple, con comentarios de personas que usan Objective-C a diario para que pueda estar seguro de que está muy bien diseñado para que esa transición sea fluida.

Por supuesto que podrían haber hecho eso. Tienen muchos recursos.

Supongo que tiene sentido presentar a Swift como su “propio” lenguaje, porque ellos:
– No tiene que esperar a otros, obtener la aceptación de otros que no sean sus desarrolladores y que puedan desarrollar el lenguaje para cumplir sus propios objetivos.
– tiene que hacerlo funcionar con una tonelada de marcos existentes.
– pueden tomar lo que consideran el “mejor” de otros idiomas.

Después de haber jugado con Swift, lo considero una versión “modernizada” del Objetivo C. Me parece que me alejo aún más del manejo manual de la memoria, lo que considero una bendición.

No lo sé, pero parece que las personas que son excelentes en lo que hacen tienen fuertes ideas sobre cómo hacerlo bien . Microsoft creó varios idiomas, incluso uno para la web (TypeScript), Google creó Dart, Facebook: Hack, Adobe: LiveScript y ahora Apple: Swift. Si Yahoo aún no lo ha hecho, estoy seguro de que lo harán.

Es posible que sintieran que el lenguaje necesitaba ciertas características que no podrían encontrar en otro lado. También es posible que quisieran representar mejor el dominio del problema. La idea de las DSL es pasar de la semántica general a las específicas del dominio. No puedo decir con certeza; esto es solo una conjetura. Solo digo que es bastante universal que las personas inteligentes tengan sus propias ideas sobre cómo deben hacerse las cosas. Si estudia los lenguajes de programación el tiempo suficiente, comenzará a preguntarse si no podría reunir el cierto conjunto de características que más le atraigan.

Finalmente, una vez que conoce una variedad de idiomas que aprovechan los conceptos que se encuentran en los diferentes paradigmas, se da cuenta de que los idiomas son solo amalgamas de los conceptos populares del lenguaje. Cada uno es solo una combinación diferente de esos conceptos. Solo a veces se introducen nuevos conceptos. La mayoría está lo suficientemente cerca de alguna idea probada y verdadera del pasado.