Home » Análisis » Swift ya es código abierto. Análisis
Swift.org

Swift ya es código abierto. Análisis

3 de diciembre de 2015, otro día que será recordado en la historia de Swift. El día en que Apple lanzó al mundo el lenguaje Swift como proyecto de código abierto. A través de la web swift.org, podemos acceder a toda la información necesaria como documentación, un nuevo blog, descarga del proyecto en plataforma Apple y para Ubuntu Linux (como binarios preconstruidos), guía de iniciación, acceso al código fuente (que a su vez está alojado en Github), comunidad y guías de contribución al proyecto.

Swift Open Source

Situación actual

Swift 2 tiene más de un año de vida y es todo un éxito sin precedentes en el mundo de la programación. Apple ha hecho lo que mejor sabe hacer: coger lo mejor que otros han hecho antes de él, unirlo, quitar lo no necesario y pulirlo hasta el extremo. Al final tenemos un lenguaje sintácticamente similar a C en algunos aspectos, pero que también tiene muchos puntos en común con otros como Haskell, Python o incluso el omnipresente Javascript. El resultado es que Swift es el lenguaje de mayor crecimiento en la historia, según el ranking RedMonk Programming Language de junio de 2015.

Y ahora, con este lanzamiento, Swift pone en circulación la versión beta de Swift 2.2 que verá la luz en primavera de 2016, como paso previo a Swift 3.0 que está planificado para otoño de 2016.

La gran característica que mejor define Swift es que es un lenguaje que extrae lo mejor de los lenguajes modernos, que está construido sobre sí mismo, es muy sencillo de “personalizar” a nuestro gusto y que ha conseguido situarse en muy poco tiempo entre los 20 lenguajes de programación de mayor repercusión y recursos en la red, en páginas claves del mundo de desarrollo como github, bitbucket o stackoverflow. Al ser Swift un lenguaje compilado, no interpretado, su compilación es uno de sus puntos fuertes, que le da la potencia en su funcionamiento.

Con este paso, Apple abre las puertas, y así lo dice textualmente, para construir el mejor lenguaje de programación de propósito general de todos. Y eso además cuenta con la idea de la multiplataforma detrás. Porque, en contra de otros lenguajes como Java, el objetivo de Apple no es hacer una máquina virtual software que ejecute un código intermedio para dar soporte en cualquier plataforma: lo que Apple persigue es crear un compilador específico para cada uno de los sistemas y variaciones, para que en todos ellos un código en Swift genere un binario pegado al hardware que garantice un funcionamiento igual, sea cual sea el hardware, y un rendimiento que aproveche ese sistema o plataforma al completo. Un objetivo muy ambicioso pero no inalcanzable.

En qué consiste el proyecto

Actualmente el proyecto de Swift tiene varias partes diferenciadas: podemos descargar unos binarios precompilados que podemos instalar en distribuciones Ubuntu de Linux (versiones 15.10 y 14.04) o en OS X 10.11, para usar junto a la actual versión beta de Xcode 7.2 (aunque actualmente no soporta los Playgrounds). Apple advierte igualmente que esta versión de Swift no sirve para enviar apps a la App Store, teniendo que hacerlo con la versión que viene oficialmente con Xcode. Las plataformas soportadas para realizar desarrollos (como target) en Apple son: OS X 10.9, iOS 7.0, watchOS 2.0 y tvOS 9.0 (de esas versiones en adelante).

El proyecto en sí tiene cuatro partes importantes, aunque tiene varios repositorios de código para ello:

  • El compilador y la librería estándar de Swift, que da soporte a todo el lenguaje. Además incluye componentes como SourceKit (para integración de herramientas IDE) y documentación de nivel de implementación.
  • El gestor de paquetes del lenguaje, que permite gestionar y distribuir el código de Swift, permitiendo automatizar los procesos de descarga, compilación y enlace de dependencias.
  • Las librerías del núcleo de Swift, que incluyen la fundación, la librería de Grand Central Dispatch y la de Unit Testing. Todas dan funcionalidad de alto nivel para tareas claves a realizar como:
    — Tipos de datos estándar necesarios para el desarrollo: datos, URLs, sets de caracteres o colecciones especializadas.
    — Unidad de testing o primitivas de trabajo en red.
    — Programación y ejecución de tareas, como gestión de hilos, notificaciones o colas de proceso.
    — Persistencia, incluyendo listas de propiedades, archivos o parsing de JSON y XML.
    — Soporte de fechas, hora y cálculo de calendario.
    — Abstracción de comportamiento específicos del sistema operativo o interacción con el sistema de archivos.
    — Internacionalización, incluyendo formateo de fechas o recursos específicos por lenguaje, así como preferencias de usuario.
  • El entorno REPL y el depurador, la última parte, obviamente, es LLDB (el depurador y entorno REPL del lenguaje). La unión de ambos permite un REPL mucho más enriquecido a la hora de trabajar y gestionar nuestro código y sus resultados.

Swift Open Source

Contribución al proyecto

La contribución puede hacerse en múltiples niveles:

  • Contestar preguntas en las listas de correo para dar soporte en el lenguaje a nuevos desarrolladores y gente que necesite ayuda o colaborar activamente en las dudas o problemas de las diferentes partes de Swift en que esté trabajando cada equipo.
  • Reportar o probar posibles bugs que pudiera haber en el proyecto (para ello se ha creado un entorno a tal efecto en este sitio, donde Apple está usando las librerías abiertas JIRA de Atlassian, responsables de la web Bitbucket.org y dónde puede usarse incluso el lenguaje español. Un sistema de tracking muy avanzado y potente. También podemos gestionar bugs para reproducirlos, reducirlos o eliminar duplicados, participando activamente en su gestión.
  • Contribuir con nuestro código, en un modelo de cambios pequeños incrementales. Apple prefiere enfocarse en pequeñas partes concretas que vayan aportándose o incorporándose, más que en trozos amplios de código que son más complicados de revisar e integrar con el resto del proyecto. Todo el código que aportemos, ha de estar perfectamente probado y será revisado con detalle antes de poder ser aprobado e incorporado al proyecto, siguiendo una serie de directrices comunes que permitan gestionar el trabajo con más eficiencia. Obviamente el código ha de estar testeado y libre de errores por nuestra parte.
  • Evolución de Swift, una iniciativa muy interesante donde cualquiera puede aportar ideas que ayuden a definir la ruta del lenguaje, su evolución y futuro. Aportar ideas sobre futuras funciones, características o funcionalidades que, una vez revisadas y vistas como interesantes y plausibles, pueden ser aprobadas e incluidas en el road map del proyecto, todo a partir del repositorio de evolución de Swift que podemos encontrar aquí.
  • El compilador LLVM, es parte imprescindible de Swift. Pero Apple tiene su propio clon de la infraestructura abierta de compilación LLVM, por lo que tiene que trabajar en evolucionar este clon propio a la vez que evoluciona el proyecto primario. También podemos participar en estos temas, a través de los tres proyectos creados para LLVM, CLang y LLDB en Swift.

El futuro de Swift

Swift Cerradura

Hay mucho trabajo por delante hasta alcanzar la actual meta, puesta en Swift 3.0 para otoño de 2016. La primera de ellas es un ABI más estable, la infraestructura que actualmente da soporte al bitcode que ahora mismo generan las apps en lugar del binario final. La idea es estabilizar el proceso de ABI para que cualquier aplicación o binario compilado con futuras versiones de Swift, pueda entenderse e interactuar a nivel binario con cualquier aplicación o librería en Swift 3.0, aunque haya habido cambios importantes en el propio código del lenguaje. Esto significaría la ansiada meta de poder evolucionar el lenguaje con la garantía de una retrocompatibilidad con una versión base.

Otra meta es la resilencia, ¿pero qué es eso? Pues bien, es la facultad por la que el cambio en un módulo o fichero fuente de la app, no suponga la recompilación completa de todo el proyecto. Actualmente, un cambio en una librería o un cambio en un código, requiere la recompilación de todo el conjunto del proyecto para preservar su consistencia. Pero la idea es tener una infraestructura lo suficiente sólida como para, simplemente, sustituir el compilado de la nueva librería y que el resto siga funcionando sin problema. Cambiar solo el trozo que ha cambiado y no generarlo todo desde 0, como hasta ahora.

La portabilidad a otros sistemas, más allá de los actuales, es otra de las metas. Llegar al máximo de plataformas posibles, no solo Windows o Linux, sino cualquier tipo de aparato o dispositivo. Tener la garantía que un código en Swift se compilará y funcionará en cualquier dispositivo.

Y por último, en otros objetivos, se quiere crear un guía de diseño estándar de librerías, para que cualquiera que quiera crear la suya en Swift, tenga unos parámetros ya definidos que permiten su desarrollo e implementación sin problema alguno, de forma que cualquier usuario pueda usar estas librerías sabiendo que responde a una estructura concreta.

Conclusiones

El paso que hoy ha dado Swift es muy importante, un primer paso, como lenguaje de programación de uso general que permita realizar programas para cualquier tipo de propósito, y construir nuevas librerías capaces de manejar todo lo que queramos.

¿Horizonte? Ahora un sistema Ubuntu Linux puede tener y trabajar con Swift, lo que abre la puerta a que otros sistemas basados en el mismo núcleo, como los que permiten que funcione una Raspberry Pi, podrían utilizar Swift para hacer programas. Y quien dice Linux dice Windows o incluso Android, pudiendo integrarse como un lenguaje más en multitud de ecosistemas, como Visual Studio de Microsoft (quienes ya expresaron su voluntad en el pasado de incluir Swift en su entorno).

Las posibilidades son infinitas y esto acaba de empezar. Swift es ahora, más que nunca, un lenguaje de futuro y esto no ha hecho más que empezar. Un consejo: mirad al comienzo del post, a vuestra derecha, porque si estáis interesados en Swift, tenemos algunos contenidos que os pueden interesar como nuestro libro “Aprendiendo Swift 2” o el curso online. Preparaos, porque iremos analizando cada parte del proyecto una a una con más detalle. Hasta entonces Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Diseñando para el iPhone X

iPhone X (léase 10). El nuevo y más deseado dispositivo de Apple, no carente de …