Tanmay Bakshi habla de programación con Julia y Swift

Dos prometedores lenguajes de aprendizaje automático

Bakshi es partidario de dos lenguajes para el aprendizaje automático:

• Julia, un lenguaje de programación compilado justo a tiempo de alto nivel, adaptado a la computación científica y numérica.
• Swift, un lenguaje de programación compilado anticipado, de propósito general, desarrollado y utilizado con mayor frecuencia para crear aplicaciones para las plataformas de Apple.

Julia es un lenguaje popular para el aprendizaje automático gracias a su simplicidad. Los desarrolladores pueden lograr más en Julia con menos líneas de código, dijo Bakshi, y escribir una aplicación completamente en ese lenguaje, sin necesidad de escribir componentes en C, por ejemplo.

«[El lenguaje Julia] aprovecha esta nueva tecnología de compilación para crear una experiencia de programación tan intuitiva o tan fácil como la de Python, pero, al mismo tiempo, es de tan alto rendimiento como lenguaje como C», dijo Bakshi. «Así que tu código puede ser compilado sobre la marcha».

Aunque el lenguaje de programación Swift ofrece potencial para el aprendizaje automático, dijo Bakshi, su uso principal es para el desarrollo de aplicaciones móviles para iOS. Apple creó el lenguaje de programación para el desarrollo de aplicaciones móviles nativas. Entre su simplicidad y su fácil integración con las plataformas de Apple, Swift ha calado rápidamente entre los programadores nuevos y los experimentados.

«A los desarrolladores les encanta programar en Swift, y es una forma estupenda de que los niños se inicien, porque la sintaxis es, en general, muy sencilla», afirma Bakshi. « [La integración nativa] en una plataforma realmente distingue a las aplicaciones».

Calidad en las aplicaciones de aprendizaje automático

Con cualquier lenguaje para el aprendizaje automático, la pregunta sigue siendo: ¿Cómo pueden las organizaciones garantizar la calidad de los datos del aprendizaje automático? Las aplicaciones de aprendizaje automático presentan problemas de interpretabilidad y sesgo que son difíciles de depurar. Aunque hay que trabajar en esta área, dijo Bakshi, un humano debe estar a cargo de la validación si hay mucho en juego.

«Si se trata de algo tan importante como el diagnóstico del cáncer, es obvio que habrá un ser humano en el bucle que examine el modelo y sus predicciones», dijo. «Ese ser humano en el bucle es el que verifica [la predicción] para asegurarse de que no hay casos límite que la red esté pasando por alto, o que la red esté cometiendo un error. Pero, al mismo tiempo, la red existe para que ese humano no tenga que hacerlo todo desde el principio, para que solo tenga que hacer la verificación».

Bakshi es optimista en cuanto a que tanto los profesionales de la informática como el público en general empezarán a entender la IA a un nivel más profundo en un futuro próximo, lo que ayudará a depurar los problemas de calidad cuando aparezcan.

«Vamos a empezar a ver que la gente entiende la razón de algunos de estos problemas, cosas como el problema del sesgo», dijo. Con lo que Bakshi denominó «expectativas menos infladas» de la IA, la gente podrá entender el razonamiento de algunos de sus problemas y resolverlos.

Dentro del mundo de Bakshi

En la entrevista, Bakshi utilizó uno de sus proyectos en IBM para explicar cómo deben abordar los innovadores los avances científicos. En los proyectos de software sencillos, los desarrolladores pueden basarse en su propia experiencia y conocimientos, así como en los de sus compañeros y la comunidad de desarrollo en general, para lanzar un producto en unas pocas iteraciones. Sin embargo, el avance científico requiere más creatividad, por no hablar de un montón de pruebas y errores. Por ello, los programadores e innovadores deben ver el fracaso como un paso clave en el proceso.

Tanmay Bakshi

«He estado trabajando en un nuevo proyecto en el campo de la garantía de calidad, donde lo que estoy trabajando es científicamente innovador», dijo Bakshi. «Lo que estoy trabajando en términos de tecnología de compiladores o de aprendizaje automático no existe todavía. Por lo tanto, hay mucha prueba y error con algunos de los componentes iniciales, como, por ejemplo, [con] esta instrumentación personalizada que estamos construyendo. Esto requiere muchas, muchas etapas de empezar desde cero, intentándolo de nuevo».

Desgraciadamente, dice, a los jóvenes programadores se les suele enseñar fundamentalmente de forma equivocada. A pesar de las ventajas únicas que hay que descubrir en cada lenguaje de programación, dice que los programadores deben aprender primero a resolver problemas, no a memorizar funciones y expresiones sin contexto. Bakshi puso en práctica estas lecciones en dos de sus libros, Tanmay Teaches Julia for Beginners: A Springboard to Machine Learning for All Ages y Hello Swift!: iOS app programming for kids and other beginners.

«Aprender con el ejemplo, aprender resolviendo problemas que te parezcan interesantes, eso es lo que realmente va a ayudar, porque entonces se te ocurren los problemas, se te ocurre la lógica para resolverlos, y luego sigues adelante e implementas el código para eso», dijo.

Bakshi también habló en la entrevista de lo que ve en el futuro para el aprendizaje automático y la IA, y de lo que él personalmente espera conseguir en las próximas décadas.

Nota del editor: Bakshi habló con el editor de SearchSoftwareQuality, David Carty, y con el editor asistente del sitio, Ryan Black. La transcripción ha sido ligeramente editada para mayor claridad y brevedad.

David Carty: Tanmay, has aprendido mucho como joven desarrollador aspirante. Estoy seguro de que has creado algunas aplicaciones desde muy joven. Para los niños de hoy en día que están experimentando con la programación, ¿qué tipo de resguardos recomendarías que pusieran? Los jóvenes programadores pueden cometer errores –también los profesionales, por cierto–, pero ¿cómo deberían sus padres o instructores, o cómo deberían ellos mismos, evitar cometer un error costoso?

Tanmay Bakshi: Creo que es importante generalizar y especificar lo que queremos decir con ‹error›. Lo que empezaré diciendo es que, actualmente, creo que muchas de las formas en que se enseña a los jóvenes a codificar son erróneas. Fundamentalmente no se les enseña de la manera correcta. Y la razón por la que digo esto es porque, mira, si echas un vistazo a lo que es la programación, creo que la programación no consiste en escribir código. No se trata de tomar un lenguaje y escribir código en ese lenguaje. Se trata más bien de cómo tomar un problema, y cómo deconstruirlo en sus piezas individuales y utilizar los bloques de construcción que los lenguajes de programación te proporcionan para resolver ese problema. Luego, pasar de esa lógica y ese flujo a escribir el código es sencillo. Esa es la parte fácil, ¿verdad? Creo que actualmente, la forma en que se enseña a los jóvenes a codificar está muy, muy centrada en el código. Está muy centrada en la programación, y no en la lógica. El objetivo es: ‹Oye, mira, puedes escribir este código, y puedes hacer que la computadora haga algo›, no: ‹Oye, hay esta lógica que puedes escribir para resolver este problema, y la computadora es la que resuelve este problema si escribes el código para ello›. Así que creo que eso es una cosa. A veces puede ser difícil enseñar de esa manera.

Además, como has mencionado, todo el mundo comete errores, no solo los principiantes, los profesionales también los cometen. En lo que respecta a la programación y la tecnología en concreto, aunque esto se aplica a todos los campos, no se puede esperar que las cosas funcionen a la primera, ¿verdad? Sé a ciencia cierta que siempre que algo complejo me ha funcionado a la primera, suele ser porque no se ha probado lo suficiente. Así que, en realidad, creo que se reduce a unas cuantas cosas clave. En primer lugar, hay que asegurarse de que no se sigue un plan de estudios preestablecido o un curso o algo por el estilo: un curso es muy, muy importante como pauta a seguir. Pero, aprender con el ejemplo, aprender resolviendo problemas que te parezcan interesantes, eso es lo que realmente va a ayudar, porque entonces se te ocurren los problemas, se te ocurre la lógica para resolverlos, y luego sigues adelante e implementas el código para ello. Ser capaz de practicar ese pensamiento computacional es absolutamente clave. A partir de ahí, la perseverancia y la persistencia son también muy, muy importantes porque, de nuevo, cuando se trata de tecnología, las cosas no funcionan a la primera. Se necesitan muchos intentos, y es realmente una especie de evolución, y recordar que cada vez que resuelves un problema estás aprendiendo, y que no te enfrentarás a problemas como ese de nuevo.

Así que eso es algo que intento hacer también con mis libros. Me gusta compartir mis conocimientos con todo tipo de medios, y los libros son uno de ellos. No solo quiero escribir libros que tengan, ya sabes: ‹Bien, aquí hay un lenguaje de programación. Así es como se usan todos los componentes individuales›, como muchos otros libros. Sino que, en cada uno de los capítulos, se explica cómo podemos construir aplicaciones de ejemplo reales que aprovechen todos los diferentes bloques de construcción de los que hemos hablado hasta ahora para construir aplicaciones cada vez más complejas. Y, al hacerlo, cómo podemos, en primer lugar, dar un paso atrás del código, mirar el problema, resolver el problema y luego escribir el código; incluso para temas complejos, como el aprendizaje automático. Así, por ejemplo, mi último libro sobre Julia, Tanmay Teaches Julia. Ese libro lo he escrito con McGraw Hill, es el primero de una serie llamada Tanmay Teaches. Este libro es para todo tipo de principiantes que quieran aprender el lenguaje Julia. Empezamos desde cero [como si] nunca hubieras programado antes. Y, al final, te introduzco en la tecnología de aprendizaje automático a través de ejemplos sencillos, incluso entrando en el sueño profundo de Google. Todo eso ocurre a lo largo de los libros con ejemplos, enseñándote ese pensamiento computacional. Creo que esa es la forma más eficaz de aprender a programar: centrarse en la lógica, centrarse en el pensamiento computacional y la resolución de problemas. La escritura de código viene en segundo lugar.

Ryan Black: Mencionaste, por supuesto, la forma en que la gente realmente aprende los lenguajes de programación, como que no van a hacer las cosas bien la primera vez. Pero, por supuesto, creo que lo que muchas empresas de TI tratan de hacer es intentar reducir el número de errores a la primera, porque [quieren] sacar un producto rápidamente al mercado. Entonces, ¿cómo equilibrarías esa realidad? Lo que estás diciendo es que estás describiendo un enfoque que realmente suena más conducente a la forma en que la gente realmente aprende a programar.

Bakshi: Depende de cómo se mire, ¿verdad? Si la pregunta es: ‹¿Cómo deberían los jóvenes aprender a programar sin tener que pensar todavía en una mentalidad empresarial?›. Entonces, sí, esa es la forma en que creo que los jóvenes deberían aprender a codificar. Deberían aprender con el ejemplo, deberían aprender con la lógica y menos con la escritura de código. Pero, entonces, si tuviéramos que cambiar a las empresas y la forma en que construimos y liberamos productos de producción, entonces las cosas cambian un poco.

Como he mencionado, las cosas no suelen funcionar a la primera. Además, hay que distinguir entre el avance científico en la innovación y el lanzamiento de productos. Así, por ejemplo, en IBM, permítanme darles un ejemplo real de primera mano: He estado trabajando en un nuevo proyecto en el campo de la garantía de calidad, donde lo que estoy trabajando es científicamente innovador. Lo que estoy trabajando en términos de tecnología de compilación o tecnología de aprendizaje automático no existe todavía. Por lo tanto, hay un montón de pruebas y errores con algunos de los componentes iniciales, como, por ejemplo, [con] esta instrumentación personalizada que estamos construyendo. Esto requiere muchas, muchas etapas de empezar de cero, de intentarlo de nuevo. Sin embargo, cuando se trata de cosas más estándar, como, por ejemplo, IBM Watson Studio, que antes se llamaba Data Science Experience, IBM tardó seis [o] siete meses en conseguir un prototipo inicial, y luego otro par de meses en lanzarlo al público. No fue necesaria ninguna innovación [fundamental] en términos de avance de las barreras tecnológicas. Pero, en cambio, se trataba de: ‹Muy bien, ya sabes, todas estas pequeñas piezas funcionan. Ya están ahí, tenemos que juntarlas en un paquete fácil de usar›.

Así que, yo diría que depende. Creo que el alcance de la pregunta se ha extendido. Pero si se trata de que los jóvenes aprendan a codificar, entonces sí, se trata de esa lógica. Se trata de aprender que nada va a funcionar en el primer intento, pero vas a ganar más experiencia y esa experiencia te va a ayudar en el futuro. Cuando se trata de construir aplicaciones, por ejemplo, IBM Data Science Experience o Watson Studio, eso va a ser súper útil. En unas pocas iteraciones, vas a tener una tecnología compleja funcionando. Pero, luego, cuando se trata de la investigación o el avance científico, de nuevo, se vuelve a eso, a falta de una frase mejor, la prueba y el error. Hay que probar varias cosas diferentes para ver qué funciona y qué no.

Black: También quería preguntarte, digamos que no tengo ningún conocimiento previo de Julia, sobre el que por supuesto escribiste un libro, pero quiero construir una aplicación con Julia. ¿Qué aspecto del lenguaje de programación debería aprender primero?

Bakshi: Esta es la cuestión. Julia ha sido construido especialmente para la computación científica y el aprendizaje automático y la IA. Por lo tanto, se podría pensar que, si quiero desarrollar una aplicación en Julia, entonces tal vez debería empezar a programar en otro lugar primero, y luego venir a Julia, ya que está destinado a todos estos temas complejos, ¿verdad? Yo no aconsejaría necesariamente empezar en un lenguaje como C o C++, porque entonces, de nuevo, te estás centrando demasiado en los detalles del código y no lo suficiente en el pensamiento computacional, asumiendo que nunca has programado antes. Se podría pensar que Julia tendría una estructura similar, pero me alegra decir que no es así. Julia aprovecha la tecnología del compilador, que es algo que me apasiona; aprovecha esta nueva tecnología del compilador para crear una experiencia de programación que es tan intuitiva o tan fácil como la de Python, pero, al mismo tiempo, es de tan alto rendimiento como un lenguaje como C. Así que tu código puede ser compilado sobre la marcha. Puede hacer inferencia de tipos. Puede hacer todas estas cosas maravillosas, y puede hacerlo realmente rápido hasta el punto de que puedes escribir kernels CUDA en Julia; puedes escribir todo tipo de cosas y hacer que se ejecuten con un rendimiento similar al de C [o] C++. Así que el objetivo de Julia es ser un lenguaje tan fácil de usar y de aprender como Python, pero con un rendimiento lo suficientemente alto como para ser utilizado en todo tipo de aplicaciones, como el aprendizaje automático, y soportar extensiones de compiladores nativos, todo tipo de cosas.

Esencialmente, lo que estoy tratando de decir es que no necesitas empezar con otro lenguaje. Puedes empezar con el lenguaje Julia por el hecho de que es tan simple, por el hecho de que descarga gran parte del trabajo de ti al compilador. Julia es una gran manera de empezar. Te permite centrarte en el pensamiento computacional, pero al mismo tiempo entrar en las tecnologías de próxima generación.

Black: Me alegro de que hayas sacado el tema del aprendizaje automático porque quería preguntarte sobre cómo los programadores pueden hacer uso de las bibliotecas de aprendizaje automático con Julia. ¿Cuáles son algunos de los beneficios únicos para el desarrollo de aplicaciones de aprendizaje automático con Julia?

Bakshi: Claro. Mira, la tecnología de aprendizaje automático y Julia encajan perfectamente. Y la razón por la que digo esto es porque, de nuevo, el aprendizaje automático es lo suficientemente importante; eso es lo que muchas empresas diferentes creen. [Julia proporciona] soporte de compilador de primera clase. Así que, lo que eso significa es que la tecnología de aprendizaje automático es un conjunto de algoritmos lo suficientemente importante, un conjunto de tecnologías que tal vez deberíamos estar integrando esa capacidad directamente en los compiladores de lenguajes de programación para hacernos la vida más fácil. Muy, muy pocas tecnologías han visto este tipo de integración a propósito dentro de los lenguajes de programación, pero Julia es uno de los lenguajes que encaja con ese tipo de modelo.

Así que, por ejemplo, digamos que queremos trabajar en una de estas exóticas arquitecturas de aprendizaje automático, de aprendizaje profundo, llamadas redes neuronales recursivas de árbol. No son redes neuronales recurrentes, no entienden los datos en el tiempo, sino en la estructura, así que son redes neuronales recursivas. Así que, por ejemplo, digamos que tomas una frase y la divides en un árbol de análisis sintáctico utilizando el kit de herramientas de análisis sintáctico de Stanford [Natural Language Processing] NLP. Si se toma ese árbol, ¿cómo se puede aprovechar no solo las palabras de la frase y los tokens, sino también la estructura de la frase que extrae el kit de herramientas? Tradicionalmente, con TensorFlow, esto requeriría varios cientos de líneas de código porque entonces tienes que hacer este extraño truco para que el modelo entienda diferentes tipos de entradas en función de si tienes un nodo hoja o tienes un nodo con múltiples entradas diferentes y diferentes detalles; se vuelve realmente, realmente complejo manejar la diferenciación y el descenso de gradiente para una arquitectura tan exótica, porque esto no es habitual. Esto no es algo que se haga todos los días con TensorFlow, y es muy, muy específico para un caso de uso. Pero entonces, cuando pasas a Julia, de repente son cinco líneas de código, porque ahora el compilador es capaz de mirar todo tu código a la vez y decir: ‹Muy bien, aquí hay un gráfico para literalmente todo lo que estás haciendo simplemente haciendo la diferenciación automática fuente a fuente›. Así que usando esta nueva biblioteca llamada Zygote, puedes tomar literalmente cualquier función de Julia, puedes echar un vistazo al código LLVM para ella, y puedes generar una nueva función LLVM, que es la representación intermedia para Julia, que representa el gradiente de esa misma función.

Así que este tipo de extensiones del compilador nativo del lenguaje, por ejemplo, son solo una de las razones por las que Julia es perfecta para el aprendizaje automático. Hay muchas bibliotecas diferentes que hacen un gran uso de ella. Por ejemplo, la biblioteca Flux está construida en código 100 % Julia, y puede ejecutar exactamente lo que estoy diciendo: como cinco líneas de código para una red neuronal recursiva. Puede ejecutar todo este tipo de cosas; puede ejecutarse en la GPU; puede ejecutarse en todo tipo de aceleradores diferentes sin tener que utilizar ningún código C. Todo está escrito en Julia nativo, porque Julia tiene la capacidad de compilar a lo que sea que estos aceleradores necesitan. Así, el hecho de que solo usemos un lenguaje hace que la gente pueda contribuir a Flux. El hecho de que Flux esté escrito en Julia hace que se puedan definir arquitecturas exóticas en unas cinco líneas de código. Todo esto sumado hace que Julia sea el entorno perfecto para el aprendizaje automático, el desarrollo del aprendizaje profundo.

Black: Suena como si, en pocas palabras, lo que Julia hace para el desarrollo de aprendizaje automático es esencialmente solo hacerlo mucho más simple, reduce el número de líneas de código que los desarrolladores tienen que mirar o escribir. ¿Es eso correcto?

Bakshi: En esencia, sí, pero yo también añadiría algo más. En primer lugar, reduce la cantidad de líneas de código que un desarrollador tendría que escribir o mirar. Pero también reduce el número de lenguajes que hay que utilizar. Así que no necesitas escribir componentes en C o componentes en Fortran o lo que sea. Puedes simplemente escribir todo en Julia.

Carty: Tanmay, en las conversaciones que he tenido sobre la IA en los círculos de control de calidad, surgen cosas como el sesgo de la IA. Algunas personas ven el aprendizaje automático y las redes neuronales como una caja negra. Sé que a algunos profesionales del aprendizaje automático se les puede erizar la piel, pero esa es una de las percepciones que hay. Así que todavía hay mucha preocupación sobre cómo garantizar la calidad. En cuanto a los modelos de aprendizaje automático, ¿cómo crees que deberían enfocarlo las organizaciones?

Bakshi: Yo diría que la forma de aplicar la tecnología de aprendizaje automático y la forma de resolver problemas como este... Hemos tocado muchos problemas diferentes, ¿verdad? Así, la interpretabilidad, los problemas de la caja negra, ese es un grupo. Luego tocamos el problema del sesgo. Yo diría que todos estos problemas no tienen una solución individual clara. Depende muy específicamente de los tipos de arquitecturas, de los tipos de modelos que se utilicen, de dónde se utilicen, de por qué se utilicen. Depende de muchas cosas diferentes. Ahora, voy a decir, si quisiéramos generalizar un poco, hay algunas soluciones a estos problemas. Por ejemplo, para el sesgo, existe el kit de herramientas de código abierto AI Fairness 360 que se puede utilizar desde IBM Research y que permite utilizar algunas técnicas de vanguardia para identificar y sesgar los datos e incluso los modelos de aprendizaje automático, y tratar de amortiguar eso.

Si se piensa en la interpretabilidad, probablemente se podría utilizar algo como Watson OpenScale [de IBM]. Se pueden utilizar estos servicios para ver qué interpretan exactamente los modelos a partir de los datos. Por supuesto, estos servicios no funcionan con modelos de redes neuronales más complejos, pero sí con modelos de aprendizaje automático. Ahora, veamos un ejemplo sencillo. Digamos que estamos echando un vistazo a la traducción automática neural, y queremos ser capaces de averiguar por qué exactamente cambiamos de una palabra o una frase en inglés a otra frase en, digamos, francés o ruso. En ese caso concreto, si utilizamos un modelo de traducción automática neural secuencia a secuencia–-esto es algo antiguo, hoy en día tenemos modelos mejores, pero digamos que sí–, entonces podríamos utilizar la capa de atención de nuestra red neural para intentar averiguar cuáles son las relaciones entre las palabras de ambas frases. Y eso es algo que puedes mostrar a tu usuario y decir, ‹Hey, esto es lo que estamos traduciendo del inglés al francés. Si ves algo mal aquí, es porque el modelo no lo ha entendido. Algo tiene que ver con la traducción›. Así que eso sería lo que harías en esa circunstancia específica. Si estás haciendo reconocimiento visual, lo máximo que puedes hacer en ese caso es algo como los mapas de activación de clases de gradiente, Grad-CAM, donde realmente echas un vistazo a la imagen, y echas un vistazo a la clase y vas hacia atrás. Usted echa un vistazo a los gradientes con respecto a la entrada, y con base en eso, está tratando de determinar qué partes de la imagen que estamos diciendo la red neuronal que, ‹Hey, estas son las clases dentro de la imagen›. Así que realmente depende del caso de uso cuando se trata de la interpretabilidad.

En cuanto a la confianza en los modelos, yo diría que, de nuevo, se reduce al caso de uso. Si se trata de algo tan importante como el diagnóstico del cáncer, es obvio que va a haber un humano en el bucle que esté examinando el modelo, que esté examinando sus predicciones y que, potencialmente, incluso esté examinando algún razonamiento de alto nivel, por falta de una palabra mejor, así, por ejemplo, utilizando Grad-CAM, para ver por qué el modelo llegó a una decisión. Ese humano en el bucle es el que verifica eso, para asegurarse de que no hay casos extremos que la red está perdiendo o que la red está cometiendo un error. Pero, al mismo tiempo, la red existe para permitir que ese humano no tenga que hacerlo todo desde el principio, para que solo tenga que hacer la verificación, y para acelerar ese proceso, y en algunos casos aumentar la precisión tratando los casos mnemónicos mejor de lo que un humano puede. Eso es una cosa. Pero, si hablamos de algo tan simple o inofensivo como la predicción de palabras clave –por ejemplo, si estás escribiendo en tu teléfono y las predicciones de tipo rápido en la parte superior del teclado–, algo tan inofensivo como eso no necesita realmente tanta verificación o confianza. Algo como Smart Compose de Gmail no necesita tanta confianza. Así que yo diría que eso se reduce a la industria, a las regulaciones en torno a ella, [y] al impacto que va a tener en la vida de la gente. Así que, cuando se trata de confiar realmente en los modelos de aprendizaje automático, si es algo de lo que depende la vida de las personas, debería haber un humano en el bucle a partir de ahora. Por supuesto, hay algunas excepciones a esta regla; también lo sé. Por ejemplo, en el caso de los coches autónomos, la vida de las personas está en manos del aprendizaje automático, pero no hay humanos en el circuito. Así que ahí es donde tenemos que trazar la línea. ¿Hemos entrenado este modelo de aprendizaje automático con suficientes casos límite o suficientes datos para poder confiar en que, en la mayoría de las circunstancias, no cometerá un error? Un error es inevitable, pero ¿podemos confiar en que, en la mayoría de las circunstancias, al menos más que un humano, no cometerá un error? Así que, lo que yo diría es que realmente depende.

Carty: Para cambiar de marcha un poco. También escribiste un libro llamado Hello Swift: iOS app programming for kids and other beginners. El otro día vi un artículo en Business Insider que decía que más de 500.000 aplicaciones en la App Store de Apple están escritas, al menos parcialmente, en Swift. ¿Qué es lo que hace que este lenguaje sea tan interesante para los desarrolladores de aplicaciones móviles, y qué hace que sea fácil de aprender para los programadores jóvenes, lo que básicamente te dio la idea del libro?

Bakshi: Durante mucho tiempo, mis dos lenguajes favoritos han sido Swift y Julia. La razón por la que lo digo es porque son muy, muy útiles en sus respectivas áreas. Hoy en día, Swift ha empezado a ser más útil incluso fuera del desarrollo de aplicaciones móviles. Pero lo que realmente distingue a Swift es –lo que yo diría, y esto es muy subjetivo y en cierto modo es difícil describir exactamente lo que hace que Swift sea tan potente, aparte de su tecnología de compilación y sus optimizaciones y el hecho de que fue construido para el desarrollo móvil– incluso su arco de gestión de la memoria, utiliza el recuento automático de referencias en la recolección de basura, que es excelente para el móvil. Hay todo tipo de cosas que hace allí.

Pero también está, de nuevo, la elegancia del lenguaje, a falta de una palabra mejor, que lo distingue. Las características que el lenguaje tiene en términos de soporte complejo para genéricos, tipos de valor y referencia, COW (copy on write), todas estas cosas diferentes que el lenguaje soporta, pero aún así ser capaz de unirlas de la manera que Swift lo hace, es algo que no muchos lenguajes consiguen. Así que a los desarrolladores les encanta programar en Swift, y es una gran manera de que los niños se inicien porque la sintaxis es generalmente muy simple.

Te da una gran idea de lo que es programar en lenguajes compilados por adelantado, a diferencia de Julia, que es compilado justo a tiempo, por lo que puede ser más como Python. [Swift] tiene que ser más como C o Java. Al mismo tiempo, es simple, es fácil de usar. Puedes escribir código Swift que sea muy, muy fácil de leer, pero aún así rápido, [y] al mismo tiempo, si quisieras, podrías usar todo tipo de [APIs para C] y escribir código de muy, muy bajo nivel y gestionar manualmente la memoria. Puedes pasar de confiar totalmente en el compilador de Swift a apenas usarlo.

Así que la flexibilidad y la naturaleza dinámica del lenguaje y el hecho de que todo pueda coexistir es muy, muy bueno. Luego, por supuesto, está el hecho de que utiliza la infraestructura del compilador LLVM. Ahora, el hecho de que utilice LLVM, y el hecho de que, en el futuro, vayamos a utilizar MLIR –que es la representación intermedia multinivel, un nuevo proyecto en LLVM– significa que cosas como Google Swift para TensorFlow pueden realmente aprovechar eso para extraer los gráficos de TensorFlow directamente del código Swift. Lo que significa es que podemos escribir modelos de aprendizaje automático de manera muy, muy simple en código Swift también, al igual que Julia. Ahora, Julia todavía tiene algunas ventajas en términos de extensiones de compilación nativa y cosas por el estilo. Así, Swift para TensorFlow no resuelve el problema de muchos lenguajes, pero sí resuelve ese problema de cientos de líneas de código para una arquitectura exótica. Así que, el hecho de que sea tan sencillo de usar, el hecho de que puedas ir de cero a cien –en términos de control– mientras sigues permitiendo que todo ese código coexista, realmente hace que el lenguaje sea algo que a los desarrolladores les encanta usar.

Black: Tengo curiosidad por saber cómo se compara Swift, en particular, con el desarrollo de aplicaciones híbridas, ya que estamos hablando de la creación de aplicaciones para iOS y Android. ¿Cuáles son las ventajas específicas de Swift en comparación con el desarrollo de aplicaciones híbridas?

Bakshi: Creo que si tuviéramos que hablar de Swift específicamente, entonces ni siquiera se trata del lenguaje, ¿verdad? Es importante definir entre el lenguaje, el marco y la experiencia. Swift como lenguaje no es realmente un lenguaje de desarrollo de aplicaciones. Es un lenguaje de programación de propósito general de código abierto. Luego, si damos un paso atrás, también se puede utilizar Swift para el desarrollo de aplicaciones móviles en iOS. Apple proporciona el SDK para eso, Swift UIKit, Cocoa, Cocoa Touch. Todo esto es lo que Apple proporciona para ayudarte a desarrollar aplicaciones en Swift. Pero Swift en sí mismo es un lenguaje de programación de propósito general. Ahora, supongo que tu verdadera pregunta en ese caso sería, ¿cuál es la diferencia? O, ¿cuáles son las ventajas de usar los marcos de desarrollo nativos de Apple como Swift UI, o como Cocoa Touch, frente a usar algo que te permita desarrollar aplicaciones híbridas?

Personalmente, soy un gran fan del desarrollo de aplicaciones nativas para diferentes plataformas. La razón por la que digo esto es por la integración en una plataforma. La integración en una plataforma realmente distingue a las aplicaciones. Así que, si echas un vistazo a la razón por la que mucha gente compra productos de Apple en primer lugar, es porque trabajan juntos muy, muy bien. Si compras un iPhone, con el tiempo te verás presionado a comprar una Mac, y te verás presionado a cambiar de Google Drive a iCloud, y te verás presionado a cambiar de Spotify a Apple Music, y todas estas cosas, solo porque todo funciona increíblemente bien. No solo eso, incluso las aplicaciones de terceros se integran en el ecosistema de Apple muy, muy bien, porque se sienten como si ya fueran parte del teléfono. Si utilizas una aplicación que descargas de la App Store que está construida de forma nativa para iOS, estás utilizando todos esos componentes nativos de la interfaz de usuario de iOS, estás utilizando todo eso. Eso hace que se sienta como una parte más de la experiencia de Apple. La forma en que puedes ofrecer esa experiencia es utilizando los marcos que te da Apple. Si tratas de generalizar entre plataformas, por lo que si estás tratando de construir una aplicación para iOS y Android, de repente tienes que generalizar, ‹Hey, hay una UI TableView [en iOS] y una lista en Android. Vamos a llamar a esto una lista›. Se pierde parte de esa funcionalidad específica de la plataforma que hace que se sienta como una aplicación de Apple, o en Android haría que se sienta [menos] como una aplicación de Android. Así que la sensación de dolor es un cambio de contexto. Acabo de salir de un entorno de Apple y entrar en este nuevo entorno, ahora voy a volver a Apple. No quiero esos cambios de contexto. Quiero tener una experiencia nativa en todas las plataformas, por lo que el uso de estos SDKs específicos de la plataforma es a veces muy ventajoso.

Carty: Para terminar con una pregunta más orientada al futuro. Es probable que estés presente para ver el futuro de la IA, el aprendizaje automático, la ciencia de los datos y el desarrollo de aplicaciones. Incluso podrías participar en la creación de ese futuro. Así que, ¿cuáles son las posibilidades de estas tecnologías en el futuro y qué esperas conseguir personalmente en estos campos?

Bakshi: En primer lugar, diría que cuando se trata de una tecnología como la IA o el aprendizaje automático, es realmente muy difícil predecir cómo será el futuro. Creo que eso se debe a que cada día las cosas cambian; hay un cambio de paradigma cuando no te lo esperas. Hace un par de años, nunca habríamos pensado que las redes neuronales serían tan buenas para generar datos. Pero, de repente, Ian Goodfellow una noche inventa la red generativa adversarial y las cosas cambian, y hay un crecimiento exponencial a partir de ahí. Las cosas cambian muy, muy rápidamente.

Pero lo que diré es que, en general, veo algunas cosas. En primer lugar, esto no es ni siquiera una cosa técnica. Creo que las expectativas de la gente con respecto a la inteligencia artificial van a empezar a calmarse un poco y a ser mucho más realistas. Ahora mismo, tenemos unas expectativas hiperinfladas sobre lo que va a hacer la IA y cómo va a funcionar, y que va a ser tan inteligente como los humanos y todo ese tipo de cosas. A medida que veamos que cada vez más gente sigue haciendo estas predicciones, pero que luego no se cumplen o se siguen, empezaremos a perder la confianza en esas predicciones y empezaremos a tener una visión más realista de lo que significa la inteligencia artificial para la humanidad. Así que, eso es una cosa: el público en general tendrá una mejor percepción de la IA en el futuro próximo. No puedo decir cuándo empezará a cambiar la perspectiva de la gente, pero espero que en los próximos años lo haga, porque necesitamos tomar decisiones mejores y más informadas basadas en esas opiniones. Eso es una cosa.

La segunda cosa que yo diría es que empezaremos a ver cómo se resuelven muchos más de esos grandes retos que ya hemos mencionado, cosas como la interpretabilidad. ¿Cómo podemos explicar lo que hace una red neuronal? ¿Cómo podemos explicar lo que hace un modelo de aprendizaje automático en términos de decisiones? ¿Cómo podemos inyectar nuestro propio conocimiento en las redes neuronales? ¿Cómo podemos hacer que no dependan solo de los datos? ¿Cómo podemos hacer que funcionen a partir de datos o conocimientos que ya tenemos estructurados? IBM ya está trabajando en alguna tecnología. IBM Research tiene redes neuronales que pueden hacer razonamiento simbólico, aparte de los datos con los que se entrenan. Así que están trabajando en ese tipo de cosas. También diría que vamos a empezar a ver que la gente entiende la razón de algunos de estos problemas, cosas como el problema del sesgo. La gente tiene que entender que no se debe a que la inteligencia artificial diga: ‹Oye, no me gusta este tipo de humano›, sino que se debe a que nuestros datos son fundamentalmente parciales. No se trata solo de cualidades específicas de los humanos, como la raza o el género o lo que sea. También se trata de [datos] generales: puedes tener un motor de avión al que una determinada red neuronal le dé más preferencia. Se trata de los datos y de las matemáticas que hay detrás. Así que esas son algunas cosas. Vamos a empezar a ver expectativas menos infladas sobre lo que va a hacer la IA. Vamos a empezar a entender en qué consiste la tecnología. Vamos a empezar a ver algunos de estos problemas resueltos. También vamos a entender el razonamiento que hay detrás de algunos de estos problemas.

Sin embargo, pasando a lo que quiero hacer en estos campos, hay muchas cosas que quiero hacer. Me encanta trabajar con tecnologías de última generación, siendo la inteligencia artificial y el aprendizaje automático el principal conjunto de tecnologías que utilizo. Principalmente, quiero aplicar estas tecnologías en los campos de la sanidad y la educación. Por lo tanto, tomar esta tecnología, tomar los campos de la salud y la educación, donde creo que puede tener un impacto, y permitir a la gente dentro de estos campos para aprovechar la tecnología tanto como sea posible. Tengo una serie [en YouTube] que presento al menos una vez al mes llamada TechTime with Tanmay. En el primer episodio, que en realidad presentaba con Sam Lightstone y Rob High, ambos becarios de IBM, mis mentores, son directores de tecnología [del departamento de IBM]. Citando a Sam Whitestone, dijo: ‹La tecnología de la inteligencia artificial no sustituirá a los humanos, pero los humanos que utilicen la inteligencia artificial sustituirán a los humanos que no lo hagan›. Así que me encanta esa cita, y realmente quiero permitir que el mayor número posible de humanos aprovechen esta tecnología de la manera más accesible. Aparte de eso, no solo aplicar esta tecnología, sino también permitir que todo el mundo la utilice, tomando todo lo que aprendo sobre ella, compartiéndolo a través de recursos, como mi canal de YouTube, los talleres que puedo organizar, los libros que escribo –Tanmay Teaches Julia [y] Hello, Swift son algunos de ellos. A partir de ahí, estoy trabajando para alcanzar mi objetivo de llegar a 100.000 aspirantes a programadores. Hasta ahora, tengo alrededor de 17.000 personas. Pero, sí, eso es lo que quiero hacer. Implementar esta tecnología en campos como la sanidad y la educación, permitiendo a los desarrolladores hacer uso de ella y compartiendo mis conocimientos al mismo tiempo.