Aprendizaje de programación Swift: ¿Está listo para el horario de máxima audiencia?

El lanzamiento de Apple en junio pasado de Swift, un nuevo lenguaje de programación para escribir aplicaciones de iOS, creó una gran expectación y entusiasmo en toda la comunidad de desarrolladores de iOS.

Desde su lanzamiento, muchos desarrolladores de iOS han estado luchando con la cuestión de si, cómo y cuándo hacer la transición de Objective-C a Swift. La respuesta a esa pregunta, por supuesto, será diferente para cada equipo y cada proyecto.

Hay varios artículos que puede leer que cubren muchas de las ventajas de Swift. Entonces, en lugar de repetir esos mismos puntos, en este artículo nos centraremos en algunas de las inquietudes que quizás desee considerar antes de aprender a desarrollar aplicaciones con Swift.

Pero primero, retrocedamos un poco el reloj...

Antes de Swift: Usarás Objective-C, y te gustará…

Era el año 2010. El iPhone aún no tenía 3 años, y la capacidad de escribir aplicaciones nativas para el iPhone solo había existido durante aproximadamente 2 años. El 8 de abril de ese año, Apple anunció la versión del iPhone OS. El iPhone OS (esto fue antes de que cambiara su nombre a iOS) incluía características nuevas y tentadoras como multitarea, cambio rápido de aplicaciones y servicios en segundo plano. Comprensiblemente, los desarrolladores de iPhone estaban ansiosos por tener en sus manos el nuevo SDK y comenzar a jugar con todas esas nuevas y emocionantes funciones.

Pero el iPhone OS 4 SDK contenía una bomba inesperada. Esta bomba no estaba en el software, estaba en el acuerdo de uso. Con iPhone OS 4 SDK, la Sección 3.3.1 del Acuerdo de desarrollador se actualizó para incluir el siguiente lenguaje problemático:

Las aplicaciones deben estar escritas originalmente en Objective-C, C, C++... y solo el código escrito en C, C++ y Objective-C puede compilarse y vincularse directamente con las API documentadas.
– Sección 3.3.1 del Acuerdo de desarrollador SDK de iPhone OS 4

No hace falta decir que esta nueva restricción tomó por sorpresa a muchos desarrolladores. El motivo oficial del cambio, proporcionado por el propio Steve Jobs, fue evitar el uso de herramientas multiplataforma como el recientemente anunciado Flash CS5. Se citó a Jobs diciendo que "las capas intermedias entre la plataforma y el desarrollador finalmente producen [sic] aplicaciones de calidad inferior". Pero el hecho de que el enfoque de Apple para combatir estas "capas intermedias" fuera restringir los lenguajes de programación que se podían usar para escribir aplicaciones para iPhone reveló algo más sobre el pensamiento de Apple: Objective-C debería ser lo suficientemente bueno para cualquiera.

Se podría perdonar a alguien por estar de acuerdo con esta afirmación, ya que Objective-C ganó el premio al "Lenguaje de programación del año" de Tiobe Index dos años seguidos. Pero la realidad era que la popularidad de Objective-C era una función del creciente ecosistema de aplicaciones, y no al revés. Incluso en 2010, muchas personas ya no estaban satisfechas con Objective-C y, como resultado, ya estaban surgiendo formas alternativas de escribir aplicaciones para iPhone en otros lenguajes de programación.

Eventualmente, bajo la presión de la comunidad de desarrolladores en general, Apple rescindió estos cambios a la Sección 3.3.1 del Acuerdo de desarrollador SDK solo cinco meses después. Aun así, el mensaje era claro: si querías escribir aplicaciones para el iPhone, probablemente deberías usar Objective-C.

… o tal vez no. Ingrese el nuevo idioma de iOS Swift.

Avance rápido 4 años desde ese incidente hasta junio de 2014 cuando Apple presentó a los desarrolladores su nuevo lenguaje, Swift. Si el mensaje de 4 años antes era que Apple estaba perfectamente satisfecha con Objective-C, entonces el mensaje enviado por la presentación de Swift fue que Apple finalmente estaba lista para admitir la verdad. Objective-C podría no ser necesariamente el mejor lenguaje para escribir aplicaciones móviles.

Mucho se ha dicho sobre cómo Swift es un lenguaje más “moderno” que Objective-C. Si está interesado en cómo aprender el lenguaje de programación Swift, puede consultar la guía para pasar de Objective-C a Swift.

Sin embargo, lo que debe notar es que hay dos diferencias importantes entre los lenguajes Objective-C y Swift:

1. Swift no es un superconjunto estricto del lenguaje C.
2. Swift se escribe estáticamente, no se escribe dinámicamente.

No ser un superconjunto estricto de C significa que Swift es libre de hacer uso de construcciones de sintaxis que de otro modo no estarían permitidas. Esto hace posible, por ejemplo, implementar operadores personalizados en Swift.

Estar tipificado estáticamente significa que Swift puede aprovechar muchos de los avances recientes en los sistemas de tipos iniciados por lenguajes como Haskell.

A pesar de haber estado en desarrollo durante 4 años antes de ser revelado al público, Swift aún es un lenguaje de programación joven, por lo que viene con una serie de advertencias.

Compatibilidad con Objective-C

iOS comparte una herencia común con OS X, que a su vez toma su historia del sistema operativo NeXTSTEP lanzado por primera vez en 1989. NeXTSTEP se escribió originalmente en gran parte en Objective-C, y muchas de las bibliotecas principales en OS X e iOS tienen sus raíces en todo el camino de regreso a estas implementaciones originales. (Por cierto, aquí es de donde proviene el omnipresente prefijo "NS" que se encuentra en las clases principales como NSString ). tendrá que interactuar con Objective-C.

Para su crédito, los desarrolladores detrás de Swift han hecho un trabajo fantástico al hacer que la interacción con las bibliotecas de Objective-C existentes sea lo menos dolorosa posible. Sin embargo, eso no quiere decir que el proceso sea completamente libre de dolor. Apple ha proporcionado una guía útil que explica cómo llamar al código Objective-C desde Swift y viceversa, pero hay algunos desajustes de impedancia importantes a tener en cuenta.

Quizás el desajuste más obvio se relaciona con los archivos de encabezado. Objective-C, debido a sus raíces C, aún requiere que las funciones se declaren antes de ser llamadas. Al llamar a una biblioteca, estas declaraciones se encontrarán en los archivos de encabezado de la biblioteca. Sin embargo, Swift no utiliza archivos de encabezado. Por lo tanto, si desea llamar al código Swift desde Objective-C, primero deberá crear un "encabezado puente". Si bien conceptualmente esto puede no parecer tan complejo, en la práctica, en realidad puede ser una gran tarea.

Otro conjunto de complicaciones en la interfaz entre Swift y Objective-C se deriva de las diferencias inherentes en sus sistemas de tipos. Swift, siguiendo el ejemplo de otros lenguajes modernos, ha eliminado el concepto de nil . En su lugar están los tipos opcionales de Swift. Por ejemplo, un método que abre un archivo solo si ya existe, tendría un tipo de retorno de File? (en lugar de solo File ) en Swift. Al rastrear todos los lugares donde los tipos son opcionales, el compilador Swift puede hacer que sea imposible encontrar el temido "Error de puntero nulo". Eso es, por supuesto, a menos que esté llamando a Objective-C. Dado que Objective-C no ofrece garantías de no devolver nil , Swift tiene una categoría especial de tipos llamados Opcionales implícitamente desenvueltos que se usan al llamar al código de Objective-C. Estos tipos se pueden tratar como opcionales en el lenguaje Swift, junto con todos los gastos generales que los acompañan necesarios para verificar la existencia. Alternativamente, se pueden usar igual que cualquier tipo no opcional, pero si Objective-C devuelve un nil , terminará con un error de tiempo de ejecución, por lo que perderá algunas de las garantías de seguridad en tiempo de compilación de Swift.

Finalmente, un desajuste un poco más sutil a tener en cuenta cuando se programa entre Swift y Objective-C tiene que ver con la forma en que los objetos y las clases se crean de forma oculta en estos dos lenguajes. Objective-C, debido a su naturaleza dinámica, utiliza envío dinámico para llamar a métodos en objetos (a través objc_msgSend ). Swift ciertamente puede usar el envío dinámico, pero dado que está tipificado estáticamente, también tiene la opción de usar un vtable para almacenar punteros de función para cada método. Cuál de estos dos mecanismos usa Swift depende de un par de factores. Plane Old Swift Objects usará el mecanismo vtable , a menos que la clase o los métodos dentro de la clase estén anotados usando el atributo @objc Swift. Las clases de Swift que heredan de las clases de Objective-C usarán el despacho dinámico para los métodos heredados, pero no para los métodos nuevos introducidos por la subclase (aunque, de nuevo, puede forzar el uso del despacho dinámico con el atributo @objc ). Independientemente, el código Swift siempre podrá funcionar con clases Swift, pero el código Objective-C solo puede utilizar objetos y métodos Swift que se hayan anotado correctamente.

¿Más rápido que Objective-C?

Cuando Apple presentó su lanzamiento, uno de los beneficios de Swift que se destacó especialmente fue su velocidad. Esto es comprensible si se tiene en cuenta que una de las razones que se dan a menudo para la reticencia de Apple a cambiar de Objective-C a un lenguaje de nivel superior es que Objective-C, al ser esencialmente una extensión de C, era capaz de crear programas mucho más rápidos y eficientes. que algo como Python o Ruby. Aun así, Objective-C no es un cohete cuando se trata de rendimiento absoluto, y gran parte de eso se puede atribuir a la escritura dinámica. Entonces, con Swift adoptando un sistema de tipo estático, uno esperaría que Swift sea al menos tan rápido o más rápido que Objective-C.

Por supuesto, como dice el refrán, “Hay tres tipos de mentiras: mentiras, malditas mentiras y puntos de referencia”. (O algo así…) Ciertamente, existen numerosas razones por las que el lenguaje Swift podría funcionar más rápido. Desafortunadamente, parece que la forma en que Swift utiliza la técnica ARC (recuento automático de referencias) de Apple para la gestión de la memoria a veces da como resultado que el compilador de Swift genere programas significativamente más lentos, especialmente con configuraciones de optimización más bajas (como la que podría usar durante el desarrollo). La buena noticia es que parece que las mejoras de Swift abordan continuamente este problema y, por lo tanto, es probable que en un futuro cercano Swift genere ejecutables al menos tan rápido o más rápido que Objective-C.

Sin embargo, hay otra advertencia sobre la velocidad de Swift. El objetivo de Swift es que los desarrolladores no escribirán el mismo código que habrían escrito en Objective-C. ¿Qué significa esto para el rendimiento? Bueno, ciertamente significa que comparar el rendimiento entre Swift y Objective-C es más complicado de lo que pueden revelar los puntos de referencia simples. También significa que comparar el rendimiento absoluto en tiempo de ejecución de los ejecutables generados solo cuenta la mitad de la historia.

Todo el mundo quiere programas rápidos, pero a menudo la velocidad de desarrollo es igual de importante, si no más. Un lenguaje más expresivo, capaz de realizar más trabajo en menos líneas de código, puede ser un gran beneficio en este sentido. Por otro lado, cuando se trabaja en un lenguaje compilado donde el ciclo de edición-compilación-ejecución-depuración ocupa gran parte del día de un programador, un compilador lento puede afectar seriamente la productividad. Si bien la evidencia es principalmente anecdótica, parece que el compilador Swift actualmente es lo suficientemente lento como para ser molesto, especialmente cuando se trabaja con código que utiliza el sistema de tipos avanzado de Swift. Un grupo incluso encontró que la velocidad de compilación era lo suficientemente problemática como para motivar un cambio a Objective-C.

el compilador

Hablando del compilador Swift, es en sí mismo la fuente de aún más advertencias al considerar hacer el cambio al nuevo lenguaje Swift. Además de la velocidad de compilación, a medida que Swift surgió del pequeño grupo de desarrolladores que trabajaban con él en Apple y se lanzó a las masas, el compilador comenzó a mostrar grietas bajo el estrés. Incluso hay un repositorio completo de GitHub dedicado a recopilar ejemplos de código que harán que el compilador de Swift se bloquee.

También está la cuestión de cómo cambiará el compilador de Swift. Otro proyecto en GitHub está recopilando especulaciones y análisis de la comunidad sobre qué cambios podrían estar reservados para Swift. Por ejemplo, los operadores personalizados pueden ejercer una presión significativa sobre un analizador. Inicialmente, los operadores personalizados en Swift no podían usar un signo de interrogación (?). Si bien esto se solucionó en la última versión de Swift, continúan llegando solicitudes de la creciente comunidad de desarrolladores de Swift para obtener aún más flexibilidad en lo que puede considerarse un operador personalizado válido.

Cada vez que escuche que el analizador de un idioma está cambiando, debería detenerlo. El analizador de un lenguaje es el corazón y el alma de un lenguaje de programación. Antes de que se pueda aplicar cualquier semántica del lenguaje para impartir significado al código, es el analizador el que determina qué es y qué no es un código válido para empezar. Es alentador, entonces, que Apple haya prometido garantizar cierto nivel de compatibilidad de tiempo de ejecución para Swift. Sin embargo, eso no garantiza necesariamente que el código Swift se ejecutará sin volver a compilarse para cada nueva versión de Xcode y/o iOS. Tampoco garantiza que no necesitará volver a escribir partes de su código Swift para seguir siendo compatible con versiones futuras de Swift. Pero nuevamente, el compromiso de Apple de hacer que este proceso sea lo menos doloroso posible es al menos un pequeño consuelo.

Comunidad

Algunos de los peores lenguajes de programación jamás creados (que permanecerán sin nombre) se han mantenido a flote, mucho después de que el sentido común dijera que deberían haber sido relegados al basurero de la tecnología fallida solo por la fuerza de sus respectivas comunidades. Al mismo tiempo, la colección de lenguajes de programación realmente agradables que no lograron afianzarse por falta de una comunidad es demasiado numerosa para contarla. Las comunidades sólidas producen tutoriales, responden preguntas sobre Stack Overflow, se reúnen en línea o en persona en conferencias para compartir historias, consejos y trucos, y escriben y comparten bibliotecas útiles entre ellos. Al elegir qué idioma usar para un proyecto, la comunidad es definitivamente algo a considerar.

Lamentablemente, la comunidad de iOS/Objective-C no tiene la mejor reputación de ser amigable y acogedora. Eso está cambiando gradualmente, y el código abierto está desempeñando un papel cada vez más importante en el desarrollo de Objective-C. Aún así, en esta etapa inicial es difícil saber cómo será la comunidad de Swift en el futuro. ¿Consistirá principalmente en desarrolladores aislados que trabajan solo con las API oficiales de Apple y sus propias colecciones privadas de código? ¿O será una comunidad vibrante de grupos que comparten consejos, trucos y bibliotecas útiles?

Otra faceta del rol de la comunidad es el rol de los propios desarrolladores de Swift. La tendencia general en la programación ha sido alejarse de los lenguajes y plataformas de programación propietarios hacia soluciones de código abierto. El desarrollo Open Source, especialmente a nivel de lenguajes de programación y tiempos de ejecución, puede ser una verdadera ventaja. Si bien los desarrolladores de Swift han declarado varias veces que su intención es abrir completamente el lenguaje y el tiempo de ejecución de Swift, eso aún no ha ocurrido, por lo que se justifica la precaución.

Dicho esto, los desarrolladores detrás de Swift son algunos de los mismos desarrolladores detrás del proyecto LLVM de larga duración. LLVM no es una analogía perfecta, ya que comenzó a la luz como un proyecto de la Universidad de Illinois, Urbana-Champaign. Pero para su crédito, los desarrolladores principales se han mantenido muy abiertos y comprometidos con la comunidad, incluso después de que la mayoría de ellos hicieran la transición para trabajar para Apple. Es completamente razonable esperar que el lenguaje Swift continúe desarrollándose (en su mayoría) al aire libre, aunque aún está por verse si los parches y las sugerencias de funciones de la comunidad llegarán al lenguaje.

¿Debería aprender Swift?

Por supuesto, aquí no hay una respuesta de "talla única". Como siempre, elegir la herramienta adecuada para el trabajo requiere un conocimiento profundo de todos los detalles del proyecto en cuestión. Ciertamente, en este momento, Objective-C sigue siendo la opción "segura" para el desarrollo de iOS, pero Swift es definitivamente digno de consideración.

Sin embargo, el cambio más significativo que trae Swift al desarrollo de iOS es que muchos desarrolladores, por primera vez, se preguntarán: "¿Qué idioma debo usar?" Dada la historia de Apple, Objective-C y la plataforma iOS, este cambio por sí solo es bastante emocionante, especialmente considerando que la elección no es binaria. Si bien Apple ha dejado en claro su preferencia, la comunidad de desarrolladores de iOS en general ha trabajado arduamente durante años y ya ha brindado aún más respuestas posibles a esta pregunta.