Swift vs Objective-C: 10 razones por las que el futuro favorece a Swift

Los lenguajes de programación no mueren fácilmente, pero los talleres de desarrollo que se aferran a paradigmas que se desvanecen sí lo hacen. Si está desarrollando aplicaciones para dispositivos móviles y no ha investigado Swift, tome nota: Swift no solo suplantará a Objective-C cuando se trata de desarrollar aplicaciones para Mac, iPhone, iPad, Apple Watch y los dispositivos futuros, pero también reemplazará a C para la programación integrada en plataformas Apple.

Gracias a varias características clave, Swift tiene el potencial de convertirse en el lenguaje de programación de facto para crear aplicaciones inmersivas, receptivas y orientadas al consumidor en los próximos años.

Apple parece tener grandes objetivos para Swift. Ha optimizado el compilador para el rendimiento y el lenguaje para el desarrollo, y alude a que Swift está "diseñado para escalar desde 'hola, mundo' a un sistema operativo completo" en la documentación de Swift. Si bien Apple aún no ha declarado todos sus objetivos para el lenguaje, los lanzamientos de Xcode 6, Playgrounds y Swift juntos señalan la intención de Apple de hacer que el desarrollo de aplicaciones sea más fácil y accesible que con cualquier otra cadena de herramientas de desarrollo.

Aquí hay 10 razones para adelantarse al juego comenzando a trabajar con Swift ahora.

1. Swift es más fácil de leer

Objective-C sufre todas las verrugas que cabría esperar de un lenguaje basado en C. Para diferenciar las palabras clave y los tipos de los tipos C, Objective-C introdujo nuevas palabras clave usando el símbolo @. Debido a que Swift no se basa en C, puede unificar todas las palabras clave y eliminar los numerosos símbolos @ delante de cada tipo de Objective-C o palabra clave relacionada con el objeto.

Convenciones heredadas de Swift drops. Por lo tanto, ya no necesita punto y coma para terminar las líneas o paréntesis para rodear las expresiones condicionales dentro de las declaraciones if / else. Otro gran cambio es que las llamadas de método no anidan dentro de sí resultando en el soporte infernal adiós, [[[ ]]]. Las llamadas a métodos y funciones en Swift utilizan la lista de parámetros separados por comas estándar de la industria entre paréntesis. El resultado es un lenguaje más limpio y expresivo con una sintaxis y gramática simplificadas.

El código Swift se parece más al inglés natural, además de a otros lenguajes de programación populares modernos. Esta legibilidad facilita a los programadores existentes de JavaScript, Java, Python, C # y C ++ adoptar Swift en su cadena de herramientas, a diferencia del patito feo que era Objective-C.

2. Swift es más fácil de mantener

El legado es lo que retiene a Objective-C: el lenguaje no puede evolucionar sin que C evolucione. C requiere que los programadores mantengan dos archivos de código para mejorar el tiempo de compilación y la eficiencia de la creación de la aplicación ejecutable, un requisito que se traslada a Objective-C.

Swift elimina el requisito de dos archivos. Xcode y el compilador LLVM pueden descubrir dependencias y realizar compilaciones incrementales automáticamente en Swift 1.2. Como resultado, la tarea repetitiva de separar la tabla de contenido (archivo de encabezado) del cuerpo (archivo de implementación) es cosa del pasado. Swift combina el encabezado Objective-C (.h) y los archivos de implementación (.m) en un solo archivo de código (.swift).

El sistema de dos archivos de Objective-C impone trabajo adicional a los programadores, y es un trabajo el que distrae a los programadores del panorama general. En Objective-C, debe sincronizar manualmente los nombres de los métodos y los comentarios entre los archivos, con suerte usando una convención estándar, pero esto no está garantizado a menos que el equipo tenga reglas y revisiones de código implementadas.

Xcode y el compilador LLVM pueden trabajar entre bastidores para reducir la carga de trabajo del programador. Con Swift, los programadores hacen menos contabilidad y pueden dedicar más tiempo a crear la lógica de la aplicación. Swift elimina el trabajo estándar y mejora la calidad del código, los comentarios y las funciones compatibles.

3. Swift es más seguro

Un aspecto interesante de Objective-C es la forma en que se manejan los punteros, en particular los punteros nulos (nulos). En Objective-C, no sucede nada si intenta llamar a un método con una variable de puntero que es nula (no inicializada). La expresión o línea de código se convierte en una no operación (no operativa) y, si bien puede parecer beneficioso que no se bloquee, ha sido una gran fuente de errores. Una no operación conduce a un comportamiento impredecible, que es el enemigo de los programadores que intentan encontrar y corregir un bloqueo aleatorio o detener un comportamiento errático.

Los tipos opcionales hacen que la posibilidad de un valor opcional nulo sea muy clara en el código Swift, lo que significa que puede generar un error de compilación al escribir código incorrecto. Esto crea un circuito de retroalimentación corto y permite a los programadores codificar con intención. Los problemas se pueden solucionar a medida que se escribe el código, lo que reduce en gran medida la cantidad de tiempo y dinero que gastará en corregir errores relacionados con la lógica del puntero de Objective-C.

Tradicionalmente, en Objective-C, si se devolvía un valor de un método, era responsabilidad del programador documentar el comportamiento de la variable de puntero devuelta (utilizando comentarios y convenciones de nomenclatura de métodos). En Swift, los tipos opcionales y los tipos de valor dejan explícitamente claro en la definición del método si el valor existe o si tiene el potencial de ser opcional (es decir, el valor puede existir o puede ser nulo).

Para proporcionar un comportamiento predecible, Swift desencadena un bloqueo en tiempo de ejecución si se utiliza una variable opcional nula. Este bloqueo proporciona un comportamiento constante, lo que facilita el proceso de corrección de errores porque obliga al programador a solucionar el problema de inmediato. El bloqueo del tiempo de ejecución de Swift se detendrá en la línea de código donde se ha utilizado una variable opcional nula. Esto significa que el error se solucionará antes o se evitará por completo en el código Swift.

4. Swift está unificado con la gestión de memoria.

Swift unifica el lenguaje de una manera que Objective-C nunca lo ha hecho. El soporte para el conteo automático de referencias (ARC) es completo en todas las rutas de código de procedimiento y orientadas a objetos. En Objective-C, ARC es compatible con las API de Cocoa y el código orientado a objetos; sin embargo, no está disponible para código C procedimental y API como Core Graphics. Esto significa que se convierte en responsabilidad del programador manejar la administración de la memoria cuando se trabaja con las API de gráficos centrales y otras API de bajo nivel disponibles en iOS. Las enormes pérdidas de memoria que puede tener un programador en Objective-C son imposibles en Swift.

Un programador no debería tener que pensar en la memoria para cada objeto digital que crea. Debido a que ARC maneja toda la administración de la memoria en tiempo de compilación, la capacidad intelectual que se habría destinado a la administración de la memoria puede, en cambio, centrarse en la lógica central de la aplicación y las nuevas funciones. Debido a que ARC en Swift funciona en código procedimental y orientado a objetos, no requiere más cambios de contexto mental para los programadores, incluso cuando escriben código que toca API de nivel inferior, un problema con la versión actual de Objective-C.

La gestión de memoria automática y de alto rendimiento es un problema que se ha resuelto y Apple ha demostrado que puede aumentar la productividad. El otro efecto secundario es que tanto Objective-C como Swift no sufren de un recolector de basura que se ejecuta limpiando la memoria no utilizada, como Java, Go o C #. Este es un factor importante para cualquier lenguaje de programación que se utilizará para gráficos receptivos y entradas de usuario, especialmente en un dispositivo táctil como el iPhone, Apple Watch o iPad (donde el retraso es frustrante y hace que los usuarios perciban que una aplicación no funciona).

5. Swift requiere menos código

Swift reduce la cantidad de código que se requiere para declaraciones repetitivas y manipulación de cadenas. En Objective-C, trabajar con cadenas de texto es muy detallado y requiere muchos pasos para combinar dos piezas de información. Swift adopta características del lenguaje de programación moderno como agregar dos cadenas junto con un operador "+", que falta en Objective-C. El soporte para combinar caracteres y cadenas de este tipo es fundamental para cualquier lenguaje de programación que muestre texto a un usuario en una pantalla.

El sistema de tipos en Swift reduce la complejidad de las declaraciones de código, ya que el compilador puede averiguar los tipos. A modo de ejemplo, Objective-C exige a los programadores de memorizar fichas especiales de cuerda ( %s, %d, %@) y proporcionar una lista separada por comas de variables para reemplazar cada ficha. Swift admite la interpolación de cadenas, lo que elimina la necesidad de memorizar tokens y permite a los programadores insertar variables directamente en línea en una cadena orientada al usuario, como una etiqueta o un título de botón. El sistema de inferencia de tipos y la interpolación de cadenas mitigan una fuente común de fallas que son comunes en Objective-C.

Con Objective-C, estropear el pedido o usar el token de cadena incorrecto hace que la aplicación se bloquee. Aquí, Swift nuevamente lo libera del trabajo de contabilidad, traduciéndose en menos código para escribir (código que ahora es menos propenso a errores) debido a su soporte en línea para manipular cadenas de texto y datos.

6. Swift es más rápido

Dejar caer las convenciones de C heredadas ha mejorado enormemente a Swift bajo el capó. Los puntos de referencia para el rendimiento del código Swift continúan apuntando a la dedicación de Apple para mejorar la velocidad a la que Swift puede ejecutar la lógica de la aplicación.

Según Primate Labs, creadores de la popular herramienta de rendimiento GeekBench, Swift se estaba acercando a las características de rendimiento de C ++ para tareas vinculadas a la computación en diciembre de 2014 utilizando el algoritmo de Mandelbrot.

En febrero de 2015, Primate Labs descubrió que Xcode 6.3 Beta mejoró el rendimiento de Swift del algoritmo GEMM, un algoritmo vinculado a la memoria con acceso secuencial de arreglos grandes, en un factor de 1.4. La implementación inicial de FFT, un algoritmo ligado a la memoria con acceso aleatorio de arreglos grandes, tuvo una mejora de rendimiento de 2.6 veces.

Se observaron mejoras adicionales en Swift al aplicar las mejores prácticas, lo que resultó en un aumento de 8.5 veces para el rendimiento del algoritmo FFT (dejando a C ++ con solo una ganancia de rendimiento de 1.1 veces). Las mejoras también permitieron a Swift superar a C ++ para el algoritmo de Mandelbrot por un factor de tan solo 1,03.

Swift está casi a la par con C ++ tanto para los algoritmos FFT como para Mandelbrot. Según Primate Labs, el rendimiento del algoritmo GEMM sugiere que el compilador Swift no puede vectorizar el código que el compilador C ++ puede, una ganancia de rendimiento fácil que podría lograrse en la próxima versión de Swift.

7. Menos conflictos de nombres con proyectos de código abierto

Un problema que ha afectado al código de Objective-C es su falta de soporte formal para espacios de nombres, que era la solución de C ++ para las colisiones de nombres de archivos de código. Cuando ocurre esta colisión de nombres en Objective-C, es un error del vinculador y la aplicación no se puede ejecutar. Existen soluciones alternativas, pero tienen posibles dificultades. La convención común es usar prefijos de dos o tres letras para diferenciar el código Objective-C que está escrito, por ejemplo, por Facebook frente a su propio código.

Swift proporciona espacios de nombres implícitos que permiten que exista el mismo archivo de código en varios proyectos sin causar una falla de compilación y requiriendo nombres como NSString (Next Step - la compañía de Steve Jobs después de ser despedido de Apple) o CGPoint (Core Graphics). En última instancia, esta función en Swift mantiene a los programadores más productivos y significa que no tienen que llevar la contabilidad que existe en Objective-C. Puede ver la influencia de Swift con nombres simples como Array, Dictionary y String en lugar de NSArray, NSDictionary y NSString, que nacieron de la falta de espacios de nombres en Objective-C.

Con Swift, los espacios de nombres se basan en el destino al que pertenece un archivo de código. Esto significa que los programadores pueden diferenciar clases o valores utilizando el identificador de espacio de nombres. Este cambio en Swift es enorme. Facilita enormemente la incorporación de proyectos, marcos y bibliotecas de código abierto en su código. Los espacios de nombres permiten que diferentes empresas de software creen los mismos nombres de archivo de código sin preocuparse por las colisiones al integrar proyectos de código abierto. Ahora tanto Facebook como Apple pueden usar un archivo de código de objeto llamado FlyingCar.swift sin errores ni fallas de compilación.

8. Swift admite bibliotecas dinámicas

El cambio más grande en Swift que no ha recibido suficiente atención es el cambio de las bibliotecas estáticas, que se actualizan en las principales versiones (iOS 8, iOS 7, etc.), a bibliotecas dinámicas. Las bibliotecas dinámicas son fragmentos de código ejecutables que se pueden vincular a una aplicación. Esta función permite que las aplicaciones Swift actuales se vinculen con versiones más recientes del idioma Swift a medida que evoluciona con el tiempo.

El desarrollador envía la aplicación junto con las bibliotecas, las cuales están firmadas digitalmente con el certificado de desarrollo para garantizar la integridad (hola, NSA). Esto significa que Swift puede evolucionar más rápido que iOS, que es un requisito para un lenguaje de programación moderno. Los cambios en las bibliotecas se pueden incluir con la última actualización de una aplicación en la App Store, y todo simplemente funciona.

Las bibliotecas dinámicas nunca han sido compatibles con iOS hasta el lanzamiento de Swift y iOS 8, aunque las bibliotecas dinámicas han sido compatibles con Mac durante mucho tiempo. Las bibliotecas dinámicas son externas al ejecutable de la aplicación, pero están incluidas en el paquete de aplicaciones descargado de la App Store. Reduce el tamaño inicial de una aplicación a medida que se carga en la memoria, ya que el código externo está vinculado solo cuando se usa.

La capacidad de diferir la carga en una aplicación móvil o una aplicación incorporada en Apple Watch mejorará el rendimiento percibido por el usuario. Esta es una de las distinciones que hacen que el ecosistema iOS se sienta más receptivo. Apple se ha centrado en cargar solo activos, recursos y ahora código compilado y vinculado sobre la marcha. La carga sobre la marcha reduce los tiempos de espera iniciales hasta que realmente se necesita un recurso para mostrarlo en la pantalla.